RE: 2.6.2-rc3: irq#19 - nobody cared - with an au88xx

[Brown, Len]

>I'm assuming that it is not the fault of either of these drivers, since
>both of those are quite straightforward; they appear to be actually
>being triggered when nothing is going on.

If IRQ initialization is done incorrectly, it is possible
For a driver to request_irq(X), while the hardware is actually
on IRQ Y.

Then when that device becomes active, it would kill the other
devices on Y because its handler is looking for interrupts on X.

If this happens with acpi enabled, but doesn't happen with acpi=off
or pci=noacpi, then we need to compare the /proc/interrupts between
the working and failintg configs to see if the IRQs have moved around
when perhaps they should not have.  Dmesg from the ACPI case would
also be needed.

>There was a set of APIC errors an hour before, but they're probably
>unrelated:
>Apr  6 11:31:31 nevyn kernel: APIC error on CPU1: 00(08)
>Apr  6 11:31:31 nevyn kernel: APIC error on CPU0: 00(02)

I believe this is due to transient hardware errors on your MB.
Though not fatal, it isn't a good indicator.

-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/