Re: CONFIG_NUMA breaks hibernation on x86-32 with PAE

On Monday, 10 of November 2008, Ingo Molnar wrote:

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:

On Mon, 10 Nov 2008 08:55:29 +0100
Pavel Machek <pavel@xxxxxxx> wrote:


* Pavel Machek <pavel@xxxxxxx> wrote:

...at least on 2.6.27 and 2.6.28-rc3. Resume gets to
acpi_hibernation_leave, then SLAB corruption is detected and machine
ends in series of oops.

Any ideas how to debug that?

do you get any serial log or USB key output, so that it's debuggable
directly?

Well, I can transcribe the BUG() from a picture, I guess, but it does
not seem to contain much useful info: SLAB corruption was detected and
backtrace is not quite important at that point...

Serial console is probably possible, but would take few days to setup.
Pavel

How about this patch ?
==
http://marc.info/?l=linux-mm-commits&m=122624388629106&w=2
==

note, that fix of Rafael's is now upstream as:

c5d7124: Fix __pfn_to_page(pfn) for CONFIG_DISCONTIGMEM=y

and included in v2.6.28-rc4.

But yes, this area of code (the save/restore of memory maps) would be
the main suspect to investigate.

It surely is, but the root cause need not be there, actually.

The problem only happens with CONFIG_NUMA enabled, only on 32-bit systems
and it _doesn't_ happen if the kernel is booted with highmem=0.

Evidently, CONFIG_NUMA is sufficient for the breakage to appear, even if
CONFIG_DISCONTIGMEM is not set (CONFIG_SPARSEMEM is set in this case, but
hibernation works with CONFIG_SPARSEMEM and without CONFIG_NUMA, both for
CONFIG_HIGHMEM64G=y).

I've been investigating this issue for quite some time now and it's starting
to look like a problem with kmap_atomic() or something along these lines.

Thanks,
Rafael
--
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/

Relevant Pages