From: Nix <nix@esperi.org.uk>
To: Martin Steigerwald <Martin@lichtvoll.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: stable? quality assurance?
Date: Mon, 12 Jul 2010 20:46:01 +0100 [thread overview]
Message-ID: <87mxtwtreu.fsf@spindle.srvr.nix> (raw)
In-Reply-To: <201007110918.42120.Martin@lichtvoll.de> (Martin Steigerwald's message of "11 Jul 2010 08:18:55 +0100")
On 11 Jul 2010, Martin Steigerwald said:
> 2.6.34 was a desaster for me: bug #15969 - patch was availble before
> 2.6.34 already, bug #15788, also reported with 2.6.34-rc2 already, as well
> as most important two complete lockups - well maybe just X.org and radeon
> KMS, I didn't start my second laptop to SSH into the locked up one - on my
> ThinkPad T42. I fixed the first one with the patch, but after the lockups I
> just downgraded to 2.6.33 again.
[...]
> hang on hibernation with kernel 2.6.34.1 and TuxOnIce 3.1.1.1
>
> on this mailing list just a moment ago. But then 2.6.33 did hang with
> TuxOnIce which apparently (!) wasn't a TuxOnIce problem either, since
> 2.6.34 did not hang with it anymore which was a reason for me to try
> 2.6.34 earlier.
To introduce yet more anecdata into this thread, I too had problems with
TuxOnIce-driven suspend/resume from just post-2.6.32 to just pre-2.6.34.
The solution was, surprise surprise, to *raise a bug report*, whereupon
in short order I had a workaround. In 2.6.34, the problem vanished as
mysteriously as it appeared, as did the bug whereby X coredumped and the
screen stayed dark forever upon quitting X. 2.6.34 and 2.6.34.1 have
worked better for me than any kernel I've used since 2.6.30, with no
bugs noticeable on any of my machines (that's a first since 2.6.26).
I speculate that there may be some subtle piece of overwriting inside
the Radeon KMS and/or DRM code, which is obscure enough that it is
relatively easily perturbed by changes elsewhere in the kernel.
But nonetheless, one cannot extrapolate from a single bug in a subsystem
as complex as DRM/KMS to the quality of the entire kernel. This is
doubly true given the degree of difference between different cards
labelled as Radeons: I'd venture to state that most of the Radeon bugs
I've seen flow past over the last year or so only affect a small subset
of cards: but if you add them all up, it's likely that most users have
been bitten by at least one. But the problem here is not the kernel
developers, nor the kernel quality: it's that ATI Radeons are a
horrifically complicated and tangled web of slightly variable hardware.
(In this they are no different from any other modern graphics card.)
Martin, might I suggest considering stable kernels 'experimental' until
at least .1 is out? Before Linus releases a kernel, its only users are
dedicated masochists and developers: after the release, piles of regular
early adopters pour in, and heaps of bug reports head to lkml and fixes
head to -stable. The .1 kernels, with fixes for some of those, are the
first you can really call *stable*, as they've got fixes for bugs
isolated after testing by a much larger userbase of suckers.
-- N., dedicated sucker and masochist
next prev parent reply other threads:[~2010-07-12 20:25 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-11 7:18 stable? quality assurance? Martin Steigerwald
2010-07-11 8:39 ` Eric Dumazet
2010-07-11 14:22 ` Martin Steigerwald
2010-07-11 14:52 ` Martin Steigerwald
2010-07-11 15:58 ` William Pitcock
2010-07-11 16:34 ` Eric Dumazet
2010-07-16 6:59 ` Greg KH
2010-08-05 3:27 ` Jeremy Fitzhardinge
2010-07-11 17:04 ` Heinz Diehl
2010-07-11 13:16 ` Ted Ts'o
2010-07-11 18:02 ` Anca Emanuel
2010-07-12 6:46 ` David Newall
[not found] ` <AANLkTilGjfx9sb66qVfZn1SeFPURHUrrdE7JCrild8VX@mail.gmail.com>
2010-07-12 12:35 ` Fwd: " Marcin Letyns
2010-07-12 12:42 ` Alexey Dobriyan
[not found] ` <AANLkTik64lxDiCN-eRo3i_-cTqAvCzbaRI4EEXoD44Vj@mail.gmail.com>
2010-07-12 12:52 ` Fwd: " Marcin Letyns
2010-07-12 14:57 ` Valdis.Kletnieks
2010-07-12 15:56 ` David Newall
2010-07-12 17:48 ` Marcin Letyns
2010-07-12 18:00 ` Stefan Richter
2010-07-12 19:58 ` David Newall
2010-07-12 21:11 ` Stefan Richter
2010-07-12 21:39 ` Martin Steigerwald
2010-07-12 22:44 ` Stefan Richter
2010-07-15 7:23 ` david
2010-07-13 16:50 ` Theodore Tso
2010-07-13 20:45 ` David Newall
2010-07-14 6:33 ` Theodore Tso
2010-09-04 17:12 ` Martin Steigerwald
2010-07-11 13:56 ` Lee Mathers
2010-07-11 14:51 ` Martin Steigerwald
2010-07-11 17:22 ` Willy Tarreau
2010-07-11 21:38 ` Rafael J. Wysocki
2010-07-12 4:17 ` Willy Tarreau
2010-07-12 9:56 ` Martin Steigerwald
2010-07-12 15:43 ` Martin Steigerwald
2010-07-12 17:36 ` Willy Tarreau
2010-07-12 19:56 ` Martin Steigerwald
2010-07-12 23:03 ` Stefan Richter
2010-07-13 10:30 ` Martin Steigerwald
2010-07-15 7:32 ` david
2010-07-12 17:55 ` Stefan Richter
2010-09-04 16:38 ` Martin Steigerwald
2010-09-04 18:46 ` Ted Ts'o
2010-09-04 19:11 ` Martin Steigerwald
2010-09-04 23:23 ` Ted Ts'o
2010-09-05 7:59 ` Martin Steigerwald
2010-09-04 19:24 ` Stefan Richter
2010-09-04 19:34 ` Stefan Richter
2010-09-04 20:21 ` Martin Steigerwald
2010-09-04 22:50 ` Stefan Richter
2010-09-04 23:16 ` Ted Ts'o
2010-09-05 8:35 ` Avi Kivity
2010-09-05 9:48 ` Martin Steigerwald
2010-07-11 19:49 ` Stefan Richter
2010-07-13 11:11 ` Alejandro Riveira Fernández
2010-07-13 12:50 ` rt2x00: slow wifi with correct basic rate bitmap (was Re: stable? quality assurance?) Stefan Richter
2010-07-13 15:35 ` John W. Linville
2010-07-13 18:19 ` Alejandro Riveira Fernández
2010-07-13 18:38 ` John W. Linville
2010-07-13 19:07 ` Alejandro Riveira Fernández
2010-07-13 18:06 ` Alejandro Riveira Fernández
2010-07-13 19:18 ` Stefan Richter
2010-07-12 19:46 ` Nix [this message]
[not found] ` <AANLkTimEdVsmIgXBbmhsq75ElQvGAI8avsM8-wlDpm4z@mail.gmail.com>
2010-07-15 9:09 ` stable? quality assurance? Valeo de Vries
2010-07-16 7:00 ` Greg KH
2010-07-16 7:19 ` Justin P. Mattock
2010-07-16 15:25 ` Randy Dunlap
2010-07-16 15:34 ` Valeo de Vries
-- strict thread matches above, loose matches on Subject: below --
2010-09-04 16:42 Martin Steigerwald
2010-09-04 17:22 ` Willy Tarreau
2010-09-04 19:33 ` Martin Steigerwald
2010-09-04 20:19 ` Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mxtwtreu.fsf@spindle.srvr.nix \
--to=nix@esperi.org.uk \
--cc=Martin@lichtvoll.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox