NVMe boot args and Dummy kext…

I totally forgot to blog about the nvme boot argument that I found in the 10.12 Beta kext seven months ago:

bit-0: (0x01) enable debug output (calls _kprintf)
bit-1: (0x02) enable self refresh
bit-2: (0x04) enable LBA extend
bit-3: (0x08) enable LPSR support during S3/S4
bit-4: (0x10) PCI only mode
bit-5: (0x20) ignore initialisation errors
bit-6: (0x40) enable enctryption support


You may want to run debugMachKernel.sh for bit-0.
For bit-1 setting the “nvme-self-refresh” Number property is required.
For bit-3 setting the “nvme-LPSR-during-S3-S4” Number property is required.
For bit-4 this appears to be the default.

Apple hardware also support: enable-IO-log=1 but that won’t work on other hardware.

Next. I also found a NVRAM variable:


Dummy Kext

I received a couple of questions about this and never got to answer it so let’s do that here. In short. Yes. I am using a dummy kext right now. Here’s what I did:

1.) I copied IONVMEfamily.kext to /S*/L*/E*/AppleNVMeFamily.kext
2.) I patched the binary with my patches only
3.) I changed the version info in the Info.plist from 2.1.0 to 9.9.9

The original vanilla IONVMeFamily.kext is still there in /System/Library/Extensions and all is fine. No issues whatsoever. With 1546 power cycles I can call this a rock solid proven method.


6 thoughts on “NVMe boot args and Dummy kext…

  1. Hi Pike, first of all, thank you for your hard work with the NVME patches.
    It’s been months that I am working on a XPS 9360 machine with NVME drive.
    We are plagued with data corruption, and I worked hard to narrow down the cause.
    I kindly ask for your opinion because this is a low level issue and a few people seem to understand that.

    ## The symptoms:
    1) We have occasional unrecoverable corruption in random disk locations, even inside unmounted partitions.
    2) It seems to happen after a standby cycle. If the system is never put on standby, no corruption will happen.
    3) ** With a system with incomplete PM (no darkwake support), it does not to happen at all. **
    4) With a system with vanilla/native storage drivers (drive LBA formatted to 4K sectors), I have yet to experience corruption, even after forcing the system to hibernate and darkwake.
    5) With patched storage drivers AND complete PM, I experienced unrecoverable corruption after prolonged sleep (so darkwakes and/or hibernate may have occurred).
    6) The corruption I experienced happened before enabling all the deep-idle ACPI patches you discovered, so they are not responsible.

    ## Given the fact that:
    7) Corruption seem to happen only with complete PM and after prolonged sleep
    8) Corruption seems to happen only with patched NVME drivers
    9) Corruption is totally unrecoverable, meaning that also the ECC block at the end of the sector got corrupted
    10) Corruption happens also in unmounted/readonly/efi partitions, meaning that the cause may be drive freeze or error during wear-leveling rewrites and/or write amplification

    ## Suspected cause:
    11) Drive not operating correctly during darkwakes, probably due to unpatched sections of NVME storage driver called only during darkwakes. Maybe the system tries to write a 4KB logical sector, the drive does not understand that, overwrites ECC sectors in emulated/native 512B and if wear-levelling happens, other sectors of the drive, maybe belonging to other unmounted partitions, get corrupted. The unrecoverable corruption is similar to what you experienced when benchmarking your drive before completing your patches.

    ## Alternate cause:
    12) Drive power states not handled correctly during darkwakes or forced to enter low power state before flushing the write cache and/or finishing a correct wear leveling cycle. This may also be caused by an incompletely patched NVME driver.
    13) Files loaded in RAM, then RAM corruption happens during darkwakes, then files flushed to the HDD in inconsistent state. First symptom of faulty RAM is indeed filesystem corruption, usually.

    My bet is on (11).

    Thank you so much for your attention.
    I can provide you any log you may need.

    • First. As fas as I know this only happens on a Dell notebook. Correct?

      Also. It is good to know that the M.2 can be reformatted in the proper format (Native Advanced Format). I sort of knew this after sysctl ran into an issue, and I came up with a test patch, but my question about how he formatted the drive was left unanswered. If only he answered it. But anyway.

      I only patched GenericNVMeSSD in the driver. I did not patch the AppleS3LabController and AppleS3XController so there are still locations that I didn’t have to patch. The question now is what controller is being used? In case that it’s no longer GenericNVMeSSD then that may explain it.

      • As far as I know, only on Dells. But given that currently there are only a few Hacks running on NVMe boot drives, maybe with incomplete PM (so no darkwakes happen), or with hibernate and darkwakes disabled via pmset and/or bootflags, maybe it’s only a matter of time.
        Plus, I don’t think it’s a bug in Dell’s provided SSD, because it’s happening both on LiteOn and Toshiba drives.

        Not every NVME SSD has the ability to be reformatted, unfortunately. Samsung ones, for example, are still stuck at 512B.

        (linux) $ sudo smartctl -a /dev/nvme0
        Supported LBA Sizes (NSID 0x1)
        Id Fmt Data Metadt Rel_Perf
        0 + 512 0 2
        1 – 4096 0 1 <=== this
        $ nvme format -l 1 /dev/nvme0

        Regarding the driver used during "special" power state sessions, how can I help you determine it? Maybe the drive choice is dictated by some ACPI config that only Dells lack/expose.

        As usual, thank you for your time.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s