On Friday 29 August 2008 15:18:08 Tejun Heo wrote:

Thomas Renninger wrote:

quoted

quoted

quoted

There were several acpipnp problems recently, but this is another topic
and that needs fixing anyway, Bjorn is doing a real good job here.

Hmm... Maybe what's necessary it to detect IRQ misrouting and turn on
irqpoll on the specific IRQ (or IRQ handler), which would help 'nobody
cared' cases too.

But you risk that things never get fixed correctly.
At least yell loudly at the user that things must get fixed.
IMO the a message (you already see appearing?) at the right place:
try irqpoll, try xyz param is enough.

Yeah, the kernel should scream like hell but keep working after screaming.

quoted

The current behavior is not that bad and not that much machines
(at least new machines) are affected, but as said I am not
deeply involved in PCI/IRQ things.

The thing is IRQ storms occassionally happen on otherwise working
machines taking down the IRQ and all the devices running off the IRQ, so
it's not as cut and dry as boot or no boot.

AFAIK legacy IRQs can be routed somewhere else (below 16 while the APIC IRQ is 
somewhere above), thus the IRQ may happen twice. Sounds a bit like what you 
explained above.
At least I remember such a very specific problem from the
Real Time people.
(could eventually be switched off by very chipset specific quirks)

Anyway, this starts to get off topic and I am really the wrong one
to answer such questions, others probably know much more about this
than I do.

   Thomas