Intel i219-LM Had Only Been Running At ~60% Of Maximum Speed Due To Linux Driver Bug

[stormcrow]

This is yet another "how was this not tested?" situations, though, if the regression was caused by something else in the kernel that isn't necessarily specific to this driver then I suppose there is some grace to be had.

I think you're proceeding under the illusion that Linus's tree is actually fully tested and "stable" on release. It's not. It's only tested by a small group of volunteers. If there's no ground shattering revelations by that relatively small group of people, it'll be pushed out to the wider public for their testing and edification. Things like that bug are easily missed in that short period of time. It's a misnomer that people, including Michael btw, label Linus' tree releases stable. They're only stable in that Linus' build process is able to complete a build, and that it doesn't completely crash the majority of the volunteer testers. That doesn't mean serious bugs aren't lurking somewhere else. (Edit to add: This is why I stick to LTS distros - I don't need a major problem resulting from premature ingestion of Linus' release kernels because they broke something important during the inclusion process. LTS on my main desktop tests for gotchas before I update my more critical systems which also use LTS distros.)

Frankly, outside of Intel's CPU software engineer contributors, Intel's contributions to the Linux kernel in NICs, GPUs, etc have often been pretty bad quality. I can't stand Intel's hardware because of their traditionally bad driver support regardless of OS. (Adding: I often doubt Intel even bothers testing their own changes. They make them, push them out as finished after cursory testing to see if it builds and probably that's about it.)

[schmidtbag]

stormcrow I wasn't speaking about the kernel devs, because I agree that it isn't their job to make sure the code works optimally - like you said, they just want to ensure it doesn't break anything. What I'm saying is Intel should have tested whether their hardware is running at its full potential before doing a pull request. In other words, this problem should have been noticed before it reached Linus' tree.

Again though: this is assuming that the drivers were actually working fine when submitted, but something else in the kernel caused a regression. Stuff like that just happens sometimes.

[gotar]

I reported a reproducible bug that crashes an Intel NIC (the driver dumps its registers and then the server is unreachable) a while ago.
I reported this both on the bugtracker and the Intel-specific mailing list (which is low traffic so it could not have been overlooked).

Intel engineers don't care. I didn't even get a response.

I've never had such a bad experience with NICs on Linux as with Intel. Their products are plagued with unfixable hardware bugs and their engineers are busy doing who knows what ... probably designing the next broken product.

Well, all the problems seem to be fixed now, as I've recently noticed - they've entirely erased the bugtracker at e1000.sf.

[ll1025]

was this bug around since the hw was introduced to the market, or is the userbase so small nobody noticed?

it's very puzzling to me that something like that would slip unnoticed for so long

e1000e is not uncommon. It is the default NIC for VMWare workstation and I believe even ESXi unless you're on a recent hardware level.