Slashdot Mirror
Operational Testing of Linux Kernel 2.5.x
G3ckoG33k writes "The Open Source Development's Lab has begun operational testing of the 2.5.x Kernel: "The staff at OSDL has been involved with development and testing of 2.5 since the beginning and we've noticed that it seems to be very stable for a development tree. So good, in fact, that we think it is ready to be tested in a production environment. We have planned and begun execution of a project to test the 2.5 kernel in our data center using our production environment. The project includes lots of testing and lots of escape hatches so we don't run recklessly off the edge. We began with some of the simpler, less critical servers and, as we build confidence, are moving to the more complex servers. Today we have several servers running 2.5 and within a month we'll have most of the data center migrated to 2.5." Can anyone say Dare Devils?"
I've been running the 2.5 kernel on my laptop for a couple of weeks now to get the new cpufreq support. It seems to work really pretty well. Getting pcmcia-cs to build took some work, but I finally got it up and running and the performance of this new kernel is really nice, especially for the desktop.
...and IN SOVIET RUSSIA, beowulf clusters imagine 1, 2, 3 profit!!!! jokes made out of YOU!!!
I've been trying out 2.5 for quite a while now with varying degrees of sucess.
It would be great to hear from more people like OSDL that it's working well.
Unfortunately, unless RH9 comes with module-init-tools, it will still be a pain to try out the 2.5 kernel.
The reason it's not for production use isn't because it is necessarily crash prone... it's because it can break drastically between minor versions as features are added/changed.
I've been playing with the 2.5 series off and on mainly for the USB Storage support (devices that don't seem to work in 2.4 seem to work fine in 2.5 - at least the two or three that I've tried.) For the longest time, there was always ONE of the features that I really wanted that wouldn't compile or work, either the USB, or Video 4 Linux, or something else...
I came back and tried it again at 2.5.63. That was the first version what compiled and ran everything I used perfectly. .64 and .65 seem to have had a timing glitch that messed up my scheduled recordings (by mencoder via V4L), but that seems to be fixed again in 2.5.66, which has been working beautifully for me so far.
I honestly expect to see "2.6.0preXX" versions start appearing in the relatively near future...
Hacker Public Radio is our Friend
There's a reason people don't use 2.5. It's the DEVELOPMENT kernel. You SHOULD NOT be using it for production use. Often things will break. Sometimes it will cause hard disk corruption. It wouldn't be the first time.
Please, fellow slashdotters, don't be tempted to use 2.5 for your important systems. It's good that it's tested more, but if you do use it, please don't bitch and whine about how it destroyed all your data.
I have also been using 2.5 on my desktop. I got it at first to test out the supposed desktop performance improvements, but I haven't really noticed any improvement. What I have noticed is the increase in quality of the sound drivers. The new drivers for my card can suddenly mix 2 channels together in hardware, allowing me to run XMMS or mplayer and still hear my Gaim sounds in the background or visit a Flash site, without running a retarded sound server, or having programs choke and die because they can't open /dev/dsp. If only ALSA would implement a kernel-mode audio mixer so everyone could have as many channels mixed together as they wanted. We could get rid of this rediculous proliferation of bloated, incompatible "media servers" that use complicated IPC schemes to achieve basically the same result less efficiently. Here's hoping.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
This is however still a DEVELOPMENT kernel. I put that in big letters because it's very, very true. Lots of kernel modules won't compile still. Documentation for what has changed is somewhat spotty, and it took me some time to get everything working decently. And getting a system that can boot into 2.4 or 2.5 seems quite difficult with the new modutils package (or at least I haven't gotten it working yet - have to reinstall modutils RPM if I want to boot into 2.4).
Also there's a major bug with ext3 right now in 2.5.66 - if your computer doesn't shut down cleanly, the journal recovery in 2.5 seems completely broken - I have to reboot into 2.4, let the 2.4 kernel do the journal recover, do a clean shutdown, and THEN boot back into 2.5. Pain in the ass, especially since I've had two hard crashes since I upgraded to 2.5. Also 2.5.66 doesn't compile out of the box with default config. Had to patch one file with a patch from LKML.
So in short, 2.5 may be more stable than usual devel branches, but don't delude yourself about what you are getting into. If you want the latest and greatest in performance for your desktop machine, give it a try. But I wouldn't run even a low uptime-requirement server with it yet.
These are folks who don't include every driver and feature available. They probably won't be running preempt, which has been at times problematic. You can get a very stable 2.5 series kernel by being prudent.
All in all, my experience at running 2.5 has been positive, and my only problems have really been with features not likely to be used by folks running special purpose servers.
Compared to war, all other forms of human endeavor shrink to insignificance. God, how I love it. - Gen. George Patton
I've been running 2.5.x on both my station at work and at home. For the most part it's been pretty stable.
I've run 1.3, 2.1, 2.3 and now 2.5 kernels as they came out and 2.5.5x and on have been a pleasure. I had a 2.1.x kernel eat my file system, I've had nothing like that so far.
Now the caveat: don't run a 2.5.x kernel unless your willing to lose everything, backup regularly! and most important because I don't think anything bad will happen, be prepared to write bug reports correctly! READ THIS AFTER DOWNLOAD! linux-2.5.x/Documentation/BUG-HUNTING
"think of it as evolution in action"
"we've noticed that it seems to be very stable for a development tree."
And, in other news, Kernel developers worldwide learned that the development tree was too stable and announced sweeping changes to the VM, IDE, and Scheduler modules.
Said one developer, "it's not bleeding edge unless someone is bleeding. It pains me to think that we've actually got this thing stabilized with an odd-number dev version. We normally don't go for that until we go to the even-number release versions, usually at a x.y.5 or x.y.6 release."
Having gone through high cpu/disk load crashes over multiple kernels, I would suggest a good test plan before embarking on any new kernel.
Our most recent experience with 'stable' kernels (specifically drivers in our case) was the default kernel in RH 8. It had some very subtle issues with Intel's GigPHY/MAC chipset that caused crashes only under specific high load every three to four days. Crashes were not repeatable in specific time frames but would eventually happen. I suggest finding a characteristic set of applications/loading of disk/mem/CPU applications and then test out your favorite kernel under all those circumstances. Many programs that run huge FFTs or other number crunching applications are many times too specific to cause failures. We in this example used a program to calculate huge FFTs while doing looping network file transfers to test without issues... nothing beats the real thing!
Also don't think that even 2.4.x series kernels are above this... as I stated earlier even a heavily patched 2.4.18 kernel could be your downfall... so maybe a 2.5.x kernel is okay but beat the crap out of it before putting both feet in.
-Ho
There are those of us who like to mess with our Linux systems but aren't exactly experts and probably never will be. Some of us would really like to dabble a bit with the new 2.5 kernel on our personal systems, but we'd rather not hose our system in the process. Is there anyplace out there where someone periodically puts together a "semi-stable" version of the development kernel, that us dabblers can download and be reasonably sure that it will be free of such things as major filesystem bugs?
Everyone says, don't run the development kernel if you don't know what you're doing, and of course any particular 2.5 kernel grabbed off of kernel.org can be majorly broken, right? So it would be really cool if one of the real kernel developers could put together something inbetween the 2.4 "stable" kernel and the 2.5 "careful!" kernel. There are just so many cool new features in 2.5, like that huge improvement in interactivity that could really make the desktop more usable, but those of us who aren't experts are really leery to just grab the source and start compiling, because who knows what might be broken in any particular development sub-version.
Does anyone make a habit of doing this "semi-stable" thing with the development kernels? Failing that, are cool things like that interactivity improvement being backported to the 2.4 kernel already?
one can compile and load nvidia binary module, though one needs to apply some patches
i am using 2.5.66/2.4.20 alternatively while using nvidia binaries
2.5 works prety well though small changes fool some user space programs
for example since the name extension of modules are different i had to hack my debian debconf script to work properly
also gkrellm memory monitor doesn't work (free works though)
vmware.
If it hoses your virtual machine, you are out nothing. If you aren't up for the kernel screwing up your*real* machine and having to reinstall everything, leave it alone.
2.4.xx is perfectly fine. You really aren't missing anything. You'll get it soon enough, without the pain. Besides, anticipation makes you appreciate it more.
You should only use a development kernel in a production environment if you've already tested it extensively and found it to have no problems with your particular load on your particular hardware with the options you're using. Of course, if you're OSDL, you can actually do this sort of testing, but practically everyone else doesn't have the spare hardware and test suites necessary.
Don't sweat it. Many ppl here use MS windows and are plenty use to lots of downtime, crashes, and loss of data.
I'm running 2.5.65-mm4 on my home box because i wanted to find out whats all the excitement and nice numbers about the new scheduler. After i got all the modules right, i did some tests ... and was a bit dissapointed. You see, it's not all that faster ... it just feels different. Yes, programs do load somewhat faster, but at the same time doing a ls -l in my home dir was kinda slower that with excellent WOLK patchset for 2.4.18. On the other side, i was completely able to browse my large inbox (~20k mails in maildir) while checking md5 of the latest knoppix iso on the same disk.
... i just can't wait to test the 'fixed up' promise driver and ide tcq code! Right now ide tcq on promise is somewhat borken. If ide tcq shows some numbers, that would be the last argument down for scsi vs. ide in our servers...
I have a lot of expectations of the Alan/Andre team with their ide work
Interactive performance - Pretty sharp. I/O background load really doesn't put much of a burden on foreground stuff, but then, 2.4 + preempt patches didn't either. Resizing is weird. Resize slowly, and the effect is like kernel 2.4 (canvas lags behind window frame). Resize fast, and the effect is like OS X, the window frame lags while the canvas catches up. Both kinda suck. CPU background load (MP3 compression) causes the machine to feel like an XP machine -- big 10-15 pauses.
CD drivers - They suck. Certain CDs (Evanescence's Fallen) will cause the CD drive to go into spasms. This doesn't happen under 2.4.
I/O scheduler - Gimpy. Under heavy CPU load (the aformentioned MP3 compression) starting an app that isn't in cache will take tens of seconds.
Compile performance - awesome. I use Gentoo, and I've noticed big improvements.
Power management - Mediocre. APM is alright. ACPI sucks. Causes weird beeping noises when I try to load the "processor" module. It's probably a fault of my Inspiron 8200's fsck'ed DSDT, so I won't bitch, but WinXP has no problem with it.
Stability - Surprisingly good, for development code. A far cry from 2.4, crashes maybe once a week, but much better than the 2.5.20-something releases, which once hosed my entire partition when I burned a bad CD...
A deep unwavering belief is a sure sign you're missing something...