linux-kernel - Re: [PATCH v2 0/2] thunderbolt: Fix S4 resume incongruities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0819af50-d19c-4169-b3be-74cde9388802@linux.intel.com>
Date: Tue, 3 Feb 2026 16:50:28 -0800
From: "Katiyar, Pooja" <pooja.katiyar@...ux.intel.com>
To: Kenneth Crudup <kenny@...ix.com>
Cc: "open list:THUNDERBOLT DRIVER" <linux-usb@...r.kernel.org>,
 linux-kernel@...r.kernel.org, Andreas Noever <andreas.noever@...il.com>,
 Yehezkel Bernat <YehezkelShB@...il.com>,
 Pooja Katiyar <pooja.katiyar@...el.com>,
 Rene Sapiens <rene.sapiens@...ux.intel.com>,
 Mika Westerberg <mika.westerberg@...ux.intel.com>,
 Mario Limonciello <superm1@...nel.org>
Subject: Re: [PATCH v2 0/2] thunderbolt: Fix S4 resume incongruities

Hi Kenny,

On Thu, Jan 29, 2026 at 05:42:43PM -0800, Kenneth Crudup wrote:
> 
> BTW, I had no TB connectivity until I'd unplugged/replugged.
> 
> -Kenny

Thanks for testing the patch series!

To help diagnose the warning/issue, can you share your TB dock/setup
information and the steps that you are following? Also it would be
helpful if you can provide logs with dynamic debugging enabled for
thunderbolt. I am not able to reproduce the issue at my end, so the
above information would be really helpful to look into the issue while
I continue checking on my end. From the warning it appears that the tunnels
are invalid from the stack trace in the logs.

> 
> On 1/29/26 17:39, Kenneth Crudup wrote:
>>
>>>> The issue I'm trying to chase down (and not sure if any of this will
>>>> help with this, I wonder if it's really BIOS/EC related) is often times
>>>> that after a suspend (or hibernate, but I use "suspend then hibernate",
>>>> which I think does both and chooses which to use upon resume) and then
>>>> connect to a different dock (or setup) from the one I'd suspended with,
>>>> sometimes I have to unplug/replug my TB cable, otherwise I either get no
>>>> recognition of my new display setup (and sometimes TB devices) or it'll
>>>> try and use the same monitor resolution of the previously-connected
>>>> monitor (as if the TB subsystem doesn't recognize things have changed).
>>
>> On 1/29/26 15:13, Katiyar, Pooja wrote:
>>
>>> Below is the patch series that addresses mentioned issue. There are two
>>> patches in this series. The series takes care of releasing the DP resources
>>> as part of freeze call before the hibernation image is created. You can test
>>> it for your issues and let us know if it helps.
>>>
>>> Please note that these changes are still under internal review and are
>>> subject to change.
>>
>> I tested this against Linus' master (4d310797262) and while the jury is still out on my issue (a few tests against different monitors looked good, the big test is when I get back home later), I did see this on the 3rd resume from hibernate (full dmesg attached):
>>
>> ----

Thanks and Regards,
Pooja