Sure. uhci_irq() in drivers/usb/host/uhci-hcd.c receives the interrupt and sets uhci->resume_detect to 1. Then hc_state_transitions() in the same file sees uhci->resume_detect and calls wakeup_hc() to restart the controller.
The first thing to prove is that the interrupt never happens. Then to figure out why.
I can tell you why. No interrupt happened because the controller didn't request one, because it never realized that anything was connected to the port. But if you want to investigate more closely, please do so.
Well your right. Both coldplug and hotplug does not get me to uhci_irq(), but then again neither does the unplug. ;-| The unplug does get to core/usb.c:usb_disconnect()
Whats the best way to figure out if interrupts are even enabled on the device?
Could this be related to acpi? If so, what can we look at?
I tried booting the kernel with acpi=off, but again... no effect.
If the controller doesn't generate an interrupt, it doesn't matter what the ACPI settings are. And even if it does generate an interrupt and the driver restarts it, if it can't detect the new connection you won't be able to communicate with the device.
I thought that maybe the interrupt wasn't being generated because... maybe... ACPI sw might have powered down the USB controller.
... snip ...
That reminds me of something I wanted to ask you about: Do you have an EHCI controller on your computer as well as UHCI?
Yes, its a Centrino laptop and uses the Intel ICH4(82801DB).
If you do, you could try loading the ehci_hcd driver (if it's not already loaded) or unloading it (if it is). It's possible that the EHCI controller is causing your problem. The way it works is, a new device is connected first to the EHCI controller, which only works at high speed. If the controller determines that the device is full speed or low speed, it hands the device over to a "companion" UHCI controller. If the handoff failed for some reason, your symptoms would be the expected result.ehci_hcd was not loaded, so I loaded it, but no effect.
Presumably I could load it with modprobe at run time, rather than to have to boot with it in.
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
