Skip to content

G15: T6031 (M3 Max, J516C) GPU firmware TEXT not pinned: a third J516C build is refused #289

New issue
New issue
Open
Open
G15: T6031 (M3 Max, J516C) GPU firmware TEXT not pinned: a third J516C build is refused#289

Description

@malik-na
malik-na
opened on Oct 30, 2026

A 16-inch M3 Max (T6031 G15C, reported as J516C by the supported list) on edge refuses the G15 probe, so there is no render node and it falls back to software rendering (llvmpipe). The display (apple-drm) comes up fine. This is the same pattern as #247 on the J514S, but on the Max.

Probe log, as posted on the Omarchy Mac Discord by MikeK on 30 Oct:

asahi-g15 40a400000.gpu: G15: probing (T6031 G15C)
asahi-g15 40a400000.gpu: unsupported GPU firmware build: TEXT 0x64000 DATA 0x140000 GKTS 0x5cf28 sha256 125f0497c7904fde87b05a9264a88cf03bdb3572a1715cec91bd0f9b78245544; to have it supported, report this line and the macOS version of the boot chain that loaded it
asahi-g15 40a400000.gpu: supported: macOS 14.7 stub firmware (iBoot-10151.140.19.700.2), J516C
asahi-g15 40a400000.gpu: supported: macOS 14.8 stub firmware, J516C
asahi-g15 40a400000.gpu: loaded GFX TEXT identity mismatch: EINVAL
asahi-g15 40a400000.gpu: probe with driver asahi-g15 failed with error -22

What the code says (drivers/gpu/drm/asahi/g15/hw/t6031.rs on integration/aurora): CONFIG.firmware has two builds, both TEXT 0x64000, DATA 0x140000, marker 0x5cf28. Their digests start c26ec89c... (macOS 14.7 stub) and 1bf2fd34... (macOS 14.8 stub). The reported 125f0497... has the same three sizes and marker but a different digest, so it is a further RTKit-2419.140.12 build that is not pinned.

Questions:
0. Which kernel is running? The report does not say. If it is older than the current integration/aurora, the build may already be admitted there. Please post uname -r and the linux-aurora package version.

  1. Which boot chain loaded it? The report has no asahi,os-fw-version, asahi,iboot2-version or asahi,system-fw-version. Please post cat /proc/device-tree/chosen/asahi,*-version (or the m1n1 log).
  2. Is the layout identical? On T6030 the three builds in G15: T6030 (M3 Pro) GPU firmware TEXT varies between Macs on the same boot chain; two J514S builds are refused #247 all booted with the same layout once admitted. On T6031 the layout and board images were measured on one J516C, so a second Max should confirm the first job runs, not only the probe.

Workaround for a single boot: asahi.g15_accept_text_prefix=0x125f0497c7904fde (the 16-digit form that worked in #247), which logs the digest.

Proposed fix: add a pin for 125f0497... once its boot chain is known and one J516C owner has run a compute job with the override. If the TEXT depends on the chip revision rather than the macOS version, as asked in #247, the pins may need keying by revision.

Activity

  1. malik-na commented on Oct 30, 2026

    @malik-na
    malik-na
    on Oct 30, 2026
    MemberAuthor

    The reporter (MikeK, on the Omarchy Mac Discord) answered the three questions and tested the workaround.

    • Model: MacBook Pro 16" M3 Max, 40-core GPU, 64 GB, 1 TB, so a J516C.
    • Kernel: 7.2.11-11-1-ARCH, package linux-aurora 7.2.11.aurora11-1, so this build is still refused on the current pin.
    • Boot chain as he pasted it (the fields ran together): mBoot-20457.1.29, iBoot-10151.140.19.700.2, m1n1 v1.6.1-dirty bc79acc4-dirty, and a trailing 14.727.0, probably OS 14.7 and system firmware 27.0 run together. Please confirm with cat /proc/device-tree/chosen/asahi,*-version.
    • With asahi.g15_accept_text_prefix=0x125f0497c7904fde the driver loads, /dev/dri/renderD* is present and glxgears runs. He did not report a compute job or longer use.

    So the build 125f0497... works with the existing J516C layout at least as far as probing and basic rendering. A pin can be added once someone confirms a compute job on it.

  2. maralcbr commented on Oct 30, 2026

    @maralcbr
    maralcbr
    on Oct 30, 2026
    Member

    The comment's boot chain changes what this issue is about. The reference J516C in #249 recorded iBoot-10151.140.19.700.2, system firmware 27.0 and OS firmware 14.7, which loads the c26ec89c… pin. If 14.727.0 reads as 14.7 + 27.0, this Mac reports the same iBoot2, OS and system-firmware versions but loads a different TEXT digest (125f0497…).

    That isn't the same as an identical boot chain. iBoot1 (mBoot-20457.1.29 here), the hardware revision and any m1n1 changes (v1.6.1-dirty) aren't compared yet. Still, it means the matched versions don't select the TEXT on their own. #247 found the same thing on T6030, and this also weakens the idea there that system firmware 26.6.2 vs 27.0 is what separates the builds.

    Two wording fixes:

    • Call it "a TEXT digest not seen before", not "a further RTKit-2419.140.12 build". Matching sizes and marker don't establish build identity or ABI compatibility.
    • The pin label "macOS 14.7 stub firmware (iBoot-10151.140.19.700.2)" says where the measurement came from. It doesn't identify that build uniquely.

    Before adding more digest pins, it's worth finding out what varies:

    1. Repeatability. Hash the TEXT over several cold boots on each unit. A per-unit constant and a per-boot change lead to different fixes.
    2. Byte diff. Compare loaded TEXT dumps from the reference J516C and this Mac, and the decoded Preboot payloads where they can be obtained, to see which ranges differ and why (a payload variant, relocation or patching at load, embedded device data, or padding inside the hashed region).
    3. Record per report: iBoot1, the exact m1n1 build, the chip revision and the firmware build identifiers. Labelled, so the fields don't run together:
    for f in /proc/device-tree/chosen/asahi,*-version; do
  printf '%s: ' "${f##*/}"
  tr -d '\000' < "$f"
  printf '\n'
done

    If the diff shows bounded, explained per-unit fields, normalising them (each one validated, with the platform and layout gates kept) could replace digest pins on T6030 and T6031. That widens admission beyond byte-identical firmware, though, so it needs maintainer agreement first. Track it with #247 as a related investigation, without assuming one fix covers both.

    As a stopgap, pinning 125f0497… is fine once this unit has also passed:

    • A compute job, with correct results and no faults in dmesg. The T6031 compute registers were measured on one J516C, and the two-cluster values fault the first job, so glxgears doesn't cover it.
    • A renderer check. glxinfo -B should report the Apple M3 Max renderer rather than llvmpipe. A render node and glxgears alone don't rule out software rendering.

  3. digital-brew commented on Oct 31, 2026

    @digital-brew
    digital-brew
    on Oct 31, 2026

    A second J516C with 125f0497…, with the compute job and renderer check asked for above.

    Machine: 16-inch M3 Max, 40-core GPU (J516C). Kernel 7.2.11-11-90-ARCH (aurora11 + the T6031 external display series in #292; the G15 driver is unchanged), Mesa 26.3.0-devel (git-672657e05e) (mesa-aurora 20261029), override asahi.g15_accept_text_prefix=0x125f0497c7904fde.

    asahi,iboot1-version: mBoot-20457.41.3
asahi,iboot2-version: iBoot-10151.140.19.700.2
asahi,m1n1-stage1-version: v1.6.1-dirty
asahi,m1n1-stage2-version: 77f000bf-dirty
asahi,os-fw-version: 14.7
asahi,system-fw-version: unknown

    So iBoot2 and OS firmware match the reference J516C and MikeK's, iBoot1 differs from MikeK's (mBoot-20457.1.29), and the TEXT is still 125f0497….

    Probe:

    GPU firmware build admitted by g15_accept_text_prefix: TEXT 0x64000 DATA 0x140000 GKTS 0x5cf28 sha256 125f0497c7904fde87b05a9264a88cf03bdb3572a1715cec91bd0f9b78245544
M3: firmware identity accepted
board data sha256 205a0323f46fc7f2f812c5356c6c0daff76df3d4bf08ba793e5e309d0af5a11b
T6031 G15C admitted, ASC=0x0
T6031 G15C: power acknowledged, version=0x7041100 counts=0x21040a core-mask=0xffffffffff
T6031 G15C: cores enabled per cluster: [10, 10, 10, 10]

    Repeatability: the same TEXT digest in all 13 boots kept in the journal (3 refused before the override, 10 admitted with it), with the same board data digest in all 10 admitted boots. These are warm and cold boots mixed; I did not record which.

    Renderer: glxinfo -B reports Apple M3 Max (G15C B2), Accelerated: yes, OpenGL 4.6 core and ES 3.2. vulkaninfo --summary: Apple M3 Max (G15C B2), driver Borealis, API 1.4.363. Not llvmpipe.

    Compute job: GLES 3.1 compute on the render node (EGL on GBM, no display): 20 dispatches of 4M invocations, each running 2000 rounds of an integer LCG + xorshift into an SSBO, results checked on the CPU (every invocation of the first and last dispatch, every 61st of the rest). 0 mismatches, no GL errors, 0.33 s of GPU time. No GPU messages in dmesg during or after the run, and no faults in any admitted boot. There is no OpenCL ICD on this install, so this is GL compute, not OpenCL.

    Daily use with the override over those 10 boots: a Hyprland desktop on the GPU, with the internal panel and one external display (up to 120 Hz) on dma-buf scanout, without GPU faults.

    Not done: TEXT dumps or a byte diff against the reference J516C, the chip revision.

    🤖 Generated with Claude Code

  4. DaniBedz commented on Nov 7, 2026

    @DaniBedz
    DaniBedz
    on Nov 7, 2026

    Another J516C (16" M3 Max, 40-core GPU), with a fourth TEXT digest:

    unsupported GPU firmware build: TEXT 0x64000 DATA 0x140000 GKTS 0x5cf28 sha256 669913fba2736e4b8f8a0f81eadc5ac00c9dc51fdd4c9d3770c66d2b0a1e8786

    Boot chain: iBoot1 mBoot-18000.161.9, iBoot2 iBoot-10151.140.19.700.2, OS firmware 14.7, system firmware 26.6 (the reference unit in #249 had 27.0, which might explain the different digest). Kernel linux-aurora 7.2.11.aurora15-1.

    With asahi.g15_accept_text_prefix=0x669913fba2736e4b it's admitted, cores enabled per cluster: [10, 10, 10, 10], renderD128 shows up and Vulkan reports Apple M3 Max (G15C B2).

    Compute: llama.cpp (Vulkan backend) running Qwen3.5-0.8B Q4_K_M fully on the GPU. Output is coherent and matches a CPU-only run apart from normal float drift, ~72 tok/s vs ~12.6 on CPU. No GPU messages in dmesg during or after. Only one boot and short runs so far, no suspend testing yet.

  5. mvanduijker commented on Nov 8, 2026

    @mvanduijker
    mvanduijker
    on Nov 8, 2026

    Another J516C (16" M3 Max, 40-core GPU) on the 125f0497 build: admitted with the override, GPU comes up.

    Kernel: 7.2.11-14-1-ARCH (linux-aurora 7.2.11.aurora14-1, mesa-aurora 26.3.0_devel.20261031). Without the override the probe fails with loaded GFX TEXT identity mismatch: EINVAL (-22).

    Boot chain:

    asahi,iboot1-version: mBoot-18000.161.10
asahi,iboot2-version: iBoot-10151.140.19.700.2
asahi,m1n1-stage1-version: v1.6.1-dirty
asahi,m1n1-stage2-version: bc79acc4-dirty
asahi,os-fw-version: 14.7
asahi,system-fw-version: 26.6.2

    Note that iBoot1 is 161.10, while the 669913fb report above has 161.9.

    Override: options asahi g15_accept_text_prefix=0x125f0497c7904fde in /etc/modprobe.d/, rebuilt with limine-mkinitcpio.

    asahi-g15 40a400000.gpu: GPU firmware build admitted by g15_accept_text_prefix: TEXT 0x64000 DATA 0x140000 GKTS 0x5cf28 sha256 125f0497c7904fde87b05a9264a88cf03bdb3572a1715cec91bd0f9b78245544
asahi-g15 40a400000.gpu: M3: firmware identity accepted
asahi-g15 40a400000.gpu: board data sha256 3a7d215147c4bd0f4ec6f85d14963632e6f166048be04830b1e7ef72a9a1ad6d
asahi-g15 40a400000.gpu: T6031 G15C: power acknowledged, version=0x7041100 counts=0x21040a core-mask=0xffffffffff
asahi-g15 40a400000.gpu: T6031 G15C: cores enabled per cluster: [10, 10, 10, 10]
asahi-g15 40a400000.gpu: G15: firmware at READY, starting the backend

    renderD128 is present. Hyprland now composites on the GPU, and 120 Hz is smooth again (it was CPU-composited before). No asahi faults, errors or timeouts in dmesg so far.

    Not yet done: a known-answer compute job, a glxinfo -B renderer check, a cold-boot repeatability check (this is one boot), and suspend. I'll add them if I get time.

  6. mlninja-dev commented on Nov 8, 2026

    @mlninja-dev
    mlninja-dev
    on Nov 8, 2026

    Another J516C (16" M3 Max, 40-core GPU, 128 GB) on the 669913fb… build, the same TEXT digest as DaniBedz's unit above: admitted with the override, the GPU comes up and Hyprland composites on it.

    Boot chain:

    asahi,iboot1-version: mBoot-18000.161.10
asahi,iboot2-version: iBoot-10151.140.19.700.2
asahi,m1n1-stage1-version: v1.6.1-dirty
asahi,m1n1-stage2-version: c6048a67-dirty
asahi,os-fw-version: 14.7
asahi,system-fw-version: 26.6.2

    These are the same iBoot1, iBoot2, OS firmware and system firmware versions as mvanduijker's 125f0497 unit above, but the TEXT digest here is 669913fb…. So these labelled versions don't select the TEXT on their own.

    Software:

    Override: asahi.g15_accept_text_prefix=0x669913fba2736e4b on the kernel command line.

    Probe:

    asahi-g15 40a400000.gpu: GPU firmware build admitted by g15_accept_text_prefix: TEXT 0x64000 DATA 0x140000 GKTS 0x5cf28 sha256 669913fba2736e4b8f8a0f81eadc5ac00c9dc51fdd4c9d3770c66d2b0a1e8786
asahi-g15 40a400000.gpu: M3: firmware identity accepted
asahi-g15 40a400000.gpu: board data sha256 13acd9a08811187076d1c8f38a337c0f026bb557c1069798b771d5c93ad22485
asahi-g15 40a400000.gpu: T6031 G15C admitted, ASC=0x0
asahi-g15 40a400000.gpu: T6031 G15C: power acknowledged, version=0x7041100 counts=0x21040a core-mask=0xffffffffff
asahi-g15 40a400000.gpu: T6031 G15C: cores enabled per cluster: [10, 10, 10, 10]
asahi-g15 40a400000.gpu: G15: firmware at READY, starting the backend

    Repeatability: the same TEXT digest appears in all 5 boots kept in the journal. 4 were refused before the override (loaded GFX TEXT identity mismatch: EINVAL), and 1 was admitted. These were mostly warm reboots; I didn't record which were cold.

    Renderer:

    • Vulkan: vulkaninfo --summary reports Apple M3 Max (G15C B2), driver Borealis, API 1.4.363, Mesa 26.3.0-devel (git-a196911147).
    • Hyprland 0.56.2 now composites on the GPU. Its CPU use fell from about 1000–1270 % (llvmpipe, 12+ threads) to 13–32 %, with no llvmpipe threads left. Aquamarine's initMgpu: no renderer and Failed to update renderer state for HDMI-A-1 on applyCommit errors (about 21/s before) are gone.
    • Displays: the internal panel at 3456x2234@120, and an external 4K monitor on HDMI at 3840x2160@60 (dcpext0, M3 Max (J516C): external displays over USB-C and HDMI #292).
    • Errors: no asahi-g15 faults, errors or timeouts in dmesg.

    Not done yet: a known-answer compute job, glxinfo -B (mesa-utils isn't installed), a cold-boot repeatability check, suspend, and use beyond a few minutes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions