Re: 2.6.18-rc1-mm1 oops on x86_64

From: Andrew Morton
Date: Sun Jul 09 2006 - 16:58:31 EST


On Sun, 9 Jul 2006 22:35:32 +0200
"Rafael J. Wysocki" <rjw@xxxxxxx> wrote:

> On Sunday 09 July 2006 22:21, Andrew Morton wrote:
> > On Sun, 09 Jul 2006 18:19:00 +0200
> > Cedric Le Goater <clg@xxxxxxxxxx> wrote:
> >
> > > Andrew Morton wrote:
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc1/2.6.18-rc1-mm1/
> > >
> > > Kernel BUG at ...home/legoater/linux/2.6.18-rc1-mm1/mm/page_alloc.c:252
> >
> > VM_BUG_ON((gfp_flags & (__GFP_WAIT | __GFP_HIGHMEM)) == __GFP_HIGHMEM);
> >
> > With your config, __GFP_HIGHMEM=0, so wham.
> >
> > I dunno, Christoph. I think those patches are going to significantly
> > increase the number of works-with-my-config, doesnt-with-yours scenarios.
>
> This particular one has no chance to work on x86_64 at all.
>

Fortunately in -mm we can make this BUG go away by setting
CONFIG_DEBUG_VM=n.

But in 2.6.18-rc1 that's a simple BUG_ON().

> So well, which one is it?

I don't understand that question, sorry. Right now, I'm inclined to drop
the patches:

reduce-max_nr_zones-remove-two-strange-uses-of-max_nr_zones.patch
reduce-max_nr_zones-fix-max_nr_zones-array-initializations.patch
reduce-max_nr_zones-make-display-of-highmem-counters-conditional-on-config_highmem.patch
reduce-max_nr_zones-make-display-of-highmem-counters-conditional-on-config_highmem-tidy.patch
reduce-max_nr_zones-move-highmem-counters-into-highmemc-h.patch
reduce-max_nr_zones-page-allocator-zone_highmem-cleanup.patch
reduce-max_nr_zones-use-enum-to-define-zones-reformat-and-comment.patch
reduce-max_nr_zones-use-enum-to-define-zones-reformat-and-comment-cleanup.patch
reduce-max_nr_zones-make-zone_dma32-optional.patch
reduce-max_nr_zones-make-zone_highmem-optional.patch
reduce-max_nr_zones-remove-display-of-counters-for-unconfigured-zones.patch
reduce-max_nr_zones-remove-display-of-counters-for-unconfigured-zones-s390-fix.patch
reduce-max_nr_zones-fix-i386-srat-check-for-max_nr_zones.patch

It's a question of whether the runtime gain merits the additional developer
load. Hard call.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/