The Big Linux 2.6.35 Kernel Problem Is Fixed

[phoronix]

Phoronix: The Big Linux 2.6.35 Kernel Problem Is Fixed

Last week we reported on a disastrous bug within the Linux 2.6.35 kernel that while this kernel is still months from being officially released, a major regression was introduced that slaughtered the Linux system's performance. This was experienced across multiple systems, architectures, and file-systems. Today we can officially report that this problem has been resolved...

http://www.phoronix.com/vr.php?view=ODMxNQ

[diegocg]

"To us at least, it still is a real problem that such a regression can be introduced in the mainline kernel and live there for a number of days without being addressed -- especially when it negatively affects the operating system's performance in so many different areas."

Well, I strongly disagree. It's not a "problem" that such regressions can be introduced. Of course, it's a bug that must be solved, but there is nothing strange or atypical with finding such bugs in a pre-rc1 git snapshot. That's why -rcx releases exist. That's why there are three months of kernel development. To find such bugs. So there is nothing "unexpected" here, a bug was found (which, BTW, is far from being a critical bug), and it was fixed. Big deal.

In fact, if you _really_ follow the kernel development (which phoronix editors don't seem to do), there are always several reverts of commits that introduce bugs that are detected in -rc releases. If you need a tree that merges bug fixes immediately then the Linus tree is not for you, because Linus may take a week off to go to some conference or because of holidays or things like that. It's also not strange that an important fix may get delayed just because people is discussing how it must be fixed. At this stage, you are expected to report bugs, test and apply the corresponding bugfix patches yourself.

In other words. Can Phoronix stop doing ridiculous claims the next time? You _will_ find performance regressions and bugs in 2.6.26-pre-rc1 if you search them, and in 2.6.27-pre-rc1, and in 2.6.28-pre-rc1. It's a good thing if you want to become a kernel tester, but they aren't interesting news.

[Vii7]

Don't see how you can't complain about that, since was intended for testing so there is room for other priorities. Yet, that could be a major problem if we're talking about a stable release - and in that situation a fix would be 1'st priority, are wouldn't be marked as stable in the 1'st place.

[Linuxhippy]

Hmm

The kernel was not even in RC state and you already cried out for a "2.6.35 desaster". No wonder the kernel guys reacted the way they did, and in fact Ingo Molnar summed the situation up quite good.

- Clemens

[M1AU]

In other words. Can Phoronix stop doing ridiculous claims the next time? You _will_ find performance regressions and bugs in 2.6.26-pre-rc1 if you search them, and in 2.6.27-pre-rc1, and in 2.6.28-pre-rc1. It's a good thing if you want to become a kernel tester, but they aren't interesting news.

I can't agree more.

[Rovanion]

FUD

This seems like another case just like the VIA article last week where Phoronix does it's best to spread FUD.

[Smorg]

Linus actually discourages people paying too much attention to his branch if you listen to his Git talk on youtube. Linus' branch shouldn't be considered somehow the most "official" one and therefore always bug free all the time. That's too much for one developer to handle.

[RealNC]

These sensationalist, self-advertising, paparazzi-style articles have backfired and are giving Phoronix a bad reputation among developers and informed users. Keep that up and no one will be paying attention to anything said here.

My two cents.

[RealNC]

Add "self-glorifying" to the list.

[kernelOfTruth]

this article already has come to first "fruition":

the evilness that is 2.6.35...

so STOP THE FUD please

IBM, Oracle, Intel, Red Hat and several other big players DO HAVE testing rigs - and that's for sure

after the regression wouldn't have been found until 2.6.35-rc2 you guys could have written the article but NOT in the transition phase