Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MP 1,1-5,1 Innie: A fix for PCI drives seen as external

cdf said:
You mean the built-in property? The reason is that the rest of the tree is not ready yet, so Innie simply gets out of the way. Of course, we can keep querying the I/O Registry, but when do we stop? We can also insert delays, but how long?
Click to expand...
Maybe not based on time, but on feedback after interrogation. Checking if the tree downstream is ready. Is there an indication?
 
startergo said:
Maybe not based on time, but on feedback after interrogation. Checking if the tree downstream is ready. Is there an indication?
Click to expand...
Right. So there are two indicators that Innie uses: "IOPCIConfigured" and "IOPCIResourced". The assumption is that if the "built-in" property is set before the rest of the tree is ready, then the corresponding internal properties are automatically applied, but this is clearly not the case. Innie still needs to apply them. If enough of the tree is present, then the issue is easy to fix. On the other hand, the indicators don't tell the whole story. It's possible for a device (often behind multiple bridges) to still appear afterwards. This is where we need to resort to heuristics, such as delays and iterations through the I/O Registry, being careful not to impact the boot process...
 
cdf said:
Right. So there are two indicators that Innie uses: "IOPCIConfigured" and "IOPCIResourced". The assumption is that if the "built-in" property is set before the rest of the tree is ready, then the corresponding internal properties are automatically applied, but this is clearly not the case. Innie still needs to apply them. If enough of the tree is present, then the issue is easy to fix. On the other hand, the indicators don't tell the whole story. It's possible for a device (often behind multiple bridges) to still appear afterwards. This is where we need to resort to heuristics, such as delays and iterations through the I/O Registry, being careful not to impact the boot process...
Click to expand...
That's an effin amount of work for something that would seem so simple...
 
cdf said:
Right. So there are two indicators that Innie uses: "IOPCIConfigured" and "IOPCIResourced". The assumption is that if the "built-in" property is set before the rest of the tree is ready, then the corresponding internal properties are automatically applied, but this is clearly not the case. Innie still needs to apply them. If enough of the tree is present, then the issue is easy to fix. On the other hand, the indicators don't tell the whole story. It's possible for a device (often behind multiple bridges) to still appear afterwards. This is where we need to resort to heuristics, such as delays and iterations through the I/O Registry, being careful not to impact the boot process...
Click to expand...

(I haven't read this whole thread, so my apologies if this has already been discussed, or you've already found this to be unworkable.) Mightn't you save some aggravation by using a narrower IOResourceMatch/IONameMatch/IOPropertyMatch in Info.plist to defer loading the kext until your desired scenario arises? It seems like the IOPCIConfigured and IOPCIResourced properties could be picked up with IOPropertyMatch, and you might not need to wait at all (just walk the subtree when loaded). You could probably even put multiple matching scenarios in the same Info.plist, or narrow the scope to just the actual PCI drives you're targeting (I haven't looked to see if that's reasonable) - basically, let IOKit do the heavy lifting for you.
 
Syncretic said:
(I haven't read this whole thread, so my apologies if this has already been discussed, or you've already found this to be unworkable.) Mightn't you save some aggravation by using a narrower IOResourceMatch/IONameMatch/IOPropertyMatch in Info.plist to defer loading the kext until your desired scenario arises? It seems like the IOPCIConfigured and IOPCIResourced properties could be picked up with IOPropertyMatch, and you might not need to wait at all (just walk the subtree when loaded). You could probably even put multiple matching scenarios in the same Info.plist, or narrow the scope to just the actual PCI drives you're targeting (I haven't looked to see if that's reasonable) - basically, let IOKit do the heavy lifting for you.
Click to expand...
Thanks for this! I think that relying more on IOKit is indeed the right approach, though given my current code, it might be easier to use IOServiceMatching than changing the driver personality. I'll have to experiment.
 
I know I'm very late chiming in here, but I recently got hold of a 12-core Mac Pro 5,1 for the right money and decided to go the NVME route (Flexx LX400 Pro SSD 512GB - card and ssd sold together). Followed the info to the letter and it worked right away - now my boot drive. It's showing as internal in all the right places. Just a couple of days in but all seems well. Just to say thanks for this. Great work.
 
  • Like
Reactions: hwojtek
Sorry haven't read the whole thread but is there a script somewhere that will work with the cMP Mac Pro 2019?
 
kings79 said:
BUMP

Is the INNIE fix working with the new Mac Pro (2019)?
Click to expand...
You can try it. As long as the SSD is not connected through a pci-bridge (check with ioregistry) it should work. If it is, you might need an SSDT. I 've been monkeying recently with MP7,1 SSDT and it is a pain in the neck.
 
startergo said:
You can try it. As long as the SSD is not connected through a pci-bridge (check with ioregistry) it should work. If it is, you might need an SSDT. I 've been monkeying recently with MP7,1 SSDT and it is a pain in the neck.
Click to expand...
SO you've never tried it?
 
TzunamiOSX said:
I have a M1 with an external TB-Drive. System is Big Sur. Does Innie convert the external icons to internal?
Click to expand...
Innie hasn’t been tested with M1 systems. Besides, TB drives should probably be considered external…
 
I have tried Innie on a Mac Pro 5,1 / Mojave with an Apple AHCI Blade and it worked.

Tested Hibernatemode 25 - and it worked since Innie got the blade shown as internal.

#11

but that was just a test for my main machine. This did not set my NVME Blade as internal, so Hibernatemode 25 did not worked

Code: 
kextstat | grep Innie

   16    0 0xffffff7f80f0d000 0x2000     0x2000     com.cdf.Innie (1.3.0) DAF7FB11-5303-3B26-BE94-45F4BB79D3CE <5 3>

so I think it loaded

my NVME is a very common Samsung SSD 970 EVO Plus

is there a chance to get it in Innie?
 
I have a Mac Pro 5.1 and had Mac OS Big Sur with NVMe M.2 as a boot drive that was detected as an external drive. After I installed Innie.kext and it changed back to internal. Recently upgraded to Monterey and it changed back to an external drive. I've tried to re-install the Innie.kext twice but was still unable to change it back. Any suggestion?

*update on Jan 6

I found the problem and fixed it. Innie.kext works fine now.

Thanks (Unable to delete this post)
 
Last edited:
macuser_007 said:
I have a Mac Pro 5.1 and had Mac OS Big Sur with NVMe M.2 as a boot drive that was detected as an external drive. After I installed Innie.kext and it changed back to internal. Recently upgraded to Monterey and it changed back to an external drive. I've tried to re-install the Innie.kext twice but was still unable to change it back. Any suggestion?

*update on Jan 6

I found the problem and fixed it. Innie.kext works fine now.

Thanks (Unable to delete this post)
Click to expand...
I have a Mac Pro 5.1 with Monterey using OCLP. I successfully install Innie.kext with the instructions of post #9 but the Finder show my nvie drive as external. DiskUtility shows the disk as internal. You have this issue? and if not how you solve it? Thanks anyway!!
 
argp74 said:
I have a Mac Pro 5.1 with Monterey using OCLP. I successfully install Innie.kext with the instructions of post #9 but the Finder show my nvie drive as external. DiskUtility shows the disk as internal. You have this issue? and if not how you solve it? Thanks anyway!!
Click to expand...
It was the permission problem with the Innie.kext. I changed the owner back to 'system' with Read & Write. Not my user account with Read & Write.
 
cdf said:
If you're using OCLP, then you should really add the kext through OC.
Click to expand...
Thanks a lot .. it works!!
I thing it needs new instructions for users with OCLP. We did not need to edit config.plist to install OS, so we didn't now that new kexts you had to load from EFI.
 
argp74 said:
Thanks a lot .. it works!!
I thing it needs new instructions for users with OCLP. We did not need to edit config.plist to install OS, so we didn't now that new kexts you had to load from EFI.
Click to expand...
With OC you can enable the built-in property under devices no need for Innie. Where Innie shines is on systems without OC (booted natively) or with boot-args="-no_compat_check"
 
cdf said:
Innie has been updated to version 1.3.1. This version addresses a long-standing detection bug (many thanks to @Macschrauber for testing)!

github.com

Release 1.3.1 · cdf/Innie

v1.3.1 Improve handling of multiple pci roots Fix detection bug
github.com github.com
Click to expand...
Huge Thanks to you CDF for the Innie Project !

I installed Innie on my machine :

Mac Pro 6,1 with 3 NVME SSDs on a Amfeltec Angelshark Carrier Board - MacOS Monterey 12.6.2

Now with Innie installed the 3 SSDs are recognized as internal.

The Only Issue is :

Since I've installed Innie my booting time is 1min longer than before
My machine use to boot in about 20/30sec and now boot in 1min20/30 sec.

So is there anything I can do to fix this longer/slower booting time ?

Thanks !

Baptiste
 
Last edited:
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back