When running the kernel in Fast RAM on Atari:
Ignoring memory chunk at 0x0:0xe00000 before the first chunk
...
Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
Oops: 00000000
Modules linked in:
PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
SR: 2714 SP: (ptrval) a2: 005e3314
d0: 00000000 d1: 0000000a d2: 00000e00 d3: 00000000
d4: 005e1fc0 d5: 0000001a a0: 01000000 a1: 00000000
Process swapper (pid: 0, task=(ptrval))
Frame format=7 eff addr=00000736 ssw=0505 faddr=00000736
wb 1 stat/addr/data: 0000 00000000 00000000
wb 2 stat/addr/data: 0000 00000000 00000000
wb 3 stat/addr/data: 0000 00000736 00000000
push data: 00000000 00000000 00000000 00000000
Stack from 005e1f84:
00000000 0000000a 027d3260 006b5006 00000000 00000000 00000000 00000000
0004f062 0003a220 0069e272 005e1ff8 0000054c 00000000 00e00000 00000000
00000001 00693cd8 027d3260 0004f062 0003a220 00691be6 00000000 00000000
00000000 00000000 00000000 00000000 006b5006 00000000 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 <[email protected]>
Fixes: 1008a11590b966b4 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
Signed-off-by: Geert Uytterhoeven <[email protected]>
---
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 <linux/memblock.h>.
---
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)
(m68k_num_memory - i) * sizeof(struct m68k_mem_info));
continue;
}
+ memblock_add(m68k_memory[i].addr, m68k_memory[i].size);
addr = m68k_memory[i].addr + m68k_memory[i].size;
if (addr > max_addr)
max_addr = addr;
--
2.17.1
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:0xe00000 before the first chunk
> ...
> Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
> Oops: 00000000
> Modules linked in:
> PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
> SR: 2714 SP: (ptrval) a2: 005e3314
> d0: 00000000 d1: 0000000a d2: 00000e00 d3: 00000000
> d4: 005e1fc0 d5: 0000001a a0: 01000000 a1: 00000000
> Process swapper (pid: 0, task=(ptrval))
> Frame format=7 eff addr=00000736 ssw=0505 faddr=00000736
> wb 1 stat/addr/data: 0000 00000000 00000000
> wb 2 stat/addr/data: 0000 00000000 00000000
> wb 3 stat/addr/data: 0000 00000736 00000000
> push data: 00000000 00000000 00000000 00000000
> Stack from 005e1f84:
> 00000000 0000000a 027d3260 006b5006 00000000 00000000 00000000 00000000
> 0004f062 0003a220 0069e272 005e1ff8 0000054c 00000000 00e00000 00000000
> 00000001 00693cd8 027d3260 0004f062 0003a220 00691be6 00000000 00000000
> 00000000 00000000 00000000 00000000 006b5006 00000000 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 <[email protected]>
> Fixes: 1008a11590b966b4 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
> Signed-off-by: Geert Uytterhoeven <[email protected]>
> ---
> 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 <linux/memblock.h>.
> ---
> 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)
> (m68k_num_memory - i) * sizeof(struct m68k_mem_info));
> continue;
> }
> + memblock_add(m68k_memory[i].addr, m68k_memory[i].size);
> addr = m68k_memory[i].addr + m68k_memory[i].size;
> if (addr > max_addr)
> max_addr = addr;
> --
> 2.17.1
>
--
Sincerely yours,
Mike.
Hi Mike,
On Fri, Dec 7, 2018 at 10:02 PM Mike Rapoport <[email protected]> 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 -- [email protected]
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
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 - [email protected]
`. `' Freie Universitaet Berlin - [email protected]
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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 <[email protected]> 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 -- [email protected]
>
> 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.
Hi Andreas,
On Fri, Dec 7, 2018 at 5:50 PM Geert Uytterhoeven <[email protected]> wrote:
> When running the kernel in Fast RAM on Atari:
>
> Ignoring memory chunk at 0x0:0xe00000 before the first chunk
> ...
> Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
> Oops: 00000000
> Modules linked in:
> PC: [<0069dbac>] free_all_bootmem+0x12c/0x186
> SR: 2714 SP: (ptrval) a2: 005e3314
> d0: 00000000 d1: 0000000a d2: 00000e00 d3: 00000000
> d4: 005e1fc0 d5: 0000001a a0: 01000000 a1: 00000000
> Process swapper (pid: 0, task=(ptrval))
> Frame format=7 eff addr=00000736 ssw=0505 faddr=00000736
> wb 1 stat/addr/data: 0000 00000000 00000000
> wb 2 stat/addr/data: 0000 00000000 00000000
> wb 3 stat/addr/data: 0000 00000736 00000000
> push data: 00000000 00000000 00000000 00000000
> Stack from 005e1f84:
> 00000000 0000000a 027d3260 006b5006 00000000 00000000 00000000 00000000
> 0004f062 0003a220 0069e272 005e1ff8 0000054c 00000000 00e00000 00000000
> 00000001 00693cd8 027d3260 0004f062 0003a220 00691be6 00000000 00000000
> 00000000 00000000 00000000 00000000 006b5006 00000000 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 <[email protected]>
> Fixes: 1008a11590b966b4 ("m68k: switch to MEMBLOCK + NO_BOOTMEM")
> Signed-off-by: Geert Uytterhoeven <[email protected]>
Does this patch fix your crash?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
I'm now getting this Oops:
[ 65.390000] Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
[ 65.390000] Oops: 00000000
[ 65.390000] 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.390000] PC: [<00211544>] blk_throtl_bio+0x10e/0x592
[ 65.390000] SR: 2700 SP: (ptrval) a2: bf506dc0
[ 65.390000] d0: 00000001 d1: 03ce63fb d2: 00000000 d3: 00000016
[ 65.390000] d4: ffffa45b d5: 00000000 a0: 00000000 a1: 00000000
[ 65.390000] Process mkswap (pid: 289, task=(ptrval))
[ 65.390000] Frame format=7 eff addr=00000060 ssw=0505 faddr=00000060
[ 65.390000] wb 1 stat/addr/data: 0000 00000000 00000000
[ 65.390000] wb 2 stat/addr/data: 0000 00000000 00000000
[ 65.390000] wb 3 stat/addr/data: 0000 00000060 0001dba1
[ 65.390000] push data: 00000000 00000000 00000000 00000000
[ 65.390000] Stack from bd1b7bdc:
[ 65.390000] 00000008 00080000 ffffffff 00000002 ffffffff 00000006 bd6e0b40 bf596c18
[ 65.390000] 00682988 bd1b7c78 006000c0 00000003 00000000 00000080 00000005 001f28e4
[ 65.390000] bf596c18 bf4f1800 bd6e0b40 00000008 00080000 00000000 00001000 000a1848
[ 65.390000] 00000001 bd6e0b40 bf596c18 bd1b7e24 00080000 00000008 bf4f1800 bf596c18
[ 65.390000] bd1b7e24 bd1b7cec 00000001 bd1b7d3a 00095c52 0010ce96 000a1848 bd1b7cec
[ 65.390000] 001f3ea8 bd6e0b40 00000008 00080000 00000000 bd6e0b40 027616cc bd1b7e24
[ 65.390000] Call Trace: [<00080000>] check_ids+0x8/0x64
[ 65.390000] [<001f28e4>] generic_make_request_checks+0x3ca/0x4ee
[ 65.390000] [<00080000>] check_ids+0x8/0x64
[ 65.390000] [<00001000>] kernel_pg_dir+0x0/0x1000
[ 65.390000] [<000a1848>] __put_page+0x0/0x32
[ 65.390000] [<00080000>] check_ids+0x8/0x64
[ 65.390000] [<00095c52>] add_to_page_cache_lru+0x0/0xc4
[ 65.390000] [<0010ce96>] do_mpage_readpage+0x0/0x5cc
[ 65.390000] [<000a1848>] __put_page+0x0/0x32
[ 65.390000] [<001f3ea8>] generic_make_request+0x32/0x23c
[ 65.390000] [<00080000>] check_ids+0x8/0x64
[ 65.390000] [<001f417c>] submit_bio+0xca/0xfc
[ 65.390000] [<00095c52>] add_to_page_cache_lru+0x0/0xc4
[ 65.390000] [<0010ce96>] do_mpage_readpage+0x0/0x5cc
[ 65.390000] [<00095c52>] add_to_page_cache_lru+0x0/0xc4
[ 65.390000] [<0010ce96>] do_mpage_readpage+0x0/0x5cc
[ 65.390000] [<000a1848>] __put_page+0x0/0x32
[ 65.390000] [<0010ce8a>] mpage_bio_submit+0x2e/0x3a
[ 65.390000] [<0010d55a>] mpage_readpages+0xf8/0x108
[ 65.390000] [<00080000>] check_ids+0x8/0x64
[ 65.390000] [<00433256>] radix_tree_lookup+0x0/0x1a
[ 65.390000] [<0000bd6e>] rtc_ioctl+0x10c/0x2ae
[ 65.390000] [<00010100>] sixty_four+0x2/0x10
[ 65.390000] [<00001000>] kernel_pg_dir+0x0/0x1000
[ 65.390000] [<00107370>] blkdev_get_block+0x0/0x30
[ 65.390000] [<000a0eb4>] read_pages+0x3c/0xe6
[ 65.390000] [<00107370>] blkdev_get_block+0x0/0x30
[ 65.390000] [<0003ffff>] _sched_setscheduler+0x47/0x7e
[ 65.390000] [<00433256>] radix_tree_lookup+0x0/0x1a
[ 65.390000] [<0009cd42>] __alloc_pages_nodemask+0x0/0x86a
[ 65.390000] [<000a1188>] __do_page_cache_readahead+0x92/0x13e
[ 65.390000] [<000a10f6>] __do_page_cache_readahead+0x0/0x13e
[ 65.390000] [<000a1558>] force_page_cache_readahead+0x94/0xa2
[ 65.390000] [<000a1848>] __put_page+0x0/0x32
[ 65.390000] [<00096316>] unlock_page+0x0/0x2a
[ 65.390000] [<000970f4>] generic_file_buffered_read+0x11e/0x64a
[ 65.390000] [<000986f4>] generic_file_read_iter+0x100/0x132
[ 65.390000] [<000e0246>] __vfs_read+0x116/0x150
[ 65.390000] [<00020000>] _FP_CALL_TOP+0x9a46/0xd512
[ 65.390000] [<000e02dc>] vfs_read+0x5c/0xe4
[ 65.390000] [<000e0766>] ksys_read+0x42/0x8a
[ 65.390000] [<000e07c0>] sys_read+0x12/0x18
[ 65.390000] [<00002934>] syscall+0x8/0xc
[ 65.390000] [<0000c016>] bvme6000_gettimeoffset+0xaa/0xe2
[ 65.390000] Code: 2d20 012a 2839 005f 5124 226b 0014 7001 <b0a9> 0060 6600 0210 4a29 0064 6700 0208 4a8b 6700 0294 2053 2068 0014 2028 002c
Andreas.
--
Andreas Schwab, [email protected]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Dez 17 2018, Andreas Schwab <[email protected]> wrote:
> On Dez 13 2018, Andreas Schwab <[email protected]> wrote:
>
>> I'm now getting this Oops:
>>
>> [ 65.390000] Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
>> [ 65.390000] Oops: 00000000
>> [ 65.390000] 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.390000] 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, [email protected]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Dez 13 2018, Andreas Schwab <[email protected]> wrote:
> I'm now getting this Oops:
>
> [ 65.390000] Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
> [ 65.390000] Oops: 00000000
> [ 65.390000] 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.390000] PC: [<00211544>] blk_throtl_bio+0x10e/0x592
And the crash does not occur when I revert commit 1008a11590.
Andreas.
--
Andreas Schwab, [email protected]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Hi Andreas,
On Mon, Dec 17, 2018 at 8:34 PM Andreas Schwab <[email protected]> wrote:
> On Dez 17 2018, Andreas Schwab <[email protected]> wrote:
> > On Dez 13 2018, Andreas Schwab <[email protected]> wrote:
> >> I'm now getting this Oops:
> >>
> >> [ 65.390000] Unable to handle kernel NULL pointer dereference at virtual address (ptrval)
> >> [ 65.390000] Oops: 00000000
> >> [ 65.390000] 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.390000] 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 -- [email protected]
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