Revised LegacyAppleAHCIport.kext & LegacyJMicronATA.kext

[thorazine74]

I have troubles using both kext at the same time, so I revised the plist of both of them.

They should work together now without problems and we should be able to use all of the Intel SATA and JMicron SATA ports at the same time with all of the JMicron PATA ports. This way the AppleAHCIport will drive both Intel and JMicron SATA ports in AHCI/RAID mode and the JMicronATA will drive only the PATA ports.

 

 

 

Here are the two plist-only kext:

 

 

 

They are made to work alongside with these vanilla AppleAHCIport.kext v1.5.2 and vanilla JMicronATA.kext v1.0.0 from Leo 10.5.6:

 

EDIT: removed the vanilla kext attachments, not sure if it goes against the rules to attach them here.

In case you dont have those particular versions you can get them from Apple Combo Update I think.

 

Only tested in Leo 10.5.6, it might work on older versions but not tested by me (AppleAHCIport.kext version changed in latest update I think). I still dont understand the logic behing legacy and binary kext, so maybe if you modify versions values in the plist (so binary and legacy kext match versions) it can be adapted to previous binaries.

 

CHANGES I MADE:

- Only plist, no binary change.

- Adding controller class matching to JMicron personalities in both kexts so only AHCI driver is used for SATA ports and only ATA driver is used for PATA ports, avoiding crashes caused by using only device id matching.

- Assign AppleICH8AHCI class to all ICH8/9/10 controllers instead of generic AppleAHCI. I dont know what are the differences between those 2 classes but ICH9 and 10 are very similar to ICH8 so it feels more right to me. If anyone knows this will break something please let me know.

- Revise all of the Intel ICHx device ids and names according to Intel infs for proper identification of each controller model in AHCI and RAID mode (except the device ids already present in vanilla kext, those I havent touched, some models might still get the wrong name). This only has a aesthetical benefit.

- Add all theoretically compatible device ids to JMicron personalities. They might or might not work with the original binary, as it only supported JMB368, but it works for me withe JMB363.

 

NOTES:

- I have only tested this on my machine config (ICH9R & JMB363) so before testing it on your own make sure you know how to go back to your original setup in case something goes wrong.

- This assumes you are running both Intel ICHx and JMicron controllers in either AHCI or RAID mode, not in IDE mode. Some motherboards might not allow you to change that so check your BIOS settings and manual to be sure.

- Some motherboards have 1 internal SATA port and 1 (hardwired) eSATA port driven by the JMicron controller. Using this kext in those boards should work but it might not give you full eSATA functionality (drives might show as internal not ejectable). If someone knows how to set SATA protocol interconnection parameters on a port by port basis please modify the kext to do it that way.

- There are at least 2 other JMicronATA binary variants, the one from DarwinATA project for +2Gb RAM and the one available from JMicron's FTP site. They should work too with this kext but I havent tried those drivers.

- Some AppleViaATA.kext version include JMicron device ids too, but they might cause some conflicts if present (like making JMicron PATA devices appear as connected to the SATA bus) so I would advice removing it if you have it installed (if you dont need AppleVIAATA to drive other hardware you might have, its definitely not needed for JMicron with these 2 kext).

 

This is of course based on cyclonefr and Gujal's work.

 

UPDATE:

I split the AHCI plist in 2 so it can be installed separately for Intel & JMicron, so mobos without JMicron can install only Intel kext for example.

I think its cleaner to keep different manufacturer personalities in different kext instead of crowding one plist (or the vanilla kext plist).

I also included ICH6 device ids, it seems to be AHCI compliant too. So now includes all Intel ICH AHCI/RAID controllers ids from ICH6 to ICH10.

Also increased IOProbeScore for the JMicron in AHCI/RAID mode trying to avoid other JMicron kext from taking over the SATA controller.

 

- AppleAHCIport plist-only kext for Intel ICHx SATA ports in AHCI/RAID mode:

 

LegacyAppleAHCIPortIntelICHx.kext.zip

 

- AppleAHCIport plist-only kext for JMicron JMB36x SATA ports in AHCI/RAID mode:

 

LegacyAppleAHCIPortJMicronJMB36xSATA.kext.zip

 

- JMicronATA plist-only kext for JMicronJMB36x SATA ports in IDE-compatibility mode (& PATA ports):

 

LegacyJMicronATASATAIDEmode.kext.zip

 

Alternatively, if instead of the vanilla JMicronATA from leopard you need to use the 2Gb+ memory fixed version from darwinata here its v0.6 of that kext with plist fixed to work with the SATA controller in AHCI mode:

JMicronATA.kext.darwinata.v0.6.PlistFix.IDE_mode_only.zip

 

If there is some mistake or I missed/mistaked some device ids please report and I'll try to fix it.

 

Also, according to this Linux SATA driver status report it seems some newer ATI, NVIDIA, SiS, ULi and VIA chipsets are AHCI compliant. If you have such chipset and have a BIOS option to switch the controller to AHCI/RAID you might try using it with AppleAHCI kext. The vanilla kext has a generic personality for any AHCI controller class so it should pick it up if there is no other driver taking over it.

[HaTaX]

Okay, so I've gone around and around on this bus and am going to post my findings here in hopes someone sees something I'm missing.

 

I've got an ABit IP35-Pro motherboard:

http://www.abit.com.tw/page/en/motherboard...p;fMTYPE=LGA775

 

This motherboard has both the Intel ICH9R and the JMicron 363 controller on it, however currently I am only using the JMicron controller. The reason for this is I have my everyday OS installed on the Intel controller and I have 2 different bios profiles for booting my trustworthy trouble free OS, and then my other OSes on an external HD. So I flip profiles, that shuts down the Intel controller completely to hide those drives from the other OSes, I flip on the power to my external HD and away I go on my quad boot setup. The JMicron on my board is used to control the 2 eSATA ports and the IDE channel just as a FYI. I'm not too concerned about the eSATA functionality, but would be happy just to boot again with AHCI mode enabled.

 

Previously to this I had installed iATKOS v4.1 which worked with the JMicron IDE DVD drive I had fine, other distros required me to install from a SATA DVD drive and then once it was installed the JMicron driver worked fine and I was able to shut down the Intel controller again. When I used the iATKOS v4.1 I just made sure the JMicron controller was set to IDE and not AHCI, if AHCI was selected I'd have problems with the HD and long periods of no response from the installer.

 

Now I've installed iATKOS v5 and updated to 10.5.6 via the combo update, no troubles with anything else except that if I try to put the JMicron controller in AHCI mode now I cannot get it to boot normally. I either get a KP, IO read errors at boot and then a reboot, or the device isn't recognized.

 

I follow what you're trying to do with the above steps, but it seems on my system it's not matching the class identifier or it just latches on to the first one and applies the driver to both device instances. But if I change the class mask so that it doesn't match any more, the kext doesn't load so I know the mask is working.

 

Here's what I've tried:

AppleAHCIPort.kext - Tried the modified version available here and the version offered in the 4GB mem issue thread

JMicronATA.kext - Both 1.0 and the newer version from their FTP site, with the helper kext and many other variations

AppleVIAATA.kext - Tried removing it and modifying the kext so it is only loaded with class ids matching IDE (0101)

IOAHCIFamily.kext - Doesn't seem to matter much, but used the fixes from the 4GB mem issue thread

 

No matter what I seem to try to modify, when I switch AHCI mode on, only one driver gets loaded for both instances and I get either a kernel panic (Perhaps they're trying to load seperate drivers here, I can't tell for sure), or the loading starts and then I can either hear the HD power down and back up while the screen fills with IORead Errors.

 

I'm attaching a few files, they are:

AHCI_DVD_JMICRON_STARTUP.TXT

This is the startup.log from the iATKOS v5 DVD with the JMicron controller in AHCI mode.

NOTE: The HD does NOT behave properly in this mode, the HD will respond for a few seconds, then pause for 15-20.

IDE_DVD_JMICRON_STARTUP.txt

This is the startup.log from the iATKOS v5 DVD with the JMicron controller in IDE mode, everything works fine.

IOREG-inosx-IDEMode.txt

This is the output from "ioreg -l" in OSX with the JMicron controller in IDE mode. (Only way I can boot OSX)

lspci-ubuntu.txt

This is the output from lspci in Ubuntu 8.10 with the JMicron controller in AHCI mode. (Everything works perfectly)

I am unsure of how to get similar "ioreg" output from Ubuntu to help troubleshoot the device and class ids, but the lspci information has everything that's needed to get that data so I hope that's enough for people to look at.

 

Is there a way I can get "ioreg" to run from within Terminal on the installer DVD? I noticed I have to do a little work even to get nano to work in that environment (fill the TERMINFO variable), but am not sure what all I would need to get ioreg to function. Everytime I goto a folder containing it, says something about no path or method available when I try to launch it.

 

Anyone have any pointers for me with this?

 

Also, I've been meaning to ask, in your second screenshot you're using a utility... What is the name of that utility?!

AHCI_DVD_JMICRON_STARTUP.TXT

IDE_DVD_JMICRON_STARTUP.txt

IOREG_inosx_IDEMode.txt

lspci_ubuntu.txt

[HaTaX]

Did some more digging on this and found something odd... Even with the same match strings in the AppleAHCIPort.kext as your LegacyAppleAHCIPort.kext, it will not engage on the eSATA ports... I've tried to use your LegacyAppleAHCIPort.kext, but I get an error at bootup, I've included a picture of the screen at boot.

 

Good news is, it looks like the JMicronATA driver is only trying to take the IDE ports, bad news is, it can't load the LegacyAppleAHCIPort.kext and either stalls there or starts getting read errors as well. I find it strange if I remove the LegacyAppleAHCIPort.kext file that the AppleAHCIPort.kext, with the same match strings, doesn't appear in the startup at all.

 

The startup screen was taken with the options "-v -f debug=0x100"

[thorazine74]

Looking at the last log it seems the Legacy Extension doesnt find the necessary dependencies to be loaded but if you have the vanilla AppleAHCIport plus the extensions that one needs that should not happen.

If you are running iAtkos 5 I think the problem could be that you have duplicated extensions in ExtraExtensions and SystemsLibraryExtensions, I think iAtkos installs some (or maybe all?) extensions you pick during setup in ExtraExtensions with version 9.9.9.

I'm not sure but I think that has an effect on loading Legacy kext-only extensions, maybe because it cant find the binaries referenced in the plist or maybe because of the diferent versions (iAtkos extension in Extra have version 9.9.9 to override extensions with same name in SystemLibraryExtensions, maybe that prevents the legacy extension to load too).

I would advise to check the ExtraExtensions folder (and/or the extensions.mkext cache in that folder) and make sure you are running all the AHCI related extensions from the same folder. It should work on either place but for me it definitely works from SystemLibraryExtensions.

[HaTaX]

Here's what I've got in my /Extra folder:

 bash-3.2# find /Extra/
/Extra/
/Extra//Extensions
/Extra//Extensions/AppleACPIPlatform.kext
/Extra//Extensions/AppleACPIPlatform.kext/Contents
/Extra//Extensions/AppleACPIPlatform.kext/Contents/Info.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/MacOS
/Extra//Extensions/AppleACPIPlatform.kext/Contents/MacOS/AppleACPIPlatform
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIButtons.kext
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIButtons.kext/Contents
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIButtons.kext/Contents/Info.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIButtons.kext/Contents/MacOS
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIButtons.kext/Contents/MacOS/AppleACPIButtons
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIButtons.kext/Contents/version.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIEC.kext
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIEC.kext/Contents
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIEC.kext/Contents/Info.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIEC.kext/Contents/MacOS
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIEC.kext/Contents/MacOS/AppleACPIEC
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIEC.kext/Contents/version.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPILPC.kext
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPILPC.kext/Contents
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPILPC.kext/Contents/Info.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPILPC.kext/Contents/MacOS
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPILPC.kext/Contents/MacOS/AppleACPILPC
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPILPC.kext/Contents/version.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPCI.kext
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPCI.kext/Contents
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPCI.kext/Contents/Info.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPCI.kext/Contents/MacOS
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPCI.kext/Contents/MacOS/AppleACPIPCI
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPCI.kext/Contents/version.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPowerSource.kext
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPowerSource.kext/Contents
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPowerSource.kext/Contents/Info.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPowerSource.kext/Contents/MacOS
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPowerSource.kext/Contents/MacOS/AppleACPIPowerSource
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/AppleACPIPowerSource.kext/Contents/version.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/ApplePCIConfigurator.kext
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/ApplePCIConfigurator.kext/Contents
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/ApplePCIConfigurator.kext/Contents/Info.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/ApplePCIConfigurator.kext/Contents/MacOS
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/ApplePCIConfigurator.kext/Contents/MacOS/ApplePCIConfigurator
/Extra//Extensions/AppleACPIPlatform.kext/Contents/PlugIns/ApplePCIConfigurator.kext/Contents/version.plist
/Extra//Extensions/AppleACPIPlatform.kext/Contents/Resources
/Extra//Extensions/AppleACPIPlatform.kext/Contents/Resources/English.lproj
/Extra//Extensions/AppleACPIPlatform.kext/Contents/Resources/English.lproj/InfoPlist.strings
/Extra//Extensions/AppleACPIPlatform.kext/Contents/version.plist
/Extra//Extensions/AppleDecrypt.kext
/Extra//Extensions/AppleDecrypt.kext/Contents
/Extra//Extensions/AppleDecrypt.kext/Contents/Info.plist
/Extra//Extensions/AppleDecrypt.kext/Contents/MacOS
/Extra//Extensions/AppleDecrypt.kext/Contents/MacOS/AppleDecrypt
/Extra//Extensions/AppleDecrypt.kext/Contents/Resources
/Extra//Extensions/AppleDecrypt.kext/Contents/Resources/English.lproj
/Extra//Extensions/AppleDecrypt.kext/Contents/Resources/English.lproj/InfoPlist.strings
/Extra//Extensions/Disabler.kext
/Extra//Extensions/Disabler.kext/Contents
/Extra//Extensions/Disabler.kext/Contents/Info.plist
/Extra//Extensions/Disabler.kext/Contents/MacOS
/Extra//Extensions/Disabler.kext/Contents/MacOS/Disabler
/Extra//Extensions.mkext

 

And here is what's in my /Extra/Extensions.mkext:

drwxr-xr-x  3 root  wheel  102 Jan 18 13:07 AppleACPIButtons.kext
drwxr-xr-x  3 root  wheel  102 Jan 18 13:07 AppleACPIEC.kext
drwxr-xr-x  3 root  wheel  102 Jan 18 13:07 AppleACPILPC.kext
drwxr-xr-x  3 root  wheel  102 Jan 18 13:07 AppleACPIPCI.kext
drwxr-xr-x  3 root  wheel  102 Jan 18 13:07 AppleACPIPlatform.kext
drwxr-xr-x  3 root  wheel  102 Jan 18 13:07 AppleACPIPowerSource.kext
drwxr-xr-x  3 root  wheel  102 Jan 18 13:07 AppleDecrypt.kext
drwxr-xr-x  3 root  wheel  102 Jan 18 13:07 ApplePCIConfigurator.kext
drwxr-xr-x  3 root  wheel  102 Jan 18 13:07 Disabler.kext

 

Are the ApplePCIConfigurator and AppleACPIPCI kexts part of the AHCI loading? If so, that could be where the problem is coming from.

 

I'm using the Vanilla AppleAHCIPort.kext file with a few modifications to it to match the device and class id of the JMicron controller, I'll attach the AppleAHCIPort.kext file currently being used with this post.

AppleAHCIPort.kext.zip

[thorazine74]

That seems right to me, I dont think any of those extensions you have in Extra are required for AppleAHCI.

It seems you already have the right device ids and class match rules in AppleAHCIport.kext, so you dont need to add the legacy kext, it would be redundant I think.

Have you tried that AppleAHCIport plus the vanilla JMicron 1.0 from Leopard plus the Legacy JMicron Kext I posted?

Or try increasing the IOProbeScore of the JMicronAHCI personality to override other drivers.

Or to be sure there is no JMicron (or ViaATA) taking over the the JMicron try removing those kexts and keep just the AppleAHCIport, that way you can know for sure if the AHCI kext works with the JMicron or not, without anything else taking over.

[HaTaX]

Here is a picture of the JMicron driver trying to take over all ports, and what it looks like when the AppleAHCIPort.kext kind of loads. I can tell it's loading in some fashion because it attempts to start up the system and starts tripping over IO errors, those errors eventually cause it to reboot, but when the drive isn't detected by any kext I just get the "waiting for root device" over and over. If you look in the LegacyAppleAHCIPort picture you can see the read errors at the bottom.

 

I think I'm getting these read errors because the AppleAHCIPort.kext file doesn't know what to do with my eSATA ports or is not communicating with them correctly. Wish I would have saved the kexts I used before I moved to iATKOS v5.... I have modified the JMicron 1.0 info.plist so that it matches my hardware so I don't need the legacy kext, and the legacy kext you provided didn't load so I modified the vanilla version myself to match class and device id.

 

I really think it boils down to the AppleAHCIPort.kext not liking my eSATA ports on the JM363, wonder what can be done about that if in fact that's what's going on here.

 

Also wanted to add, I noticed on the Ubuntu boot it not only recognizes that there are two separate devices for AHCI on the eSATA ports and IDE on the PATA port, it recognizes them on different IRQs. Ubuntu shows IRQ 16 & 17 being used while I am guessing that OSX is only showing the primary and secondary ports on the JMicronATA as being IRQ 17, not sure what the AppleAHCIPort driver is using for an interrupt.

 

Just something I noticed, could be important, could mean nothing.

[thorazine74]

I think you have a bit messed up system there...

In those last pictures it looks like the JMicronATA is still being loaded for both SATA and PATA controllers. All those controller messages must come from it and not from AHCIport which is completely silent in the log in my system

My only suggestion is either what I said above about removing JMicronATA.kext completely to avoid it completely or start from scratch with the just vanilla kexts and the legacy ones I posted.

[HaTaX]

Yes the AppleAHCIPort is completely silent on my system which makes things a little harder. The screenshot of the JMicron driver trying to take over all the ports is with the JMicron driver as it sits with no class id filters. The latest version I believe does have those filters, but that screenshot was more to show what happens if it DOES try to take over the eSATA ports.

 

If I remove the PATA device I cannot get OSX to load with just the hard drive connected to eSATA and the controller in AHCI mode. It seems no matter what I do, if I enable AHCI mode and get a kext to load, it isn't able to communicate with the controller properly. Every time it appears a kext does attach to the eSATA controller in AHCI mode that the screen starts to fill with IO read errors and I can never get to the desktop. Normally once I start seeing those it's about 2-5 minutes of the OS trying to boot and then it just restarts.

 

I've been digging on here for threads on eSATA ports based on the JMicron controller but haven't had any luck. I would expect to be able to boot from this port at least if I completely remove the PATA from the picture, but that doesn't seem to be the case... Looks like none of the kexts know how to communicate properly with the eSATA ports on my controller.

[thorazine74]

I suggested removing the jmicron kext, not the pata device.

[HaTaX]

Okay, I tried removing the JMicron kext, and rebooted, then the AppleVIAATA kext attached to it and it booted up fine. I removed the AppleVIAATA kext and upon reboot it sat at waiting for root device. I then went into the bios and enabled AHCI mode, upon boot it finds the HD, but the screen starts to fill with the IO read errors and eventually I get a reboot.

 

To get it back to life I just booted off the CD and restored the JMicron kext from a backup location, and then went from AHCI to IDE.

 

Wonder why this driver worked fine with 10.5.2-4 and now with 10.5.5-6 I'm having issues?

[thorazine74]

Well I got no more clues then.

Just for testing I unplugged the hard drive from the ICH port and plugged it to the JMicron using a eSATA bracket and it booted up without any troubles. Granted is not a real eSATA device but it booted the same as it was plugged on the ICH ports.

So your trouble could be:

- Your system extensions are messed up somehow. Starting with a clean installation might fix it.

- The eSATA ports on your mobo are somehow different. It could be but I seriously doubt it, from what I know eSATA mostly differs to SATA in plugs, signaling and cabling, I dont think the controller cares where and how the device is plugged.

- Your hard disk could be incompatible with Mac eSATA. I've read some reports that certain USB/1394/eSATA HD or enclosures have buggy bridge chipsets that dont get along well with Mac in eSATA mode. I got no clue which ones though.

[HaTaX]

The eSATA ports on my controller might very well be "unique", I noticed on their FTP they have two drivers listed for WinXP/Vista use:

ftp://driver.jmicron.com.tw/jmb36x/Win2k_xp_Vista/

 

They have one for the controller, and then a special version for the eSATA version of their controller. I'm not sure what the differences are between the two as I haven't looked in depth, and windows doesn't seem to need their provided drivers to work correctly.

 

I think I'm going to dig up my old iATKOS v4.1 disc and see if the hard drive is readable after booting from the DVD in AHCI mode. It's odd because I can start the install DVD in AHCI mode, but it still gives read errors and keeps spinning down the drive (Almost as if it's a sleep mode) and generally doesn't get very far. I believe before I was able to load the iATKOS v4.1i DVD with the controller in IDE or AHCI mode and it worked just fine.

 

I'm thinking there's a new extension in here or something that's causing some issues with the AHCI side of things, just wish I knew how to get under the hood a little further and see if I could get some more verbose information on what's happening with the kexts/drivers and what information they're NOT telling me now.

[HaTaX]

Hah! Got it figured out... And it was the DUMBEST of things to overlook. I moved the external HD to the other eSATA connection (There are two, it was on bottom one).. And it fired right up without any IO read errors!!!!

 

I'm attaching my lspci and ioreg outputs if for nothing else to have them somewhere so I can look at them if need be in the future.

 

Drives are orange, and that's fine with me, but I'd like to tweak the section that sees it as removeable. (It's in the ioreg report)

 

Thanks again for your patience!!

ioreg.txt

lspci.txt

[Bit Shoveler]

Nice work thorazine74.

 

Mods, please sticky this thread!

[Bit Shoveler]

I got home and looked at the plist... did you realize you've preserved the original Apple misspelling "CFBundeIdentifier" in the GenericAHCI dict? I guess no one but me has had the courage to try correcting it!

 

Seriously though, good work, I will probably switch to yours instead of my home-grown version.

[thorazine74]

Thanks, I cant believe there is a typo in original Apple vanilla plist. I just copy and paste the generic ahci, I think it still works with that mistake or maybe not? I remember seeing some generic AHCI controller but not sure if it was with this version. I guess its better to fix it right?

 

I did a little google searching and it seems there is many more south bridges that declare to be AHCI-compliant nowadays, here its the list I could compile from various sources (mainly linux drivers):

 

- NVIDIA: MCP65 (nForce 560?), MCP67 (nForce 610/630a?), MCP73 (nForce 610i/630i), MCP77, MCP79, MCP7B [not sure awhat are the right nForce names for the MCP code-names...]

- AMD: SB600, SB700, SB750, SB800

- VIA: VT8251

- SIS: 966, 968

- ULI: M1573, M1575, M1697, M5288

- MARVELL: 88SE6121, 88SE6145

- PROMISE: PDC42819

Also some Silicon Image SteelVine series support AHCI but not sure which chipsets are...

 

It could be interesting to test if any of this chipsets work with the ahci driver supplied by Apple. I've read some of them have various quirks that prevents them to work with a pure ahci driver (in Linux) without patches but others seem to be pretty standard, nobody tried to run any of those in AHCI or RAID mode with the AppleAHCIport? If they work with the AHCI driver it should be much better than using AppleViaATA or similar things.

Best candidates could be the nForce chipsets as the vanilla driver already supports MCP79...

If we find out some of those work without troubles or data corruption we could add the ids to the AHCI driver.

[CJP2]

I've had great success with your "AppleAHCIport plist-only kext for Intel ICHx SATA ports in AHCI/RAID mode" kext on my board. I've been running experiments the last few days with various methods of doing a vanilla install and have perfect results with the grub-dfe.iso. I have multiple drives and partitions to play with what might work (and how it might work with other things ) with the minimum of tampering with the install. Previously I'd been trying several home brewed combinations and the ICH9 folder (4 kexts) download via OSX86Tools.

 

Only thing - in System Profiler it's identified as "ICH9R/ICH9DO/ICH9DH AHCI". Is it possible to merely change this line in the info.plist to "ICH9R AHCI"? Just visually it would seem more "vanilla" to me.

 

Unfortunately I'm also working with a Marvell 88SE6101 ATA controller that I've only had success with AppleVIAATA.kext. Any chance you can come up with a equally great replacement for that?

 

Also, I can confirm that this works in 10.5.5 as well on my machine.

 

Thanks for the great work.

 

Edit: I think I've found a good solution to my ATA problem here.

[thorazine74]

I cant change the chipset name to show each ich9 variation because the 3 of them have the same device id. That's only for display, you can edit that string in the plist if you wish.

 

Is that marvell ata only? If its so it wont work with the ahci driver I'm afraid...

If you want a plist only kext for the dfe iso for the marvell you cant use appleviaata for it because that kext doesnt exist in the retail dvd I think.

[CJP2]

Thanks for the quick response.

 

The Marvell controller is ATA only:

IDE interface [0101]: Marvell Technology Group Ltd. 88SE6101 single-port PATA133 interface [11ab:6101] (rev b2)

 

It's working perfectly with AppleVIAATA.kext: v0.2 from slashhack I'm only using your LegacyAppleAHCIPortIntelICHx.kext for AHCI recognition. It'll be a few days before I can test this in 10.5.6 but I'll edit the string to fix my little System Profiler report.

 

I'll post back here with results but so far it's running far smoother with everything vanilla but the above 2 kexts and OpenHaltRestart.kext.

[walterav]

I have troubles using both kext at the same time, so I revised the plist of both of

them.http://www.insanelymac.com/forum/style_images/insane2/folder_editor_images/rte-align-center.png

They should work together now without problems and we should be able to use all of the Intel SATA and JMicron SATA ports at the same time with all of the JMicron PATA ports. This way the AppleAHCIport will drive both Intel and JMicron SATA ports in AHCI/RAID mode and the JMicronATA will drive only the PATA ports.

 

 

 

Here are the two plist-only kext:

 

 

 

They are made to work alongside with these vanilla AppleAHCIport.kext v1.5.2 and vanilla JMicronATA.kext v1.0.0 from Leo 10.5.6:

 

EDIT: removed the vanilla kext attachments, not sure if it goes against the rules to attach them here.

In case you dont have those particular versions you can get them from Apple Combo Update I think.

 

Only tested in Leo 10.5.6, it might work on older versions but not tested by me (AppleAHCIport.kext version changed in latest update I think). I still dont understand the logic behing legacy and binary kext, so maybe if you modify versions values in the plist (so binary and legacy kext match versions) it can be adapted to previous binaries.

 

CHANGES I MADE:

- Only plist, no binary change.

- Adding controller class matching to JMicron personalities in both kexts so only AHCI driver is used for SATA ports and only ATA driver is used for PATA ports, avoiding crashes caused by using only device id matching.

- Assign AppleICH8AHCI class to all ICH8/9/10 controllers instead of generic AppleAHCI. I dont know what are the differences between those 2 classes but ICH9 and 10 are very similar to ICH8 so it feels more right to me. If anyone knows this will break something please let me know.

- Revise all of the Intel ICHx device ids and names according to Intel infs for proper identification of each controller model in AHCI and RAID mode (except the device ids already present in vanilla kext, those I havent touched, some models might still get the wrong name). This only has a aesthetical benefit.

- Add all theoretically compatible device ids to JMicron personalities. They might or might not work with the original binary, as it only supported JMB368, but it works for me withe JMB363.

 

NOTES:

- I have only tested this on my machine config (ICH9R & JMB363) so before testing it on your own make sure you know how to go back to your original setup in case something goes wrong.

- This assumes you are running both Intel ICHx and JMicron controllers in either AHCI or RAID mode, not in IDE mode. Some motherboards might not allow you to change that so check your BIOS settings and manual to be sure.

- Some motherboards have 1 internal SATA port and 1 (hardwired) eSATA port driven by the JMicron controller. Using this kext in those boards should work but it might not give you full eSATA functionality (drives might show as internal not ejectable). If someone knows how to set SATA protocol interconnection parameters on a port by port basis please modify the kext to do it that way.

- There are at least 2 other JMicronATA binary variants, the one from DarwinATA project for +2Gb RAM and the one available from JMicron's FTP site. They should work too with this kext but I havent tried those drivers.

- Some AppleViaATA.kext version include JMicron device ids too, but they might cause some conflicts if present (like making JMicron PATA devices appear as connected to the SATA bus) so I would advice removing it if you have it installed (if you dont need AppleVIAATA to drive other hardware you might have, its definitely not needed for JMicron with these 2 kext).

 

This is of course based on cyclonefr and Gujal's work.

 

UPDATE:

I split the AHCI plist in 2 so it can be installed separately for Intel & JMicron, so mobos without JMicron can install only Intel kext for example.

I think its cleaner to keep different manufacturer personalities in different kext instead of crowding one plist (or the vanilla kext plist).

I also included ICH6 device ids, it seems to be AHCI compliant too. So now includes all Intel ICH AHCI/RAID controllers ids from ICH6 to ICH10.

Also increased IOProbeScore for the JMicron in AHCI/RAID mode trying to avoid other JMicron kext from taking over the SATA controller.

 

- AppleAHCIport plist-only kext for Intel ICHx SATA ports in AHCI/RAID mode:

 

LegacyAppleAHCIPortIntelICHx.kext.zip

 

- AppleAHCIport plist-only kext for JMicron JMB36x SATA ports in AHCI/RAID mode:

 

LegacyAppleAHCIPortJMicronJMB36xSATA.kext.zip

 

- JMicronATA plist-only kext for JMicronJMB36x SATA ports in IDE-compatibility mode (& PATA ports):

 

LegacyJMicronATASATAIDEmode.kext.zip

 

Alternatively, if instead of the vanilla JMicronATA from leopard you need to use the 2Gb+ memory fixed version from darwinata here its v0.6 of that kext with plist fixed to work with the SATA controller in AHCI mode:

JMicronATA.kext.darwinata.v0.6.PlistFix.IDE_mode_only.zip

 

If there is some mistake or I missed/mistaked some device ids please report and I'll try to fix it.

 

Also, according to this Linux SATA driver status report it seems some newer ATI, NVIDIA, SiS, ULi and VIA chipsets are AHCI compliant. If you have such chipset and have a BIOS option to switch the controller to AHCI/RAID you might try using it with AppleAHCI kext. The vanilla kext has a generic personality for any AHCI controller class so it should pick it up if there is no other driver taking over it.

 

 

Hi, you split up the legacy kext, one for intel one for jmicron:

Does this mean that the disks on intel ahci ports can look as internal, and the jmicron esata disks can look as external at the same time?

[thorazine74]

I dont know if that's posible, because the current SATA external icons fix does not change this kext, but the IOAHCIBlockStorage.kext, which is loaded for all AHCI-connected disks no matter which controller they are connected to.

Maybe it could be posible to change the icons for a certain controller but I dont know of any way to change the ejectable/not ejectable property for Intel and JMicron separately.

Well for me neither the orange icons, neither the orange icons nor the Eject menu bother me.

I guess you are trying to make Intel ports look internal and JMicron external, right?

[HaTaX]

I had success with loading my JMicron drives as eSATA, in fact that was the only thing that made my system stable and resolved the 30 second HD pauses I would see now and again.

 

Here's the post I made with changes I made to have the ports recognized as eSATA:

http://www.insanelymac.com/forum/index.php...=149308&hl=

 

Hopefully this helps you guys out in here, it just seems we don't have a "template" plist to go off of that supports eSATA drives so I had to come up with this from strings that could be returned when running IOREG. Seems it was the fix I was looking for as I did test removing the "ESATA" section from the plist and once again I could not mount and dismount my 1TB drive, and I got 30 second pauses again.

 

Nice updates to the OP thorazine!

[westwaerts]

I have the LegacyAHCIPort.kext and the LegacyJMicronSATA.kext in my Extra Folder, wrote an mkext ( only that is loaded here, so its not enough just to put them there with permissions repaired)

 

and i have the same dependecy errors in the system log, but they work.

in sysprofil the formerly Unknown AHCI is now Intel ICH8 AHCI.

[thorazine74]

I think the dependency errors will appear in that case because it only looks for the dependencies inside the current directory/extensions.mkext.

I just tried to remove the IOAHCI and IOPCI family dependencies entries from the plist and it seems to work the same way, maybe we dont need to put any dependencies in the plist-only kext, as the binary-kext will already load all the needed dependencies first.

 

<key>OSBundleLibraries</key>

<dict>

<key>com.apple.iokit.IOAHCIFamily</key>

<string>1.0.0</string>

<key>com.apple.iokit.IOPCIFamily</key>

<string>1.0.0</string>

<key>com.apple.kpi.bsd</key>

<string>8.0.0</string>

<key>com.apple.kpi.iokit</key>

<string>8.0.0</string>

<key>com.apple.kpi.libkern</key>

<string>8.0.0</string>

<key>com.apple.kpi.mach</key>

<string>8.0.0</string>

</dict>