[Investigation request] MacPro6,1 Tahiti/D700 7.3 HDMI framebuffer pin -ENOMEM; 1080p workaround
@ptr1337 is already working on this.
Since Oct 25, 2026.
Assessment
This issue has not been assessed yet.
Description
Pre-flight checklist
- I have searched existing issues/PRs and this has not been requested before.
- I have read the Contributing Guidelines.
Request type
- New patch / patchset inclusion
- Kernel config change (enable/disable option)
- New kernel variant
- Scheduler tuning / addition
- Compiler / LTO / PGO optimization
- Security hardening
- Driver or hardware enablement
- Other
Summary
Please advise which display/TTM patch or diagnostic path is appropriate for a MacPro6,1 with dual FirePro D700 (Tahiti), where an HDMI-connected TV lost its picture on CachyOS-based 7.3 boots and recovered at 1080p60. This is a hardware-enablement/investigation request, not a claim of a proven upstream regression or a ready patch. I am using this form because I cannot truthfully check the bug form’s required Arch-linux/latest-unmodified-kernel comparison boxes. Those comparisons have not been performed.
Motivation / use case
Apple MacPro6,1, Xeon E5-2697 v2 (12 cores/24 threads, no AVX2), 64 GiB RAM; two FirePro D700 / PCI 1002:6798 with 6 GiB each; AMDGPU SI, Mesa/RADV 26.2.4, Plasma/KWin 6.8.1, Wayland. Four displays: Apple Thunderbolt Display, two Lenovo T2424pA, TCL 55S421 TV on an HDMI-connected path exposed as DP. All outputs report VRR incapable.
The retained 7.2.7-1-cachyos-rt-bore boot had a working TV and zero framebuffer-pin errors, with GPU 06:00.0 initialized. The distro 7.3.0-rc4-1-cachyos-rc boot lost the TV picture and recorded 717 pin errors, with both GPUs initialized. A later custom 7.3.0-4-macpro61-clang boot also lost the TV picture and recorded 204 errors initially, increasing to 219 before the mode workaround. Counts are cumulative snapshots, not comparable rates. The RC failure predates the custom GMUX patch.
Patch / upstream reference (if available)
Related issues #1075 and #1094 involve newer GPUs/VRR/FRL; I am not assuming the same cause or blindly applying those fixes.
No proposed fix patch yet. I would appreciate guidance on an appropriate clean comparison, relevant backport/revert, or specific TTM/scanout diagnostics for DCE/Tahiti.
Testing / benchmarks
Physical observations: at 4096x2160@30, KDE reported the TCL TV connected/enabled but it had no picture. EDID identity matched the prior working TV; audio ELD identified 55S421. Changing only this TV to its advertised 1920x1080@60 mode, keeping scale 1.5 and other displays unchanged, restored its picture and stopped mouse jumping. The user confirmed both. The pin-error count remained at 219 during the subsequent observation and separate short Vulkan rendering checks. 3840x2160@30 has not been tested.
Repeated sanitized kernel messages from the failing boot:
amdgpu 0000:06:00.0: [object-address-redacted] pin failed
[drm:amdgpu_dm_plane_helper_prepare_fb] *ERROR* Failed to pin framebuffer: -ENOMEM
No matching system OOM, GPU reset or ring-gfx-timeout messages were found at that inspection. One snapshot showed ~1.44 GB VRAM used and ~198 MB of the 256 MB visible BAR used; this does not prove the allocation failure cause.
Additional context
Important confounders: the final-7.3 comparison used a custom build from CachyOS recipe 523baf9cc1e37b7f8079064447f1418702c45154 / signed cachyos-7.3.0-4 source, Clang 23.1.3, ThinLTO/O3, x86-64-v1 with Ivy Bridge tuning, BORE, built-in AMDGPU/SI and embedded firmware, driver trimming, and an experimental MacPro6,1-only bypass of vga_switcheroo_client_probe_defer(). Both GPUs initialize on the 7.3 boots but only the display GPU initialized on the working 7.2.7 boot. The working boot also used a different GPU power-feature mask and mitigations setting. Kernel version, GPU initialization and command-line differences are therefore not isolated. No Arch linux or vanilla/upstream comparison has been performed. Adapter model is not yet recorded.
The original failing setup is historical; the current machine keeps the confirmed 1080p60 workaround and recovery kernels. I am requesting maintainer guidance, not asserting that the experimental platform patch belongs upstream or that newer-kernel versions remain affected.
- Dominant language
- Shell
- Stars
- 4.7k
- Forks
- 174
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 5
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CachyOS/linux-cachyos
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
CachyOS/linux-cachyos#1091 · 1 reaction ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
CachyOS/linux-cachyos#961 · 1 comment ·
-
[BUG] linux-cachyos on iMac 18,1 Intel i5 Iris Graphics causes it to freeze on boot with blank screenPossibly taken @ptr1337 claimed this today. Openbug
CachyOS/linux-cachyos#1116 · 2 assignees ·
-
Difficulty 4/5 3-5 days Newbie friendliness 47/100
CachyOS/linux-cachyos#1115 · 1 comment ·
-
[FEATURE] Missing regular x86-64 build of 7.3 kernelPossibly taken @ptr1337 claimed this 2 days ago. Openenhancement
CachyOS/linux-cachyos#1111 · 2 assignees ·
All issues in CachyOS/linux-cachyos
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
pypa/advisory-database#412 ·
Maintainers usually reply within 1 day
-
GEFSv12
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100