lkml.org 
[lkml]   [1996]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.0.9, 2.0.10 and CMD640 EIDE... (Warning: Soapbox alert)

I'd like to take this opportunity to register some *extreme* annoyance on
the IDE patches that took place under 2.0.9 (and propogated into 2.0.10).
I now have 12+ machines which will not boot these kernels. Please note
that these same machines worked just fine with kernels ranging from 1.1.21
(vanilla) to 2.0.8.

Before someone asks, yes I can back out the IDE patches on these kernels,
and yes I did. I'm now running a more-or-less 2.0.10 minus the IDE stuff.

My question (and comments) concern WHY I had to do so.

1) I was given to believe that even numbered kernel series were
PRODUCTION releases.

2) I was also led to believe that production releases were for BUG FIXES,
not bug introductions.

3) Why is the latest kernel release still 2.0.10? Linus, if you had a
typo in something, we would see a 2.0.11 before 10 finished
propogating to this side of the Atlantic. Right? :-)

4) Given that there have been a plethora of complaints on various
newsgroups and mailing lists, why HASN'T this been done?

5) I know that the CMD640 is a busted chip. If I could perform an
exorcism on these machines and get rid of them, I would. But do we
HAVE to introduce NON WORKING patches into production level kernels to
try and excise those annoyances?


And the amazing part is that we are so busy introducing bugs INTO the
kernel, we've taken no notice of some of the EXISTING bugs. Despite many
reports of bugs in the signal handling code and stuck processes, both by
myself and others, we still have a huge system cluster with processes
hanging by the truckload. I'd like to claim non-standard hardware, bad
software, and the like, but too many others are experiencing the same
problems.

Give that this problem (I'm just using it as an example) has been brought
to the list IN DETAIL several times by myself and others, with offers of
machine time/accounts to diagnose plus information and traces by the
tub-full, I find the total lack of responsiveness to it, and problems like
it, _especially_ gauling given the almost casual way this new code was
placed and what has happened since.

Guys, I know this is frustration speaking (and I'll probably cool down and
be a nice happy clam later), but I'm about at my wits end. I'd hate to
turn my back on Linux (our whole campus is running it, both on
workstations and major server clusters), but I've never seen the FreeBSD
folks (another example) treat something like this. Which is too bad, as I
really like Linux (always have since .96).

Regards,

-Jonathan _ _
------------------------------------------------------------->>>>>>>>-(o)(o)---
Jonathan A. Davis | Academic Systems Analyst | Hattiesburg/Gulf Park/Stennis
Computing Center | Box 5171 | 39401-5171 | (601) 266-4103 | davis@cc.usm.edu
http://evergreen.cc.usm.edu/~davis | Linux: The choice of a GNU generation



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:2.362 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site