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: <CAD8Lp44tO_pz_HZmPOKUQ-LEQT=c856eH52xWL9nBtAtJwjL1g@mail.gmail.com>
Date: Fri, 9 Feb 2024 09:36:21 +0100
From: Daniel Drake <drake@...lessos.org>
To: david.e.box@...ux.intel.com
Cc: Bjorn Helgaas <helgaas@...nel.org>, 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, Feb 8, 2024 at 5:57 PM David E. Box <david.e.box@...ux.intel.com> wrote:
> 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?

On Windows for the VMD=on case, we only tested this on a BIOS with
StorageD3Enable=0. The NVMe device and parent bridge stayed in D0 over
suspend, but that's exactly what the BIOS asked for, so it doesn't
really answer your question.

On Linux with VMD=on and StorageD3Enable=1, the NVMe storage device
and the VMD parent bridge are staying in D0 over suspend. I don't know
why this is, I would have expected at least D3hot.  However, given
that the NVMe device has no firmware_node under the VMD=on setup, I
believe there is no way it would enter D3cold because there's no
linkage to an ACPI device, so no available _PS3 or _PR0 or whatever is
the precise definition of D3cold.

I also realise I may have made a bad assumption in my previous mail
when looking at the Dell device: I was assuming that a parent PCI
bridge cannot go into D3cold if its child devices only got as far as
D3hot, but I now realise I'm not sure if that constraint actually
exists.

Not sure if these questions are relevant for the consideration of this
patch, but I'll try to find some time to answer them next week.

Daniel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ