> >With USB IRQ Disabled in BIOS:
> >
> >Was able to login (worked for a while) and afterwords
> >incurred hard lockup (I guess moved mouse ...). Powering off/on.
>
> Ok.
>
> This seems to be due to the excessively clever IRQ routing code that is
> new as of 2.3.19, which thinks that it should fix up things that the
> BIOS left disabled.
>
> Which is absolutely deadly, because the BIOS in this case apparently
> left the irq routing disabled for a very good reason: it is probably
> routing the USB IRQ into an SMI, and doing the magic "emulate old
> devices with USB" in SMM mode thing.
>
> When the new PCI code then changes the IRQ routing without being aware
> of the two levels of drivers that are using the interrupts (the kernel
> driver for a PS/2 mouse, and the SMM-mode BIOS driver that has the USB
> device enabled), you end up with an endless stream of USB interrupts
> that go to the wrong driver (which won't know what to do with them, so
> they'll keep coming - PCI interrupts are level-triggered, and once they
> start with nobody to shut them off they will just never stop).
Even when PCI device is trying to interrupt you (level triggered) you
can disable that interrupt. userirq driver is using this kind of dirty
trick, and yes, I works.
So, if uhci receives interrupts it does not know how to shut up, it
can disable that interrupt to avoid hard lockup. [Well, with some
sideeffects: like killing all devices on shared interrupt.]
We could do something like
if (no driver handler interrupt, and 1000 of such interrupts came one
after each other)
printk( "Someone is interrupting us and we don't know what to do
with it\n" );
disable_irq(offending_irq);
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/