Re: [hatari-devel] MEMWATCH freezes Hatari

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 16/10/2018 à 19:22, Nicolas Pomarède a écrit :

> I will make further traces/test, because there was still some errors 
> when CE mode is on (maybe a cache issue)

Here're some traces with CE ON (and cache ON)

For easier comparison, programs were loaded at the same location as in 
previous traces with prefetch=ff and CE=off


0001E274 4211                     CLR.B (A1)
cpu exception 2 currpc 1e274 buspc 1e274 newpc 1a822 fault_e3 0 op_e3 0 
addr_e3 0 SR 300

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)
 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]
 0001A8AC 4e73                     RTE

 0001E274 4211                     CLR.B (A1)
cpu exception 2 currpc 1e274 buspc 1e274 newpc 1a822 fault_e3 0 op_e3 0 
addr_e3 0 SR 300

 0001A822 2f2f 0004                MOVE.L (A7, $0004) == $00005700 
[*e274b008],-(A7) [*003da6c6]
 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)

As can be seen, when 'clr.b (a1)' is retried, this gives again a bus 
error, as if the FC bits were not changed to supervisor (as they were 
with CE=off).

So, bus error handler is called again, which retries 'clr.b (a1)' and so on.

Could it be that in cache mode uae_mmu030_get_fc_data() is not called 
before accessing memory ?

Nicolas