Widespread boot failures on ARM due to "mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()"
Since 20151231 -next has been failing to boot on a wide range of ARM platforms in the kernelci.org boot tests[1]. Doing bisections with Arndale and BeagleBone Black identifies 904769ac82ebf (mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()) from the akpm tree as the first broken commit[2,3]. An example bootlog from the failure is:
http://storage.kernelci.org/next/next-20151231/arm-multi_v7_defconfig/lab-ca...
which shows no output on the console once we start the kernel, a brief sampling of failing boards suggests this is the normal failure mode. x86 and arm64 targets seem fine (juno shows up as failing but the boot log seems fine so it's probably a false positive, Mustang was failing already) and there are a small number of ARM platforms that boot. I've not yet had any time to investigate further than that (including trying a revert of that commit), sorry.
[1] http://kernelci.org/boot/all/job/next/kernel/next-20151231/ [2] https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/135/console [3] https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/136/console
On Mon, 4 Jan 2016 22:42:33 +0000 Mark Brown broonie@kernel.org wrote:
Since 20151231 -next has been failing to boot on a wide range of ARM platforms in the kernelci.org boot tests[1]. Doing bisections with Arndale and BeagleBone Black identifies 904769ac82ebf (mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()) from the akpm tree as the first broken commit[2,3]. An example bootlog from the failure is:
http://storage.kernelci.org/next/next-20151231/arm-multi_v7_defconfig/lab-ca...
which shows no output on the console once we start the kernel, a brief sampling of failing boards suggests this is the normal failure mode. x86 and arm64 targets seem fine (juno shows up as failing but the boot log seems fine so it's probably a false positive, Mustang was failing already) and there are a small number of ARM platforms that boot. I've not yet had any time to investigate further than that (including trying a revert of that commit), sorry.
[1] http://kernelci.org/boot/all/job/next/kernel/next-20151231/ [2] https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/135/console [3] https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/136/console
Thanks. That patch has rather a blooper if CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
Arnd's tentative fix is below.
I shall drop that patchset for now.
From: Arnd Bergmann arnd@arndb.de Subject: mm/page_alloc.c: set a zone_start_pfn value in zone_spanned_pages_in_node
We got a new build warning in linux-next:
mm/page_alloc.c: In function 'free_area_init_node': mm/page_alloc.c:5278:25: warning: 'zone_start_pfn' may be used uninitialized in this function [-Wmaybe-uninitialized] zone->zone_start_pfn = zone_start_pfn; mm/page_alloc.c:5265:17: note: 'zone_start_pfn' was declared here unsigned long zone_start_pfn, zone_end_pfn;
The code indeed looks wrong, but this is just a guess of what the fix might be: I have not looked it in detail, so please treat this as a bug report.
Signed-off-by: Arnd Bergmann arnd@arndb.de Cc: Taku Izumi izumi.taku@jp.fujitsu.com Cc: Tony Luck tony.luck@intel.com Signed-off-by: Andrew Morton akpm@linux-foundation.org ---
mm/page_alloc.c | 2 ++ 1 file changed, 2 insertions(+)
diff -puN mm/page_alloc.c~mm-calculate-zone_start_pfn-at-zone_spanned_pages_in_node-fix mm/page_alloc.c --- a/mm/page_alloc.c~mm-calculate-zone_start_pfn-at-zone_spanned_pages_in_node-fix +++ a/mm/page_alloc.c @@ -5013,6 +5013,8 @@ static inline unsigned long __meminit zo unsigned long *zone_end_pfn, unsigned long *zones_size) { + *zone_start_pfn = node_start_pfn; + *zone_end_pfn = node_end_pfn; return zones_size[zone_type]; }
_
On Mon, Jan 04, 2016 at 03:09:46PM -0800, Andrew Morton wrote:
On Mon, 4 Jan 2016 22:42:33 +0000 Mark Brown broonie@kernel.org wrote:
platforms in the kernelci.org boot tests[1]. Doing bisections with Arndale and BeagleBone Black identifies 904769ac82ebf (mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()) from the akpm tree as the first broken commit[2,3]. An example bootlog from the failure is:
Thanks. That patch has rather a blooper if CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
Seems to be what's making a difference from a quick run through, yes.
On Mon, 4 Jan 2016 23:55:12 +0000 Mark Brown broonie@kernel.org wrote:
On Mon, Jan 04, 2016 at 03:09:46PM -0800, Andrew Morton wrote:
On Mon, 4 Jan 2016 22:42:33 +0000 Mark Brown broonie@kernel.org wrote:
platforms in the kernelci.org boot tests[1]. Doing bisections with Arndale and BeagleBone Black identifies 904769ac82ebf (mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()) from the akpm tree as the first broken commit[2,3]. An example bootlog from the failure is:
Thanks. That patch has rather a blooper if CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
Seems to be what's making a difference from a quick run through, yes.
OK, thanks.
Stephen, can we please retain
mm-calculate-zone_start_pfn-at-zone_spanned_pages_in_node.patch mm-introduce-kernelcore=mirror-option.patch mm-introduce-kernelcore=mirror-option-fix.patch mm-introduce-kernelcore=mirror-option-fix-2.patch
and add the below?
Or don't bother - I'll do an mmotm tomorrow with these in it.
I'd still like reviewing and testing from Taku Izumi please.
From: Arnd Bergmann arnd@arndb.de Subject: mm/page_alloc.c: set a zone_start_pfn value in zone_spanned_pages_in_node
We got a new build warning in linux-next:
mm/page_alloc.c: In function 'free_area_init_node': mm/page_alloc.c:5278:25: warning: 'zone_start_pfn' may be used uninitialized in this function [-Wmaybe-uninitialized] zone->zone_start_pfn = zone_start_pfn; mm/page_alloc.c:5265:17: note: 'zone_start_pfn' was declared here unsigned long zone_start_pfn, zone_end_pfn;
The code indeed looks wrong, but this is just a guess of what the fix might be: I have not looked it in detail, so please treat this as a bug report.
Signed-off-by: Arnd Bergmann arnd@arndb.de Cc: Taku Izumi izumi.taku@jp.fujitsu.com Cc: Tony Luck tony.luck@intel.com Signed-off-by: Andrew Morton akpm@linux-foundation.org ---
mm/page_alloc.c | 2 ++ 1 file changed, 2 insertions(+)
diff -puN mm/page_alloc.c~mm-calculate-zone_start_pfn-at-zone_spanned_pages_in_node-fix mm/page_alloc.c --- a/mm/page_alloc.c~mm-calculate-zone_start_pfn-at-zone_spanned_pages_in_node-fix +++ a/mm/page_alloc.c @@ -5013,6 +5013,8 @@ static inline unsigned long __meminit zo unsigned long *zone_end_pfn, unsigned long *zones_size) { + *zone_start_pfn = node_start_pfn; + *zone_end_pfn = node_end_pfn; return zones_size[zone_type]; }
_
Hi Andrew,
On Mon, 4 Jan 2016 16:35:28 -0800 Andrew Morton akpm@linux-foundation.org wrote:
Stephen, can we please retain
mm-calculate-zone_start_pfn-at-zone_spanned_pages_in_node.patch mm-introduce-kernelcore=mirror-option.patch mm-introduce-kernelcore=mirror-option-fix.patch mm-introduce-kernelcore=mirror-option-fix-2.patch
and add the below?
Sure, that is easier than dropping the above patches, anyway.
Hi Andrew,
On Tue, 5 Jan 2016 11:49:18 +1100 Stephen Rothwell sfr@canb.auug.org.au wrote:
On Mon, 4 Jan 2016 16:35:28 -0800 Andrew Morton akpm@linux-foundation.org wrote:
Stephen, can we please retain
mm-calculate-zone_start_pfn-at-zone_spanned_pages_in_node.patch mm-introduce-kernelcore=mirror-option.patch mm-introduce-kernelcore=mirror-option-fix.patch mm-introduce-kernelcore=mirror-option-fix-2.patch
and add the below?
Sure, that is easier than dropping the above patches, anyway.
I have done that *except* that mm-introduce-kernelcore=mirror-option-fix-2.patch is not in mmotm and I cannot find it anywhere.
On Tue, 5 Jan 2016 16:47:16 +1100 Stephen Rothwell sfr@canb.auug.org.au wrote:
Hi Andrew,
On Tue, 5 Jan 2016 11:49:18 +1100 Stephen Rothwell sfr@canb.auug.org.au wrote:
On Mon, 4 Jan 2016 16:35:28 -0800 Andrew Morton akpm@linux-foundation.org wrote:
Stephen, can we please retain
mm-calculate-zone_start_pfn-at-zone_spanned_pages_in_node.patch mm-introduce-kernelcore=mirror-option.patch mm-introduce-kernelcore=mirror-option-fix.patch mm-introduce-kernelcore=mirror-option-fix-2.patch
and add the below?
Sure, that is easier than dropping the above patches, anyway.
I have done that *except* that mm-introduce-kernelcore=mirror-option-fix-2.patch is not in mmotm and I cannot find it anywhere.
oops sorry, I took it out so it isn't in today's http://ozlabs.org/~akpm/mmots/broken-out/. Here:
From: Arnd Bergmann arnd@arndb.de Subject: mm: avoid unused variables in memmap_init_zone
A quick fix on mm/page_alloc.c introduced a harmless warning:
mm/page_alloc.c: In function 'memmap_init_zone': mm/page_alloc.c:4617:44: warning: unused variable 'tmp' [-Wunused-variable] mm/page_alloc.c:4617:26: warning: unused variable 'r' [-Wunused-variable]
This uses another #ifdef to avoid declaring the two variables when the code is not built.
Signed-off-by: Arnd Bergmann arnd@arndb.de Cc: Taku Izumi izumi.taku@jp.fujitsu.com Cc: Tony Luck tony.luck@intel.com Signed-off-by: Andrew Morton akpm@linux-foundation.org ---
mm/page_alloc.c | 2 ++ 1 file changed, 2 insertions(+)
diff -puN mm/page_alloc.c~mm-introduce-kernelcore=mirror-option-fix-2 mm/page_alloc.c --- a/mm/page_alloc.c~mm-introduce-kernelcore=mirror-option-fix-2 +++ a/mm/page_alloc.c @@ -4465,7 +4465,9 @@ void __meminit memmap_init_zone(unsigned unsigned long pfn; struct zone *z; unsigned long nr_initialised = 0; +#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP struct memblock_region *r = NULL, *tmp; +#endif
if (highest_memmap_pfn < end_pfn - 1) highest_memmap_pfn = end_pfn - 1; _
On Mon, Jan 04, 2016 at 04:35:28PM -0800, Andrew Morton wrote:
On Mon, 4 Jan 2016 23:55:12 +0000 Mark Brown broonie@kernel.org wrote:
On Mon, Jan 04, 2016 at 03:09:46PM -0800, Andrew Morton wrote:
Thanks. That patch has rather a blooper if CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
Seems to be what's making a difference from a quick run through, yes.
OK, thanks.
Seems like I was mistaken here somehow or there's some other problem - I've kicked off another bisect for today's -next:
https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/137/console
and will follow up with any results.
On 05/01/16 11:45, Mark Brown wrote:
On Mon, Jan 04, 2016 at 04:35:28PM -0800, Andrew Morton wrote:
On Mon, 4 Jan 2016 23:55:12 +0000 Mark Brown broonie@kernel.org wrote:
On Mon, Jan 04, 2016 at 03:09:46PM -0800, Andrew Morton wrote:
Thanks. That patch has rather a blooper if CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
Seems to be what's making a difference from a quick run through, yes.
OK, thanks.
Seems like I was mistaken here somehow or there's some other problem - I've kicked off another bisect for today's -next:
https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/137/consoleand will follow up with any results.
With both patches applied(one already in today's -next), I am able to boot on ARM64 platform but I get huge load(for each pfn) of below warning:
-->8
BUG: Bad page state in process swapper pfn:900000 page:ffffffbde4000000 count:0 mapcount:1 mapping: (null) index:0x0 flags: 0x0() page dumped because: nonzero mapcount Modules linked in: Hardware name: ARM Juno development board (r0) (DT) Call trace: [<ffffffc000089830>] dump_backtrace+0x0/0x180 [<ffffffc0000899c4>] show_stack+0x14/0x20 [<ffffffc000335008>] dump_stack+0x90/0xc8 [<ffffffc0001531f8>] bad_page+0xd8/0x138 [<ffffffc000153470>] free_pages_prepare+0x218/0x290 [<ffffffc000154d4c>] __free_pages_ok+0x1c/0xb8 [<ffffffc000155638>] __free_pages+0x30/0x50 [<ffffffc00092fa9c>] __free_pages_bootmem+0xa0/0xa8 [<ffffffc0009321d0>] free_all_bootmem+0x11c/0x184 [<ffffffc000925264>] mem_init+0x48/0x1b4 [<ffffffc0009217e0>] start_kernel+0x224/0x3b4 [<0000000080663000>] 0x80663000 Disabling lock debugging due to kernel taint
On Tue, Jan 05, 2016 at 12:21:51PM +0000, Sudeep Holla wrote:
On 05/01/16 11:45, Mark Brown wrote:
On Mon, Jan 04, 2016 at 04:35:28PM -0800, Andrew Morton wrote:
On Mon, 4 Jan 2016 23:55:12 +0000 Mark Brown broonie@kernel.org wrote:
On Mon, Jan 04, 2016 at 03:09:46PM -0800, Andrew Morton wrote:
Thanks. That patch has rather a blooper if CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
Seems to be what's making a difference from a quick run through, yes.
OK, thanks.
Seems like I was mistaken here somehow or there's some other problem - I've kicked off another bisect for today's -next:
https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/137/console
and will follow up with any results.
With both patches applied(one already in today's -next), I am able to boot on ARM64 platform but I get huge load(for each pfn) of below warning:
Bisect on today's -next with Arndale (an ARM platform) flags the same patch:
https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/137/console
as does Juno which is an arm64 platform:
https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/138/console
(it does get to a console but with lots of the backtraces Sudeep indicated).
On 5 January 2016 at 12:21, Sudeep Holla sudeep.holla@arm.com wrote:
On 05/01/16 11:45, Mark Brown wrote:
On Mon, Jan 04, 2016 at 04:35:28PM -0800, Andrew Morton wrote:
On Mon, 4 Jan 2016 23:55:12 +0000 Mark Brown broonie@kernel.org wrote:
On Mon, Jan 04, 2016 at 03:09:46PM -0800, Andrew Morton wrote:
Thanks. That patch has rather a blooper if CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
Seems to be what's making a difference from a quick run through, yes.
OK, thanks.
Seems like I was mistaken here somehow or there's some other problem - I've kicked off another bisect for today's -next:
https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/137/console
and will follow up with any results.
With both patches applied(one already in today's -next), I am able to boot on ARM64 platform but I get huge load(for each pfn) of below warning:
-->8
BUG: Bad page state in process swapper pfn:900000 page:ffffffbde4000000 count:0 mapcount:1 mapping: (null) index:0x0 flags: 0x0() page dumped because: nonzero mapcount Modules linked in: Hardware name: ARM Juno development board (r0) (DT) Call trace: [<ffffffc000089830>] dump_backtrace+0x0/0x180 [<ffffffc0000899c4>] show_stack+0x14/0x20 [<ffffffc000335008>] dump_stack+0x90/0xc8 [<ffffffc0001531f8>] bad_page+0xd8/0x138 [<ffffffc000153470>] free_pages_prepare+0x218/0x290 [<ffffffc000154d4c>] __free_pages_ok+0x1c/0xb8 [<ffffffc000155638>] __free_pages+0x30/0x50 [<ffffffc00092fa9c>] __free_pages_bootmem+0xa0/0xa8 [<ffffffc0009321d0>] free_all_bootmem+0x11c/0x184 [<ffffffc000925264>] mem_init+0x48/0x1b4 [<ffffffc0009217e0>] start_kernel+0x224/0x3b4 [<0000000080663000>] 0x80663000 Disabling lock debugging due to kernel taint
--
I managed to get 904769ac82ebf60cb54f225f59ae7c064772a4d7 booting on an arm64 machine without errors with the following changes:
=====================================
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index a8bb70d..0edb608 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5013,6 +5013,15 @@ static inline unsigned long __meminit zone_spanned_pages_in_node(int nid, unsigned long *zone_end_pfn, unsigned long *zones_size) { + unsigned int zone; + + *zone_start_pfn = node_start_pfn; + for (zone = 0; zone < zone_type; zone++) { + *zone_start_pfn += zones_size[zone]; + } + + *zone_end_pfn = *zone_start_pfn + zones_size[zone_type]; + return zones_size[zone_type]; }
@@ -5328,6 +5337,8 @@ void __paginginit free_area_init_node(int nid, unsigned long *zones_size, pr_info("Initmem setup node %d [mem %#018Lx-%#018Lx]\n", nid, (u64)start_pfn << PAGE_SHIFT, end_pfn ? ((u64)end_pfn << PAGE_SHIFT) - 1 : 0); +#else + start_pfn = node_start_pfn; #endif calculate_node_totalpages(pgdat, start_pfn, end_pfn, zones_size, zholes_size);
=====================================
My understanding is that 904769a ("mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()") inadvertently discards information when pgdat->node_start_pfn is removed from free_area_init_core (and zone_start_pfn is no longer updated by "size" in the loop inside free_area_init_core). This isn't an issue with systems where CONFIG_HAVE_MEMBLOCK_NODE_MAP is enabled as zone_start_pfn is set correctly. On systems without CONFIG_HAVE_MEMBLOCK_NODE_MAP, zone_start_pfn is always 0.
When I ported the above fix to linux-next (8ef79cd05e6894c01ab9b41aa918a402fa8022a7) I was able to boot in a VM but not on my actual machine, I'll investigate that tomorrow.
Cheers, -- Steve
On 05/01/16 19:59, Steve Capper wrote:
On 5 January 2016 at 12:21, Sudeep Holla sudeep.holla@arm.com wrote:
On 05/01/16 11:45, Mark Brown wrote:
On Mon, Jan 04, 2016 at 04:35:28PM -0800, Andrew Morton wrote:
On Mon, 4 Jan 2016 23:55:12 +0000 Mark Brown broonie@kernel.org wrote:
On Mon, Jan 04, 2016 at 03:09:46PM -0800, Andrew Morton wrote:
Thanks. That patch has rather a blooper if CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
Seems to be what's making a difference from a quick run through, yes.
OK, thanks.
Seems like I was mistaken here somehow or there's some other problem - I've kicked off another bisect for today's -next:
https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/137/console
and will follow up with any results.
With both patches applied(one already in today's -next), I am able to boot on ARM64 platform but I get huge load(for each pfn) of below warning:
-->8
BUG: Bad page state in process swapper pfn:900000 page:ffffffbde4000000 count:0 mapcount:1 mapping: (null) index:0x0 flags: 0x0() page dumped because: nonzero mapcount Modules linked in: Hardware name: ARM Juno development board (r0) (DT) Call trace: [<ffffffc000089830>] dump_backtrace+0x0/0x180 [<ffffffc0000899c4>] show_stack+0x14/0x20 [<ffffffc000335008>] dump_stack+0x90/0xc8 [<ffffffc0001531f8>] bad_page+0xd8/0x138 [<ffffffc000153470>] free_pages_prepare+0x218/0x290 [<ffffffc000154d4c>] __free_pages_ok+0x1c/0xb8 [<ffffffc000155638>] __free_pages+0x30/0x50 [<ffffffc00092fa9c>] __free_pages_bootmem+0xa0/0xa8 [<ffffffc0009321d0>] free_all_bootmem+0x11c/0x184 [<ffffffc000925264>] mem_init+0x48/0x1b4 [<ffffffc0009217e0>] start_kernel+0x224/0x3b4 [<0000000080663000>] 0x80663000 Disabling lock debugging due to kernel taint
--
I managed to get 904769ac82ebf60cb54f225f59ae7c064772a4d7 booting on an arm64 machine without errors with the following changes:
=====================================
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index a8bb70d..0edb608 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5013,6 +5013,15 @@ static inline unsigned long __meminit zone_spanned_pages_in_node(int nid, unsigned long *zone_end_pfn, unsigned long *zones_size) {
unsigned int zone;*zone_start_pfn = node_start_pfn;for (zone = 0; zone < zone_type; zone++) {*zone_start_pfn += zones_size[zone];}*zone_end_pfn = *zone_start_pfn + zones_size[zone_type];return zones_size[zone_type];@@ -5328,6 +5337,8 @@ void __paginginit free_area_init_node(int nid, unsigned long *zones_size, pr_info("Initmem setup node %d [mem %#018Lx-%#018Lx]\n", nid, (u64)start_pfn << PAGE_SHIFT, end_pfn ? ((u64)end_pfn << PAGE_SHIFT) - 1 : 0); +#else
start_pfn = node_start_pfn;=====================================
My understanding is that 904769a ("mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()") inadvertently discards information when pgdat->node_start_pfn is removed from free_area_init_core (and zone_start_pfn is no longer updated by "size" in the loop inside free_area_init_core). This isn't an issue with systems where CONFIG_HAVE_MEMBLOCK_NODE_MAP is enabled as zone_start_pfn is set correctly. On systems without CONFIG_HAVE_MEMBLOCK_NODE_MAP, zone_start_pfn is always 0.
When I ported the above fix to linux-next (8ef79cd05e6894c01ab9b41aa918a402fa8022a7) I was able to boot in a VM but not on my actual machine, I'll investigate that tomorrow.
It fixes the issue on real hardware too(Juno).
On 5 January 2016 at 19:59, Steve Capper steve.capper@linaro.org wrote:
On 5 January 2016 at 12:21, Sudeep Holla sudeep.holla@arm.com wrote:
On 05/01/16 11:45, Mark Brown wrote:
On Mon, Jan 04, 2016 at 04:35:28PM -0800, Andrew Morton wrote:
On Mon, 4 Jan 2016 23:55:12 +0000 Mark Brown broonie@kernel.org wrote:
On Mon, Jan 04, 2016 at 03:09:46PM -0800, Andrew Morton wrote:
Thanks. That patch has rather a blooper if CONFIG_HAVE_MEMBLOCK_NODE_MAP=n. Is that the case in your testing?
Seems to be what's making a difference from a quick run through, yes.
OK, thanks.
Seems like I was mistaken here somehow or there's some other problem - I've kicked off another bisect for today's -next:
https://ci.linaro.org/view/people/job/tbaker-boot-bisect-bot/137/console
and will follow up with any results.
With both patches applied(one already in today's -next), I am able to boot on ARM64 platform but I get huge load(for each pfn) of below warning:
-->8
BUG: Bad page state in process swapper pfn:900000 page:ffffffbde4000000 count:0 mapcount:1 mapping: (null) index:0x0 flags: 0x0() page dumped because: nonzero mapcount Modules linked in: Hardware name: ARM Juno development board (r0) (DT) Call trace: [<ffffffc000089830>] dump_backtrace+0x0/0x180 [<ffffffc0000899c4>] show_stack+0x14/0x20 [<ffffffc000335008>] dump_stack+0x90/0xc8 [<ffffffc0001531f8>] bad_page+0xd8/0x138 [<ffffffc000153470>] free_pages_prepare+0x218/0x290 [<ffffffc000154d4c>] __free_pages_ok+0x1c/0xb8 [<ffffffc000155638>] __free_pages+0x30/0x50 [<ffffffc00092fa9c>] __free_pages_bootmem+0xa0/0xa8 [<ffffffc0009321d0>] free_all_bootmem+0x11c/0x184 [<ffffffc000925264>] mem_init+0x48/0x1b4 [<ffffffc0009217e0>] start_kernel+0x224/0x3b4 [<0000000080663000>] 0x80663000 Disabling lock debugging due to kernel taint
--
I managed to get 904769ac82ebf60cb54f225f59ae7c064772a4d7 booting on an arm64 machine without errors with the following changes:
=====================================
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index a8bb70d..0edb608 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5013,6 +5013,15 @@ static inline unsigned long __meminit zone_spanned_pages_in_node(int nid, unsigned long *zone_end_pfn, unsigned long *zones_size) {
unsigned int zone;*zone_start_pfn = node_start_pfn;for (zone = 0; zone < zone_type; zone++) {*zone_start_pfn += zones_size[zone];}*zone_end_pfn = *zone_start_pfn + zones_size[zone_type];return zones_size[zone_type];}
@@ -5328,6 +5337,8 @@ void __paginginit free_area_init_node(int nid, unsigned long *zones_size, pr_info("Initmem setup node %d [mem %#018Lx-%#018Lx]\n", nid, (u64)start_pfn << PAGE_SHIFT, end_pfn ? ((u64)end_pfn << PAGE_SHIFT) - 1 : 0); +#else
start_pfn = node_start_pfn;#endif calculate_node_totalpages(pgdat, start_pfn, end_pfn, zones_size, zholes_size);
=====================================
My understanding is that 904769a ("mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()") inadvertently discards information when pgdat->node_start_pfn is removed from free_area_init_core (and zone_start_pfn is no longer updated by "size" in the loop inside free_area_init_core). This isn't an issue with systems where CONFIG_HAVE_MEMBLOCK_NODE_MAP is enabled as zone_start_pfn is set correctly. On systems without CONFIG_HAVE_MEMBLOCK_NODE_MAP, zone_start_pfn is always 0.
When I ported the above fix to linux-next (8ef79cd05e6894c01ab9b41aa918a402fa8022a7) I was able to boot in a VM but not on my actual machine, I'll investigate that tomorrow.
I got 8ef79cd05e6894c01ab9b41aa918a402fa8022a7 working on my main devboard with the fix above. (It turned out that I had a misconfigured earlycon command line option and this became a problem with one of the pl011 patches.)
Cheers,
On Mon, Jan 04, 2016 at 10:42:33PM +0000, Mark Brown wrote:
Since 20151231 -next has been failing to boot on a wide range of ARM platforms in the kernelci.org boot tests[1]. Doing bisections with Arndale and BeagleBone Black identifies 904769ac82ebf (mm/page_alloc.c: calculate zone_start_pfn at zone_spanned_pages_in_node()) from the akpm tree as the first broken commit[2,3]. An example bootlog from the failure is:
http://storage.kernelci.org/next/next-20151231/arm-multi_v7_defconfig/lab-ca...
which shows no output on the console once we start the kernel, a brief sampling of failing boards suggests this is the normal failure mode. x86 and arm64 targets seem fine (juno shows up as failing but the boot log seems fine so it's probably a false positive, Mustang was failing already) and there are a small number of ARM platforms that boot. I've not yet had any time to investigate further than that (including trying a revert of that commit), sorry.
I see the same problem with my qemu tests for arm.
Reverting the offending commit together with cd31fe16b585 ("mm/page_alloc.c: set a zone_start_pfn value in zone_spanned_pages_in_node") fixes the problem.
Guenter
kernel-build-reports@lists.linaro.org
-
Andrew Morton -
Guenter Roeck -
Mark Brown -
Stephen Rothwell -
Steve Capper -
Sudeep Holla