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] [day] [month] [year] [list]

Date:   Fri, 12 Aug 2022 18:16:56 +0800
From:   Brad Campbell <lists2009@...rfbargle.com>
To:     Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Apple Thunderbolt Display chaining

G'day Mika,

On 12/8/22 17:35, Mika Westerberg wrote:
> Hi Brad,
> 
> On Thu, Aug 11, 2022 at 10:17:02PM +0800, Brad Campbell wrote:
>> G'day Mika,
>>> Okay, do you see in the dmesg whether the DP tunnels are actually
>>> created when you see the issue?
>>>
>>
>> Yes, the DP tunnels appear to be created. Xorg sees them and believes they are there :
>>
>> brad@bkd:~$ grep -A1 EDID  /var/log/Xorg.0.log.old 
>> [    29.377] (II) AMDGPU(0): EDID for output HDMI-A-0
>> [    29.377] (II) AMDGPU(0): Manufacturer: DEL  Model: a19d  Serial#: 810240841
>> --
>> [    29.377] (II) AMDGPU(0): EDID Version: 1.3
>> [    29.377] (II) AMDGPU(0): Digital Display Input
>> --
>> [    29.377] (II) AMDGPU(0): Number of EDID sections to follow: 1
>> [    29.377] (II) AMDGPU(0): EDID (in hex):
>> [    29.377] (II) AMDGPU(0): 	00ffffffffffff0010ac9da1494b4b30
>> --
>> [    29.377] (II) AMDGPU(0): EDID for output DisplayPort-0
>> [    29.377] (II) AMDGPU(0): Manufacturer: APP  Model: 9227  Serial#: 354616281
>> --
>> [    29.377] (II) AMDGPU(0): EDID Version: 1.4
>> [    29.377] (II) AMDGPU(0): Digital Display Input
>> --
>> [    29.378] (II) AMDGPU(0): Number of EDID sections to follow: 1
>> [    29.378] (II) AMDGPU(0): EDID (in hex):
>> [    29.378] (II) AMDGPU(0): 	00ffffffffffff0006102792d9032315
>> --
>> [    29.378] (II) AMDGPU(0): EDID for output DisplayPort-1
>> [    29.378] (II) AMDGPU(0): Manufacturer: APP  Model: 9227  Serial#: 437126968
>> --
>> [    29.378] (II) AMDGPU(0): EDID Version: 1.4
>> [    29.378] (II) AMDGPU(0): Digital Display Input
>> --
>> [    29.378] (II) AMDGPU(0): Number of EDID sections to follow: 1
>> [    29.378] (II) AMDGPU(0): EDID (in hex):
>> [    29.378] (II) AMDGPU(0): 	00ffffffffffff000610279238070e1a
>>
>> This test was done with thunderbolt compiled in just to demonstrate,
>> but any load sequence or combination
>> winds up with the same issue.
> 
> I went through your log but could not find anything out of ordinary from
> TBT perspective. The tunnels get cleaned up by the discovery code and
> then re-created after the reset completes and they seem to be fine. You
> may try to add some sort of delay like 100ms or so after the DPR reset
> but I doubt it changes anything.
> 

I'll have a bit more of a play. I compiled both thunderbolt and amdgpu as modules
and played with them both blacklisted and then loading both manually from the console
after boot to see if there was any timing interaction with the DP tunnels. I normally
have to force the DP links up and provide the EDID on the kernel command line, but
if I give it sufficient time between thunderbolt discovery and amdgpu load it picks up
the links *and* manages to load the EDID from both without anything having to be forced.

I think with your diagnostic assistance I've learned enough about how the architecture
works to keep futzing around to see if I can find some determinism in the system and
figure out what is going on. I'll keep cracking at it and try not to bother you unless
I really can't figure it out.

I'm beginning to think as I'm the only person that seems to be running this hardware
it's some perverse combination that anyone else is highly unlikely to run into. Worst
case I still have my existing workarounds.

I really, _really_ appreciate your assistance.

Regards,
Brad