Re: [hatari-devel] Hatari and OUTSIDE (virtual memory manager) |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Hatari and OUTSIDE (virtual memory manager)
- From: Uwe Seimet <Uwe.Seimet@xxxxxxxxx>
- Date: Thu, 4 Oct 2018 12:22:04 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1538648524; s=strato-dkim-0002; d=seimet.de; h=In-Reply-To:References:Message-ID:Subject:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=84s03pGtL1UacOcgqULySt0XylUEs6+0d4GXBToxLLE=; b=kID/0sZ3lhOyIOq3n5ZWUpzxLBPDoTpUq7iV+flMTeM4EmsStHxXBO2RKQyEGT9Bv+ NbpBqgtBYsJRs7gMwkepOR0k5gWauRg1ZevDL6feZh1ixOU33/B/MU2+yzf1Xq3mtj0E mwILD92ibYLu3CJk5Jf1KFRt7REfOcy0rCRCDyGOgMF+W8yMmm/m6uhnhihxI/8YH0LX ccgkwLS/5se7oclYOaY5N5rqRM7NzJyQX5WD4SoCltv4kxVtt5dHt9OJQz38hXYd8E+K phP0AcCAOjOb70xlrw37xUDkW/v21mMK9E28WsX9Z6Tw2XLDDm1JDvK7mjzyIP94DZae UbBA==
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
> >>
> >>
> >
> >
>