public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Eric <eric.4.debian@grabatoulnz.fr>,
	Salvatore Bonaccorso <carnil@debian.org>,
	Mario Limonciello <mario.limonciello@amd.com>,
	Christoph Hellwig <hch@infradead.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Damien Le Moal <dlemoal@kernel.org>,
	Jian-Hong Pan <jhp@endlessos.org>,
	regressions@lists.linux.dev, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, linux-ide@vger.kernel.org,
	Dieter Mummenschanz <dmummenschanz@web.de>
Subject: Re: Regression from 7627a0edef54 ("ata: ahci: Drop low power policy board type") on reboot (but not cold boot)
Date: Mon, 10 Mar 2025 19:13:08 +0100	[thread overview]
Message-ID: <Z88rtGH39C-S8phk@ryzen> (raw)
In-Reply-To: <9c4a635a-ce9f-4ed9-9605-002947490c61@redhat.com>

Hello Hans,

On Mon, Mar 10, 2025 at 10:34:13AM +0100, Hans de Goede wrote:
> 
> I think that the port-mask register is only read-only from an OS pov,
> the BIOS/UEFI/firmware can likely set it to e.g. exclude ports which are
> not enabled on the motherboard (e.g. an M2 slot which can do both pci-e + 
> ata and is used in pci-e mode, so the sata port on that slot should be
> ignored).
> 
> What we seem to be hitting here is a bug where the UEFI can not detect
> the SATA SSD after reboot if it ALPM was used by the OS before reboot and
> the UEFI's SATA driver responds to the not detecting by clearing the bit
> in the port-mask register.
> 
> The UEFI not detecting the disk after reboot when ALPM was in use also
> matches with not being able to boot from the disk after reboot.

If we look at dmesg:
ahci 0000:00:11.0: AHCI vers 0001.0200, 32 command slots, 6 Gbps, SATA mode
ahci 0000:00:11.0: 3/3 ports implemented (port mask 0x38)
ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 

We can see that the controller supports slumber, partial,
and aggressive link power management ("pm").


A COMRESET is supposed to take the device out of partial or slumber.

Now, we do not know if the BIOS code sends a COMRESET, but it definitely
should.

Anyway, it is stated in AHCI 1.3.1 "10.1 Software Initialization of HBA",

"To aid system software during runtime, the BIOS shall ensure that the
following registers are initialized to values that are reflective of the
capabilities supported by the platform."

"-PI (ports implemented)"


> 
> I think what would be worth a try would be to disable ALPM on reboot
> from a driver shutdown hook. IIRC the ALPM level can be changed at runtime
> from a sysfs file, so we should be able to do the same at shutdown ?
> 
> Its been a while since I last touched the AHCI code, so I hope someone else
> can write a proof of concept patch with the shutdown handler disabling ALPM
> on reboot ?

I mean, that would be a quirk, and if such a quirk is created, it should
only be applied for buggy BIOS versions.

(Since BIOS is supposed to initialize the PI register properly.)

If
ahci.mobile_lpm_policy=1
or
ahci.mobile_lpm_policy=2
works around your buggy BIOS, then I suggest you keep that
until your BIOS vendor manages to release a new BIOS version.


Kind regards,
Niklas

  reply	other threads:[~2025-03-10 18:13 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-02 16:03 Regression from 7627a0edef54 ("ata: ahci: Drop low power policy board type") on reboot (but not cold boot) Salvatore Bonaccorso
2025-03-02 16:20 ` Christian Heusel
2025-03-02 19:28 ` Salvatore Bonaccorso
2025-03-02 19:32 ` Niklas Cassel
2025-03-02 20:32   ` Eric
2025-03-03  6:25     ` Niklas Cassel
     [not found]       ` <8b1cbfd4-6877-48ef-b17d-fc10402efbf7@grabatoulnz.fr>
2025-03-03 18:04         ` Eric
2025-03-06 10:37         ` Niklas Cassel
2025-03-06 10:40           ` Niklas Cassel
2025-03-06 12:27             ` Eric
2025-03-07  9:53               ` Niklas Cassel
2025-03-08 10:05                 ` Eric
2025-03-08 18:20                   ` Eric
2025-03-10 16:24                   ` Niklas Cassel
2025-03-17 16:33                     ` Mario Limonciello
2025-03-10  9:34                 ` Hans de Goede
2025-03-10 18:13                   ` Niklas Cassel [this message]
2025-03-10 20:12                     ` Hans de Goede
2025-03-11 14:14                       ` Niklas Cassel
2025-03-12 17:11                         ` Eric
2025-03-12 21:39                           ` Eric
2025-03-13 12:21                             ` Niklas Cassel
2025-03-13 10:04                         ` Hans de Goede
2025-03-13 12:48                           ` Niklas Cassel
2025-03-13 15:13                             ` Hans de Goede
2025-03-13 15:28                               ` Niklas Cassel
2025-03-13 18:47                                 ` Hans de Goede
2025-03-17 17:09                                   ` Niklas Cassel
2025-03-17 19:15                                     ` Eric
2025-03-18  0:04                                       ` Eric
2025-03-18  9:10                                         ` Niklas Cassel
2025-03-22 19:11                                           ` Eric

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z88rtGH39C-S8phk@ryzen \
    --to=cassel@kernel.org \
    --cc=carnil@debian.org \
    --cc=dlemoal@kernel.org \
    --cc=dmummenschanz@web.de \
    --cc=eric.4.debian@grabatoulnz.fr \
    --cc=hch@infradead.org \
    --cc=hdegoede@redhat.com \
    --cc=jhp@endlessos.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=regressions@lists.linux.dev \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox