On Thu, 17 Jul 2003, Charles Lepple wrote: > Alan Stern said: > > The information in the -g4 log was helpful. Here's another patch, which > > is my attempt to fix the bug. It actually changes two things: > > Cool, thanks! No more kernel panics-- my filesystem thanks you. However, > the test still reports failure. > > > Try this patch and run those tests again. If it still fails, try > > repeating it with both this patch and the diagnostic patch I sent > > yesterday. > > Representative logs attached. Occasionally, I would see a few more of the > "Element != First TD" printouts, but that was hard to reproduce.
Don't worry about that; it's not an error. It just means that the debugging snapshot of the driver state was made at a time when the USB transfer being shown had already started (or in this case, had already finished). A similar disclaimer applies to the "Element points to QH (bug?)" messages. > I am assuming that something still isn't going right, since without your > debug patch, uhci-hcd still does some printks, and usbtest reports errors. > However, the final result code from testusb is zero. Is this normal? It might not be as bad as you think. The messages from uhci-hcd are alerting you to the fact that some of the control transfers in the test were short -- the device didn't send all the information requested by the test program. That might or might not be an error; it depends on what the test is doing and on whether your device is working correctly. I'm not sure about that last message from usbtest, though. Maybe David can help explain what's going on. David -- here's the result of one of Charles's tests with my debugging output included (and some other stuff removed). In short: "Failed with status 0" means that a control transfer was short. Remove_list is a list of URBs that were unlinked by the user. Complete_list is a list of URBs that are ready to be sent to giveback_urb(), either because they completed or because they were unlinked. The URB's hcd-private data structure (urbp) is freed at the time the URB is taken off the complete_list. drivers/usb/misc/usbtest.c: 0000:00:02.2-1:0 TEST 10: queue 4 control calls, 5000 times uhci: added urbp c575653c to complete_list uhci: added urbp c57564f4 to complete_list drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 0 uhci: added urbp c57564ac to complete_list uhci: added urbp c5756464 to complete_list 4 URBs completed, one of which was a short transfer. uhci: took urbp c575653c off complete_list uhci: freed urbp c575653c uhci: took urbp c57564f4 off complete_list uhci: freed urbp c57564f4 uhci: took urbp c57564ac off complete_list uhci: freed urbp c57564ac 3 of them were sent to giveback_urb(). drivers/usb/misc/usbtest.c: subtest 2 error, status -121 drivers/usb/misc/usbtest.c: control queue 81.0a, err -121, 19997 left It seems that this output was triggered by the test program without waiting for the 4th URB's completion routine. uhci: added urbp c575653c to remove_list uhci: added urbp c57564f4 to remove_list Apparently 2 more URBs were submitted and then unlinked. usb 1-1: hcd_unlink_urb c7118dd8 fail -16 Here's where the test program tried to unlink the 4th URB from above and got an error because it had already completed. Note: c7118dd8 is the URB's address, not the urbp's. uhci: took urbp c5756464 off complete_list uhci: freed urbp c5756464 Here's where that 4th URB got sent to its completion routine. uhci: took urbp c575653c off remove_list uhci: added urbp c575653c to complete_list uhci: took urbp c57564f4 off remove_list uhci: added urbp c57564f4 to complete_list The 2 unlinked URBs were marked as having finished. uhci: added urbp c5756464 to complete_list Although the same address as that 4th one, this must refer to a new URB that was submitted and completed. uhci: took urbp c575653c off complete_list uhci: freed urbp c575653c uhci: took urbp c57564f4 off complete_list uhci: freed urbp c57564f4 uhci: took urbp c5756464 off complete_list uhci: freed urbp c5756464 The 2 unlinked URBs and the completed one were sent to giveback_urb(). drivers/usb/misc/usbtest.c: subcase 3 completed out of order, last 1 I don't know how the test program is supposed to work. Does this message really reflect what's going on? Does it mean that something isn't working as expected? Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
