From: Mike Rapoport <rppt@kernel.org>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
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 13:34:32 +0200 [thread overview]
Message-ID: <Y/yVSM5Mi/Qdc2N1@kernel.org> (raw)
In-Reply-To: <2159d5c6-ee10-06e6-8085-831914ceccce@gmail.com>
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 - 08000000
> >
> > 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 0x0000000007400000-0x0000007fffffffff]
> > Normal empty
> > Movable zone start for each node
> > Early memory node ranges
> > node 0: [mem 0x0000000007400000-0x0000000007ffffff]
> > Initmem setup node 0 [mem 0x0000000007400000-0x0000000007ffffff]
> > -initrd: 00b61166 - 00c00000
> >
> > 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: 00000000
> > +Modules linked in:
> > +PC: [<002c11be>] memcmp+0x2c/0x5c
> > +SR: 2700 SP: (ptrval) a2: 003bd560
> > +d0: 0035eb83 d1: 07fffff8 d2: 002c1192 d3: 000000e6
> > +d4: 000684e8 d5: 00447000 a0: 0000000c a1: 07fffff4
> > +Process swapper (pid: 0, task=(ptrval))
> > +Frame format=7 eff addr=003bbfbc ssw=0505 faddr=07fffff4
> > +wb 1 stat/addr/data: 0005 00447000 07401000
> > +wb 2 stat/addr/data: 0005 000000e6 000684e8
> > +wb 3 stat/addr/data: 0005 003bbfb4 002c1192
> > +push data: 07401000 002c7d82 07401000 074a2cf4
> > +Stack from 003bbfb4:
> > +002c1192 000000e6 002c7d82 00428eda 07fffff4 0035eb7f 0000000c 00447000
> > +000000e6 000684e8 00447000 07401000 074bec08 07401000 074a2cf4 07fffff0
> > +00440406 00000000 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 <fthain@linux-m68k.org> 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.
next prev parent reply other threads:[~2023-02-27 11:34 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 [this message]
2023-02-27 12:31 ` Geert Uytterhoeven
2023-02-27 12:40 ` Mike Rapoport
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/yVSM5Mi/Qdc2N1@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.