Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Linux Software

Operational Testing of Linux Kernel 2.5.x 191

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?"
This discussion has been archived. No new comments can be posted.

Operational Testing of Linux Kernel 2.5.x

Comments Filter:
  • 2.5 impressions (Score:5, Insightful)

    by yokem_55 ( 575428 ) on Monday March 31, 2003 @07:49PM (#5634554)
    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.
    • Re:2.5 impressions (Score:5, Informative)

      by SuperBanana ( 662181 ) on Monday March 31, 2003 @08:20PM (#5634720)
      I've been running the 2.5 kernel on my laptop for a couple of weeks now to get the new cpufreq support.

      This reminds me- one problem I've always had is that new stuff that gets thrown into the kernel isn't clearly explained- in the most basic ways. Ie, what the heck is it? I remember lots of versions of 2.4 had features and options with no help to explain what they did. Google searches don't always turn up anything handy- often they turn up lots of hits on patches or posts talking about the feature, but not describing what it actually is.

      Anyway, For those wondering what the heck cpufreq is...From a kerneltrap interview [kerneltrap.com]:

      JA: You also mentioned working on the x86 side of Russell King's cpufreq code. We spoke with Russell King in an earlier interview, but we didn't talk about cpufreq. What is it?

      Dave Jones: Quite a few CPUs these days allow changing of the voltage/multiplier/bus speed through software. Russell and Erik Mouw did a bunch of work on the ARM CPUs that support this feature, and started writing a generic framework for this type of technology so that he wouldn't have to duplicate code that for eg, recalculates loops_per_sec in every speed scaling.

      etc.

  • by Anonymous Coward on Monday March 31, 2003 @07:49PM (#5634557)
    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.
    • for 2.6 to hit the streets. Though the 2.4 scheduler sometimes has me crawling up the wall in frustration (e.g. compared to BSD), I don't want to go down the road of playing with development kernels on my production machines again. Been there a few years ago when I had to pursuade a recalcitrant framebuffer device to work. Hats off to the kernel development crowd and all, my sysprogging skills were not gained on *nix in the first place, and now I've jumped into other disciplines I would rather build on wha
  • by mindstrm ( 20013 ) on Monday March 31, 2003 @07:53PM (#5634580)
    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.

  • by miketang16 ( 585602 ) on Monday March 31, 2003 @07:53PM (#5634584) Journal
    I've tried compiling several different 2.5 versions, and yes they're very stable, when run in normal VGA mode... but I prefer the higher res FBdev mode. Unfortunately whenever I boot into a higher res, my screen either scrambles, or totally blacks out...
    • Try pulling down the XFree86 source and recompiling it against the 2.5 kernel headers. Seems to work fine on my dev box at home (Tyan Tiger MPX mobo, 2 x 1900+ Athlons)

      [dave@bend ~]# X -version

      XFree86 Version 4.3.0
      Release Date: 27 February 2003
      X Protocol Version 11, Revision 0, Release 6.6
      Build Operating System: Linux 2.5.61 i686 [ELF]
      Build Date: 04 March 2003

      At some point I'll rebuild X aginst the current (2.5.66 for the moment) dev kernel. Its hard enough keeping up with the various kernels so I only

      • I think he's talking about the console frame buffers - shouldn't really make a difference whether you have X or not. in fact I did what you said and I still had the same problems miketang has(with both vesa and rivafb drivers).
        • I always keep the console REALLY simple (e.g., you could put it up on a monochrome, 25x80 text monitor) so I didn't even think about console frame buffers. I think one of the reasons I ended up pulling down the X source and compiling it was that 4.1 whigged out against 2.5 at some point and I decided I may as well bring X up to current. That would have probably been about when X 4.2 came out so its a while ago. Once I got bit with the "keep current" bug, I went to X 4.3 when it was released.
          • I used to keep the console simple too except I've always had problems with this Dell Inspiron 4000 and display corruption when switching back and forth from console to X Windows. Recently I installed Slackware 9.0 and it uses the vesa fb by default (even for X!). I've been using it for a while and no display corruption at all. It works wonderfully and as a side benefit I get a nice big 1024x768 console fulling my LCD instead of some little odd looking 640x480 centered portion.

            I'm a convert to the fb world
        • Perhaps I'm not the only one, maybe I'll post this to the kernel developers. I was just afraid of bothering them with some bug that was due to my idiocy.
          • I don't think it could hurt - what's the worst that could happen? They ask you to check your kernel config and tell you if you made an "obvious" mistake. I would just make sure this bug is still valid. I haven't tried the frame buffer @ high res since 2.5.58. I'll try again in a day or so just for kicks.

            Is there a reason you are trying to get this to work? I like high res consoles too, but usually end up in X with two terms per desktop.
  • by Dr.Dubious DDQ ( 11968 ) on Monday March 31, 2003 @07:59PM (#5634618) Homepage

    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...

  • by Anonymous Coward on Monday March 31, 2003 @08:00PM (#5634625)
    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.
    • by iabervon ( 1971 ) on Monday March 31, 2003 @08:35PM (#5634789) Homepage Journal
      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.
    • by Anonymous Coward on Monday March 31, 2003 @08:37PM (#5634803)
      Don't sweat it. Many ppl here use MS windows and are plenty use to lots of downtime, crashes, and loss of data.
      • I am using a fresh install of Mandrake 9.1, I killed it not longer than 10 minutes ago

        I boot up the working system, try to install kvirc from the SuSE RPM, mentions need to satisfy dependency and install kvirc-something-or-other, I click yes. Never installs I never get another error.

        Go into KDE control panel, click around in the styles section, kde begins locking up. I start closing stuff. kicker is starting to lock up also. I try to run a terminal from quick launch and get an error to the effect of KDE ini

        • Yeah. Obviously, you did something that you knew was not going to work. Kind of like installing a bunch of NT4.0 dlls on an XP box and expecting nothing to go wrong. It is doable, but not really recommended as it will destabilize the system.
          Personally, though, I do think that sys admin is one of the major weakness of the distros (if not THE major one). Just as the distros made install easy, they should now work on making admin easy.
      • Not true! I had a co-worker once whose older brother's nephew went to school with this kid who was running Windows 98 and it had uptimes of DAYS!
        • Before my Linux days I had ran Win98 SE for 2 years straight without reformatting and no serious problems. It had it's fair share of lockups mostly from gaming. Even then uptime sometimes reached almost a month every once in awhile. But hell, it ran fast and I could laugh at my friends that had to reformat monthly. I think it had a lot to do with the hardware. It's a p3 500 with an Abit BE6. Yes one of those mobo's with the bad capacitors. Either I got a good batch or this thing is going to die any minute.
    • The idiots are the ones who moan about 2.5 being unstable without ever testing it themselves.

      It's not for joe 6-pack yet, leave that to the vendor release of 2.6 - but for those who know what they are doing, the 2.5 kernel is getting to be pretty useful for everyday work, and provides some improvements over the current stable kernel.

      I've been running 2.5.66-mm1 for 4 days now, and it's been surprisingly stable on a box that is doing 24x7 service -
    • OK, you read the beginning and the end of the summary. The part in the middle mentions "The project includes lots of testing and lots of escape hatches so we don't run recklessly off the edge." This is good planning--nothing really suprising since most smart companies do the same thing when they go through a major version change (or install a Service Pack in many cases.)

      However, your warning should be noted by anyone thinking of doing such a thing without properly assessing the risks and making the nec
    • No, no, no. It's fine if someone ELSE tests it under production! ;P

      -buf
    • Happy April the First.
  • 2.5 (Score:5, Interesting)

    by Spy Hunter ( 317220 ) on Monday March 31, 2003 @08:00PM (#5634627) Journal
    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.
    • Ironic.
      The first thing I noticed was that it MUCH faster and, oh... that there was no sound. Still isn't. Can't really get ALSA to work.
    • Re:2.5 (Score:3, Interesting)

      by glenebob ( 414078 )
      Yeah! Let's put the X server in kernel too while we're at it. NOT!

      It seems to me that media services should either become embedded in the X protocol, or standardized as a sister protocol. The problem lies in the failure to properly standardize the protocols. The actual mixing can still be done in hardware when possible, but the applications should have a very standard way of writing to the sound stream and that it shouldn't be done in kernel. I'd rather write to $DISPLAY:$SOUND_PORT than to /dev/dsp o
      • Re:2.5 (Score:3, Informative)

        by Spy Hunter ( 317220 )
        An audio mixer is hardly rocket science. It's actually a very simple thing. It just demands very low latency and very high efficiency, which the kernel can easily provide, while user-space servers have a little more trouble. There is a humongous difference between putting the X server in the kernel and putting an audio mixer in the kernel.

        Putting media services in the X protocol [mediaappli...server.net] would probably be a good idea, but it is orthogonal to a kernel mode audio mixer. Some programs will always want to access t

    • The new drivers for my card can suddenly mix 2 channels together in hardware

      Linux is just getting that feature???

      I know I'm going to sound like a troll, but I'm rather surprised Linux on the Desktop is that far behind -- Windows has been doing it for over 4 years.
      • Re:2.5 (Score:3, Informative)

        by Spy Hunter ( 317220 )
        No, the driver for my card is just getting that feature. In fact, the Windows driver doesn't even have it (but Windows has a kernel mode mixer so programs can still play sounds at the same time, the CPU does the mixing). Other Linux drivers have had it for some time, I understand. And I'm talking about 2 PCM streams here, as in two programs playing sounds at the same time. It has always been able to mix the microphone, line in, MIDI, CD, and other channels of course.
      • by Alan ( 347 )
        For his card. If you have a common card (ie: the sb live!) you have had this forever from what I remember, if you have some wacky card that no one has gotten around to writing drivers for (what I assume he has) then the *drivers* are behind.
      • Re:2.5 (Score:3, Informative)

        by PhoenixK7 ( 244984 )
        Most desktop apps at least support going through arts, esd or some other software mixer so while its kindof a crappy solution its not that much of an issue.

        I'm not sure about most of the cards available these days, but I do know that at least the SBLive (and the linux drivers, both alsa and the old oss ones) allows for hardware mixing of multiple channels (not sure how many but its way more than just 2).

        The ALSA drivers ARE of a much higher quality though. Has anyone else noticed that if you put the PCM v
        • Most desktop apps at least support going through arts, esd or some other software mixer so while its kindof a crappy solution its not that much of an issue.

          I tried playing TuxRacer with sound through one of those daemons. But I found that the sound would be delayed. It might have been less than one second of delay, but it was obviously far too much and was actually very confusing.
      • It depends on the card. My laptop has a four-way sound card which has worked on all fours with Linux since 2.2.14 or so. It means you can't generalize it at all. It doesn't mean 2.5 is always better than 2.4.

        Funnily enough, the card could be used with an Amiga style tracker [everything2.org].. except that modern trackers do the mixing in software so there's no need.

      • Windows has been doing it for over 4 years.

        Keep in mind that in spite of what people want you to think, most people who use Linux don't use a soundcard anyway. I have well over a half dozen boxes with Linux on them. One has a sound card. Most people STILL use Linux commercially, in a server environment. Mixing audio hasn't been as high on the list of things to do as say, iptables, journal file system, etc.

        The question is whether this should be done in the kernel (Linus), in X, or in hardware (emu10k
        • Keep in mind that in spite of what people want you to think, most people who use Linux don't use a soundcard anyway. I have well over a half dozen boxes with Linux on them. One has a sound card.

          That's one more with a sound card than I have. ;) I use Linux on a couple servers, I have no need for sound cards in those.
    • Re:2.5 (Score:3, Informative)

      by sydb ( 176695 )
      I don't understand. I run 2.4.20, standard Debian package. I am listening to the Ozric Tentacles with XMMS as I write. As I test I installed mpg321 and played an Eddie Izzard track from the command line at the same time. No problem., mixed seamlessly.

      Now, let's try more channels...

      Now, I've mixed Wagner, Ride of the Valkyries into that too. I'm kind of dizzy, but it all works.

      Maybe this is a feature of the EMU10k1 driver, or something, but it just works for me.

      Woooah my head is spinning! Stop!
      • The SBLive! has brilliant support for audio that way - entirely in hardware.
      • Re:2.5 (Score:3, Informative)

        by Spy Hunter ( 317220 )
        Apparently you've discovered that the EMU10k1 driver from the 2.4 series also has this ability. Some cards have the ability to mix up to 8 streams, I've heard. If you keep opening up more mpg123s eventually you will hit a wall. The mixing was new to me since my sound card driver (ESS something-or-other) didn't have this capability in 2.4. The new ALSA driver for my card in 2.5 does. Also it doesn't have the annoying bug where every time XMMS switched songs, it swapped the left and right channels :-) T
      • Re:2.5 (Score:3, Informative)

        by Doug Neal ( 195160 )
        The emu10k1 chip that the SB Live is built around can mix 32 channels together like that in hardware. the Linux driver provides support for that ability by letting you open /dev/dsp for output up to 32 times simeltaneously.

        Simple :)

    • by XO ( 250276 )
      I have noticed vast increases in desktop usability, and noticed the ability for several programs to access the sound device simultaneously. (I didn't even notice that 2.4 didn't do that, until after 2.5 started doing it.. lol )

      I've never really decided on a Window Manager/Desktop, so I've been playing with GNOME, KDE, and other older WM's and such.. I've noticed that KDE's sound server will cause any program that tries to directly access /dev/dsp to not play it's sound until after KDE is shutdown. I h
  • by Fnkmaster ( 89084 ) on Monday March 31, 2003 @08:02PM (#5634634)
    Yeah, it seems to run very well, the preemption patch is fabulous, new scheduler and whatever other magic made it into 2.5. Subjectively, X feels more responsive on my older hardware (okay, it's a PIII 650 but still a generation behind the times), which is running Mandrake 9.1 with KDE 3.1 now, on the 2.5.66 kernel.


    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.

  • by ahkbarr ( 259594 ) on Monday March 31, 2003 @08:04PM (#5634648)
    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.

  • 2.5.x (Score:4, Informative)

    by Dante ( 3418 ) on Monday March 31, 2003 @08:05PM (#5634652) Journal

    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

  • by Anonymous Coward on Monday March 31, 2003 @08:14PM (#5634697)
    "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."
    • Strangely enough, that's all happened in the last 40 releases of 2.5.

      It's been MORE stable with all these changes than it was BEFORE. :P
  • by Ho Kooshy Fly ( 561299 ) on Monday March 31, 2003 @08:15PM (#5634701)
    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
    • Bottom line: never upgrade kernels immediately on ANY production machine. (Never do it unless you absolutely have to, in fact.) Case in point: 2.4.18 through 2.4.20 released with bugs in ext3, notably the journal=data bug.
      • I have a machine running 2.4.20, that requires a physical power off about every 3-4 days.. haven't got a head anywhere near it to check it out, either.. too lazy to move on, since a power cycle just fixes it.. i guess that's the same reason people just run windows, eh?

        it never did that under 2.2.18 .. but 2.4.x is just not very stable on any of the hardware i've tried it on. i'll be loading my laptop with 2.5.x as soon as i figure out -how-...
        • ...running 2.4.20, that requires a physical power off about every 3-4 days..

          Really? maybe you should report that as a bug. My 4 machines haven't been rebooted since 2.4.20 came out except for 2 days ago when we had a freak lightning storm and I took everything off-line :-). I've found 2.4.20 to be completely rock-solid with no evident leaks.

          • Yeah, I really should get a monitor on it.. I did get one to it once, and it had OOPS!ed in the NFS server in the kernel.. I figure that's what it's probably doing.. but I hardly ever mount it's NFS share, so it hasn't bugged me too much
  • Question (Score:4, Interesting)

    by RedBear ( 207369 ) <redbear@nOSPam.redbearnet.com> on Monday March 31, 2003 @08:16PM (#5634702) Homepage
    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?
    • Answer (Score:4, Insightful)

      by BlowChunx ( 168122 ) on Monday March 31, 2003 @08:28PM (#5634753)
      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.
    • Wouldn't this end up being the 2.6.0pre releases? While it would be great to load up 2.5 to try out, I think it would be very difficult to determine a certain release as "stable enough" to give it a more stable rating than a previous or future version of the kernel. If you want to try out latest kernel, best thing to do is to setup a development box to test out the kernel (read: a system where if it gets completely trashed, you won't be losing critical/important data) --- next best is dual boot, but you *m
    • Re:Question (Score:1, Informative)

      by Anonymous Coward
      If you follow the mailing list (mandatory if you want to run a development kernel, of course) just stay a few versions behind. Download the latest 2.5, but don't install it. Read the list for a couple of weeks. If nobody mentions any show-stopping bugs in your version, you're probably safe to go ahead with the install, and you'll know what to expect from others' posts. DON'T post incessant questions to the list asking whether each new version is OK to run - just watching for bug reports gives you enough
    • What I did (Score:3, Informative)

      by DaveAtFraud ( 460127 )
      Regardless of whether you use lilo or grub, you can have the option of booting multiple kernels as long as you have room for them in /boot. When you install a new, development kernel, edit the appropriate boot loader configuration file to make sure you can still boot to a stable kernel (e.g., 2.4.X). I have only had a couple of instances where a new development kernel either wouldn't boot or was unstable once it did. I documented the bug, in a couple instances helped test the patch and could always drop
    • I used Debian Woody for 2.4 experimentation. Debian provides a system called kernel-package. You build the kernel into a package and install it. This doesn't remove your old kernel. You configure LILO (or whatever) to allow the operator to select the kernel version. Reboot. If things get hairy you just boot into the old kernel.
      • The parent post refers (in part) specifically to file system bugs. Just booting into a different kernel with the boot loader does nothing to protect your disk against corruption if the fs goes haywire.

        Something like user-mode-linux may be better suited than running an unstable kernel on live partitions... having your old kernel binary around is no solace if your new, experimental one just hosed your disk.

    • From what I understand, due to differences in the modutils package, dual booting the 2.5 kernels with the 2.4 kernels is a little harder than in the past.

      I would recommend checking out the UML kernels which are released a few days after the main releases. You can run the new kernel inside a stable environment with it own root. See if it works with your workload. If its stable there you might trust it enough to boot into it.
      • An easy work around for the new modutils package is to just make sure that everything your system has to have in order to boot up and run is built into the development kernel you're playing with. That is, not a module. That way, you can leave modutils alone, let the development kernel boot and then modprobe any "optional" modules in after the system has booted. Examples of optional stuff would be things like sound, "other" file systems, etc.

        Come to think of it... if some functionality is required to boo
    • Re:Question (Score:2, Informative)

      by oxfletch ( 108699 )
      I actually *do* try to do that in the -mjb tree already ... I collect bug fixes, performance improvements, and diagnostics tools (so if it does break, you can find what went wrong).

      Staying one kernel release back will help you too ... ie we're on 2.5.66 now, so run 2.5.65-mjb2 (the latest 65 version). And don't turn on preempt (it's broken in my tree by something I did).

      The interactivity tweaks are against the O(1) scheduler, so won't do you much good in 2.4 .. unless you run 2.4-aa or something.

      If you'r
  • I've been running 2.5.xx on my home server since xx was >30ish. not really by choice either. 2.4.xx (for all xx) is grossly unstable for my combination of hardware. I got ide irq timeouts which brings the machine crashing down often before it had finished booting. It would run in uniprocessor mode but what's the point of that!!!

    I have one problem with hostap (wireless access point drivers) and my sound card sharing an interrupt which causes a crash occasionally, but if i don't load the sounds drivers it
  • Are there any improvements for Linux native games like Quake series, Return to Castle Wolfenstein, etc.?
  • by Pegasus ( 13291 ) on Monday March 31, 2003 @08:46PM (#5634841) Homepage
    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 have a lot of expectations of the Alan/Andre team with their ide work ... 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...
    • by Nicopa ( 87617 ) <nico@lichtmaier.gmail@com> on Monday March 31, 2003 @10:42PM (#5635450)
      Your expectations were wrong. The new Linux won't make things faster, it will just (as you put it) make things feel different for interactive processes. The idea is to be able to work without one second pauses when a background process is performing some heavy task.
      • I too am seeing *MAJOR* slowdowns in performance when using 2.5.66 or anything after 2.5.64-mm1 (.64-mm1 is hands-down the most responsive out of any 2.5.xx kernel series to date).

        Since -mm1, the rest have gotten more and more and more sluggish. Now with 2.5.66-mm1, it takes rougly 3-4 seconds for an xterm to open with a ctrl-alt-b keystroke in sawfish. With 2.5.64-mm1, it's instantaneous. 2.5.66-mm1 (or alan's patch or straight 2.5.66) also seems to "miss" my keyboard shortcuts to launch applications, lik

  • Not really daring (Score:3, Insightful)

    by ChaoticCoyote ( 195677 ) on Monday March 31, 2003 @08:51PM (#5634860) Homepage

    I've been running the 2.5 kernels since about 2.5.30 -- on my primary workstation, no less. In other words, my livelihood is depending on a development kernel.

    It works. For me, I've had almost no trouble, save for some difficulties with the radeonfb driver not liking my DFP when it's attached to the DVI. Overall, though, performance is excellent -- though I do keep studious backups in case soemthing "goes wrong."

    2.5 is really a solid pice of work. Yes, it had bugs; follow the kernel mailing list, watch what people say, read the patch lists, and skip releases that seem a bit flakey.

  • Mixed results (Score:5, Informative)

    by be-fan ( 61476 ) on Monday March 31, 2003 @09:24PM (#5635034)
    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...

    • did you report these kernel bugs in the linux-kernel mailing list? I bet someone is interested, especially for features that worked fine in Linux 2.4.
  • One of the nice things about Linux (or other free unices out there) is that it is soo easy to try out different kernels. You can try the devel code, if it doesn't work out for you you can easily go back to the last known good.

    For the more conservative, just stick with the productized Linux disto's.
  • You've got to stay away from odd numbers, remember all the problems with everybody's 3.0 4.0 7.0 8.0 releases?

    Oh no, those were the even numbers.......
  • I thought the same thing a week or 2 ago or so, and mainly wanted to test some features to adjust some programs before 2.5.(99) became mainstream.

    I tested on two P3 machines (Katmai and Coppermine) with funny results.

    1. Coppermine: booted, but due to the fact that I forgot to install module-init-tools, I lost contact with the machine. It hasn't been seen since :P
    After installing the tools, the machine seemed to boot, but no tty1 was spawned and seemingly resulting in messy fscks (proof is in my lastlog)

    2
    • 2. Katmai: I installed the module-init-tools and the machine decompressed the kernel, ... and then halted.

      Check your config and make sure you've enabled the console. For some bizarre reason, this isn't the out-of-the-box default.

Anyone can make an omelet with eggs. The trick is to make one with none.

Working...