[Bug]: MMU emulation bug: SysInfo 4.4 throws MuForce hits on startup - same config works in Amiberry

[codewiz]

Area

Emulation accuracy (display, audio, timing, chipset behaviour)

Summary

When SysInfo starts, it does some probe at $100004 to check whether it aliases $000004.

This results in a single MuForce hit on Amiberry:

LONG READ from 00100004                        PC: 085F8BB8
USP : 085B9C6C SR: 0004  (U0)(-)(-)  TCB: 08599F48
Data: 00000002 0000FFFF 00000000 00000007 003C147A 00000000 00000001 0000FFFF
Addr: 08000888 085B9C56 0858E474 085FA405 085FA2BC 00F95600 08000888 080022A4
...
----> 085F8BB8 - "sysinfo"  Hunk 0000 Offset 00007008
085f8bac :  6e20                       bgt.s $85f8bce
085f8bae :  0c00 0002                  cmpi.b #$2,d0
085f8bb2 :  6d26                       blt.s $85f8bda
085f8bb4 :  2078 0004                  movea.l $4.w,a0
085f8bb8 : *2279 0010 0004             movea.l $100004,a1
085f8bbe :  b3c8                       cmpa.l a0,a1
085f8bc0 :  6712                       beq.s $85f8bd4
085f8bc2 :  41fa e4de                  lea.l $85f70a2(pc),a0
Name: "Shell Process"  CLI: "sysinfo"  Hunk 0000 Offset 00007008

On Copperline, for some reason SysInfo wedges the machine with the power LED flashing (MuForce trying to log hits at high rate).

I couldn't debug further.

Copperline version

e5e1de0

Host system

Linux

Machine/configuration

I found this while testing A3000-030, but a regular A1200 040 suffices.

Reproduction steps

1. Boot (with or without startup).
2. Run at least SetPatch and MuForce
3. Run Sysinfo

Actual behaviour

Infinite hits (which I couldn't capture).

Expected behaviour

At most a single hit, benign - as in Amiberry.

Logs or debugger output

[codewiz]

Investigated with a bus-error (MMU fault) trace in the 68k core. I don't think this is an MMU bug.

The hits are real faults on pages MuForce/MuGA deliberately armed: every one has fault cause "indirect" (page descriptor is an indirect descriptor whose target is invalid), which is how the MuTools invalidate a page. And they are not a refault loop - the faulting addresses advance monotonically and never repeat ($201000, $201700, $2017A0, $202080, ... $202390), one fault per read.

What SysInfo does: it raw-reads a word every 16 bytes upward from $00200000, which on my A1200 config is the Zorro II fast RAM board. That memory is free (unallocated), so MuGuardianAngel reports every read - correctly. Rebooting the same machine with the Zorro II board removed and nothing else changed, SysInfo runs to completion with zero hits.

So the "infinite" hits are one legitimate hit per read of a long scan, and the apparent hang is throughput: each hit drags a full register/stack dump through MuForce (about 930 hits in 3 minutes here).

The Amiberry comparison isn't the same experiment: that config is A4000-040-MMU, whose fast RAM is Zorro III at $40000000 with nothing at $00200000, so SysInfo probes different addresses and you only see the $100004 one. Worth re-testing Amiberry with a Zorro II fast board at $200000 - I'd expect the same storm there.

Open question is whether SysInfo's scan is a long-standing SysInfo bug that MuGA simply exposes.

[LinuxJedi]

I disassembled SysInfo 4.4 (Aminet util/moni/SysInfo.lha, byte-identical to the build in the report: the movea.l $100004,a1 probe sits at hunk 0 offset $7008) and ran controlled repros. This confirms @codewiz's analysis and pins down exactly what SysInfo is doing, why Amiberry's A4000 config shows nothing, and that the storm is finite. Summary: not an emulation bug -- MuGuardianAngel is reporting real, deliberate raw reads of free memory by SysInfo.

What the scan is

SysInfo decides whether a fast-RAM region is shown as FAST RAM $ (16-bit) or 32BitRAM $ (32-bit) in its MEMORY window by timing raw reads of that region. Hunk 0 offset $37F6:

37fa  lea    $DFF000,a0
3800  cmpi.b #1,6(a0)          ; beam-sync on VHPOSR
3806  bne.s  $3800
3808  bsr.w  $3378             ; timestamp
380e  moveq  #1,d3             ; 2 passes
3810  movea.l (probe_base),a2  ; = mh_Lower of the region under test
3814  move.l #8191,d2          ; 8192 reads per pass
381a  move.w (a2),d0           ; RAW word read
381c  adda.l #16,a2            ; stride 16
3822  dbf    d2,$381a
3826  dbf    d3,$3810
      ...                      ; then the same again with move.l (a2),d0

2 x 8192 word reads plus 2 x 8192 long reads, stride 16, covering the first 128KB from mh_Lower -- never AllocMem'd. If long reads take about as long as word reads, the region is labeled 32-bit.

The region selection (offset $3722) walks ExecBase->MemList and only probes a region when:

• it is not MEMF_CHIP,
• mh_Lower has no bits in $FF000000 (regions outside 24-bit space, i.e. Zorro III / motherboard RAM, are labeled 32BitRAM without any probe),
• mh_Lower < $C00000 (slow RAM excluded),
• the CPU is 68020+ (AttnFlags bit 1).

So the probe runs precisely on a Zorro II fast-RAM board at $200000 on a 68020+ machine. That is also why the Amiberry comparison was silent: the A4000-040 config's fast RAM is Zorro III at $40000000, which short-circuits to 32BitRAM with zero reads. Same emulator behaviour, different memory map -- as suspected in the comment above.

(The separate, single $100004 hit is unrelated: it's SysInfo's Agnus-type detection at offset $6FDE -- for ECS Agnus IDs it compares ExecBase against $100004 to distinguish "ECS AGNUS - 1Meg" vs "2Meg" via chip-RAM wraparound. Copperline's A1200 Alice reports the AGA ID, takes the AGA branch, and never performs that read.)

Repro matrix (Copperline, A1200 / 68040 / KS3.1, MMULib MuTools, MuForce logging to serial)

Config	Result
fast=2M only	No storm. WB loads libraries into the Z2 board's first 128KB, so the probed pages are allocated (valid). SysInfo starts and runs normally.
fast=2M + z3=32M	Storm. Allocations go to Z3, the Z2 board stays free and MuGA-armed: WORD READ from 00201000, 00201010, ... advancing by exactly $10 per hit, all from the probe-loop PC.
fast=2M + z3=32M, MuForce without MuGuardianAngel	No storm (only a handful of unrelated page-0 FPU-vector write hits). The free-memory read guarding is MuGA's; the repro needs MuGuardianAngel running, not just MuForce.

The storm is finite

The loop is dbf-bounded: 32768 reads total, and every read landing on a MuGA-armed (free) page faults exactly once. I ran it to completion headless: in my layout, pages $201000-$20FFFF of the probed window were free, giving exactly 15360 hits -- 3840 per pass, four passes (7680 WORD + 7680 LONG), sweeping $201000-$20FFF0 identically each time, final hit LONG READ from 0020FFF0, after which SysInfo's window opened and it ran normally with MuForce still armed. The addresses never repeat within a pass and there is no refault loop. (The hit count depends on how much of the first 128KB happens to be free -- up to ~32k; the gaps in the addresses quoted above are just allocated pages sitting inside the window.)

Each hit costs a full MuForce dump (serial at 9600 baud, or the FILE= path measured at ~5 hits/s above), so with default output the storm takes on the order of an hour or more of continuous LED-flashing before SysInfo's window appears -- indistinguishable from a wedge unless you wait it out. Running MuForce with TINY (one line per hit) shrinks the dump cost considerably.

The same storm will occur on real hardware (and on Amiberry/WinUAE) given the same ingredients: 68020+, a Zorro II fast board, another RAM region taking the OS allocations, and MuGuardianAngel armed. SysInfo probing memory it doesn't own is long-standing behaviour -- its own 4.0 changelog fixed a crash from "assumed accessable memory at $2000" (tnx Piru), and this 16/32-bit probe is the same pattern. Worth reporting upstream to sysinfo.d0.se; on the Copperline side I believe this can be closed as working-as-intended.

[codewiz]

Great analysis, we don't have to fix anything in Copperline then.

Well, we could at eliminate the MuForce-hit storm on most A1200/A3000/A4000 profiles by allocating onboard Fast RAM where it's usually found on real hardware:

• A3000: 0x0700_0000
• A4000: 0x0800_0000
• A1200-020: Trapdoor expansions had to allocate Fast RAM within the 24bit range of the 680EC020, but since it had no MMU, the hit-storm won't ever happen.
• A1200 + 030/040/060: the popular Blizzards accelerators used 0x0800_0000, probably configured by a boot ROM (TBC).

SysInfo is a very popular app for evaluating emulators, but few users run it under MuForce. I'd say this is low priority, but worth doing one day. My vote: keep this bug open for a rainy day.

Separately, I have a fix for the A3000 reporting an AGA Denise in SysInfo and xSysInfo:
#187