Bug 110954

Summary: USB Type-C monitor flashes once when play a video file after unplug and re-plug the monitor
Product: DRI Reporter: Chintan Patel <chintan.m.patel>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: RESOLVED MOVED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: intel-gfx-bugs, nathan.d.ciobanu
Version: DRI git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard: ReadyForDev, Triaged
i915 platform: CFL, KBL i915 features: display/Other
Attachments:
Description Flags
dmesg logs on Chromebook with drm-tip logs enabled with 0x1e
none
dmesg logs on Chrome OS Kernel
none
Exact dmesg logs when flash happens after connecting monitor
none
dmesg marked with "play audio and flash"
none
for comment #10
none
video file used to reproduce the bug
none
attachment-15818-0.html none

Description Chintan Patel 2019-06-21 16:26:55 UTC
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.
Comment 1 Chintan Patel 2019-06-21 16:30:04 UTC
Created attachment 144605 [details]
dmesg logs on Chrome OS Kernel
Comment 2 Chintan Patel 2019-06-21 22:59:09 UTC
Created attachment 144607 [details]
Exact dmesg logs when flash happens after connecting monitor
Comment 3 Lakshmi 2019-06-26 09:09:29 UTC
(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?
Comment 4 Nathan Ciobanu 2019-06-26 20:48:23 UTC
(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.
Comment 5 Lakshmi 2019-07-17 07:52:47 UTC
Considering the issue happens only in a specific scenario and to a particular Solomon dock(90% repro), setting the priority to Medium.
Comment 6 Nathan Ciobanu 2019-08-08 15:47:45 UTC
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.
Comment 7 Jani Nikula 2019-08-09 10:58:57 UTC
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"
Comment 8 Stanislav Lisovskiy 2019-08-16 08:46:43 UTC
Does it also flash, if you play video with sound device being disabled?
Comment 9 Nathan Ciobanu 2019-08-16 22:34:48 UTC
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.
Comment 10 Nathan Ciobanu 2019-08-16 22:54:36 UTC
(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]
Comment 11 Nathan Ciobanu 2019-08-16 22:55:48 UTC
Created attachment 145082 [details]
for comment #10

This is the log I referred to in comment 10 where audio is disabled.
Comment 12 Stanislav Lisovskiy 2019-08-19 13:25:33 UTC
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?
Comment 13 Nathan Ciobanu 2019-08-19 16:29:15 UTC
(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.
Comment 14 Nathan Ciobanu 2019-08-19 16:47:01 UTC
Created attachment 145102 [details]
video file used to reproduce the bug
Comment 15 Stanislav Lisovskiy 2019-08-20 10:02:48 UTC
(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?
Comment 16 Nathan Ciobanu 2019-08-20 19:51:10 UTC
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.
Comment 17 Stanislav Lisovskiy 2019-08-21 08:26:34 UTC
(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.
Comment 18 Nathan Ciobanu 2019-08-23 17:32:27 UTC
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.
Comment 19 Chintan Patel 2019-08-23 17:32:36 UTC
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
Comment 20 Stanislav Lisovskiy 2019-08-26 09:33:04 UTC
(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.
Comment 21 Nathan Ciobanu 2019-09-15 03:02:07 UTC
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.
Comment 22 Martin Peres 2019-11-29 19:15:08 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/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.