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

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

[Hans de Goede]

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.

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.

Interestingly enough when booting with the dock connected at boot,
the "thunderbolt ... (DP): not active, tearing down" repeats after
unplug + replug of the dock. Even though on the replug i915 is loaded
and active.

And when booting without the dock connected at boot and then
later connecting the dock things work fine even if i915 was not
in the initramfs.

But if i915 was not in the initramfs *and* the dock was plugged at
boot then the "thunderbolt ... (DP): not active, tearing down" error
persists on TB dock unplug + re-plugs.

I'm not familiar enough with the thunderbolt code to take a shot
at fixing this (and don't have time to dig into it), but I'm happy
to test any possible fixes for this.

Regards,

Hans

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

[Mika Westerberg]

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.

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

[Hans de Goede]

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

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

[Hans de Goede]

Hi,

On 26-Oct-26 11:30 AM, Hans de Goede wrote:
> 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 ?

Ok, so re-reading your answer I guess one problem here is:

"complication with add-in-cards that don't have all DP INs connected"

Still I would expect at least one GPU driver to always load and
initialize successfully. Can we have the GPU driver make a call
to the thunderbolt code that it has initialized even if it is not
claiming any DP connections and then start the timeout from that call?

I think it is reasonable to expect any secondary GPU drivers to load
within 12 seconds once the first one has loaded. But for the no GPU
drivers in initramfs case it may take longer then that for the first
GPU driver to load.

Regards,

Hans


p.s.

We had a similar problem with deferred_probe_timeout handling, see:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/base/Kconfig?id=56e3ee721b33bdc4ce0765d370983aa4384f8a59

there this was fixed by making the default timeout value a Kconfig
option and letting distros override it since previous discussions
did not lead to a consensus on how to handle this. But that won't
work here if we want to deal with the "complication with add-in-cards
that don't have all DP INs connected" case.

I'm mentioning this because it shows there is a generic problem
with this "timeout design pattern" trap us kernel devs seem to
keep falling for, especially in relation to things not happening
in the initramfs while it waits for user input causing all
these timeouts to trigger while they should not trigger yet
because more drivers will load once we switch to the real rootfs.

This has made me thinking that maybe we need a bootup-done
or at least switched-to-real-rootfs sysfs file userspace can
write and only start timeouts like these once userspace has
written that file?

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

[Mika Westerberg]

Hi,

On Mon, Oct 26, 2026 at 11:48:06AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 26-Oct-26 11:30 AM, Hans de Goede wrote:
> > 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 ?
> 
> Ok, so re-reading your answer I guess one problem here is:
> 
> "complication with add-in-cards that don't have all DP INs connected"
> 
> Still I would expect at least one GPU driver to always load and
> initialize successfully. Can we have the GPU driver make a call
> to the thunderbolt code that it has initialized even if it is not
> claiming any DP connections and then start the timeout from that call?
> 
> I think it is reasonable to expect any secondary GPU drivers to load
> within 12 seconds once the first one has loaded. But for the no GPU
> drivers in initramfs case it may take longer then that for the first
> GPU driver to load.
> 
> Regards,
> 
> Hans
> 
> 
> p.s.
> 
> We had a similar problem with deferred_probe_timeout handling, see:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/base/Kconfig?id=56e3ee721b33bdc4ce0765d370983aa4384f8a59
> 
> there this was fixed by making the default timeout value a Kconfig
> option and letting distros override it since previous discussions
> did not lead to a consensus on how to handle this. But that won't
> work here if we want to deal with the "complication with add-in-cards
> that don't have all DP INs connected" case.
> 
> I'm mentioning this because it shows there is a generic problem
> with this "timeout design pattern" trap us kernel devs seem to
> keep falling for, especially in relation to things not happening
> in the initramfs while it waits for user input causing all
> these timeouts to trigger while they should not trigger yet
> because more drivers will load once we switch to the real rootfs.
> 
> This has made me thinking that maybe we need a bootup-done
> or at least switched-to-real-rootfs sysfs file userspace can
> write and only start timeouts like these once userspace has
> written that file?

Yes, I think this is the way to go forward. Then something (like
notification or callback) that drivers who are interested can opt-in.

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

[Hans de Goede]

Hi Mika,

On 26-Oct-26 1:37 PM, Mika Westerberg wrote:
> Hi,
> 
> On Mon, Oct 26, 2026 at 11:48:06AM +0100, Hans de Goede wrote:

<snip>

>> p.s.
>>
>> We had a similar problem with deferred_probe_timeout handling, see:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/base/Kconfig?id=56e3ee721b33bdc4ce0765d370983aa4384f8a59
>>
>> there this was fixed by making the default timeout value a Kconfig
>> option and letting distros override it since previous discussions
>> did not lead to a consensus on how to handle this. But that won't
>> work here if we want to deal with the "complication with add-in-cards
>> that don't have all DP INs connected" case.
>>
>> I'm mentioning this because it shows there is a generic problem
>> with this "timeout design pattern" trap us kernel devs seem to
>> keep falling for, especially in relation to things not happening
>> in the initramfs while it waits for user input causing all
>> these timeouts to trigger while they should not trigger yet
>> because more drivers will load once we switch to the real rootfs.
>>
>> This has made me thinking that maybe we need a bootup-done
>> or at least switched-to-real-rootfs sysfs file userspace can
>> write and only start timeouts like these once userspace has
>> written that file?
> 
> Yes, I think this is the way to go forward. Then something (like
> notification or callback) that drivers who are interested can opt-in.

I'm glad you like the idea.

There are some details which we need to work out. If we enable this
unconditionally in the kernel then all timeouts based on this will
only work if there is a new enough userspace to actually write

"rootfs-mouned" or "bootup-done" to:

/sys/kernel/boot-stage

So my suggestion would be that the initramfs itself will write:

"initramfs" to "/sys/kernel/boot-stage" early on and that activates
this mechanism pausing any potential timeouts.

The problem with this approach though is that this means starting
the timeouts as before, cancelling them on "initramfs" boot-stage
and then re-starting them on "rootfs-mouned" or "bootup-done" .

With the cancelling bit feeling a bit icky, although I guess this
could all be done with the same notifier depending on the notifier
argument so this might not be too bad...

###

Once we've an API design we like, the problem becomes who is going
to write the code for this and lead the attempt to get something
like this upstream. I'm interested in this, but I also really do not
have the time to work on this atm.

Regards,

Hans

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

[Mika Westerberg]

Hi,

On Mon, Oct 26, 2026 at 03:22:06PM +0100, Hans de Goede wrote:
> Hi Mika,
> 
> On 26-Oct-26 1:37 PM, Mika Westerberg wrote:
> > Hi,
> > 
> > On Mon, Oct 26, 2026 at 11:48:06AM +0100, Hans de Goede wrote:
> 
> <snip>
> 
> >> p.s.
> >>
> >> We had a similar problem with deferred_probe_timeout handling, see:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/base/Kconfig?id=56e3ee721b33bdc4ce0765d370983aa4384f8a59
> >>
> >> there this was fixed by making the default timeout value a Kconfig
> >> option and letting distros override it since previous discussions
> >> did not lead to a consensus on how to handle this. But that won't
> >> work here if we want to deal with the "complication with add-in-cards
> >> that don't have all DP INs connected" case.
> >>
> >> I'm mentioning this because it shows there is a generic problem
> >> with this "timeout design pattern" trap us kernel devs seem to
> >> keep falling for, especially in relation to things not happening
> >> in the initramfs while it waits for user input causing all
> >> these timeouts to trigger while they should not trigger yet
> >> because more drivers will load once we switch to the real rootfs.
> >>
> >> This has made me thinking that maybe we need a bootup-done
> >> or at least switched-to-real-rootfs sysfs file userspace can
> >> write and only start timeouts like these once userspace has
> >> written that file?
> > 
> > Yes, I think this is the way to go forward. Then something (like
> > notification or callback) that drivers who are interested can opt-in.
> 
> I'm glad you like the idea.
> 
> There are some details which we need to work out. If we enable this
> unconditionally in the kernel then all timeouts based on this will
> only work if there is a new enough userspace to actually write
> 
> "rootfs-mouned" or "bootup-done" to:
> 
> /sys/kernel/boot-stage
> 
> So my suggestion would be that the initramfs itself will write:
> 
> "initramfs" to "/sys/kernel/boot-stage" early on and that activates
> this mechanism pausing any potential timeouts.

I wonder if using SYSTEM_RUNNING and the like here would do the trick? If
not then maybe adding one more state there?

> The problem with this approach though is that this means starting
> the timeouts as before, cancelling them on "initramfs" boot-stage
> and then re-starting them on "rootfs-mouned" or "bootup-done" .
> 
> With the cancelling bit feeling a bit icky, although I guess this
> could all be done with the same notifier depending on the notifier
> argument so this might not be too bad...

At least for TB I think we can start with the infinite and then once we get
some "notification" just modify the timeout to now + 12s or so. Not sure
about the other use cases though.

> ###
> 
> Once we've an API design we like, the problem becomes who is going
> to write the code for this and lead the attempt to get something
> like this upstream. I'm interested in this, but I also really do not
> have the time to work on this atm.

Yeah, I also don't have time to work on this right now.