SATA Detection Failure Post-Boot – Likely Timing Regression in AHCI Stack (Affects Suspend-to-RAM)

[Daniel Dube]

To the Linux kernel development team,

Hello I am one of the Local IT specialists and a constant Admirer of
your OS distros I’m reporting a critical, recurring issue observed across a
variety of machines—ranging from 2nd to 10th generation Intel-based laptops
(including units from HP, Acer, and Lenovo). The problem manifests
consistently under the following conditions:

   -

   The SATA drive is not detected or fails to mount during boot, *despite*
   being visible to the bootloader (GRUB) and fully operational under Windows.
   -

   This behaviour spans multiple Linux distributions (Fedora, Pop!_OS,
   Ubuntu, Arch) and kernel versions (tested on 6.2, 6.5, and 6.8).
   -

   Curiously, after a suspend-to-RAM cycle and resume, the drive is
   immediately detected and mounts without issue—suggesting a delayed or
   missed hardware enumeration routine in the AHCI driver or early userspace.

*Key Notes:*

   -

   Issue does *not* stem from BIOS settings or Secure Boot/SATA mode
   misconfiguration.
   -

   The pattern implies a race condition or hardware readiness delay that
   Linux does not currently handle gracefully during early boot.
   -

   The problem significantly affects deployment on lab setups, refurbished
   enterprise laptops, and low-cost educational rollouts—systems where
   reliability and detection of base hardware are non-negotiable.
   -

   It is *not* isolated to a single vendor or age group of machines.

*Request:*
A review of the AHCI SATA enumeration logic or udev timing around early
boot in initramfs. The suspend-resume workaround points to a missing
trigger or state-reset that Windows seems to handle, but Linux does not—yet.

Community reproduction and confirmation should be easy using affected
units. A workaround using RTC wake/suspend injected into initramfs has
proven successful, but this is suboptimal and requires deep user
intervention.

Please advise if this warrants submission to Bugzilla, Kernel.org mailing
lists, or elsewhere.

With urgency and thanks,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20250615/9401d9df/attachment.html>