Created attachment 144604 [details] dmesg logs on Chromebook with drm-tip logs enabled with 0x1e Steps to reproduce this issue: 1. Boot chromebook/Ubuntu 16.04 to OS. 2. Connect type-c cable to laptop. 3. Plug DP to MST Display 4. Switch sound output to speaker. 5. Play a local video or music (not suggested Youtube). OR "speaker_test" from command line 6. Close the player. 7. Unplug type-c cable then plug cable in about 5~10s. 8. Play a local video or music again. 9. MST monitor will flash once when playing multimedia. <------issue Steps to reproduce on Ubuntu 16.04 OS: 1. Boot Ubuntu OS 2. Connect Display with Solomon Dock 3. Make sure to select HDMI from audio settings ==> Check if issue happens?? 4. Play video ==> Check if issue happens?? Issue happens on KBL/WHL as well as with SST monitor, although reproduction rate is low. High reproduction rate(90%) if done using S2718D and Solomon dock. Issue happens with drm-tip SH1 034e3ac6a2d1 also. Attaching the logs with Chrome OS Kernel as well as with drm-tip.
Created attachment 144605 [details] dmesg logs on Chrome OS Kernel
Created attachment 144607 [details] Exact dmesg logs when flash happens after connecting monitor
(In reply to Chintan Patel from comment #0) > Created attachment 144604 [details] > dmesg logs on Chromebook with drm-tip logs enabled with 0x1e > > Steps to reproduce this issue: > 1. Boot chromebook/Ubuntu 16.04 to OS. > 2. Connect type-c cable to laptop. > 3. Plug DP to MST Display > 4. Switch sound output to speaker. > 5. Play a local video or music (not suggested Youtube). OR "speaker_test" > from command line > 6. Close the player. > 7. Unplug type-c cable then plug cable in about 5~10s. > 8. Play a local video or music again. > 9. MST monitor will flash once when playing multimedia. <------issue > After step 9, is audio working as expected? only issue is monitoring flashing?
(In reply to Lakshmi from comment #3) > (In reply to Chintan Patel from comment #0) > > Created attachment 144604 [details] > > dmesg logs on Chromebook with drm-tip logs enabled with 0x1e > > > > Steps to reproduce this issue: > > 1. Boot chromebook/Ubuntu 16.04 to OS. > > 2. Connect type-c cable to laptop. > > 3. Plug DP to MST Display > > 4. Switch sound output to speaker. > > 5. Play a local video or music (not suggested Youtube). OR "speaker_test" > > from command line > > 6. Close the player. > > 7. Unplug type-c cable then plug cable in about 5~10s. > > 8. Play a local video or music again. > > 9. MST monitor will flash once when playing multimedia. <------issue > > > After step 9, is audio working as expected? only issue is monitoring > flashing? Yes audio recovers after the flash and works fine.
Considering the issue happens only in a specific scenario and to a particular Solomon dock(90% repro), setting the priority to Medium.
This bug can also be reproduced with two daisy-chained monitors (DP MST). It is harder but the bug is there even without the Dell dock. I hope this helps setting the priority higher than Medium.
Please indicate precisely in the dmesg where the flashing occurs. It's not obvious. You can even log it yourself in the dmesg, using for example: $ sudo bash -c "echo play audio > /dev/kmsg" and $ sudo bash -c "echo end audio > /dev/kmsg"
Does it also flash, if you play video with sound device being disabled?
Created attachment 145081 [details] dmesg marked with "play audio and flash" I took another log on a Chromebook with drm-tip and drm.debug=0xe. I also marked the spot where I start playing the video with "play audio and flash". You'll then see the spurious which get printed during the video playback. [drm:skl_update_scaler] scaler_user index 0.0: staged scaling request for 1920x1080->1724x970 scaler_users = 0x1 [drm:intel_atomic_setup_scalers] Attached scaler id 0.0 to PLANE:31" It is during the video playback time that the flash occurs. The one interesting thing I found is that we restart probing for connectors at this point: [ 3980.917229] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] which is triggered by an ioctl call from user space. For some reason the userspace needs to reprobe and I'm not sure what causes this. Another finding from my previous investigation was that if you wait for the this reprobing to finish and then play the video the flash will not occur.
(In reply to Stanislav Lisovskiy from comment #8) > Does it also flash, if you play video with sound device being disabled? No if I blacklist snd_hda_intel module to disable audio the bug is not reproducible. The reprobe is still there though, but without audio there is no flash. [ 718.086179] [drm:edp_panel_vdd_off_sync] Turning eDP port A VDD off [ 718.086313] [drm:edp_panel_vdd_off_sync] PP_STATUS: 0x80000008 PP_CONTROL: 0x00000067 [ 725.108202] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1]
Created attachment 145082 [details] for comment #10 This is the log I referred to in comment 10 where audio is disabled.
What do you mean by "that if you wait for the this reprobing to finish and then play the video the flash will not occur"? So it does not happen once you start playback, but at some point before this?
(In reply to Stanislav Lisovskiy from comment #12) > What do you mean by "that if you wait for the this reprobing to finish and > then play the video the flash will not occur"? > > So it does not happen once you start playback, but at some point before this? The flash happens if you play the video (with audio) before the reprobe, If you play the video after reprobe it doesn't occur.
Created attachment 145102 [details] video file used to reproduce the bug
(In reply to Nathan Ciobanu from comment #13) > (In reply to Stanislav Lisovskiy from comment #12) > > What do you mean by "that if you wait for the this reprobing to finish and > > then play the video the flash will not occur"? > > > > So it does not happen once you start playback, but at some point before this? > > The flash happens if you play the video (with audio) before the reprobe, If > you play the video after reprobe it doesn't occur. But when does reprobe occur? Does it occur on its own or after you replug it or some other action?
On Tue, Aug 20, 2019 at 10:02:48AM +0000, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=110954 > > --- Comment #15 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> --- > (In reply to Nathan Ciobanu from comment #13) > > (In reply to Stanislav Lisovskiy from comment #12) > > > What do you mean by "that if you wait for the this reprobing to finish and > > > then play the video the flash will not occur"? > > > > > > So it does not happen once you start playback, but at some point before this? > > > > The flash happens if you play the video (with audio) before the reprobe, If > > you play the video after reprobe it doesn't occur. > > But when does reprobe occur? Does it occur on its own or after you replug it or > some other action? It always occurs regardless of my actions. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
(In reply to Nathan Ciobanu from comment #16) > On Tue, Aug 20, 2019 at 10:02:48AM +0000, bugzilla-daemon@freedesktop.org > wrote: > > https://bugs.freedesktop.org/show_bug.cgi?id=110954 > > > > --- Comment #15 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> --- > > (In reply to Nathan Ciobanu from comment #13) > > > (In reply to Stanislav Lisovskiy from comment #12) > > > > What do you mean by "that if you wait for the this reprobing to finish and > > > > then play the video the flash will not occur"? > > > > > > > > So it does not happen once you start playback, but at some point before this? > > > > > > The flash happens if you play the video (with audio) before the reprobe, If > > > you play the video after reprobe it doesn't occur. > > > > But when does reprobe occur? Does it occur on its own or after you replug it or > > some other action? > It always occurs regardless of my actions. That is weird then. It should occur only once you do hotplug/change display configuration. It should not happen on its own, probably that might be origin of this issue. > > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug.
On Wed, Aug 21, 2019 at 08:26:34AM +0000, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=110954 > > --- Comment #17 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> --- > (In reply to Nathan Ciobanu from comment #16) > > On Tue, Aug 20, 2019 at 10:02:48AM +0000, bugzilla-daemon@freedesktop.org > > wrote: > > > https://bugs.freedesktop.org/show_bug.cgi?id=110954 > > > > > > --- Comment #15 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> --- > > > (In reply to Nathan Ciobanu from comment #13) > > > > (In reply to Stanislav Lisovskiy from comment #12) > > > > > What do you mean by "that if you wait for the this reprobing to finish and > > > > > then play the video the flash will not occur"? > > > > > > > > > > So it does not happen once you start playback, but at some point before this? > > > > > > > > The flash happens if you play the video (with audio) before the reprobe, If > > > > you play the video after reprobe it doesn't occur. > > > > > > But when does reprobe occur? Does it occur on its own or after you replug it or > > > some other action? > > It always occurs regardless of my actions. > > That is weird then. It should occur only once you do hotplug/change display > configuration. It should not happen on its own, probably that might be origin > of this issue. That is my suspicion as well. I don't know how hda behaves in MST situations but maybe it isn't "ready" right away when the displays finish training but may become "ready" a few seconds later and thus trigger a reprobe. To prove this which register do I need to print? Thanks, Nathan > > > > > > > > > -- > > > You are receiving this mail because: > > > You are on the CC list for the bug. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Created attachment 145147 [details] attachment-15818-0.html I will be OOO on Oct 05 and Oct 08. Please expect dealy in email responses. Thanks, Chintan
(In reply to Nathan Ciobanu from comment #18) > On Wed, Aug 21, 2019 at 08:26:34AM +0000, bugzilla-daemon@freedesktop.org > wrote: > > https://bugs.freedesktop.org/show_bug.cgi?id=110954 > > > > --- Comment #17 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> --- > > (In reply to Nathan Ciobanu from comment #16) > > > On Tue, Aug 20, 2019 at 10:02:48AM +0000, bugzilla-daemon@freedesktop.org > > > wrote: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=110954 > > > > > > > > --- Comment #15 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> --- > > > > (In reply to Nathan Ciobanu from comment #13) > > > > > (In reply to Stanislav Lisovskiy from comment #12) > > > > > > What do you mean by "that if you wait for the this reprobing to finish and > > > > > > then play the video the flash will not occur"? > > > > > > > > > > > > So it does not happen once you start playback, but at some point before this? > > > > > > > > > > The flash happens if you play the video (with audio) before the reprobe, If > > > > > you play the video after reprobe it doesn't occur. > > > > > > > > But when does reprobe occur? Does it occur on its own or after you replug it or > > > > some other action? > > > It always occurs regardless of my actions. > > > > That is weird then. It should occur only once you do hotplug/change display > > configuration. It should not happen on its own, probably that might be origin > > of this issue. > That is my suspicion as well. I don't know how hda behaves in MST situations > but maybe it isn't "ready" right away when the displays finish training but > may become "ready" a few seconds later and thus trigger a reprobe. To prove > this which register do I need to print? > > Thanks, > Nathan > > > > > > > > > > > > > -- > > > > You are receiving this mail because: > > > > You are on the CC list for the bug. > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug. The dmesg log looks flooded with hpd irq events like this "gen8_de_irq_handler] hotplug event received, stat 0x00400000, dig 0x10101110, pins 0x00000040, long 0x00000000", I don't think this is even related to hda, most likely there is some issue with DP MST itself. The flash probably just happens as a result of constant reprobing and simultaneous modeset. Userspace starts reprobing after it gets uevent sent by the driver in response to hpd irq.
On Mon, Aug 26, 2019 at 09:33:04AM +0000, bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=110954 > > --- Comment #20 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> --- > (In reply to Nathan Ciobanu from comment #18) > > On Wed, Aug 21, 2019 at 08:26:34AM +0000, bugzilla-daemon@freedesktop.org > > wrote: > > > https://bugs.freedesktop.org/show_bug.cgi?id=110954 > > > > > > --- Comment #17 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> --- > > > (In reply to Nathan Ciobanu from comment #16) > > > > On Tue, Aug 20, 2019 at 10:02:48AM +0000, bugzilla-daemon@freedesktop.org > > > > wrote: > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=110954 > > > > > > > > > > --- Comment #15 from Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> --- > > > > > (In reply to Nathan Ciobanu from comment #13) > > > > > > (In reply to Stanislav Lisovskiy from comment #12) > > > > > > > What do you mean by "that if you wait for the this reprobing to finish and > > > > > > > then play the video the flash will not occur"? > > > > > > > > > > > > > > So it does not happen once you start playback, but at some point before this? > > > > > > > > > > > > The flash happens if you play the video (with audio) before the reprobe, If > > > > > > you play the video after reprobe it doesn't occur. > > > > > > > > > > But when does reprobe occur? Does it occur on its own or after you replug it or > > > > > some other action? > > > > It always occurs regardless of my actions. > > > > > > That is weird then. It should occur only once you do hotplug/change display > > > configuration. It should not happen on its own, probably that might be origin > > > of this issue. > > That is my suspicion as well. I don't know how hda behaves in MST situations > > but maybe it isn't "ready" right away when the displays finish training but > > may become "ready" a few seconds later and thus trigger a reprobe. To prove > > this which register do I need to print? > > > > Thanks, > > Nathan > > > > > > > > > > > > > > > > > -- > > > > > You are receiving this mail because: > > > > > You are on the CC list for the bug. > > > > > > -- > > > You are receiving this mail because: > > > You are on the CC list for the bug. > > The dmesg log looks flooded with hpd irq events like this "gen8_de_irq_handler] > hotplug event received, stat 0x00400000, dig 0x10101110, pins 0x00000040, long > 0x00000000", I don't think this is even related to hda, most likely there is > some issue with DP MST itself. The flash probably just happens as a result of > constant reprobing and simultaneous modeset. > Userspace starts reprobing after it gets uevent sent by the driver in response > to hpd irq. Does this point to the dock as a possible soure of the hpd interrupts? Do you think the dock may have an issue? Any register we can dump to prove this? Thanks, Nathan > > -- > You are receiving this mail because: > You are on the CC list for the bug.
-- 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/318.
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.