Re: [PATCH v3] m68k: Fix memblock-related crashes
Hi Andreas,
On Mon, Dec 17, 2018 at 8:34 PM Andreas Schwab wrote:
> On Dez 17 2018, Andreas Schwab wrote:
> > On Dez 13 2018, Andreas Schwab wrote:
> >> I'm now getting this Oops:
> >>
> >> [ 65.39] Unable to handle kernel NULL pointer dereference at virtual
> >> address (ptrval)
> >> [ 65.39] Oops:
> >> [ 65.39] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat
> >> virtio_rng virtio_blk virtio_ring virtio xfs btrfs xor zlib_deflate
> >> raid6_pq libcrc32c reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod
> >> binfmt_misc loop sg
> >> [ 65.39] PC: [<00211544>] blk_throtl_bio+0x10e/0x592
> >
> > And the crash does not occur when I revert commit 1008a11590.
>
> That is not true, so this is an unrelated bug.
Thank you.
So I'll queue my patch as a late fix for v4.20.
Sun-3 can be fixed when someone can test Mike's suggestion.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3] m68k: Fix memblock-related crashes
On Dez 17 2018, Andreas Schwab wrote: > On Dez 13 2018, Andreas Schwab wrote: > >> I'm now getting this Oops: >> >> [ 65.39] Unable to handle kernel NULL pointer dereference at virtual >> address (ptrval) >> [ 65.39] Oops: >> [ 65.39] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat >> virtio_rng virtio_blk virtio_ring virtio xfs btrfs xor zlib_deflate raid6_pq >> libcrc32c reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod binfmt_misc >> loop sg >> [ 65.39] PC: [<00211544>] blk_throtl_bio+0x10e/0x592 > > And the crash does not occur when I revert commit 1008a11590. That is not true, so this is an unrelated bug. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH v3] m68k: Fix memblock-related crashes
On Dez 13 2018, Andreas Schwab wrote: > I'm now getting this Oops: > > [ 65.39] Unable to handle kernel NULL pointer dereference at virtual > address (ptrval) > [ 65.39] Oops: > [ 65.39] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat virtio_rng > virtio_blk virtio_ring virtio xfs btrfs xor zlib_deflate raid6_pq libcrc32c > reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod binfmt_misc loop sg > [ 65.39] PC: [<00211544>] blk_throtl_bio+0x10e/0x592 And the crash does not occur when I revert commit 1008a11590. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH v3] m68k: Fix memblock-related crashes
I'm now getting this Oops: [ 65.39] Unable to handle kernel NULL pointer dereference at virtual address (ptrval) [ 65.39] Oops: [ 65.39] Modules linked in: nls_iso8859_1 nls_cp437 vfat fat virtio_rng virtio_blk virtio_ring virtio xfs btrfs xor zlib_deflate raid6_pq libcrc32c reiserfs squashfs fuse dm_snapshot dm_bufio dm_mod binfmt_misc loop sg [ 65.39] PC: [<00211544>] blk_throtl_bio+0x10e/0x592 [ 65.39] SR: 2700 SP: (ptrval) a2: bf506dc0 [ 65.39] d0: 0001d1: 03ce63fbd2: d3: 0016 [ 65.39] d4: a45bd5: a0: a1: [ 65.39] Process mkswap (pid: 289, task=(ptrval)) [ 65.39] Frame format=7 eff addr=0060 ssw=0505 faddr=0060 [ 65.39] wb 1 stat/addr/data: [ 65.39] wb 2 stat/addr/data: [ 65.39] wb 3 stat/addr/data: 0060 0001dba1 [ 65.39] push data: [ 65.39] Stack from bd1b7bdc: [ 65.39] 0008 0008 0002 0006 bd6e0b40 bf596c18 [ 65.39] 00682988 bd1b7c78 006000c0 0003 0080 0005 001f28e4 [ 65.39] bf596c18 bf4f1800 bd6e0b40 0008 0008 1000 000a1848 [ 65.39] 0001 bd6e0b40 bf596c18 bd1b7e24 0008 0008 bf4f1800 bf596c18 [ 65.39] bd1b7e24 bd1b7cec 0001 bd1b7d3a 00095c52 0010ce96 000a1848 bd1b7cec [ 65.39] 001f3ea8 bd6e0b40 0008 0008 bd6e0b40 027616cc bd1b7e24 [ 65.39] Call Trace: [<0008>] check_ids+0x8/0x64 [ 65.39] [<001f28e4>] generic_make_request_checks+0x3ca/0x4ee [ 65.39] [<0008>] check_ids+0x8/0x64 [ 65.39] [<1000>] kernel_pg_dir+0x0/0x1000 [ 65.39] [<000a1848>] __put_page+0x0/0x32 [ 65.39] [<0008>] check_ids+0x8/0x64 [ 65.39] [<00095c52>] add_to_page_cache_lru+0x0/0xc4 [ 65.39] [<0010ce96>] do_mpage_readpage+0x0/0x5cc [ 65.39] [<000a1848>] __put_page+0x0/0x32 [ 65.39] [<001f3ea8>] generic_make_request+0x32/0x23c [ 65.39] [<0008>] check_ids+0x8/0x64 [ 65.39] [<001f417c>] submit_bio+0xca/0xfc [ 65.39] [<00095c52>] add_to_page_cache_lru+0x0/0xc4 [ 65.39] [<0010ce96>] do_mpage_readpage+0x0/0x5cc [ 65.39] [<00095c52>] add_to_page_cache_lru+0x0/0xc4 [ 65.39] [<0010ce96>] do_mpage_readpage+0x0/0x5cc [ 65.39] [<000a1848>] __put_page+0x0/0x32 [ 65.39] [<0010ce8a>] mpage_bio_submit+0x2e/0x3a [ 65.39] [<0010d55a>] mpage_readpages+0xf8/0x108 [ 65.39] [<0008>] check_ids+0x8/0x64 [ 65.39] [<00433256>] radix_tree_lookup+0x0/0x1a [ 65.39] [] rtc_ioctl+0x10c/0x2ae [ 65.39] [<00010100>] sixty_four+0x2/0x10 [ 65.39] [<1000>] kernel_pg_dir+0x0/0x1000 [ 65.39] [<00107370>] blkdev_get_block+0x0/0x30 [ 65.39] [<000a0eb4>] read_pages+0x3c/0xe6 [ 65.39] [<00107370>] blkdev_get_block+0x0/0x30 [ 65.39] [<0003>] _sched_setscheduler+0x47/0x7e [ 65.39] [<00433256>] radix_tree_lookup+0x0/0x1a [ 65.39] [<0009cd42>] __alloc_pages_nodemask+0x0/0x86a [ 65.39] [<000a1188>] __do_page_cache_readahead+0x92/0x13e [ 65.39] [<000a10f6>] __do_page_cache_readahead+0x0/0x13e [ 65.39] [<000a1558>] force_page_cache_readahead+0x94/0xa2 [ 65.39] [<000a1848>] __put_page+0x0/0x32 [ 65.39] [<00096316>] unlock_page+0x0/0x2a [ 65.39] [<000970f4>] generic_file_buffered_read+0x11e/0x64a [ 65.39] [<000986f4>] generic_file_read_iter+0x100/0x132 [ 65.39] [<000e0246>] __vfs_read+0x116/0x150 [ 65.39] [<0002>] _FP_CALL_TOP+0x9a46/0xd512 [ 65.39] [<000e02dc>] vfs_read+0x5c/0xe4 [ 65.39] [<000e0766>] ksys_read+0x42/0x8a [ 65.39] [<000e07c0>] sys_read+0x12/0x18 [ 65.39] [<2934>] syscall+0x8/0xc [ 65.39] [ ] bvme6000_gettimeoffset+0xaa/0xe2 [ 65.39] Code: 2d20 012a 2839 005f 5124 226b 0014 7001 0060 6600 0210 4a29 0064 6700 0208 4a8b 6700 0294 2053 2068 0014 2028 002c Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH v3] m68k: Fix memblock-related crashes
Hi Andreas,
On Fri, Dec 7, 2018 at 5:50 PM Geert Uytterhoeven wrote:
> When running the kernel in Fast RAM on Atari:
>
> Ignoring memory chunk at 0x0:0xe0 before the first chunk
> ...
> Unable to handle kernel NULL pointer dereference at virtual address
> (ptrval)
> Oops:
> Modules linked in:
> PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
> SR: 2714 SP: (ptrval) a2: 005e3314
> d0: d1: 000ad2: 0e00d3:
> d4: 005e1fc0d5: 001aa0: 0100a1:
> Process swapper (pid: 0, task=(ptrval))
> Frame format=7 eff addr=0736 ssw=0505 faddr=0736
> wb 1 stat/addr/data:
> wb 2 stat/addr/data:
> wb 3 stat/addr/data: 0736
> push data:
> Stack from 005e1f84:
> 000a 027d3260 006b5006
>
> 0004f062 0003a220 0069e272 005e1ff8 054c 00e0
>
> 0001 00693cd8 027d3260 0004f062 0003a220 00691be6
>
> 006b5006 00690872
> Call Trace: [<0004f062>] printk+0x0/0x18
> [<0003a220>] parse_args+0x0/0x2d4
> [<0069e272>] memblock_virt_alloc_try_nid+0x0/0xa4
> [<00693cd8>] mem_init+0xa/0x5c
> [<0004f062>] printk+0x0/0x18
> [<0003a220>] parse_args+0x0/0x2d4
> [<00691be6>] start_kernel+0x1ca/0x462
> [<00690872>] _sinittext+0x872/0x11f8
> Code: 7a1a eaae 2270 6db0 0061 ef14 2f01 2f03 <96a9> 0736 2203 e589 d681
> e78b d6a9 0732 2f03 2f40 0034 4eb9 0069 b8d0 260e 4fef
> Disabling lock debugging due to kernel taint
> Kernel panic - not syncing: Attempted to kill the idle task!
>
> As the kernel must run in the memory chunk with the lowest address,
> ST-RAM is ignored, and removed from the m68k_memory[] array.
> However, it is not removed from memblock, causing a crash later.
>
> More investigation shows that there are 3 places where memory chunks are
> ignored, all after the calls to memblock_add() in m68k_parse_bootinfo(),
> and thus causing crashes:
> 1. On classic m68k CPUs with a MMU, paging_init() ignores all memory
> chunks below the first chunk, cfr. above,
> 2. On Amigas equipped with a Zorro III bus, config_amiga() ignores all
> Zorro II memory,
> 3. If CONFIG_SINGLE_MEMORY_CHUNK=y, m68k_parse_bootinfo() ignores all
> but the first memory chunk.
>
> Fix this by moving the calls to memblock_add() from
> m68k_parse_bootinfo() to paging_init(), after all ignored memory chunks
> have been removed from m68k_memory[].
>
> Reported-by: Andreas Schwab
> Fixes: 1008a11590b966b4 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
> Signed-off-by: Geert Uytterhoeven
Does this patch fix your crash?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3] m68k: Fix memblock-related crashes
On Sat, Dec 08, 2018 at 11:51:38AM +0100, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Fri, Dec 7, 2018 at 10:02 PM Mike Rapoport wrote:
> > On Fri, Dec 07, 2018 at 05:50:11PM +0100, Geert Uytterhoeven wrote:
> > > Sun-3 must be broken before this fix, as it fills in m68k_memory[0] in
> > > config_sun3(), i.e. after m68k_parse_bootinfo().
> > > Sun-3 is not fixed by this fix, as it uses its own paging_init(), not
> > > the one in motorola.c.
> > > Fixing Sun-3 requires adding memblock_add()/memblock_reserve() calls to
> > > the Sun-3 memory management code.
> >
> > I think that adding memblock_add() to config_sun3 would be sufficient,
> > something like the diff below. This will make memblock aware of the
> > available physical memory and it seems there no allocations in sun3 before
> > paging_init().
> >
> > diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c
> > index 542c440..9a5b9dd 100644
> > --- a/arch/m68k/sun3/config.c
> > +++ b/arch/m68k/sun3/config.c
> > @@ -150,6 +150,7 @@ void __init config_sun3(void)
> >
> > m68k_num_memory=1;
> > m68k_memory[0].size=*(romvec->pv_sun3mem);
> > + memblock_add(memory_start, memory_end - memory_start);
> >
> > sun3_bootmem_alloc(memory_start, memory_end);
> > }
>
> Thanks!
>
> It doesn't need a memblock_reserve() for the kernel, as memory_start is
> already adjusted for that, right?
Yes, unless I've missed something.
> Anyone who can test this is on Sun-3? Thanks!
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
--
Sincerely yours,
Mike.
Re: [PATCH v3] m68k: Fix memblock-related crashes
Hi Geert! On 12/8/18 11:51 AM, Geert Uytterhoeven wrote: > Anyone who can test this is on Sun-3? Thanks! Theoretically, I can. I have three Sun-3 boxes but I haven't set them up for booting a kernel yet. If I manage to find a quick guide for getting started, I might be able to fire up a test machine. Could maybe someone build me a test kernel so I can just focus on setting up the machine and its bootserver? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3] m68k: Fix memblock-related crashes
Hi Mike,
On Fri, Dec 7, 2018 at 10:02 PM Mike Rapoport wrote:
> On Fri, Dec 07, 2018 at 05:50:11PM +0100, Geert Uytterhoeven wrote:
> > Sun-3 must be broken before this fix, as it fills in m68k_memory[0] in
> > config_sun3(), i.e. after m68k_parse_bootinfo().
> > Sun-3 is not fixed by this fix, as it uses its own paging_init(), not
> > the one in motorola.c.
> > Fixing Sun-3 requires adding memblock_add()/memblock_reserve() calls to
> > the Sun-3 memory management code.
>
> I think that adding memblock_add() to config_sun3 would be sufficient,
> something like the diff below. This will make memblock aware of the
> available physical memory and it seems there no allocations in sun3 before
> paging_init().
>
> diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c
> index 542c440..9a5b9dd 100644
> --- a/arch/m68k/sun3/config.c
> +++ b/arch/m68k/sun3/config.c
> @@ -150,6 +150,7 @@ void __init config_sun3(void)
>
> m68k_num_memory=1;
> m68k_memory[0].size=*(romvec->pv_sun3mem);
> + memblock_add(memory_start, memory_end - memory_start);
>
> sun3_bootmem_alloc(memory_start, memory_end);
> }
Thanks!
It doesn't need a memblock_reserve() for the kernel, as memory_start is
already adjusted for that, right?
Anyone who can test this is on Sun-3? Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3] m68k: Fix memblock-related crashes
On Fri, Dec 07, 2018 at 05:50:11PM +0100, Geert Uytterhoeven wrote:
> When running the kernel in Fast RAM on Atari:
>
> Ignoring memory chunk at 0x0:0xe0 before the first chunk
> ...
> Unable to handle kernel NULL pointer dereference at virtual address
> (ptrval)
> Oops:
> Modules linked in:
> PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
> SR: 2714 SP: (ptrval) a2: 005e3314
> d0: d1: 000ad2: 0e00d3:
> d4: 005e1fc0d5: 001aa0: 0100a1:
> Process swapper (pid: 0, task=(ptrval))
> Frame format=7 eff addr=0736 ssw=0505 faddr=0736
> wb 1 stat/addr/data:
> wb 2 stat/addr/data:
> wb 3 stat/addr/data: 0736
> push data:
> Stack from 005e1f84:
> 000a 027d3260 006b5006
>
> 0004f062 0003a220 0069e272 005e1ff8 054c 00e0
>
> 0001 00693cd8 027d3260 0004f062 0003a220 00691be6
>
> 006b5006 00690872
> Call Trace: [<0004f062>] printk+0x0/0x18
> [<0003a220>] parse_args+0x0/0x2d4
> [<0069e272>] memblock_virt_alloc_try_nid+0x0/0xa4
> [<00693cd8>] mem_init+0xa/0x5c
> [<0004f062>] printk+0x0/0x18
> [<0003a220>] parse_args+0x0/0x2d4
> [<00691be6>] start_kernel+0x1ca/0x462
> [<00690872>] _sinittext+0x872/0x11f8
> Code: 7a1a eaae 2270 6db0 0061 ef14 2f01 2f03 <96a9> 0736 2203 e589 d681
> e78b d6a9 0732 2f03 2f40 0034 4eb9 0069 b8d0 260e 4fef
> Disabling lock debugging due to kernel taint
> Kernel panic - not syncing: Attempted to kill the idle task!
>
> As the kernel must run in the memory chunk with the lowest address,
> ST-RAM is ignored, and removed from the m68k_memory[] array.
> However, it is not removed from memblock, causing a crash later.
>
> More investigation shows that there are 3 places where memory chunks are
> ignored, all after the calls to memblock_add() in m68k_parse_bootinfo(),
> and thus causing crashes:
> 1. On classic m68k CPUs with a MMU, paging_init() ignores all memory
> chunks below the first chunk, cfr. above,
> 2. On Amigas equipped with a Zorro III bus, config_amiga() ignores all
> Zorro II memory,
> 3. If CONFIG_SINGLE_MEMORY_CHUNK=y, m68k_parse_bootinfo() ignores all
> but the first memory chunk.
>
> Fix this by moving the calls to memblock_add() from
> m68k_parse_bootinfo() to paging_init(), after all ignored memory chunks
> have been removed from m68k_memory[].
>
> Reported-by: Andreas Schwab
> Fixes: 1008a11590b966b4 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
> Signed-off-by: Geert Uytterhoeven
> ---
> As all 3 cases involve ignoring memory chunks, thus not requiring real
> memory present in the ignored chunks, I managed to test all 3 cases on
> my Amiga 4000 by using a memfile describing nonexistent memory in the
> Zorro II or 32-bit address space, below system RAM.
>
> Sun-3 must be broken before this fix, as it fills in m68k_memory[0] in
> config_sun3(), i.e. after m68k_parse_bootinfo().
> Sun-3 is not fixed by this fix, as it uses its own paging_init(), not
> the one in motorola.c.
> Fixing Sun-3 requires adding memblock_add()/memblock_reserve() calls to
> the Sun-3 memory management code.
I think that adding memblock_add() to config_sun3 would be sufficient,
something like the diff below. This will make memblock aware of the
available physical memory and it seems there no allocations in sun3 before
paging_init().
diff --git a/arch/m68k/sun3/config.c b/arch/m68k/sun3/config.c
index 542c440..9a5b9dd 100644
--- a/arch/m68k/sun3/config.c
+++ b/arch/m68k/sun3/config.c
@@ -150,6 +150,7 @@ void __init config_sun3(void)
m68k_num_memory=1;
m68k_memory[0].size=*(romvec->pv_sun3mem);
+ memblock_add(memory_start, memory_end - memory_start);
sun3_bootmem_alloc(memory_start, memory_end);
}
> v3:
> - Move memblock_add() after memory block removal instead of sprinkling
> memblock_remove() all over the place,
> - Remove Suggested-by, Tested-by.
>
> v2:
> - Add missing #include .
> ---
> arch/m68k/kernel/setup_mm.c | 2 --
> arch/m68k/mm/motorola.c | 2 ++
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
> index a1a3eaeaf58c960d..ad0195cbe04255ea 100644
> --- a/arch/m68k/kernel/setup_mm.c
> +++ b/arch/m68k/kernel/setup_mm.c
> @@ -164,8 +164,6 @@ static void __init m68k_parse_bootinfo(const struct
> bi_record *record)
> be32_to_cpu(m->addr);
> m68k_memory[m68k_num_memory].size =
> be32_to_cpu(m->size);
> -
[PATCH v3] m68k: Fix memblock-related crashes
When running the kernel in Fast RAM on Atari:
Ignoring memory chunk at 0x0:0xe0 before the first chunk
...
Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
Oops:
Modules linked in:
PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
SR: 2714 SP: (ptrval) a2: 005e3314
d0: d1: 000ad2: 0e00d3:
d4: 005e1fc0d5: 001aa0: 0100a1:
Process swapper (pid: 0, task=(ptrval))
Frame format=7 eff addr=0736 ssw=0505 faddr=0736
wb 1 stat/addr/data:
wb 2 stat/addr/data:
wb 3 stat/addr/data: 0736
push data:
Stack from 005e1f84:
000a 027d3260 006b5006
0004f062 0003a220 0069e272 005e1ff8 054c 00e0
0001 00693cd8 027d3260 0004f062 0003a220 00691be6
006b5006 00690872
Call Trace: [<0004f062>] printk+0x0/0x18
[<0003a220>] parse_args+0x0/0x2d4
[<0069e272>] memblock_virt_alloc_try_nid+0x0/0xa4
[<00693cd8>] mem_init+0xa/0x5c
[<0004f062>] printk+0x0/0x18
[<0003a220>] parse_args+0x0/0x2d4
[<00691be6>] start_kernel+0x1ca/0x462
[<00690872>] _sinittext+0x872/0x11f8
Code: 7a1a eaae 2270 6db0 0061 ef14 2f01 2f03 <96a9> 0736 2203 e589 d681
e78b d6a9 0732 2f03 2f40 0034 4eb9 0069 b8d0 260e 4fef
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Attempted to kill the idle task!
As the kernel must run in the memory chunk with the lowest address,
ST-RAM is ignored, and removed from the m68k_memory[] array.
However, it is not removed from memblock, causing a crash later.
More investigation shows that there are 3 places where memory chunks are
ignored, all after the calls to memblock_add() in m68k_parse_bootinfo(),
and thus causing crashes:
1. On classic m68k CPUs with a MMU, paging_init() ignores all memory
chunks below the first chunk, cfr. above,
2. On Amigas equipped with a Zorro III bus, config_amiga() ignores all
Zorro II memory,
3. If CONFIG_SINGLE_MEMORY_CHUNK=y, m68k_parse_bootinfo() ignores all
but the first memory chunk.
Fix this by moving the calls to memblock_add() from
m68k_parse_bootinfo() to paging_init(), after all ignored memory chunks
have been removed from m68k_memory[].
Reported-by: Andreas Schwab
Fixes: 1008a11590b966b4 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
Signed-off-by: Geert Uytterhoeven
---
As all 3 cases involve ignoring memory chunks, thus not requiring real
memory present in the ignored chunks, I managed to test all 3 cases on
my Amiga 4000 by using a memfile describing nonexistent memory in the
Zorro II or 32-bit address space, below system RAM.
Sun-3 must be broken before this fix, as it fills in m68k_memory[0] in
config_sun3(), i.e. after m68k_parse_bootinfo().
Sun-3 is not fixed by this fix, as it uses its own paging_init(), not
the one in motorola.c.
Fixing Sun-3 requires adding memblock_add()/memblock_reserve() calls to
the Sun-3 memory management code.
v3:
- Move memblock_add() after memory block removal instead of sprinkling
memblock_remove() all over the place,
- Remove Suggested-by, Tested-by.
v2:
- Add missing #include .
---
arch/m68k/kernel/setup_mm.c | 2 --
arch/m68k/mm/motorola.c | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index a1a3eaeaf58c960d..ad0195cbe04255ea 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -164,8 +164,6 @@ static void __init m68k_parse_bootinfo(const struct
bi_record *record)
be32_to_cpu(m->addr);
m68k_memory[m68k_num_memory].size =
be32_to_cpu(m->size);
- memblock_add(m68k_memory[m68k_num_memory].addr,
-m68k_memory[m68k_num_memory].size);
m68k_num_memory++;
} else
pr_warn("%s: too many memory chunks\n",
diff --git a/arch/m68k/mm/motorola.c b/arch/m68k/mm/motorola.c
index 7497cf30bf1cd41b..3f3d0bf360910c0d 100644
--- a/arch/m68k/mm/motorola.c
+++ b/arch/m68k/mm/motorola.c
@@ -228,6 +228,7 @@ void __init paging_init(void)
min_addr = m68k_memory[0].addr;
max_addr = min_addr + m68k_memory[0].size;
+ memblock_add(m68k_memory[0].addr, m68k_memory[0].size);
for (i = 1; i < m68k_num_memory;) {
if (m68k_memory[i].addr < min_addr) {
printk("Ignoring memory chunk at 0x%lx:0x%lx before the
first chunk\n",
@@ -238,6 +239,7 @@ void __init paging_init(void)
