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

[ Thread Index | Date Index | More Archives ]

Le 02/10/2018 à 11:34, Nicolas Pomarède a écrit :
Le 02/10/2018 à 11:27, Uwe Seimet a écrit :

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.


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


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.


Mail converted by MHonArc 2.6.19+