linux-kernel - Re: [PATCH v2 1/2] PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge

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: <9654146ac849bb00faf2fe963d3da94ad65003b8.camel@linux.intel.com>
Date: Thu, 08 Feb 2024 08:57:12 -0800
From: "David E. Box" <david.e.box@...ux.intel.com>
To: Daniel Drake <drake@...lessos.org>, Bjorn Helgaas <helgaas@...nel.org>
Cc: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, 
 linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
 bhelgaas@...gle.com,  mario.limonciello@....com, rafael@...nel.org,
 lenb@...nel.org,  linux-acpi@...r.kernel.org, linux@...lessos.org
Subject: Re: [PATCH v2 1/2] PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge

On Thu, 2024-02-08 at 10:52 +0100, Daniel Drake wrote:
> On Thu, Feb 8, 2024 at 9:37 AM Daniel Drake <drake@...lessos.org> wrote:
> > > What would be the downside of skipping the DMI table and calling
> > > pci_d3cold_disable() always?  If this truly is a Root Port defect, it
> > > should affect all platforms with this device, and what's the benefit
> > > of relying on BIOS to use StorageD3Enable to avoid the defect?
> > 
> > I had more assumed that it was a platform-specific DSDT bug, in that
> > PEG0.PXP._OFF is doing something that PEG0.PXP._ON is unable to
> > recover from, and that other platforms might handle the suspend/resume
> > of this root port more correctly. Not sure if it is reasonable to
> > assume that all other platforms on the same chipset have the same bug
> > (if that's what this is).

This does look like a firmware bug. We've had reports of D3cold support missing
when running in non-VMD mode on systems that were designed with VMD for Windows.
These issues have been caught and addressed by OEMs during enabling of Linux
systems. Does D3cold work in VMD mode?

David

> 
> Just realised my main workstation (Dell XPS) has the same chipset.
> 
> The Dell ACPI table has the exact same suspect-buggy function, which
> the affected Asus system calls from PEG0.PXP._OFF:
> 
>         Method (DL23, 0, Serialized)
>         {
>             L23E = One
>             Sleep (0x10)
>             Local0 = Zero
>             While (L23E)
>             {
>                 If ((Local0 > 0x04))
>                 {
>                     Break
>                 }
> 
>                 Sleep (0x10)
>                 Local0++
>             }
> 
>             SCB0 = One
>         }
> 
> (the "L23E = One" line is the one that writes a value to config offset
> 0xe2, if you comment out this line then everything works)
> 
> However, on the Dell XPS system, nothing calls DL23() i.e. it is dead code.
> 
> Comparing side by side:
> Asus root port (PC00.PEG0) has the PXP power resource which gets
> powered down during D3cold transition as it becomes unused. Dell root
> port has no power resources (no _PR0).
> Asus NVM device sitting under that root port (PC00.PEG0.PEGP) has
> no-op _PS3 method, but Dell does not have _PS3. This means that Dell
> doesn't attempt D3cold on NVMe nor the parent root port during suspend
> (both go to D3hot only).
> 
> Let me know if you have any ideas for other useful comparative experiments.
> Daniel