This was a lengthy but informative message! On Fri, 27 Aug 2004, Alex Villac��s Lasso wrote:
> I have been looking on the mailing list to see whether anybody has a > problem like mine. The problem still exists in 2.6.8.1, and I am trying > to analyze what is going on in my system. > > DISCLAIMER: I am just an user, not a kernel or USB expert. My idea of > what is going on might be completely wrong. > > Having said that, here goes my guess: > > From what I can tell, my system has an USB 1.1 controller (uhci-hcd) > which fires interrupts at IRQ 5, and an USB 2.0 controller (ehci-hcd) which > reports interrupts at IRQ 10 (see question 1). This situation shows up > at /proc/interrupts (IRQ5 is handled by uhci-hcd and via-rhine, and > IRQ10 is handled by ehci-hcd *only*). It also shows up with lspci -v: > the USB 2.0 reports �PIN D mapped to IRQ 10�, and USB 1.1 reports �PIN A > mapped to IRQ 5�. > > When I rmmod ehci-hcd, everything goes fine. However, when I modprobe > ehci-hcd, /var/log/messages reports that ehci-hcd (USB 2.0) is being > assigned IRQ 10. This, by itself, is not suspicious for me. The problem > starts when I plug the memory stick. I believe (remember, I might be > terribly > wrong with this guess) that the following sequence of events occurs: I'm not an expert on how interrupt management works, but a lot of people have experienced problems with it when using ACPI. You could try booting with "pci=noacpi acpi=noirq" or "acpi=off" on the boot command line to disable it. You also might find some interesting reading here: http://bugme.osdl.org/show_bug.cgi?id=2243 > * The device is plugged, and it identifes itself as an USB 2.0-capable > device. > * Since ehci-hcd is loaded and the USB 2.0 controller is enabled, the > USB IRQ fires. > * The USB IRQ comes out at IRQ 5 (see question 3) No, that's not what happens. The device is _not_ high speed, so the EHCI controller turns it over to its companion UHCI full-speed controller. Then some time later an unexpected interrupt arrives on IRQ 5. > * ehci-hcd is waiting at IRQ 10, so it never gets notified :-( > * via-rhine tries to handle the interrupt. Since the network card does > not need servicing, via-rhine ignores the interrupt (which is expected). > * uhci-hcd tries to handle the interrupt. Somehow it decides that it > does not have to service the interrupt (maybe because it is a USB 2.0 > that needs > servicing, but uhci-hcd by itself only handles USB 1.1), and therefore > ignores the interrupt. > * nobody handled IRQ 5, so the kernel prints the �nobody cared!� > message, and then disables IRQ 5 > * no USB device works until the machine is rebooted > > Some questions I have about this situation: > > Q1: Is it normal or expected for a system with a USB 2.0 controller to > have different IRQs for USB 1.1 (IRQ 5) and USB 2.0 (IRQ 10)? Yes. > Q2: Is the Linux USB subsystem prepared to handle a (sane) system as > described in Q1? (Really, I don�t know) Yes. > Q3: Is it normal, or at least expected, for a USB 2.0 controller to fire > an interrupt through the USB 1.1 IRQ (which is a different IRQ from USB 2.0, > as described in Q1)? No, that can't happen. Not unless the system is broken -- but some systems are indeed broken (or at least damaged) in this sort of way. > Well, I thought, if the USB 2.0 interrupt fires at IRQ 5, then I should > force ehci-hcd to monitor IRQ 5 instead of IRQ 10. I tried setpci > INTERRUPT_LINE for this, but it does not work - modprobe ehci-hcd still > assigns IRQ 10 to ehci-hcd. I also tried echo 05 > irq at the pciXXXXXX > directories in sysfs, and it hangs (maybe it is chmod 444 for a reason - > I assigned chmod 777 before running echo). > > Any response (even a correction to my guesses) will be greatly appreciated. > Alex Villacis Lasso What has happened to other people is that some other device, typically an Ethernet interface, sends an interrupt request that the system mistakenly routes to the USB IRQ. It's the result of a bug or a misfeature in the computer's BIOS. > The original message follows: > I regularly use a usb-stick on my home computer (RedHat 9). Up to kernel > 2.6.6, it worked correctly, but > now the following appears on dmesg when inserting the usb stick, and the > device is not recognized: > > hub 1-0:1.0: port 1, status 0501, change 0001, 480 Mb/s > hub 1-0:1.0: debounce: port 1: delay 100ms stable 4 status 0x501 > hub 1-0:1.0: port 1 not reset yet, waiting 50ms > ehci_hcd 0000:00:10.3: port 1 full speed --> companion There, you just saw the EHCI controller reporting that the new device runs at full speed and handing the device over to the companion. > ehci_hcd 0000:00:10.3: GetStatus port 1 status 003801 POWER OWNER sig=j > CONNECT > uhci_hcd 0000:00:10.0: port 1 portsc 0093 > hub 2-0:1.0: port 1, status 0101, change 0001, 12 Mb/s > uhci_hcd 0000:00:10.0: wakeup_hc > hub 2-0:1.0: debounce: port 1: delay 100ms stable 4 status 0x101 At this point the companion controller has detected the new device. > usb 2-1: new full speed USB device using address 2 > irq 5: nobody cared! The rest you know... > This is probably something unique to my home machine - my work computer > uses the same kernel version with RedHat 8 and does not show this problem. > I notice that IRQ 5 seems to be shared by my network card and by USB, and > it is disabled as a result of this problem, so if I were using a LAN, I > would > lose access to the LAN after this problem. Try disabling ACPI at boot time. If that doesn't work, you could file a bug report using the URL mentioned above. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
