* [PATCH 0/2] m68k: fixups for recent changes in memory initialization @ 2020-06-17 6:53 Mike Rapoport 2020-06-17 6:53 ` [PATCH 1/2] m68k: nommu: register start of the memory with memblock Mike Rapoport 2020-06-17 6:53 ` [PATCH 2/2] m68k: mm: fix node memblock init Mike Rapoport 0 siblings, 2 replies; 8+ messages in thread From: Mike Rapoport @ 2020-06-17 6:53 UTC (permalink / raw) To: Greg Ungerer Cc: Geert Uytterhoeven, linux-m68k, linux-kernel, Mike Rapoport, Mike Rapoport From: Mike Rapoport <rppt@linux.ibm.com> Hi, It's a followup to the Greg's [1] and Angelo's [2] reports of boot problems caused by the recent rework of the memory initialization. I'm resending Angelo's original patch for mcfmmu and my fix for the nommu variant. [1] https://lore.kernel.org/lkml/f53e68db-ed81-6ef6-5087-c7246d010ea2@linux-m68k.org [2] https://lore.kernel.org/linux-m68k/20200614225119.777702-1-angelo.dureghello@timesys.com Angelo Dureghello (1): m68k: mm: fix node memblock init Mike Rapoport (1): m68k: nommu: register start of the memory with memblock arch/m68k/kernel/setup_no.c | 3 ++- arch/m68k/mm/mcfmmu.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) -- 2.26.2 ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/2] m68k: nommu: register start of the memory with memblock 2020-06-17 6:53 [PATCH 0/2] m68k: fixups for recent changes in memory initialization Mike Rapoport @ 2020-06-17 6:53 ` Mike Rapoport 2020-06-17 12:33 ` Greg Ungerer 2020-06-17 6:53 ` [PATCH 2/2] m68k: mm: fix node memblock init Mike Rapoport 1 sibling, 1 reply; 8+ messages in thread From: Mike Rapoport @ 2020-06-17 6:53 UTC (permalink / raw) To: Greg Ungerer Cc: Geert Uytterhoeven, linux-m68k, linux-kernel, Mike Rapoport, Mike Rapoport From: Mike Rapoport <rppt@linux.ibm.com> The m68k nommu setup code didn't register the beginning of the physical memory with memblock because it was anyway occupied by the kernel. However, commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than zone sizes") changed zones initialization to use memblock.memory to detect the zone extents and this caused inconsistency between zone PFNs and the actual PFNs: BUG: Bad page state in process swapper pfn:20165 page:41fe0ca0 refcount:0 mapcount:1 mapping:00000000 index:0x0 flags: 0x0() raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000 page dumped because: nonzero mapcount CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-00001-g3a38f8a60c65-dirty #1 Stack from 404c9ebc: 404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4 00020165 00000000 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21 00000000 40088a12 41fe0ca0 41fe0ca4 0000020a 00000000 00000001 402ca000 00000000 41fe0ca0 41fd2c10 41fd2c10 00000000 00000000 402b2388 00000001 400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 00000001 41fd2c04 41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0 ffffffff Call Trace: [<40088470>] 0x40088470 [<40088504>] 0x40088504 [<40088a12>] 0x40088a12 [<402ca000>] 0x402ca000 [<400a0934>] 0x400a0934 Adjust the memory registration with memblock to include the beginning of the physical memory and make sure that the area occupied by the kernel is marked as reserved. Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> --- arch/m68k/kernel/setup_no.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c index e779b19e0193..f66f4b1d062e 100644 --- a/arch/m68k/kernel/setup_no.c +++ b/arch/m68k/kernel/setup_no.c @@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p) pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ", __bss_stop, memory_start, memory_start, memory_end); - memblock_add(memory_start, memory_end - memory_start); + memblock_add(_rambase, memory_end - _rambase); + memblock_reserve(_rambase, memory_start - _rambase); /* Keep a copy of command line */ *cmdline_p = &command_line[0]; -- 2.26.2 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] m68k: nommu: register start of the memory with memblock 2020-06-17 6:53 ` [PATCH 1/2] m68k: nommu: register start of the memory with memblock Mike Rapoport @ 2020-06-17 12:33 ` Greg Ungerer 2020-06-29 1:10 ` Greg Ungerer 0 siblings, 1 reply; 8+ messages in thread From: Greg Ungerer @ 2020-06-17 12:33 UTC (permalink / raw) To: Mike Rapoport; +Cc: Geert Uytterhoeven, linux-m68k, linux-kernel, Mike Rapoport Hi Mike, On 17/6/20 4:53 pm, Mike Rapoport wrote: > From: Mike Rapoport <rppt@linux.ibm.com> > > The m68k nommu setup code didn't register the beginning of the physical > memory with memblock because it was anyway occupied by the kernel. However, > commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than > zone sizes") changed zones initialization to use memblock.memory to detect > the zone extents and this caused inconsistency between zone PFNs and the > actual PFNs: > > BUG: Bad page state in process swapper pfn:20165 > page:41fe0ca0 refcount:0 mapcount:1 mapping:00000000 index:0x0 flags: 0x0() > raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000 > page dumped because: nonzero mapcount > CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-00001-g3a38f8a60c65-dirty #1 > Stack from 404c9ebc: > 404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4 > 00020165 00000000 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21 > 00000000 40088a12 41fe0ca0 41fe0ca4 0000020a 00000000 00000001 402ca000 > 00000000 41fe0ca0 41fd2c10 41fd2c10 00000000 00000000 402b2388 00000001 > 400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 00000001 41fd2c04 > 41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0 ffffffff > Call Trace: > [<40088470>] 0x40088470 > [<40088504>] 0x40088504 > [<40088a12>] 0x40088a12 > [<402ca000>] 0x402ca000 > [<400a0934>] 0x400a0934 > > Adjust the memory registration with memblock to include the beginning of > the physical memory and make sure that the area occupied by the kernel is > marked as reserved. > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Greg Ungerer <gerg@linux-m68k.org> Regards Greg > --- > arch/m68k/kernel/setup_no.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c > index e779b19e0193..f66f4b1d062e 100644 > --- a/arch/m68k/kernel/setup_no.c > +++ b/arch/m68k/kernel/setup_no.c > @@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p) > pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ", > __bss_stop, memory_start, memory_start, memory_end); > > - memblock_add(memory_start, memory_end - memory_start); > + memblock_add(_rambase, memory_end - _rambase); > + memblock_reserve(_rambase, memory_start - _rambase); > > /* Keep a copy of command line */ > *cmdline_p = &command_line[0]; > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] m68k: nommu: register start of the memory with memblock 2020-06-17 12:33 ` Greg Ungerer @ 2020-06-29 1:10 ` Greg Ungerer 2020-06-29 4:14 ` Mike Rapoport 0 siblings, 1 reply; 8+ messages in thread From: Greg Ungerer @ 2020-06-29 1:10 UTC (permalink / raw) To: Mike Rapoport; +Cc: Geert Uytterhoeven, linux-m68k, linux-kernel, Mike Rapoport Hi Mike, On 17/6/20 10:33 pm, Greg Ungerer wrote: > Hi Mike, > > On 17/6/20 4:53 pm, Mike Rapoport wrote: >> From: Mike Rapoport <rppt@linux.ibm.com> >> >> The m68k nommu setup code didn't register the beginning of the physical >> memory with memblock because it was anyway occupied by the kernel. However, >> commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than >> zone sizes") changed zones initialization to use memblock.memory to detect >> the zone extents and this caused inconsistency between zone PFNs and the >> actual PFNs: >> >> BUG: Bad page state in process swapper pfn:20165 >> page:41fe0ca0 refcount:0 mapcount:1 mapping:00000000 index:0x0 flags: 0x0() >> raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000 >> page dumped because: nonzero mapcount >> CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-00001-g3a38f8a60c65-dirty #1 >> Stack from 404c9ebc: >> 404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4 >> 00020165 00000000 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21 >> 00000000 40088a12 41fe0ca0 41fe0ca4 0000020a 00000000 00000001 402ca000 >> 00000000 41fe0ca0 41fd2c10 41fd2c10 00000000 00000000 402b2388 00000001 >> 400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 00000001 41fd2c04 >> 41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0 ffffffff >> Call Trace: >> [<40088470>] 0x40088470 >> [<40088504>] 0x40088504 >> [<40088a12>] 0x40088a12 >> [<402ca000>] 0x402ca000 >> [<400a0934>] 0x400a0934 >> >> Adjust the memory registration with memblock to include the beginning of >> the physical memory and make sure that the area occupied by the kernel is >> marked as reserved. >> >> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> > > Acked-by: Greg Ungerer <gerg@linux-m68k.org> What path do you anticipate this taking into mainline? I see it is still broken in 5.8-rc3. Regards Greg >> --- >> arch/m68k/kernel/setup_no.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c >> index e779b19e0193..f66f4b1d062e 100644 >> --- a/arch/m68k/kernel/setup_no.c >> +++ b/arch/m68k/kernel/setup_no.c >> @@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p) >> pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ", >> __bss_stop, memory_start, memory_start, memory_end); >> - memblock_add(memory_start, memory_end - memory_start); >> + memblock_add(_rambase, memory_end - _rambase); >> + memblock_reserve(_rambase, memory_start - _rambase); >> /* Keep a copy of command line */ >> *cmdline_p = &command_line[0]; >> ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] m68k: nommu: register start of the memory with memblock 2020-06-29 1:10 ` Greg Ungerer @ 2020-06-29 4:14 ` Mike Rapoport 2020-06-29 14:03 ` Greg Ungerer 0 siblings, 1 reply; 8+ messages in thread From: Mike Rapoport @ 2020-06-29 4:14 UTC (permalink / raw) To: Greg Ungerer; +Cc: Geert Uytterhoeven, linux-m68k, linux-kernel, Mike Rapoport Hi Greg, On Mon, Jun 29, 2020 at 11:10:16AM +1000, Greg Ungerer wrote: > Hi Mike, > > On 17/6/20 10:33 pm, Greg Ungerer wrote: > > Hi Mike, > > > > On 17/6/20 4:53 pm, Mike Rapoport wrote: > > > From: Mike Rapoport <rppt@linux.ibm.com> > > > > > > The m68k nommu setup code didn't register the beginning of the physical > > > memory with memblock because it was anyway occupied by the kernel. However, > > > commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than > > > zone sizes") changed zones initialization to use memblock.memory to detect > > > the zone extents and this caused inconsistency between zone PFNs and the > > > actual PFNs: > > > > > > BUG: Bad page state in process swapper pfn:20165 > > > page:41fe0ca0 refcount:0 mapcount:1 mapping:00000000 index:0x0 flags: 0x0() > > > raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000 > > > page dumped because: nonzero mapcount > > > CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-00001-g3a38f8a60c65-dirty #1 > > > Stack from 404c9ebc: > > > 404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4 > > > 00020165 00000000 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21 > > > 00000000 40088a12 41fe0ca0 41fe0ca4 0000020a 00000000 00000001 402ca000 > > > 00000000 41fe0ca0 41fd2c10 41fd2c10 00000000 00000000 402b2388 00000001 > > > 400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 00000001 41fd2c04 > > > 41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0 ffffffff > > > Call Trace: > > > [<40088470>] 0x40088470 > > > [<40088504>] 0x40088504 > > > [<40088a12>] 0x40088a12 > > > [<402ca000>] 0x402ca000 > > > [<400a0934>] 0x400a0934 > > > > > > Adjust the memory registration with memblock to include the beginning of > > > the physical memory and make sure that the area occupied by the kernel is > > > marked as reserved. > > > > > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> > > > > Acked-by: Greg Ungerer <gerg@linux-m68k.org> > > What path do you anticipate this taking into mainline? > I see it is still broken in 5.8-rc3. I thought it will go through m68k tree. > Regards > Greg > > > > > > --- > > > arch/m68k/kernel/setup_no.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c > > > index e779b19e0193..f66f4b1d062e 100644 > > > --- a/arch/m68k/kernel/setup_no.c > > > +++ b/arch/m68k/kernel/setup_no.c > > > @@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p) > > > pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ", > > > __bss_stop, memory_start, memory_start, memory_end); > > > - memblock_add(memory_start, memory_end - memory_start); > > > + memblock_add(_rambase, memory_end - _rambase); > > > + memblock_reserve(_rambase, memory_start - _rambase); > > > /* Keep a copy of command line */ > > > *cmdline_p = &command_line[0]; > > > -- Sincerely yours, Mike. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] m68k: nommu: register start of the memory with memblock 2020-06-29 4:14 ` Mike Rapoport @ 2020-06-29 14:03 ` Greg Ungerer 0 siblings, 0 replies; 8+ messages in thread From: Greg Ungerer @ 2020-06-29 14:03 UTC (permalink / raw) To: Mike Rapoport; +Cc: Geert Uytterhoeven, linux-m68k, linux-kernel, Mike Rapoport Hi Mike, On 29/6/20 2:14 pm, Mike Rapoport wrote: > On Mon, Jun 29, 2020 at 11:10:16AM +1000, Greg Ungerer wrote: >> On 17/6/20 10:33 pm, Greg Ungerer wrote: >>> On 17/6/20 4:53 pm, Mike Rapoport wrote: >>>> From: Mike Rapoport <rppt@linux.ibm.com> >>>> >>>> The m68k nommu setup code didn't register the beginning of the physical >>>> memory with memblock because it was anyway occupied by the kernel. However, >>>> commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than >>>> zone sizes") changed zones initialization to use memblock.memory to detect >>>> the zone extents and this caused inconsistency between zone PFNs and the >>>> actual PFNs: >>>> >>>> BUG: Bad page state in process swapper pfn:20165 >>>> page:41fe0ca0 refcount:0 mapcount:1 mapping:00000000 index:0x0 flags: 0x0() >>>> raw: 00000000 00000100 00000122 00000000 00000000 00000000 00000000 00000000 >>>> page dumped because: nonzero mapcount >>>> CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-00001-g3a38f8a60c65-dirty #1 >>>> Stack from 404c9ebc: >>>> 404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4 >>>> 00020165 00000000 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21 >>>> 00000000 40088a12 41fe0ca0 41fe0ca4 0000020a 00000000 00000001 402ca000 >>>> 00000000 41fe0ca0 41fd2c10 41fd2c10 00000000 00000000 402b2388 00000001 >>>> 400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 00000001 41fd2c04 >>>> 41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0 ffffffff >>>> Call Trace: >>>> [<40088470>] 0x40088470 >>>> [<40088504>] 0x40088504 >>>> [<40088a12>] 0x40088a12 >>>> [<402ca000>] 0x402ca000 >>>> [<400a0934>] 0x400a0934 >>>> >>>> Adjust the memory registration with memblock to include the beginning of >>>> the physical memory and make sure that the area occupied by the kernel is >>>> marked as reserved. >>>> >>>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> >>> >>> Acked-by: Greg Ungerer <gerg@linux-m68k.org> >> >> What path do you anticipate this taking into mainline? >> I see it is still broken in 5.8-rc3. > > I thought it will go through m68k tree. Ok, no worries, I will push them through. I have pushed into the for-next and for-linus branches of the m68knommu git tree to get the ball rolling. Regards Greg >>>> --- >>>> arch/m68k/kernel/setup_no.c | 3 ++- >>>> 1 file changed, 2 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c >>>> index e779b19e0193..f66f4b1d062e 100644 >>>> --- a/arch/m68k/kernel/setup_no.c >>>> +++ b/arch/m68k/kernel/setup_no.c >>>> @@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p) >>>> pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ", >>>> __bss_stop, memory_start, memory_start, memory_end); >>>> - memblock_add(memory_start, memory_end - memory_start); >>>> + memblock_add(_rambase, memory_end - _rambase); >>>> + memblock_reserve(_rambase, memory_start - _rambase); >>>> /* Keep a copy of command line */ >>>> *cmdline_p = &command_line[0]; >>>> > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] m68k: mm: fix node memblock init 2020-06-17 6:53 [PATCH 0/2] m68k: fixups for recent changes in memory initialization Mike Rapoport 2020-06-17 6:53 ` [PATCH 1/2] m68k: nommu: register start of the memory with memblock Mike Rapoport @ 2020-06-17 6:53 ` Mike Rapoport 2020-06-17 12:34 ` Greg Ungerer 1 sibling, 1 reply; 8+ messages in thread From: Mike Rapoport @ 2020-06-17 6:53 UTC (permalink / raw) To: Greg Ungerer Cc: Geert Uytterhoeven, linux-m68k, linux-kernel, Mike Rapoport, Angelo Dureghello, Mike Rapoport From: Angelo Dureghello <angelo.dureghello@timesys.com> After pulling 5.7.0 (linux-next merge), mcf5441x mmu boot was hanging silently. memblock_add() seems not appropriate, since using MAX_NUMNODES as node id, while memblock_add_node() sets up memory for node id 0. Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> --- arch/m68k/mm/mcfmmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c index 29f47923aa46..7d04210d34f0 100644 --- a/arch/m68k/mm/mcfmmu.c +++ b/arch/m68k/mm/mcfmmu.c @@ -174,7 +174,7 @@ void __init cf_bootmem_alloc(void) m68k_memory[0].addr = _rambase; m68k_memory[0].size = _ramend - _rambase; - memblock_add(m68k_memory[0].addr, m68k_memory[0].size); + memblock_add_node(m68k_memory[0].addr, m68k_memory[0].size, 0); /* compute total pages in system */ num_pages = PFN_DOWN(_ramend - _rambase); -- 2.26.2 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] m68k: mm: fix node memblock init 2020-06-17 6:53 ` [PATCH 2/2] m68k: mm: fix node memblock init Mike Rapoport @ 2020-06-17 12:34 ` Greg Ungerer 0 siblings, 0 replies; 8+ messages in thread From: Greg Ungerer @ 2020-06-17 12:34 UTC (permalink / raw) To: Mike Rapoport Cc: Geert Uytterhoeven, linux-m68k, linux-kernel, Angelo Dureghello, Mike Rapoport Hi Mike, On 17/6/20 4:53 pm, Mike Rapoport wrote: > From: Angelo Dureghello <angelo.dureghello@timesys.com> > > After pulling 5.7.0 (linux-next merge), mcf5441x mmu boot was > hanging silently. > > memblock_add() seems not appropriate, since using MAX_NUMNODES > as node id, while memblock_add_node() sets up memory for node id 0. > > Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Greg Ungerer <gerg@linux-m68k.org> Regards Greg > --- > arch/m68k/mm/mcfmmu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/m68k/mm/mcfmmu.c b/arch/m68k/mm/mcfmmu.c > index 29f47923aa46..7d04210d34f0 100644 > --- a/arch/m68k/mm/mcfmmu.c > +++ b/arch/m68k/mm/mcfmmu.c > @@ -174,7 +174,7 @@ void __init cf_bootmem_alloc(void) > m68k_memory[0].addr = _rambase; > m68k_memory[0].size = _ramend - _rambase; > > - memblock_add(m68k_memory[0].addr, m68k_memory[0].size); > + memblock_add_node(m68k_memory[0].addr, m68k_memory[0].size, 0); > > /* compute total pages in system */ > num_pages = PFN_DOWN(_ramend - _rambase); > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-06-29 21:41 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-17 6:53 [PATCH 0/2] m68k: fixups for recent changes in memory initialization Mike Rapoport 2020-06-17 6:53 ` [PATCH 1/2] m68k: nommu: register start of the memory with memblock Mike Rapoport 2020-06-17 12:33 ` Greg Ungerer 2020-06-29 1:10 ` Greg Ungerer 2020-06-29 4:14 ` Mike Rapoport 2020-06-29 14:03 ` Greg Ungerer 2020-06-17 6:53 ` [PATCH 2/2] m68k: mm: fix node memblock init Mike Rapoport 2020-06-17 12:34 ` Greg Ungerer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).