Re: [hatari-devel] MEMWATCH freezes Hatari

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

Thank you for further analyzing this,

Best regards

Uwe

> Le 13/10/2018 à 11:02, Nicolas Pomarède a écrit :
> > Myabe it would be better to track the issue with pure debugger, it's 
> > likely that the code is easier to follow, especially if there's a double 
> > bus error, this is often very close to the cause of the exception.
> 
> hi
> 
> I was able to test this issue with pure debugger and I think the 
> rte/rerun is not fixed yet, the PC is not set to the faulty instruction 
> but to the next instruction.
> 
> I tested with prefetch=off and CE=off as well as with CE=on
> 
> In both cases, it doesn't rerun.
> 
> The simpler case might be with prefetch=off and CE=off :
> 
> This is the "faulty" instruction (memory is write protected, so it 
> triggers a bus error) :
> 
> 0001E270 43f0 1001                LEA.L (A0, D1.W*1, $01) == $0001e0eb,A1
> 0001E274 4211                     CLR.B (A1)
> 
> This calls 1a822, which is just an intermediate handler and calls 1a832 
> which is the real bus error handler
> 
> 0001A822 2f2f 0004                MOVE.L (A7, $0004) == $00005700 
> [e274b008],-(A7) [00040000]
> 0001A826 0297 0000 0fff           AND.L #$00000fff,(A7) [e274b008]
> 0001A82C 2eb7 0151                MOVE.L (A7, D0.W*1+0)+0 == $00000008 
> [0001a832],(A7) [00000008]
> 0001A830 4e75                     RTS
> 0001A832 48e7 8002                MOVEM.L D0/A6,-(A7)
> 
> Here, A7=$56fc and the stack is :
> 
> 000056FC: 03 00 00 01 e2 74 b0 08 00 00 03 11 00 00 00 00
> 0000570C: 00 01 e0 eb 00 00 42 11 00 00 00 00 00 01 e0 eb
> 0000571C: 00 00 00 00 00 01 e0 eb 00 00 3f 00 00 01 e0 eb
> 0000572C: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0000573C: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> So, return PC is correctly set to 1e274, the faulty instruction.
> 
> 0001A836 4def 0008                LEA.L (A7, $0008) == $000056fc,A6
> 0001A83A 0c6e 1008 0006           CMP.W #$1008,(A6, $0006) == $00005702 
> [b008]
> 0001A840 6604                     BNE.B #$04 == $0001a846 (T)
> 0001A846 102e 000b                MOVE.B (A6, $000b) == $00005707 [11],D0
> 0001A84A 4e7b 0001                MOVEC D0,DFC
> 0001A84E f036 9c01 0161           MMUOP030 (A6, A1.L*4, $01) == 
> $0007daa9,#$0161
> 0001A856 558f                     SUBA.L #$02,A7
> 0001A858 f017 6200                MMUOP030 (A7),#$6200
> 0001A85C 081f 0003                BTST.B #$0003,(A7)+ [0a]
> 0001A860 660e                     BNE.B #$0e == $0001a870 (T)
> 0001A870 202e 0010                MOVE.L (A6, $0010) == $0000570c 
> [0001e0eb],D0
> 0001A874 2c70 01e2 04f2 0028      MOVEA.L (D0.W*1+1266)+40 == $00e00028 
> [0000771e],A6
> 0001A87C 2c56                     MOVEA.L (A6) [0001e06a],A6
> 0001A87E 90ae 0008                SUB.L (A6, $0008) == $0001e072 
> [0001e16a],D0
> 0001A882 651e                     BCS.B #$1e == $0001a8a2 (T)
> 0001A8A2 4cdf 4001                MOVEM.L (A7)+,,D0/A6
> 0001A8A6 08ef 0002 000b           BSET.B #$0002,(A7, $000b) == $00005707 
> [11]
> 
> FC bits are changed in SSW. At this point, A7=$56fc and the stack is :
> 
> 000056FC: 03 00 00 01 e2 74 b0 08 00 00 03 15 00 00 00 00
> 0000570C: 00 01 e0 eb 00 00 42 11 00 00 00 00 00 01 e0 eb
> 0000571C: 00 00 00 00 00 01 e0 eb 00 00 3f 00 00 01 e0 eb
> 0000572C: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0000573C: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 
> So, it should still return to 1e274.
> 
> 0001A8AC 4e73                     RTE
> 0001E276 42a7                     CLR.L -(A7)
> 0001E278 6036                     BT .B #$36 == $0001e2b0 (T)
> 
> As can be seen, the RTE executes the instruction at 1e276, but the 
> "clr.b (a1)" at 1e274 is not retried.
> 
> So, in that case there's no instant crash, this clr.b might be useless 
> now, but the rerun behaviour was not correct.
> 
> I don't see anything obvious in m68k_do_rte_mmu030(), neither in code 
> for op_4e73.
> 
> Toni, do you see sthg with these traces or do you need more infos ?
> 
> Note that in m68k_do_rte_mmu030 there might be a bug with these lines :
> 
> uae_u32 ps = get_long_mmu030c(a7 + 0x28);
> uae_u32 oc = get_long_mmu030c (a7 + 0x14);
> 
> shouldn't it be the non-cache version ?
> uae_u32 ps = get_long_mmu030(a7 + 0x28);
> uae_u32 oc = get_long_mmu030 (a7 + 0x14);
> 
> (but it doesn't change this case anyway)
> 
> Nicolas
> 
> 
> 
> 
> 
> 
>