Messages in this thread | | | Subject | Re: [PATCH 00/20] generic show_mem() v5 | From | Dave Hansen <> | Date | Tue, 15 Jul 2008 13:33:06 -0700 |
| |
On Tue, 2008-07-15 at 13:22 -0700, Andrew Morton wrote: > > The sections are 512MB, and you can see 6 valid ones > > followed by two holes, and then two more valid ones. > > > > Anyway, I believe this patch will fix the oops. > > This looks like it might be suitable. Can you please test it?
Yup, will do. It's where I'm sending this email from, so I'll get to it in a bit. :)
> > --- > > arch/x86/mm/pgtable_32.c | 2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/arch/x86/mm/pgtable_32.c b/arch/x86/mm/pgtable_32.c > > index 369cf06..eb2a480 100644 > > --- a/arch/x86/mm/pgtable_32.c > > +++ b/arch/x86/mm/pgtable_32.c > > @@ -37,6 +37,8 @@ void show_mem(void) > > for (i = 0; i < pgdat->node_spanned_pages; ++i) { > > if (unlikely(i % MAX_ORDER_NR_PAGES == 0)) > > touch_nmi_watchdog(); > > + if (!pfn_valid(pgdat->node_start_pfn + i)) > > + continue; > > page = pgdat_page_nr(pgdat, i); > > total++; > > if (PageHighMem(page)) > > What change caused this oops to turn up now?
Me getting an extra 2GB (up to 4GB) of RAM for my laptop, which caused a memory hole, which triggers only with SPARSEMEM=y. Most people probably don't run with sparsemem or a 32-bit kernel with that much RAM.
-- Dave
| |