Description of problem: System is ABit KN9 SLI, MCP55 chipset. I use only USB peripherals. The keyboard sometimes gets crazy, it repeats the last pressed key and doesn't stop it. Nothing can bring the system back to a working state, only hard reboot. It seems the IRQs are generated in such rate that even ACPI events (single short press on power switch) are missed. Version-Release number of selected component (if applicable): kernel-2.6.19-1.2911.fc6 and kernel-2.6.19-1.2911.6.4.fc6 How reproducible: non-deterministic, it happens after some hours of work Steps to Reproduce: 1. just work on the machine and type... 2. 3. Actual results: Described above Expected results: It shouldn't happen Additional info: kernel-rt-2.6.20-0119.rt8 from Ingo Molnar doesn't have the problem. I guess the problem is fixed in 2.6.20.x but there is no 2.6.20 based kernel from Fedora Core 6 yet.
I had some other problems on this machine, too. the built-in dual Gb forcedeth didn't really work, meaning: the thin client I have behave very erratic, like it didn't get IP from the DHCP server or when it did, it failed to mount the NFS root or stalled later during boot. I have put a 3Com 905C in the main machine and the thin client was always succeeded to boot up. However, after some work, the 3Com card stopped working, I got something like this below in the logs. This row of messages was repeated some times, eventually stopping the card. This is also lethal for the thin client hanging off that ethernet line. Mar 10 08:15:08 static-81-17-177-202 kernel: NETDEV WATCHDOG: eth2: transmit timed out Mar 10 08:15:08 static-81-17-177-202 kernel: eth2: transmit timed out, tx_status 00 status e601. Mar 10 08:15:08 static-81-17-177-202 kernel: diagnostics: net 0cfa media 8880 dma 0000003a fifo 0000 Mar 10 08:15:08 static-81-17-177-202 kernel: eth2: Interrupt posted but not delivered -- IRQ blocked by another device? Mar 10 08:15:08 static-81-17-177-202 kernel: Flags; bus-master 1, dirty 9944973(13) current 9944973(13) Mar 10 08:15:08 static-81-17-177-202 kernel: Transmit list 00000000 vs. ffff81007bd1aa20. Mar 10 08:15:08 static-81-17-177-202 kernel: 0: @ffff81007bd1a200 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 1: @ffff81007bd1a2a0 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 2: @ffff81007bd1a340 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 3: @ffff81007bd1a3e0 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 4: @ffff81007bd1a480 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 5: @ffff81007bd1a520 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 6: @ffff81007bd1a5c0 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 7: @ffff81007bd1a660 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 8: @ffff81007bd1a700 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 9: @ffff81007bd1a7a0 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 10: @ffff81007bd1a840 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 11: @ffff81007bd1a8e0 length 800005ea status 8c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 12: @ffff81007bd1a980 length 800005ea status 8c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 13: @ffff81007bd1aa20 length 800005ea status 0c0105ea Mar 10 08:15:08 static-81-17-177-202 kernel: 14: @ffff81007bd1aac0 length 8000006e status 0c01006e Mar 10 08:15:08 static-81-17-177-202 kernel: 15: @ffff81007bd1ab60 length 800005ea status 0c0105ea In the meantime, I have changed two things on this machine. Now kernel version is 2.6.19-1.2911.6.5.fc6. I also got the above error on eth2 just like with earlier kernels. I guess the USB keyboard would drop dead after some time, too. ABit released BIOS version 18 for this mainboard. The changelog mentions "enhanced compatibility with Linux". I upgraded to it and will report back if there's an error.
Since the upgrading to the new BIOS I haven't had a single IRQ-related problem with the machine.
Thanks for the report. I looked at it but could not corellate it with any changes... Naturally :-) The Ingo's branch must be using some different mode or interrupt routing.