| Summary: | Problems with (tiled) MST display (Dell UP3214Q) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Paul Menzel <pmenzel+bugs.freedesktop.org> | ||||||||
| Component: | DRM/Intel | Assignee: | Stanislav Lisovskiy <stanislav.lisovskiy> | ||||||||
| Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | medium | CC: | intel-gfx-bugs, pmenzel+bugs.freedesktop.org, stanislav.lisovskiy | ||||||||
| Version: | DRI git | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | Triaged, ReadyForDev | ||||||||||
| i915 platform: | SKL | i915 features: | display/DP MST | ||||||||
| Attachments: |
|
||||||||||
Paul, we recommend to create a separate bug for each individual issue. Also, Please try to reproduce the error using latest drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot for each case. (In reply to Lakshmi from comment #1) > Paul, we recommend to create a separate bug for each individual issue. I can do that, but I believe they all have the same cause. > Also, Please try to reproduce the error using latest drm-tip > (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e > log_buf_len=4M, and if the problem persists attach the full dmesg from boot > for each case. Unfortunately, I cannot do that in this environment in reasonable time. What is the difference between 0x1e and 0xe, which I attached. Which desktop manager/X Server version is used here? Lakshmi, it looks like this is something different, most likely those are multiple bugs. Problem is that I've already seen that this kind of behavior can be introduced from userspace( I mean DDX, X Server and/or desktop manager), which doesn't properly react to hotplug events and/or doesn't choose a correct modesetting. At least this was a case with fdo #106250. I would suggest to try some recent Linux distribution with the same kernel to see if the problem is still there. Created attachment 141501 [details] Linux 4.19-rc2+ (drm-tip) messages (In reply to Stanislav Lisovskiy from comment #3) > Which desktop manager/X Server version is used here? Xfce 4.13 and X.Org X Server 1.19.6. > Lakshmi, it looks like this is something different, most likely those are > multiple bugs. Agreed. Unfortunately, there is also an issue with the graphics driver in the UEFI firmware, that it often is not able to initialize the display. So Linux’ UEFI frame buffer driver doesn’t display anything. So, let’s make the bug about the issue, that the Linux kernel (not user space) Intel graphics driver i915 is not able to initialize the display when loaded. I jumped through the hoops to build latest drm-tip. Please find the log with `drm.debug=0x1e` attached. Hopefully, the logs are useful, so that we do not have to guess, what’s going wrong. The messages below jump out, though that is already quite a while after the i915 is executed. ``` [ 16.753610] [drm:intel_pch_type [i915]] Found SunrisePoint PCH […] [ 43.195398] [drm:gen8_de_irq_handler [i915]] hotplug event received, stat 0x00800000, dig 0x10121010, pins 0x00000080, long 0x00000080 [ 43.195407] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long [ 43.195414] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0 [ 43.195459] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long [ 43.195492] [drm:i915_hotplug_work_func [i915]] running encoder hotplug functions [ 43.195505] [drm:i915_hotplug_work_func [i915]] Connector DP-2 (pin 7) received hotplug event. [ 43.195516] [drm:intel_dp_detect [i915]] [CONNECTOR:86:DP-2] [ 43.195561] [drm:intel_dp_detect [i915]] MST device may have disappeared 1 vs 1 [ 43.203953] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.212342] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.220730] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.229117] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.237505] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.245893] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.254281] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.262668] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.271056] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.279444] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.287831] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.296219] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.304607] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.312994] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.321382] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.329770] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.338157] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.346545] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.354932] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.363320] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.371707] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.380095] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.388483] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.396872] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.405260] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.413649] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.422037] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.430424] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.438812] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.447199] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.455587] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.463975] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x7c2003ff [ 43.463979] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110 ``` Paul Menzel, does it help if you unplug and plug the display again, when you see those intel_dp_aux_xfer messages? (In reply to Stanislav Lisovskiy from comment #6) > Paul Menzel, does it help if you unplug and plug the display again, when you > see those intel_dp_aux_xfer messages? With GDM turning on the screen didn’t bring it back up, and the message below could be seen in the logs. [Tue Sep 18 09:40:10 2018] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Unplugging and plugging the display again fixed the issue. (In reply to Paul Menzel from comment #7) > (In reply to Stanislav Lisovskiy from comment #6) > > Paul Menzel, does it help if you unplug and plug the display again, when you > > see those intel_dp_aux_xfer messages? > > With GDM turning on the screen didn’t bring it back up, and the message > below could be seen in the logs. > > [Tue Sep 18 09:40:10 2018] [drm:intel_cpu_fifo_underrun_irq_handler > [i915]] *ERROR* CPU pipe B FIFO underrun > > Unplugging and plugging the display again fixed the issue. … of the black screen, but the two panels were not used on one monitor but as two. Paul, is this still present with current drm-tip? A bunch of DP MST and underrun fixes have been merged since. (In reply to Jani Nikula from comment #9) > Paul, is this still present with current drm-tip? A bunch of DP MST and > underrun fixes have been merged since. Yes, it is unfortunately still present with Linux 5.1. (In reply to Paul Menzel from comment #10) > (In reply to Jani Nikula from comment #9) > > Paul, is this still present with current drm-tip? A bunch of DP MST and > > underrun fixes have been merged since. > > Yes, it is unfortunately still present with Linux 5.1. Can you try one simple experiment - switch to text mode(either by killing desktop manager or by pressing ctrl-alt-f[123], adding 3 to kernel command line in grub). Then try to reproduce that issue - if it doesn't reproduce most likely this is userspace issue, which we dealt with previously and which is unfortunately still no fixed. (In reply to Stanislav Lisovskiy from comment #11) > Can you try one simple experiment - switch to text mode(either by killing > desktop manager or by pressing ctrl-alt-f[123], adding 3 to kernel command > line in grub). What do you mean by adding 3 to kernel command line (drm.debug)? (In reply to Paul Menzel from comment #12) > (In reply to Stanislav Lisovskiy from comment #11) > > > Can you try one simple experiment - switch to text mode(either by killing > > desktop manager or by pressing ctrl-alt-f[123], adding 3 to kernel command > > line in grub). > > What do you mean by adding 3 to kernel command line (drm.debug)? No, you just add digit 3 to the and of kernel command line in grub. Like if you had drm.debug=0x1e, it would look like "drm.debug=0x1e 3". This will make it boot to text mode without desktop manager and UI. So that if the issue happens here as well, we can at least exclude desktop manager issues. Paul, any updates here? Sorry, the problem is still there with Linux 5.2, and the text mode test was unsuccessful. Can you please attach the logs for text mode, when issue happens? I.e kernel command line should have this line: drm.debug=0x1e log_buf_len=10M 3 What I want to check is what is the connector state reported by kernel when the issue happens, also do get a mode set request from userspace(drm_mode_setcrtc) and other things. Created attachment 145990 [details]
Linux 5.4-rc8 messages (dmesg)
Please find the log messages attached.
-- 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/intel/issues/154. |
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.
Created attachment 141467 [details] Linux 4.18.6 messages Using the MST display Dell UP3214Q connected over DisplayPort, there are several problems, which are happening since at least 4.14 and are still present with Linux 4.18.6. 1. Restarting the system and leaving the monitor on, neither the Fujitsu firmware nor Linux is able to display something. (This happens rarely.) 2. Turning the monitor off and back on, sometimes the monitor does not detect a signal, and only after waiting a while and pressing keys, or turning it off and back on several times, a connection is established and an image displayed (which might have the problems below though). 3. The panel order is sometimes switched (LR becomes RL, where X and Y are panels). 4. The X server shows each panel as one screen, and does not overlap them. 5. Instead of one full screen of 3840x2160, only one screen 1920x2160 seems to be detected and stretched over the whole display. The device below is used. 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) Please find the debug log attached. In this time the aforementioned problems happened.