From: Con Kolivas <kernel@kolivas.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.21-rc3-mm2
Date: Fri, 9 Mar 2007 01:52:49 +1100 [thread overview]
Message-ID: <200703090152.49253.kernel@kolivas.org> (raw)
In-Reply-To: <20070307201915.4d579113.akpm@linux-foundation.org>
On Thursday 08 March 2007 15:19, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.
>6.21-rc3-mm2/
>
> - This is the same as 2.6.21-rc3-mm1, except Con's CPU scheduler changes
> were dropped.
As for benchmarking between them I haven't seen anyone post anything yet.
Test.kernel.org is having a field day with both of them ABORTing or WARNing
without one GOOD so far. Urgh what was the description you gave of -mm to
Gene?...I don't envy you :(
Apart from your big fat oops on that massive config, I've had people boot it
also on alpha and IA64. The bitmap error also manifested on alpha but not on
IA64 (neither oopsed).
So on qemu I can reproduce the oops you're getting with your config (make
oldconfig all default on top of your config), but I'm getting other wonderful
related problems too on rc3-mm2. On qemu -mm1 boots mostly without error and
then crashes nicely when I type 'ps' with a long pause for about twenty
seconds and then a combination of soft lockups, bitmap errors, and eventually
hits the BUG_ON I put in bitmap_error(). However, -mm2 also vomits on
typing 'ps'.
It pauses and then spits out (fun lines selected from ps output):
7 ? serial8250: too much work for irq4
00:00:00 watchdog/1
88 ? 00:00:0serial8250: too much work for irq4
0 cqueue/1
137 ? 00:00serial8250: too much work for irq4
:00 aio/0
Checking a few /proc files I see that "serial83250" info littered
throughout /proc/stat as well. -mm2 does not oops but the proc output is
variously corrupted.
Interestingly if I don't type 'ps' in the -mm1 qemu it runs fine with no sign
of a bug... In summary, here I can only reproduce your big fat oops by it
being triggered by some corruption elsewhere on this config related to /proc
breakage that I haven't managed to track down. I checked the broken-out
patches to see which touched /proc and it was oh, most of them. I tried on rc3
and had the same thing happen. I haven't tried rc3 without rsdl (your config
takes too darn long to build!).
The bitmap error that you're hitting on ppc I believe is a different issue. I
don't have hardware that does it at my end but one user has hit it also on
alpha and is trying to help me find the root cause. If we change it from
being a once only printk to every time, it seems to go away after 10 mins of
runtime never to return again. What could possibly change over that time for
the error never to return again is a mystery. This part definitely looks to
be my fault but a bug "getting better and going away" is a new one for me. I
have to think about some timer interaction although I don't use jiffies or
timers directly at all in my code. It also happens on 2.6.20 with RSDL.
Summary from what I've been able to find:
x86_32: ok
x86_64: ok
x86_64 fat config: scheduler code oops brought on by accessing /proc
IA64 ok: ok
Alpha: bitmap error, runs ok
I'm off to pass out for now so that I'm of some use to the rest of my
existence tomorrow.
--
-ck
next prev parent reply other threads:[~2007-03-08 14:53 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-08 4:19 2.6.21-rc3-mm2 Andrew Morton
2007-03-08 7:39 ` [PATCH] fix BUG_ON check at move_freepages() (Re: 2.6.21-rc3-mm2) Yasunori Goto
2007-03-08 11:01 ` Mel Gorman
2007-03-08 14:52 ` Con Kolivas [this message]
2007-03-08 21:04 ` 2.6.21-rc3-mm2 Con Kolivas
2007-03-08 21:56 ` 2.6.21-rc3: /proc broken Con Kolivas
2007-03-09 8:53 ` Russell King
2007-03-09 9:59 ` Con Kolivas
2007-03-12 12:56 ` 2.6.21-rc3-mm2 hangs my opteron during bootup, ACPI? Helge Hafting
2007-03-12 13:25 ` Luming Yu
2007-03-12 19:56 ` Len Brown
2007-03-17 0:10 ` Helge Hafting
2007-03-14 3:52 ` 2.6.21-rc3-mm2 (oops in move_freepages) Bjorn Helgaas
2007-03-14 9:44 ` Mel Gorman
2007-03-14 15:11 ` Bjorn Helgaas
2007-03-14 16:13 ` Mel Gorman
2007-03-14 16:52 ` Bjorn Helgaas
2007-03-14 17:21 ` Mel Gorman
2007-03-14 18:36 ` Bjorn Helgaas
2007-03-14 18:59 ` Mel Gorman
2007-03-14 20:46 ` Bjorn Helgaas
2007-03-14 20:55 ` Mel Gorman
2007-03-14 19:10 ` [PATCH] Avoid unsafe use of struct pages in move_freepages when CONFIG_HOLES_IN_ZONE is set Mel Gorman
[not found] ` <200703141457.06489.bjorn.helgaas@hp.com>
2007-03-15 1:14 ` 2.6.21-rc3-mm2 (BUG in pci_restore_state()) Eric W. Biederman
2007-03-19 19:17 ` 2.6.21-rc3-mm2 Randy Dunlap
2007-03-19 19:55 ` 2.6.21-rc3-mm2 Andrew Morton
2007-03-19 23:01 ` 2.6.21-rc3-mm2 Kay Sievers
2007-03-19 19:40 ` 2.6.21-rc3-mm2 Randy Dunlap
2007-03-19 22:26 ` [PATCH] ptrace needs PROC_FS Randy Dunlap
2007-03-19 22:48 ` Roland McGrath
2007-03-20 11:18 ` Pavel Machek
2007-03-20 0:27 ` 2.6.21-rc3-mm2 Randy Dunlap
2007-03-20 0:39 ` 2.6.21-rc3-mm2 Andrew Morton
2007-03-20 0:51 ` 2.6.21-rc3-mm2 Randy Dunlap
2007-03-20 18:51 ` 2.6.21-rc3-mm2 Roland McGrath
2007-03-20 12:14 ` 2.6.21-rc3-mm2 Sam Ravnborg
2007-03-20 15:43 ` 2.6.21-rc3-mm2 Randy Dunlap
-- strict thread matches above, loose matches on Subject: below --
2007-03-09 4:36 2.6.21-rc3-mm2 Michael
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=200703090152.49253.kernel@kolivas.org \
--to=kernel@kolivas.org \
--cc=akpm@linux-foundation.org \
--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