e1000e NVM corruption

From: jbi
Date: Sun Sep 28 2008 - 05:48:41 EST


I am not a member of this list (I read occasionally via the public archives) or an experienced kernel hacker but I do have a few semi-informed thoughts on the 8256x NVM corruption issue. Take with salt as necessary:

According to Intel's datasheet, these interfaces expose *writable* PCI ID registers at NVM words 0x0A-0x0E[1]. Fill the NVM with FFs and the interface will probably respond with vendor ID : device ID FFFF:FFFF during bus enumeration. The potential for these devices to disappear off the PCI bus after NVM corruption means that unbricking damaged devices could be nontrivial.

One possible recovery option would be see if a bricked interface still responds to commands at the appropriate hardware address in the PCI configuration space. Even if the device escapes enumeration because its vendor ID and device ID are invalid, the hardware might be alive enough to work with an NVM-reflash driver that ignored the PCI ID. In the best case, getting a dead device back could just be a matter of setting up MBARB by writing to the configuration space for bus 0 dev 25 fn 0 (for ICH9) and reloading the NVM with a reasonable set of defaults.

Another recovery possibility would be to rewrite the NVM using the ICH's SPI interface. The same flash chip serves both the BIOS and NIC. The NVM might be rewritable through the ICH even if the NVM is too deeply corrupted for the NIC to respond to reflash commands. This fix would be complex, risky, and possibly motherboard specific, but should be able to put most bricked 8256x NICs back together unless NVM corruption has caused deeper damage.

Finally, given that one write to the wrong part of the NVM will turn one of these NICs into a brick, memory mapping the NVM--even for the briefest period--seems deeply imprudent. As long as the NVM is memory mapped, all it takes to turn one of these NICs into a brick is for one kernel mode bug to make one dword write to any of those registers. With the current cost of stomping on 8256x NVM data running at upwards of $500 per laptop, eliminating MMIO NVM access in favor of extensively sanity checked IO-mapped access seems like a very good idea. Unlike the simplicity of MMIO writes, the IO-based flash write process for the 8256x chips is sufficiently complex that rogue writes are unlikely to happen by accident.



[1]
http://download.intel.com/design/network/applnots/ICH9_NVM.pdf
See especially the example NVM tables in the last few pages.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/