USB Type-C monitor flashes once when play a video file after unplug and re-plug the monitor

added Community Needs Information feature: display/Other platform: CFL platform: KBL priority::medium severity::normal + 1 deleted label

📎 Chintan Patel uploaded an attachment:

Attachment 144605, "dmesg logs on Chrome OS Kernel":
dmesg_1f_flash_happens_chromeos.txt

📎 Chintan Patel uploaded an attachment:

Attachment 144607, "Exact dmesg logs when flash happens after connecting monitor":
dmesg_drm-tip-flash_happens_trimmed.txt

💬 LAKSHMINARAYANA VUDUM @l4kshmi said:

(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:

Boot chromebook/Ubuntu 16.04 to OS.

Connect type-c cable to laptop.

Plug DP to MST Display

Switch sound output to speaker.

Play a local video or music (not suggested Youtube). OR "speaker_test"
from command line

Close the player.

Unplug type-c cable then plug cable in about 5~10s.

Play a local video or music again.

MST monitor will flash once when playing multimedia. <------issue

After step 9, is audio working as expected? only issue is monitoring flashing?

💬 Nathan Ciobanu said:

(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:

Boot chromebook/Ubuntu 16.04 to OS.

Connect type-c cable to laptop.

Plug DP to MST Display

Switch sound output to speaker.

Play a local video or music (not suggested Youtube). OR "speaker_test"
from command line

Close the player.

Unplug type-c cable then plug cable in about 5~10s.

Play a local video or music again.

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.

💬 LAKSHMINARAYANA VUDUM @l4kshmi said:

Considering the issue happens only in a specific scenario and to a particular Solomon dock(90% repro), setting the priority to Medium.

💬 Nathan Ciobanu said:

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.

💬 Jani Nikula @jani said:

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"

💬 Stanislav Lisovskiy said:

Does it also flash, if you play video with sound device being disabled?

📎 Nathan Ciobanu uploaded an attachment:

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.

Attachment 145081, "dmesg marked with "play audio and flash"":
marked_dmesg.log

💬 Nathan Ciobanu said:

(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]

📎 Nathan Ciobanu uploaded an attachment:

This is the log I referred to in comment 10 where audio is disabled.

Attachment 145082, "for comment #10 (closed)":
dmesg_no_audio.log

💬 Stanislav Lisovskiy said:

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?

💬 Nathan Ciobanu said:

(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.

📎 Nathan Ciobanu uploaded an attachment:

Attachment 145102, "video file used to reproduce the bug":
GTA_5_FAILS__EP.35__GTA_5_Funny_Moments_Compilation_-YouTube__1080p

💬 Stanislav Lisovskiy said:

(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?

💬 Nathan Ciobanu said:

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.

💬 Stanislav Lisovskiy said:

(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.

💬 Nathan Ciobanu said:

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.

📎 Chintan Patel uploaded an attachment:

I will be OOO on Oct 05 and Oct 08. Please expect dealy in email responses.

Thanks,
Chintan

Attachment 145147, "attachment-15818-0.html":
attachment-15818-0.html

💬 Stanislav Lisovskiy said:

(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.

💬 Nathan Ciobanu said:

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.

flash_once.diff

We have finding as attached patch for reference. Add 40ms delay after set cvt_nid power state in function haswell_verify_D0 issue seems been fixed Verify PASS 20 iterations with S2718D and Solomon dock.(platfomr:WHL, CML) Not sure if it's good solution. May need expert to help to review.

Reporter, Can you verify with the patch provided by Cheng and and check with latest drm-tip and respond accordingly?

HI reporter, As there is no response since a month assuming that issue is not seen with latest drm-tip,closing the issue.If issue still exists,please reopen the same.

closed

This issue is still reproducible on drm-tip (03/09/2020).

reopened

Please find attached the latest logs with drm-tipdmesg_reproduce_monitor_flash.zip

@skarana1, is there any status update on this bug? is anyone actively working on it? thanks

Hi reporter, are you still seeing the issue? As per the latest comments issue seems to be existing.

please confirm if this issue is still seen on latest kernel also.

If yes, provide the steps to reproduce it for further debugging.

@ysainan, the steps for reproducing this issues are still the same as listed above.As far as i know, this issue is still unresolved.

assigned to @tejaskux

unassigned @tejaskux

Hi @gdsworo, Can you provide some detail on MST Display(Model/Product discerption) and Solomon Dock(Model/Product discerption)

Closing #318 (closed) since there is no activity for 1 year. Please re-open this bug, if issue is still seen on latest drmtip.

closed

USB Type-C monitor flashes once when play a video file after unplug and re-plug the monitor

Submitted by Chintan Patel

Description

Child items 0

Activity

Admin message

Admin message

USB Type-C monitor flashes once when play a video file after unplug and re-plug the monitor

Submitted by Chintan Patel

Description

Activity