On Mon, 16 Jul 2007, Akkana Peck wrote: > 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?
That's right. Or it might have a handler registered for a different IRQ number, a wrong one. > (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?) Yes. But your problem isn't that an IRQ is failing to work; the problem is that an IRQ is firing when the kernel thinks it shouldn't be. Alan Stern ------------------------------------------------------------------------- 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
