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

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Sorry for the confusion, but NVDI still hangs: I forgot to only enable
PMMU, but not also the other two options. With PMMU enabled and prefetch
and cycle exact disabled NVDI still hangs.

> I forgot to mention: Without OUTSIDE NVDI now does not hang anymore, so
> with this patch at least the problem with NVDI I mentioned in the other
> thread may have been resolved.
> 
> > Hi,
> > 
> > OUTSIDE does not crash anymore when being started, but it still does not
> > work. When starting NVDI Hatari freezes, does not even react when
> > pressing F12. Even Ctrl-C could not kill it, I had to use the kill
> > command. Without NVDI OUTSIDE can be started, but the system is not
> > stable, often there are double bus faults.
> > 
> > ROMSPEED now crashes Hatari:
> > 
> > #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
> > #5  0x0000555555930b74 in fill_prefetch_030_ntx ()
> >     at /home/us/hatari/hatari/src/cpu/newcpu.c:12089
> > #6  0x0000555555932425 in fill_prefetch_030 ()
> >     at /home/us/hatari/hatari/src/cpu/newcpu.c:12236
> > #7  fill_prefetch () at /home/us/hatari/hatari/src/cpu/newcpu.c:12256
> > #8  0x0000555555932b79 in Exception_mmu030 (oldpc=<optimized out>, nr=11)
> >     at /home/us/hatari/hatari/src/cpu/newcpu.c:3603
> > 
> > I noticed that this code fragment:
> > 
> > if (eamode == 0 || eamode == 1 || eamode == 3 || eamode == 4 || eamode =
> > = 6 || (eamode == 7 && rreg > 1))
> > 
> > is present in cpummu030.c and also in newcpu.c, but the changes only refer to
> > one of these files?
> > 
> > When testing I had both prefetch and cycle exact enabled.
> > 
> > Best regards
> > 
> > Uwe
> > 
> > > Le 03/10/2018 à 17:42, Uwe Seimet a écrit :
> > > > Maybe I missed something when testing the latest patches. I will test
> > > > them again as soon as they have been checked in.
> > > 
> > > I'd rather you test them again with the command parameter from my 
> > > example before I commit them, it's possible you have a different case 
> > > from mine and the patch is not complete yet.
> > > 
> > > > 
> > > >> Le 02/10/2018 à 19:29, Uwe Seimet a écrit :
> > > >>> Just applied this patch and also Toni's change, but still get the same
> > > >>> errors as before with OUTSIDE and ROMSPEED.
> > > >>
> > > >> for me it doesn't crash anymore (whether I apply my own quick
> > > >> modification from yesterday or the patch by andreas).
> > > >>
> > > >> I run for example (with cycle exact enabled in config file) :
> > > >> hatari   --machine tt --tos tos306fr.img -s 14 --mmu on
> > > >>
> > > >> That part of the code in romspeed then gives :
> > > >>
> > > >>           ptestr #2,([8,a0]),#7,a0
> > > >>
> > > >> -> returns A0=$7f8 and D0=$20005
> > > >>
> > > >>           move.l d0,(a0)  ;enter in descriptor table
> > > >>           pflusha
> > > >>
> > > >> then romspeed exits cleanly and tos keeps on working
> > > >>
> > > >> and this changes default TOS MMU tables from :
> > > >>
> > > >> 000007F0: 00 c0 00 09 00 d0 00 19 00 e0 00 09 00 f0 00 59
> > > >>
> > > >> to :
> > > >>
> > > >> 000007F0: 00 c0 00 09 00 d0 00 19 00 02 00 0d 00 f0 00 59
> > > >>
> > > >>
> > > >> I'm booting on a gemdos hd directory with nothing loaded from auto, just
> > > >> default tos desktop.
> > > >>
> > > >> Nicolas
> > > >>
> > > >>
> > > > 
> > > > 
> > > 
> > 
> > 
> 
>