Re: [Bug 16415] New: Show_Memory/Shift-ScrollLock triggers "unable to handle kernel paging request at 00021c6e"

[Hugh Dickins <hughd@google.com>]

On Wed, 28 Jul 2010, Mel Gorman wrote:
> On Wed, Jul 28, 2010 at 02:31:54PM +0200, The Nimble Byte wrote:
> > [   17.182169] BUG: unable to handle kernel paging request at 4c4fe4ad
> > [   17.182169] IP: [<c01d8a07>] show_mem+0xbf/0x15c
> 
> In both boot logs, the bad request was very close to 0x4c4fe400. It
> doesn't look like any poison pattern but does it look like any sort of
> relevant sequence to anyone else? I'm wondering if there is some piece
> of hardware writing where it shouldn't similar to what this bug was
> about http://lkml.org/lkml/2010/6/6/172 .

This has intrigued me, but I can't spend more time on it.

I doubt whether it's worth trying to interpret the 0x4c4fe4ad etc, I
think just leftover junk from a troubled history.  What's much easier
to make sense of is the poison in the sister bug 16416: 0xcc splattered
over a portion of mem_map.  Cannot be SLUB_RED_INACTIVE because SLUB is
not configured in, so looks like POISON_FREE_INITMEM.

Yesterday I thought that too unlikely (I'd expect 16416 to be quicker
to reproduce if it really were that); but looking through this latest
on 16415 also points to initmem:

> > [    0.000000] Linux version 2.6.34.1 
> > (root@doeblin.development.xafax.nl) (gcc version 4.2.4) #26 SMP Wed Jul 
> > 28 13:24:34 CEST 2010
> > ...
> > [    0.000000] Subtract (46 early reservations)
> > [    0.000000]   #1 [0000001000 - 0000002000]   EX TRAMPOLINE
> > [    0.000000]   #2 [0000100000 - 000048df10]   TEXT DATA BSS
> > [    0.000000]   #3 [000048e000 - 00004920a6]             BRK
> > ...
> > [    0.000000] virtual kernel memory layout:
> > ...
> > [    0.000000]       .init : 0xc130c000 - 0xc135f000   ( 332 kB)
> > [    0.000000]       .data : 0xc031dd65 - 0xc040bc80   ( 951 kB)
> > [    0.000000]       .text : 0xc0100000 - 0xc031dd65   (2167 kB)
> > ...
> > [   17.182169] BUG: unable to handle kernel paging request at 4c4fe4ad
> > [   17.182169] IP: [<c01d8a07>] show_mem+0xbf/0x15c
> > [   17.182169] Oops: 0000 [#1] SMP
> > [   17.182169] Pid: 0, comm: swapper Not tainted 2.6.34.1 #26
> > [   17.182169] EIP is at show_mem+0xbf/0x15c
> > [   17.182169] EAX: 4c4fe4a9 EBX: 00018580 ECX: 00000001 EDX: c130c000
> > [   17.182169] ESI: 00018570 EDI: c0407900 EBP: c03dfdc8 ESP: c03dfda8

That EDX: c130c000 there is show_mem's struct page pointer into mem_map:
and it matches the start of the init area in the virtual kernel memory
layout above.  Looks as if we've had the misfortune to allocate mem_map
across an area which soon gets freed as initmem.

When I try to build that .config, my .init follows on immediately from
.data; and as I understand it, should all be included in the reservation
of TEXT DATA BSS.  But here there's a significant gap: I suppose that's
either confusing something, or else a symptom of confusion.

I wonder what toolchain the Nimble Byte is using, and a bugzilla
attachment of System.map might be helpful, to see where __init_begin
and __init_end are shown there in relation to other sections.

But over to you guys, I must extricate myself!

Hugh

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