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. On Mon, 16 Feb 2004, Axel Waggershauser wrote: > If I reconnect my test device after my unplug-test I get these syslog > lines: > > 16:45:28: uhci_irq status = 36, uhci->state = -10 > > # looks like there is an interrupt from a disabled (status=0x20) > # controller ??? the uhci_irq handler processes the pending urb... Yes; when the controller is suspended it will still generate interrupts for certain events: device attach, device unplug, and resume request. > 16:45:28: uhci_remove_pending_qhs processed d680eac0 > 16:45:28: >>> uhci_finish_urb d680eac0 > 16:45:28: >>> uhci_set_next_interrupt > 16:45:28: << uhci_set_next_interrupt > 16:45:28: << uhci_finish_urb d680eac0 > 16:45:28: drivers/usb/host/uhci-hcd.c: c800: wakeup_hc Okay, so the controller _is_ waking up. > 16:45:29: hub 1-0:1.0: new USB device on port 2, assigned address 5 > 16:45:34: usb 1-2: control timeout on ep0out > > # up until here happened what I expected but now there comes another > # uhci_urb_deque for the already processed d680eac0 URB... > > 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. > Thats all that happens after the reconnection. So there is especially no > irq except this one in the first line. To me it looks like the wakeup_hc > did not really work. If I connect another device (not my test device) > after the unplug-test I get the exact same results. I see that after the set_next_interrupt calls you didn't receive any interrupts. So even though the controller apparently was woken up, it still wasn't running correctly. 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. I wouldn't be surprised if this turns out to be another form of VIA weirdness causing your host controller to shutdown unexpectedly. 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
