![]() | |||||||||||||
Messages in this thread |
>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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 13:02 [W:0.417 / U:0.060 seconds] ©2003-2008 Jasper Spaans | |||||||||||||