CM5: V3D alpha corruption (255 -> 247) and GPU hangs across OS versions

[markoromteh]

Describe the bug

On a Compute Module 5 Lite, 8 GB, a small offscreen GLES test repeatedly reads some opaque-red pixels as RGBA (255,0,0,247) instead of (255,0,0,255) after a GPU clear or draw. Buffer guards are intact and glGetError() returns zero. The native-V3D CPU-upload/readback control and matching llvmpipe controls pass.

This also reproduces on a freshly imaged official Raspberry Pi OS Bookworm installation, with its own stock kernel/Mesa, NVMe absent, no DSI connector enumerated, and no desktop running. Independent Piglit tests on that installation reproduce incorrect pixels and GPU hangs. Selected Khronos CTS cases also reproduced failures/hangs on the original installation.

I am reporting the reproducible graphics failure, not asserting a known regression or defective module. I have no known-working hardware-accelerated baseline on this unit. I would appreciate independent reproduction or guidance on a targeted driver/firmware test before replacing hardware. If this belongs in the Mesa tracker, please advise and I can move the report.

Steps to reproduce the behaviour

1. Boot Raspberry Pi OS with dtoverlay=vc4-kms-v3d enabled and no other GPU workload. The test uses surfaceless EGL and does not require an active desktop or monitor.

2. Save the exact clear-check.c source included below. Build with a C compiler and EGL/GLES development headers available:

   cc -O2 -Wall -Wextra clear-check.c -o clear-check -lEGL -lGLESv2

3. Run the software control; verify that the printed renderer is llvmpipe:

   env -u MESA_LOADER_DRIVER_OVERRIDE -u GALLIUM_DRIVER -u V3D_DEBUG \
     EGL_PLATFORM=surfaceless MESA_SHADER_CACHE_DISABLE=true \
     LIBGL_ALWAYS_SOFTWARE=true timeout -k 2s 15s ./clear-check clear

4. Run the GPU comparison; verify that the renderer is V3D, not a software fallback:

   env -u LIBGL_ALWAYS_SOFTWARE -u MESA_LOADER_DRIVER_OVERRIDE \
     -u GALLIUM_DRIVER -u V3D_DEBUG EGL_PLATFORM=surfaceless \
     MESA_SHADER_CACHE_DISABLE=true timeout -k 2s 15s ./clear-check clear

5. Repeat each command separately with upload and draw in place of clear. Expected output is RESULT PASS, zero bad pixels, intact guards and zero GL error in every case. Stop if a GPU reset or kernel fault occurs; these comparisons do not require a long stress test.

The program creates a 256 × 256 RGBA texture framebuffer. clear fills it with opaque red using glClear; upload copies opaque red from CPU memory; draw renders an opaque-red triangle covering the framebuffer. It compares all 65,536 pixels after readback. Exit status 0 means pass, 2 means comparison/guard/GL failure, and 3 means setup/render failure.

Device (s)

Raspberry Pi CM5 Lite, CM5108000, 8 GB RAM with wireless/Bluetooth, on the official CM5 IO Board. Official Raspberry Pi 45 W PSU and fitted heatsink; no overclock added for the tests.

Original setup: 512 GB Raspberry Pi NVMe and 10-inch Touch Display 2 on CAM/DISP0. The AI Camera is disconnected. The reduced-hardware fresh-SD comparison had no NVMe or DSI display enumerated and LightDM inactive.

System

Current original SSD installation:

Raspberry Pi OS 64-bit / Debian 13 Trixie
Raspberry Pi reference 2026-09-15
pi-gen: 2c235fa703cacb65e0fe0b2ab2fcb23d44dfd268, stage4
Linux 6.18.50+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.50-1+rpt1 (2026-09-11) aarch64
Mesa: 26.2.2-1~bpo13+0~rpt1
GPU renderer: V3D 7.1.10.2
vcgencmd version: 2026/09/25 15:59:09, version 1accd665 (release) (embedded)
EEPROM: 1accd6659983613cd104973ce2432da14f1a7682

Fresh full-OS comparison: official 2026-09-15-raspios-bookworm-arm64.img.xz, image SHA256 28c432b8abbeea65365d957f8b1d4f9ebfcca42284044c5dfa149151a501d9c9; stock kernel 6.12.109+rpt-rpi-2712, stock Mesa 24.2.8-1~bpo12+rpt5. Graphics packages were not replaced or updated before that comparison. It used the earlier 12 September EEPROM, a86983925695a7e63166327d7c002d64040ed31d.

Logs

Representative native GPU clear on the current kernel/Mesa, original 45 W PSU and updated EEPROM:

renderer=V3D 7.1.10.2
version=OpenGL ES 3.1 Mesa 26.2.2-1~bpo13+0~rpt1
operation=clear
bad x=0 y=0 rgba=255,0,0,247
bad x=4 y=0 rgba=255,0,0,247
bad x=8 y=0 rgba=255,0,0,247
bad x=12 y=0 rgba=255,0,0,247
...
RESULT FAIL pixels=65536 bad=12 alpha247=12 guards=1 gl_error=0x0

Configuration	Software clear/upload/draw	Native GPU incorrect pixels: clear/upload/draw
6.18.50 / Mesa 26.2.2, normal 8 GB	All pass	12 / 0 / 208
Same stack, verified one-node numa=fake=1 boot	All pass	12 / 0 / 193
Same stack, separate total_mem=4096 boot, original command line	All pass	13 / 0 / 195
Fresh full Bookworm SD, 6.12.109 / Mesa 24.2.8	All pass	13 / 0 / 225

The latest 18 baseline/memory cases had intact guards, zero GL errors, get_throttled=0x0 throughout, and no new GPU hang or monitor failure. Sampled 5 V readings were 5.10–5.13 V and temperatures 44–51°C. Counts vary by run; all incorrect pixels in these small C cases had alpha 247. Clean sampled values cannot exclude every electrical transient.

Separately, the fresh-SD Piglit framebuffer-clear test passed 38/38 software subtests. Its GPU run returned alpha 247 instead of 255 in the first format, then triggered three GPU resets and was stopped. Kernel messages included:

v3d 1002000000.v3d: [drm:v3d_reset [v3d]] *ERROR* Resetting GPU for hang.
v3d 1002000000.v3d: [drm:v3d_reset [v3d]] *ERROR* V3D_ERR_STAT: 0x00001000

That run reported get_throttled=0x0, approximately 34–36°C, and sampled input voltage above 5.12 V. Linux/SSH remained available during reproduced GPU hangs; these observations do not establish a whole-board reset. The small C probe's pixel corruption and the other tests' hangs are not assumed to have a proven common cause.

Additional context

• Additional bounded comparisons did not resolve corruption: 6.18.50 with 4 KiB pages, 6.12.109 with the current userspace, privately extracted Mesa 25.0.7, PCIe Gen2, a temporary 500 MHz GPU cap, and held-active V3D runtime PM. The full-SD test also reproduced the fault without NVMe.
• Zink over V3DV still produced incorrect pixels, including its upload case; true CPU-Zink controls passed. Native drawing without glClear, and a supported sRGB framebuffer, also failed. These are not an exhaustive cross-product of all software versions.
• The original PSU, a second supply, and reseating the CM5 did not eliminate corruption. A boot on the second supply recorded historical undervoltage; the subsequent original-45 W repeat above had clear flags and reproduced the same failure. No module/carrier substitution or oscilloscope measurement has been performed.
• The installed kernel source is cff533aec2fa601846766b32ff57204e0a61bed7; the relevant unconditional-MMU-flush and pre-suspend-cache-clean fixes from PR of Maira's pmdomain/downstream/timeouts branch #7400 are already present. Holding V3D continuously active also failed to remove the corruption.
• One untested question is whether the cache-lock widening proposed in drm/v3d: Widen cache_clean_lock over the whole L2TCACTL sequence #7491 has any relevance here. That PR is closed without merging; its rationale cites an erratum whose pending-flush workaround is gated to hardware older than V3D 7.1. I have not applied it or treated it as a confirmed CM5 fix.

All temporary boot overrides have been removed and normal 8 GB operation restored. The SSD desktop is currently kept usable with software rendering. I can provide additional selected logs or run a targeted patch/debug capture. Independent reproduction on another CM5 would be particularly useful.

Exact bounded reproducer: clear-check.c

/* Independent, bounded GLES2 framebuffer test. No display/camera access. */
#include <EGL/egl.h>
#include <GLES2/gl2.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static void need(int ok, const char *what) {
    if (!ok) {
        fprintf(stderr, "%s failed: EGL=0x%x GL=0x%x\n", what,
                eglGetError(), glGetError());
        exit(3);
    }
}

static GLuint shader(GLenum kind, const char *source) {
    GLuint s = glCreateShader(kind);
    glShaderSource(s, 1, &source, NULL);
    glCompileShader(s);
    GLint ok = 0;
    glGetShaderiv(s, GL_COMPILE_STATUS, &ok);
    if (!ok) {
        char log[2048];
        glGetShaderInfoLog(s, sizeof(log), NULL, log);
        fprintf(stderr, "%s\n", log);
    }
    need(ok, "shader compile");
    return s;
}

int main(int argc, char **argv) {
    const char *mode = argc == 2 ? argv[1] : "clear";
    need(!strcmp(mode, "clear") || !strcmp(mode, "upload") ||
         !strcmp(mode, "draw"), "operation");
    enum { W = 256, H = 256, N = W * H * 4, GUARD = 16 };
    EGLDisplay d = eglGetDisplay(EGL_DEFAULT_DISPLAY);
    EGLint major, minor;
    need(d != EGL_NO_DISPLAY && eglInitialize(d, &major, &minor), "eglInitialize");
    need(eglBindAPI(EGL_OPENGL_ES_API), "eglBindAPI");
    const EGLint ca[] = {EGL_SURFACE_TYPE, EGL_PBUFFER_BIT,
        EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
        EGL_RED_SIZE, 8, EGL_GREEN_SIZE, 8, EGL_BLUE_SIZE, 8,
        EGL_ALPHA_SIZE, 8, EGL_DEPTH_SIZE, 0, EGL_NONE};
    EGLConfig cfg;
    EGLint count;
    need(eglChooseConfig(d, ca, &cfg, 1, &count) && count == 1, "eglChooseConfig");
    const EGLint pa[] = {EGL_WIDTH, 16, EGL_HEIGHT, 16, EGL_NONE};
    EGLSurface surf = eglCreatePbufferSurface(d, cfg, pa);
    need(surf != EGL_NO_SURFACE, "eglCreatePbufferSurface");
    const EGLint ctxa[] = {EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE};
    EGLContext ctx = eglCreateContext(d, cfg, EGL_NO_CONTEXT, ctxa);
    need(ctx != EGL_NO_CONTEXT && eglMakeCurrent(d, surf, surf, ctx), "eglMakeCurrent");
    printf("renderer=%s\nversion=%s\noperation=%s\n", glGetString(GL_RENDERER),
           glGetString(GL_VERSION), mode);
    fflush(stdout);

    GLuint tex, fb;
    glGenTextures(1, &tex);
    glBindTexture(GL_TEXTURE_2D, tex);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, W, H, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
    glGenFramebuffers(1, &fb);
    glBindFramebuffer(GL_FRAMEBUFFER, fb);
    glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, tex, 0);
    need(glCheckFramebufferStatus(GL_FRAMEBUFFER) == GL_FRAMEBUFFER_COMPLETE,
         "framebuffer completeness");
    glViewport(0, 0, W, H);
    glDisable(GL_DITHER);
    glDisable(GL_BLEND);
    glDisable(GL_SCISSOR_TEST);
    glDisable(GL_SAMPLE_ALPHA_TO_COVERAGE);
    glDisable(GL_SAMPLE_COVERAGE);
    glPixelStorei(GL_PACK_ALIGNMENT, 1);
    glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

    unsigned char *upload = malloc(N);
    unsigned char *buf = malloc(N + 2 * GUARD);
    need(upload != NULL && buf != NULL, "allocation");
    for (int i = 0; i < N; i += 4) {
        upload[i] = upload[i+3] = 255;
        upload[i+1] = upload[i+2] = 0;
    }
    memset(buf, 0xa5, N + 2 * GUARD);
    if (!strcmp(mode, "upload")) {
        glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, W, H, GL_RGBA,
                        GL_UNSIGNED_BYTE, upload);
    } else if (!strcmp(mode, "clear")) {
        glClearColor(1, 0, 0, 1);
        glClear(GL_COLOR_BUFFER_BIT);
    } else {
        const char *vs = "attribute vec2 p; void main(){gl_Position=vec4(p,0.0,1.0);}";
        const char *fs = "precision highp float; void main(){gl_FragColor=vec4(1.0,0.0,0.0,1.0);}";
        GLuint program = glCreateProgram();
        glAttachShader(program, shader(GL_VERTEX_SHADER, vs));
        glAttachShader(program, shader(GL_FRAGMENT_SHADER, fs));
        glBindAttribLocation(program, 0, "p");
        glLinkProgram(program);
        GLint linked = 0;
        glGetProgramiv(program, GL_LINK_STATUS, &linked);
        need(linked, "program link");
        glUseProgram(program);
        const GLfloat vertices[] = {-1,-1, 3,-1, -1,3};
        GLuint vb;
        glGenBuffers(1, &vb);
        glBindBuffer(GL_ARRAY_BUFFER, vb);
        glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);
        glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, 0, NULL);
        glEnableVertexAttribArray(0);
        glClearColor(0, 0, 0, 1);
        glClear(GL_COLOR_BUFFER_BIT);
        glDrawArrays(GL_TRIANGLES, 0, 3);
    }
    glFinish();
    need(glGetError() == GL_NO_ERROR, "render");
    glReadPixels(0, 0, W, H, GL_RGBA, GL_UNSIGNED_BYTE, buf + GUARD);
    GLenum err = glGetError();
    size_t bad = 0, alpha247 = 0;
    int guards = 1;
    for (int i = 0; i < GUARD; i++)
        if (buf[i] != 0xa5 || buf[GUARD + N + i] != 0xa5) guards = 0;
    for (int i = 0; i < N; i += 4) {
        unsigned char *p = buf + GUARD + i;
        if (memcmp(p, upload + i, 4)) {
            if (bad < 16) printf("bad x=%d y=%d rgba=%u,%u,%u,%u\n",
                (i/4)%W, (i/4)/W, p[0],p[1],p[2],p[3]);
            bad++;
            if (p[3] == 247) alpha247++;
        }
    }
    printf("RESULT %s pixels=%d bad=%zu alpha247=%zu guards=%d gl_error=0x%x\n",
           !bad && guards && !err ? "PASS" : "FAIL", W*H, bad, alpha247, guards, err);
    fflush(stdout);
    eglMakeCurrent(d, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
    eglDestroyContext(d, ctx);
    eglDestroySurface(d, surf);
    eglTerminate(d);
    free(upload);
    free(buf);
    return bad || !guards || err ? 2 : 0;
}

[6by9]

Raspberry Pi OS Bookworm is now the legacy release, so will only get security fixes.

Does it fail on Raspberry Pi OS Trixie? That is over a year closer to the latest Mesa than Bookworm will be, and even that is a chunk behind latest. There have certainly been multiple patches recently looking at the GPU reset paths.

[markoromteh]

Thanks — yes, it also fails on Raspberry Pi OS Trixie 64-bit, which is the original SSD installation where the problem was first observed. Bookworm was an additional clean-install comparison.

The latest Trixie reproduction used:

Kernel: 6.18.50+rpt-rpi-2712 (1:6.18.50-1+rpt1)
Mesa: 26.2.2-1~bpo13+0~rpt1
Renderer: V3D 7.1.10.2
EEPROM: 2026-09-25, 1accd6659983613cd104973ce2432da14f1a7682

With the original 45 W PSU and get_throttled=0x0, the C reproducer returned 12 incorrect pixels for clear and 208 for draw, out of 65,536, all alpha 247 instead of 255. The native-V3D upload/readback control and all three llvmpipe controls passed. There were no GL errors or damaged guards.

That short comparison did not hang. Earlier Piglit/CTS GPU runs on Trixie also produced GPU hangs with V3D_ERR_STAT=0x00001000.

We verified that the relevant MMU-flush and pre-suspend cache-clean changes from #7400 are already present in the installed kernel source. This does not establish that every recent reset-path fix is included.

Could you recommend a specific newer kernel/Mesa version or commit to test against this reproducer? I can test a targeted build and provide the resulting logs.

[6by9]

@mairacanal can you advise on this?

[mairacanal]

The latest 18 baseline/memory cases had intact guards, zero GL errors, get_throttled=0x0 throughout, and no new GPU hang or monitor failure.

This looks like a Mesa issue to me, not a kernel issue. Considering that this reproducible in 6.12, it's reproducible in a kernel without any PM runtime changes. @markoromteh, please open an issue in [1]. In the issue, please mention which Piglit tests you ran (Was it fbo-clear-formats?).

[1] https://gitlab.freedesktop.org/mesa/mesa/-/work_items

[mairacanal]

I don't have a Raspberry Pi CM5, but on Raspberry Pi 5 Model B Rev 1.0 all tests passed (clear/upload/draw) with 6.18.50+rpt-rpi-2712 and Mesa 26.2.2-1~bpo13+0~rpt1.

[6by9]

I don't have a Raspberry Pi CM5, but on Raspberry Pi 5 Model B Rev 1.0 all tests passed (clear/upload/draw) with 6.18.50+rpt-rpi-2712 and Mesa 26.2.2-1~bpo13+0~rpt1.

CM5 is the same BCM2712 D0 step as on Pi5 16GB and more recent other Pi5 variants. (Memory says the 2GB was always D0 too)
Your Rev 1.0 is likely to be the BCM2712 C1 step (it should be readable on the top of the SoC at the end of the second line), but there shouldn't be any differences in v3d between them.

I've done a very quick test on a test on a Pi5 4GB with D0. 6.18.50+rpt-rpi-v8 or 6.18.50+rpt-rpi-2712 kernel. Mesa 26.2.2-1bpo13+0rpt1. All tests are passing for me too.

[markoromteh]

Thanks both for running the reproducer. The passing Pi 5 results are useful, especially the D0 comparison. Could someone also run it on an 8 GB CM5 with the official CM5 IO Board? I would like to distinguish a problem specific to this setup from a broader CM5 issue before replacing hardware.

To answer the Piglit question: yes, fbo-clear-formats -auto -fbo was tested. On Trixie, llvmpipe passed 38 subtests; V3D returned 22 failures and 16 skips without a hang in that run. fbo-blending-formats -auto -fbo passed 38 subtests in software, but its V3D run failed the first tested format and then hit GPU hangs. On the fresh Bookworm image, the hardware fbo-clear-formats run also produced wrong alpha values and GPU hangs. The complete results and reproducer are prepared for a Mesa issue, which has not been submitted yet.

Would you recommend a particular Mesa main commit or debug build for the next test? I have not tested Mesa main. If the small clear/draw reproducer is insufficient, which V3D debug output or trace would be most useful to distinguish a driver problem from a fault on this unit?

I also have a Pi 5 8 GB available. Would running the same diagnostic SD installation and reproducer on both boards add useful evidence, or would a CM5-specific capture be more helpful at this point?

[popcornmix]

I also have a Pi 5 8 GB available. Would running the same diagnostic SD installation and reproducer on both boards add useful evidence, or would a CM5-specific capture be more helpful at this point?

I think that would be useful. There is no relevant difference between a pi5 and cm5.
I think you either have something unique in your environment that causes the fail, or your CM5 is faulty.
Running the exact reproducer on a Pi5 would narrow this down.

[markoromteh]

I completed the comparison on my Pi 5 8 GB (Model B Rev 1.1), using the same physical diagnostic SD card and the same official 45 W PSU used with the CM5. No graphics packages, boot configuration or firmware were changed for the Pi 5 test.

This is the Bookworm SD installation that previously failed on the CM5: kernel 6.12.109+rpt-rpi-2712, Mesa 24.2.8-1~bpo12+rpt5. The stock configuration and retained test executable hashes match the earlier CM5 run; the executable was not rebuilt.

Test	CM5 on this SD	Pi 5 on this SD
V3D clear	13 incorrect pixels	Pass, 0 incorrect
V3D upload/readback	Pass	Pass
V3D draw	225 incorrect pixels	Pass, 0 incorrect
llvmpipe clear/upload/draw	All pass	All pass
Hardware fbo-clear-formats -auto -fbo	Wrong alpha, then GPU hangs	18 pass, 20 unsupported-format skips, 0 fail; no hang
Software fbo-clear-formats -auto -fbo	38 pass	38 pass

The C cases each checked 65,536 pixels, with intact guards and zero GL errors. The Pi 5 reported V3D 7.1.10.2. On the Pi 5, all eight monitored runs completed with no GPU/kernel fault or monitor error; get_throttled=0x0 throughout. In-test samples were 5.11210–5.16972 V and 40.0–45.0°C.

One remaining difference is EEPROM firmware: the Pi 5 has 2026-05-11 / 66f33f7e651cf482a26fb2c931a7587bb14e71db; the earlier CM5 SD failure used 2026-09-12 / a86983925695a7e63166327d7c002d64040ed31d. The CM5 now has September 25 firmware and still failed the separate Trixie/SSD comparisons. I have not yet repeated this SD test on the CM5 after the Pi 5 pass.

The Mesa report is https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16440. Does this comparison suggest a specific CM5 firmware or hardware-isolation check next? I can provide the selected per-case logs.

[popcornmix]

In case the CM5 is marginal (in clock/voltage sense), can you try a few things in config.txt

over_voltage_delta=50000

gpu_freq=500

arm_freq=1500

Try them one at a time, reboot and test. Report if any give a pass.

[markoromteh]

Thanks — I tried all three settings individually on the CM5, rebooting between them. None produced a pass for the clear/draw reproducer.

This comparison used the original Trixie SSD installation: kernel 6.18.50+rpt-rpi-2712, Mesa 26.2.2-1~bpo13+0~rpt1, September 25 EEPROM, the same retained C executable, and the original official 45 W PSU. Each setting was applied through a full copy of the normal configuration in a one-shot tryboot.txt; settings were not combined. The active values were checked after each boot before testing.

Setting for this boot	V3D clear: incorrect pixels	V3D upload/readback	V3D draw: incorrect pixels
Fresh normal baseline	17	Pass	222
over_voltage_delta=50000 only	12	Pass	189
gpu_freq=500 only	62	Pass	80
arm_freq=1500 only	13	Pass	207

Each case checked 65,536 pixels. All mismatches were the same alpha 247 instead of 255; guards remained intact and GL error was zero. All 12 llvmpipe controls passed. Across the 24 bounded cases there were no new GPU hangs, kernel-fault detections or monitor failures, and get_throttled=0x0 throughout.

The voltage-offset trial reported over_voltage_delta=50000 with normal clocks; sampled core voltage increased from approximately 0.877 V to 0.927 V. The GPU trial reported both V3D and core at a configured maximum of 500 MHz, with zero voltage offset and the normal 2400 MHz CPU maximum. The CPU trial reported 1500 MHz, with both CPU frequency-policy maxima at 1500000 kHz, normal V3D configuration, and zero voltage offset. Normal V3D configuration on this CM5 reports 1150 MHz. No force_turbo setting was enabled. Normal settings have now been restored and the temporary trial file removed.

Given these results and the passing comparison on my Pi 5 with the same diagnostic SD and PSU, is there another specific check that could distinguish the CM5 module from its IO board or a CM5-specific firmware issue before arranging a hardware replacement? Selected per-case logs are available.

[popcornmix]

force_turbo=1 could be worth a try if the issue occurs at idle rather than turbo voltages.
I'd also try both gpu_freq=500 and arm_freq=1500 (which forces the idle voltage).

But otherwise, most likely it is the CM5 module that is faulty.
It's less likely to be IO board or power supply (given no under-voltage report in get_throttled and no improvement with lower clocks).

[markoromteh]

I tested both additional configurations on the CM5. Neither fixed the corruption.

Configuration	V3D clear: incorrect pixels	V3D upload/readback	V3D draw: incorrect pixels
force_turbo=1 only	19	Pass	209
gpu_freq=500 + arm_freq=1500, with forced turbo disabled	72	Pass	120

Each case checked 65,536 pixels. All mismatches were still alpha 247 instead of 255, with intact guards and zero GL errors. All six llvmpipe controls passed. There were no new GPU hangs, monitoring failures or throttling flags during these 12 bounded cases.

Both trials used the same Trixie SSD, kernel 6.18.50+rpt-rpi-2712, Mesa 26.2.2-1~bpo13+0~rpt1, September 25 EEPROM, retained C executable and original 45 W PSU. Each trial was built from the unchanged normal configuration; the earlier voltage offset was absent. Tests started after 75 seconds uptime, beyond the unchanged initial_turbo=60 startup period.

The first trial reported force_turbo=1, ARM/V3D/core maxima of 2400/1150/910 MHz and zero voltage offset. The combined trial reported force_turbo=0, ARM/V3D/core maxima of 1500/500/500 MHz, both CPU policy maxima at 1500000 kHz, and zero voltage offset. Sampled clocks matched those operating values; core voltage was approximately 0.877 V with forced turbo and 0.751–0.753 V with the combined limits. Temperatures during the cases were 46.1–49.4°C. Clock and PMIC samples were retained alongside the output and kernel logs.

That completes all five configurations you suggested, with no passing clear/draw result on this CM5. The same diagnostic SD and PSU previously passed on my Pi 5. Does this evidence now justify requesting assessment/replacement of the CM5 module first, rather than buying both a module and an IO board? I can provide selected logs for that assessment.