Re: [hatari-devel] Hatari hangs with NVDI when MMU is enabled

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 02/10/2018 à 11:34, Nicolas Pomarède a écrit :
> Le 02/10/2018 à 11:27, Uwe Seimet a écrit :
> > Hi,
> >
> > I'm quite sure NVDI does not use the PMMU. It's not the kind of
> > application that would typically make use of it, and definitely does not
> > require one.
> >  From Christian's analysis there appears to be some side effect 
> > related to
> > using or not using the PMMU, prefetch and cycle exact options, and
> > handling of exception vectors.
>
> hi
>
> it might not use it, but if there's a buggy combination of 
> mmu/prefetch/cycle exact in the 68030 cpu emulation and nvdi allows to 
> show it, then it's better to use nvdi to debug this issue than just 
> looking at the C code in newcpu.c, because cpu emulation with 
> 68030/caches/mmu is *really* complex and not having traces of the 
> crashing program makes it nearly impossible to guess ;(

hi

I reproduced the issue seen by christian, after some debugging / 
tracing, the problem is that cache state was not consistent in the case 
of 68030 + mmu with more_compatible=off and cycle_exact=off.
Some functions were accessing memory through the data cache, other were 
not, so in the end the value written to change trap's vector was not 
seen by the exception handler :(

After discussing with Toni, this options' combination is in fact not 
valid : data cache emulation requires either more_compatible or 
cycle_exact, so if none are set, data cache emulation should be disabled

The problem would the same with 68030 and no mmu, but in that case the 
code path is different and data cache is not used by cpu emulation even 
if it was enabled, which explain why there was no crash.

Change was committed to disable cache when necesary, with or without MMU.

Please, test if NVDI works better now.

Nicolas