Comment 258 for bug 263555

Jesse, the question I'm left with is "what TYPE of eeprom interface does the broken NIC's implement?" I.e. what specific chip and what interface does it provide to the eeprom. Part of that you get from the customer, and part you get from Intel. Considering the Intel 7256x and 7257x parts, you have 4 different interface - that I know of.

For SPI / uW its hard to "accidentally" overwrite the prom as you have to sent it the write enable opcode first and then shift in the data. That's typically to complicated to happen via random garbage from a crash. If these are parts with SPI / uW addressed proms, then the overwrite is most likely the result of e1000e code being called. If that's the case, the debug builds of the driver would dump out the "I'm writing to the prom" messages. ( Hint: that's not the case. )

For the parallel eeprom, which are memory mapped, they can be overwritten by writing junk over top of thir address space. I think the 72573 has this type. The 72566 part also has a similar, but different memory mapped eeprom.

Point being, if the SPI based parts are having issues, this points towards programatic overwrite - as its unlikely to happen by accidental overwrite of I/O or memory space. Damage to the memory mapped parts, on the other hand, could happen because accidental overwrites are poorly defended.

Perhaps John can give us a clue as to the Intel parts which use SPI vs uW vs shadow RAM vs memory mapped. I don't see much in the code that latches the memory mapped eeproms from accidental overwrite. For the shadow ram method, it wants the write through flag to be set to true, well FF's are "true" so if this is the means to protect the underlying prom data, its a pretty feeble one. If the gfx crash writes all FF's over a swatch of memory, there you have it.