linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Tony Lill <ajlill@ajlc.waterloo.on.ca>,
	linux-mm@kvack.org, bugzilla-daemon@bugzilla.kernel.org,
	bugme-daemon@bugzilla.kernel.org,
	Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [Bugme-new] [Bug 15214] New: Oops at __rmqueue+0x51/0x2b3
Date: Mon, 8 Feb 2010 11:18:52 -0800	[thread overview]
Message-ID: <20100208111852.a0ada2b4.akpm@linux-foundation.org> (raw)
In-Reply-To: <20100208101045.GA23680@csn.ul.ie>

On Mon, 8 Feb 2010 10:10:46 +0000
Mel Gorman <mel@csn.ul.ie> wrote:

> On Sun, Feb 07, 2010 at 01:34:58PM -0500, Tony Lill wrote:
> > On Friday 05 February 2010 06:20:00 Mel Gorman wrote:
> > > On Wed, Feb 03, 2010 at 02:39:21PM -0800, Andrew Morton wrote:
> > > > > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> > > 
> > > This is a bit of a reach, but how confident are you that this version of
> > > gcc is building kernels correctly?
> > >
> > > There are a few disconnected reports of kernel problems with this
> > > particular version of gcc although none that I can connect with this
> > > problem or on x86 for that matter. One example is
> > > 
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536354
> > > 
> > > which reported problems building kernels on the s390 with that compiler.
> > > Moving to 4.2 helped them and it *should* have been fixed according to
> > > this bug
> > > 
> > > http://bugzilla.kernel.org/show_bug.cgi?id=13012
> > > 
> > > It might be a red herring, but just to be sure, would you mind trying
> > > gcc 4.2 or 4.3 just to be sure please?
> > 
> > Well, it was producing working kernels up until 2.6.30, but I recompiled with
> > gcc (Debian 4.3.2-1.1) 4.3.2
> > and the box has been running nearly 48 hour without incident. My previous 
> > record was 2. So I guess we can put this down to a new compiler bug.
> > 
> 
> Well, it's great the problem source is known but pinning down compiler bugs
> is a bit of a pain. Andrew, I don't recall an easy-as-in-bisection-easy
> means of identifying which part of the compile unit went wrong and why so
> it can be marked with #error for known broken compilers. Is there one or is
> it a case of asking for two objdumps of __rmqueue and making a stab at it?

ugh.  This is pretty rare.

Probably the best strategy is to generate the two page_alloc.s files,
fish out the __rmqueue part and then try to compare them.  The key
part is to Cc Linus then thrash around stupidly for long enough for him
to take pity and find the bug for you.

> > I probably should have checked this before reporting a bug. Mea culpa
> 
> Not at all. Miscompiles like this are rare and usually caught a lot quicker
> than this. If you hadn't reported the problem with  two different machines,
> I would have blamed hardware and asked for a memtest. The only reason I
> spotted this might be a compiler was because the type of error you reported
> "couldn't happen".
> 
> Thanks for reporting and testing.

Yup.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-02-08 19:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-15214-10286@http.bugzilla.kernel.org/>
2010-02-03 22:39 ` [Bugme-new] [Bug 15214] New: Oops at __rmqueue+0x51/0x2b3 Andrew Morton
2010-02-05 11:20   ` Mel Gorman
2010-02-07 18:34     ` Tony Lill
2010-02-08 10:10       ` Mel Gorman
2010-02-08 19:18         ` Andrew Morton [this message]
2010-02-09 14:45           ` Mel Gorman
     [not found]             ` <201002101217.34131.ajlill@ajlc.waterloo.on.ca>
2010-02-11 18:20               ` Mel Gorman
2010-02-11 18:49                 ` Linus Torvalds
2010-02-12 12:17                   ` Mel Gorman

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=20100208111852.a0ada2b4.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=ajlill@ajlc.waterloo.on.ca \
    --cc=bugme-daemon@bugzilla.kernel.org \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    /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;
as well as URLs for NNTP newsgroup(s).