Re: [hatari-devel] 030 exceptions on auto-increment instructions

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 27/02/2020 à 00:26, Eero Tamminen a écrit :
> Hi,
>
> On 2/24/20 12:45 PM, Nicolas Pomarède wrote:
> > Le 13/04/2019 à 01:08, Eero Tamminen a écrit :
> > > While mailing about some issue I was hitting with m68k Linux, it
> > > was noticed that Linux fault handler gives different register
> > > values under Hatari than under real 030.
> > >
> > > Faulting instruction is:
> > >      $00249f5a : 0e98 2000  moves.l   (a0)+,d2
> > >
> > > A0 reg content is struct member offset address, but struct was NULL.
> > >
> > > Under Hatari Falcon emulation, Linux fault handler reg dump showed A0
> > > value to be 0x04, whereas with under real 030 Mac it showed 0x08.
> > >
> > > Environments weren't completely identical, so it's not 100% sure
> > > this is WinAUE CPU core issue, but I think it warrants checking.
> > >
> > >
> > > If you can have recent Linux version (5.x or slightly older, with
> > > SYSRQ config option enabled) under WinUAE and real m68k HW, this
> > > is easy to trigger.  Just do:
> > >      # echo t > /proc/sysrq-trigger
> >
> > regarding this issue, as of 2020/02/23 Hatari includes all the latest 
> > changes from WinUAE's cpu core where many of these stack values were 
> > measured on real HW and are now emulated.
> >
> > Can you check if this works better ?
>
> I haven't checked autoincrement addresses yet,
> but same things that were crashing earlier are
> still crashing.
>
> However, kernel backtraces look a bit different now:
> -----------------------------------------
> *** ILLEGAL INSTRUCTION ***   FORMAT=0
> Current process id is 37
> BAD KERNEL TRAP: 00000000
> PC: [<0013035a>] strncpy_from_user+0x62/0xec
> SR: 2200  SP: 4512139a  a2: 008545b0
> d0: 00000000    d1: 2f737973    d2: 00000ff0    d3: 00000ff0
> d4: 00000ff0    d5: 00000000    a0: 009b3010    a1: 80155c8c
> Process cttyhack (pid: 37, task=f9793eee)
> Frame format=0
> Stack from 009cbf18:
>          00000000 80155c8c 00000000 8017b101 ffffff49 efdfefc9 009b3000 
> 000938ba
>          001302f8 009cbf68 000a1ba2 009b3010 80155c8c 00000ff0 00000000 
> 00020000
>          00020000 009cbf9a 80170f52 801712bc 009cbf7c 000a1ca6 80155c8c 
> 00000000
>          00000000 009cbfac 00097d20 80155c8c 80155c8c 00020000 00000000 
> efa9bd4d
>          efa90002 00000000 00000004 00000100 00000001 009cbfc4 00097e04 
> ffffff9c
>          80155c8c 00020000 00000000 efa9bd68 00002988 ffffff9c 80155c8c 
> 00020000
> Call Trace: [<000938ba>] kmem_cache_alloc+0x0/0x6e
>   [<001302f8>] strncpy_from_user+0x0/0xec
>   [<000a1ba2>] getname_flags+0x40/0x132
>   [<00020000>] _I_CALL_TOP+0x85c/0x1900
>   [<00020000>] _I_CALL_TOP+0x85c/0x1900
>   [<000a1ca6>] getname+0x12/0x18
>   [<00097d20>] do_sys_open+0x32/0xce
> -----------------------------------------
>
> Earlier getname_flags() was shown to be the place
> where things went south, but I think above back
> trace is more correct.
>
> (There seems to be something fishy in kernel <->
> userspace interface, I've seen Linux to use
> use exception handling liberally when accessing
> all kinds of things, instead of it e.g. checking
> for NULL pointers etc.  And for some reasons that
> still doesn't work properly in Hatari.)

hi

hard to tell what's going on with just this kernel dump.

could you try this :

 - in a console under linux/hatari, type "echo t > /proc/sysrq-trigger" 
(don't press enter)
 - at this point, save a memory snapshot

 - restart hatari with --memstate XXXX and --trace all,-int,-cpuregs 
(redirect stderr to a file)

 - press 'enter' to validate the "echo t > /proc/sysrq-trigger" command 
and stop hatari when the crash happens.

This way you should get a a more verbose trace with all the context.

Nicolas