Update 3: There are two EEPROM corruption bugs in the e1000/e1000e driver, both fixed in 2.6.27, and I was chasing the wrong one. The correct fix commit should

Update 3: There are two EEPROM corruption bugs in the e1000/e1000e driver, both fixed in 2.6.27, and I was chasing the wrong one. The correct fix commit should be [3]. Still, the problem here is that the EEPROM of Intel 82571/82573 was writable directly via EEWR [4] without an initialization sequence. But according to the fix [3], there's indeed a hardware option to lock the EEPROM from unwanted writes. Corrected verdict: * 30% responsibility - Device driver not locking the EEPROM. * 70% responsibility - Intel's EEWR that write directly into EEPROM. [3] https://github.com/torvalds/linux/commit/4a7703582836f55a1cbad0e2c1c6ebbee3f9b3a7#diff-ca290b3e4f09ef68dedb39e7760f5405 https://github.com/torvalds/linux/commit/4a7703582836f55a1cb... [4] https://github.com/torvalds/linux/blob/4a7703582836f55a1cbad0e2c1c6ebbee3f9b3a7/drivers/net/e1000e/82571.c#L569 https://github.com/torvalds/linux/blob/4a7703582836f55a1cbad...