Alan Stern writes:
> Maybe. The difficulty with trying to solve these "nobody cared"
> problems is that you can't rely on the list of known interrupt
> handlers. By definition, "nobody cared" means some interrupts occurred
> which the handlers all ignored. Maybe something is wrong with one of
> the handlers, but more likely the interrupts were caused by a
> completely different device -- one without a registered handler on that
> IRQ.
Interesting. I have a lot on IRQ9: /proc/interrupts shows yenta,
uhci_hcd:usb1, YMFPCI, eth0. Those are all working now (the cardbus
eth0 card, the usb hub, and sound). But if the bad device doesn't
have a handler registered, does that mean it might not even show
up in /proc/interrupts?
(Hmm, maybe I spoke too soon. Turns out the cardbus network card
no longer gets configured properly on insert, only at boot. But I
suspect that's an unrelated issue: dmesg does show eject/insert
events, and that means the IRQ is working for yenta, right?)
> Quite often ACPI ends up being involved, one way or another. What
> happens if you boot with "acpi=off"?
It's definitely not ACPI -- I disable that entirely and use APM,
because of bug 8274 where kacpid eats up all available CPU time.
...Akkana
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
