Jump to content

AppleIntelPIIXATA kext fully working for all ICHx Mobo (All Sata Channels working)


-DuNe-
 Share

418 posts in this topic

Recommended Posts

So far the testing on Tiger/IP35-E isn't going well. I keep running into a problem where my SATA drive won't boot anymore, and I have to reinstall OSX. I also added 8GB of memory. So far Tiger has locked up everytime the used memory reaches 3.25GB.

 

I installed Leopard on a USB drive, so I will try out the Leopard version of the kext and let everone know if it works.

 

Update: Leopard (10.5.1) with this kext detects drives on SATA1 SATA2 and SATA6, so that looks like it is working. I ran a memory test though, and Leopard locked up too. Leopard will reboot after locking up, so I am not sure what is happening to Tiger. The only thing I had to install in Leopard was AppleHDA patcher for the audio, and I am just using VESA mode for the X800GTO for now. Leopard seems to boot very fast, except booting from the Kalyway installation disk is very slow.

 

I plan to run Memtest on the memory just to make sure the memory itself is okay. (I miss my TForce motherboard that had Memtest in the BIOS.)

Link to comment
Share on other sites

I plan to run Memtest on the memory just to make sure the memory itself is okay. (I miss my TForce motherboard that had Memtest in the BIOS.)

 

hmm, do you have a memory remap options in your bios. if not enabled , do it and vice versa. look too if you are not using JmicronATA. it is known that it has the same problems with memory barrier than AppleViaata.

 

i reinstalled Tiger to do its ApplePIIXATA version and have not problems at all, but i have only 2go of memory so i can not say if it works well with more than 3go. if it is the case, blame apple cos it would say that the original Tiger kext has the problem too.

Link to comment
Share on other sites

hmm, do you have a memory remap options in your bios. if not enabled , do it and vice versa. look too if you are not using JmicronATA. it is known that it has the same problems with memory barrier than AppleViaata.

No memory remap BIOS option on the IP35-E, as far as I can tell.

 

Memtest86+ v2.01 hasn't found any problems with the memory (seems to work in 2GB segments=PAE mode?), so it looks like all 8GB are useable.

 

Yes, I deleted AppleVIAATA.kext on both Tiger and Leopard. Neither appears to have anything JMicron (though I notice the JMicron attached drives do show up in the Kalyway installer.) I actually disabled the JMicron controller in the BIOS. Some other kext might be causing the issue.

 

Update: there was a JMicronATA.kext in Leopard, so I deleted that too, but the JMicron attached drives are still showing up--makes me think I need to do something to rebuild the kext cache or whatever. Using -v mode it shows JMicronATA and AppleVIAATA still showing up. How do I get rid of these?

Link to comment
Share on other sites

Update: there was a JMicronATA.kext in Leopard, so I deleted that too, but the JMicron attached drives are still showing up--makes me think I need to do something to rebuild the kext cache or whatever. Using -v mode it shows JMicronATA and AppleVIAATA still showing up. How do I get rid of these?

did you delete Extensions.mkext ?

Link to comment
Share on other sites

This is awsome !! You rock bro !! :censored2:)

With your new kext , my Leopard recognized my DVD Recorder , even I was not able to read any CD / DVD.

My notebook with 4 GB of RAM works with all IDE SATA channels functional !!!!!!!

YaaaaY :)

Link to comment
Share on other sites

did you delete Extensions.mkext ?

Yes, but it seems to reappear pretty much immediately.

 

Disabling the JMicron in the BIOS means it does not show up during a -v boot, but the AppleVIAATA Driver is still showing up (both kexts were deleted).

 

Also, I commented about Leopard booting faster, but I realize that I decided to not use Journalling on that drive (Is this feature worth it?)

Link to comment
Share on other sites

SOLVED

 

Mar 2 17:51:25 Mac-Pro kernel[0]: IOATAController device blocking bus.

Mar 2 17:51:51: --- last message repeated 2 times ---

Mar 2 17:51:51 Mac-Pro kernel[0]: IOSCSIPeripheralDeviceType05::setPowerState(0x3b6e500, 0 -> 4) timed out after 100708 ms

Mar 2 17:51:59 Mac-Pro kernel[0]: IOATAController device blocking bus.

Mar 2 17:53:14 Mac-Pro kernel[0]: IOATAController device blocking bus.

Mar 2 17:53:36: --- last message repeated 2 times ---

 

flashed Firmware of DVD-Drive to newer version. error seems to be gone.

Link to comment
Share on other sites

did you delete Extensions.mkext ?

Somehow, the JMicron and AppleVIAATA kexts were still in my Jaguar System/Library folder. So, I booted into Tiger and deleted them and everything in the Leopard's System/Library/Caches and then Extensions.mkext. When I rebooted Leopard with -v the AppleVIAATA Driver no longer showed up. Sure enough, I fired up a couple copies of Rember and no panic happened. Though I notice the SATA drives are not showing up either. So, I must not have the new IOATAFamily.kext installed right, but I am getting closer...

 

Update: I used Kext Helper b7 to reinstall Dune's IOATAFamily.kext. The SATA drives showed up immediately in Leopard and also when rebooted. I then fired up the command line version of Memtest 4.2 which had previously panicked the kernel immediately. This time it was able to configure itself to run on 7348MB and passed all tests. Cool!

 

I am one happy ICH9 owner.

Link to comment
Share on other sites

Tiger with your IOATAFamily.kext is still panicking for me.

 

blame apple for this... that would say that their original kext is unable to handle more than 3gb(maybe 32bits limits).

Anyway are you sure there are no AppleVIAATA or JmicronATA left in your tiger install ?

Link to comment
Share on other sites

blame apple for this... that would say that their original kext is unable to handle more than 3gb(maybe 32bits limits).

Anyway are you sure there are no AppleVIAATA or JmicronATA left in your tiger install ?

Apple didn't have a Mac model that could take more than 3GB that used the kext? I guess I will have to move to Leopard or get a motherboard with an AHCI compatible southbridge chip.

 

FWIW: Whatever happens to Tiger when it panics, it won't boot afterwards.

Link to comment
Share on other sites

Hi again,

 

Sorry for the delay, I've some computer problems not related to this fix.

 

Well, I can confirm 100% that the fixed AppleIntelPIIXATA.kext / IOATAFamily.kext for Tiger works without issues!

 

No Kernel Panics of any kind while using 3 x 500 GB SATA HDs + 1 x DVD SATA burner (all in the 4 ports of an ICH9 controller) and 4 GB DDR2 800 installed.

 

Transfered big (+ 8 GB) files from one side to other (permutating the HDs), not a single issue, no corruption, no Kernel Panics.

 

No more problems installing software (.mpkg) that was a positive Kernel Panic using the AppleVIAATA.kext workaround.

 

Also I've done a complete Highload memory test finished successfully.

 

No more AppleVIAATA.kext (or JMicronATA.kext in Leo) for me. Goodbye buggy kexts!!!

 

Again, thank you very much -DuNe- !!!

Link to comment
Share on other sites

PAE: 32- vs. 64-Bit Systems

 

Addressing physical memory above 4 GB requires more than the 32 bits of address offered by the standard operating mode of Intel (32-bit) processors. To this end, Intel introduced the 36-bit physical addressing mode called PAE, starting with the Intel Pentium Pro processor.

 

look in your system log if PAE is enabled. i turned of usb legacy support ( because i wanted to check, if more than one usb2 ports are available and surprise, surprise my system report shows

 

localhost kernel[0]: hi mem tramps at 0xffe00000

Mar 6 10:07:43 localhost kernel[0]: PAE enabled

Mar 6 10:07:43 localhost kernel[0]: 64 bit mode enabled

Mar 6 10:07:43 localhost kernel[0]: Darwin Kernel Version 9.2.0: Tue Feb 5 16:13:22 PST 2008; root:xnu-1228.3.13~1/RELEASE_I386

Link to comment
Share on other sites

If I'm not wrong, PAE is mandatory for OS X... about the "64-bit mode" I don't know exactly how Apple deal with this, but to my understanding their OS is an hybrid 32-bit/64-bit one. Obviously the 64-bit compatibility is used with 64-bit compatible kernels and only with supported processors, unless you use the -legacy switch in com.apple.boot.plist...

 

but truly I don't know how all this is related to -DuNe-'s IOATAFamily.kext fix.

Link to comment
Share on other sites

If I'm not wrong, PAE is mandatory for OS X... about the "64-bit mode" I don't know exactly how Apple deal with this, but to my understanding their OS is an hybrid 32-bit/64-bit one.

PAE allows x86 processors to handle 36-bits of memory in 32-bit mode. As far as I can tell PAE doesn't exist in x64 mode.

 

According to John Siracusa of Arstechnica Leopard's kernel is still 32-bit. All OSX kernel extensions are thus 32-bit, which probably explains why we have so much trouble with kernel panics. It also means that Leopard's memory support really isn't any better than 32-bit Windows--there is just better PAE driver support in OSX.

Link to comment
Share on other sites

yes and i was reporting that pae enabled has not been reported in my system log until i turned of usb legacy support ( i turned it of for another reason, to have ehci) but it seems that until osx cannot take full control it just takes what bios offers.

Link to comment
Share on other sites

yes and i was reporting that pae enabled has not been reported in my system log until i turned of usb legacy support ( i turned it of for another reason, to have ehci) but it seems that until osx cannot take full control it just takes what bios offers.

 

Oh, ok... but again, if I'm not wrong that couldn't be possible. OS X needs PAE to even start (all real Intel Mac's use PAE-enabled processors). Maybe that's not 100% real, but at least is what I read in some technical docs.

 

About the 64-bit and PAE, yes, PAE is non-existant for a 64-bit process. It's simple not needed.

 

Anyway, going back ontopic, the problem with AppleVIAATA.kext and JMicronATA.kext surely is the lack of PAE compatibility (i.e. they're using 32-bit pointers). When you have 4 GB, the MMIO (Memory Mapped I/O, the address range that the kext's uses to "communicate" with the hardware) is remapped to the >4 GB range, so those kext's can't reach it.

 

Cheers!

Link to comment
Share on other sites

When you have 4 GB, the MMIO (Memory Mapped I/O, the address range that the kext's uses to "communicate" with the hardware) is remapped to the >4 GB range, so those kext's can't reach it.

I think what really happens is the kexts map the I/O address range in the 3.25GB to 4GB range. This works fine until the OS gives that memory to a program and then the kernel panics.

 

Reading about this today, AMD decided to make x64 work a lot smarter. Even though today's X64 processors only really support 40 some bits of physical address--the unused bits have to be 1s, so X64 kernels put all their IO at the very top of the 64-bit address space--Nice!

Link to comment
Share on other sites

blame apple for this... that would say that their original kext is unable to handle more than 3gb(maybe 32bits limits).

Anyway are you sure there are no AppleVIAATA or JmicronATA left in your tiger install ?

I just did a fresh install of 10.4.11 and installed your patched Tiger kext. Memtest 4.2 started up just fine and allocated 7534MB, so far it hasn't panicked. Now I am thinking it might have be something from my iMac drive that caused the panics. Thank you very much for your work!

 

Update: Memtest 4.2 passed all tests!

Link to comment
Share on other sites

Hi,

 

Oddness - I tried replacing the old kext (10.5.2) with this one and it didn't find the device at all... previously the Apple provided kext was intermittently working/not working (would not find boot device) in IDE mode. Only the two SATA chanels were working.

 

I am running an HP dc7800 small form factor system that has only IDE and RAID options for the SATA - no AHCI.

 

Renaming the new kext and having the original kext present has solved the problem (strangely enough). The DC7800s have three SATA ports SATA0, SATA1 and SATA4. SATA0 and 1 worked with the original kext but now SATA4 works with the setup I described.

 

If anybody knows why I need to have both kexts, let me know :rolleyes:

Link to comment
Share on other sites

Hi,

 

Oddness - I tried replacing the old kext (10.5.2) with this one and it didn't find the device at all... previously the Apple provided kext was intermittently working/not working (would not find boot device) in IDE mode. Only the two SATA chanels were working.

 

I am running an HP dc7800 small form factor system that has only IDE and RAID options for the SATA - no AHCI.

 

Renaming the new kext and having the original kext present has solved the problem (strangely enough). The DC7800s have three SATA ports SATA0, SATA1 and SATA4. SATA0 and 1 worked with the original kext but now SATA4 works with the setup I described.

 

If anybody knows why I need to have both kexts, let me know :hysterical:

 

that's because you have certainly not deleted the cache after installing the new kext... the fact to change the name of the kext have forced the system to recreate an Extensions.mkext cache and so this time it works. Because your method is not clean at all, if i were you i would delete the original , rename the new kext with the good name, delete the Extensions.mkext and reboot. It should work

 

By the way, if you install the kext with kexthelper, it will do all of this for you...

Link to comment
Share on other sites

 Share

×
×
  • Create New...