SysInfo 4.4 throws MuForce hits on profiles with Z2 RAM

[codewiz]

SysInfo wedges the machine with a MuForce / MuGA hit storm when a machine has Zorro II RAM at $200000-BFFFFF (slow RAM excluded). Looks like deliberate design rather than a bug in SysInfo.

Copperline triggers this in the A1200, A3000 and A4000 profiles by mapping RAM in this range.

To mitigate this, we should simply fix these profiles to map fast RAM in the address ranges where it is usually expected:

• 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)

[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

[LinuxJedi]

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

Both A3000 and A4000 it is 0x07000000 - 0x07FFFFFF. But it starts at the top end and counts down. Copperline now does this too.

A4000 can also use $04000000 - $06FFFFFF with a motherboard hack.

$08000000 - $0FFFFFFF is used by CPU cards.

• A1200 + 030/040/060: the popular Blizzards accelerators used 0x0800_0000, probably configured by a boot ROM (TBC).

A1200 seem to do it three different ways:

TF cards - $08000000 range (requires Kickstart 3.1 minimum, or manual AddMem)
Blizzard - Custom ROM shoving the RAM in $68000000-$68FFFFFF area
Other cards such as ACA1233n - Z3 memory area (autoconfig)