A good Linux kernel vintage?

[sara fink]

try 2.6.38. Works pretty fine on 2 machines and no problems with the sound
and hd load.

You can always select from which kernel to boot. In the worst case, you
will return back to the old version

On Thu, Nov 17, 2011 at 1:19 PM, Eli Billauer <eli at billauer.co.il> wrote:

> Nadav Har'El wrote:
>
> Well, basically, all released kernels fit your description. It's not
>> like Linus, and a few hundreds of the kernel developers, are going to
>> release a version, after a few weeks of intensive testing, which doesn't
>> "work". You could be sure that all of them "love multitasking", and
>> (of course) "compile a kernel", and also "check their mail" and "watch
>> youtube videos". So for all this, *all* kernel versions should be fine.
>>
>>
> That should be true in theory. And since Oleg asked about my own
> experience, I'll explain myself a bit.
>
> I started off with the distribution kernel just like anyone else, but
> upgraded to vanilla 2.6.35.4 to solve some driver issues (this is where
> normal people upgrade their entire distro, I know). At this point I
> discovered the disk freeze issue. And yes, I tried every scheduler
> available. This was a bug, which was fixed after it had been *known* for
> several kernel versions (2.6.32 to 2.6.35, IIRC). It's a known secret, that
> a reported bug can survive for quite a while in the kernel, because nobody
> takes the initiative to fix it. This was the case.
>
> I summarized the disk freeze issue in my blog:
> http://billauer.co.il/blog/?p=**759 <http://billauer.co.il/blog/?p=759>
>
> But hey, since the bug was fixed on 2.6.36, I happily jumped on that
> kernel version. When booting, I couldn't login to my computer. As it turned
> out, it was a new kernel bug, which locked up all TTY devices, including
> the login/password entry. The thread I started in LKML about this can be
> seen at https://lkml.org/lkml/2010/10/**30/16<https://lkml.org/lkml/2010/10/30/16>
>
> As the discussion in the thread reveals, the problem was that the Big
> Kernel Lock had been removed from the TTY drivers, and replaced with an
> all-TTY lock. Unfortunately, the new lock was held during 30-second sleeps,
> which the maintainer didn't consider when making the lock reorganization.
> So anything related to TTY devices, including logins, was frozen for long
> periods of time.
>
> So what should I do now? I could upgrade to the latest kernel again. I
> could also patch the existing one, which has been running smooth for a
> year, except for a couple of issues.
>
> So how can you tell a kernel which doesn't have this kind of bugs? My
> thought was, that since both the complaints and their solution appear in
> LKML, someone who follows this mailing list tightly would know, in
> retrospective, which kernel had major issues, and which one didn't. So I
> hoped someone on this list could just name a kernel version and say "this
> one went through with nothing dramatic".
>
> Since that didn't happen, I'll patch my kernel for the disk bug, try to
> upgrade the ALSA drivers specifically, and hopefully not break something on
> the way.
>
> Thanks all for trying.
>
>  Eli
>
> --
> Web: http://www.billauer.co.il
>
>
>  ______________________________**_________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/**mailman/listinfo/linux-il<http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20111117/b974538e/attachment.html>