On Tue, 17 Feb 2004, Axel Waggershauser wrote: > On Mon, 2004-02-16 at 18:30, Alan Stern wrote: > > Axel: > > > > Your problems have been among the most puzzling I've seen... :-) > > You might try this patch: > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=107671082606352&w=2 > > > > I think it will help solve one of your problems. > [...] > > > 16:45:34: >>> uhci_urb_dequeue d680eac0 > > > 16:45:34: >>> uhci_set_next_interrupt > > > 16:45:34: << uhci_set_next_interrupt > > > 16:45:34: uhci_urb_dequeue d680eac0 list_empty == true > > > 16:45:34: >>> uhci_set_next_interrupt > > > 16:45:34: << uhci_set_next_interrupt > > > 16:45:34: << uhci_urb_dequeue d680eac0 uhci->state: 2 > > > > Maybe the patch I mentioned above will fix this. > > No, it didn't. :-/
I'm surprised. The patch was intended to fix precisely that problem, where an URB would be dequeued after it had already finished. With that patch it should not be possible for an URB to terminate more than once without being resubmitted in between. The reasone is simple: transfer_result() in uhci-hcd.c and hcd_unlink_urb() & hcd_endpoint_disable() in core/hcd.c all check first that urb->status is equal to -EINPROGRESS and then they change it to something else. Did the debugging log end up looking exactly the same as last time? And are you sure that the URB hadn't been resubmitted after being sent to finish_urb? > > Here's something you can do to verify this diagnosis. Take the patch in > > http://marc.theaimsgroup.com/?l=linux-usb-devel&m=107560509311256&w=2 > > > > and apply the portion the changes the uhci-debug.c file. Every time > > you open the /proc/driver/uhci/... file (the one for the controller you > > are using) it will do the equivalent of set_next_interrupt. After > > running your test, unplugging the test device, and plugging in another > > device -- when you've reached the state shown at the end of the dmesg log > > here -- try cat'ing the file a couple of times. We'll see the state of > > the controller and whether or not any interrupts occur in your log. > > You advised me already to do exactly this and I did so with the result > that the controller could not be convinced to generate any > "set_next_interrupt calls" _after_ the unplug-test run. This did not > change with your patch mentioned above. I'm trying to help too many people with too many problems to remember all the details, so you'll have to forgive me when I forget some of earlier correspondence. I'm interested in seeing the state of the controller registers as printed in the /proc/driver/uhci/... file as well as whether or not an interrupt occurred. Can you provide the debugging log from that test? > > I wouldn't be surprised if this turns out to be another form of VIA > > weirdness causing your host controller to shutdown unexpectedly. > > Neither would I - actually my conclusion has been that exactly this is > the case. Therefore I hoped your workaround patch for the VIA weirdness > would help somehow. That workaround was only supposed to address "babble" packets, which you don't observe. Unfortunately it doesn't even seem to do that! Alan Stern ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
