Hi Geert,
Am 14.03.2025 um 21:51 schrieb Geert Uytterhoeven:
Hi Michael,
On Thu, 13 Mar 2025 at 19:32, Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
On 14/03/25 04:51, Geert Uytterhoeven wrote:
On Thu, 13 Mar 2025 at 16:35, Mike Rapoport <rppt@xxxxxxxxxx> wrote:
On Thu, Mar 13, 2025 at 04:19:10PM +0100, Geert Uytterhoeven wrote:
On Thu, 13 Mar 2025 at 14:53, Mike Rapoport <rppt@xxxxxxxxxx> wrote:
From: "Mike Rapoport (Microsoft)" <rppt@xxxxxxxxxx>
The point where the memory is released from memblock to the buddy allocator
is hidden inside arch-specific mem_init()s and the call to
memblock_free_all() is needlessly duplicated in every artiste cure and
after introduction of arch_mm_preinit() hook, mem_init() implementation on
many architecture only contains the call to memblock_free_all().
Pull memblock_free_all() call into mm_core_init() and drop mem_init() on
relevant architectures to make it more explicit where the free memory is
released from memblock to the buddy allocator and to reduce code
duplication in architecture specific code.
Acked-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> # x86
Signed-off-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
arch/m68k/mm/init.c | 2 --
Acked-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> # m68k
Thanks :)
While working on this I was wondering if init_pointer_tables() can be moved
from mem_init() to motorola::paging_init(). It seems to me that it can, but
I wasn't sure enough so I left it there for now.
Oh, that would be nice, as it would allow us to get rid of the ugly
#ifdef, and (in the context of this series) of our own mem_init().
It looked promising at first, but crashed later (on ARAnyM):
VFS: Mounted root (ext3 filesystem) readonly on device 8:1.
devtmpfs: mounted
Unable to handle kernel access at virtual address (ptrval)
Oops: 00000000
Modules linked in:
PC: [<0001273b>] xdnrm_dn+0xf/0x10
SR: 2208 SP: (ptrval) a2: 01030000
d0: 00000097 d1: ffffffff d2: 00000001 d3: 00563000
d4: 0055f924 d5: 00421b56 a0: 0102e000 a1: 0102e000
Process swapper (pid: 1, task=(ptrval))
Frame format=7 eff addr=00ffee01 ssw=0545 faddr=00ffee01
What's at that address? The 14 MB ST-RAM ought to end at 0xe00000 (which
would have been left unmapped if FastRAM is in use). MMIO area starts at
0xff0000 but base addresses there are 0xff8xxx, 0xffaxxx or 0xfffxxx
from what I've found.
As paging_init() is done much earlier than mem_int(), I guess it just
failed to mark the initial pointer table as reserved, and scribbled over
it later, so I wouldn't trust anything in that backtrace...
That wasn't from the backtrace but from the exception frame. I'd hope we
can trust that one ...
Cheers,
Michael
Gr{oetje,eeting}s,
Geert
