linux-kernel - Re: Apple Thunderbolt Display chaining

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]

Date:   Fri, 5 Aug 2022 14:30:11 +0300
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Brad Campbell <lists2009@...rfbargle.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Apple Thunderbolt Display chaining

Hi,

On Fri, Aug 05, 2022 at 03:41:14PM +0800, Brad Campbell wrote:
> [  620.072070] pcieport 0000:2a:05.0: can't change power state from D3cold to D0 (config space inaccessible)
> [  620.676124] pcieport 0000:2a:05.0: pciehp: pcie_do_write_cmd: no response from device
> [  621.903381] hrtimer: interrupt took 604006559 ns
> [  622.296070] pcieport 0000:2a:05.0: pciehp: pcie_do_write_cmd: no response from device
> [  622.698769] pcieport 0000:31:05.0: can't change power state from D3cold to D0 (config space inaccessible)
> [  623.302796] pcieport 0000:31:05.0: pciehp: pcie_do_write_cmd: no response from device
> [  623.906840] pcieport 0000:31:04.0: can't change power state from D3cold to D0 (config space inaccessible)
> [  624.511090] pcieport 0000:31:04.0: pciehp: pcie_do_write_cmd: no response from device
> [  625.115091] pcieport 0000:04:01.0: can't change power state from D3cold to D0 (config space inaccessible)
> [  625.719304] pcieport 0000:04:01.0: pciehp: pcie_do_write_cmd: no response from device
> [  625.920747] thunderbolt 0000:05:00.0: 303: timeout writing config space 2 to 0x28
> [  625.920752] thunderbolt 0-303: reading DROM failed: -5
> [  625.920753] thunderbolt 0000:05:00.0: 303: uid: 0x0
> [  626.524964] pcieport 0000:31:05.0: pciehp: pcie_do_write_cmd: no response from device
> [  626.726306] pcieport 0000:31:04.0: pciehp: pcie_do_write_cmd: no response from device
> [  626.927661] pcieport 0000:04:01.0: pciehp: pcie_do_write_cmd: no response from device
> [  627.330332] pcieport 0000:04:02.0: can't change power state from D3cold to D0 (config space inaccessible)
> [  627.837000] thunderbolt 0000:05:00.0: 303: timeout reading config space 1 from 0x0
> [  627.837005] thunderbolt 0-303: failed to initialize port 1
> [  628.277015] thunderbolt 0000:05:00.0: 3: timeout reading config space 1 from 0x3b
> [  628.716825] thunderbolt 0000:05:00.0: 0: timeout reading config space 1 from 0x3b
> [  629.156976] thunderbolt 0000:05:00.0: 0: timeout reading config space 1 from 0x3b
> [  629.597002] thunderbolt 0000:05:00.0: 0: timeout reading config space 1 from 0x39
> [  630.037013] thunderbolt 0000:05:00.0: 0: timeout reading config space 1 from 0x39
> [  630.477032] thunderbolt 0000:05:00.0: 0: timeout reading config space 1 from 0x39
> [  630.916994] thunderbolt 0000:05:00.0: 0: timeout reading config space 1 from 0x39
> [  631.356836] thunderbolt 0000:05:00.0: 3: timeout reading config space 1 from 0x39
> [  631.806792] thunderbolt 0000:05:00.0: 3: timeout reading config space 1 from 0x39
> [  632.246828] thunderbolt 0000:05:00.0: 0: timeout reading config space 2 from 0x10f
> [  632.686977] thunderbolt 0000:05:00.0: 0: timeout reading config space 2 from 0x10f
> 
> I'm dangerously *assuming* that when trying to configure an already configured system the thunderbolt
> driver is getting stuck because booting without trying to load the driver works fine.
> 
> If I try and warm boot when its in this state, the machine doesn't reach the EFI and I have to
> hard reset or power cycle.
> 
> My questions are :
> A) Since I have a viable but hacky work-around, is this something
> you'd be interested in helping chase down?

I can try yes.

> B) If so, what debugging information can I supply?

Well can you try so that you disable PCIe PM for starters? Pass
"pcie_port_pm=off" in the command line and see if anything changes. Of
course this prevents low power states.