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: <YvYe+5AyI3aD6Q5V@black.fi.intel.com>
Date:   Fri, 12 Aug 2022 12:35:55 +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 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ