Consistent kernel faulting after kernel reconfiguration (IRIX 6.5.22, R5000, IP24)

[iblowmymind]

I've been constantly getting this crash after a couple restarts and software installs. If it matters I installed some patches on top of IRIX 6.5.22, but it happened before on a clean install after installing Maya too.

My machine configuration is:

"indy65": {
      "prom": "/Volumes/Genesis/Emulators/IRIS/indy_prom.bin",
      "nvram": "/Volumes/Genesis/Emulators/IRIS/indy65/nvram.bin",
      "nveeprom": "nveeprom.bin",
      "banks": [
        128,
        128,
        0,
        0
      ],
      "scale": 1,
      "headless": false,
      "no_audio": false,
      "test_device": false,
      "cheritest_dump_hook": false,
      "nat_subnet": "192.168.0.0/24",
      "ci": false,
      "ci_socket": "/tmp/iris.sock",
      "ci_display": false,
      "mouse_scroll_pixels_per_line": 40.0,
      "lock_aspect_ratio": true,
      "serial_log": "/Volumes/Genesis/Emulators/IRIS/indy65/serial.txt",
      "scsi": {
        "1": {
          "path": "/Volumes/Genesis/Emulators/IRIS/indy65/disk0.chd",
          "discs": [],
          "cdrom": false,
          "overlay": false,
          "scratch": false,
          "size_mb": null,
          "controller": 0
        },
        "4": {
          "path": "/Volumes/Onyx/Software/SGI/IRIX 6.5.22/IRIX 6.5.22 Overlay 1 of 3.iso",
          "discs": [],
          "cdrom": true,
          "kind": "cdrom",
          "overlay": false,
          "scratch": false,
          "size_mb": null,
          "controller": 0
        }
      },
      "nfs": {
        "shared_dir": "/Volumes/Genesis/Emulators/IRIS/indy65/shared",
        "version": "v3"
      },
      "port_forward": [
        {
          "proto": "tcp",
          "host_port": 2323,
          "guest_port": 23,
          "bind": "localhost"
        },
        {
          "proto": "tcp",
          "host_port": 2121,
          "guest_port": 21,
          "bind": "localhost"
        },
        {
          "proto": "tcp",
          "host_port": 2222,
          "guest_port": 22,
          "bind": "localhost"
        },
        {
          "proto": "tcp",
          "host_port": 5901,
          "guest_port": 5900,
          "bind": "localhost"
        },
        {
          "proto": "udp",
          "host_port": 11177,
          "guest_port": 177,
          "bind": "any"
        }
      ],
      "vino": {
        "source": "test_pattern",
        "standard": "ntsc",
        "camera_index": 0
      },
      "network": {
        "mode": "pcap",
        "pcap_interface": "en0",
        "nfs_pcap_ip": "192.168.10.213"
      },
      "scsi_deferred_int": true,
      "audio": {
        "prebuf_ms": 20
      },
      "machine": {
        "profile": "indy_ip24",
        "cpu": "r5000"
      },
      "graphics": {
        "board": "newport",
        "heads": 1,
        "resolution": "guest"
      },
      "impact": {
        "gfx": "none",
        "exp0": "none",
        "exp1": "none"
      },
      "debug": {
        "gui_gl_capture": false,
        "no_idle": false
      },
      "jitv2": {
        "threads": 1
      },
      "perf": {
        "thread_affinity": false
      },
      "clock": {}
    }

I believe this happens during early boot, while mounting the filesystem. Weird thing is, though, booting a recovery miniroot I could mount the filesystem just fine.
I'm on an M3 Pro MBP, macOS 26.6.2
Does anyone have any info on this? Thanks!

[iblowmymind]

How can I pull out the dump from the disk image? It's a chd.

[iblowmymind]

Okay, I think I have a lead. According to Claude;

Root cause of the actual fault

Extracted the real /unix kernel binary straight from the XFS root partition (via a from-scratch XFS parser, since sleuthkit's XFS support turned out to be an unofficial fork — not available here). It's unstripped with full debug info, which let me resolve the panic PC exactly.

PC: 0x8829bc68 is inside prbuild() — part of IRIX's procfs (/proc) implementation (neighboring symbols: prfork, prexit, procfs_initvfs, procfs_newvfs, prroot...). That fits perfectly: after root mounts, the kernel bootstraps /proc next, and that path produces no console output on success — exactly matching the observed sequence (Ending XFS recovery... → immediately PANIC, nothing printed in between).

Disassembly around the fault:
0x8829bc14: move  $s4, $a0              ; s4 = prbuild's 1st arg (the target struct)
...
0x8829bc5c: lw    $a3, 0x770($s4)       ; a3 = s4->field_0x770  (some sub-object pointer)
0x8829bc60: beqz  $a3, 0x8829bcd0       ; NULL-check... but only catches exactly 0
0x8829bc64: nop
0x8829bc68: lh    $at, 0x36($a3)        ; <== FAULT: read a3->field_0x36

The code does guard against a NULL pointer — but $a3 wasn't 0, it was 1. 0x1 + 0x36 = 0x37, which is exactly the Bad addr: 0x37 from the panic screen. That's not a coincidence; it's the precise arithmetic of the crash.

So the real bug: some field at offset 0x770 of the object passed into prbuild() got left holding the sentinel/flag value 1 instead of either a real pointer or a true 0/NULL — and prbuild's NULL check isn't strict enough to catch a bogus non-zero value like that. It then blindly dereferences it to read a 2-byte flags field (andi $at, $at, 2 right after — checking a specific bit), and faults.

This happens while procfs is building a process node — almost certainly for one of the very first processes at boot (pid 0/sched or pid 1's early state), whose backing structure isn't fully populated yet when procfs tries to walk it.

This fully retires the earlier "misaliased root device" theory — the message buffer already showed the correct partition-0 XFS filesystem was mounted successfully; this is an unrelated, genuine pointer bug in the procfs bootstrap path triggered right after mount completes.

Open question, worth a call: is this a latent IRIX kernel bug (would happen on real hardware too, just rare) or specifically an artifact of techomancer/iris — e.g. some structure field the emulator's boot sequence doesn't fully zero/initialize the way real hardware/PROM does, leaving stray 1s behind. Want me to chase that next (would mean finding what writes to s4+0x770 and tracing backward — either in the kernel source/decompiled logic, or on the emulator side)?

Do note that this starts happening after a kernel rebuild, I believe, so we could've hit a previously unseen CPU emulation bug.

I've attached my /unix and the full kernel dump, extracted from the dump partition (raw):
https://dropover.cloud/01fab0

[iblowmymind]

Okay so, the same crash happens with MAME too. Puzzled. Did I screw up my kernel somehow?

[iblowmymind]

Tried a rebuild with booting onto recovery, mounting /dev/dsk/realroot and chrooting into it, running lboot to link a new kernel and I get the same error. Any way I can restore a stock kernel?

[iblowmymind]

Huge discovery: Pinpointed the crashing down to patches installed from https://archive.org/download/sgi-irix-patches/patches_6.5.22_64bit.tar ! For reference, booted to inst miniroot, keep *, remove patch*, go; rebooted and no more crashes! It has to be caused by one of the patches checked here, which are the ones I installed (patchSG0004605 from DevF 1.3 ruled out):

[techomancer]

its not the patches, i have fully patched irix 6.5.22 and it works in r5k mode.
i will investigate.

[techomancer]

btw r5k alone does not cause autoconfig. 6.5.22m kernel is the same for r4k and r5k and does not use any r5k/mips4 instructions.
i would recommend not to use mame chd images, i think they may have some xfs corruption.
hit me up on sgug discord in #emulation channel