Bug 199709

Summary: E1000 drivers compilation and compatibility problem with Netgear GB Smart Switches
Product: [Fedora] Fedora Reporter: Aaron Bowers <aarbow>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-26 03:47:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Aaron Bowers 2006-07-21 15:04:42 UTC
Description of problem:

DNS resolution doesn't function and some delays occur while attempting to access
other machines via IP address from SuperMicro X7DVL-E motherboard with onboard
Intel Gigabit Ethernet adapters using both most recent BIOS rev (1.1a) and
original BIOS (1.0) and connecting to Netgear GS724TNA Smart Gigabit Switch with
most recent firmware installed.

The version of the e1000 drivers recently integrated into the kernel (i.e.
7.0.33) won't work with this smart switch, but will work with the equivalent
dumb Netgear GB switch.

I had to download and install the most recent drivers from the motherboard
manufacturer (7.0.39) in order to get proper communication to work between these
new machines and the Smart Netgear switch.  However these drivers would not
compile on the most recent smp kernel (2157) giving me the folowing error:

make install
make -C /lib/modules/2.6.17-1.2157_FC5smp/build SUBDIRS=/root/e1000-7.0.39/src
modules
make[1]: Entering directory `/usr/src/kernels/2.6.17-1.2157_FC5-smp-i686'
  CC [M]  /root/e1000-7.0.39/src/e1000_main.o
/root/e1000-7.0.39/src/e1000_main.c: In function âe1000_tsoâ:
/root/e1000-7.0.39/src/e1000_main.c:2502: error: âstruct skb_shared_infoâ has no
member named âtso_sizeâ
/root/e1000-7.0.39/src/e1000_main.c:2510: error: âstruct skb_shared_infoâ has no
member named âtso_sizeâ
/root/e1000-7.0.39/src/e1000_main.c: In function âe1000_tx_mapâ:
/root/e1000-7.0.39/src/e1000_main.c:2629: error: âstruct skb_shared_infoâ has no
member named âtso_sizeâ
/root/e1000-7.0.39/src/e1000_main.c: In function âe1000_xmit_frameâ:
/root/e1000-7.0.39/src/e1000_main.c:2877: error: âstruct skb_shared_infoâ has no
member named âtso_sizeâ
/root/e1000-7.0.39/src/e1000_main.c:2927: error: âstruct skb_shared_infoâ has no
member named âtso_sizeâ
make[2]: *** [/root/e1000-7.0.39/src/e1000_main.o] Error 1
make[1]: *** [_module_/root/e1000-7.0.39/src] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.17-1.2157_FC5-smp-i686'
make: *** [default] Error 2

When I boot to the 2145 smp kernel I am able to compile the 7.0.39 version of
the driver and all the problems go away.

However, as it is, I am stuck with the 2145 kernel.

Would it be possible to release the next kernel update with the e1000 family of
drivers integrated but at version 7.0.39 or 7.0.38 rather than 7.0.33 which is
the integrated version at the moment? 




Version-Release number of selected component (if applicable):


How reproducible:  Every time I use the 7.0.33 NIC drivers in combination with
the hardware and kernels listed above. 


Steps to Reproduce:
1. Connect all the hardware listed above with the versions of the software
listed above
2. Attempt to do a dnslookup or a ping using an FQDN
3. The prompt hangs for a while and then command fails
  
Actual results:

No DNS name resolution possible and some delayed communication between hosts via
IP addresses

Expected results:

Normal TCP/IP communications:  DNS resolution, no or mimimal packet loss.

Additional info:

I tested an IBM Thinkpad running FC4 with the most recent kernel too, and it had
the same problem on this family of Netgear Switches.  

I also tested two different systems (Thinkpad and Supermicro based system)
running RHEL4ES, and those systems had no problems whatsoever.

Comment 1 Dave Jones 2006-07-26 03:47:41 UTC

*** This bug has been marked as a duplicate of 199701 ***