e1000e Bug Squashed — Linux Kernel Patch Released

ruphus13 writes "As mentioned earlier, there was a kernel bug in the alpha/beta version of the Linux kernel (up to 2.6.27 rc7), which was corrupting (and rendering useless) the EEPROM/NVM of adapters. Thankfully, a patch is now out that prevents writing to the EEPROM once the driver is loaded, and this follows a patch released by Intel earlier in the week. From the article: 'The Intel team is currently working on narrowing down the details of how and why these chipsets were affected. They also plan on releasing patches shortly to restore the EEPROM on any adapters that have been affected, via saved images using ethtool -e or from identical systems.' This is good news as we move towards a production release!"

News?

[quarrel]

I know this is News For Nerds and all that, but isn't this a tad specific?

An alpha/beta of the most recent linux kernel patch had a bug fixed, and it hits the front page?

Don't get me wrong, I'm glad they found it, but this is kinda the point of debug cycles.. If we start reporting every bug squashed in all the major open source projects out there this is going to go downhill fast.. (of course, it's possible some may think that the idle. is only a step above..)

--Q

Re:News?

[Atriqus]

It's newsworthy because it was a bug that actually bricked hardware.

e1000 been broken a while

[AaronW]

About a year ago we built up some new machines to run Linux and found that multiple e1000 cards would cause the Ethernet connectivity to drop and become useless. We ended up replacing them with much cheaper Realtek cards and all the problems disappeared. I haven't trusted Intel since. It's as if there were some buggy interrupt interaction with the on-board Intel Ethernet in the 915 chipset.

Re:News?

[sumdumass]

Try Erasing the BIOS on the main board and you will be more accurate in your comparison.

This bug actually flashed the firmware for the network controller and hosed access to it in some unexplained sort of way. That is something note worthy because of the rarity of it. If it was simply hosing something that was readily diagnosable and more common like a boot sector or something, then it would be different. It isn't often the software is associated with hardware damage either purposefully or accidentally.

BTW, I know there are recovery methods for a hosed BIOS. That isn't the point. Simply installing an operating system shouldn't hose it nor should it hose hardware either. Imagine all the people who just thought their card was broken or something and went for a refund under warranty or the bad name Intel or Linux received for the "faulty shipment of devices" or the ability to break a device. This is something that would work in windows, load Linux in a dual boot mode, it would stop working in both windows and Linux without any errors or indication that the car was even capable of being seen by the mainboard.

Re:Hardware of Software Problem?

[techno-vampire]

He's got good reason. It should be impossible for the system to write to the EEPROM without special measures being taken, possibly a jumper that has to be removed to allow it. And, if possible, the card won't work right (in some way that doesn't prevent boot) until the jumper's put back to normal. That way, if you really have to re-flash it, you can, but it's not going to happen by accident.

I remember having a motherboard with a jumper that had to be specially set to update the BIOS. The smart way was to power down, open the case and pull the jumper so that you could flash the EEPROM. Then, of course, once that was done, reverse the procedure for safety. I always regarded anybody who left the jumper off for the rare convenience as fools who deserved anything that might happen.

So, we put the workaround in _hardware_?

[SanityInAnarchy]

Linus has a very good analogy here -- in fact, I love the fact that on the rare occasions I have to set modelines myself, I can pretty much put whatever I want, knowing that if it doesn't work, I can just ctrl+alt+backspace and try again.

But the conclusion does bother me: We're basically saying that all software is buggy, or that we're incapable of preventing this kind of thing from happening (in software). This is true of most modern OS designs -- monolithic kernels do make it possible for pretty much any driver to accidentally ruin any other driver's day.

The proposed workaround, then, is to prevent that memory from being written -- and to prevent this in hardware, for no other reason than to avoid having to write it into every kernel that might potentially allow buggy code to run in Ring 0.

I don't like either solution. Hardware shouldn't be brickable from software, or at least, not so easily. But software shouldn't need hardware to coddle it, either -- why is the SSD in this laptop emulating a hard disk?

Re:So, we put the workaround in _hardware_?

[PRMan]

Yes, because as long as the hardware can be bricked by software, it remains an exploit that can be used by malicious software writers.

Speaking of the fried monitors, back in the day a college I worked at got a virus that fried 2 monitors before I got smart and put a Hercules monochrome card in it and cleaned it up.

So, yes, while it can (and should) be worked around in Linux, it should also be fixed in hardware, if possible.