Hi Michael,
On Fri, Sep 9, 2022 at 7:03 AM Michael Schmitz <schmitz...@gmail.com> wrote:
> Am 09.09.2022 um 13:36 schrieb Finn Thain:
>
> >> Kernel 5.19, intrd 5.19
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >> [ 0.000000] Linux version 5.19.0-1-m68k
> >> (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld
> >> (GNU Binutils for Debian) 2.38.90.20220713) #1 Debian 5.19.6-1 (2022-09-01)
> >> [ 0.000000] printk: console [debug0] enabled
> >> [ 0.000000] Amiga hardware found: [A3000] VIDEO BLITTER AMBER_FF AUDIO
> >> FLOPPY A3000_SCSI KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA
> >> DENISE_HR AGNUS_HR_PAL MAGIC_REKICK ZORRO3
> >> [ 0.000000] initrd: 0f7f6794 - 10000000
> >
> > Length is 0x80986d.
> >
> ...
> >> Kernel 5.18, intrid 5.18
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >> [ 0.000000] Linux version 5.18.0-3-m68k
> >> (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-4) 11.3.0, GNU ld
> >> (GNU Binutils for Debian) 2.38.90.20220713) #1 Debian 5.18.14-1
> >> (2022-07-23)
> >> [ 0.000000] printk: console [debug0] enabled
> >> [ 0.000000] Amiga hardware found: [A3000] VIDEO BLITTER AMBER_FF AUDIO
> >> FLOPPY A3000_SCSI KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA
> >> DENISE_HR AGNUS_HR_PAL MAGIC_REKICK ZORRO3
> >> [ 0.000000] initrd: 0f7f7b16 - 10000000
> >
> > Length is 0x8084eb.
> ...
> >> kernel 5.19, intrid 5.15
> >>
> >>>>>>>>>>>>>>>>>>>>>>
> >> [ 0.000000] Linux version 5.19.0-1-m68k
> >> (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld
> >> (GNU Binutils for Debian) 2.38.90.20220713) #1 Debian 5.19.6-1 (2022-09-01)
> >> [ 0.000000] printk: console [debug0] enabled
> >> [ 0.000000] Amiga hardware found: [A3000] VIDEO BLITTER AMBER_FF AUDIO
> >> FLOPPY A3000_SCSI KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA
> >> DENISE_HR AGNUS_HR_PAL MAGIC_REKICK ZORRO3
> >> [ 0.000000] initrd: 0f83283d - 10000000
> >
> > Length is 0x7cd7c4 which is below 8 MiB. Moreover, this is a known-good
> > initrd. So the oops appears to be caused by a kernel change and not initrd
> > growth.
>
> All these have the initrd in the second memory chunk - at least one of
> the successful boots had the initrd in the first (8 MB) chunk).
>
> I know nothing about the way amiboot works, and how the RAM chunk to
> copy the initrd image to is selected. Just speculating: maybe amiboot
> plus initrd size must be below 8 MB for the first chunk to get used?
m68kboot/common/amiga/linuxboot.c
bi.ramdisk.addr = (u_long)start_mem+mem_size-rd_size;
However, that's not where it is loaded initially:
memreq = kernel_size+bi_size+rd_size;
memptr = (char *)AllocMem(memreq, MEMF_FAST | MEMF_PUBLIC | MEMF_CLEAR);
I expect the allocated memory to be from the largest (second)
block of memory.
Later, everything is copied to the first memory block.
But from a quick glance, I see no check to verify the first
block is sufficiently large.
I think we really need to see the output of "amiboot -d",
for both the good and the bad cases.
> But that's a little academic. I really wonder what makes the initrd at
> the end of the second RAM chunk fault. But e.g. the range
>
> 0f83283d - 10000000
>
> extends one byte beyond what's mapped
>
> node 0: [mem 0x0000000008000000-0x000000000fffffff]
That's because the first printed range is initrd_start, initrd_end,
while the second is (u64)start_pfn << PAGE_SHIFT,
((u64)end_pfn << PAGE_SHIFT) - 1).
> and the fault occurs at faddr=0ffffff4, at which point the processor
> probably pre-fetched out to 10000000.
Or perhaps memcmp() (that's __builtin_memcmp()?) loads 4 words
at once?
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
