linux-kernel - Re: [PATCH 1/2] PCI: Clear LBMS on resume to avoid Target Speed quirk

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: <alpine.DEB.2.21.2408121247580.59022@angie.orcam.me.uk>
Date: Mon, 12 Aug 2024 12:59:04 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
cc: Bjorn Helgaas <helgaas@...nel.org>, linux-pci@...r.kernel.org, 
    LKML <linux-kernel@...r.kernel.org>, 
    Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH 1/2] PCI: Clear LBMS on resume to avoid Target Speed
 quirk

On Fri, 9 Aug 2024, Ilpo Järvinen wrote:

> > # setpci -s 02:03.0 CAP_EXP+0x12.W
> > 5812
> > # setpci -s 02:03.0 CAP_EXP+0x12.W
> > 5811
> > 
> > As you can see the Link Training bit oscillates as I previously reported 
> > and noted in the introduction to `pcie_failed_link_retrain', and also the 
> > Current Link Speed field flips between 2.5GT/s and 5GT/s.
> 
> Okay, thanks for testing. I suppose that test wasn't done in a busy loop 
> (it might not be easy capture very short link up state if there was any 
> such period when testing it by manually launching that command a few 
> times)?

 These were just random samples obtained by reissuing `setpci' command at
a command prompt, as shown.  As I say I haven't ever seen DLLLA going up, 
or I suppose the dance would have stopped.  Polling for the bit set in a 
busy loop would require injecting code into `pcie_failed_link_retrain' for 
such a diagnostic check if at all feasible or fiddling with U-Boot code.  

 I'll see if I can make a suitable change to `pcie_failed_link_retrain' 
and persuade the kernel not to interfere for the duration of the check 
(it'll be fine for the kernel to crash afterwards).  If that won't do, 
then it's straightforward to arrange with U-Boot, but to do it safely it 
requires physical access to the system as U-Boot is stored on a uSD card 
with this system, and I'm not on site anymore, so it'll have to wait.

  Maciej