Bug 1132926 - Intel i915 graphics driver issues with external monitor when laptop in docking station
Intel i915 graphics driver issues with external monitor when laptop in dockin...
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel
Leap 15.1
x86-64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
https://gitlab.freedesktop.org/drm/in...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-04-19 18:35 UTC by Otrebor Igorig
Modified: 2022-04-12 14:10 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
no-dock-no-monitor-dmesg (58.96 KB, text/plain)
2019-04-19 18:37 UTC, Otrebor Igorig
Details
no-dock-no-monitor-journalctl (198.50 KB, text/plain)
2019-04-19 18:38 UTC, Otrebor Igorig
Details
o-dock-no-monitor-xrandr (1.08 KB, text/plain)
2019-04-19 18:38 UTC, Otrebor Igorig
Details
no-dock-with-monitor-dmesg (59.03 KB, text/plain)
2019-04-19 18:39 UTC, Otrebor Igorig
Details
no-dock-with-monitor-journalctl (204.13 KB, text/plain)
2019-04-19 18:40 UTC, Otrebor Igorig
Details
no-dock-with-monitor-xrandr (1.56 KB, text/plain)
2019-04-19 18:41 UTC, Otrebor Igorig
Details
dock-no-monitor-dmesg (60.97 KB, text/plain)
2019-04-19 18:41 UTC, Otrebor Igorig
Details
dock-no-monitor-journalctl (207.13 KB, text/plain)
2019-04-19 18:42 UTC, Otrebor Igorig
Details
dock-no-monitor-xrandr (1.08 KB, text/plain)
2019-04-19 18:42 UTC, Otrebor Igorig
Details
dock-with-monitor-dmesg (61.00 KB, text/plain)
2019-04-19 18:43 UTC, Otrebor Igorig
Details
dock-with-monitor-xrandr (1.76 KB, text/plain)
2019-04-19 18:43 UTC, Otrebor Igorig
Details
dock-with-monitor-journalctl (329.89 KB, text/plain)
2019-04-19 18:44 UTC, Otrebor Igorig
Details
dock-with-monitor-dmesg-after-screensaver (61.68 KB, text/plain)
2019-04-19 18:45 UTC, Otrebor Igorig
Details
dock-with-monitor-journalctl-after-screensaver (492.62 KB, text/plain)
2019-04-19 18:45 UTC, Otrebor Igorig
Details
dock-with-monitor-xrandr-after-screensaver (1.73 KB, text/plain)
2019-04-19 18:46 UTC, Otrebor Igorig
Details
test with kernel from lp151 on a lp150 system (391 bytes, text/plain)
2019-04-28 19:23 UTC, Otrebor Igorig
Details
Screenshot of settings screen when looking at the laptop screen (53.07 KB, image/png)
2019-04-28 19:23 UTC, Otrebor Igorig
Details
Screenshot of Settings screen when looking at the external monitor (54.43 KB, image/png)
2019-04-28 19:24 UTC, Otrebor Igorig
Details
Test with kernel 5.0.10 from Kernel:stable repo (392 bytes, text/plain)
2019-04-30 09:02 UTC, Otrebor Igorig
Details
Test with kernel 5.5.11 from Kernel:stable repo (279.85 KB, application/gzip)
2020-03-23 18:03 UTC, Otrebor Igorig
Details
Test with kernel 5.6rc7 from Kernel:HEAD repo (132.17 KB, application/gzip)
2020-03-23 18:04 UTC, Otrebor Igorig
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Otrebor Igorig 2019-04-19 18:35:42 UTC
I have a HP EliteBook 840 G2 running openSUSE Leap 15.0 with all patches applied.
The laptop runs fine when it is in normal portable mode (off dock), also with an external monitor. When I dock it into its docking station at home, I experience weird graphic device behaviour. It is a matter of luck if it is able to initialize and configure the attached external monitor the way it is expected. Sometimes it hangs in an endless config loop when trying to initialize the monitor.
The external monitor is a SAMSUNG U28D590D connected via display port to port #1 to the docking station.
However, if I undock the laptop and plug the very same display cable to the onboard display port then the display and the laptop run as expected. It really is an issue I can only experience when putting the device into the docking station.
For comparison: I had the chance to try another device, a HP EliteBook 840 G3 with the very same docking station and monitor. It was running Windows 7 and I did not see any strange behaviour. Additionally, I was earlier running openSUSE 42.3 on the very same device configuration and did not have any issues. The odd behaviour only started after upgrading to Leap 15.0 and got worse with each patch cycle, to reach total unusability as of today. Hence, thats why I am writing this bug report.
One thing I occasionally see is this error message in the logs:
kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe C FIFO underrun

I attaching output from dmesg, journalctl, and xrandr in different configurations. Let me know if you need more.
Thanks for the support.
Comment 1 Otrebor Igorig 2019-04-19 18:37:34 UTC
Created attachment 803273 [details]
no-dock-no-monitor-dmesg
Comment 2 Otrebor Igorig 2019-04-19 18:38:11 UTC
Created attachment 803274 [details]
no-dock-no-monitor-journalctl
Comment 3 Otrebor Igorig 2019-04-19 18:38:35 UTC
Created attachment 803275 [details]
o-dock-no-monitor-xrandr
Comment 4 Otrebor Igorig 2019-04-19 18:39:41 UTC
Created attachment 803276 [details]
no-dock-with-monitor-dmesg
Comment 5 Otrebor Igorig 2019-04-19 18:40:32 UTC
Created attachment 803277 [details]
no-dock-with-monitor-journalctl
Comment 6 Otrebor Igorig 2019-04-19 18:41:14 UTC
Created attachment 803278 [details]
no-dock-with-monitor-xrandr
Comment 7 Otrebor Igorig 2019-04-19 18:41:57 UTC
Created attachment 803279 [details]
dock-no-monitor-dmesg
Comment 8 Otrebor Igorig 2019-04-19 18:42:27 UTC
Created attachment 803280 [details]
dock-no-monitor-journalctl
Comment 9 Otrebor Igorig 2019-04-19 18:42:55 UTC
Created attachment 803281 [details]
dock-no-monitor-xrandr
Comment 10 Otrebor Igorig 2019-04-19 18:43:26 UTC
Created attachment 803282 [details]
dock-with-monitor-dmesg
Comment 11 Otrebor Igorig 2019-04-19 18:43:57 UTC
Created attachment 803283 [details]
dock-with-monitor-xrandr
Comment 12 Otrebor Igorig 2019-04-19 18:44:46 UTC
Created attachment 803284 [details]
dock-with-monitor-journalctl
Comment 13 Otrebor Igorig 2019-04-19 18:45:18 UTC
Created attachment 803285 [details]
dock-with-monitor-dmesg-after-screensaver
Comment 14 Otrebor Igorig 2019-04-19 18:45:54 UTC
Created attachment 803286 [details]
dock-with-monitor-journalctl-after-screensaver
Comment 15 Otrebor Igorig 2019-04-19 18:46:32 UTC
Created attachment 803287 [details]
dock-with-monitor-xrandr-after-screensaver
Comment 16 Otrebor Igorig 2019-04-19 18:49:26 UTC
I have uploaded the logs of different configurations with/without docking station and with/without the external monitor.

Additonally, I had the ext monitor running as expceted. Then the screensave kicked in and turnded the screens off. After that, it did not come back in the pre-screensaver configuration. This also has been attached to the logs.
Let me know if you need more or something else.
Comment 17 Takashi Iwai 2019-04-23 14:30:27 UTC
Could you check Leap 15.1 kernel to see whether the problem persists?  You can just install the kernel package while keeping the rest 15.0 system.

It's possibly a known issue wrt DP-MST, and it's hard to nail down in Leap 15.1 code (which is a la 4.16 kernel level of DRM code).  Leap 15.1 got the lots of updates and bumped DRM drivers up to 4.19+, so we have a better chance to get it fixed.
Comment 18 Otrebor Igorig 2019-04-23 20:07:31 UTC
Ok, I'll give it a shot.
Allow me a couple of days to do this, as this is a much needed production system, so I need to test this over the weekend.
Stay tuned...
Comment 19 Otrebor Igorig 2019-04-28 19:23:02 UTC
Created attachment 803753 [details]
test with kernel from lp151 on a lp150 system
Comment 20 Otrebor Igorig 2019-04-28 19:23:49 UTC
Created attachment 803754 [details]
Screenshot of settings screen when looking at the laptop screen
Comment 21 Otrebor Igorig 2019-04-28 19:24:32 UTC
Created attachment 803755 [details]
Screenshot of Settings screen when looking at the external monitor
Comment 22 Otrebor Igorig 2019-04-28 19:27:37 UTC
I installed the Leap 15.1 kernel-default as requested (see attached release info file). There is no visible change in (bad) external screen behaviour with this kernel.

What else can I do to be of help?
Comment 23 Takashi Iwai 2019-04-29 05:40:18 UTC
OK, then could you check the 5.0.x kernel in OBS Kernel:stable repo as well?
IOW, does any new kernel work properly?
Comment 24 Otrebor Igorig 2019-04-30 09:02:16 UTC
Created attachment 803889 [details]
Test with kernel 5.0.10 from Kernel:stable repo
Comment 25 Otrebor Igorig 2019-04-30 09:10:05 UTC
I've tested with the 5.0.10 kernel from the Kernel:stable repo, and the issue persists. There are very slight nuances in behaviour, but it still fails to initialize the external monitor.

During the boot process the ext monitor seems to initialize properly multiple times. This is true for the console screen as for the graphical screen when entering the encryption keys for dm-crypt. However, it fails when switching to the graphical login screen. I am also not able to activate it once I have logged in.

I've also tried to undock the device and attach the screen directly to the onboard DP of the device. This works as expected allthough it does limit the resolution of the ext monitor to 2560x1440 instead of 3840x2160.
Comment 26 Takashi Iwai 2019-04-30 09:19:05 UTC
Thanks, that's more or less expected, so it's at least a not bad news for us.
I guess it's now worth for reporting to upstream.  Care to open an upstream bug report, e.g. bugzilla.freedesktop.org component DRI/Intel?
Feel free to put me (tiwai@suse.de) to Cc there.  Thanks.
Comment 27 Otrebor Igorig 2019-04-30 10:02:49 UTC
It's bad news for me ;-)
Never opened an upstream bug with them, but can do.
What's the preferred practice?
Do I copy over all the logs and comments or do I just refer to this one?
I'd prefer the latter.
Comment 28 Takashi Iwai 2019-04-30 10:05:48 UTC
Don't worry, you can point this bugzilla URL, and provide only the requested information there.
Comment 29 Otrebor Igorig 2019-05-06 18:18:29 UTC
Opened bug at bugs.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=110629
Comment 30 Miroslav Beneš 2020-03-09 14:48:12 UTC
This looks forgotten.

Unfortunately, the upstream was not much helpful and closed the bug three days ago without providing the info how to test the latest drm-tip branch to inexperienced user.

Otrebor, could you retest with newer kernel from OBS Kernel:stable repo, please? It does not have the current drm-tip branch, but something may have changed meanwhile. If not, feel free to reopen upstream asking for more help.

We might have some guidelines how to build the kernel somewhere, but I am not sure. Takashi, have you got something simple enough somewhere?
Comment 31 Takashi Iwai 2020-03-11 12:01:25 UTC
Well, usually it's good enough to test with the latest Linus tree, i.e. 5.6-rc.
It can be found in OBS Kernel:HEAD repo.  If the problem persists and the upstream has already a fix, they can inform us.

If it matters, we have also a build from linux-next tree, OBS Kernel:linux-next repo, kernel-vanilla.rpm (not kernel-default).  This is pretty experimental, so if the i915 devs ask about the 5.7 material, we can try it.
Comment 32 Otrebor Igorig 2020-03-23 18:02:09 UTC
Thanks for coming back on this. This isn't solved at all.
I've upgraded this system to leap 15.1 in the meantime, but no improvement in handling the external monitor.
I've also tested both kernels as suggested from the repos Kernel:Stable (@5.5.11) and Kernel:Head (@5.6rc7) with no success.
With 5.6rc7 the system was also close to unusable (screen lag when moving windows).
So, overall it is still the same behaviour as it was with the first approach where the external monitor had been disabled as a quick fix.
pls also see attached logs.
Comment 33 Otrebor Igorig 2020-03-23 18:03:47 UTC
Created attachment 833671 [details]
Test with kernel 5.5.11 from Kernel:stable repo
Comment 34 Otrebor Igorig 2020-03-23 18:04:22 UTC
Created attachment 833672 [details]
Test with kernel 5.6rc7 from Kernel:HEAD repo
Comment 35 Takashi Iwai 2020-03-23 20:35:02 UTC
Could you report the results back to the upstream bug tracker?
  https://gitlab.freedesktop.org/drm/intel/issues/292
Comment 36 Takashi Iwai 2020-03-23 20:39:47 UTC
The issue on upstream gitlab was closed but you can reopen it and report back those results.  5.6-rc must be new enough.
Comment 37 Otrebor Igorig 2020-03-23 21:49:59 UTC
Had to open a new bug as I was unable to reopen the migrated bug.
original bug: https://bugs.freedesktop.org/show_bug.cgi?id=110629
migrated bug: https://gitlab.freedesktop.org/drm/intel/issues/292
new bug: https://gitlab.freedesktop.org/drm/intel/issues/1512
Comment 38 Miroslav Beneš 2021-12-31 14:41:42 UTC
Any news here? There has been no response in upstream bug report. Does the issue persist in Leap 15.3 (probably yes given the kernel version, in that case try Kernel:HEAD repo again, please)?
Comment 39 Otrebor Igorig 2022-01-03 20:46:09 UTC
I now have upgraded the system to Leap 15.3 with Kernel 5.3.18-59.37-default.
The behavior is different now. Better from a users perspective, but still not where I would expect it to be.
I'm now able to initialize the external monitor and get it to work. However, this only works in a usable manner, when making the monitor a display mirror of the internal one with the very same resolution in place (1920x1080).
Using any other resolution or making the external monitor a virtual screen extension does not work in any usable way.
Also, the KDE screen config utility gets confused about the state of the monitor.
When it *is* working, it reports it as disabled and vice versa.
So, I need multiple attempts when activating it, to use it as a mirrored screen in the end. So I'm only doing it when I *really* do need it, which is less now as it used to be.

I've also guessed, that it may have something to do, that the graphics chipset is rather old by now. But occasionally the monitor is able to display its full 4k resolution with the internal one being at 1920x1080, rarely though. 

btw. I've changed employer in the meantime. They handed me a MacBook Pro which is using the same monitor via a USB bridge and HDMI. The monitor works as expected.

So it really *is* a driver issue.
Comment 40 Miroslav Beneš 2022-01-04 07:58:58 UTC
Ok, thanks for the update.

Could you also try the latest kernel from Kernel:HEAD repo? It contains 5.16-rc8 now with the latest drm-tip branch and you could share the results in the upstream bug report. I am afraid we cannot help much besides that.

Patrik might have an idea.
Comment 41 Patrik Jakobsson 2022-01-10 15:46:07 UTC
Yes, it would help if you can try the latest kernel from Kernel:Head. Nothing really stands out in the logs. As Takashi says, it is likely related to MST. I'll try looking some more into the logs. Perhaps the vcpi allocation is incorrect.
Comment 42 Otrebor Igorig 2022-01-18 21:00:49 UTC
Tried to install the 5.16 series kernel from kernel:HEAD today.
This failed as it had package dependency errors when trying to install the kernel. In particular about the filesystem package. I reverted back to the regular kernel as I would not want to risk the system in an unusable state.
Will try again in a couple of days, maybe next week.
Comment 43 Takashi Iwai 2022-01-19 09:07:55 UTC
Please use the kernel in OBS Kernel:stable:Backport if you'd like to try the recent upstream kernel on Leap system.  This is built for the old file hierarchy.
Comment 44 Otrebor Igorig 2022-04-04 19:00:20 UTC
So now this bug has become a bit dated. I'd like to suggest to close this one. I am using kernel version 5.3.18-150300.59.60-default directly from the os package repository. After a number of update cycles the external monitor does what I want. It still has some timing issues when initializing, but I somehow got used to them.

re: timing issues
The monitor needs to be in an active state for the driver to act correctly. I do this by manually waking up the monitor first. Then I set the driver to adjust the monitor as I want it. This works reliably. Having the monitor in passive state does still not work and needs multiple cycles of configuration play-around. btw. My MacBookPro does not have these timing issues using the very same monitor.
Comment 45 Takashi Iwai 2022-04-12 14:10:31 UTC
OK, let's close the bug for now.  Thanks!