Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
> Yasunori Goto wrote: > >> On Thu, 6 Dec 2007, Geert Uytterhoeven wrote: > >> > On Thu, 6 Dec 2007, Yasunori Goto wrote: > >> > > > I'll try Milton's suggestion to pre-allocate the memory early. It > >> > > > seems > >> > > > that should work as long as nothing else before the hot-plug mem is > >> > > > added > >> > > > needs a large chunk. > >> > > > >> > > Hello. Geoff-san. Sorry for late response. > >> > > > >> > > Could you tell me the value of the following page_size calculation > >> > > in vmemmap_populate()? I think this page_size may be too big value. > >> > > > >> > > -- > >> > > int __meminit vmemmap_populate(struct page *start_page, > >> > >unsigned long nr_pages, int > >> > > node) > >> > >: > >> > >: > >> > > unsigned long page_size = 1 << > >> > > mmu_psize_defs[mmu_linear_psize].shift; > >> > >: > >> > > --- > >> > >> 16 MiB of course. > > > > 16 MiB is not page size. It is "section size". > > IIRC, powerpc's page size must be 4K (or 64K). > > If page size is 4k, vmemmap_alloc_block will call the order 12 page. > > > By default PS3 uses 4K virtual pages, and 16M linear pages. > > > > Is it really correct value for vmemmap population? > > > It seems vmemmap needs linear pages, so I think it is ok. Oh, I see. Sorry for noise. Bye. -- Yasunori Goto -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Yasunori Goto wrote: On Thu, 6 Dec 2007, Geert Uytterhoeven wrote: On Thu, 6 Dec 2007, Yasunori Goto wrote: I'll try Milton's suggestion to pre-allocate the memory early. It seems that should work as long as nothing else before the hot-plug mem is added needs a large chunk. Hello. Geoff-san. Sorry for late response. Could you tell me the value of the following page_size calculation in vmemmap_populate()? I think this page_size may be too big value. -- int __meminit vmemmap_populate(struct page *start_page, unsigned long nr_pages, int node) : : unsigned long page_size = 1 mmu_psize_defs[mmu_linear_psize].shift; : --- 16 MiB of course. 16 MiB is not page size. It is section size. IIRC, powerpc's page size must be 4K (or 64K). If page size is 4k, vmemmap_alloc_block will call the order 12 page. By default PS3 uses 4K virtual pages, and 16M linear pages. Is it really correct value for vmemmap population? It seems vmemmap needs linear pages, so I think it is ok. Oh, I see. Sorry for noise. Bye. -- Yasunori Goto -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On 12/05/2007 10:09 PM, Yasunori Goto wrote: >> I'll try Milton's suggestion to pre-allocate the memory early. It seems >> that should work as long as nothing else before the hot-plug mem is added >> needs a large chunk. > > (However, I think Milton-san's suggestion is very desirable. > If preallocation of hotadd works on ia64 too, I'm very glad.) As it turns out, preallocation is not a such a good solution I think because in the general case the system may need many allocations to support the added memory, so it would be difficult to know how much pre-allocated memory is needed. I think a preferable solution is to use memory from the newly added region. I don't plan to work on a pre-allocation method. I think I can free up sufficient memory in other ways. -Geoff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Yasunori Goto wrote: >> On Thu, 6 Dec 2007, Geert Uytterhoeven wrote: >> > On Thu, 6 Dec 2007, Yasunori Goto wrote: >> > > > I'll try Milton's suggestion to pre-allocate the memory early. It >> > > > seems >> > > > that should work as long as nothing else before the hot-plug mem is >> > > > added >> > > > needs a large chunk. >> > > >> > > Hello. Geoff-san. Sorry for late response. >> > > >> > > Could you tell me the value of the following page_size calculation >> > > in vmemmap_populate()? I think this page_size may be too big value. >> > > >> > > -- >> > > int __meminit vmemmap_populate(struct page *start_page, >> > >unsigned long nr_pages, int node) >> > >: >> > >: >> > > unsigned long page_size = 1 << >> > > mmu_psize_defs[mmu_linear_psize].shift; >> > >: >> > > --- >> >> 16 MiB of course. > > 16 MiB is not page size. It is "section size". > IIRC, powerpc's page size must be 4K (or 64K). > If page size is 4k, vmemmap_alloc_block will call the order 12 page. By default PS3 uses 4K virtual pages, and 16M linear pages. > Is it really correct value for vmemmap population? It seems vmemmap needs linear pages, so I think it is ok. >> PS3 initially starts with 128 MiB. >> Later hotplug is used to add the remaining memory (96 or 112 MIB, IIRC). > > Ok. > Then, add_memory() must be called 6 or 7 times for each sections. Yes, I call add_memory() once, then it in turn calls sparse_add_one_section() 7 times. -Geoff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On 12/05/2007 10:09 PM, Yasunori Goto wrote: I'll try Milton's suggestion to pre-allocate the memory early. It seems that should work as long as nothing else before the hot-plug mem is added needs a large chunk. (However, I think Milton-san's suggestion is very desirable. If preallocation of hotadd works on ia64 too, I'm very glad.) As it turns out, preallocation is not a such a good solution I think because in the general case the system may need many allocations to support the added memory, so it would be difficult to know how much pre-allocated memory is needed. I think a preferable solution is to use memory from the newly added region. I don't plan to work on a pre-allocation method. I think I can free up sufficient memory in other ways. -Geoff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Yasunori Goto wrote: On Thu, 6 Dec 2007, Geert Uytterhoeven wrote: On Thu, 6 Dec 2007, Yasunori Goto wrote: I'll try Milton's suggestion to pre-allocate the memory early. It seems that should work as long as nothing else before the hot-plug mem is added needs a large chunk. Hello. Geoff-san. Sorry for late response. Could you tell me the value of the following page_size calculation in vmemmap_populate()? I think this page_size may be too big value. -- int __meminit vmemmap_populate(struct page *start_page, unsigned long nr_pages, int node) : : unsigned long page_size = 1 mmu_psize_defs[mmu_linear_psize].shift; : --- 16 MiB of course. 16 MiB is not page size. It is section size. IIRC, powerpc's page size must be 4K (or 64K). If page size is 4k, vmemmap_alloc_block will call the order 12 page. By default PS3 uses 4K virtual pages, and 16M linear pages. Is it really correct value for vmemmap population? It seems vmemmap needs linear pages, so I think it is ok. PS3 initially starts with 128 MiB. Later hotplug is used to add the remaining memory (96 or 112 MIB, IIRC). Ok. Then, add_memory() must be called 6 or 7 times for each sections. Yes, I call add_memory() once, then it in turn calls sparse_add_one_section() 7 times. -Geoff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Geert Uytterhoeven wrote: > On Wed, 5 Dec 2007, Geoff Levand wrote: >> Andrew Morton wrote: >> > On Wed, 5 Dec 2007 10:52:48 +0100 (CET) >> > Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: >> > >> >> >> >> Subject: sparsemem: sparse_add_one_section() may fail to allocate memory >> >> >> >> sparsemem: sparse_add_one_section() may fail to allocate memory, and must >> >> check >> >> whether the allocation succeeded before proceeding to touch the allocated >> >> memory. >> >> >> >> From: Geert Uytterhoeven <[EMAIL PROTECTED]> >> >> >> >> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> >> >> --- >> >> FIXME There are still some possible memory leaks in >> >> sparse_add_one_section(): >> >> - usemap is never deallocated >> >> - __kfree_section_memmap() is a not yet implemented dummy >> > >> > I already had >> > >> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch >> > and >> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch >> > >> > queued. Do they fix the problem, and should they be merged in 2.6.24? >> >> No, a quick test shows it just panics in a different place. Geert's >> patch does also. > > What do you mean, that it still paniced after my patch? > > The kernel did boot succesfully for me when passing ps3fb=48M. Userspace saw > 58 > MiB (128 MiB - kernelsize - 48 MiB(ps3fb)). > > I did not try kexec, though. On looking at it, your patch should have worked, so I guess I didn't boot the correct image, or something like that. Sorry. -Geoff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
> On Thu, 6 Dec 2007, Geert Uytterhoeven wrote: > > On Thu, 6 Dec 2007, Yasunori Goto wrote: > > > > I'll try Milton's suggestion to pre-allocate the memory early. It seems > > > > that should work as long as nothing else before the hot-plug mem is > > > > added > > > > needs a large chunk. > > > > > > Hello. Geoff-san. Sorry for late response. > > > > > > Could you tell me the value of the following page_size calculation > > > in vmemmap_populate()? I think this page_size may be too big value. > > > > > > -- > > > int __meminit vmemmap_populate(struct page *start_page, > > >unsigned long nr_pages, int node) > > >: > > >: > > > unsigned long page_size = 1 << > > > mmu_psize_defs[mmu_linear_psize].shift; > > >: > > > --- > > > > 24 MiB > > Bummer, messing up bits and MiB. > > 16 MiB of course. 16 MiB is not page size. It is "section size". IIRC, powerpc's page size must be 4K (or 64K). If page size is 4k, vmemmap_alloc_block will call the order 12 page. Is it really correct value for vmemmap population? > PS3 initially starts with 128 MiB. > Later hotplug is used to add the remaining memory (96 or 112 MIB, IIRC). Ok. Then, add_memory() must be called 6 or 7 times for each sections. Thanks. -- Yasunori Goto -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Thu, 6 Dec 2007, Geert Uytterhoeven wrote: > On Thu, 6 Dec 2007, Yasunori Goto wrote: > > > I'll try Milton's suggestion to pre-allocate the memory early. It seems > > > that should work as long as nothing else before the hot-plug mem is added > > > needs a large chunk. > > > > Hello. Geoff-san. Sorry for late response. > > > > Could you tell me the value of the following page_size calculation > > in vmemmap_populate()? I think this page_size may be too big value. > > > > -- > > int __meminit vmemmap_populate(struct page *start_page, > >unsigned long nr_pages, int node) > >: > >: > > unsigned long page_size = 1 << > > mmu_psize_defs[mmu_linear_psize].shift; > >: > > --- > > 24 MiB Bummer, messing up bits and MiB. 16 MiB of course. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Thu, 6 Dec 2007, Yasunori Goto wrote: > > I'll try Milton's suggestion to pre-allocate the memory early. It seems > > that should work as long as nothing else before the hot-plug mem is added > > needs a large chunk. > > Hello. Geoff-san. Sorry for late response. > > Could you tell me the value of the following page_size calculation > in vmemmap_populate()? I think this page_size may be too big value. > > -- > int __meminit vmemmap_populate(struct page *start_page, >unsigned long nr_pages, int node) >: >: > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift; >: > --- 24 MiB > In addition, I remember that current add_memory() is designed for > only 1 section's addition. (See: memory_probe_store() and > sparse_mem_map_populate(). > they require only for 1 section's mem_map by specifing > PAGES_PER_SECTION.) > The 1 section size for normal powerpc box is only 16MB. > (IA64 -> 1GB, x86-64 -> 128MB). > > But, if my understanding is correct, PS3's add_memory() requires all > of total memory. I'm afraid something other problems might be hidden > in this issue yet. > > (However, I think Milton-san's suggestion is very desirable. > If preallocation of hotadd works on ia64 too, I'm very glad.) PS3 initially starts with 128 MiB. Later hotplug is used to add the remaining memory (96 or 112 MIB, IIRC). With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Thu, 6 Dec 2007, Geert Uytterhoeven wrote: On Thu, 6 Dec 2007, Yasunori Goto wrote: I'll try Milton's suggestion to pre-allocate the memory early. It seems that should work as long as nothing else before the hot-plug mem is added needs a large chunk. Hello. Geoff-san. Sorry for late response. Could you tell me the value of the following page_size calculation in vmemmap_populate()? I think this page_size may be too big value. -- int __meminit vmemmap_populate(struct page *start_page, unsigned long nr_pages, int node) : : unsigned long page_size = 1 mmu_psize_defs[mmu_linear_psize].shift; : --- 24 MiB Bummer, messing up bits and MiB. 16 MiB of course. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Thu, 6 Dec 2007, Yasunori Goto wrote: I'll try Milton's suggestion to pre-allocate the memory early. It seems that should work as long as nothing else before the hot-plug mem is added needs a large chunk. Hello. Geoff-san. Sorry for late response. Could you tell me the value of the following page_size calculation in vmemmap_populate()? I think this page_size may be too big value. -- int __meminit vmemmap_populate(struct page *start_page, unsigned long nr_pages, int node) : : unsigned long page_size = 1 mmu_psize_defs[mmu_linear_psize].shift; : --- 24 MiB In addition, I remember that current add_memory() is designed for only 1 section's addition. (See: memory_probe_store() and sparse_mem_map_populate(). they require only for 1 section's mem_map by specifing PAGES_PER_SECTION.) The 1 section size for normal powerpc box is only 16MB. (IA64 - 1GB, x86-64 - 128MB). But, if my understanding is correct, PS3's add_memory() requires all of total memory. I'm afraid something other problems might be hidden in this issue yet. (However, I think Milton-san's suggestion is very desirable. If preallocation of hotadd works on ia64 too, I'm very glad.) PS3 initially starts with 128 MiB. Later hotplug is used to add the remaining memory (96 or 112 MIB, IIRC). With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Thu, 6 Dec 2007, Geert Uytterhoeven wrote: On Thu, 6 Dec 2007, Yasunori Goto wrote: I'll try Milton's suggestion to pre-allocate the memory early. It seems that should work as long as nothing else before the hot-plug mem is added needs a large chunk. Hello. Geoff-san. Sorry for late response. Could you tell me the value of the following page_size calculation in vmemmap_populate()? I think this page_size may be too big value. -- int __meminit vmemmap_populate(struct page *start_page, unsigned long nr_pages, int node) : : unsigned long page_size = 1 mmu_psize_defs[mmu_linear_psize].shift; : --- 24 MiB Bummer, messing up bits and MiB. 16 MiB of course. 16 MiB is not page size. It is section size. IIRC, powerpc's page size must be 4K (or 64K). If page size is 4k, vmemmap_alloc_block will call the order 12 page. Is it really correct value for vmemmap population? PS3 initially starts with 128 MiB. Later hotplug is used to add the remaining memory (96 or 112 MIB, IIRC). Ok. Then, add_memory() must be called 6 or 7 times for each sections. Thanks. -- Yasunori Goto -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Geert Uytterhoeven wrote: On Wed, 5 Dec 2007, Geoff Levand wrote: Andrew Morton wrote: On Wed, 5 Dec 2007 10:52:48 +0100 (CET) Geert Uytterhoeven [EMAIL PROTECTED] wrote: Subject: sparsemem: sparse_add_one_section() may fail to allocate memory sparsemem: sparse_add_one_section() may fail to allocate memory, and must check whether the allocation succeeded before proceeding to touch the allocated memory. From: Geert Uytterhoeven [EMAIL PROTECTED] Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- FIXME There are still some possible memory leaks in sparse_add_one_section(): - usemap is never deallocated - __kfree_section_memmap() is a not yet implemented dummy I already had ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch and ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch queued. Do they fix the problem, and should they be merged in 2.6.24? No, a quick test shows it just panics in a different place. Geert's patch does also. What do you mean, that it still paniced after my patch? The kernel did boot succesfully for me when passing ps3fb=48M. Userspace saw 58 MiB (128 MiB - kernelsize - 48 MiB(ps3fb)). I did not try kexec, though. On looking at it, your patch should have worked, so I guess I didn't boot the correct image, or something like that. Sorry. -Geoff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Wed, 5 Dec 2007, Geoff Levand wrote: > Andrew Morton wrote: > > On Wed, 5 Dec 2007 10:52:48 +0100 (CET) > > Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > > > >> > >> Subject: sparsemem: sparse_add_one_section() may fail to allocate memory > >> > >> sparsemem: sparse_add_one_section() may fail to allocate memory, and must > >> check > >> whether the allocation succeeded before proceeding to touch the allocated > >> memory. > >> > >> From: Geert Uytterhoeven <[EMAIL PROTECTED]> > >> > >> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> > >> --- > >> FIXME There are still some possible memory leaks in > >> sparse_add_one_section(): > >> - usemap is never deallocated > >> - __kfree_section_memmap() is a not yet implemented dummy > > > > I already had > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch > > and > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch > > > > queued. Do they fix the problem, and should they be merged in 2.6.24? > > No, a quick test shows it just panics in a different place. Geert's > patch does also. What do you mean, that it still paniced after my patch? The kernel did boot succesfully for me when passing ps3fb=48M. Userspace saw 58 MiB (128 MiB - kernelsize - 48 MiB(ps3fb)). I did not try kexec, though. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
> I'll try Milton's suggestion to pre-allocate the memory early. It seems > that should work as long as nothing else before the hot-plug mem is added > needs a large chunk. Hello. Geoff-san. Sorry for late response. Could you tell me the value of the following page_size calculation in vmemmap_populate()? I think this page_size may be too big value. -- int __meminit vmemmap_populate(struct page *start_page, unsigned long nr_pages, int node) : : unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift; : --- In addition, I remember that current add_memory() is designed for only 1 section's addition. (See: memory_probe_store() and sparse_mem_map_populate(). they require only for 1 section's mem_map by specifing PAGES_PER_SECTION.) The 1 section size for normal powerpc box is only 16MB. (IA64 -> 1GB, x86-64 -> 128MB). But, if my understanding is correct, PS3's add_memory() requires all of total memory. I'm afraid something other problems might be hidden in this issue yet. (However, I think Milton-san's suggestion is very desirable. If preallocation of hotadd works on ia64 too, I'm very glad.) Thanks. -- Yasunori Goto -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Andrew Morton wrote: > On Wed, 5 Dec 2007 10:52:48 +0100 (CET) > Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > >> >> Subject: sparsemem: sparse_add_one_section() may fail to allocate memory >> >> sparsemem: sparse_add_one_section() may fail to allocate memory, and must >> check >> whether the allocation succeeded before proceeding to touch the allocated >> memory. >> >> From: Geert Uytterhoeven <[EMAIL PROTECTED]> >> >> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> >> --- >> FIXME There are still some possible memory leaks in sparse_add_one_section(): >> - usemap is never deallocated >> - __kfree_section_memmap() is a not yet implemented dummy > > I already had > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch This one has an error in it. A patch to fix it is below. > and > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch > > queued. Do they fix the problem, and should they be merged in 2.6.24? These two plus my fix below allow the hot plug add_memory() call to fail gracefully and for the platform code to continue to boot on the 128MB of boot mem. With ps3_defconfig the condition is only hit by the second stage kexec'ed (kboot) kernel, which is not generally built by end users, but there is a chance this condition would be hit by custom kernel config, so I think they should go in for 2.6.24. I'll continue to work on a fix for the memory allocation failure. -Geoff -- Subject: sparsemem: Fix sparse_index_init return check sparse_index_init() returns -EEXIST to indicate the index has already been created. Exclude this from the error check on the return value. Signed-off-by: Geoff Levand <[EMAIL PROTECTED]> --- mm/sparse.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/sparse.c +++ b/mm/sparse.c @@ -392,7 +392,7 @@ int sparse_add_one_section(struct zone * * plus, it does a kmalloc */ ret = sparse_index_init(section_nr, pgdat->node_id); - if (ret < 0) + if (ret < 0 && ret != -EEXIST) return ret; memmap = kmalloc_section_memmap(section_nr, pgdat->node_id, nr_pages); if (!memmap) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Andrew Morton wrote: > On Wed, 5 Dec 2007 10:52:48 +0100 (CET) > Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > >> >> Subject: sparsemem: sparse_add_one_section() may fail to allocate memory >> >> sparsemem: sparse_add_one_section() may fail to allocate memory, and must >> check >> whether the allocation succeeded before proceeding to touch the allocated >> memory. >> >> From: Geert Uytterhoeven <[EMAIL PROTECTED]> >> >> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> >> --- >> FIXME There are still some possible memory leaks in sparse_add_one_section(): >> - usemap is never deallocated >> - __kfree_section_memmap() is a not yet implemented dummy > > I already had > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch > and > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch > > queued. Do they fix the problem, and should they be merged in 2.6.24? No, a quick test shows it just panics in a different place. Geert's patch does also. I'll try Milton's suggestion to pre-allocate the memory early. It seems that should work as long as nothing else before the hot-plug mem is added needs a large chunk. -Geoff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Wed, 5 Dec 2007 10:52:48 +0100 (CET) Geert Uytterhoeven <[EMAIL PROTECTED]> wrote: > > Subject: sparsemem: sparse_add_one_section() may fail to allocate memory > > sparsemem: sparse_add_one_section() may fail to allocate memory, and must > check > whether the allocation succeeded before proceeding to touch the allocated > memory. > > From: Geert Uytterhoeven <[EMAIL PROTECTED]> > > Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> > --- > FIXME There are still some possible memory leaks in sparse_add_one_section(): > - usemap is never deallocated > - __kfree_section_memmap() is a not yet implemented dummy I already had ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch and ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch queued. Do they fix the problem, and should they be merged in 2.6.24? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Mon, 3 Dec 2007, Milton Miller wrote: > On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote: > > ps3_mm_add_memory:317: start_addr 74032000h, start_pfn 74032h, > > nr_pages 17000h > > <4>swapper: page allocation failure. order:12, mode:0x80d0 > > Call Trace: > > [c6047820] [c000e700] .show_stack+0x68/0x1b0 (unreliable) > > [c60478c0] [c0089eb4] .__alloc_pages+0x358/0x3ac > > [c60479b0] [c00a3964] .vmemmap_alloc_block+0x6c/0xf4 > > [c6047a40] [c0026544] .vmemmap_populate+0x74/0x100 > > [c6047ae0] [c00a385c] .sparse_mem_map_populate+0x38/0x5c > > [c6047b70] [c00a36e4] .sparse_add_one_section+0x64/0x128 > > [c6047c20] [c00aa74c] .__add_pages+0xac/0x18c > > [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 > > [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 > > [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 > > [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 > > [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 > > Mem-info: > > DMA per-cpu: > > CPU0: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: > > 0 > > CPU1: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: > > 0 > > Active:0 inactive:0 dirty:0 writeback:0 unstable:0 > > free:18094 slab:122 mapped:0 pagetables:0 bounce:0 > > DMA free:72376kB min:0kB low:0kB high:0kB active:0kB inactive:0kB > > present:129280kB pages_scanned:0 all_unreclaimable? no > > lowmem_reserve[]: 0 0 0 > > DMA: 8*4kB 5*8kB 5*16kB 7*32kB 3*64kB 5*128kB 4*256kB 3*512kB 5*1024kB > > 3*2048kB 4*4096kB 5*8192kB 0*16384kB = 72376kB > > Swap cache: add 0, delete 0, find 0/0, race 0+0 > > Free swap = 0kB > > Total swap = 0kB > > Free swap:0kB > > 32768 pages of RAM > > 10403 reserved pages > > 0 pages shared > > 0 pages swap cached > > The kernel is using 16MB pages for the linear mapping and, since its in the > same region, the sparse virtural memmap. PS3 uses hotplug for all most all of > its memory. In this case, its trying to allocate an additional page to cover > a new region of the memory map. However, the initial 128 MB is fragmented, > we have 8 8M chunks but no 16MB ones. > > > <1>Unable to handle kernel paging request for data at address > > 0xcf0001960b10 > > <1>Faulting instruction address: 0xc0087340 > > Oops: Kernel access of bad area, sig: 11 [#1] > > SMP NR_CPUS=2 PS3 > > Modules linked in: > > NIP: c0087340 LR: c008733c CTR: > > REGS: c6047900 TRAP: 0300 Not tainted > > (2.6.24-rc3-ps3-linux-dev-g91428d55-dirty) > > MSR: 80008032 CR: 2200 XER: > > DAR: cf0001960b10, DSISR: 4200 > > TASK = c6041080[1] 'swapper' THREAD: c6044000 CPU: 1 > > <6>GPR00: c6047b80 c052b410 > > c6001b40 > > <6>GPR04: 0001 0003 0008 > > > > <6>GPR08: 0002 cf0001960b08 c6051240 > > 0003 > > <6>GPR12: 0003 c0484080 100d > > 00bc5000 > > <6>GPR16: 07fff000 0001 100a > > 100d > > <6>GPR20: 100df628 100df458 > > 100df678 > > <6>GPR24: 00740336 c0492c00 > > 0001 > > <6>GPR28: 000740325000 000740324924 c04ce9a8 > > cf0001960ae0 > > NIP [c0087340] .memmap_init_zone+0xf0/0x134 > > LR [c008733c] .memmap_init_zone+0xec/0x134 > > Call Trace: > > [c6047b80] [c01da530] .add_memory_block+0xd8/0x108 > > (unreliable) > > [c6047c20] [c00aa7ac] .__add_pages+0x10c/0x18c > > [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 > > [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 > > [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 > > [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 > > [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 > > Instruction dump: > > 901f000c 38000400 7d20f8a8 7d290378 7d20f9ad 40a2fff4 7ba00521 7fe3fb78 > > 3882 41820008 4b0d 393f0028 f93f0028 3bbd0001 3bff0038 > > <0>Kernel panic - not syncing: Attempted to kill init! > > Instead of detecting the fail and aborting the add, we proceed to dereference > the memory map. sparse_add_one_section() does: memmap = kmalloc_section_memmap(section_nr, pgdat->node_id, nr_pages); but doesn't check whether the allocation succeeded. Patch to make it continue booting below (but this doesn't fix the issue that you need 16 MiB of contiguous memory before you can add a new memory region). Subject: sparsemem: sparse_add_one_section() may fail to allocate memory
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Mon, 3 Dec 2007, Milton Miller wrote: On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote: ps3_mm_add_memory:317: start_addr 74032000h, start_pfn 74032h, nr_pages 17000h 4swapper: page allocation failure. order:12, mode:0x80d0 Call Trace: [c6047820] [c000e700] .show_stack+0x68/0x1b0 (unreliable) [c60478c0] [c0089eb4] .__alloc_pages+0x358/0x3ac [c60479b0] [c00a3964] .vmemmap_alloc_block+0x6c/0xf4 [c6047a40] [c0026544] .vmemmap_populate+0x74/0x100 [c6047ae0] [c00a385c] .sparse_mem_map_populate+0x38/0x5c [c6047b70] [c00a36e4] .sparse_add_one_section+0x64/0x128 [c6047c20] [c00aa74c] .__add_pages+0xac/0x18c [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 Mem-info: DMA per-cpu: CPU0: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0 CPU1: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0 Active:0 inactive:0 dirty:0 writeback:0 unstable:0 free:18094 slab:122 mapped:0 pagetables:0 bounce:0 DMA free:72376kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:129280kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 8*4kB 5*8kB 5*16kB 7*32kB 3*64kB 5*128kB 4*256kB 3*512kB 5*1024kB 3*2048kB 4*4096kB 5*8192kB 0*16384kB = 72376kB Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap = 0kB Total swap = 0kB Free swap:0kB 32768 pages of RAM 10403 reserved pages 0 pages shared 0 pages swap cached The kernel is using 16MB pages for the linear mapping and, since its in the same region, the sparse virtural memmap. PS3 uses hotplug for all most all of its memory. In this case, its trying to allocate an additional page to cover a new region of the memory map. However, the initial 128 MB is fragmented, we have 8 8M chunks but no 16MB ones. 1Unable to handle kernel paging request for data at address 0xcf0001960b10 1Faulting instruction address: 0xc0087340 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 PS3 Modules linked in: NIP: c0087340 LR: c008733c CTR: REGS: c6047900 TRAP: 0300 Not tainted (2.6.24-rc3-ps3-linux-dev-g91428d55-dirty) MSR: 80008032 EE,IR,DR CR: 2200 XER: DAR: cf0001960b10, DSISR: 4200 TASK = c6041080[1] 'swapper' THREAD: c6044000 CPU: 1 6GPR00: c6047b80 c052b410 c6001b40 6GPR04: 0001 0003 0008 6GPR08: 0002 cf0001960b08 c6051240 0003 6GPR12: 0003 c0484080 100d 00bc5000 6GPR16: 07fff000 0001 100a 100d 6GPR20: 100df628 100df458 100df678 6GPR24: 00740336 c0492c00 0001 6GPR28: 000740325000 000740324924 c04ce9a8 cf0001960ae0 NIP [c0087340] .memmap_init_zone+0xf0/0x134 LR [c008733c] .memmap_init_zone+0xec/0x134 Call Trace: [c6047b80] [c01da530] .add_memory_block+0xd8/0x108 (unreliable) [c6047c20] [c00aa7ac] .__add_pages+0x10c/0x18c [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 Instruction dump: 901f000c 38000400 7d20f8a8 7d290378 7d20f9ad 40a2fff4 7ba00521 7fe3fb78 3882 41820008 4b0d 393f0028 f9290008 f93f0028 3bbd0001 3bff0038 0Kernel panic - not syncing: Attempted to kill init! Instead of detecting the fail and aborting the add, we proceed to dereference the memory map. sparse_add_one_section() does: memmap = kmalloc_section_memmap(section_nr, pgdat-node_id, nr_pages); but doesn't check whether the allocation succeeded. Patch to make it continue booting below (but this doesn't fix the issue that you need 16 MiB of contiguous memory before you can add a new memory region). Subject: sparsemem: sparse_add_one_section() may fail to allocate memory sparsemem: sparse_add_one_section() may fail to allocate memory, and must check whether the allocation succeeded before proceeding to touch the allocated memory. From: Geert
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Wed, 5 Dec 2007 10:52:48 +0100 (CET) Geert Uytterhoeven [EMAIL PROTECTED] wrote: Subject: sparsemem: sparse_add_one_section() may fail to allocate memory sparsemem: sparse_add_one_section() may fail to allocate memory, and must check whether the allocation succeeded before proceeding to touch the allocated memory. From: Geert Uytterhoeven [EMAIL PROTECTED] Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- FIXME There are still some possible memory leaks in sparse_add_one_section(): - usemap is never deallocated - __kfree_section_memmap() is a not yet implemented dummy I already had ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch and ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch queued. Do they fix the problem, and should they be merged in 2.6.24? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Andrew Morton wrote: On Wed, 5 Dec 2007 10:52:48 +0100 (CET) Geert Uytterhoeven [EMAIL PROTECTED] wrote: Subject: sparsemem: sparse_add_one_section() may fail to allocate memory sparsemem: sparse_add_one_section() may fail to allocate memory, and must check whether the allocation succeeded before proceeding to touch the allocated memory. From: Geert Uytterhoeven [EMAIL PROTECTED] Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- FIXME There are still some possible memory leaks in sparse_add_one_section(): - usemap is never deallocated - __kfree_section_memmap() is a not yet implemented dummy I already had ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch and ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch queued. Do they fix the problem, and should they be merged in 2.6.24? No, a quick test shows it just panics in a different place. Geert's patch does also. I'll try Milton's suggestion to pre-allocate the memory early. It seems that should work as long as nothing else before the hot-plug mem is added needs a large chunk. -Geoff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Andrew Morton wrote: On Wed, 5 Dec 2007 10:52:48 +0100 (CET) Geert Uytterhoeven [EMAIL PROTECTED] wrote: Subject: sparsemem: sparse_add_one_section() may fail to allocate memory sparsemem: sparse_add_one_section() may fail to allocate memory, and must check whether the allocation succeeded before proceeding to touch the allocated memory. From: Geert Uytterhoeven [EMAIL PROTECTED] Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- FIXME There are still some possible memory leaks in sparse_add_one_section(): - usemap is never deallocated - __kfree_section_memmap() is a not yet implemented dummy I already had ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch This one has an error in it. A patch to fix it is below. and ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch queued. Do they fix the problem, and should they be merged in 2.6.24? These two plus my fix below allow the hot plug add_memory() call to fail gracefully and for the platform code to continue to boot on the 128MB of boot mem. With ps3_defconfig the condition is only hit by the second stage kexec'ed (kboot) kernel, which is not generally built by end users, but there is a chance this condition would be hit by custom kernel config, so I think they should go in for 2.6.24. I'll continue to work on a fix for the memory allocation failure. -Geoff -- Subject: sparsemem: Fix sparse_index_init return check sparse_index_init() returns -EEXIST to indicate the index has already been created. Exclude this from the error check on the return value. Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- mm/sparse.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/sparse.c +++ b/mm/sparse.c @@ -392,7 +392,7 @@ int sparse_add_one_section(struct zone * * plus, it does a kmalloc */ ret = sparse_index_init(section_nr, pgdat-node_id); - if (ret 0) + if (ret 0 ret != -EEXIST) return ret; memmap = kmalloc_section_memmap(section_nr, pgdat-node_id, nr_pages); if (!memmap) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
I'll try Milton's suggestion to pre-allocate the memory early. It seems that should work as long as nothing else before the hot-plug mem is added needs a large chunk. Hello. Geoff-san. Sorry for late response. Could you tell me the value of the following page_size calculation in vmemmap_populate()? I think this page_size may be too big value. -- int __meminit vmemmap_populate(struct page *start_page, unsigned long nr_pages, int node) : : unsigned long page_size = 1 mmu_psize_defs[mmu_linear_psize].shift; : --- In addition, I remember that current add_memory() is designed for only 1 section's addition. (See: memory_probe_store() and sparse_mem_map_populate(). they require only for 1 section's mem_map by specifing PAGES_PER_SECTION.) The 1 section size for normal powerpc box is only 16MB. (IA64 - 1GB, x86-64 - 128MB). But, if my understanding is correct, PS3's add_memory() requires all of total memory. I'm afraid something other problems might be hidden in this issue yet. (However, I think Milton-san's suggestion is very desirable. If preallocation of hotadd works on ia64 too, I'm very glad.) Thanks. -- Yasunori Goto -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Wed, 5 Dec 2007, Geoff Levand wrote: Andrew Morton wrote: On Wed, 5 Dec 2007 10:52:48 +0100 (CET) Geert Uytterhoeven [EMAIL PROTECTED] wrote: Subject: sparsemem: sparse_add_one_section() may fail to allocate memory sparsemem: sparse_add_one_section() may fail to allocate memory, and must check whether the allocation succeeded before proceeding to touch the allocated memory. From: Geert Uytterhoeven [EMAIL PROTECTED] Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED] --- FIXME There are still some possible memory leaks in sparse_add_one_section(): - usemap is never deallocated - __kfree_section_memmap() is a not yet implemented dummy I already had ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-improve-the-error-handling-for-sparse_add_one_section.patch and ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc4/2.6.24-rc4-mm1/broken-out/mm-sparsec-check-the-return-value-of-sparse_index_alloc.patch queued. Do they fix the problem, and should they be merged in 2.6.24? No, a quick test shows it just panics in a different place. Geert's patch does also. What do you mean, that it still paniced after my patch? The kernel did boot succesfully for me when passing ps3fb=48M. Userspace saw 58 MiB (128 MiB - kernelsize - 48 MiB(ps3fb)). I did not try kexec, though. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Geert Uytterhoeven wrote: > On Mon, 3 Dec 2007, Milton Miller wrote: >> Chris, as you can see, PS3 needs to allocate 1/8th of total initial memory to >> add any more memory. Geoff, can you predict what linear address the >> additional memory will occupy? Judging from the attempted address toa add, >> maybe not. If not, my only thought is to pre-reserve an additional page and >> consume it on the first add. Additional adds will likely draw from the >> first >> added region, pinning. > > To me it sounds a bit strange that hotplug memory relies on having huge > contiguous blocks of memory available. If this isn't done very early in the > boot process, changes are high it will fail. > > Would it be possible to allocate the memory from the newly added block, which > is guaranteed to be unfragmented? Yes, this sounds like a cleaner solution than pre-allocating, as the memory is there and its properties are known. -Geoff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Milton Miller wrote: > On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote: > >> Hi. >> >> I'm finding that recently kexec'ed kernels on PS3 will >> panic on startup. It seems the trouble was introduced >> with the ppc64 SPARSEMEM_VMEMMAP support. The problem >> is the same when starting either new or old kernels: >> >> 2.6.24 -> 2.6.23 ok >> 2.6.24 -> 2.6.23 panic >> 2.6.24 -> 2.6.24 panic > > I'm not sure I completely follow this. What is the difference between > 1 and 2 ? Sorry, '2.6.23 -> 2.6.24 ok', but it really doesn't have much meaning, considering what the actual problem is. > Also, you are talking about starting with kexec, but I > don't see how that fits in the failure you have below. I think just buy chance the kexec'ed kernel hits because the 2.6.24 kernel is just at the point of hitting the condition, and the memory usage of the kexe'ed kernel hits. If I just reduce the size of the kernel a small amount kexec works ok, and as Geert pointed out, if you increase the size of the first stage kernel it will hit it. >> DMA free:72376kB min:0kB low:0kB high:0kB active:0kB inactive:0kB >> present:129280kB pages_scanned:0 all_unreclaimable? no >> lowmem_reserve[]: 0 0 0 >> DMA: 8*4kB 5*8kB 5*16kB 7*32kB 3*64kB 5*128kB 4*256kB 3*512kB 5*1024kB >> 3*2048kB 4*4096kB 5*8192kB 0*16384kB = 72376kB >> Swap cache: add 0, delete 0, find 0/0, race 0+0 >> Free swap = 0kB >> Total swap = 0kB >> Free swap:0kB >> 32768 pages of RAM >> 10403 reserved pages >> 0 pages shared >> 0 pages swap cached > > The kernel is using 16MB pages for the linear mapping and, since its in > the same region, the sparse virtural memmap. PS3 uses hotplug for all > most all of its memory. In this case, its trying to allocate an > additional page to cover a new region of the memory map. However, the > initial 128 MB is fragmented, we have 8 8M chunks but no 16MB ones. Yes, I see this is the problem. -Geoff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Mon, 3 Dec 2007, Milton Miller wrote: > On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote: > > I'm finding that recently kexec'ed kernels on PS3 will > > panic on startup. It seems the trouble was introduced > > with the ppc64 SPARSEMEM_VMEMMAP support. The problem > > is the same when starting either new or old kernels: > > > > 2.6.24 -> 2.6.23 ok > > 2.6.24 -> 2.6.23 panic > > 2.6.24 -> 2.6.24 panic > > I'm not sure I completely follow this. What is the difference between 1 and 2 > ? Also, you are talking about starting with kexec, but I don't see how that I think the first line should be `2.6.23 -> 2.6.23' (i.e. a 2.6.23 kernel kexec's a 2.6.24(-rc) kernel). > fits in the failure you have below. In other words, there may be more than > one failure. But I can talk a bit about the scope of the problem in the > current traceback. The problem can be triggered in other ways, e.g. playing with the ps3fb=xxxM parameter, which specifies how much memory is reserved for ps3fb. With 2.6.23, I can boot with `ps3fb=48M'. Very early in 2.6.24-rc*, this changed. 2.6.24 seems to be easier fragmented than 2.6.23. > > These are the commits that seem to introduce the problem: > > > > d29eff7bca60c9ee401d691d4562a4abca8de543 ppc64: SPARSEMEM_VMEMMAP suppor > > 8f6aac419bd590f535fb110875a51f7db2b62b5b Generic Virtual Memmap support > > for SPARSEMEM > > > > > > Below is a startup dump. Any help in finding the problem > > would be appreciated. > > > > -Geoff > > > > > > > > ps3_mm_add_memory:317: start_addr 74032000h, start_pfn 74032h, > > nr_pages 17000h > > <4>swapper: page allocation failure. order:12, mode:0x80d0 > > Call Trace: > > [c6047820] [c000e700] .show_stack+0x68/0x1b0 (unreliable) > > [c60478c0] [c0089eb4] .__alloc_pages+0x358/0x3ac > > [c60479b0] [c00a3964] .vmemmap_alloc_block+0x6c/0xf4 > > [c6047a40] [c0026544] .vmemmap_populate+0x74/0x100 > > [c6047ae0] [c00a385c] .sparse_mem_map_populate+0x38/0x5c > > [c6047b70] [c00a36e4] .sparse_add_one_section+0x64/0x128 > > [c6047c20] [c00aa74c] .__add_pages+0xac/0x18c > > [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 > > [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 > > [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 > > [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 > > [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 > > Mem-info: > > DMA per-cpu: > > CPU0: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: > > 0 > > CPU1: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: > > 0 > > Active:0 inactive:0 dirty:0 writeback:0 unstable:0 > > free:18094 slab:122 mapped:0 pagetables:0 bounce:0 > > DMA free:72376kB min:0kB low:0kB high:0kB active:0kB inactive:0kB > > present:129280kB pages_scanned:0 all_unreclaimable? no > > lowmem_reserve[]: 0 0 0 > > DMA: 8*4kB 5*8kB 5*16kB 7*32kB 3*64kB 5*128kB 4*256kB 3*512kB 5*1024kB > > 3*2048kB 4*4096kB 5*8192kB 0*16384kB = 72376kB > > Swap cache: add 0, delete 0, find 0/0, race 0+0 > > Free swap = 0kB > > Total swap = 0kB > > Free swap:0kB > > 32768 pages of RAM > > 10403 reserved pages > > 0 pages shared > > 0 pages swap cached > > The kernel is using 16MB pages for the linear mapping and, since its in the > same region, the sparse virtural memmap. PS3 uses hotplug for all most all of > its memory. In this case, its trying to allocate an additional page to cover > a new region of the memory map. However, the initial 128 MB is fragmented, > we have 8 8M chunks but no 16MB ones. > > > <1>Unable to handle kernel paging request for data at address > > 0xcf0001960b10 > > <1>Faulting instruction address: 0xc0087340 > > Oops: Kernel access of bad area, sig: 11 [#1] > > SMP NR_CPUS=2 PS3 > > Modules linked in: > > NIP: c0087340 LR: c008733c CTR: > > REGS: c6047900 TRAP: 0300 Not tainted > > (2.6.24-rc3-ps3-linux-dev-g91428d55-dirty) > > MSR: 80008032 CR: 2200 XER: > > DAR: cf0001960b10, DSISR: 4200 > > TASK = c6041080[1] 'swapper' THREAD: c6044000 CPU: 1 > > <6>GPR00: c6047b80 c052b410 > > c6001b40 > > <6>GPR04: 0001 0003 0008 > > > > <6>GPR08: 0002 cf0001960b08 c6051240 > > 0003 > > <6>GPR12: 0003 c0484080 100d > > 00bc5000 > > <6>GPR16: 07fff000 0001 100a > > 100d > > <6>GPR20: 100df628 100df458 > > 100df678 > > <6>GPR24: 00740336 c0492c00 > > 0001 > > <6>GPR28: 000740325000 000740324924 c04ce9a8 > > cf0001960ae0 > > NIP
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Mon, 3 Dec 2007, Milton Miller wrote: On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote: I'm finding that recently kexec'ed kernels on PS3 will panic on startup. It seems the trouble was introduced with the ppc64 SPARSEMEM_VMEMMAP support. The problem is the same when starting either new or old kernels: 2.6.24 - 2.6.23 ok 2.6.24 - 2.6.23 panic 2.6.24 - 2.6.24 panic I'm not sure I completely follow this. What is the difference between 1 and 2 ? Also, you are talking about starting with kexec, but I don't see how that I think the first line should be `2.6.23 - 2.6.23' (i.e. a 2.6.23 kernel kexec's a 2.6.24(-rc) kernel). fits in the failure you have below. In other words, there may be more than one failure. But I can talk a bit about the scope of the problem in the current traceback. The problem can be triggered in other ways, e.g. playing with the ps3fb=xxxM parameter, which specifies how much memory is reserved for ps3fb. With 2.6.23, I can boot with `ps3fb=48M'. Very early in 2.6.24-rc*, this changed. 2.6.24 seems to be easier fragmented than 2.6.23. These are the commits that seem to introduce the problem: d29eff7bca60c9ee401d691d4562a4abca8de543 ppc64: SPARSEMEM_VMEMMAP suppor 8f6aac419bd590f535fb110875a51f7db2b62b5b Generic Virtual Memmap support for SPARSEMEM Below is a startup dump. Any help in finding the problem would be appreciated. -Geoff ps3_mm_add_memory:317: start_addr 74032000h, start_pfn 74032h, nr_pages 17000h 4swapper: page allocation failure. order:12, mode:0x80d0 Call Trace: [c6047820] [c000e700] .show_stack+0x68/0x1b0 (unreliable) [c60478c0] [c0089eb4] .__alloc_pages+0x358/0x3ac [c60479b0] [c00a3964] .vmemmap_alloc_block+0x6c/0xf4 [c6047a40] [c0026544] .vmemmap_populate+0x74/0x100 [c6047ae0] [c00a385c] .sparse_mem_map_populate+0x38/0x5c [c6047b70] [c00a36e4] .sparse_add_one_section+0x64/0x128 [c6047c20] [c00aa74c] .__add_pages+0xac/0x18c [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 Mem-info: DMA per-cpu: CPU0: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0 CPU1: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0 Active:0 inactive:0 dirty:0 writeback:0 unstable:0 free:18094 slab:122 mapped:0 pagetables:0 bounce:0 DMA free:72376kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:129280kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 8*4kB 5*8kB 5*16kB 7*32kB 3*64kB 5*128kB 4*256kB 3*512kB 5*1024kB 3*2048kB 4*4096kB 5*8192kB 0*16384kB = 72376kB Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap = 0kB Total swap = 0kB Free swap:0kB 32768 pages of RAM 10403 reserved pages 0 pages shared 0 pages swap cached The kernel is using 16MB pages for the linear mapping and, since its in the same region, the sparse virtural memmap. PS3 uses hotplug for all most all of its memory. In this case, its trying to allocate an additional page to cover a new region of the memory map. However, the initial 128 MB is fragmented, we have 8 8M chunks but no 16MB ones. 1Unable to handle kernel paging request for data at address 0xcf0001960b10 1Faulting instruction address: 0xc0087340 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 PS3 Modules linked in: NIP: c0087340 LR: c008733c CTR: REGS: c6047900 TRAP: 0300 Not tainted (2.6.24-rc3-ps3-linux-dev-g91428d55-dirty) MSR: 80008032 EE,IR,DR CR: 2200 XER: DAR: cf0001960b10, DSISR: 4200 TASK = c6041080[1] 'swapper' THREAD: c6044000 CPU: 1 6GPR00: c6047b80 c052b410 c6001b40 6GPR04: 0001 0003 0008 6GPR08: 0002 cf0001960b08 c6051240 0003 6GPR12: 0003 c0484080 100d 00bc5000 6GPR16: 07fff000 0001 100a 100d 6GPR20: 100df628 100df458 100df678 6GPR24: 00740336 c0492c00 0001 6GPR28: 000740325000 000740324924 c04ce9a8 cf0001960ae0 NIP [c0087340] .memmap_init_zone+0xf0/0x134 LR [c008733c] .memmap_init_zone+0xec/0x134 Call Trace: [c6047b80] [c01da530] .add_memory_block+0xd8/0x108 (unreliable)
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Milton Miller wrote: On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote: Hi. I'm finding that recently kexec'ed kernels on PS3 will panic on startup. It seems the trouble was introduced with the ppc64 SPARSEMEM_VMEMMAP support. The problem is the same when starting either new or old kernels: 2.6.24 - 2.6.23 ok 2.6.24 - 2.6.23 panic 2.6.24 - 2.6.24 panic I'm not sure I completely follow this. What is the difference between 1 and 2 ? Sorry, '2.6.23 - 2.6.24 ok', but it really doesn't have much meaning, considering what the actual problem is. Also, you are talking about starting with kexec, but I don't see how that fits in the failure you have below. I think just buy chance the kexec'ed kernel hits because the 2.6.24 kernel is just at the point of hitting the condition, and the memory usage of the kexe'ed kernel hits. If I just reduce the size of the kernel a small amount kexec works ok, and as Geert pointed out, if you increase the size of the first stage kernel it will hit it. DMA free:72376kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:129280kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 8*4kB 5*8kB 5*16kB 7*32kB 3*64kB 5*128kB 4*256kB 3*512kB 5*1024kB 3*2048kB 4*4096kB 5*8192kB 0*16384kB = 72376kB Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap = 0kB Total swap = 0kB Free swap:0kB 32768 pages of RAM 10403 reserved pages 0 pages shared 0 pages swap cached The kernel is using 16MB pages for the linear mapping and, since its in the same region, the sparse virtural memmap. PS3 uses hotplug for all most all of its memory. In this case, its trying to allocate an additional page to cover a new region of the memory map. However, the initial 128 MB is fragmented, we have 8 8M chunks but no 16MB ones. Yes, I see this is the problem. -Geoff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
Geert Uytterhoeven wrote: On Mon, 3 Dec 2007, Milton Miller wrote: Chris, as you can see, PS3 needs to allocate 1/8th of total initial memory to add any more memory. Geoff, can you predict what linear address the additional memory will occupy? Judging from the attempted address toa add, maybe not. If not, my only thought is to pre-reserve an additional page and consume it on the first add. Additional adds will likely draw from the first added region, pinning. To me it sounds a bit strange that hotplug memory relies on having huge contiguous blocks of memory available. If this isn't done very early in the boot process, changes are high it will fail. Would it be possible to allocate the memory from the newly added block, which is guaranteed to be unfragmented? Yes, this sounds like a cleaner solution than pre-allocating, as the memory is there and its properties are known. -Geoff -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote: Hi. I'm finding that recently kexec'ed kernels on PS3 will panic on startup. It seems the trouble was introduced with the ppc64 SPARSEMEM_VMEMMAP support. The problem is the same when starting either new or old kernels: 2.6.24 -> 2.6.23 ok 2.6.24 -> 2.6.23 panic 2.6.24 -> 2.6.24 panic I'm not sure I completely follow this. What is the difference between 1 and 2 ? Also, you are talking about starting with kexec, but I don't see how that fits in the failure you have below. In other words, there may be more than one failure. But I can talk a bit about the scope of the problem in the current traceback. These are the commits that seem to introduce the problem: d29eff7bca60c9ee401d691d4562a4abca8de543 ppc64: SPARSEMEM_VMEMMAP suppor 8f6aac419bd590f535fb110875a51f7db2b62b5b Generic Virtual Memmap support for SPARSEMEM Below is a startup dump. Any help in finding the problem would be appreciated. -Geoff ps3_mm_add_memory:317: start_addr 74032000h, start_pfn 74032h, nr_pages 17000h <4>swapper: page allocation failure. order:12, mode:0x80d0 Call Trace: [c6047820] [c000e700] .show_stack+0x68/0x1b0 (unreliable) [c60478c0] [c0089eb4] .__alloc_pages+0x358/0x3ac [c60479b0] [c00a3964] .vmemmap_alloc_block+0x6c/0xf4 [c6047a40] [c0026544] .vmemmap_populate+0x74/0x100 [c6047ae0] [c00a385c] .sparse_mem_map_populate+0x38/0x5c [c6047b70] [c00a36e4] .sparse_add_one_section+0x64/0x128 [c6047c20] [c00aa74c] .__add_pages+0xac/0x18c [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 Mem-info: DMA per-cpu: CPU0: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0 CPU1: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0 Active:0 inactive:0 dirty:0 writeback:0 unstable:0 free:18094 slab:122 mapped:0 pagetables:0 bounce:0 DMA free:72376kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:129280kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 8*4kB 5*8kB 5*16kB 7*32kB 3*64kB 5*128kB 4*256kB 3*512kB 5*1024kB 3*2048kB 4*4096kB 5*8192kB 0*16384kB = 72376kB Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap = 0kB Total swap = 0kB Free swap:0kB 32768 pages of RAM 10403 reserved pages 0 pages shared 0 pages swap cached The kernel is using 16MB pages for the linear mapping and, since its in the same region, the sparse virtural memmap. PS3 uses hotplug for all most all of its memory. In this case, its trying to allocate an additional page to cover a new region of the memory map. However, the initial 128 MB is fragmented, we have 8 8M chunks but no 16MB ones. <1>Unable to handle kernel paging request for data at address 0xcf0001960b10 <1>Faulting instruction address: 0xc0087340 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 PS3 Modules linked in: NIP: c0087340 LR: c008733c CTR: REGS: c6047900 TRAP: 0300 Not tainted (2.6.24-rc3-ps3-linux-dev-g91428d55-dirty) MSR: 80008032 CR: 2200 XER: DAR: cf0001960b10, DSISR: 4200 TASK = c6041080[1] 'swapper' THREAD: c6044000 CPU: 1 <6>GPR00: c6047b80 c052b410 c6001b40 <6>GPR04: 0001 0003 0008 <6>GPR08: 0002 cf0001960b08 c6051240 0003 <6>GPR12: 0003 c0484080 100d 00bc5000 <6>GPR16: 07fff000 0001 100a 100d <6>GPR20: 100df628 100df458 100df678 <6>GPR24: 00740336 c0492c00 0001 <6>GPR28: 000740325000 000740324924 c04ce9a8 cf0001960ae0 NIP [c0087340] .memmap_init_zone+0xf0/0x134 LR [c008733c] .memmap_init_zone+0xec/0x134 Call Trace: [c6047b80] [c01da530] .add_memory_block+0xd8/0x108 (unreliable) [c6047c20] [c00aa7ac] .__add_pages+0x10c/0x18c [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 Instruction dump: 901f000c 38000400 7d20f8a8 7d290378 7d20f9ad 40a2fff4 7ba00521 7fe3fb78 3882 41820008 4b0d 393f0028 f93f0028 3bbd0001 3bff0038 <0>Kernel panic - not
Re: PS3: trouble with SPARSEMEM_VMEMMAP and kexec
On Dec 2, 2007, at 9:59 PM, Geoff Levand wrote: Hi. I'm finding that recently kexec'ed kernels on PS3 will panic on startup. It seems the trouble was introduced with the ppc64 SPARSEMEM_VMEMMAP support. The problem is the same when starting either new or old kernels: 2.6.24 - 2.6.23 ok 2.6.24 - 2.6.23 panic 2.6.24 - 2.6.24 panic I'm not sure I completely follow this. What is the difference between 1 and 2 ? Also, you are talking about starting with kexec, but I don't see how that fits in the failure you have below. In other words, there may be more than one failure. But I can talk a bit about the scope of the problem in the current traceback. These are the commits that seem to introduce the problem: d29eff7bca60c9ee401d691d4562a4abca8de543 ppc64: SPARSEMEM_VMEMMAP suppor 8f6aac419bd590f535fb110875a51f7db2b62b5b Generic Virtual Memmap support for SPARSEMEM Below is a startup dump. Any help in finding the problem would be appreciated. -Geoff ps3_mm_add_memory:317: start_addr 74032000h, start_pfn 74032h, nr_pages 17000h 4swapper: page allocation failure. order:12, mode:0x80d0 Call Trace: [c6047820] [c000e700] .show_stack+0x68/0x1b0 (unreliable) [c60478c0] [c0089eb4] .__alloc_pages+0x358/0x3ac [c60479b0] [c00a3964] .vmemmap_alloc_block+0x6c/0xf4 [c6047a40] [c0026544] .vmemmap_populate+0x74/0x100 [c6047ae0] [c00a385c] .sparse_mem_map_populate+0x38/0x5c [c6047b70] [c00a36e4] .sparse_add_one_section+0x64/0x128 [c6047c20] [c00aa74c] .__add_pages+0xac/0x18c [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 Mem-info: DMA per-cpu: CPU0: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0 CPU1: Hot: hi: 42, btch: 7 usd: 0 Cold: hi: 14, btch: 3 usd: 0 Active:0 inactive:0 dirty:0 writeback:0 unstable:0 free:18094 slab:122 mapped:0 pagetables:0 bounce:0 DMA free:72376kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:129280kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 8*4kB 5*8kB 5*16kB 7*32kB 3*64kB 5*128kB 4*256kB 3*512kB 5*1024kB 3*2048kB 4*4096kB 5*8192kB 0*16384kB = 72376kB Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap = 0kB Total swap = 0kB Free swap:0kB 32768 pages of RAM 10403 reserved pages 0 pages shared 0 pages swap cached The kernel is using 16MB pages for the linear mapping and, since its in the same region, the sparse virtural memmap. PS3 uses hotplug for all most all of its memory. In this case, its trying to allocate an additional page to cover a new region of the memory map. However, the initial 128 MB is fragmented, we have 8 8M chunks but no 16MB ones. 1Unable to handle kernel paging request for data at address 0xcf0001960b10 1Faulting instruction address: 0xc0087340 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 PS3 Modules linked in: NIP: c0087340 LR: c008733c CTR: REGS: c6047900 TRAP: 0300 Not tainted (2.6.24-rc3-ps3-linux-dev-g91428d55-dirty) MSR: 80008032 EE,IR,DR CR: 2200 XER: DAR: cf0001960b10, DSISR: 4200 TASK = c6041080[1] 'swapper' THREAD: c6044000 CPU: 1 6GPR00: c6047b80 c052b410 c6001b40 6GPR04: 0001 0003 0008 6GPR08: 0002 cf0001960b08 c6051240 0003 6GPR12: 0003 c0484080 100d 00bc5000 6GPR16: 07fff000 0001 100a 100d 6GPR20: 100df628 100df458 100df678 6GPR24: 00740336 c0492c00 0001 6GPR28: 000740325000 000740324924 c04ce9a8 cf0001960ae0 NIP [c0087340] .memmap_init_zone+0xf0/0x134 LR [c008733c] .memmap_init_zone+0xec/0x134 Call Trace: [c6047b80] [c01da530] .add_memory_block+0xd8/0x108 (unreliable) [c6047c20] [c00aa7ac] .__add_pages+0x10c/0x18c [c6047cd0] [c0025fd4] .arch_add_memory+0x44/0x60 [c6047d60] [c00aa5b0] .add_memory+0xd4/0x124 [c6047e00] [c0452544] .ps3_mm_add_memory+0x8c/0x108 [c6047ea0] [c04417c4] .kernel_init+0x1f4/0x3b8 [c6047f90] [c0021d88] .kernel_thread+0x4c/0x68 Instruction dump: 901f000c 38000400 7d20f8a8 7d290378 7d20f9ad 40a2fff4 7ba00521 7fe3fb78 3882 41820008 4b0d 393f0028 f9290008 f93f0028 3bbd0001 3bff0038 0Kernel panic - not syncing:
