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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/