Difference between revisions of "Problem with e1000: EEPROM Checksum Is Not Valid"

From ThinkWiki
Jump to: navigation, search
(Problem Description)
Line 8: Line 8:
  
 
The problem is caused by a power savings feature obstructing normal operation, and causes the first bytes read from the EEPROM to be corrupt, resulting in a random or invalid MAC address (but no other data corruption). The EEPROM checksum test traps the problem and the driver refuses to load.
 
The problem is caused by a power savings feature obstructing normal operation, and causes the first bytes read from the EEPROM to be corrupt, resulting in a random or invalid MAC address (but no other data corruption). The EEPROM checksum test traps the problem and the driver refuses to load.
 +
 +
== Solution ==
 +
 +
Lenovo provides a [http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-67166 script] that uses 'ethtool' command to update the card's settings. They say it is for SLED 10 but the Linux flavor shouldn't really matter. For some users, neither of the circumventions listed below help, but this script does!
  
 
== Circumvention ==
 
== Circumvention ==
Line 41: Line 45:
 
== See also ==
 
== See also ==
  
 +
* [http://www-307.ibm.com/pc/support/site.wss/document.do?sitestyle=lenovo&lndocid=MIGR-67166 Lenovo's solution]
 
* [http://sourceforge.net/tracker/index.php?func=detail&aid=1474679&group_id=42302&atid=447449 bug report] submitted for e1000 driver.
 
* [http://sourceforge.net/tracker/index.php?func=detail&aid=1474679&group_id=42302&atid=447449 bug report] submitted for e1000 driver.
 
* Discussion at [http://forums.gentoo.org/viewtopic-t-476305-highlight-e1000.html Gentoo forums]
 
* Discussion at [http://forums.gentoo.org/viewtopic-t-476305-highlight-e1000.html Gentoo forums]

Revision as of 20:10, 16 February 2007

Problem Description

On certain ThinkPads, e1000 driver for Intel Gigabit controller fails to load with the following error message in /var/log/messages:

e1000: 0000:02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid
e1000: probe of 0000:02:00.0 failed with error -5 

The problem is caused by a power savings feature obstructing normal operation, and causes the first bytes read from the EEPROM to be corrupt, resulting in a random or invalid MAC address (but no other data corruption). The EEPROM checksum test traps the problem and the driver refuses to load.

Solution

Lenovo provides a script that uses 'ethtool' command to update the card's settings. They say it is for SLED 10 but the Linux flavor shouldn't really matter. For some users, neither of the circumventions listed below help, but this script does!

Circumvention

  • Upgrade your BIOS

Lenovo has published newer BIOS revisions that appear to fix the issue for some users. The BIOS upgrade turns off "Deep smart power down" which has been known to cause issues at initialization time (the driver can re-enable the issue later if you desire, the feature works correctly then).

  • Insert a cable

Inserting a linked network cable bypasses the problem.

  • Take the checksum twice

This bug report describes a fix -- take the checksum twice. First time will report a bad checksum, second will work (the problem seems to be triggered by some power-saving technology). This requires a tweak to the driver source and a rebuild of your kernel. This is much better than a previous "fix" published here that disabled checksum checking entirely.

  • Remove/add kernel module

Removing and adding the kernel module is a possible work-around. As root, run

# modprobe -r e1000
# modprobe e1000

On some occasions, the commands have to be run twice before eth0 becomes useable. On some X60s this will not work at all.

  • Disabling and re-enabling the NIC in the BIOS

For some it fixed the issue finally, for some it helped just temporarily.

See also