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

[Michael Schmitz <schmitzmic@gmail.com>]

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