Re: "thunderbolt ... (DP): not active, tearing down" error breaking DP over thunderbolt displays

[Hans de Goede <johannes.goede@oss.qualcomm.com>]

Hi Mika,

Thank you for your quick answer.

On 26-Oct-26 6:23 AM, Mika Westerberg wrote:
> Hi,
> 
> On Sat, Oct 24, 2026 at 08:17:16PM +0200, Hans de Goede wrote:
>> Hi All,
>>
>> I hit this error:
>>
>> Oct 24 19:16:58 x1 kernel: thunderbolt 0000:00:0d.3: 0:5 <-> 1:11 (DP): not active, tearing down
>>
>> while doing some work on a Raptor Lake ThinkPad laptop plugged into a Thunderbolt dock.
>>
>> After a bunch of debugging I found that the problem is that I had:
>>
>> "UseSimpleDrm=1" in /etc/plymouth/plymouthd.conf, which combined with
>> the latest dracut version causes dracut to omit the i915 drm driver
>> from the initramfs.
> 
> The error means that the graphics driver did not read the monitor
> capabilities in time (~12s) and therefore the tunnel was torn down.
> Capabilities read is required for DP tunnels to work properly.
> 
>> And when thunderbolt.ko loads (or maybe only once userspace pokes it ?)
>> and the i915.ko driver has not claimed the DP connection then the above
>> message is logged and Linux does not see the DP attached display(s).
>>
>> Building i915.ko into the initramfs works around this, but there
>> seems to be an assumption on the kernel side about things happening
>> in a certain order during boot which there should not be.
> 
> Right but as above capabilities read is required by the specs and we cannot
> keep the DP tunnels up forever to consume power (and there is also
> complication with add-in-cards that don't have all DP INs connected).
> 
> You can pass "thunderbolt.dprx_timeout=-1" (or some number or seconds) to
> work it around.

Hmm, I see thank you for explaining this. The problem is that these kind
of timeouts *never* work. We've been at this since the late 199x years
where we had initramfs shell scripts which loaded scsi drivers and then
had a "sleep 5" for the scsi bus to get scanned, which of course was not
enough on some machines. This was never fixed until we made initramfs-
scripts use udev events to actually wait for the specific disk to show up
instead of a sleep X + blind mount /dev/sdx / which failed when the sleep
was not long enough.

In this case specifically there are plans to stop including the GPU drivers
in the initramfs because of the ever growing size of both the drivers and
especially the firmware the GPU drivers need, see e.g.:

https://hansdegoede.dreamwidth.org/28291.html
https://fedoraproject.org/wiki/Changes/PlymouthUseSimpledrm

The plan is to instead only use simpledrm during the initramfs boot-phase.
And the recent dracut changes to modify dracut's plymouth support to stop
it from bringing in GPU drivers when UseSimpleDrm=1 is set in plymouth's
config file show people are sitll working on this.

Combine this e.g. no i915 in the initramfs with a LUKS diskcrypt password
which the user needs to type in in the initramfs boot-phase and one can
easily exceed the 12 seconds.

AFAICT the GPU driver never showing up (rather then showing up later)
would be a (configuration?) bug of the system. Under normal circumstances
this (GPU driver never showing up) should not happen.

OTOH the GPU driver showing up late is expected behavior when a system
is configured to not have the GPU drivers in the initramfs.

So it seems that the current timeout of 12s optimizes for the wrong thing,
it optimizes for a scenario which should never happen while OTOH breaking
a scenario which (IMHO) we actually want to work.

I think using a timeout of -1 should be the default, since by default
we should expect a GPU driver to show up and claim the DP connection.

Would you be willing to accept a patch to change the default timeout
to -1 ?

Regards,

Hans