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

[Mika Westerberg <mika.westerberg@linux.intel.com>]

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.