Bug 199709 - E1000 drivers compilation and compatibility problem with Netgear GB Smart Switches
E1000 drivers compilation and compatibility problem with Netgear GB Smart Swi...
Status: CLOSED DUPLICATE of bug 199701
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-21 11:04 EDT by Aaron Bowers
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-25 23:47:41 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 Aaron Bowers 2006-07-21 11:04:42 EDT
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-25 23:47:41 EDT

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

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