Kernel versions 6.x don't boot on Amiga 4000

Kernel versions 6.x don't boot on Amiga 4000

[John Paul Adrian Glaubitz]

Hi!

I tested Debian's most recent m68k kernels from the 6.0.x and 6.1.x series and
neither of these boot on my Amiga 4000/060. Both get stuck at the ABCDGHIJK
message.

Will try earlier kernels until I found the one where the breakage was introduced.
Currently known latest kernel to work is 5.10.5.

FWIW, I noticed that the kernel image itself is already over 7 MB, not sure
whether this is a problem.

Anyone else tried a recent kernel on their Amigas?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Kernel versions 6.x don't boot on Amiga 4000

[Geert Uytterhoeven]

Hi Adrian,

On Tue, Feb 21, 2023 at 3:51 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> I tested Debian's most recent m68k kernels from the 6.0.x and 6.1.x series and

Thanks for testing!

> neither of these boot on my Amiga 4000/060. Both get stuck at the ABCDGHIJK
> message.

Looks surprisingly similar to the issue reported by Stan.
Do the mitigations given in
https://lore.kernel.org/all/CAMuHMdUtkr2zvZiJfLXvs9d_inJbktSNqQQfO1oxnJHZeoYcHg@mail.gmail.com
help?

> FWIW, I noticed that the kernel image itself is already over 7 MB, not sure
> whether this is a problem.

Depends on how much RAM you have ;-)

> Anyone else tried a recent kernel on their Amigas?

I really should start booting on real Amiga hardware again...

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

Re: Kernel versions 6.x don't boot on Amiga 4000

[John Paul Adrian Glaubitz]

Hi Geert!

On Tue, 2023-02-21 at 15:55 +0100, Geert Uytterhoeven wrote:
> Looks surprisingly similar to the issue reported by Stan.
> Do the mitigations given in
> https://lore.kernel.org/all/CAMuHMdUtkr2zvZiJfLXvs9d_inJbktSNqQQfO1oxnJHZeoYcHg@mail.gmail.com
> help?

The kernel actually crashes with a backtrace:

ABCDGHIJK
[    0.000000] Linux version 6.0.0-6-m68k (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for
Debian) 2.39) #1 Debian 6.0.12-1 (2022-12-09)
[    0.000000] Enabling workaround for errata I14
[    0.000000] printk: bootconsole [debug0] enabled
[    0.000000] Amiga hardware found: [A4000] VIDEO BLITTER AUDIO FLOPPY A4000_IDE KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA
LISA ALICE_PAL ZORRO3 
[    0.000000] initrd: 0ef0602c - 0f800000
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000008000000-0x000000f7ffffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000008000000-0x000000000f7fffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000008000000-0x000000000f7fffff]
[    0.000000] Unable to handle kernel access at virtual address (ptrval)
[    0.000000] Oops: 00000000
[    0.000000] Modules linked in:
[    0.000000] PC: [<00201d3c>] memcmp+0x28/0x56
[    0.000000] SR: 2709  SP: (ptrval)  a2: 004a5580
[    0.000000] d0: 00000003    d1: 00000001    d2: 00201d14    d3: 00000272
[    0.000000] d4: 00012750    d5: 08023ec0    a0: 0000000c    a1: 0f7ffff4
[    0.000000] Process swapper (pid: 0, task=(ptrval))
[    0.000000] Frame format=4 fault addr=0f7ffff4 fslw=01051000
[    0.000000] Stack from 004a3fac:
[    0.000000]         00201d14 00000272 00374e40 0f7ffff4 0f800000 00534b22 0f7ffff4 0042e325
[    0.000000]         0000000c 0055c000 00000272 00012750 08023ec0 00012750 080dbf48 08001000
[    0.000000]         08001000 0f7ffff0 00553d9a 00000000 00533872
[    0.000000] Call Trace: [<00201d14>] memcmp+0x0/0x56
[    0.000000]  [<00374e40>] _printk+0x0/0x18
[    0.000000]  [<00534b22>] start_kernel+0x8a/0x5d6
[    0.000000]  [<00012750>] LOGTBL+0x228/0x800
[    0.000000]  [<00012750>] LOGTBL+0x228/0x800
[    0.000000]  [<00533872>] _sinittext+0x872/0x11f8
[    0.000000] 
[    0.000000] Code: b288 661e 4280 6030 2a49 284b 264c 224d <bb8c> 66ea 5988 7003 b088 65f0 224d 264c 60dc 4283 1631 1800 4282 1433 1800
2003
[    0.000000] Disabling lock debugging due to kernel taint
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

> > FWIW, I noticed that the kernel image itself is already over 7 MB, not sure
> > whether this is a problem.
> 
> Depends on how much RAM you have ;-)

128 MB.

> > Anyone else tried a recent kernel on their Amigas?
> 
> I really should start booting on real Amiga hardware again...

You should ;-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Kernel versions 6.x don't boot on Amiga 4000

[Michael Schmitz]

Hi Adrian,

On 22/02/23 04:53, John Paul Adrian Glaubitz wrote:
> Hi Geert!
>
> On Tue, 2023-02-21 at 15:55 +0100, Geert Uytterhoeven wrote:
>> Looks surprisingly similar to the issue reported by Stan.
>> Do the mitigations given in
>> https://lore.kernel.org/all/CAMuHMdUtkr2zvZiJfLXvs9d_inJbktSNqQQfO1oxnJHZeoYcHg@mail.gmail.com
>> help?
> The kernel actually crashes with a backtrace:
>
> ABCDGHIJK
> [    0.000000] Linux version 6.0.0-6-m68k (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for
> Debian) 2.39) #1 Debian 6.0.12-1 (2022-12-09)
> [    0.000000] Enabling workaround for errata I14
> [    0.000000] printk: bootconsole [debug0] enabled
> [    0.000000] Amiga hardware found: [A4000] VIDEO BLITTER AUDIO FLOPPY A4000_IDE KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA
> LISA ALICE_PAL ZORRO3
> [    0.000000] initrd: 0ef0602c - 0f800000
> [    0.000000] Zone ranges:
> [    0.000000]   DMA      [mem 0x0000000008000000-0x000000f7ffffffff]
> [    0.000000]   Normal   empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000008000000-0x000000000f7fffff]

In both your case and Kars', the memory does not start at 0x0. Kars 
finds all memory reserved on his HP.

6.2rc8 boots fine on my 030 (memory starting at 0x0).

> [    0.000000] Initmem setup node 0 [mem 0x0000000008000000-0x000000000f7fffff]
> [    0.000000] Unable to handle kernel access at virtual address (ptrval)
> [    0.000000] Oops: 00000000
> [    0.000000] Modules linked in:
> [    0.000000] PC: [<00201d3c>] memcmp+0x28/0x56
> [    0.000000] SR: 2709  SP: (ptrval)  a2: 004a5580
> [    0.000000] d0: 00000003    d1: 00000001    d2: 00201d14    d3: 00000272
> [    0.000000] d4: 00012750    d5: 08023ec0    a0: 0000000c    a1: 0f7ffff4

a1 is just  before the end of your RAM chunk. If that's a longword 
access, you'd fall over the edge :) Can you disassemble the code snippet 
(or memcmp()) so we can see what's happening?

I do recall recent changes to the mm code, but that was for NOMMU. I 
wonder whether there was anything else that would introduce an implicit 
assumption about memory starting at 0x0 ...

> [    0.000000] Process swapper (pid: 0, task=(ptrval))
> [    0.000000] Frame format=4 fault addr=0f7ffff4 fslw=01051000
> [    0.000000] Stack from 004a3fac:
> [    0.000000]         00201d14 00000272 00374e40 0f7ffff4 0f800000 00534b22 0f7ffff4 0042e325
> [    0.000000]         0000000c 0055c000 00000272 00012750 08023ec0 00012750 080dbf48 08001000
> [    0.000000]         08001000 0f7ffff0 00553d9a 00000000 00533872
> [    0.000000] Call Trace: [<00201d14>] memcmp+0x0/0x56
> [    0.000000]  [<00374e40>] _printk+0x0/0x18
> [    0.000000]  [<00534b22>] start_kernel+0x8a/0x5d6
> [    0.000000]  [<00012750>] LOGTBL+0x228/0x800
> [    0.000000]  [<00012750>] LOGTBL+0x228/0x800
> [    0.000000]  [<00533872>] _sinittext+0x872/0x11f8
> [    0.000000]
> [    0.000000] Code: b288 661e 4280 6030 2a49 284b 264c 224d <bb8c> 66ea 5988 7003 b088 65f0 224d 264c 60dc 4283 1631 1800 4282 1433 1800
> 2003
> [    0.000000] Disabling lock debugging due to kernel taint
> [    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> [    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
>
>>> FWIW, I noticed that the kernel image itself is already over 7 MB, not sure
>>> whether this is a problem.
>> Depends on how much RAM you have ;-)
> 128 MB.
>
>>> Anyone else tried a recent kernel on their Amigas?
>> I really should start booting on real Amiga hardware again...
> You should ;-).

Thirded :-)

Cheers,

     Michael

>
> Adrian
>

Re: Kernel versions 6.x don't boot on Amiga 4000

[John Paul Adrian Glaubitz]

Hi Michael!

On Wed, 2023-02-22 at 10:09 +1300, Michael Schmitz wrote:
> a1 is just  before the end of your RAM chunk. If that's a longword 
> access, you'd fall over the edge :) Can you disassemble the code snippet 
> (or memcmp()) so we can see what's happening?

Here you go:

00201d14 <memcmp>:
  201d14:       48e7 301c       moveml %d2-%d3/%a3-%a5,%sp@-
  201d18:       226f 0018       moveal %sp@(24),%a1
  201d1c:       266f 001c       moveal %sp@(28),%a3
  201d20:       206f 0020       moveal %sp@(32),%a0
  201d24:       7003            moveq #3,%d0
  201d26:       b088            cmpl %a0,%d0
  201d28:       650a            bcss 201d34 <memcmp+0x20>
  201d2a:       4281            clrl %d1
  201d2c:       b288            cmpl %a0,%d1
  201d2e:       661e            bnes 201d4e <memcmp+0x3a>
  201d30:       4280            clrl %d0
  201d32:       6030            bras 201d64 <memcmp+0x50>
  201d34:       2a49            moveal %a1,%a5
  201d36:       284b            moveal %a3,%a4
  201d38:       264c            moveal %a4,%a3
  201d3a:       224d            moveal %a5,%a1
  201d3c:       bb8c            cmpml %a4@+,%a5@+
  201d3e:       66ea            bnes 201d2a <memcmp+0x16>
  201d40:       5988            subql #4,%a0
  201d42:       7003            moveq #3,%d0
  201d44:       b088            cmpl %a0,%d0
  201d46:       65f0            bcss 201d38 <memcmp+0x24>
  201d48:       224d            moveal %a5,%a1
  201d4a:       264c            moveal %a4,%a3
  201d4c:       60dc            bras 201d2a <memcmp+0x16>
  201d4e:       4283            clrl %d3
  201d50:       1631 1800       moveb %a1@(0,%d1:l),%d3
  201d54:       4282            clrl %d2
  201d56:       1433 1800       moveb %a3@(0,%d1:l),%d2
  201d5a:       2003            movel %d3,%d0
  201d5c:       9082            subl %d2,%d0
  201d5e:       5281            addql #1,%d1
  201d60:       b483            cmpl %d3,%d2
  201d62:       67c8            beqs 201d2c <memcmp+0x18>
  201d64:       4cdf 380c       moveml %sp@+,%d2-%d3/%a3-%a5
  201d68:       4e75            rts

The kernel image is actually unstripped. Is there a config option for that?

Do we want to keep symbols in a non-debug kernel?

> I do recall recent changes to the mm code, but that was for NOMMU. I 
> wonder whether there was anything else that would introduce an implicit 
> assumption about memory starting at 0x0 ...

Sounds like a possible culprit.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Kernel versions 6.x don't boot on Amiga 4000

[Michael Schmitz]

Hi Adrian,

On 22/02/23 10:46, John Paul Adrian Glaubitz wrote:
> Hi Michael!
>
> On Wed, 2023-02-22 at 10:09 +1300, Michael Schmitz wrote:
>> a1 is just  before the end of your RAM chunk. If that's a longword

Actually it isn't that close - if I read the stack correctly, we're 
comparing 0xc bytes from 0x0f7ffff4 which is to 0x0f7ffffff.

The post-increment of a5 to 0x0f800000 might cause a pre-fetch beyond 
end of memory - how does that get handled?

>> access, you'd fall over the edge :) Can you disassemble the code snippet
>> (or memcmp()) so we can see what's happening?
> Here you go:
>
> 00201d14 <memcmp>:
>    201d14:       48e7 301c       moveml %d2-%d3/%a3-%a5,%sp@-
>    201d18:       226f 0018       moveal %sp@(24),%a1
>    201d1c:       266f 001c       moveal %sp@(28),%a3
>    201d20:       206f 0020       moveal %sp@(32),%a0
>    201d24:       7003            moveq #3,%d0
>    201d26:       b088            cmpl %a0,%d0
>    201d28:       650a            bcss 201d34 <memcmp+0x20>
>    201d2a:       4281            clrl %d1
>    201d2c:       b288            cmpl %a0,%d1
>    201d2e:       661e            bnes 201d4e <memcmp+0x3a>
>    201d30:       4280            clrl %d0
>    201d32:       6030            bras 201d64 <memcmp+0x50>
>    201d34:       2a49            moveal %a1,%a5			<=======  0x0f7ffff4
>    201d36:       284b            moveal %a3,%a4
>    201d38:       264c            moveal %a4,%a3
>    201d3a:       224d            moveal %a5,%a1
>    201d3c:       bb8c            cmpml %a4@+,%a5@+		<=======  a5 will be 0x0f800000 after post-increment
>    201d3e:       66ea            bnes 201d2a <memcmp+0x16>
>    201d40:       5988            subql #4,%a0
>    201d42:       7003            moveq #3,%d0
>    201d44:       b088            cmpl %a0,%d0
>    201d46:       65f0            bcss 201d38 <memcmp+0x24>
>    201d48:       224d            moveal %a5,%a1
>    201d4a:       264c            moveal %a4,%a3
>    201d4c:       60dc            bras 201d2a <memcmp+0x16>
>    201d4e:       4283            clrl %d3
>    201d50:       1631 1800       moveb %a1@(0,%d1:l),%d3
>    201d54:       4282            clrl %d2
>    201d56:       1433 1800       moveb %a3@(0,%d1:l),%d2
>    201d5a:       2003            movel %d3,%d0
>    201d5c:       9082            subl %d2,%d0
>    201d5e:       5281            addql #1,%d1
>    201d60:       b483            cmpl %d3,%d2
>    201d62:       67c8            beqs 201d2c <memcmp+0x18>
>    201d64:       4cdf 380c       moveml %sp@+,%d2-%d3/%a3-%a5
>    201d68:       4e75            rts
>
> The kernel image is actually unstripped. Is there a config option for that?
I'm sure the compressed kernel image is stripped but includes the kernel 
symbol table (see below). The symbol table is definitely good to have 
(otherwise you'd have to figure what all the addresses on the stack mean 
from a separate symbol table).
> Do we want to keep symbols in a non-debug kernel?

Definitely ...

Cheers,

     Michael

Output of objdump -h:

vmlinux-6.2.0-rc8-atari-fpuemu-atafbfix+:     file format elf32-m68k

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         0030169c  00001000  00001000  00001000  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 __ex_table    00001ab0  003026a0  003026a0  003026a0  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   2 .rodata       000c81e8  00305000  00305000  00305000  2**4
                   CONTENTS, ALLOC, LOAD, DATA
   3 __ksymtab     00009a14  003cd1e8  003cd1e8  003cd1e8  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   4 __ksymtab_gpl 000057c0  003d6bfc  003d6bfc  003d6bfc  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   5 __ksymtab_strings 000166a3  003dc3bc  003dc3bc  003dc3bc  2**0
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   6 __param       000006cc  003f2a60  003f2a60  003f2a60  2**1
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   7 __modver      00000088  003f312c  003f312c  003f312c  2**1
                   CONTENTS, ALLOC, LOAD, DATA
   8 .notes        00000054  003f31b4  003f31b4  003f31b4  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   9 .data         00051a20  003f4000  003f4000  003f4000  2**4
                   CONTENTS, ALLOC, LOAD, DATA
  10 .bss          0002266c  00445a20  00445a20  00445a20  2**4
                   ALLOC
  11 .init.text    00017be0  00469000  00469000  00447000  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
  12 .init.data    00004c1c  00480be0  00480be0  0045ebe0  2**2
                   CONTENTS, ALLOC, LOAD, DATA
  13 .m68k_fixup   00000480  004857fc  004857fc  004637fc  2**0
                   CONTENTS, ALLOC, LOAD, DATA
  14 .init_end     00000384  00485c7c  00485c7c  00463c7c  2**0
                   ALLOC
  15 .comment      0000002d  00000000  00000000  00463c7c  2**0
                   CONTENTS, READONLY

>
>> I do recall recent changes to the mm code, but that was for NOMMU. I
>> wonder whether there was anything else that would introduce an implicit
>> assumption about memory starting at 0x0 ...
> Sounds like a possible culprit.
>
> Adrian
>

Re: Kernel versions 6.x don't boot on Amiga 4000

[Michael Schmitz]

Correcting myself again...

On 22/02/23 13:53, Michael Schmitz wrote:
> Hi Adrian,
>
> On 22/02/23 10:46, John Paul Adrian Glaubitz wrote:
>> Hi Michael!
>>
>> On Wed, 2023-02-22 at 10:09 +1300, Michael Schmitz wrote:
>>> a1 is just  before the end of your RAM chunk. If that's a longword
>
> Actually it isn't that close - if I read the stack correctly, we're 
> comparing 0xc bytes from 0x0f7ffff4 which is to 0x0f7ffffff.
>
> The post-increment of a5 to 0x0f800000 might cause a pre-fetch beyond 
> end of memory - how does that get handled?

The stack frame format in this case (at least, going by the 68000 series 
PRM) seems to indicate it's not something to do with prefetch.

Can you try Kars' recent patch? Maybe the old bug calculating the RAM 
end address only now got 'active' on your configuration due to more 
recent MM changes?

Cheers,

     Michaell

>
>>> access, you'd fall over the edge :) Can you disassemble the code 
>>> snippet
>>> (or memcmp()) so we can see what's happening?
>> Here you go:
>>
>> 00201d14 <memcmp>:
>>    201d14:       48e7 301c       moveml %d2-%d3/%a3-%a5,%sp@-
>>    201d18:       226f 0018       moveal %sp@(24),%a1
>>    201d1c:       266f 001c       moveal %sp@(28),%a3
>>    201d20:       206f 0020       moveal %sp@(32),%a0
>>    201d24:       7003            moveq #3,%d0
>>    201d26:       b088            cmpl %a0,%d0
>>    201d28:       650a            bcss 201d34 <memcmp+0x20>
>>    201d2a:       4281            clrl %d1
>>    201d2c:       b288            cmpl %a0,%d1
>>    201d2e:       661e            bnes 201d4e <memcmp+0x3a>
>>    201d30:       4280            clrl %d0
>>    201d32:       6030            bras 201d64 <memcmp+0x50>
>>    201d34:       2a49            moveal %a1,%a5 <=======  0x0f7ffff4
>>    201d36:       284b            moveal %a3,%a4
>>    201d38:       264c            moveal %a4,%a3
>>    201d3a:       224d            moveal %a5,%a1
>>    201d3c:       bb8c            cmpml %a4@+,%a5@+ <=======  a5 will 
>> be 0x0f800000 after post-increment
>>    201d3e:       66ea            bnes 201d2a <memcmp+0x16>
>>    201d40:       5988            subql #4,%a0
>>    201d42:       7003            moveq #3,%d0
>>    201d44:       b088            cmpl %a0,%d0
>>    201d46:       65f0            bcss 201d38 <memcmp+0x24>
>>    201d48:       224d            moveal %a5,%a1
>>    201d4a:       264c            moveal %a4,%a3
>>    201d4c:       60dc            bras 201d2a <memcmp+0x16>
>>    201d4e:       4283            clrl %d3
>>    201d50:       1631 1800       moveb %a1@(0,%d1:l),%d3
>>    201d54:       4282            clrl %d2
>>    201d56:       1433 1800       moveb %a3@(0,%d1:l),%d2
>>    201d5a:       2003            movel %d3,%d0
>>    201d5c:       9082            subl %d2,%d0
>>    201d5e:       5281            addql #1,%d1
>>    201d60:       b483            cmpl %d3,%d2
>>    201d62:       67c8            beqs 201d2c <memcmp+0x18>
>>    201d64:       4cdf 380c       moveml %sp@+,%d2-%d3/%a3-%a5
>>    201d68:       4e75            rts
>>
>> The kernel image is actually unstripped. Is there a config option for 
>> that?
> I'm sure the compressed kernel image is stripped but includes the 
> kernel symbol table (see below). The symbol table is definitely good 
> to have (otherwise you'd have to figure what all the addresses on the 
> stack mean from a separate symbol table).
>> Do we want to keep symbols in a non-debug kernel?
>
> Definitely ...
>
> Cheers,
>
>     Michael
>
> Output of objdump -h:
>
> vmlinux-6.2.0-rc8-atari-fpuemu-atafbfix+:     file format elf32-m68k
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         0030169c  00001000  00001000  00001000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 __ex_table    00001ab0  003026a0  003026a0  003026a0  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   2 .rodata       000c81e8  00305000  00305000  00305000  2**4
>                   CONTENTS, ALLOC, LOAD, DATA
>   3 __ksymtab     00009a14  003cd1e8  003cd1e8  003cd1e8  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   4 __ksymtab_gpl 000057c0  003d6bfc  003d6bfc  003d6bfc  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   5 __ksymtab_strings 000166a3  003dc3bc  003dc3bc  003dc3bc  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   6 __param       000006cc  003f2a60  003f2a60  003f2a60  2**1
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   7 __modver      00000088  003f312c  003f312c  003f312c  2**1
>                   CONTENTS, ALLOC, LOAD, DATA
>   8 .notes        00000054  003f31b4  003f31b4  003f31b4  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   9 .data         00051a20  003f4000  003f4000  003f4000  2**4
>                   CONTENTS, ALLOC, LOAD, DATA
>  10 .bss          0002266c  00445a20  00445a20  00445a20  2**4
>                   ALLOC
>  11 .init.text    00017be0  00469000  00469000  00447000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  12 .init.data    00004c1c  00480be0  00480be0  0045ebe0  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>  13 .m68k_fixup   00000480  004857fc  004857fc  004637fc  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
>  14 .init_end     00000384  00485c7c  00485c7c  00463c7c  2**0
>                   ALLOC
>  15 .comment      0000002d  00000000  00000000  00463c7c  2**0
>                   CONTENTS, READONLY
>
>>
>>> I do recall recent changes to the mm code, but that was for NOMMU. I
>>> wonder whether there was anything else that would introduce an implicit
>>> assumption about memory starting at 0x0 ...
>> Sounds like a possible culprit.
>>
>> Adrian
>>

Re: Kernel versions 6.x don't boot on Amiga 4000

[Geert Uytterhoeven]

Hi Adrian,

On Tue, Feb 21, 2023 at 4:53 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Tue, 2023-02-21 at 15:55 +0100, Geert Uytterhoeven wrote:
> > Looks surprisingly similar to the issue reported by Stan.
> > Do the mitigations given in
> > https://lore.kernel.org/all/CAMuHMdUtkr2zvZiJfLXvs9d_inJbktSNqQQfO1oxnJHZeoYcHg@mail.gmail.com
> > help?
>
> The kernel actually crashes with a backtrace:
>
> ABCDGHIJK
> [    0.000000] Linux version 6.0.0-6-m68k (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for
> Debian) 2.39) #1 Debian 6.0.12-1 (2022-12-09)
> [    0.000000] Enabling workaround for errata I14
> [    0.000000] printk: bootconsole [debug0] enabled
> [    0.000000] Amiga hardware found: [A4000] VIDEO BLITTER AUDIO FLOPPY A4000_IDE KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA
> LISA ALICE_PAL ZORRO3
> [    0.000000] initrd: 0ef0602c - 0f800000
> [    0.000000] Zone ranges:
> [    0.000000]   DMA      [mem 0x0000000008000000-0x000000f7ffffffff]
> [    0.000000]   Normal   empty
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000008000000-0x000000000f7fffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000008000000-0x000000000f7fffff]
> [    0.000000] Unable to handle kernel access at virtual address (ptrval)

I see the same issue on my A4000, bisecting...

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

Re: Kernel versions 6.x don't boot on Amiga 4000

[Geert Uytterhoeven]

On Sun, Feb 26, 2023 at 12:02 PM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Tue, Feb 21, 2023 at 4:53 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> > On Tue, 2023-02-21 at 15:55 +0100, Geert Uytterhoeven wrote:
> > > Looks surprisingly similar to the issue reported by Stan.
> > > Do the mitigations given in
> > > https://lore.kernel.org/all/CAMuHMdUtkr2zvZiJfLXvs9d_inJbktSNqQQfO1oxnJHZeoYcHg@mail.gmail.com
> > > help?
> >
> > The kernel actually crashes with a backtrace:
> >
> > ABCDGHIJK
> > [    0.000000] Linux version 6.0.0-6-m68k (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for
> > Debian) 2.39) #1 Debian 6.0.12-1 (2022-12-09)
> > [    0.000000] Enabling workaround for errata I14
> > [    0.000000] printk: bootconsole [debug0] enabled
> > [    0.000000] Amiga hardware found: [A4000] VIDEO BLITTER AUDIO FLOPPY A4000_IDE KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA
> > LISA ALICE_PAL ZORRO3
> > [    0.000000] initrd: 0ef0602c - 0f800000
> > [    0.000000] Zone ranges:
> > [    0.000000]   DMA      [mem 0x0000000008000000-0x000000f7ffffffff]
> > [    0.000000]   Normal   empty
> > [    0.000000] Movable zone start for each node
> > [    0.000000] Early memory node ranges
> > [    0.000000]   node   0: [mem 0x0000000008000000-0x000000000f7fffff]
> > [    0.000000] Initmem setup node 0 [mem 0x0000000008000000-0x000000000f7fffff]
> > [    0.000000] Unable to handle kernel access at virtual address (ptrval)
>
> I see the same issue on my A4000, bisecting...

Bisected to commit 376e3fdecb0dcae2 ("m68k: Enable memtest
functionality") in v5.17-rc1.  Reverting that on top of latest fixes the
issue.

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

Re: Kernel versions 6.x don't boot on Amiga 4000

[Michael Schmitz]

Hi Geert, Stephen,

Am 27.02.2023 um 01:52 schrieb Geert Uytterhoeven:
> On Sun, Feb 26, 2023 at 12:02 PM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Tue, Feb 21, 2023 at 4:53 PM John Paul Adrian Glaubitz
>> <glaubitz@physik.fu-berlin.de> wrote:
>>> On Tue, 2023-02-21 at 15:55 +0100, Geert Uytterhoeven wrote:
>>>> Looks surprisingly similar to the issue reported by Stan.
>>>> Do the mitigations given in
>>>> https://lore.kernel.org/all/CAMuHMdUtkr2zvZiJfLXvs9d_inJbktSNqQQfO1oxnJHZeoYcHg@mail.gmail.com
>>>> help?
>>>
>>> The kernel actually crashes with a backtrace:
>>>
>>> ABCDGHIJK
>>> [    0.000000] Linux version 6.0.0-6-m68k (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for
>>> Debian) 2.39) #1 Debian 6.0.12-1 (2022-12-09)
>>> [    0.000000] Enabling workaround for errata I14
>>> [    0.000000] printk: bootconsole [debug0] enabled
>>> [    0.000000] Amiga hardware found: [A4000] VIDEO BLITTER AUDIO FLOPPY A4000_IDE KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA
>>> LISA ALICE_PAL ZORRO3
>>> [    0.000000] initrd: 0ef0602c - 0f800000
>>> [    0.000000] Zone ranges:
>>> [    0.000000]   DMA      [mem 0x0000000008000000-0x000000f7ffffffff]
>>> [    0.000000]   Normal   empty
>>> [    0.000000] Movable zone start for each node
>>> [    0.000000] Early memory node ranges
>>> [    0.000000]   node   0: [mem 0x0000000008000000-0x000000000f7fffff]
>>> [    0.000000] Initmem setup node 0 [mem 0x0000000008000000-0x000000000f7fffff]
>>> [    0.000000] Unable to handle kernel access at virtual address (ptrval)
>>
>> I see the same issue on my A4000, bisecting...
>
> 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?

Cheers,

	Michael


>
> Gr{oetje,eeting}s,
>
>                         Geert
>

Re: Kernel versions 6.x don't boot on Amiga 4000

[Michael Schmitz]

Hi Geert,

Am 27.02.2023 um 01:52 schrieb Geert Uytterhoeven:
> On Sun, Feb 26, 2023 at 12:02 PM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Tue, Feb 21, 2023 at 4:53 PM John Paul Adrian Glaubitz
>> <glaubitz@physik.fu-berlin.de> wrote:
>>> On Tue, 2023-02-21 at 15:55 +0100, Geert Uytterhoeven wrote:
>>>> Looks surprisingly similar to the issue reported by Stan.
>>>> Do the mitigations given in
>>>> https://lore.kernel.org/all/CAMuHMdUtkr2zvZiJfLXvs9d_inJbktSNqQQfO1oxnJHZeoYcHg@mail.gmail.com
>>>> help?
>>>
>>> The kernel actually crashes with a backtrace:
>>>
>>> ABCDGHIJK
>>> [    0.000000] Linux version 6.0.0-6-m68k (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for
>>> Debian) 2.39) #1 Debian 6.0.12-1 (2022-12-09)
>>> [    0.000000] Enabling workaround for errata I14
>>> [    0.000000] printk: bootconsole [debug0] enabled
>>> [    0.000000] Amiga hardware found: [A4000] VIDEO BLITTER AUDIO FLOPPY A4000_IDE KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA
>>> LISA ALICE_PAL ZORRO3
>>> [    0.000000] initrd: 0ef0602c - 0f800000
>>> [    0.000000] Zone ranges:
>>> [    0.000000]   DMA      [mem 0x0000000008000000-0x000000f7ffffffff]
>>> [    0.000000]   Normal   empty
>>> [    0.000000] Movable zone start for each node
>>> [    0.000000] Early memory node ranges
>>> [    0.000000]   node   0: [mem 0x0000000008000000-0x000000000f7fffff]
>>> [    0.000000] Initmem setup node 0 [mem 0x0000000008000000-0x000000000f7fffff]
>>> [    0.000000] Unable to handle kernel access at virtual address (ptrval)
>>
>> I see the same issue on my A4000, bisecting...
>
> Bisected to commit 376e3fdecb0dcae2 ("m68k: Enable memtest
> functionality") in v5.17-rc1.  Reverting that on top of latest fixes the

What about instead changing the piece of code that you identified as 
problematic in Kars' case to claim/map the last few bits as well 
(memblock_cap_size() to be precise)?

I wonder whether Finn's memtest patch merely exposed another MM bug that 
we don't hit as easily (not without putting memory under a lot of pressure)?

Cheers,

	Michael


> issue.
>
> Gr{oetje,eeting}s,
>
>                         Geert
>

Re: Kernel versions 6.x don't boot on Amiga 4000

[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 (?)

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

Re: Kernel versions 6.x don't boot on Amiga 4000

[Finn Thain]

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.

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

[Michael Schmitz]

Hi Finn,

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.

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)

Cheers,

	Michael

Re: Kernel versions 6.x don't boot on Amiga 4000

[Finn Thain]

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

[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?

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 -- 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

Re: Kernel versions 6.x don't boot on Amiga 4000

[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

[Michael Schmitz]

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?
>
> 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

[Michael Schmitz]

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

[Mike Rapoport]

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.

Re: Kernel versions 6.x don't boot on Amiga 4000

[Geert Uytterhoeven]

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:
> > > 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();

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 -- 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

Re: Kernel versions 6.x don't boot on Amiga 4000

[Mike Rapoport]

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.