Re: [hatari-devel] MEMWATCH freezes Hatari

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

> file downloaded. From what I see, pflusha is working, then romspeed 
> create a cookie in RAM, call gemdos's super to go back to user mode. And 
> it crashes here, from the trace it looks like A7 is 0 after going back 
> to user mode, which is wrong ; it should have its value from earlier.
> 
> Can you try to run the test from the floppy, but add "-d ''" to the 
> parameters to completely disable loading the fake cartridge code that 
> emulate gemdos HD ? It doesn't mtter in my case, but maybe it changes 
> sthg for you.

Your note with A7 caused me to recompile ROMSPEED without the PMMU
instructions, in order to see whether it would still crash. It did not.
Then I noticed something which is embararrassing, in particular because you
spent so much time on the error analysis: There were two copies of
ROMSPEED on my drive, and the one I was using must have been different
from the one I attached to one of my emails and which you were most likely
using. I'm really sorry for that ...
The other copy does not crash, and also a copy built fresh from the
source does not. This means the problem is gone, nothing was actually wrong.

Next thing I did is double-checking whether I made a similar mistake
with MEMWATCH, but I did not. There is only one copy. I tried the floppy
disk image approach with it, but the first program I start from floppy
after MEMWATCH results in Hatari hanging. I now tried the same logfile
approach as the one you suggested before, and I may have found
something, please see below. On my machine Hatari hangs because it is
constantly executing the same code (at the very bottom of this email).
Looks as if there was a bus error due to an illegal write acces and the bus
error handling is repeated over and over.
This code:

cpu exception 2 currpc 100ba58 buspc 100ba58 newpc 1ec8c fault_e3 0 op_e3 0 addr_e3 0 SR 300
cpu video_cyc=322888 1832@158 : 0001EC8C 2f2f 0004                MOVE.L (A7, $0004) == $00005700 [ba58b008],-(A7) [01ffffc6]
mfp start CD handler=7 data=2 ctrl=1 timer_cyc=8 pending_cyc=7104 video_cyc=322892 1836@158 pc=1ec90 instr_cyc=4 first=false resume=true
cpu video_cyc=322892 1836@158 : 0001EC90 0297 0000 0fff           AND.L #$00000fff,(A7) [ba58b008]
cpu video_cyc=322896 1840@158 : 0001EC96 2eb7 0151                MOVE.L (A7, D0.W*1+0)+0 == $00000008 [0001ec9c],(A7) [00000008]
cpu video_cyc=322900 1844@158 : 0001EC9A 4e75                     RTS 

results in an immediate new bus error. I guess this has to do with the
fact that the MEMWATCH moved the exception vector table to a new
location, i.e. it changes the VBR register. I assume that are not many
programs changing the VBR, maybe something is wrong with the emulation?
Of course I wonder why you cannot reproduce this.
The reason why MEMWATCH changes the vector address is in order to always
be the first program that sees a bus error. Any other program will
typically just modify the bus error vector by writing to $04, but $04 is
not the actual vector address anymore when MEMWATCH is active. MEMWATCH
calls the original vector by evaluating the 68030 vector offset on the
stack. This is also something rather unusual but makes it possible to
use the same code fragment in order to call all original exception
vectors, i.e. no vector-specific handling is required here.

Best regards

Uwe

---


cpu video_cyc=534420 532388@264 : 0001ECB8 f036 9c01 0161           MMUOP030 (A6, A1.L*4, $01) == $0005cefd,#$0161
cpu video_cyc=534424 532392@264 : 0001ECC0 558f                     SUBA.L #$02,A7
cpu video_cyc=534428 532396@264 : 0001ECC2 f017 6200                MMUOP030 (A7),#$6200
cpu video_cyc=534432 532400@264 : 0001ECC6 081f 0003                BTST.B #$0003,(A7)+ [0a]
cpu video_cyc=534436 532404@264 : 0001ECCA 660e                     BNE.B #$0e == $0001ecda (T)
cpu video_cyc=534448 532416@264 : 0001ECDA 202e 0010                MOVE.L (A6, $0010) == $0000570c [0100d58a],D0
mfp start CD handler=7 data=2 ctrl=1 timer_cyc=8 pending_cyc=13248 video_cyc=534452 532420@264 pc=1ecde instr_cyc=4 first=false resume=true
cpu video_cyc=534452 532420@264 : 0001ECDE 2c70 01e2 04f2 0028      MOVEA.L (D0.W*1+1266)+40 == $00e00028 [0000771e],A6
cpu video_cyc=534456 532424@264 : 0001ECE6 2c56                     MOVEA.L (A6) [0100b920],A6
cpu video_cyc=534460 532428@264 : 0001ECE8 90ae 0008                SUB.L (A6, $0008) == $0100b928 [0100ba20],D0
cpu video_cyc=534464 532432@264 : 0001ECEC 651e                     BCS.B #$1e == $0001ed0c (F)
cpu video_cyc=534468 532436@264 : 0001ECEE b0ae 000c                CMP.L (A6, $000c) == $0100b92c [00001438],D0
cpu video_cyc=534472 532440@264 : 0001ECF2 6418                     BCC.B #$18 == $0001ed0c (T)
cpu video_cyc=534484 532452@264 : 0001ED0C 4cdf 4001                MOVEM.L (A7)+,,D0/A6
cpu video_cyc=534496 532464@264 : 0001ED10 08ef 0002 000b           BSET.B #$0002,(A7, $000b) == $00005707 [11]
cpu video_cyc=534504 532472@264 : 0001ED16 4e73                     RTE 
cpu exception 2 currpc 100ba58 buspc 100ba58 newpc 1ec8c fault_e3 0 op_e3 0 addr_e3 0 SR 300
cpu video_cyc=534504 532472@264 : 0001EC8C 2f2f 0004                MOVE.L (A7, $0004) == $00005700 [ba58b008],-(A7) [01ffffc6]
cpu video_cyc=534508 532476@264 : 0001EC90 0297 0000 0fff           AND.L #$00000fff,(A7) [ba58b008]
cpu video_cyc=534512 532480@264 : 0001EC96 2eb7 0151                MOVE.L (A7, D0.W*1+0)+0 == $00000008 [0001ec9c],(A7) [00000008]
cpu video_cyc=534516 532484@264 : 0001EC9A 4e75                     RTS 
cpu video_cyc=534536 532504@264 : 0001EC9C 48e7 8002                MOVEM.L D0/A6,-(A7)
cpu video_cyc=534548 532516@264 : 0001ECA0 4def 0008                LEA.L (A7, $0008) == $000056fc,A6
cpu video_cyc=534552 532520@264 : 0001ECA4 0c6e 1008 0006           CMP.W #$1008,(A6, $0006) == $00005702 [b008]
mfp start CD handler=7 data=2 ctrl=1 timer_cyc=8 pending_cyc=8992 video_cyc=534556 532524@264 pc=1ecaa instr_cyc=4 first=false resume=true
cpu video_cyc=534556 532524@264 : 0001ECAA 6604                     BNE.B #$04 == $0001ecb0 (T)
cpu video_cyc=534568 532536@264 : 0001ECB0 102e 000b                MOVE.B (A6, $000b) == $00005707 [11],D0
cpu video_cyc=534572 532540@264 : 0001ECB4 4e7b 0001                MOVEC D0,DFC
cpu video_cyc=534580 532548@264 : 0001ECB8 f036 9c01 0161           MMUOP030 (A6, A1.L*4, $01) == $0005cefd,#$0161
cpu video_cyc=534584 532552@264 : 0001ECC0 558f                     SUBA.L #$02,A7
cpu video_cyc=534588 532556@264 : 0001ECC2 f017 6200                MMUOP030 (A7),#$6200
cpu video_cyc=534592 532560@264 : 0001ECC6 081f 0003                BTST.B #$0003,(A7)+ [0a]
cpu video_cyc=534596 532564@264 : 0001ECCA 660e                     BNE.B #$0e == $0001ecda (T)
cpu video_cyc=534608 532576@264 : 0001ECDA 202e 0010                MOVE.L (A6, $0010) == $0000570c [0100d58a],D0
cpu video_cyc=534612 532580@264 : 0001ECDE 2c70 01e2 04f2 0028      MOVEA.L (D0.W*1+1266)+40 == $00e00028 [0000771e],A6
cpu video_cyc=534616 532584@264 : 0001ECE6 2c56                     MOVEA.L (A6) [0100b920],A6
cpu video_cyc=534620 532588@264 : 0001ECE8 90ae 0008                SUB.L (A6, $0008) == $0100b928 [0100ba20],D0
cpu video_cyc=534624 532592@264 : 0001ECEC 651e                     BCS.B #$1e == $0001ed0c (F)
cpu video_cyc=534628 532596@264 : 0001ECEE b0ae 000c                CMP.L (A6, $000c) == $0100b92c [00001438],D0
cpu video_cyc=534632 532600@264 : 0001ECF2 6418                     BCC.B #$18 == $0001ed0c (T)
cpu video_cyc=534644 532612@264 : 0001ED0C 4cdf 4001                MOVEM.L (A7)+,,D0/A6
cpu video_cyc=534656 532624@264 : 0001ED10 08ef 0002 000b           BSET.B #$0002,(A7, $000b) == $00005707 [11]
mfp start CD handler=7 data=2 ctrl=1 timer_cyc=8 pending_cyc=43136 video_cyc=534664 532632@264 pc=1ed16 instr_cyc=6 first=false resume=true
cpu video_cyc=534664 532632@264 : 0001ED16 4e73                     RTE 

Best regards

Uwe



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/