Bad Page dump (help)

Felipe Balbi balbi at ti.com
Thu Jul 31 08:30:27 PDT 2014


Hi,

On Thu, Jul 31, 2014 at 03:53:54PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 29, 2014 at 03:17:50PM -0500, Felipe Balbi wrote:
> > [    0.000000] Booting Linux on physical CPU 0x0
> > [    0.000000] Linux version 3.16.0-rc7-next-20140729-00002-g4169dc8-dirty (balbi at saruman) (gcc version 4.8.2 20130902 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.09 - Linaro GCC 2013.09) ) #590 SMP Tue Jul 29 15:13:32 CDT 2014
> > [    0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
> > [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> > [    0.000000] Machine model: TI AM437x Industrial Development Kit
> > [    0.000000] bootconsole [earlycon0] enabled
> > [    0.000000] memblock_reserve: [0x00000080008340-0x0000008118240f] flags 0x0 arm_memblock_init+0x20/0x1a0
> > [    0.000000] memblock_reserve: [0x00000080004000-0x00000080007fff] flags 0x0 arm_memblock_init+0x11c/0x1a0
> > [    0.000000] memblock_reserve: [0x0000008fff5000-0x0000008fffcfff] flags 0x0 early_init_fdt_scan_reserved_mem+0x30/0x8c
> > [    0.000000] memblock_reserve: [0x000000ae800000-0x000000af7fffff] flags 0x0 memblock_alloc_range_nid+0x38/0x5c
> > [    0.000000] cma: Reserved 16 MiB at ae800000
> > [    0.000000] MEMBLOCK configuration:
> > [    0.000000]  memory size = 0x40000000 reserved size = 0x21860d0
> > [    0.000000]  memory.cnt  = 0x1
> > [    0.000000]  memory[0x0]	[0x00000080000000-0x000000bfffffff], 0x40000000 bytes flags: 0x0
> 
> So that's your available RAM.

right, 1GiB.

> > [    0.000000]  reserved.cnt  = 0x4
> > [    0.000000]  reserved[0x0]	[0x00000080004000-0x00000080007fff], 0x4000 bytes flags: 0x0
> 
> The swapper page dir.
> 
> > [    0.000000]  reserved[0x1]	[0x00000080008340-0x0000008118240f], 0x117a0d0 bytes flags: 0x0
> 
> The kernel.
> 
> > [    0.000000]  reserved[0x2]	[0x0000008fff5000-0x0000008fffcfff], 0x8000 bytes flags: 0x0
> 
> The device tree blob.
> 
> > [    0.000000]  reserved[0x3]	[0x000000ae800000-0x000000af7fffff], 0x1000000 bytes flags: 0x0
> 
> Some 16MB reservation.
> 
> ...
> 
> > [    0.000000] memblock_virt_alloc_try_nid_nopanic: 9437184 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 alloc_node_mem_map.constprop.68+0x68/0x94
> > [    0.000000] memblock_reserve: [0x000000adef1000-0x000000ae7f0fff] flags 0x0 memblock_virt_alloc_internal+0x100/0x16c
> > [    0.000000] free_area_init_node: node 0, pgdat c08e7e40, node_mem_map edef1000
> 
> So, this time the node 0 mem_map starts at 0xedef1000.
> 
> > [    0.000000] BUG: Bad page state in process swapper  pfn:811db
> > [    0.000000] page:edf192cc count:0 mapcount:-3407872 mapping:  (null) index:0x0
> 
> Your struct page appears to have grown by 4 bytes to 36 bytes.  In your
> previous example, I think it was 32 bytes.
> 
> mapcount here is 0xffcc0000.
> 
> mapcount is stored at an offset of 12 bytes from the start, and shares
> its location with...
> 	counter
> 	active
> and a slub data structure - frozen in bit 31, objects in 30-16, and inuse
> for bits 15-0.  The count is stored at offset 16.  Mapping is at offset
> 4, and index at 8.
> 
> mapcount is slightly weird in that the code to access it is:
> 
> static inline void page_mapcount_reset(struct page *page)
> {
>         atomic_set(&(page)->_mapcount, -1);
> }
> 
> static inline int page_mapcount(struct page *page)
> {
>         return atomic_read(&(page)->_mapcount) + 1;
> }
> 
> So there's an offset of one on the mapcount values which we have to
> compensate for.  Hence, we can build up a picture of memory here:
> 
> 0xedf192cc:	unknown
> 0xedf192d0:	0
> 0xedf192d4:	0
> 0xedf192d8:	0xffcbffff
> 0xedf192dc:	0
> 
> So, the locations surrounding the mapcount seem to be zero.  This pattern
> is repeated for every entry in the table - except with different values
> for the mapcount.
> 
> The values include:
> 
> 0xfffbffff
> 0xffcbffff
> 0xffebffff
> 0xff4affff
> 0xff42ffff
> 
> If I include the values from your previous message, which were with
> a sizeof(struct page) == 32, we have these:
> 
> 0xff4fffff
> 0xff6bffff
> 0xff6fffff
> 0xffcfffff
> 
> This looks rather suspicious.  As the surrounding bytes are zero, I
> don't think I'd blame it on uninitialised data, and I don't think it's
> slub somehow making use of the page array before it's been loaded up
> with free pages.
> 
> Looking closer at the bit patterns of byte 3:
> 
> 1111 1011
> 1100 1011
> 1110 1011
> 0100 1010
> 0100 0010
> ---------
> 0100 1111
> 0110 1011
> 0110 1111
> 1100 1111
> 
> makes me wonder a bit... why is bit 6 and 1 always set, but bit 2 is
> always clear amongst this data set.
> 
> 
> > [    0.000000] Memory: 274804K/1048576K available (5769K kernel code, 654K rwdata, 2220K rodata, 458K init, 8786K bss, 44608K reserved, 270336K highmem)
> > [    0.000000] Virtual kernel memory layout:
> > [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> > [    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
> > [    0.000000]     vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
> > [    0.000000]     lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
> > [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> > [    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
> > [    0.000000]       .text : 0xc0008000 - 0xc07d58e4   (7991 kB)
> > [    0.000000]       .init : 0xc07d6000 - 0xc0848800   ( 458 kB)
> > [    0.000000]       .data : 0xc084a000 - 0xc08ed8f0   ( 655 kB)
> > [    0.000000]        .bss : 0xc08ed8f0 - 0xc1182410   (8787 kB)
> > [    0.000000] page:ee128024 count:0 mapcount:-1048576 mapping:  (null) index:0x0
> > [    0.000000] page flags: 0x0()
> > [    0.000000] page dumped because: VM_BUG_ON_PAGE((*(volatile int *)&(&page->_mapcount)->counter) != -1)
> > [    0.000000] ------------[ cut here ]------------
> > [    0.000000] Kernel BUG at c00f2a78 [verbose debug info unavailable]
> > [    0.000000] Internal error: Oops - BUG: 0 [#1] SMP ARM
> > [    0.000000] Modules linked in:
> > [    0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G    B   W      3.16.0-rc7-next-20140729-00002-g4169dc8-dirty #590
> > [    0.000000] task: c0855dc0 ti: c084a000 task.ti: c084a000
> > [    0.000000] PC is at __rmqueue+0x618/0x644
> > [    0.000000] LR is at dump_page_badflags+0x6c/0x98
> > [    0.000000] pc : [<c00f2a78>]    lr : [<c00f0644>]    psr: 600001d3
> > [    0.000000] sp : c084bd78  ip : c084a000  fp : 00000009
> > [    0.000000] r10: 00000000  r9 : c08e7e40  r8 : 00000000
> > [    0.000000] r7 : 00000002  r6 : c08e7f24  r5 : c08e7f10  r4 : ee128024
> > [    0.000000] r3 : 00000000  r2 : 00000000  r1 : c084bcd0  r0 : 0000005a
> 
> Unfortunately, by this time we've lost the value of _mapcount in the
> registers.  I'm willing to bet that some bits in 23:16 are clear in
> this.
> 
> I'm wondering why it's always that byte - as you say in your initial
> message, this is a new board.  Has it ever worked before?  What is

it's the first time I'm porting this board to any kernel whatsoever. No
other kernel/bootloader has ever run :-) On the plus side, though, it's
a very, very similar layout to am437x-sk which has just hit linux-next
and I ported u-boot and kernel. From the DDR point of view, it's the
same thing. Well, different PCB routing, but same components.

> the hardware RAM organisation?  Is the full 1GB provided by a single
> 32-bit or 64-bit chip covering the whole range, or is it two separate
> chips covering part of the range?

I have two MT41K256M16HA (256x16) both attached to a single EMIF
instance. One DDR handles top 16-bits of data and the other handles
lower 16-bits.

> I'm suspecting that you either have badly a routed data bus connection
> on bits 23:16, or you have a bad RAM chip which corrupts those bits.
> 
> It may be worth trying a simple assembly-level RAM test which pokes
> all locations with alternating 0xffffffff, 0x00000000 and verifies
> them.  By that I mean odd word addresses set to one value, even set
> to the other, verify, reverse them, try again.
> 
> Alternatively, if there's a proper ARM memory checker around, I think
> it would be well worth running it on this board to check the integrity
> of the hardware.

I'll try u-boot's memtester and see what results it yields.

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140731/82e53137/attachment.sig>


More information about the linux-arm-kernel mailing list