The Huge Disaster Within The Linux 2.6.35 Kernel

[V!NCENT]

Jesus guys... WTF!

A single kernel commit causing a 50% performance drop IS a disaster!

Do you call your CNN everytime they interview Obama and tell them to aid with the booming or STFU when oil spills hit the shore?

This is news and be glad Michael MADE the fscking tools to discover it!

I am very happy on being kept up to date with development news. If you want to catch the individual stable releases with explenations for the crack stupid I suggest you go to Digg.com for your latest Ubuntu release info.

If there is either no news or a mini studie/article to help Linux lernel devs than I gladly welcome that.

I hope that the Steam Linux client is soon released, because that would cut away the complaining about Phoronix on the forums so I can read the interesting comments of people who do know their shit so I can learn something new.

Jesus...

[MisterIO]

Thing is, bugs like this shouldn't be allowed to enter into the main repository. Again, proper practices and test procedures...

I agree. Usually the code that gets merged at this stage has lived for some time before in linux-next. This kind of huge regression basically tells us that nobody tests what lands into linux-next. The fact that it stayed there for a week is even stranger. Nobody tested the code for a whole week? I mean, the problem is so spread that it's difficult to think that the tests that have been run didn't report anything strange.

[DeepDayze]

I am not criticizing Michael for posting this article, as its indeed informative and I do hope he submits his info to LKML so that the devs will be aware and this bug(s) get fixed

Why not pull a snapshot and TEST it, guys? Will only help the devs if we test and report anything bad or broken

[mtippett]

well if you'd done just a little bit more research you'd found the lkml thread mentioned in this forum thread before and you'd seen that it might not even be a kernel bug but an udev bug...

the more spectacular news an article brings, the more effect you'll have to put in to make sure that you've got your facts straight.

you're kind of falling flat-out on your face right now. and you're pissing of lots of kernel people. not very wise

Guys, when you inject a change on a system and you cause a regression it simply doesn't matter who needs to make an ultimate fix. Before you inject the change, you make sure the system will work properly. If the change went in with "This causes a performance regression unless you are using udev xx.yy" then the due diligence has been done. Anything less is to some extent irresponsible.

[kraftman]

WTF!

There's no spoon and there's no 2.6.35, so Phoronix, few 'smart' people talking about development, WTF?

[deanjo]

Some points to consider.

1) The kernel team generally does not have the tools to monitor regressions on a regular cadence. The kernel has been in development for the last 18 years.

That is so sad and scary at the same time. With all the major corporations and individual that are involved with the kernel development you would think that at least one of them would have donated use of a few boxes for automatic regression testing. It's not rocket science to setup such a regression testing facility. I bet pretty much every devel out there has an older box that they no longer use that could be used for such testing, not to mention the corporations that have tones of nil load hardware out there just burning power sitting idle.

Does nobody else see a major flaw in this lack of capability? With the kernel getting larger and larger and more complex you would think that someone, somewhere that is involved would have said "Hey let's set something up to be proactive watching for regressions!" instead of relying solely on user feedback and the efforts of one enthusiast site.

[V!NCENT]

There's no spoon and there's no 2.6.35, so Phoronix, few 'smart' people talking about development, WTF?

r600g wasn't merged to mesa. So scrapt these articles then?
Bridgman and others do not add very interesting info on not released drivers?

What else does not matter at all? All I see is nin pages full of "why did you report a development bug?"

Can I have my WTF back now? I might need it in the future where you might comment on Mesa, KDE and Gnome development.

[mtippett]

That is so sad and scary at the same time. With all the major corporations and individual that are involved with the kernel development you would think that at least one of them would have donated use of a few boxes for automatic regression testing. It's not rocket science to setup such a regression testing facility. I bet pretty much every devel out there has an older box that they no longer use that could be used for such testing, not to mention the corporations that have tones of nil load hardware out there just burning power sitting idle.

Yes, it's really scary. Unfortunately, the concept of proactive regression management is lightly understood through the industry.

Does nobody else see a major flaw in this lack of capability? With the kernel getting larger and larger and more complex you would think that someone, somewhere that is involved would have said "Hey let's set something up to be proactive watching for regressions!" instead of relying solely on user feedback and the efforts of one enthusiast site.

Well that's why Michael and I created Phoromatic and PTS.

If there are kernel developers interested and motivated enough to work with us to tune the testing and the systems, we can push the kernel tracker way further than it is at the moment.

[deanjo]

Yes, it's really scary. Unfortunately, the concept of proactive regression management is lightly understood through the industry.

The fact that it is lightly understood is very disturbing. Pretty much every development project that I have worked with however has had a regression tracking setup so I'm not sure if it's so much "the industry" or more just the case in a open development model.

Well that's why Michael and I created Phoromatic and PTS.

And some of us appreciate that. It seems however, at least judging from a lot of the comments in this thread, if something bad is mentioned against the "church" all of a sudden you become public enemy #1 in their eyes.

If there are kernel developers interested and motivated enough to work with us to tune the testing and the systems, we can push the kernel tracker way further than it is at the moment.

Have you guys approached the larger projects out there in setting up any facility like this? It seems to me if intel/amd can donate hardware for build services, ftp mirrors, etc for distro's they surely can offer some boxes to setup such a facility for the kernel devs to use.

[mtippett]

The fact that it is lightly understood is very disturbing. Pretty much every development project that I have worked with however has had a regression tracking setup so I'm not sure if it's so much "the industry" or more just the case in a open development model.

I have lots of personal thoughts on this, I won't go into it here.

It depends on what people term as regression tracking. I have seen a lot of incantations from we test now and then to we have a tool. Regression management in my mind has the following aspects.

o A way of detecting the regression
o A way determining the regression cause (down to the code change)





And some of us appreciate that. It seems however, at least judging from a lot of the comments in this thread, if something bad is mentioned against the "church" all of a sudden you become public enemy #1 in their eyes.



Have you guys approached the larger projects out there in setting up any facility like this? It seems to me if intel/amd can donate hardware for build services, ftp mirrors, etc for distro's they surely can offer some boxes to setup such a facility for the kernel devs to use.[/QUOTE]