Re: [hatari-devel] Hatari and OUTSIDE (virtual memory manager)

[Andreas Grabher <andreas_g86@xxxxxxxxxx>]

Am 04.10.2018 um 14:48 schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 04/10/2018 à 14:35, Uwe Seimet a écrit :
>> Hi,
>>> I can't get a crash when I use your config file you posted with the nvdi
>>> issues. I run :
>>> 
>>> ./hatari -c ../tests/hatari_uwe.cfg -d /others/ST/D/ --tos
>>> ~/Emul/ST/tos/tos306fr.img
>>> 
>>> Once desktop appears, I run romspeed (that I copied into /others/ST/D)
>>> and it works in all cases, with or without cycle exact.
>>> 
>>> Maybe your config is autostarting some other programs that create this
>>> failure ? Can you try to start with only a gemdos HD drive containing
>>> only romspeed ?
>>> 
>>> Or start with an empty hatari.cfg ("touch hatari.cfg") and add all the
>>> parameters on the command line ?
>>> 
>>> And just to be sure, did you do a "make clean" before compiling, just in
>>> case some old code was still present ?
>> Yes, I ran a "make clean" before. With the attached config file, which
>> uses no disk images and maps drive C: to a folder that only contains
>> ROMSPEED.PRG there is no change. Hatari crashes just like before:
>> #0  0x00007ffff5b81fa0 in raise () from /lib64/libc.so.6
>> #1  0x00007ffff5b83b7d in abort () from /lib64/libc.so.6
>> #2  0x000055555586f5ef in __pushtry (j=<optimized out>)
>>     at /home/us/hatari/hatari/src/cpu/cpummu.c:1743
>> #3  0x000055555601e8bb in __pushtry (j=<optimized out>)
>>     at /home/us/hatari/hatari/src/cpu/cpummu.c:1736
>> #4  0x000055555591e47c in fill_icache030 (addr=addr@entry=14684700)
>>     at /home/us/hatari/hatari/src/cpu/newcpu.c:10786
> 
> I tried your config file, and no crash for me.
> 
> From your traces and from nvdi's crash with christian's logs, I'm quite sure there's a bug somewhere in the 68030's cache when mmu is used (the code path / memory access functions are different than 68030 with caches and no mmu).
> 
> For whatever reasons (compilation env, flags, OS, ...) the cache problem triggers also in your case, while for me it doesn't with romspeed.
> 
> I'm actually looking at the cache issue, once it's fixed (which can take quite some time to get to the root of the problem), I will post some patch to try.
> 
> Until then, I don't think more tests are needed on your side.
> 
> Nicolas
> 
Just a guess: Maybe something wrong with handling MMU cache inhibit bit? I never tested that one. I do not use cache emulation for Previous.