public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Clayton Weaver" <cgweav@email.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4.21-rc7
Date: Sun, 08 Jun 2003 03:54:48 -0500	[thread overview]
Message-ID: <20030608085448.31378.qmail@email.com> (raw)

> Now I really hope its the last one, all this
> rc's are making me mad.

We still have ide problems, and I don't see any
potential fixes for that in the changelog between -rc6 and -rc7.

I tried -rc6 on a whim and had hda report
a timeout (dma, I think, but the message went by kind of quick), then the big freeze with the
disk light stuck on,  Never happened
in 6 months on the same hardware running
2.4.19-rc2 (with glibc-2.2.5, gcc-2.95.3,
binutils-2.12.90.0.9, all ext2 filesystems).

I recompiled with all kernel debugging options
enabled and disabled partition statistics, since that was the one thing that was obviously new about the enabled ide options (I didn't select
any other new options, but of course the kernel code underneath is probably different, so one could not conclude anything from suck meager
testing). It ran for about 8 hours without freezing, with that drive doing a lot more
work than it was doing when it livelocked.

e2fsck reported errors on the next reboot, though,
and it's been rebooted into 2.4.19-rc2 to get some
other work done with it since then (caching the source for an upgrade of a 2.2.x box, different libc, yada yada, needs to be reliable until
that is finished).

SiS530/5513, k6-II/450, udma33 Maxtor drive that 2.4.19-rc2 has no problems with.

You can release a 2.4.21 anyway, of course, but without finding out where the ide livelock (and other big freezes, thinking of the report on the all-scsi system already posted) originates, calling it "stable" would be a bit fanciful.

(2.4.19-rc2 has its own quirks, of course, but
not "single-threaded ide livelock with this
chipset and ide drive". I can reliably kill it with 32 threads depth-first scanning different directory trees on that same disk in parallel, unfortunately without an oops to show for it.
It is not running out of memory (no ENOMEM reports), merely some mundane race condition or missing lock or whatever. Change it to 32 forks running in parallel, and they finish normally, though of course not all that quickly while seek-thrashing one and the same disk between them.)

Not what you wanted to hear, right? Oh well.

(Better to find out sooner than release
2.4.21-stable and watch 52 different bug reports on it arrive at the list the next day.)

Regards,

Clayton Weaver
<mailto: cgweav@email.com>

-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup


             reply	other threads:[~2003-06-08  8:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-08  8:54 Clayton Weaver [this message]
2003-06-08  9:47 ` Linux 2.4.21-rc7 Willy Tarreau
  -- strict thread matches above, loose matches on Subject: below --
2003-06-08 20:17 Clayton Weaver
2003-06-08 20:51 ` Bartlomiej Zolnierkiewicz
2003-06-08 21:47 ` Willy Tarreau
2003-06-03 18:45 Margit Schubert-While
2003-06-03 18:50 ` Marc-Christian Petersen
2003-06-03 19:38   ` Christoph Hellwig
2003-06-03 17:04 Marcelo Tosatti
2003-06-03 18:02 ` Tomas Szepe
2003-06-03 18:07   ` Marcelo Tosatti
2003-06-03 19:15     ` lk
2003-06-03 19:40       ` Alan Cox
2003-06-03 18:30 ` Alex Romosan
2003-06-03 19:27   ` Jeff Garzik
2003-06-03 19:58     ` Alex Romosan
2003-06-03 20:14       ` Tom Rini
2003-06-04  3:35         ` David S. Miller
2003-06-04 15:09           ` Mr. James W. Laferriere
2003-06-04 23:37           ` Alex Romosan
2003-06-05 12:09 ` Andreas Haumer
2003-06-07 15:46   ` Andreas Haumer
2003-06-11 20:48     ` Marcelo Tosatti
     [not found]       ` <1055408183.2552.18.camel@tor.trudheim.com>
2003-06-12  9:35         ` Andreas Haumer

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=20030608085448.31378.qmail@email.com \
    --to=cgweav@email.com \
    --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