Bug ID: 1187566 Summary: Display connected to Thunderbolt 3 Docking Station is not detected on cold boot Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: email@example.com Reporter: firstname.lastname@example.org QA Contact: email@example.com Found By: --- Blocker: ---
I am using a HP Elitebook 1040 G4 notebook connected to a HP Thunderbolt 3 Docking Station, which in turn is connected to multiple USB devices and an external monitor via DisplayPort. Unfortunately, I am experiencing issues with this configuration as described below.
I am using boltd from the hardware repository to authorize my Thunderbolt 3 Docking Station during startup. (Boot ACLs are not supported by my BIOS, as far as I can tell.) While devices connected to the docking station via USB will work afterwards, my external monitor, which is connected via DisplayPort, will not be detected automatically. Only when I manually reconnect the docking station after startup has completed, it will finally be detected (and awoken from standby). This leads me to believe that this issue is boot order related.
(Previously, I was using openSUSE Leap 15.2 and a custom udev rule to authorize the docking station via sysfs and I did not experience this issue but the system would occasionally hang while booting instead. I have already tried the udev rule with openSUSE Leap 15.3 but this made the issue worse as the display was then only detected if I reconnected the external monitor itself.)
Any help investigating this issue is appreciated as I do not have in-depth knowledge of the kernel or its Thunderbolt subsystem and cannot really make any progress towards a resolution on my own.
--- Comment #2 from Anonymous User firstname.lastname@example.org --- I have done some more testing with kernel 5.12.12-lp153.3.1.g43254cf-x86_64 from Kernel:stable:Backports an obtained some interesting results:
With the default 5.3.18 kernel, the monitor will awake from standby one out of four times during startup. (So the issue seems to be dependent on some timing, which in turn might affect the order of parts of the boot sequence.)
With the 5.12.12 kernel, the monitor will awake from standby three out of four times during startup. When the monitor awakes, one of the following happens: 1) The monitor awakes while the splash screen is displayed. In this case startup will finish and everything works as expected. 2) The monitor awakes while both my notebook's BIOS logo and the Leap logo are still being displayed, which happens before the actual splash screen is being displayed. In this case the system will hang and startup will not proceed any further. If I unplug my docking station, startup will continue. If i reconnect my docking station after startup is completed, the monitor will be detect and awake from standby after boltd authorizes the docking station. (This is the issue that I have already observed back when I was using openSUSE Leap 15.2 with the default kernel except that I was using a udev rule instead of boltd, as mentioned above.)
So there seems to be an improvement with a more up-to-date kernel but the issue is not fully resolved yet.
--- Comment #3 from Anonymous User email@example.com --- Further clarification because some terminology might not be well defined:
With splash screen I was referring to the splash screen of KDE.
The display showing both my BIOS' logo and the Leap logo should be the plymouth splash screen.
Anonymous User firstname.lastname@example.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|eecdc3.opensuse@coders-have | |n.net | Version|Leap 15.3 |Leap 15.4 Flags|needinfo?(eecdc3.opensuse@c | |oders-haven.net) | OS|openSUSE Leap 15.3 |openSUSE Leap 15.4
--- Comment #4 from Anonymous User email@example.com --- I just wanted to let you know that the problem still persists after I updated to openSUSE Leap 15.4 (which ships with support for bolt out of the box) with kernel 5.14.21-150400.24.21-default. I am therefor updating the affected version.
--- Comment #5 from Anonymous User firstname.lastname@example.org --- One thing has apparently changed though: I am not getting anymore hangs as described in comment #2. Instead of the hang the system will just power down immediately and my caps lock indicator light lights up for at least one second indicating some internal/hardware error of my notebook. I have found no entry in /var/log/messages at first glance that would explain this, but I also do not know which type of entry I should be looking for.
--- Comment #6 from Anonymous User email@example.com --- Another interesting observation: My monitor also has a USB hub, which is connected to one of the USB ports of my Thunderbolt 3 docking station. And it turns out that in the cases where my monitor is not detected (as a device connected via DisplayPort over the Thunderbolt connection), the USB hub is still detected via USB over the Thunderbolt connection.
Takashi Iwai firstname.lastname@example.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eecdc3.opensuse@coders-have | |n.net Flags| |needinfo?(eecdc3.opensuse@c | |oders-haven.net)
--- Comment #7 from Takashi Iwai email@example.com --- Was your test with the latest Leap 15.4 kernel? If yes, retest with the kernel in OBS Kernel:SLE15-SP4 repo. There have been a few serious bugs that might lead to the problem as you described in the latest Leap 15.4 kernel.
--- Comment #8 from Anonymous User firstname.lastname@example.org --- The kernel version I used, 5.14.21-150400.24.21-default, is the most recent openSUSE Leap 15.4 kernel.
I can retry with the SLE build of the kernel. As I understand it, I simply have to add the repository at https://download.opensuse.org/repositories/Kernel:/SLE15-SP4/pool and then switch packages, right?
And just to make sure: From a legal perspective I am also allowed to use that package in my openSUSE installation, yes?
--- Comment #9 from Takashi Iwai email@example.com --- There is no legal problem at all. The only caveat would be that it's an unofficial build, hence you'd need to turn off Secure Boot on BIOS, if it's enabled beforehand.
The next update kernel will appear likely in this week, so you can wait for a few days, instead, too.