[ltp] Linux kernel instability? (Rant/Panic/Cry-for-help!)

Sebastian Geiger linux-thinkpad@linux-thinkpad.org
Mon, 29 Sep 2008 09:51:06 +0200


This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEEB676D9F7375B3313AAF0ED
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dear Henrique,

as for my part, I have an X61 with only parts for which opensource
drivers exists, e.g. the i965 graphics chipset and centrino hardware.
Thus I have not installed any binary blob in to the kernel, I have
currently two kernels installed, the 2.6.25-1 and the 2.6.26 (both are
tuxonice-sources on gentoo) if i boot the later one, suspend ceases worki=
ng.

Best Regards
Sebastian

Henrique de Moraes Holschuh wrote:
> If you guys want any of us people closer to the kernel to even particip=
ate
> on threads as this, there is an EXTREMELY important information you mus=
t
> give:  whether you are using any binary blobs.  Also which kernel, but =
most
> of you provide that information already.
>
> Really, because if you use nVidia drivers (hello T61 users), fglrx (hel=
lo
> most 3d-using ThinkPad users), madwifi (hello IBM wireless adapter user=
s)...
> your experiences will only be valid for people using the very *same* ve=
rsion
> of the binary blob and mainline kernel: these drivers often do NOT play=
 nice
> with mainline, and they DO regress when you upgrade mainline (or just t=
he
> driver).
>
> My T43 has been extremely stable, but I play it safe:
>
> I don't use Ubuntu's patched kernel (I'd use either Fedora's or SuSE's,=
 they
> DO have a team large enough to take care of it.  Ubuntu doesn't).  I so=
rt of
> trust Debian's kernel because it is *really* close to mainline, often i=
t has
> fixes for weird arches (doesn't matter for a x86 build) and minor backp=
orts
> of stuff that has been accepted upstream but is not in stable mainline =
yet.
> The only heavy weight patching I do is tp_smapi, plus whatever crap I a=
m
> working on (currently rfkill and thinkpad-acpi).
>
> I don't use bleeding edge kernels except for fast testing (laptop produ=
ction
> is currently at latest 2.6.25 + a few selected patches.  Server product=
ion
> is at 2.6.16.y), and take note that I *am* a kernel driver developer.  =
I
> don't use ANY binary blobs at all, EVER.  I don't use the latest
> fuck-the-box-to-get-some-useless-eyecandy crap from KDE or Gnome, that =
is
> likely to touch something fragile in X.org.  I don't enable known-unsta=
ble
> or still immature stuff in the kernel (PAT, group scheduling,
> virtualization, containers, etc).
>
> And I never do hibernation, just suspend-to-RAM (VERY often, so I am 10=
0%
> sure it is working perfectly, even if it were a crash in 1000, I'd hit =
it
> within a week).  No undervolting or screwing up with the clock, either.=

>
> This doesn't mean the quality of mainline's core is not changing for th=
e
> worst, it really might be.  But it DOES mean that there is such a thing=
 as
> "playing it safer"...
>
>  =20


--------------enigEEB676D9F7375B3313AAF0ED
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJI4IjuAAoJEC3c23gFjIjfM40QAIbBTRxJDPPtedCjb3VGkI3D
mGJDpoALHbsWcD1c8wCgIbbc9OACLhXwPy0yazYDP2NJtFkd1VCkPcFxk63vdH08
El2q6Uv+vy4X8EUG6d9RPo0ngqMRiVHlBtxGg3CT9kWM8UvYWeBZWaisSW9rmL8V
W+JrWbG3nMIT+Poqz87I1TXbKJBYDHLNnADmCHsGgTIySFUCSdlI6wjIq1kQOkna
6NJ2wHNoVOTOmZD3R5E8VxY9sSlF6eY5uROjDtCIz01ZazXpXbNOA08RJUqLjuEt
oyMX6MzmQk1wC9w0hnUaoYDotKT97Vyn2+j+TpSGCNYu9OdOUrS1ymgCBtIx5djv
ulbmwGctJsW/yIC9gSmQRJwaUoS8L4H4gBDl1kN8wAVwxCMsiOFbB6cc0SkqsxHS
crevxUDUOg3ZvFnUwHKaqiQMaxYGQarY1+/ngMb45BwlPByXfKn5dyPdHzKSiDEc
h4KX61CVVbZhGg2B12klSPRFORDZeu1XQcL/alNAO2E0Radta5lBAzpGEvf94UeD
K91F0cGjyv99TVUPHUR6ByilDeU2k/+fGFcFW4pKxZJnSYtUMhCJmCg+4GRKHYru
idgIlGHwd+BrAv4un7XafPpNwS0OuT2SZ3zQsuPHUgykgUsgTh03GJNSWC+4hpp4
eD9WBdW2XXM0q6Us36VN
=axal
-----END PGP SIGNATURE-----

--------------enigEEB676D9F7375B3313AAF0ED--