Bug 105397 - e1000 nic does not work properly under a 2.4.20 kernel
e1000 nic does not work properly under a 2.4.20 kernel
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i686 Linux
high Severity low
: ---
: ---
Assigned To: Jeff Garzik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-25 14:20 EDT by Brett Oster
Modified: 2013-07-02 22:15 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-11 14:17:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brett Oster 2003-09-25 14:20:15 EDT
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
Comment 1 Brett Oster 2003-09-25 16:16:54 EDT
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
Comment 2 tadavis 2003-10-17 19:15:04 EDT
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.
Comment 3 Brett Oster 2004-03-03 18:30:57 EST
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.

Note You need to log in before you can comment on or make changes to this bug.