Bug 106191

Summary: FirePro v8800 Failure to recognize DisplayPort signal
Product: DRI Reporter: François Jacques <francois.jacques>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: major    
Priority: medium CC: francois.jacques
Version: DRI gitKeywords: have-backtrace
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
callstack from DRM/radeon
none
"xrandr --current" with DisplayPort-to-HDMI connected
none
"lspci -k -vv -b" output (snipped, showing v8800-related stuff only)
none
Xorg output (shows modelines and mysterious flip queue failed messages)
none
dmesg with 4.16.2
none
dmesg with 4.16.3
none
dmesg (Linux 4.16.3, drm.debug=0x06, audio enabled)
none
REAL dmesg output (with debug messages) none

Description François Jacques 2018-04-23 13:23:33 UTC
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)
Comment 1 François Jacques 2018-04-23 13:24:25 UTC
Created attachment 139005 [details]
"xrandr --current" with DisplayPort-to-HDMI connected
Comment 2 François Jacques 2018-04-23 13:25:14 UTC
Created attachment 139006 [details]
"lspci -k -vv -b" output (snipped, showing v8800-related stuff only)
Comment 3 François Jacques 2018-04-23 13:27:08 UTC
Created attachment 139007 [details]
Xorg output (shows modelines and mysterious flip queue failed messages)
Comment 4 François Jacques 2018-04-23 13:29:18 UTC
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
Comment 5 François Jacques 2018-04-23 13:34:58 UTC
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.
Comment 6 Alex Deucher 2018-04-23 14:43:54 UTC
Please attach your full dmesg output.
Comment 7 François Jacques 2018-04-23 16:44:13 UTC
Created attachment 139014 [details]
dmesg with 4.16.2
Comment 8 François Jacques 2018-04-23 16:48:43 UTC
Thank you so much Alex to help out on this! I'll generate another dmesg dump with 4.16.3
Comment 9 François Jacques 2018-04-23 17:14:07 UTC
Created attachment 139017 [details]
dmesg with 4.16.3

backtrace disappears in 4.16.3, still no image.
Comment 10 François Jacques 2018-04-24 11:10:43 UTC
Just found out about drm.debug. Would you like me to generate a new dmesg output? With which drm.debug value?
Comment 11 François Jacques 2018-04-25 01:26:32 UTC
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.
Comment 12 François Jacques 2018-04-25 02:14:57 UTC
Created attachment 139082 [details]
dmesg (Linux 4.16.3, drm.debug=0x06, audio enabled)
Comment 13 François Jacques 2018-04-25 02:24:28 UTC
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.

Interesting bits:
[ 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
Comment 14 Martin Peres 2019-11-19 09:33:17 UTC
-- 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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.