Re: 2.6.10-rc2-mm3 [was: Re: 2.6.9-rc2: "kernel BUG at mm/rmap.c:473!"]

[Hugh Dickins]

On Tue, 30 Nov 2004, Benoit Boissinot wrote:
> 
> I had the same BUG_ON with 2.6.10-rc2-mm3 while transcoding a video.
> 
> kernel BUG at mm/rmap.c:479!
> CPU:    0
> EIP:    0060:[<c01454a4>]    Not tainted VLI
> EFLAGS: 00010286   (2.6.10-rc2-mm3-arakou) 
> EIP is at page_remove_rmap+0x34/0x40
...
>  BUG: atomic counter underflow at:
>  [<c0103b57>] dump_stack+0x17/0x20
>  [<c011a51e>] do_exit+0x39e/0x420
>  [<c0103efc>] die+0x13c/0x140
...
> Bad page state at prep_new_page (in process 'mpd', page c17712c0)
> flags:0x40020114 mapping:00000000 mapcount:-1 count:0
> Backtrace:
>  [<c0103b57>] dump_stack+0x17/0x20
>  [<c0136352>] bad_page+0x72/0xb0
>  [<c013669b>] prep_new_page+0x2b/0x80

Thanks for the report.  I'm still searching for something useful
to say.  I've recently spent several days trying to deduce what's
behind such page_remove_rmap BUGs, but not yet come up with any
convincing hypothesis.  Yours is the first I've seen without
CONFIG_PREEMPT, so that's another potential culprit exonerated.

Some things which _might_ help me to shed more light on your case:
outputs of "objdump -rd" on your mm/memory.o, mm/rmap.o, kernel/exit.o;
and "cat /proc/$(pidof transcode)/maps" while transcode is running.

The atomic counter underflow in do_exit does suggest corruption
elsewhere than in transcode's page table (though I'm not at all
sure that is corrupt) - as always, it is worth giving memtest86
a thorough run to check your memory.

Thanks,
Hugh

-
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/