Created attachment 282339 [details] kernel config From 5.1-rc1, my multi-head amdgpu polaris11 system will often only display on one head in (non-X) text frame-buffer mode. The not-working head stays on, but blank. It worked fine in 5.0, and is broken at least thru 5.1-rc5. The initial DRI display will come up on both heads if both TV/monitors are on at kernel load, but even then, if I start X (with KDE/Plasma), where it displays correctly on both monitors regardless of what it does outside X, and ctrl-alt-Fn back to a different VT still in text-fb mode, or quit X, it'll often (always?) only display the text-fb mode on one instead of both. Which one seems somewhat random tho it might be consistent with which one, or both, were on at amdgpu driver load, as it seems (mostly? entirely?) consistent for a single boot. At a guess it might be trying to use the same clock rate and etc settings for both outputs at the same resolution, but one needs slightly different settings. X presumably programs the different outputs correctly, so it works there, and as I said it worked correctly in text-fb mode in 5.0. dmesg reports: [drm] initializing kernel modesetting (POLARIS11 0x1002:0x67EF 0x1458:0x22DD 0xCF). ... [drm] Display Core initialized with v3.2.17! [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. ... fbcon: amdgpudrmfb (fb0) is primary device Console: switching to colour frame buffer device 320x108 amdgpu 0000:01:00.0: fb0: amdgpudrmfb frame buffer device [drm] Initialized amdgpu 3.30.0 20150101 for 0000:01:00.0 on minor 0 Xorg's log reports: AMDGPU(0): Chipset: "AMD Radeon (TM) RX 460 Graphics" (ChipID = 0x67ef) ... AMDGPU(0): glamor X acceleration enabled on AMD Radeon (TM) RX 460 Graphics (POLARIS11, DRM 3.30.0, 5.1.0-rc5-dirty, LLVM 8.0.0) I have the following CONFIG_CMDLINE: CONFIG_CMDLINE="rootwait net.ifnames=0 video=HDMI-A-1:1920x1080 video=DVI-D-1:1920x1080 video=DisplayPort-1:1920x1080" But only two of the three video ports are actually connected, HDMI-A-1 (kernel, X says 0 not 1) and DisplayPort-1. HDMI-A-1 is actually connected to a 4k TV and runs at its native 3840x2160 in X, but as you can see it's set for 1920x1080 in the text-framebuffer. DisplayPort-1 is a full-HD TV, thus native 1920x1080. Of note, the cable for the full-HD TV is HDMI/DVI-D single-link, TV-side HDMI, with a DVI-D/DisplayPort adaptor, so I can connect it via DVI-D or DisplayPort. As noted, it's currently connected via DisplayPort. I'm attaching kernel config. I'll add boot dmesg.
Can you bisect? Meanwhile, amdgpu.dc=0 on the kernel command line might serve as a workaround.
Created attachment 282341 [details] boot dmesg
(In reply to Michel Dänzer from comment #1) > Can you bisect? > > Meanwhile, amdgpu.dc=0 on the kernel command line might serve as a > workaround. [Wow. Fast response!] Yes, I can bisect, technically, anyway. But I'm selling/buying and moving between houses in the next several weeks and had hoped to avoid it. Unfortunately it might be 5.2 cycle before I get to it (tho I tend to do upgrades and bug hunting for relaxation, so there's a good chance I'll get to it before 5.2, but perhaps not in time to get the bug squashed for 5.1 if you're waiting on the bisect). That's why I didn't bisect before reporting.
Should be fixed with this patch: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.1&id=c238bfe0be9ef7420f7669a69e27c8c8f4d8a568
(In reply to Alex Deucher from comment #4) > Should be fixed with this patch: > https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5. > 1&id=c238bfe0be9ef7420f7669a69e27c8c8f4d8a568 Thanks. That's in mainline now, merged just today, and does indeed appear to fix it. =:^) I'm confused between code_fix and patch_already_available, and the status-help link doesn't help because those are apparently kernel-bugzilla-specific and the documentation isn't so doesn't cover them (bug filed on that years ago, but...), so I'll guess code_fix.