Bugzilla – Bug 1132926
Intel i915 graphics driver issues with external monitor when laptop in docking station
Last modified: 2022-04-12 14:10:31 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.
Created attachment 803273 [details]
Created attachment 803274 [details]
Created attachment 803275 [details]
Created attachment 803276 [details]
Created attachment 803277 [details]
Created attachment 803278 [details]
Created attachment 803279 [details]
Created attachment 803280 [details]
Created attachment 803281 [details]
Created attachment 803282 [details]
Created attachment 803283 [details]
Created attachment 803284 [details]
Created attachment 803285 [details]
Created attachment 803286 [details]
Created attachment 803287 [details]
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.
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.
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.
Created attachment 803753 [details]
test with kernel from lp151 on a lp150 system
Created attachment 803754 [details]
Screenshot of settings screen when looking at the laptop screen
Created attachment 803755 [details]
Screenshot of Settings screen when looking at the external monitor
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?
OK, then could you check the 5.0.x kernel in OBS Kernel:stable repo as well?
IOW, does any new kernel work properly?
Created attachment 803889 [details]
Test with kernel 5.0.10 from Kernel:stable repo
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.
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 (email@example.com) to Cc there. Thanks.
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.
Don't worry, you can point this bugzilla URL, and provide only the requested information there.
Opened bug at bugs.freedesktop.org
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?
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.
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.
Created attachment 833671 [details]
Test with kernel 5.5.11 from Kernel:stable repo
Created attachment 833672 [details]
Test with kernel 5.6rc7 from Kernel:HEAD repo
Could you report the results back to the upstream bug tracker?
The issue on upstream gitlab was closed but you can reopen it and report back those results. 5.6-rc must be new enough.
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
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)?
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.
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.
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.
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.
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.
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.
OK, let's close the bug for now. Thanks!