by

IONVMeFamily.kext changes in Sierra DP4 (build 16A270f)

Here is the slightly modified data that you can use in your KernelAndKextPatches section of Clover config for macOS Sierra DP4:

	<key>KextsToPatch</key>
	<array>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#1</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>ibPwAgAAweAMBQAQAACJgw==</data>
			<key>Replace</key>
			<data>ibPwAgAAweAJBQAQAACJgw==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#2</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>D7aMiIIAAACD+QwPhTIBAA==</data>
			<key>Replace</key>
			<data>D7aMiIIAAACD+QkPhTIBAA==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#3</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>AMeDpAAAAAAQAABIi0gISA==</data>
			<key>Replace</key>
			<data>AMeDpAAAAAACAABIi0gISA==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#4</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>SYnGTYX2dGFBwecMSWP/vg==</data>
			<key>Replace</key>
			<data>SYnGTYX2dGFBwecJSWP/vg==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#5</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>hv8PAABIwegMD7cPgeH/Dw==</data>
			<key>Replace</key>
			<data>hv8PAABIwegJD7cPgeH/Dw==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#6_7</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>icGB4f8PAABIAdFIgfn/DwAAdzs=</data>
			<key>Replace</key>
			<data>icGB4f8BAABIAdFIgfn/AQAAdzs=</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#8</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>SYHF/w8AAEnB7QxJiwQkSA==</data>
			<key>Replace</key>
			<data>SYHF/w8AAEnB7QlJiwQkSA==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#9_10</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>BgIAAEyNuAAQAABMiflIgeEA8P//SYmGGgEAAEmJjiIBAABBvAAQAABJKfQ=</data>
			<key>Replace</key>
			<data>BgIAAEyNuAACAABMiflIgeEA8P//SYmGGgEAAEmJjiIBAABBvAACAABJKfQ=</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#11</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>AABJiY4iAQAAugAQAABIKQ==</data>
			<key>Replace</key>
			<data>AABJiY4iAQAAugACAABIKQ==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#12</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>yAAAAEkp17gAEAAATYskJA==</data>
			<key>Replace</key>
			<data>yAAAAEkp17gAAgAATYskJA==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#13</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>4b+AQBUGTYnWugAQAABFMQ==</data>
			<key>Replace</key>
			<data>4b+AQBUGTYnWugACAABFMQ==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#14</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>iWTY+EmBxAAQAABJgccA8A==</data>
			<key>Replace</key>
			<data>iWTY+EmBxAACAABJgccA8A==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#15</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>Bf8PAABIwegMZvfB/w8PlQ==</data>
			<key>Replace</key>
			<data>Bf8PAABIwegJZvfB/w8PlQ==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#16</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>weIIQQ+2wcHgDEQJ0EQJwA==</data>
			<key>Replace</key>
			<data>weIIQQ+2wcHgCUQJ0EQJwA==</data>
		</dict>
		<dict>
			<key>Comment</key>
			<string>IONVMeFamily Pike R. Alpha Patch#17</string>
			<key>Disabled</key>
			<false/>
			<key>Name</key>
			<string>IONVMeFamily</string>
			<key>Find</key>
			<data>RYTJD5XAD7bAweAMRAnYRA==</data>
			<key>Replace</key>
			<data>RYTJD5XAD7bAweAJRAnYRA==</data>
		</dict>
	</array>

Note that I removed the Info.plist patch, because that is no longer required. Not since DP2 anymore, which is when Apple fixed the IOPCIClassMatch error.

Another thing that changed is the first patch. Ok. It’s only a single byte that changed, but just so that you know what changed.

Edit: I don’t use Clover myself, and I prefer a dummy kext with the patched binary in it. Similar to what I use for AppleHDA8Series.sh but now even cleaner.

You may also want to add the patch to solve the orange drive icon (external drive) and you can do that by adding this patch but you should be using a tiny SSDT with these properties in it. Either that or a modified DSDT.

Advertisements

33 thoughts on “IONVMeFamily.kext changes in Sierra DP4 (build 16A270f)”

  1. Presume you use RevoBoot.
    Is there an *updated* “revoboot for dummies” equivalent resource?
    nb: Am NOT asking you personally for assistance. (and never will). I understand your deep insights get ‘filtered’ by others for projects like Clover.
    Shoulders of giants and all.

    Reply

  5. Pike thanks so much for your posts I really have been enjoying them. I also blog with Hackintosh fixes and I know it takes time to put this stuff online.

    Thanks to your NVMe patches I’ve been able to get my Samsung 950 Pros working on Sierra but something doesn’t seem right. My system log is getting spammed with the message:

    AppleNVMe Assert failed: 0 == (status)

    And this is while using two 950 Pro drives in raid, and booted to it. But the drives work OK and are fast. The issue is that there seems to be cache issues because the deleted process runs continuously invalidating caches and regenerating them. My guess is that it cant write to the cache for some reason. Maybe it is trying to update the boot cache and cannot for some reason? Do you have any ideas?

    Here’s a screenshot of the whole message:

    Thanks again!

    Reply

    • Thanks for your comment @13parsecs,

      I did check out that board before upgrading to X99 because I didn’t have enough PCIe lanes. The cost of the card is still in the $350 range according to the company. I have 2x NVMe drives running in a software raid which is solid and I could run up to 5 because I have the PCIe slots for it.

      Thanks for the suggestion though, that’s a cool article.

      Reply

    • Thanks for moving it. Top!

      Ok. I am looking at your log and I see three errors in it. The first error is usually about the LBA shift value, which we patched already, but the first error in your log appears to be related to the formatted LBA sector size/format (byte 0x1a/26) in the following structure (see flbas):

      /*
 * Identify Namespace Data Structure (v1.10)
 */

struct nvme_id_ns
{
	__le64				nsze;			// Namespace Size
	__le64				ncap;			// Namespace Capacity
	__le64				nuse;			// Namespace Utilization
	__u8				nsfeat;			// Namespace Features
	__u8				nlbaf;			// Number of LBA Formats
	__u8				flbas;			// Formatted LBA Size
	__u8				mc;				// Metadata Capabilities
	__u8				dpc;			// End-to-end Data Protection Capabilities
	__u8				dps;			// End-to-end Data Protection Type Settings
	__u8				rsvd30[98];		// Reserved
	struct nvme_lbaf	lbaf[16];		// LBA Format [16] Support
	__u8				rsvd192[192];	// Reserved
	__u8				vs[3712];		// Vendor Specific
};

      This value can be anything to represent: 512 (no metadata), 520 (8 bytes metadata), 528 (16 bytes metadata), 4096 (no metadata), 4104 (8 bytes metadata), 4160 (64 bytes metadata), and 4224 (128 bytes metadata) bytes. Among others. So how did you format the drive?

      In IONVMeBlockStorageDevice::GetDeviceProperties() at offset 0x4cad in the binary, there is this code:

      test    cl, 0x10
jne     0x41d1

      If flbas bit:4 (0x10) is set (1) then the metadata is transferred at the end of the data LBA, creating an extended data LBA. If flbas bit:4 is cleared (0) then the metadata for a command is transferred as a separate contiguous buffer of data. Bit:4 is not applicable when there is no metadata. And here it fails.

      You can find this in the binary when you search for:


      0xF6 0xC1 0x10
      0x0F 0x85 0x1C 0x01 0x00 0x00

      What I would do (first) is NOP/0x90 out the jne instruction – second line – and check the log. See if the error about line 174 is gone. If that works, then change the value 0x10 into 0x01 or 0x02, 0x04 and 0x08 to see which one works for your drive. Note that there are 16 possible supported LBA Formats (flbas bits 3:0) and I mentioned only a few values. By the way. This value points to a value in lbaf[16]. There the LBA size and format is defined. See the next structure:

      /*
 * Relative Performance
 */

enum {
	NVME_NS_FEAT_THIN	= 1 << 0,
	NVME_LBAF_RP_BEST	= 0,
	NVME_LBAF_RP_BETTER	= 1,
	NVME_LBAF_RP_GOOD	= 2,
	NVME_LBAF_RP_DEGRADED	= 3,
};

/*
 * LBA Format Data Structure
 */

struct nvme_lbaf
{
	__le16			ms;		// Metadata Size
	__u8			ds;		// LBA Data Size
	__u8			rp;		// Relative Performance
};

      Note: flbas bits 7:5 are reserved

      Warning: Please note that doing this is not without risks!

      Tip: I boot from a USB flash drive with the patched binary of the IONVMeFamily.kext on it. Which is relatively easy to setup, and it should protect you from drive errors. When I am done and everything works, only then I copy the driver to my SSD.

      Reply

      • Dear Pike:

        I love you!!!!!!! After change 0x10 to 0x01, it works as expected!!

        find: f6c1100f 851c0100 00
        replace: f6c1010f 851c0100 00

        Here’s the screenshot, I will install macOS on NVMe and report here soon!

        Thank you very much!!!
        syscl

  8. Hello @Piker-Alpha,

    How are you?

    Could you please give me the reason why you change the value from 0x10 to 0x01, 0x02, 0x04, 0x08? Is this value depends on specific hard disk and cannot be changed?(Very curious about it)

    Here’s the NVMe information after install macOS 10.12.2

    Here’s the ioreg
    https://github.com/syscl/XPS9350-macOS/files/721209/syscl.s.MacBook.zip

    There’s no IONVMEFamily.kext error in log anymore, gut ;).

    Now the rest is to log out the IONVMeFamily information before sleep(to see what cause the data corruption):
    sudo log config –mode “level:debug”
    log show –predicate ‘process == “kernel”‘ –last “5m”

    is this command lines fit your requirement?

    Thank you!
    syscl

    Reply

    • I think that I explained that already in my previous post 😉

      Edit: Sorry for running out of time/being a bit lazy. I now added some extra information. I hope that this helps you to understand what we are doing 😉

      Ok. Let’s assume that there is no firmware bug, which can cause data corruption as well, and that sleep is entered without delay, then you may need to add Sleep (0x3e8) in method _PTS to give it some time to flush out the data.

      For the debug output. I take it that the corruption occurs when it enters sleep, so you will need to write the data (in plain text) so another volume/device, or it will be lost.

      You can setup a hot corner to enter sleep. What I do is move the mouse cursor in the upper left corner to let it sleep, and then after a short while, I move the cursor around on the screen to wake it up, before is goes into a deeper sleep state. Why? The last few lines in the log may give me some clues as to what goes wrong. So please. Try this before anything.

      Reply

      • Dear Pike,

        OK, I need some time to digest your content 😉

        BTW, my friends lent their MacBook9,1 and MacBookPro13,2 for me. I dumped some information from their new MacBook. I soon found some interesting properties rooted Device (SSD0):
        “deep-idle”, here’s the code I changed(added deep-idle and removed “sats-express-power-off” and “ssd-off-in-S4”:

        If (LEqual (NVME, One))
        {
        Return (Package (0x06)
        {
        “deep-idle”
        One,
        “use-msi”,
        One,
        “nvme-LPSR-during-S3-S4”,
        One
        })
        }
        Else
        {
        Return (Package (0x02)
        {
        “use-msi”,
        One,
        })
        }

        Then there will be deep-idle in ioreg:

        Now, the power consume has slightly lowered down(lower 0.1w~0.3w).

        Wish this could help to improve power consume.

        Have a good day,
        syscl

      • Let’s first check if deep-idle et all is even supported. Add nvme=0x100 to your boot arguments and reboot. Check the log for IONVMeFamily related output.

  9. Dear Pike,

    I added nvme=0x100 -v in boot arguments then reboot. But I found no a single line log information about IONVMeFamily. Does that means something or I do something wrong? I use IONVMeFamily.kext from 10.12.3 beta4(16D30a).

    Thank you,
    syscl

    Reply

    • I going to assume that you forgot to add debug=0x12a and perhaps I am wrong and was it nvme=0x101. Give it a try. You should find at least a few lines with IONVMeController:: in the log.

      Reply

      • Hi @Pike,

        Thanks for the heads up.

        boot arguments: debug=0x12a nvme=0x100 -v gives:
        no NVMe log

        boot arguments: debug=0x12a nvme=0x101 -v gives only the following log of NVMe:
        2017-01-22 13:02:05.181918-0600 localhost kernel[0]: (IONVMeFamily) virtual bool IONVMeController::InitializePCI()::861:Number of MSI-X interrupts=0x13

        Thank you,
        syscl

      • Ok. 0x101 it is then, but that line alone is even less than anything else I have seen so far.

        Edit: Do I have your ACPI tables? If not. Please link me to the files. Thanks.

Leave a Reply

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

Gravatar
WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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 )

Cancel

Connecting to %s