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] [thread-next>] [day] [month] [year] [list]
Message-ID: <f0a04f70-5539-42bd-ac15-07054878acfb@kylinos.cn>
Date: Thu, 18 Sep 2025 16:34:31 +0800
From: 李佳怡 <lijiayi@...inos.cn>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org, jiayi_dec@....com
Subject: Re: [PATCH RFC] thunderbolt: Re-add DP resources on resume



在 2025/9/17 20:50, Mika Westerberg 写道:
> On Wed, Sep 17, 2025 at 06:12:31PM +0800, 李佳怡 wrote:
>>
>> As requested, I've attached the complete dmesg output (from boot to after
>> resume) reproducing the issue.
>>
>> Testing Methodology:
>> 1. Start with the Targus Thunderbolt dock already connected to the system
>> 2. Enter S3 suspend (sleep) with no DP monitor connected to the dock
>> 3. Resume from S3
>> 4. After the system has fully resumed, connect the DP monitor to the dock
> 
> Thanks! It is badly line wrapped. I wonder if you can just attach it?
> Anyways I found some unexpected things there:
> 
>> [    8.647850] With USB4 patch v1.0.0
> 
> What is this? ;-)

Thanks for your help!

This is a self-compiled kernel based on version 5.4 with backported 
Thunderbolt drivers. I will also attach the kernel log from a build 
using the linux-6.6.y branch of the community linux-stable repository.

> 
>> [    8.647860] ACPI: bus type thunderbolt registered
>> [    8.664660] [7] nhi_probe:1326: thunderbolt 0000:2c:00.0: total paths: 21
>> [    8.665209] [7] tb_ring_alloc:586: thunderbolt 0000:2c:00.0: allocating
>> TX ring 0 of size 10
>> [    8.665243] [7] tb_ring_alloc:586: thunderbolt 0000:2c:00.0: allocating
>> RX ring 0 of size 10
>> [    8.665267] [7] tb_ctl_alloc:665: thunderbolt 0000:2c:00.0: control
>> channel created
>> [    8.665272] [7] icm_probe:2549: thunderbolt 0000:2c:00.0: ICM not
>> supported on this controller
>> [    8.665285] [7] tb_ring_free:840: thunderbolt 0000:2c:00.0: freeing RX
>> ring 0
>> [    8.665294] [7] tb_ring_free:840: thunderbolt 0000:2c:00.0: freeing TX
>> ring 0
> 
> What is this?
> 
> Is this Intel TB/USB4 controller or something else? All USB4 compliant
> controllers should go directly to tb.c as that's the part dealing with
> software connection manager. The above looks like it tries first with the
> firmware connection manager and that should not happen outside of Intel
> Thunderbolt 3 hosts.

Yes, there is a mistake. I discovered that during the 
USB4_NATIVE_CONTROL negotiation in the firmware, an 
OSC_CAPABILITIES_MASK_ERROR bit was being set incorrectly, which should 
not have happened.

The log I will attach next has been modified to fix this issue.

Thank you for the pointer!

View attachment "thunderbolt-6.6.txt" of type "text/plain" (136671 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ