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).
>With USB IRQ Enabled in BIOS everything fine.
That's because when the USB irq is enabled, the BIOS won't have
activated the USB controller because it thinks that the OS will handle
the USB interrupt natively (you don't happen to have the USB driver
enabled, so in your case the OS will _not_ have enabled the USB
controller either, and you never get an endless stream of interrupts,
because in this case there won't be any confusion - the only driver that
will actually use irq12 is the PS/2 driver and it will be able to
correctly handle all incoming interrupts - none of the crossed wires as
in the bad case).
Martin, the 2.3.19 code must go. It cannot be fixed up, and this cannot
continue.
Maybe NOW you understand why I have harped and harped on the issue of
NOT trying to fix up random PCI state without having the driver
explicitly ask for it? This is going to keep on happening as long as the
PCI subsystem continues to think that it can know what the
"RightThing(tm)" to do is. But the PCI subsystem really doesn't know
enough in the absense of a driver, and there may be some really good
reason why an IO area is not mapped or an IRQ is not enabled.
This is why missing interrupt routing stuff and missing IO mappings etc
should be enabled ONLY by the driver. Because by the time the driver
enables them, we know that they will be managed properly (or at least at
that time it can be considered a driver bug and fixed at the proper
level). Not before.
Linus
-
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/