From: Steven Cole <elenstev@mesatop.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Andrew Morton <akpm@osdl.org>,
torvalds@osdl.org, adi@bitmover.com, scole@lanl.gov,
support@bitmover.com, linux-kernel@vger.kernel.org
Subject: Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.)
Date: Sun, 16 May 2004 20:12:56 -0600 [thread overview]
Message-ID: <200405162012.57066.elenstev@mesatop.com> (raw)
In-Reply-To: <20040516235310.GZ3044@dualathlon.random>
On Sunday 16 May 2004 05:53 pm, Andrea Arcangeli wrote:
> On Sun, May 16, 2004 at 04:11:16PM -0600, Steven Cole wrote:
> > On Sunday 16 May 2004 03:29 pm, Andrew Morton wrote:
> > > Steven Cole <elenstev@mesatop.com> wrote:
> > > >
> > > > Anyway, although the regression for my particular machine for this
> > > > particular load may be interesting, the good news is that I've seen
> > > > none of the failures which started this whole thread, which are relatively
> > > > easily reproduceable with PREEMPT set.
> > >
> > > So... would it be correct to say that with CONFIG_PREEMPT, ppp or its
> > > underlying driver stack
> > >
> > > a) screws up the connection and hangs and
> > >
> > > b) scribbles on pagecache?
> > >
> > > Because if so, the same will probably happen on SMP.
> > >
> > Perhaps someone has the hardware to test this.
> >
> > To summarize my experience with the past 24 hours of testing:
> > Without PREEMPT , everything is rock solid.
>
> so we've two separate problems: the first is the ppp instability with
> preempt, the second is a regresion in the vm heuristics between 2.6.3
> and 2.6.5.
Yes, that is correct.
The instability was first noticed about one month ago when doing
a bk pull from linus' repository. I've been updating my kernel via
bk almost nightly, and around the time of 2.6.6-rc1 (IIRC), I got the
Assertion `s && s->tree' failed message from bk. At first it was thought
to be related to using an older version (3.0.1) of bk, so that was updated.
A few days later, the problem recurred. Since it only happened about
15% to 20% of the time, and was easy to recover from, I didn't scream
too loudly or too often to bitmover. But then, the problem started becoming
more persistent about a week ago, so I began complaining again. I managed
to get a bitkeeper-generated file to bitmover, who discovered that a very
odd (or even in this case) number of NUL bytes existed where they
should not exist. Hence this thread.
Then during the course of testing, I noticed the significant difference
in time it took to run a test script supplied by bitkeeper for current kernels
versus an older vendor kernel. Hence your being cc'ed.
>
> > and I (cringes at the thought) may repeat some bk pulls with
> > PREEMPT set.
>
> I've heard other reports of preempt being unstable with some sound
> stuff, just in case are you using sound drivers at all during that
> workload?
>
>
Yes, mea culpa. CONFIG_SND_ENS1371=y.
Steven
next prev parent reply other threads:[~2004-05-17 2:13 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6616858C-A5AF-11D8-A7EA-000A95CC3A8A@lanl.gov>
[not found] ` <200405122234.06902.elenstev@mesatop.com>
[not found] ` <15594C37-A509-11D8-A7EA-000A95CC3A8A@lanl.gov>
[not found] ` <20040513183316.GE17965@bitmover.com>
2004-05-14 4:32 ` 1352 NUL bytes at the end of a page? Steven Cole
[not found] ` <20040514144617.GE20197@work.bitmover.com>
[not found] ` <200405131723.15752.elenstev@mesatop.com>
2004-05-14 16:53 ` 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) Andy Isaacson
2004-05-14 17:23 ` Steven Cole
2004-05-15 0:54 ` Steven Cole
2004-05-15 1:55 ` 1352 NUL bytes at the end of a page? Wayne Scott
2004-05-15 3:15 ` 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) Lincoln Dale
2004-05-15 3:41 ` Andrew Morton
2004-05-15 5:39 ` Steven Cole
2004-05-16 1:23 ` Steven Cole
2004-05-16 2:18 ` Linus Torvalds
2004-05-16 3:44 ` Linus Torvalds
2004-05-16 4:31 ` Steven Cole
2004-05-16 4:52 ` Linus Torvalds
2004-05-16 5:22 ` Andrea Arcangeli
2004-05-16 15:28 ` Steven Cole
2004-05-16 17:49 ` Rutger Nijlunsing
2004-05-16 20:38 ` Andrea Arcangeli
2004-05-16 21:19 ` Steven Cole
2004-05-16 21:29 ` Andrew Morton
2004-05-16 22:11 ` Steven Cole
2004-05-16 23:53 ` Andrea Arcangeli
2004-05-17 2:12 ` Steven Cole [this message]
2004-05-17 8:21 ` R. J. Wysocki
2004-05-16 5:54 ` Steven Cole
2004-05-16 6:09 ` Andrew Morton
2004-05-16 6:24 ` Andrew Morton
2004-05-16 10:01 ` Andrew Morton
2004-05-16 13:49 ` Steven Cole
2004-05-18 1:47 ` Benjamin Herrenschmidt
2004-05-16 3:20 ` Andrew Morton
2004-05-16 3:58 ` Linus Torvalds
2004-05-17 2:28 ` Larry McVoy
2004-05-17 2:42 ` Linus Torvalds
2004-05-17 3:36 ` Steven Cole
2004-05-17 5:17 ` Linus Torvalds
2004-05-17 6:11 ` Andrew Morton
2004-05-17 13:56 ` 1352 NUL bytes at the end of a page? Wayne Scott
2004-05-17 15:17 ` Theodore Ts'o
2004-05-17 15:20 ` Larry McVoy
2004-05-17 15:22 ` Linus Torvalds
2004-05-17 15:25 ` Larry McVoy
2004-05-17 15:37 ` viro
2004-05-17 17:30 ` Steven Cole
2004-05-17 17:40 ` viro
2004-05-17 17:39 ` Steven Cole
2004-05-17 19:06 ` viro
2004-05-17 15:40 ` Arjan van de Ven
2004-05-17 15:53 ` Steven Cole
2004-05-17 16:23 ` Davide Libenzi
2004-05-17 16:28 ` Davide Libenzi
2004-05-17 14:07 ` 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) Larry McVoy
2004-05-17 14:12 ` Linus Torvalds
2004-05-17 7:25 ` Andrew Morton
2004-05-17 7:46 ` Andrew Morton
2004-05-17 8:39 ` Vladimir Saveliev
2004-05-17 8:44 ` Andrew Morton
2004-05-17 11:58 ` Steven Cole
2004-05-17 14:05 ` Larry McVoy
2004-05-17 14:14 ` Larry McVoy
2004-05-17 14:32 ` Linus Torvalds
2004-05-17 14:52 ` Larry McVoy
2004-05-17 15:02 ` Linus Torvalds
2004-05-17 15:05 ` Larry McVoy
2004-05-17 15:23 ` Chris Mason
2004-05-17 15:49 ` Steven Cole
2004-05-17 20:24 ` Chris Mason
2004-05-17 21:08 ` Steven Cole
2004-05-17 21:29 ` Andrew Morton
2004-05-17 22:15 ` Steven Cole
2004-05-17 23:52 ` Steven Cole
2004-05-18 0:03 ` Chris Mason
2004-05-18 0:15 ` Andrew Morton
2004-05-18 0:13 ` Andrew Morton
2004-05-18 0:45 ` Steven Cole
2004-05-18 1:34 ` Larry McVoy
2004-05-18 1:42 ` Andrew Morton
2004-05-18 1:56 ` Steven Cole
2004-05-17 14:11 ` Larry McVoy
[not found] ` <200405172142.52780.elenstev@mesatop.com>
[not found] ` <Pine.LNX.4.58.0405172056480.25502@ppc970.osdl.org>
[not found] ` <200405172319.38853.elenstev@mesatop.com>
2004-05-18 12:42 ` Chris Mason
2004-05-18 14:29 ` Steven Cole
2004-05-18 14:38 ` Linus Torvalds
2004-05-19 10:53 ` Steven Cole
2004-05-19 12:10 ` Chris Mason
2004-05-19 12:20 ` 1352 NUL bytes at the end of a page? Wayne Scott
2004-05-19 12:42 ` Nick Piggin
2004-05-19 13:28 ` Steven Cole
2004-05-19 13:36 ` Chris Mason
2004-05-19 13:59 ` Steven Cole
2004-05-19 14:03 ` Wayne Scott
2004-05-19 14:08 ` Chris Mason
2004-05-19 14:20 ` Steven Cole
2004-05-19 14:45 ` Steven Cole
2004-05-19 21:11 ` Non-regression for current kernel (was Re: 1352 NUL bytes at the end of a page?) Steven Cole
2004-05-17 15:35 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) Albert Cahalan
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=200405162012.57066.elenstev@mesatop.com \
--to=elenstev@mesatop.com \
--cc=adi@bitmover.com \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=scole@lanl.gov \
--cc=support@bitmover.com \
--cc=torvalds@osdl.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