Created attachment 139004 [details]
callstack from DRM/radeon
DRM/radeon fails with in drm_dp_link_rate_to_bw_code
Driver fails to negotiate video resolution with DP-connected monitor, on any of 4 DP ports.
Controller can drive monitor at 2048x1080 through HDMI adapter. Straight DP cable only works in console (low-res)
Disconnecting power cable from monitor for 5 minutes trick doesn't help ;)
Video controller: FirePro v8800 ChipID 0x6888 (see hardware.txt for details, 4 DPs)
DP monitor: Dell U2717DA
Workstation: HP xw8600
Kernel messages with backtrace: see var_log_messages_excerpt.txt
Max res supported by monitor: 1440p (see Xorg.0.log)
Created attachment 139005 [details]
"xrandr --current" with DisplayPort-to-HDMI connected
Created attachment 139006 [details]
"lspci -k -vv -b" output (snipped, showing v8800-related stuff only)
Created attachment 139007 [details]
Xorg output (shows modelines and mysterious flip queue failed messages)
Forgot to mention... last but not least:
$ uname --all
Linux xw8600.EDITED 4.16.2-gentoo-xw8600-fj #1 SMP PREEMPT Sat Apr 21 10:20:24 EDT 2018 x86_64 Intel(R) Xeon(R) CPU X5450 @ 3.00GHz GenuineIntel GNU/Linux
If there's anything else I can provide that would help further diagnosing this issue, I'll gladly try.
Steps I'm thinking about taking for further experiments, in the meantime:
1) try with latest stable kernel available for my distro
2) try with liveCD of a commercial distro /w rolling release
3) try with older liveCD /w fglrx driver (perhaps from 2011)
I can change the radeon files to output more data or 'debug' trace too. I would need minimal guidance for which DEFINE to set prior rebuilding to get that debug trace.
Thank you very much in advance; I can't understand why this pro beast from 2010 can't drive that monitor through DisplayPort.
Please attach your full dmesg output.
Created attachment 139014 [details]
dmesg with 4.16.2
Thank you so much Alex to help out on this! I'll generate another dmesg dump with 4.16.3
Created attachment 139017 [details]
dmesg with 4.16.3
backtrace disappears in 4.16.3, still no image.
Just found out about drm.debug. Would you like me to generate a new dmesg output? With which drm.debug value?
The bug is caused by having both the audio signal and image simultaneously, it seems.
After I added "radeon.audio=0" to the kernel argument list and rebooted, the video interface and the monitor concluded their signal handshake successfully (!) and I could switch the monitor to full res and, lo' behol', a 1440p image (!!).
For future reference, should anyone have issues, try radeon.audio=0. If you were relying on the radeon for audio, look for an alternative, or use a DP-to-HDMI adapter and tolerate the lower resolution until the bug is fixed.
Googling on this specific symptom revealed multiple regressions on this matter before, it could be a new one or it's been lurking for a while. Which means either:
- tons of dupes in the DRM bugs list wrt radeon and DP /w audio enabled and users don't know how to disable it.
- all radeon users having switched their audio off
- most radeon users gave up on their DisplayPort or their radeon-based card altogether (perhaps switching brand in the process, frustration kicking in)
- it's a recent regression and I've been lucky to catch it before the kernel goes mainstream in major distros.
I'll still provide a dmesg dump, this time with drm.debug=0x06 (0x06 any good? any prefered value?) by rebooting with audio back on and image gone.
Created attachment 139082 [details]
dmesg (Linux 4.16.3, drm.debug=0x06, audio enabled)
Created attachment 139083 [details]
REAL dmesg output (with debug messages)
Last attachment for tonight. This one its not /var/log/messages but really dmesg output. We can see the debug messages as I disconnected the HDMI cable, then connected the DP cable (no image, audio enabled), then disconnected and reconnected the HDMI cable.
Hopefully that will be useful to stabilize DP display with audio.
[ 1288.208351] [drm:radeon_process_aux_ch.constprop.2 [radeon]] dp_aux_ch flags not zero
[ 1288.208354] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -5
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/849.