Re: Kernel versions 6.x don't boot on Amiga 4000
On Mon, 27 Feb 2023, I wrote:
> On Mon, 27 Feb 2023, Michael Schmitz wrote:
>
> >
> > I wonder whether Finn's memtest patch merely exposed another MM bug
> >
>
> A kernel patch may be easier than a bootloader patch (even if this is a
> bootloader bug) particularly if it affects multiple platforms.
>
> A partial revert of my patch (below) will probably avoid the issue, but
> with the side effect that use of memtest will clobber the initrd.
>
Maybe that's for the best now that the initrd/initramfs has grown so
large. That portion of memory is presently skipped by memtest, which means
you'd have to disable the initrd to get good coverage from memtest anyway.
> The initrd and memtest features aren't usually needed together. At the
> time when I needed the memtest feature I did not have confidence in the
> hardeare. An initrd wasn't very useful at that point.
>
> diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
> index 3a2bb2e8fdad..92f1b9268dff 100644
> --- a/arch/m68k/kernel/setup_mm.c
> +++ b/arch/m68k/kernel/setup_mm.c
> @@ -326,6 +326,8 @@ void __init setup_arch(char **cmdline_p)
> panic("No configuration setup");
> }
>
> + paging_init();
> +
> #ifdef CONFIG_BLK_DEV_INITRD
> if (m68k_ramdisk.size) {
> memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
> @@ -335,8 +337,6 @@ void __init setup_arch(char **cmdline_p)
> }
> #endif
>
> - paging_init();
> -
> #ifdef CONFIG_NATFEAT
> nf_init();
> #endif
>
>
Re: Kernel versions 6.x don't boot on Amiga 4000
Hi Finn,
FTR, here is the diff of the dmesg between good and bad:
+initrd: 07f61166 - 0800
This is wrong (note the 6 trailing zeros), as phys_to_virt() is not
working correctly yet (module_fixup() is called from paging_init()).
Zone ranges:
DMA [mem 0x0740-0x007f]
Normal empty
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0740-0x07ff]
Initmem setup node 0 [mem 0x0740-0x07ff]
-initrd: 00b61166 - 00c0
This is correct (note the 5 trailing zeros).
-pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
-pcpu-alloc: [0] 0
[...]
+Unable to handle kernel access at virtual address (ptrval)
+Oops:
+Modules linked in:
+PC: [<002c11be>] memcmp+0x2c/0x5c
+SR: 2700 SP: (ptrval) a2: 003bd560
+d0: 0035eb83d1: 07f8d2: 002c1192d3: 00e6
+d4: 000684e8d5: 00447000a0: 000ca1: 07f4
+Process swapper (pid: 0, task=(ptrval))
+Frame format=7 eff addr=003bbfbc ssw=0505 faddr=07f4
+wb 1 stat/addr/data: 0005 00447000 07401000
+wb 2 stat/addr/data: 0005 00e6 000684e8
+wb 3 stat/addr/data: 0005 003bbfb4 002c1192
+push data: 07401000 002c7d82 07401000 074a2cf4
+Stack from 003bbfb4:
+002c1192 00e6 002c7d82 00428eda 07f4 0035eb7f 000c 00447000
+00e6 000684e8 00447000 07401000 074bec08 07401000 074a2cf4 07f0
+00440406 00428322
+Call Trace: [<002c1192>] memcmp+0x0/0x5c
+[<002c7d82>] _printk+0x0/0x18
+[<00428eda>] start_kernel+0x80/0x5b0
+[<000684e8>] pcpu_alloc+0x88/0x3b4
+[<00428322>] _sinittext+0x322/0x9b0
On Mon, Feb 27, 2023 at 7:30 AM Finn Thain wrote:
> On Mon, 27 Feb 2023, Michael Schmitz wrote:
> > I wonder whether Finn's memtest patch merely exposed another MM bug
>
> A kernel patch may be easier than a bootloader patch (even if this is a
> bootloader bug) particularly if it affects multiple platforms.
>
> A partial revert of my patch (below) will probably avoid the issue, but
> with the side effect that use of memtest will clobber the initrd.
Which we can avoid, by moving the ramdisk handling inside paging_init().
> The initrd and memtest features aren't usually needed together. At the
> time when I needed the memtest feature I did not have confidence in the
> hardeare. An initrd wasn't very useful at that point.
>
> diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
> index 3a2bb2e8fdad..92f1b9268dff 100644
> --- a/arch/m68k/kernel/setup_mm.c
> +++ b/arch/m68k/kernel/setup_mm.c
> @@ -326,6 +326,8 @@ void __init setup_arch(char **cmdline_p)
> panic("No configuration setup");
> }
>
> + paging_init();
> +
> #ifdef CONFIG_BLK_DEV_INITRD
> if (m68k_ramdisk.size) {
> memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
Presumably something in memblock_reserve() relies on having
called paging_init() before?
I'll do some more debugging later today...
> @@ -335,8 +337,6 @@ void __init setup_arch(char **cmdline_p)
> }
> #endif
>
> - paging_init();
> -
> #ifdef CONFIG_NATFEAT
> nf_init();
> #endif
>
--
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: Kernel versions 6.x don't boot on Amiga 4000
Hi,
On 27.2.2023 9.19, Michael Schmitz wrote:
Am 27.02.2023 um 18:55 schrieb Finn Thain:
On Mon, 27 Feb 2023, Michael Schmitz wrote:
Bisected to commit 376e3fdecb0dcae2 ("m68k: Enable memtest
functionality") in v5.17-rc1. Reverting that on top of latest fixes
the issue.
Yes, I'm sorry to say that was the only likely candidate. Can't see why
though - are Macs all configured to have RAM start at address zero, and
possibly contiguous, Finn?
I don't really understand your question. This was not a Mac patch. The
issue seems to be about the locations initrd_start and initrd_end in
relation to the various memory segments (?)
I didn't realize that - thanks for pointing this out.
>
This seems to be the same bug that was raised about 6 months ago... I had
thought it was a bootloader bug but I'm out of my depth here.
https://lists.debian.org/debian-68k/2022/09/msg00047.html
https://lists.debian.org/debian-68k/2022/09/msg00051.html
https://lists.debian.org/debian-68k/2022/09/msg00055.html
I had forgotten all about that one... Thanks for jogging my memory!
In this case though, the bug happens when the ramdisk is loaded in the
lowest address memory chunk, at least at a lower address than the one
the kernel runs from.
I'm wondering whether this old Atari side boot issue is related at all...
When adding Linux bootinfo support to Hatari emulator (from Aranym
emulator) few years ago, I noticed that:
"Linux barfs at ST-RAM memory range given after TT-RAM. However, if
kernel is loaded to TT-RAM and ST-RAM range is given before TT-RAM
range, kernel crashes."
=> Only working config was Linux being loaded to ST-RAM, TT-RAM being
given only after that in bootinfo, and initrd ramdisk after kernel.
Based on mails in archive, this seemed to have been a known Linux/Atari
issue already in 2013.
The crashes in the above thread were all from boots where the initrd got
loaded at the end of the memory chunk the kernel runs from.
Time to try using copy_from_kernel_nofault() to copy the ramdisk into
its final location? (just kidding)
- Eero
PS. For people familiar only with Amiga terminology, ST-RAM = chip RAM,
TT-RAM = fast RAM.
Re: Kernel versions 6.x don't boot on Amiga 4000
Hi Geert,
adding Mike Rapoport to the recipient list who would know whether
memblock_reserve() relies on paging_init() having run.
Cheers,
Michael
Am 27.02.2023 um 21:26 schrieb Geert Uytterhoeven:
Hi Finn,
FTR, here is the diff of the dmesg between good and bad:
+initrd: 07f61166 - 0800
This is wrong (note the 6 trailing zeros), as phys_to_virt() is not
working correctly yet (module_fixup() is called from paging_init()).
Zone ranges:
DMA [mem 0x0740-0x007f]
Normal empty
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0740-0x07ff]
Initmem setup node 0 [mem 0x0740-0x07ff]
-initrd: 00b61166 - 00c0
This is correct (note the 5 trailing zeros).
-pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
-pcpu-alloc: [0] 0
[...]
+Unable to handle kernel access at virtual address (ptrval)
+Oops:
+Modules linked in:
+PC: [<002c11be>] memcmp+0x2c/0x5c
+SR: 2700 SP: (ptrval) a2: 003bd560
+d0: 0035eb83d1: 07f8d2: 002c1192d3: 00e6
+d4: 000684e8d5: 00447000a0: 000ca1: 07f4
+Process swapper (pid: 0, task=(ptrval))
+Frame format=7 eff addr=003bbfbc ssw=0505 faddr=07f4
+wb 1 stat/addr/data: 0005 00447000 07401000
+wb 2 stat/addr/data: 0005 00e6 000684e8
+wb 3 stat/addr/data: 0005 003bbfb4 002c1192
+push data: 07401000 002c7d82 07401000 074a2cf4
+Stack from 003bbfb4:
+002c1192 00e6 002c7d82 00428eda 07f4 0035eb7f 000c 00447000
+00e6 000684e8 00447000 07401000 074bec08 07401000 074a2cf4 07f0
+00440406 00428322
+Call Trace: [<002c1192>] memcmp+0x0/0x5c
+[<002c7d82>] _printk+0x0/0x18
+[<00428eda>] start_kernel+0x80/0x5b0
+[<000684e8>] pcpu_alloc+0x88/0x3b4
+[<00428322>] _sinittext+0x322/0x9b0
On Mon, Feb 27, 2023 at 7:30 AM Finn Thain wrote:
On Mon, 27 Feb 2023, Michael Schmitz wrote:
I wonder whether Finn's memtest patch merely exposed another MM bug
A kernel patch may be easier than a bootloader patch (even if this is a
bootloader bug) particularly if it affects multiple platforms.
A partial revert of my patch (below) will probably avoid the issue, but
with the side effect that use of memtest will clobber the initrd.
Which we can avoid, by moving the ramdisk handling inside paging_init().
The initrd and memtest features aren't usually needed together. At the
time when I needed the memtest feature I did not have confidence in the
hardeare. An initrd wasn't very useful at that point.
diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
index 3a2bb2e8fdad..92f1b9268dff 100644
--- a/arch/m68k/kernel/setup_mm.c
+++ b/arch/m68k/kernel/setup_mm.c
@@ -326,6 +326,8 @@ void __init setup_arch(char **cmdline_p)
panic("No configuration setup");
}
+ paging_init();
+
#ifdef CONFIG_BLK_DEV_INITRD
if (m68k_ramdisk.size) {
memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
Presumably something in memblock_reserve() relies on having
called paging_init() before?
I'll do some more debugging later today...
@@ -335,8 +337,6 @@ void __init setup_arch(char **cmdline_p)
}
#endif
- paging_init();
-
#ifdef CONFIG_NATFEAT
nf_init();
#endif
Re: Kernel versions 6.x don't boot on Amiga 4000
Eero,
that issue (kernel running from TT-RAM) was fixed quite a few years ago
(but maybe not in 2013), in the sense that ST-RAM could be used for
drivers (SCSI, atafb). Using ST-RAM as normal VM should have been made a
lot easier by changing to memblock, but AFAIR there are still some bits
missing.
RAM must be listed in bootinfo with the chunk holding the kernel first,
_not_ in ascending address order, so that second option is expected to
crash.
This isn't related to the current issue for all I can see.
Cheers,
Michael
Am 27.02.2023 um 22:41 schrieb Eero Tamminen:
Hi,
On 27.2.2023 9.19, Michael Schmitz wrote:
Am 27.02.2023 um 18:55 schrieb Finn Thain:
On Mon, 27 Feb 2023, Michael Schmitz wrote:
Bisected to commit 376e3fdecb0dcae2 ("m68k: Enable memtest
functionality") in v5.17-rc1. Reverting that on top of latest fixes
the issue.
Yes, I'm sorry to say that was the only likely candidate. Can't see why
though - are Macs all configured to have RAM start at address zero, and
possibly contiguous, Finn?
I don't really understand your question. This was not a Mac patch. The
issue seems to be about the locations initrd_start and initrd_end in
relation to the various memory segments (?)
I didn't realize that - thanks for pointing this out.
This seems to be the same bug that was raised about 6 months ago... I
had
thought it was a bootloader bug but I'm out of my depth here.
https://lists.debian.org/debian-68k/2022/09/msg00047.html
https://lists.debian.org/debian-68k/2022/09/msg00051.html
https://lists.debian.org/debian-68k/2022/09/msg00055.html
I had forgotten all about that one... Thanks for jogging my memory!
In this case though, the bug happens when the ramdisk is loaded in the
lowest address memory chunk, at least at a lower address than the one
the kernel runs from.
I'm wondering whether this old Atari side boot issue is related at all...
When adding Linux bootinfo support to Hatari emulator (from Aranym
emulator) few years ago, I noticed that:
"Linux barfs at ST-RAM memory range given after TT-RAM. However, if
kernel is loaded to TT-RAM and ST-RAM range is given before TT-RAM
range, kernel crashes."
=> Only working config was Linux being loaded to ST-RAM, TT-RAM being
given only after that in bootinfo, and initrd ramdisk after kernel.
Based on mails in archive, this seemed to have been a known Linux/Atari
issue already in 2013.
The crashes in the above thread were all from boots where the initrd
got loaded at the end of the memory chunk the kernel runs from.
Time to try using copy_from_kernel_nofault() to copy the ramdisk into
its final location? (just kidding)
- Eero
PS. For people familiar only with Amiga terminology, ST-RAM = chip RAM,
TT-RAM = fast RAM.
Re: Kernel versions 6.x don't boot on Amiga 4000
Hi,
On Mon, Feb 27, 2023 at 10:42:34PM +1300, Michael Schmitz wrote:
> Hi Geert,
>
> adding Mike Rapoport to the recipient list who would know whether
> memblock_reserve() relies on paging_init() having run.
>
> Cheers,
>
> Michael
>
> Am 27.02.2023 um 21:26 schrieb Geert Uytterhoeven:
> > Hi Finn,
> >
> > FTR, here is the diff of the dmesg between good and bad:
> >
> > +initrd: 07f61166 - 0800
> >
> > This is wrong (note the 6 trailing zeros), as phys_to_virt() is not
> > working correctly yet (module_fixup() is called from paging_init()).
> >
> > Zone ranges:
> >DMA [mem 0x0740-0x007f]
> >Normal empty
> > Movable zone start for each node
> > Early memory node ranges
> >node 0: [mem 0x0740-0x07ff]
> > Initmem setup node 0 [mem 0x0740-0x07ff]
> > -initrd: 00b61166 - 00c0
> >
> > This is correct (note the 5 trailing zeros).
> >
> > -pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> > -pcpu-alloc: [0] 0
> > [...]
> > +Unable to handle kernel access at virtual address (ptrval)
> > +Oops:
> > +Modules linked in:
> > +PC: [<002c11be>] memcmp+0x2c/0x5c
> > +SR: 2700 SP: (ptrval) a2: 003bd560
> > +d0: 0035eb83d1: 07f8d2: 002c1192d3: 00e6
> > +d4: 000684e8d5: 00447000a0: 000ca1: 07f4
> > +Process swapper (pid: 0, task=(ptrval))
> > +Frame format=7 eff addr=003bbfbc ssw=0505 faddr=07f4
> > +wb 1 stat/addr/data: 0005 00447000 07401000
> > +wb 2 stat/addr/data: 0005 00e6 000684e8
> > +wb 3 stat/addr/data: 0005 003bbfb4 002c1192
> > +push data: 07401000 002c7d82 07401000 074a2cf4
> > +Stack from 003bbfb4:
> > +002c1192 00e6 002c7d82 00428eda 07f4 0035eb7f 000c 00447000
> > +00e6 000684e8 00447000 07401000 074bec08 07401000 074a2cf4 07f0
> > +00440406 00428322
> > +Call Trace: [<002c1192>] memcmp+0x0/0x5c
> > +[<002c7d82>] _printk+0x0/0x18
> > +[<00428eda>] start_kernel+0x80/0x5b0
> > +[<000684e8>] pcpu_alloc+0x88/0x3b4
> > +[<00428322>] _sinittext+0x322/0x9b0
> >
> > On Mon, Feb 27, 2023 at 7:30 AM Finn Thain wrote:
> > > On Mon, 27 Feb 2023, Michael Schmitz wrote:
> > > > I wonder whether Finn's memtest patch merely exposed another MM bug
> > >
> > > A kernel patch may be easier than a bootloader patch (even if this is a
> > > bootloader bug) particularly if it affects multiple platforms.
> > >
> > > A partial revert of my patch (below) will probably avoid the issue, but
> > > with the side effect that use of memtest will clobber the initrd.
> >
> > Which we can avoid, by moving the ramdisk handling inside paging_init().
> >
> > > The initrd and memtest features aren't usually needed together. At the
> > > time when I needed the memtest feature I did not have confidence in the
> > > hardeare. An initrd wasn't very useful at that point.
> > >
> > > diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
> > > index 3a2bb2e8fdad..92f1b9268dff 100644
> > > --- a/arch/m68k/kernel/setup_mm.c
> > > +++ b/arch/m68k/kernel/setup_mm.c
> > > @@ -326,6 +326,8 @@ void __init setup_arch(char **cmdline_p)
> > > panic("No configuration setup");
> > > }
> > >
> > > + paging_init();
> > > +
> > > #ifdef CONFIG_BLK_DEV_INITRD
> > > if (m68k_ramdisk.size) {
> > > memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
> >
> > Presumably something in memblock_reserve() relies on having
> > called paging_init() before?
memblock_reserve() does not rely on paging_init() as it operates on
physical addresses and it does not care if memory was already registered.
What does rely on paging_init() it's phys_to_virt() in the line after
memblock_reserve():
initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
initrd_end = initrd_start + m68k_ramdisk.size;
So to have both memtest and initrd we'd need something like
memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
paging_init() {
/* setup page tables and memblock */
early_memtest();
}
initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
or
paging_init(); /* without early_memtest() */
memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
early_memtest();
> > I'll do some more debugging later today...
> >
> > > @@ -335,8 +337,6 @@ void __init setup_arch(char **cmdline_p)
> > > }
> > > #endif
> > >
> > > - paging_init();
> > > -
> > > #ifdef CONFIG_NATFEAT
> > > nf_init();
> > > #endif
> > >
> >
> >
--
Sincerely yours,
Mike.
Re: Kernel versions 6.x don't boot on Amiga 4000
Hi Mike,
On Mon, Feb 27, 2023 at 12:34 PM Mike Rapoport wrote:
> On Mon, Feb 27, 2023 at 10:42:34PM +1300, Michael Schmitz wrote:
> > Am 27.02.2023 um 21:26 schrieb Geert Uytterhoeven:
> > > FTR, here is the diff of the dmesg between good and bad:
> > >
> > > +initrd: 07f61166 - 0800
> > >
> > > This is wrong (note the 6 trailing zeros), as phys_to_virt() is not
> > > working correctly yet (module_fixup() is called from paging_init()).
> > >
> > > Zone ranges:
> > >DMA [mem 0x0740-0x007f]
> > >Normal empty
> > > Movable zone start for each node
> > > Early memory node ranges
> > >node 0: [mem 0x0740-0x07ff]
> > > Initmem setup node 0 [mem 0x0740-0x07ff]
> > > -initrd: 00b61166 - 00c0
> > >
> > > This is correct (note the 5 trailing zeros).
> > >
> > > -pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> > > -pcpu-alloc: [0] 0
> > > [...]
> > > +Unable to handle kernel access at virtual address (ptrval)
> > > +Oops:
> > > +Modules linked in:
> > > +PC: [<002c11be>] memcmp+0x2c/0x5c
> > > +SR: 2700 SP: (ptrval) a2: 003bd560
> > > +d0: 0035eb83d1: 07f8d2: 002c1192d3: 00e6
> > > +d4: 000684e8d5: 00447000a0: 000ca1: 07f4
> > > +Process swapper (pid: 0, task=(ptrval))
> > > +Frame format=7 eff addr=003bbfbc ssw=0505 faddr=07f4
> > > +wb 1 stat/addr/data: 0005 00447000 07401000
> > > +wb 2 stat/addr/data: 0005 00e6 000684e8
> > > +wb 3 stat/addr/data: 0005 003bbfb4 002c1192
> > > +push data: 07401000 002c7d82 07401000 074a2cf4
> > > +Stack from 003bbfb4:
> > > +002c1192 00e6 002c7d82 00428eda 07f4 0035eb7f 000c
> > > 00447000
> > > +00e6 000684e8 00447000 07401000 074bec08 07401000 074a2cf4
> > > 07f0
> > > +00440406 00428322
> > > +Call Trace: [<002c1192>] memcmp+0x0/0x5c
> > > +[<002c7d82>] _printk+0x0/0x18
> > > +[<00428eda>] start_kernel+0x80/0x5b0
> > > +[<000684e8>] pcpu_alloc+0x88/0x3b4
> > > +[<00428322>] _sinittext+0x322/0x9b0
> > >
> > > On Mon, Feb 27, 2023 at 7:30 AM Finn Thain wrote:
> > > > On Mon, 27 Feb 2023, Michael Schmitz wrote:
> > > > > I wonder whether Finn's memtest patch merely exposed another MM bug
> > > >
> > > > A kernel patch may be easier than a bootloader patch (even if this is a
> > > > bootloader bug) particularly if it affects multiple platforms.
> > > >
> > > > A partial revert of my patch (below) will probably avoid the issue, but
> > > > with the side effect that use of memtest will clobber the initrd.
> > >
> > > Which we can avoid, by moving the ramdisk handling inside paging_init().
> > >
> > > > The initrd and memtest features aren't usually needed together. At the
> > > > time when I needed the memtest feature I did not have confidence in the
> > > > hardeare. An initrd wasn't very useful at that point.
> > > >
> > > > diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
> > > > index 3a2bb2e8fdad..92f1b9268dff 100644
> > > > --- a/arch/m68k/kernel/setup_mm.c
> > > > +++ b/arch/m68k/kernel/setup_mm.c
> > > > @@ -326,6 +326,8 @@ void __init setup_arch(char **cmdline_p)
> > > > panic("No configuration setup");
> > > > }
> > > >
> > > > + paging_init();
> > > > +
> > > > #ifdef CONFIG_BLK_DEV_INITRD
> > > > if (m68k_ramdisk.size) {
> > > > memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
> > >
> > > Presumably something in memblock_reserve() relies on having
> > > called paging_init() before?
>
> memblock_reserve() does not rely on paging_init() as it operates on
> physical addresses and it does not care if memory was already registered.
>
> What does rely on paging_init() it's phys_to_virt() in the line after
> memblock_reserve():
>
> initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
> initrd_end = initrd_start + m68k_ramdisk.size;
>
> So to have both memtest and initrd we'd need something like
>
> memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
>
> paging_init() {
> /* setup page tables and memblock */
> early_memtest();
> }
>
> initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
>
> or
>
> paging_init(); /* without early_memtest() */
>
> memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
> initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
>
> early_memtest();
Of course... /me bangs his head against the TFT for not having
realized before the values saved into initrd_{start,end} are not just
for printing in the pr_info() line...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with t
Re: Kernel versions 6.x don't boot on Amiga 4000
Hi Geert,
On Mon, Feb 27, 2023 at 01:31:23PM +0100, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Mon, Feb 27, 2023 at 12:34 PM Mike Rapoport wrote:
> > On Mon, Feb 27, 2023 at 10:42:34PM +1300, Michael Schmitz wrote:
> > > Am 27.02.2023 um 21:26 schrieb Geert Uytterhoeven:
> > > > > On Mon, 27 Feb 2023, Michael Schmitz wrote:
> > > > > > I wonder whether Finn's memtest patch merely exposed another MM bug
> > > > >
> > > > > A kernel patch may be easier than a bootloader patch (even if this is
> > > > > a
> > > > > bootloader bug) particularly if it affects multiple platforms.
> > > > >
> > > > > A partial revert of my patch (below) will probably avoid the issue,
> > > > > but
> > > > > with the side effect that use of memtest will clobber the initrd.
> > > >
> > > > Which we can avoid, by moving the ramdisk handling inside paging_init().
> > > >
> > > > > The initrd and memtest features aren't usually needed together. At the
> > > > > time when I needed the memtest feature I did not have confidence in
> > > > > the
> > > > > hardeare. An initrd wasn't very useful at that point.
> > > > >
> > > > > diff --git a/arch/m68k/kernel/setup_mm.c b/arch/m68k/kernel/setup_mm.c
> > > > > index 3a2bb2e8fdad..92f1b9268dff 100644
> > > > > --- a/arch/m68k/kernel/setup_mm.c
> > > > > +++ b/arch/m68k/kernel/setup_mm.c
> > > > > @@ -326,6 +326,8 @@ void __init setup_arch(char **cmdline_p)
> > > > > panic("No configuration setup");
> > > > > }
> > > > >
> > > > > + paging_init();
> > > > > +
> > > > > #ifdef CONFIG_BLK_DEV_INITRD
> > > > > if (m68k_ramdisk.size) {
> > > > > memblock_reserve(m68k_ramdisk.addr,
> > > > > m68k_ramdisk.size);
> > > >
> > > > Presumably something in memblock_reserve() relies on having
> > > > called paging_init() before?
> >
> > memblock_reserve() does not rely on paging_init() as it operates on
> > physical addresses and it does not care if memory was already registered.
> >
> > What does rely on paging_init() it's phys_to_virt() in the line after
> > memblock_reserve():
> >
> > initrd_start = (unsigned
> > long)phys_to_virt(m68k_ramdisk.addr);
> > initrd_end = initrd_start + m68k_ramdisk.size;
> >
> > So to have both memtest and initrd we'd need something like
> >
> > memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
> >
> > paging_init() {
> > /* setup page tables and memblock */
> > early_memtest();
> > }
> >
> > initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
> >
> > or
> >
> > paging_init(); /* without early_memtest() */
> >
> > memblock_reserve(m68k_ramdisk.addr, m68k_ramdisk.size);
> > initrd_start = (unsigned long)phys_to_virt(m68k_ramdisk.addr);
> >
> > early_memtest();
>
> Of course... /me bangs his head against the TFT for not having
> realized before the values saved into initrd_{start,end} are not just
> for printing in the pr_info() line...
Happens to the best of us :)
> 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.
