From: Mike Rapoport <rppt@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Michael Schmitz <schmitzmic@gmail.com>,
Finn Thain <fthain@linux-m68k.org>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
linux-m68k@lists.linux-m68k.org, debian-68k@lists.debian.org
Subject: Re: Kernel versions 6.x don't boot on Amiga 4000
Date: Mon, 27 Feb 2023 14:40:40 +0200 [thread overview]
Message-ID: <Y/ykyFEDt5tYoWp3@kernel.org> (raw)
In-Reply-To: <CAMuHMdWk+D1jDEFn1aSmNwKR08jc3wKeynE8Nkvf71T8cSZV4w@mail.gmail.com>
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 <rppt@kernel.org> 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 -- geert@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.
prev parent reply other threads:[~2023-02-27 12:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-21 14:50 Kernel versions 6.x don't boot on Amiga 4000 John Paul Adrian Glaubitz
2023-02-21 14:55 ` Geert Uytterhoeven
2023-02-21 15:53 ` John Paul Adrian Glaubitz
2023-02-21 21:09 ` Michael Schmitz
2023-02-21 21:46 ` John Paul Adrian Glaubitz
2023-02-22 0:53 ` Michael Schmitz
2023-02-23 18:24 ` Michael Schmitz
2023-02-26 11:02 ` Geert Uytterhoeven
2023-02-26 12:52 ` Geert Uytterhoeven
2023-02-27 2:01 ` Michael Schmitz
2023-02-27 5:55 ` Finn Thain
2023-02-27 7:19 ` Michael Schmitz
2023-02-27 9:41 ` Eero Tamminen
2023-02-27 9:52 ` Michael Schmitz
2023-02-27 2:09 ` Michael Schmitz
2023-02-27 6:33 ` Finn Thain
2023-02-27 8:01 ` Finn Thain
2023-02-27 8:26 ` Geert Uytterhoeven
2023-02-27 9:42 ` Michael Schmitz
2023-02-27 11:34 ` Mike Rapoport
2023-02-27 12:31 ` Geert Uytterhoeven
2023-02-27 12:40 ` Mike Rapoport [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y/ykyFEDt5tYoWp3@kernel.org \
--to=rppt@kernel.org \
--cc=debian-68k@lists.debian.org \
--cc=fthain@linux-m68k.org \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=schmitzmic@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox