Messages in this thread | | | Subject | Re: 2.6.23 boot failures on x86-64. | From | Zou Nan hai <> | Date | 31 Oct 2007 14:19:19 +0800 |
| |
On Wed, 2007-10-31 at 14:04, Zou Nan hai wrote: > On Tue, 2007-10-30 at 05:21, Martin Ebourne wrote: > > On Mon, 2007-10-29 at 15:43 -0400, Dave Jones wrote: > > > On Mon, Oct 29, 2007 at 08:03:09PM +0100, Andi Kleen wrote: > > > > > > But if allocating bootmem >4G doesn't work on these systems > > > > > > most likely they have more problems anyways. It might be better > > > > > > to find out what goes wrong exactly. > > > > > Any ideas on what to instrument ? > > > > > > > > See what address the bootmem_alloc_high returns; check if it overlaps > > > > with something etc. > > > > > > > > Fill the memory on the system and see if it can access all of its memory. > > > > > > Martin, as you have one of the affected systems, do you feel up to this? > > > > Faking a node at 0000000000000000-000000001fff0000 > > Bootmem setup node 0 0000000000000000-000000001fff0000 > > sparse_early_mem_map_alloc: returned address ffff81000070b000 > > > > My box has 512MB of RAM. > > > > Cheers, > > > > Martin. > > Oops, sorry, > seem to be a mistake of me. > I forget to exclude the DMA range. > > Does the following patch fix the issue? > > Thanks > Zou Nan hai > > --- a/arch/x86/mm/init_64.c 2007-10-31 11:24:11.000000000 +0800 > +++ b/arch/x86/mm/init_64.c 2007-10-31 12:31:02.000000000 +0800 > @@ -731,7 +731,7 @@ int in_gate_area_no_task(unsigned long a > void * __init alloc_bootmem_high_node(pg_data_t *pgdat, unsigned long size) > { > return __alloc_bootmem_core(pgdat->bdata, size, > - SMP_CACHE_BYTES, (4UL*1024*1024*1024), 0); > + SMP_CACHE_BYTES, (4UL*1024*1024*1024), __pa(MAX_DMA_ADDRESS)); > } > > const char *arch_vma_name(struct vm_area_struct *vma) > > > >
Please ignore the patch, the patch is wrong.
However I think the root cause is when __alloc_bootmem_core fail to allocate a memory above 4G it will fall back to allocate from the lowest page. Then happens to be allocated in DMA region sometimes...
Since this code path is dead, I am OK to revert the patch.
Suresh and I will check the CONFIG_SPARSE_VMEMMAP path. Thanks Zou Nan hai
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |