OpenSUSE Beta Can Brick Intel e1000e Network Cards

An anonymous reader writes "Some Intel cards don't just not work with the new OpenSUSE beta, they can get bricked as well. Check your hardware before you install!" The only card mentioned as affected is the Intel e1000e, and it's not just OpenSUSE for which this card is a problem, according to this short article: "Bug reports for Fedora 9 and 10 and Linux Kernel 2.6.27rc1 match the symptoms reported by SUSE users."

Comments

Badly written firmware.

[psergiu]

Any decent firmware for a device should not allow the user to accidentally destroy the device. Looks like Intel skipped on Q&A.

Re:Badly written firmware.

[reashlin]

Any decent device driver should also not be writing to the firmware, which i'm guessing is how the device can become bricked.

Re:Badly written firmware.

[arkhan_jg]

A few years back, Mandrake merged a kernel patch in their new release that would accidentally brick certain LG CDROM drives using old firmware versions when it checked if it had writing capabilities. This was largely LG's fault for re-using a valid command code to mean 'start flashing me now' instead, and of course, no firmware was then forthcoming, leaving the drive in an unusable state.

LG ended up replacing old affected drives, and the kernel patch was rewritten. Mandrake bore the brunt of the reputation hit though for quite a while, which I suspect will happen to SuSE.

The e1000e driver is the new one for pci-e based intel pro 1000 chipsets, with the old pci and pci-x cards unaffected with the original e1000 driver. Still, that's going to be quite a lot of cards affected.

Re:Badly written firmware.

[Anonymous Coward]

It appears that the bug is a combination of memory-mapped control registers which can enable flash writing and another (graphics related) problem which causes random data to be written to that area. The driver itself does not attempt to rewrite the firmware.

Re:Badly written firmware.

[jandrese]

Except for the multitude of cards that require you to basically reflash the firmware as part of the initialization? Cheap 802.11 cards are notorious for this, and it's a pain because it means you have to ship a binary blob with the driver and all of the licensing headaches that entails.

Re:Badly written firmware.

[ChrisJones]

the NVM is checksummed. If the checksum fails, the driver refuses to initialise the card.
It seems that something is able to write garbage data to the NVM, leaving all of its settings broken.

This isn't some database API where you get to do lots of nice high-level verification, this is twiddling bits in hardware. Of course it should be properly protected, and my discussions with Intel about this suggest that it is, and that something else is at work here, but until they release a fix, we won't know for sure.

Also, their own DOS tools to restore NIC EEPROMs actually break the laptop NICs to the point that they won't enumerate on the PCI bus, so there is literally no hope of recovery unless you happen to have a BIOS update which will rewrite all of the memory the NIC uses.

!Bricked

[Anonymous Coward]

Why won't people stop using the word brick to mean things that aren't bricked! All you have to do is use a quasi-negative reverse transponder linked to your flux capacitor to generate an inverse tachyon field, connect it to the JTAG while chanting Siaynoq and it will come right up. Sheesh!

Re:!Bricked

[clickety6]

I also hate it when people call these things bricked incorrectly.

Bricked XBOXen, bricked PSPs, bricked iPhones and now bricked network cards.

People, these things are not bricked! Believe me. I've tried building houses and garden walls out of them and they are absolutely fecking useless as bricks!

Please use the correct term in future. These items are not bricked, they are just FUBI (fecked up by incompetence)

Thank you...

That's not what Bricked means!!!!oneone1

[OverlordQ]

I hate it when people keep incorrectly using brick . . . . wait, what? They used it right? Oh . . . my bad, carry on.

Kernel fix, perhaps?

[Anonymous Coward]

Kernel 2.6.27-rc7 has a changelog entry that reads:

Christopher Li (1):
            e1000: prevent corruption of EEPROM/NVM

Re:Kernel fix, perhaps?

[neonprimetime]

From: Christopher Li

Andrey reports e1000 corruption, and that a patch in vmware's ESX fixed it.

The EEPROM corruption is triggered by concurrent access of the EEPROM read/write. Putting a lock around it solve the problem.

link

Oh great.

[gandhi_2]

Remember when Dell told customers that installing Linux on their computers voided the warranty?

Remember how everyone on /. called bullshit?

This doesn't look good for our cause.

What is really happening regarding this problem

[ronch]

I work on the e1000 team (including the e1000e driver) and here is what we know. A panic in another driver (believed to be the gfx driver but uncertain) which scribbles over the NIC/LOM non-volatile memory (NVM). This is only happening with the 2.6.27-rc kernels on ICHx systems. Since the NIC/LOM VNM is part of the whole BIOS image other things in the system could be effected by this driver panic as well. An update of the system BIOS will restore the NIC/LOM to be operational. We have some patches under test right now that we will be releasing later today to protect the NIC/LOM NVM. That should help narrow down who is scribbling over NVM.

Re:What is really happening regarding this problem

[Anonymous Coward]

This post was what to helpful and informative.

It doesn't belong in the comments of a Slashdot article!

Re:What is really happening regarding this problem

[pipatron]

This post was what to helpful and informative.

Good thing you set it straight again with a sentence that's both incomprehensible and contains a typo.

Re:What is really happening regarding this problem

[ChrisJones]

As I just pointed out elsewhere, that particular comment is not correct.
A BIOS update *may* restore the NIC, but it depends purely on the BIOS update including that information.
All of the available updates for my laptop do not include that, so the device was not recoverable. ie bricked.

Re:What is really happening regarding this problem

[T.E.D.]

I've written an E1000 driver (for a realtime program on a different OS). The issue is that once you have the base address registers for the card mapped into system memory, they are there. There's no super-special secret mechanisim devoted to writing only to the flash RAM.

Oversimplifying things a great deal (so experts out there, please don't roast me over the nitty details), every PCI device in your system presents software drivers with up to 6 "Base Address Registers" (BARs). Most PCI devices really only use one or two of those. This is (mostly) the device-driver's only window into the PCI device.

At bootup the system places the physical address of the device's control registers and memory into its BARs. When the device driver starts up later, it grabs those physical addresses and maps them into virtual memory so that software can get at them.

Once this is done, *all* the device's control registers are avialble to software. If one of these registers can command the card to write data to flash (as one of the control registers on the E1000 does), then the proper (or improper) value written to that memory location by *anyone* will cause a flash write. Its that simple.

Mandriva notification

[AdamWill]

This can also affect Mandriva Linux 2009 pre-releases. To be clear, the bug is in the upstream kernel itself, not in any code specific to any distribution.
It affects any 2.6.27rc kernel, whether it's in a distribution or a clean upstream build.
We have posted a full, detailed notification of the issue for Mandriva users.