Bug 101559 - Displays fail to wake up when booting machine away from Display Port KVM switch
Summary: Displays fail to wake up when booting machine away from Display Port KVM switch
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-22 16:36 UTC by dhruv.a.thakkar
Modified: 2019-12-04 09:29 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log (45.25 KB, text/plain)
2017-06-22 16:36 UTC, dhruv.a.thakkar
no flags Details
/var/log/messages (2.40 MB, text/plain)
2017-06-22 16:37 UTC, dhruv.a.thakkar
no flags Details
xorg.conf for nouveau driver (2.97 KB, text/plain)
2017-06-22 16:38 UTC, dhruv.a.thakkar
no flags Details

Description dhruv.a.thakkar 2017-06-22 16:36:51 UTC
Created attachment 132142 [details]
Xorg.0.log

Description of problem:

We are trying to solve an issue in which displays fail to wake up when booting a Rhel 7.3 machine (Machine A) connected to a Display Port KVM while the KVM is pointing to Machine B. The unusual bit is that xorg logs in /var/log/Xorg.0.log indicate that everything comes up correctly, and a "ps -ef |grep X|xinit" shows that X and xinit are up and running. If we boot Machine A while the KVM is pointing to it, the displays come up with no issues.

We have KMS parameters set to force the output of the video (video=DP-1:2560x1600D and video=DP-2:2560x1600D) as well as options to load the EDID information. These parameters have worked in the past for us when we used DVI connections through KVMs, but DisplayPort is not showing the same results. Note that we have additional kernel options added for extra debug information (log_buf_len=8M nouveau.debug=disp=trace,i2c=trace,bios=trace)

Using Xrandr and Udev rules with a script allow us to turn off and then back on the displays automatically, allowing us a workaround, but it still does not solve the core issue of that nouveau is not waking up the monitors.

Please see the attached logs/config files and diagram below for more information.

|Machine A| |Machine B|
\               /
 \             /
  \ _________ /
   |DPort KVM|
   |_________|
   /         \
  /           \
 /             \
|Monitor 2| |Monitor 1|
Comment 1 dhruv.a.thakkar 2017-06-22 16:37:34 UTC
Created attachment 132143 [details]
/var/log/messages
Comment 2 dhruv.a.thakkar 2017-06-22 16:38:24 UTC
Created attachment 132144 [details]
xorg.conf for nouveau driver
Comment 3 Ilia Mirkin 2017-06-22 16:46:35 UTC
You appear to be using a 3.10 kernel. This was released in June 2013. Nouveau has been rewritten ~3 times by now. Can you try more recent software?

Better DP link training logic is one of the things that has had a lot of revisions to it.

Separately, you appear to want to use the card in Zaphod mode, but you haven't explicitly enabled it... no clue what happens when you do it that way.
Comment 4 dhruv.a.thakkar 2017-06-22 17:39:28 UTC
Thanks for your response Ilia. 

I'm slightly confused by your comment. Currently, we are using Redhat 7.3 with kernal version 3.10.0-514, which is the latest version available as shown here: https://access.redhat.com/articles/3078

Nouveau's website indicates that the latest linux kernal available is 4.11.6. 

I'm confused by this discrepancy, but I believe I'm misunderstanding something. Could you clarify a bit more?

Dhruv
Comment 5 Ilia Mirkin 2017-06-22 17:42:34 UTC
(In reply to dhruv.a.thakkar from comment #4)
> I'm slightly confused by your comment. Currently, we are using Redhat 7.3
> with kernal version 3.10.0-514, which is the latest version available as
> shown here: https://access.redhat.com/articles/3078

This isn't the RH support forum. This is upstream. http://www.kernel.org/ has the relevant info of what the current kernel releases are.

Kernel 3.10 was released in 2013. Then someone at RH has been cherry-picking "important" fixes for the past 4 years. The idea of such stable branches is "if it worked before, it'll keep working". However for you, it didn't work "before".
Comment 6 Martin Peres 2019-12-04 09:29:20 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/xorg/driver/xf86-video-nouveau/issues/356.


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.