Description of problem: I have just upgraded from an Intel C2D 775 processor and MB to a i3(2100) 1155 processor and MB and have been seeing terrible network speeds and sometimes terrible disk to disk transfer speeds. This is affecting both Fedora 14 and Fedora 15. I use an Intel GT 1000/Pro network card rather than the motherboard NIC. On further investigation of the system log (/var/log/messages) I found the following; irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 0, comm: swapper Not tainted 2.6.35.13-92.fc14.x86_64 #1 Call Trace: <IRQ> [<ffffffff810a74f3>] __report_bad_irq.clone.1+0x3d/0x8b [<ffffffff810a765b>] note_interrupt+0x11a/0x17f [<ffffffff810a813b>] handle_fasteoi_irq+0xa8/0xce [<ffffffff8100c2ea>] handle_irq+0x88/0x90 [<ffffffff81470b44>] do_IRQ+0x5c/0xb4 [<ffffffff8146b093>] ret_from_intr+0x0/0x11 <EOI> [<ffffffff8102b7dd>] ? native_safe_halt+0xb/0xd [<ffffffff81290b75>] acpi_safe_halt+0x2a/0x43 [<ffffffff81290bae>] acpi_idle_do_entry+0x20/0x30 [<ffffffff81290c27>] acpi_idle_enter_c1+0x69/0xb6 [<ffffffff8146e01e>] ? notifier_call_chain+0x14/0x63 [<ffffffff81395d56>] ? menu_select+0x177/0x28c [<ffffffff81394d6d>] cpuidle_idle_call+0x8b/0xe9 [<ffffffff81008325>] cpu_idle+0xaa/0xcc [<ffffffff81452876>] rest_init+0x8a/0x8c [<ffffffff81ba1c49>] start_kernel+0x40b/0x416 [<ffffffff81ba12c6>] x86_64_start_reservations+0xb1/0xb5 [<ffffffff81ba13c2>] x86_64_start_kernel+0xf8/0x107 handlers: [<ffffffff813148a8>] (ata_bmdma_interrupt+0x0/0x1a) <-- Via PATA controller ?? [<ffffffffa00d8622>] (mpt_interrupt+0x0/0x890 [mptbase]) <--Sata PCIe controller [<ffffffffa00d8622>] (mpt_interrupt+0x0/0x890 [mptbase]) <--Sata PCIe controller [<ffffffffa0132850>] (e1000_intr+0x0/0xe9 [e1000]) <--- Network Card Disabling IRQ #16 After turning off the audio, USB3 and network controller on the MB I still got the same error (only the e1000 affected this time and a different IRQ number). The error can occur at any time, not just on boot, but it usually happens fairly quickly. The ata_bmdma_interrupt and e1000_intr were always affected. I cannot turn off the PATA controller without disabling the onboard SATA ports which are needed. Version-Release number of selected component (if applicable): Fedora 14 - (2.6.35.13-92.fc14.x86_64) Latest Fedora 15 install CD (as of last week). How reproducible: Always Steps to Reproduce: 1. Turn server on in above config. 2. Perform a large file transfer (5-10GB) 3. Watch for network transfer speed to change. Actual results: Network transfer speeds not able to go higher than 3MB/s Disk to disk transfer speeds also sometimes affected depending on which devices were also using the same IRQ which was disabled. Expected results: Normal boot, network speeds of approx 80-90MB/s (obtained when using the previous Intel C2D MB and CPU). Running Windows Server 2008r2 (SBS2011 / WHS 2011) exhibits no issues so the hardware would appear to be sound. Additional info: Hardware list; Intel i3 2100 CPU (LGA1155) Asus P8H67-V (v3) MB 4Gb DDR3 Ram 2xLSI 1068e PCIe (8 sata drive controllers) 1xIntel GT 1000/Pro (PCI) network controller. Various hard drives Norco 4220 case. Video is via the i3 and motherboard. The box is configured as a NAS and so no sound chipset is required. Originally reported in RedHat Bugzilla -> https://bugzilla.redhat.com/show_bug.cgi?id=713351 A quick search here has highlighted an number of other people with the same or very similar issues. https://bugzilla.kernel.org/show_bug.cgi?id=38632 https://bugzilla.kernel.org/show_bug.cgi?id=35332 https://bugzilla.kernel.org/show_bug.cgi?id=34242 https://bugzilla.kernel.org/show_bug.cgi?id=35332 https://bugzilla.kernel.org/show_bug.cgi?id=32242 https://bugzilla.kernel.org/show_bug.cgi?id=39122 I do not have Linux installed on this machine as it is a functioning server and needs to work but am interested in getting Linux back on it to use as a virtulization platform (have upgraded to an i5 and 12GB ram). This is not possible if this bug has not been rectified.
Thomas told me: > Weird, that this shares interrupts It's PCIe, so it should use MSI and > not a shared interrupt on the IOApic. We'd need a config and a full > dmesg to see what's possibly going on.