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

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

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