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

Michael Schmitz
2023-02-22T00:54:04Z

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
>