Ubuntu
linux package

[X1 Carbon 7, i915, HDMI] Ultra-wide monitor recognized properly when plugged in only intermittently [Xorg only]

Bug #1849484 reported by Jonathan Kamens
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linux
Unknown
Medium
linux (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

I have an LG ultra-wide (2560x1080) monitor.

Sometimes when I plug it into my laptop, whose screen was working fine before I plugged it in, both screens go black but nothing else happens. I can still see the mouse cursor and move it between the two monitors (sometimes in the correct location configuration I've configured, sometimes not), but nothing is rendered on the screens.

Sometimes when I plug the monitor in, it comes on, but the resolution is wrong.

Sometimes it is actually recognized and configured correctly.

Frequently I have to unplug the monitor and plug it back in three times or more before it is recognized correctly.

I wish it just worked right the first time. :-/

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: gnome-shell 3.34.1-1ubuntu1
ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
Uname: Linux 5.3.0-19-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu8
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Oct 23 08:34:07 2019
DisplayManager: gdm3
InstallationDate: Installed on 2019-09-12 (40 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to eoan on 2019-09-20 (32 days ago)
---
ProblemType: Bug
.tmp.unity_support_test.0:

ApportVersion: 2.20.11-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: jik 3196 F.... pulseaudio
 /dev/snd/pcmC1D0p: jik 3196 F...m pulseaudio
 /dev/snd/controlC0: jik 3196 F.... pulseaudio
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
DistUpgraded: 2019-09-20 10:09:14,777 DEBUG Running PostInstallScript: './xorg_fix_proprietary.py'
DistroCodename: eoan
DistroRelease: Ubuntu 19.10
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Intel Corporation UHD Graphics 620 (Whiskey Lake) [8086:3ea0] (rev 02) (prog-if 00 [VGA controller])
   Subsystem: Lenovo UHD Graphics 620 (Whiskey Lake) [17aa:2292]
InstallationDate: Installed on 2019-09-12 (45 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
MachineType: LENOVO 20QD001VUS
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
Package: xorg-server (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-19-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
RelatedPackageVersions:
 linux-restricted-modules-5.3.0-19-generic N/A
 linux-backports-modules-5.3.0-19-generic N/A
 linux-firmware 1.183.1
Tags: eoan ubuntu
Uname: Linux 5.3.0-19-generic x86_64
UpgradeStatus: Upgraded to eoan on 2019-09-20 (38 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo vboxusers wireshark
_MarkForUpload: True
dmi.bios.date: 07/04/2019
dmi.bios.vendor: LENOVO
dmi.bios.version: N2HET30W (1.13 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20QD001VUS
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrN2HET30W(1.13):bd07/04/2019:svnLENOVO:pn20QD001VUS:pvrThinkPadX1Carbon7th:rvnLENOVO:rn20QD001VUS:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad X1 Carbon 7th
dmi.product.name: 20QD001VUS
dmi.product.sku: LENOVO_MT_20QD_BU_Think_FM_ThinkPad X1 Carbon 7th
dmi.product.version: ThinkPad X1 Carbon 7th
dmi.sys.vendor: LENOVO
modified.conffile..etc.apport.crashdb.conf: [modified]
mtime.conffile..etc.apport.crashdb.conf: 2019-10-23T16:51:18.143596
version.compiz: compiz 1:0.9.14.0+19.10.20190918-0ubuntu1
version.libdrm2: libdrm2 2.4.99-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.1-1ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.1-1ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.20.5+git20191008-0ubuntu1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.0.1-1ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20190815-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1

See original description
Revision history for this message
In , Maks (kolmax94) wrote :

Created attachment 138193
/sys/kernel/debug/dri/0/i915_display_info

I have Lenovo X1 Carbon laptop from 2014 with the following CPU:

Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz

lspci reports GPU as

VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)

I'm on Gentoo Linux with kernel 4.15.9-gentoo, xorg-server 1.19.5, libdrm 2.4.91 and mesa 18.0.0_rc4. I'm using modesetting driver without xf86-video-intel.

As my laptop has only mini displayport output, I'm trying to use DP-to-HDMI/VGA/DVI converter I got from AliExpress. Sometimes when I plug in the converter and enable the monitor with xrandr it works fine, but most of the time I see the output in xrandr, but when I enable it, monitor does not show anything.

I have this in dmesg:

[15:47] i915 0000:00:02.0: HDMI-A-1: EDID is invalid:
[ +0,000004] [00] BAD 00 ff ff ff ff ff ff 00 09 d1 bd 78 45 54 00 00
[ +0,000001] [00] BAD 0b 17 01 03 80 30 1b 78 2e 9a d5 a3 59 55 9f 27
[ +0,000001] [00] BAD 0c 50 54 21 08 00 61 c0 81 00 81 c0 81 40 81 80
[ +0,000001] [00] BAD a9 c0 b3 00 d1 c0 02 3a 80 18 71 38 2d 40 58 2c
[ +0,000001] [00] BAD 45 00 dd 0c 11 00 00 1e 00 00 00 ff 00 53 33 44
[ +0,000001] [00] BAD 30 35 38 34 30 53 4c 30 0a 20 00 00 00 fd 00 32
[ +0,000001] [00] BAD 4c 1e 53 11 00 0a 20 20 20 20 20 20 00 01 ff ff
[ +0,000001] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ +0,108525] i2c i2c-4: sendbytes: NAK bailout.
[ +9,914962] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode adaptor ID 44
[ +0,261571] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode adaptor ID 44

I googled and found bug 92685 and tried kernel patch from there (https://patchwork.freedesktop.org/patch/195306/), but it did not change anything for me.

Attaching i915_display_info and full dmesg, but without drm.debug=0xe yet.

Revision history for this message
In , Maks (kolmax94) wrote :

Created attachment 138194
dmesg

Revision history for this message
In , Ville-syrjala-e (ville-syrjala-e) wrote :

(In reply to Maxim from comment #0)
> Created attachment 138193 [details]
> /sys/kernel/debug/dri/0/i915_display_info
>
> I have Lenovo X1 Carbon laptop from 2014 with the following CPU:
>
> Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz

I have a similar carbon and no real issues with any DP++ dongle I've tested.

> [15:47] i915 0000:00:02.0: HDMI-A-1: EDID is invalid:
> [ +0,000004] [00] BAD 00 ff ff ff ff ff ff 00 09 d1 bd 78 45 54 00 00
> [ +0,000001] [00] BAD 0b 17 01 03 80 30 1b 78 2e 9a d5 a3 59 55 9f 27
> [ +0,000001] [00] BAD 0c 50 54 21 08 00 61 c0 81 00 81 c0 81 40 81 80
> [ +0,000001] [00] BAD a9 c0 b3 00 d1 c0 02 3a 80 18 71 38 2d 40 58 2c
> [ +0,000001] [00] BAD 45 00 dd 0c 11 00 00 1e 00 00 00 ff 00 53 33 44
> [ +0,000001] [00] BAD 30 35 38 34 30 53 4c 30 0a 20 00 00 00 fd 00 32
> [ +0,000001] [00] BAD 4c 1e 53 11 00 0a 20 20 20 20 20 20 00 01 ff ff
> [ +0,000001] [00] BAD ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ +0,108525] i2c i2c-4: sendbytes: NAK bailout.

So it failed even with bit banging :(

> [ +9,914962] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode
> adaptor ID 44
> [ +0,261571] [drm:drm_dp_dual_mode_detect] *ERROR* Unexpected DP dual mode
> adaptor ID 44

And the dongle itself is returning garbage when we try to access its registers, so the problem is not limited to the ddc passthrough.

One thing you may want to try is slow down the i2c bus further. We use 100kHz by default, and you may want to try something like 10kHz instead.

--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -127,7 +127,7 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,

 /* Intel GPIO access functions */

-#define I2C_RISEFALL_TIME 10
+#define I2C_RISEFALL_TIME 100

Revision history for this message
In , Maks (kolmax94) wrote :

Created attachment 138229
dmesg with 10kHz patch

Hi. I tried the patch you gave me and it seems to work, but I can't be sure yet.

I tried disconnecting adapter from laptop and HDMI from adapter in different orders and each time I'm able to enable HDMI output to my TV. I'll check this with the monitor at my work on the next week.

I've also enabled drm.debug=0xe and noticed some errors and timeouts in dmesg. Attaching it just in case.

Revision history for this message
In , Maks (kolmax94) wrote :

Hi again. Unfortunately, I still have issues with this. I have image on the monitor, but it goes black every couple of seconds or so for a second, thus impossible to work with. I have such lines in dmesg:

[266394.619490] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.622024] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.624561] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.627101] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.629638] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.632165] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.634703] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.637240] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[266394.637254] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110
[266394.637266] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:72:DP-1] disconnected

Can this be fixed or this adapter is impossible to work with?

Revision history for this message
In , Ville-syrjala-e (ville-syrjala-e) wrote :

(In reply to Maxim from comment #4)
> Hi again. Unfortunately, I still have issues with this. I have image on the
> monitor, but it goes black every couple of seconds or so for a second, thus
> impossible to work with. I have such lines in dmesg:
>
> [266394.619490] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.622024] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.624561] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.627101] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.629638] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.632165] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.634703] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.637240] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
> [266394.637254] [drm:drm_dp_dpcd_access] Too many retries, giving up. First
> error: -110
> [266394.637266] [drm:drm_helper_probe_single_connector_modes]
> [CONNECTOR:72:DP-1] disconnected

Those aren't directly related to the blinking. These are in fact normal messages one would expect during hotplug processing. However they may be a symptom of the dongle failing somehow and wiggling the hotplug line.

>
> Can this be fixed or this adapter is impossible to work with?

Can you do:

dmesg -C
wait until the display blink has happened a couple of times
dmesg

and attach the log from dmesg.

Revision history for this message
In , Jani-saarinen-g (jani-saarinen-g) wrote :

First of all. Sorry about spam.
This is mass update for our bugs.

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.

Revision history for this message
In , Maks (kolmax94) wrote :

Created attachment 138693
new dmesg

Sadly, the problem continues. I came to work once again and tried to connect my monitor, but this time it won't show the image at all. xrandr sees the monitor and can set mode, but nothing happens after it. Judging by dmesg, kernel recognizes monitor, as it prints its model. What can be wrong now? Attaching dmesg after reboot just in case.

Revision history for this message
In , Maks (kolmax94) wrote :

(In reply to Maxim from comment #7)
> Created attachment 138693 [details]
> new dmesg
>
> Sadly, the problem continues. I came to work once again and tried to connect
> my monitor, but this time it won't show the image at all. xrandr sees the
> monitor and can set mode, but nothing happens after it. Judging by dmesg,
> kernel recognizes monitor, as it prints its model. What can be wrong now?
> Attaching dmesg after reboot just in case.

Actually, ignore that. It seems that I forgot to switch input on monitor... Sorry :)

Revision history for this message
In , Jani-saarinen-g (jani-saarinen-g) wrote :

So solved or still issue?

Revision history for this message
In , Maks (kolmax94) wrote :

Created attachment 138723
dmesg after flicker

(In reply to Ville Syrjala from comment #5)
> Can you do:
>
> dmesg -C
> wait until the display blink has happened a couple of times
> dmesg
>
> and attach the log from dmesg.

Okay, so I did as you said. Here's dmesg right after display went black two times.

Revision history for this message
In , Ville-syrjala-e (ville-syrjala-e) wrote :

(In reply to Maxim from comment #10)
> Created attachment 138723 [details]
> dmesg after flicker
>
> (In reply to Ville Syrjala from comment #5)
> > Can you do:
> >
> > dmesg -C
> > wait until the display blink has happened a couple of times
> > dmesg
> >
> > and attach the log from dmesg.
>
> Okay, so I did as you said. Here's dmesg right after display went black two
> times.

Nothing particularly interesting in the log. There is a normal looking disable->do nothing for ~26 minutes->re-enable modeset sequence (presuambly the display was just blanked for that period of time?). Also a ton of some ASLE junk but presumably that should be harmless.

Given the evidence we have I'd lean towards the DP++ dongle simply being garbage.

Revision history for this message
In , Maks (kolmax94) wrote :

(In reply to Ville Syrjala from comment #11)
> (In reply to Maxim from comment #10)
>
> Nothing particularly interesting in the log. There is a normal looking
> disable->do nothing for ~26 minutes->re-enable modeset sequence (presuambly
> the display was just blanked for that period of time?). Also a ton of some
> ASLE junk but presumably that should be harmless.
>
> Given the evidence we have I'd lean towards the DP++ dongle simply being
> garbage.

Okay, I'm OK with that, as long as it works with 10kHz patch :) Are you going to commit it or at least make configurable?

Revision history for this message
In , Jani-saarinen-g (jani-saarinen-g) wrote :

Ville, what was next step, is this invalid issue?

Revision history for this message
In , Ville-syrjala-e (ville-syrjala-e) wrote :

(In reply to Maxim from comment #12)
> (In reply to Ville Syrjala from comment #11)
> > (In reply to Maxim from comment #10)
> >
> > Nothing particularly interesting in the log. There is a normal looking
> > disable->do nothing for ~26 minutes->re-enable modeset sequence (presuambly
> > the display was just blanked for that period of time?). Also a ton of some
> > ASLE junk but presumably that should be harmless.
> >
> > Given the evidence we have I'd lean towards the DP++ dongle simply being
> > garbage.
>
> Okay, I'm OK with that, as long as it works with 10kHz patch :) Are you
> going to commit it or at least make configurable?

We definitely don't want to put that patch in as is since it'll slow down things for everyone. Making it configurable is an option I suppose. Possibly a better option would be to introduce some kind of fallback mechanism where we try to reduce the i2c bus speed when encountering errors. We might want something like that for DDC/CI as well. Or at least I have one monitor here where the DDC/CI isn't happy with the 100KHz speed either.

Revision history for this message
In , Lakshminarayana-vudum (lakshminarayana-vudum) wrote :

Reducing the priority to low based on the impact and the workaround.

Revision history for this message
Jonathan Kamens (jik) wrote :
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Please try logging into both "Ubuntu" and "Ubuntu on Wayland". Do they both have the bug?

Please also plug the monitor in to reproduce the bug and then immediately run these commands and send us the resulting files:

  journalctl -b0 > journal.txt
  xrandr > xrandr.txt

Changed in gnome-shell (Ubuntu):
status: New → Incomplete
Revision history for this message
Jonathan Kamens (jik) wrote :

The problem does not appear to happen under Wayland.

I am attaching a zip file containing four sets of the output of the commands you requested spanning the time from before I plugged in the HDMI cable to afterward, waiting long enough to confirm that I was getting black screens rather than the correct behavior after plugging in the cable.

To minimize the content of the zip, I've edited the journal.txt files in all of the sets after the first to remove the logs that were in the previous journal.txt, so if you append all four journal.txt files you will get a complete, consecutive journal.

Changed in gnome-shell (Ubuntu):
status: Incomplete → New
Revision history for this message
Jonathan Kamens (jik) wrote :

OK, this is really weird, but it appears that this problem only happens (or, at the very least, happens much more frequently) when Synology Drive Client is running, or more accurately, when the Synology Drive Client applet is in my top bar.

Furthermore, sometimes (but not always) when I plug in my monitor and this problem occurs, Synology Drive Client applet process segfaults and exits, and then if I unplug the monitor and plug it back in again everything is fine.

Daniel van Vugt (vanvugt)
summary: - ultra-wide monitor recognized properly when plugged in only
- intermittently
+ Ultra-wide monitor recognized properly when plugged in only
+ intermittently [Xorg only]
affects: gnome-shell (Ubuntu) → xorg-server (Ubuntu)
Revision history for this message
Daniel van Vugt (vanvugt) wrote : Re: Ultra-wide monitor recognized properly when plugged in only intermittently [Xorg only]

It's interesting you say the problem does not happen in Wayland sessions.

Your logs suggest the kernel is having trouble, which then confuses Xorg:

Oct 23 08:32:51 jik-d42-x1 kernel: i915 0000:00:02.0: HDMI-A-1: EDID is invalid:
Oct 23 08:32:51 jik-d42-x1 kernel: [00] BAD 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58
...

and

Oct 23 08:32:52 jik-d42-x1 kernel: [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 54

The problem "EDID is invalid" means it is either a kernel bug, a faulty monitor or a faulty connection. Please try a different HDMI cable to see if that helps.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Also you have kernel errors happening immediately before errors from gnome-shell/mutter:

Oct 24 09:15:20 jik-d42-x1 kernel: [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
Oct 24 09:15:20 jik-d42-x1 gnome-shell[20744]: (../src/backends/meta-monitor.c:1543):meta_monitor_derive_current_mode: runtime check failed: (is_current_mode_known (monitor))

and

Oct 24 09:15:23 jik-d42-x1 kernel: [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
Oct 24 09:15:23 jik-d42-x1 gnome-shell[20744]: Failed to use stored monitor configuration: Invalid mode 2560x1080 (59.999535) for monitor 'GSM LG ULTRAWIDE'

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Are you using some kind of adaptor between HDMI and DisplayPort? I wonder if this monitor needs proper DisplayPort for multi-stream.

Changed in mutter (Ubuntu):
status: New → Incomplete
Changed in xorg-server (Ubuntu):
status: New → Incomplete
Changed in linux (Ubuntu):
status: New → Incomplete
summary: - Ultra-wide monitor recognized properly when plugged in only
- intermittently [Xorg only]
+ [X1 Carbon 7, i915, HDMI] Ultra-wide monitor recognized properly when
+ plugged in only intermittently [Xorg only]
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Hmm, it shouldn't be a multi-stream problem. It looks like you only need HDMI v1.3 to drive that resolution and your laptop supports HDMI 1.4b already.

So mainly I suspect a bad HDMI cable, bad HDMI adaptor, or just faulty EDID data coming from the monitor.

Daniel van Vugt (vanvugt)
no longer affects: mutter (Ubuntu)
Revision history for this message
Jonathan Kamens (jik) wrote :

It's not clear to me how this can be a cable or monitor issue when it only happens in Xorg and it happens much more frequently when one particular app is running (see comment #4). Having said that, I will try to find a spare HDMI cable and test.

I am not using an adapter, I'm plugging an HDMI cable directly into an HDMI port both on the monitor and on the laptop.

Revision history for this message
Jonathan Kamens (jik) wrote :

I tried a different cable. It didn't help.

Also, I can trigger my monitors freaking out as described above merely by launching the Synology Drive Client when the ultra-wide monitor is connected.

Also, the issue seems to be triggered even if the applet isn't visible in my top bar, i.e., even if the only Synology Drive processes that are running are the background processes.

Synology Drive does kernel stuff -- I believe it uses inotify to monitor directories for changes -- so I'm suspecting that there's something misbehaving in the kernel and something that Synology Drive does is banging up against it.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

> Synology Drive does kernel stuff -- I believe it uses inotify to monitor directories for changes -- so I'm suspecting that there's something misbehaving in the kernel and something that Synology Drive does is banging up against it.

I think you might be right.

Changed in linux (Ubuntu):
status: Incomplete → New
Changed in xorg-server (Ubuntu):
status: Incomplete → New
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1849484

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Jonathan Kamens (jik) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected ubuntu
description: updated
Revision history for this message
Jonathan Kamens (jik) wrote : CRDA.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : DpkgLog.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : IwConfig.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : Lspci.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : Lsusb.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : MonitorsUser.xml.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : ProcEnviron.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : ProcModules.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : PulseList.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : RfKill.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : UdevDb.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : UnitySupportTest.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : WifiSyslog.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : XorgLog.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : XorgLogOld.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : Xrandr.txt

apport information

Revision history for this message
Jonathan Kamens (jik) wrote : xdpyinfo.txt

apport information

Changed in linux (Ubuntu):
status: Incomplete → New
status: New → Confirmed
Revision history for this message
Jonathan Kamens (jik) wrote :

FYI: While apport-collect was running, my screens went blank briefly and then when they came back my monitor configuration was wrong: the ultra-wide monitor was at a lower resolution than it's supposed to be and the two monitors' relative positions were not configured correctly. Unplugging the ultra-wide and plugging it back in fixed this situation. This is similar to the behavior I see which prompted me to file this bug in the first place. It would seem that something that apport-collect did triggers the issue or a similar one.

So does launching the TeamViewer client, by the way.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

If you see changes like that after boot then please attach output from 'dmesg' showing the period of time when the change occurred.

Revision history for this message
Jonathan Kamens (jik) wrote :

"If you see changes like that after boot then please attach output from 'dmesg' showing the period of time when the change occurred."

I'm sorry, I'm not sure what you're asking me to watch for here. Can you clarify?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I mean if your monitor shows any faults at all while using it then each time open a Terminal window and run:

  dmesg

Then please copy and paste the most recent messages (probably mentioning "kernel: i915" or "kernel: drm") to here.

Revision history for this message
Jonathan Kamens (jik) wrote :
Download full text (5.7 KiB)

[72227.300557] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72228.173908] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72229.956316] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72233.510378] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72236.205870] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72237.999470] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72239.786382] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72242.549836] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72243.442375] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 54
[72244.361826] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72250.961559] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72254.547660] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72269.690250] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72273.607350] [drm] EDID has major version 93, instead of 1
[72279.495513] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72290.492743] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 54
[72293.153731] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 54
[72294.043151] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 54
[72295.855213] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72297.632687] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 54
[72300.590655] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 54
[72301.836996] i2c i2c-3: sendbytes: error -110
[72315.236846] [drm] EDID has major version 93, instead of 1
[72318.454559] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72318.778580] [drm] EDID has major version 93, instead of 1
[72321.074870] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72322.836269] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72324.607377] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 54
[72325.489757] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72330.776866] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] *ERROR* Unexpected DP dual mode adaptor ID 50
[72332.734125] mce: CPU7: Core temperature above threshold, cpu clock throttled (total events = 575)
[72332.734125] mce: CPU3: Core temperature above threshold, ...

Read more...

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thanks. I still feel the first solution we should be aiming for is (another) new HDMI cable. If you've tried a few (without any adapters!) and none work then I would treat this as a proper kernel bug. The closest existing one I have found is:

https://bugs.freedesktop.org/show_bug.cgi?id=105601

no longer affects: xorg-server (Ubuntu)
Bug Watch Updater (bug-watch-updater)
Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Jonathan Kamens (jik) wrote :

I am somewhat surprised that you think the most likely explanation is a cable issue. The likelihood of a bad cable being the issue when the problem occurs with two different cables and is triggered by specific apps seems, to me, vanishingly low.

Can you elaborate on why you consider that the most likely explanation?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Because in my experience the probability of encountering a low quality cable or bad connection is quite high. Cheap cables are often the norm, not the exception. Sometimes you need to try a few till you find one that works reliably, depending on the resolution and depending on the devices involved.

Anyway, we have an upstream bug now so consider it a software bug:
https://bugs.freedesktop.org/show_bug.cgi?id=105601

Revision history for this message
Jonathan Kamens (jik) wrote :

I ordered a brand new, "premium" Roswell HDMI cable from Newegg and the problem occurs with that cable as well.

Now that the problem has occurred with three different cables, two of them new, with no adapters in the middle, I hope we can agree that it is unlikely that this is a cable issue.

Revision history for this message
In , Jonathan Kamens (jik) wrote :

The folks over at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1849484 are saying they think that bug is the same as this one, but I don't think it is. What do you think?

Revision history for this message
In , Jani-saarinen-g (jani-saarinen-g) wrote :

You are reporter of the issue currently having low priority. Do you still see issue. If so, please spesify clearly what is impact to you.

Revision history for this message
In , Martin-peres-n (martin-peres-n) wrote :

-- 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/91.

Bug Watch Updater (bug-watch-updater)
Changed in linux:
status: Confirmed → Unknown
Revision history for this message
T (tebsu) wrote :

Hi,

i also have the X1 and i had the same problem today.

When my X1 didnt have an external monitor attached, everything was fine. When an external monitor in, everything went black (but mouse cursor visible). I had PhpStorm open.. so i closed it and tried again and it worked. Afterwards i could open PhpStorm again and everything was good.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Thank you for reporting this bug to Ubuntu.
Ubuntu 19.10 (eoan) reached end-of-life on July 17, 2020.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in.

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.