Hacker News Reader

Comment by wtallis | Hacker News Reader

The quirks tables in the Linux NVMe drivers are impressive and depressing:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

And they're not even close to being comprehensive.

Interesting that there are also some anti-quirk special cases in the vendor combo function (second link above), so a certain platform is excepted from the quirk workaround:

   \*
   \* Exclude some Kingston NV1 and A2000 devices from
   \* NVME_QUIRK_SIMPLE_SUSPEND. Do a full suspend to save a
   \* lot fo energy with s2idle sleep on some TUXEDO platforms.
   \*/
  if (dmi_match(DMI_BOARD_NAME, "NS5X_NS7XAU") ||
      dmi_match(DMI_BOARD_NAME, "NS5x_7xAU") ||
      dmi_match(DMI_BOARD_NAME, "NS5x_7xPU") ||
      dmi_match(DMI_BOARD_NAME, "PH4PRX1_PH6PRX1"))
   return NVME_QUIRK_FORCE_NO_SIMPLE_SUSPEND;

I think some of those issues probably stem from the fact that there's not really any alignment between the NVMe spec and the PCIe spec with respect to power management capabilities. I've encountered drives that have implicit dependencies where certain NVMe power management features only work as intended when certain PCIe power management features are available, but there's no way for the drive to express those requirements to the host system, and no standard compliance test suite that will reveal the broken behavior that can occur in the wild.

Sometimes figuring out who to blame for misbehaving hardware requires custom kernel patches, a hardware protocol analyzer at the M.2 slot, and reverse-engineering the motherboard firmware. Most of the entries in the quirks tables are based on a lot of guess-work and inferences because the kernel developers don't have the resources to fully investigate and reproduce these kinds of issues (and the hardware vendors simply don't care about thoroughly ironing out these bugs). It really sucks when you have to look at power flow out of the laptop battery and try to figure out from that whether your SSD is pulling more power than it should.

Wow. I guess this also explains some of the s2idle troubles, with S3 sleep there are the vendor-tested motherboard+peripheral combos that are shown to work with the power states attempted by suspend and any hw/fw bugs get troubleshot before they make it out of the vendors lab.

Oh yeah, and in some cases if the system attempts to go into S2 sleep it simply bricks the SSD forever. I lost a whole lab worth of drives once before I figured it out. The vendor was the opposite of helpful, refusing to acknowledge the problem and then wiping their hands of it and walking away. The only solution I've found requires a hardware modification of the drive, downloading a rip of the vendor's internal repos from a sketchy russian website, building a new firmware from scratch, and then flashing it with some custom hardware.

That would explain why, sometimes, my linux will not find the NVME SSD when booting. (MSI mobo with Kingston SSD).

Model or at least year of that SSD? Early on Kingston used faulty controllers that randomly fail to initiate and degrade with power cycles.

Since last year.

I have a pair of ASUS Vivobook laptops with Kingston NVMEs.

While running the factory install of Windows, those NVMEs would cause a BSOD every third or so boot. Clean install didn't help either, nor any driver or firmware update.

No Linux install has shown any signs of problems.

Reply on news.ycombinator.com