Description of problem: Under a 2.4.20 or higher redhat kernel, a nic using the e1000 driver will transfer 1.4 megs and then drop NETDEV WATCHDOG: eth2: transmit timed out into the dmesg, and then it claims to be brought back up. However, the only way for it to actually transfer another 1.4 megs is to ifconfig the device down, rmmod the module, modprobe it, and bring the interface back up. Interestingly enough, under a 2.4.18 kernel (2.4.18-14 is the one that I have tested) it behaves just fine. I compiled the version of the e1000 driver that came with the 2.4.18-14 kernel for 2.4.20-8 with no luck. I have tried many different revisions of the 2.4.20 kernel, but I could not get any of them working, including the base kernel, the smp kernel, and the bigmem (which is what I really need). I would usually not mind just running the 2.4.18 kernel, but apparently there is an issue with 2.4.18 kernels and oracle databases (related to IO (or so my DBA tells me)), so I'm trying to find a solution here. The hardware that I have is as follows: two dell servers, a 4600 and a 2600, as well as a cobbled together machine. All three of them are using intel fiber gigabit nics. Version-Release number of selected component (if applicable): 2.4.20-8bigmem How reproducible: Every time Steps to Reproduce: 1. config the nic 2. try to transfer any amount of data 3. as soon as 1.4 megs of traffic are sent/recieved, the device stops working. Actual results: The device must be ifconfiged down, have the driver reloaded, and ifconfiged back up. Expected results: It sould work without a problem. Additional info: dmesg: Intel(R) PRO/1000 Network Driver - version 4.4.19-k1 Copyright (c) 1999-2002 Intel Corporation. divert: allocating divert_blk for eth2 eth2: Intel(R) PRO/1000 Network Connection Receive Interrupt Delay set to 0 PCI: 0d:06.0 PCI cache line size set incorrectly (64 bytes) by BIOS/FW. PCI: 0d:06.0 PCI cache line size corrected to 128. ip_tables: (C) 2000-2002 Netfilter core team e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport0: irq 7 detected lp0: using parport0 (polling). lp0: console ready NETDEV WATCHDOG: eth2: transmit timed out e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex divert: freeing divert_blk for eth2 Intel(R) PRO/1000 Network Driver - version 4.4.19-k1 Copyright (c) 1999-2002 Intel Corporation. divert: allocating divert_blk for eth2 eth2: Intel(R) PRO/1000 Network Connection Receive Interrupt Delay set to 0 ip_tables: (C) 2000-2002 Netfilter core team e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex NETDEV WATCHDOG: eth2: transmit timed out e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex lspci -v: 0d:06.0 Ethernet controller: Intel Corp. 82542 Gigabit Ethernet Controller (rev 02) Subsystem: Intel Corp. PRO/1000 Gigabit Server Adapter Flags: bus master, medium devsel, latency 32, IRQ 43 Memory at edd00000 (32-bit, non-prefetchable) [size=128K] Capabilities: [dc] Power Management version 1
more information: dmesg under a 2.4.20 kernel contains these lines: PCI: 0d:06.0 PCI cache line size set incorrectly (64 bytes) by BIOS/FW. PCI: 0d:06.0 PCI cache line size corrected to 128. dmesg under 2.4.18 has about 6 of these: PCI: 0d:06.0 PCI cache line size set incorrectly (64 bytes) by BIOS/FW, expecting 32
diff -urNp linux-10010/arch/i386/config.in linux-10020/arch/i386/config.in --- linux-10010/arch/i386/config.in +++ linux-10020/arch/i386/config.in @@ -98,7 +98,7 @@ if [ "$CONFIG_M586MMX" = "y" ]; then define_bool CONFIG_X86_F00F_WORKS_OK n fi if [ "$CONFIG_M686" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACHE_SHIFT 7 define_bool CONFIG_X86_HAS_TSC y define_bool CONFIG_X86_GOOD_APIC y define_bool CONFIG_X86_PGE y @@ -107,7 +107,7 @@ if [ "$CONFIG_M686" = "y" ]; then define_bool CONFIG_X86_F00F_WORKS_OK y fi if [ "$CONFIG_MPENTIUMIII" = "y" ]; then - define_int CONFIG_X86_L1_CACHE_SHIFT 5 + define_int CONFIG_X86_L1_CACHE_SHIFT 7 define_bool CONFIG_X86_HAS_TSC y define_bool CONFIG_X86_GOOD_APIC y define_bool CONFIG_X86_PGE y this broke it.
the cards were somesort of pre-production oem samples that a company sold to us. They worked under single proc amd workstations, but not under the intel boxes. please close this bug.