Re: mmotm boot panic bootmem-avoid-dma32-zone-by-default.patch
From: Yinghai Lu
Date: Fri Mar 05 2010 - 04:06:07 EST
On 03/04/2010 07:21 PM, Johannes Weiner wrote:
> Hello Greg,
> On Thu, Mar 04, 2010 at 01:21:41PM -0800, Greg Thelen wrote:
>> On several systems I am seeing a boot panic if I use mmotm
>> (stamp-2010-03-02-18-38). If I remove
>> bootmem-avoid-dma32-zone-by-default.patch then no panic is seen. I
>> find that:
>> * 2.6.33 boots fine.
>> * 2.6.33 + mmotm w/o bootmem-avoid-dma32-zone-by-default.patch: boots fine.
>> * 2.6.33 + mmotm (including
>> bootmem-avoid-dma32-zone-by-default.patch): panics.
>> Note: I had to enable earlyprintk to see the panic. Without
>> earlyprintk no console output was seen. The system appeared to hang
>> after the loader.
> where sparse_index_init(), in the SPARSEMEM_EXTREME case, will allocate
> the mem_section descriptor with bootmem. If this would fail, the box
> would panic immediately earlier, but NO_BOOTMEM does not seem to get it
> Greg, could you retry _with_ my bootmem patch applied, but with setting
> CONFIG_NO_BOOTMEM=n up front?
> I think NO_BOOTMEM has several problems. Yinghai, can you verify them?
> 1. It does not seem to handle goal appropriately: bootmem would try
> without the goal if it does not make sense. And in this case, the
> goal is 4G (above DMA32) and the amount of memory is 256M.
> And if I did not miss something, this is the difference with my patch:
> without it, the default goal is 16M, which is no problem as it is well
> within your available memory. But the change of the default goal moved
> it outside it which the bootmem replacement can not handle.
> 2. The early reservation stuff seems to return NULL but callsites assume
> that the bootmem interface never does that. Okay, the result is the same,
> we crash. But it still moves error reporting to a possibly much later
> point where somebody actually dereferences the returned pointer.
for alloc_bootmem_node it will honor goal, if someone input big goal it will not
fallback to get a small one below that goal.
return NULL, could make caller have more choice and more control.
anyway we should honor the goal, otherwise should use _nopanic instead.
according to context
please check current linus tree still have problem about mem_map is using that much low mem?
on my 1024g system first node has 128G ram, [2g, 4g) are mmio range.
[ 0.000000] a - 11
[ 0.000000] 19 40 - 80 95
[ 0.000000] 702 740 - 1000 1000
[ 0.000000] 331f 3340 - 3400 3400
[ 0.000000] 35dd - 3600
[ 0.000000] 37dd - 3800
[ 0.000000] 39dd - 3a00
[ 0.000000] 3bdd - 3c00
[ 0.000000] 3ddd - 3e00
[ 0.000000] 3fdd - 4000
[ 0.000000] 41dd - 4200
[ 0.000000] 43dd - 4400
[ 0.000000] 45dd - 4600
[ 0.000000] 47dd - 4800
[ 0.000000] 49dd - 4a00
[ 0.000000] 4bdd - 4c00
[ 0.000000] 4ddd - 4e00
[ 0.000000] 4fdd - 5000
[ 0.000000] 51dd - 5200
[ 0.000000] 93dd 9400 - 7d500 7d53b
[ 0.000000] 7f730 - 7f750
[ 0.000000] 100012 100040 - 100200 100200
[ 0.000000] 170200 170200 - 2080000 2080000
[ 0.000000] 2080065 2080080 - 2080200 2080200
so PFN: 9400 - 7d500 are free.
[ 0.000000] nid=0 start=0x0000000000 end=0x0002080000 aligned=1
[ 0.000000] free [0x000000000a - 0x0000000095]
[ 0.000000] free [0x0000000702 - 0x0000001000]
[ 0.000000] free [0x00000032c4 - 0x0000003400]
[ 0.000000] free [0x00000035de - 0x0000003600]
[ 0.000000] free [0x00000037dd - 0x0000003800]
[ 0.000000] free [0x00000039dd - 0x0000003a00]
[ 0.000000] free [0x0000003bdd - 0x0000003c00]
[ 0.000000] free [0x0000003ddd - 0x0000003e00]
[ 0.000000] free [0x0000003fdd - 0x0000004000]
[ 0.000000] free [0x00000041dd - 0x0000004200]
[ 0.000000] free [0x00000043dd - 0x0000004400]
[ 0.000000] free [0x00000045dd - 0x0000004600]
[ 0.000000] free [0x00000047dd - 0x0000004800]
[ 0.000000] free [0x00000049dd - 0x0000004a00]
[ 0.000000] free [0x0000004bdd - 0x0000004c00]
[ 0.000000] free [0x0000004ddd - 0x0000004e00]
[ 0.000000] free [0x0000004fdd - 0x0000005000]
[ 0.000000] free [0x00000051dd - 0x0000005200]
[ 0.000000] free [0x00000053dd - 0x000007d53b]
[ 0.000000] free [0x000007f730 - 0x000007f750]
[ 0.000000] free [0x000010041f - 0x0000100a00]
[ 0.000000] free [0x0000170a00 - 0x0000180a00]
[ 0.000000] free [0x0000180a03 - 0x0002080000]
so pfn: 53dd 7d53b are free
looks like we don't need to change the default goal in alloc_bootmem_node.
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/