Slow Hard Drive access on Snow

[skydrone]

Hi,

I'm having slow hard drive reads. Suddenly, it stops for 10 seconds, keeping the hd activity led steady on.

When this happens, nothing is written to system.log, so it's really hard to trace.

Can somebody help me?

[OG-Phantom]

Hi,

I'm having slow hard drive reads. Suddenly, it stops for 10 seconds, keeping the hd activity led steady on.

When this happens, nothing is written to system.log, so it's really hard to trace.

Can somebody help me?

Please post your system specs (motherboard, hds, cpu, etc. etc.) and post what non-vanilla kexts your using (dsmos, platformuuid, etc.) and if your booting into 32 or 64bit mode and what build of snow your using. Would help us to help you!

[hubba]

10.6 installed on Dell T3400 x48 system with QX9650 8gb ram from 10.8 leopard drive. Initial boot into SL with -v -x32 flags & quick launch of Kext Utility to repair permissions. Reboot & now fully stable x64 :)

BUT... if I leave any combination of SATA 1-5 on (misc hard drive & DVD) disc access for SATA 0 is fine but ANY activity for SATA 1-5 is crazy slow. In addition system profiler cannot get details on SATA and yields "No information found"... and If I turn off all but SATA-0 which is my 10.6 drive... all is well and profiler sees ICH9... BUT also still sees SATA 1-5 with nothing attached (even tho they are off in bios???)

IDE is shut off in BIOS & there are no IDE devices.

I've input UUID for SL drive in all proper locations... and I used DSDT patcher on the same system to create a proper SL dsdt.aml... edited for cmos reset.

Here are images of my chameleon EXTRA folder (all x64) & the console messages when all SATA 0-5 are on but 1-5 are responding slow.. notice the timeout streaming a preview of an mp3:

[skydrone]

Motherboard is GA P45 UD3, with Q9550.
I'm using a USB stick to boot a RAID 0 on WD Eco Blue 500GB drives. On this USB, I have Chameleon RC2, and mkext with:

Disabler.kext
IOAHCIBlockStorageInjector.kext
NullCPUPowerManagement.kext
OpenHaltRestart.kext
PlatformUUID.kext
SleepEnabler.kext
fakesmc.kext

Disabled APM on my hard drives. Also unchecked to sleep disks in system preferences.
I can't give further information, because nothing is written in dmesg when this happens...

[Snow]

And you use Disabler for?

[diskeeper]

@hubba: Try to remove AHCIPortInjector, ATAPortInjector, JMicronATAInjector. Use only the IOAHCIBlockStorageInjector.

[hubba]

Thank you Snow... didn't realize that nullcpupower & disabler were doing the same thing.

[hubba]

Thank you diskeeper... I cleared those from the EXTRA folder.. used kext utility to rebuild cache & a quick hard drive access test on all drives seemed fine... but system profile now shows all 6 channels of Serial-ATA as unknown? Do you think I need to edit the device id I pulled from OSX86tools leopard install and update the ICH9 plist section of IOATAFAMILY.kext -> Plugins -> AppleIntelPIIXATA.kext of SL? Oops just checked and there is no ICH9 section there. Maybe I should pull the updated Netkas AppleIntelPIIXATA.kext & update device id section for ICH9?

[diskeeper]

This is only cosmetics, not necessary. Mine is the same: unknown, but working.

[jimmydigital00]

I am also having this problem.
Rampage II Extreme core i7 920 chip
All Sata drives no ide
The main drive works fine but all other sata drives are very slow.
I am only running dsmos, IOAHCIBlockStorageInjector.kext, NullCPUPowerManagement.kext and PlatformUUID.kext

Any thoughts?

[jimmydigital00]

Anybody have any ideas?

[hubba]

This same issue is still a current problem even after removing all but the necessary kext from EXTRA. SATA0 responds normally (maybe a little slower than normal)... while SATA 1-5 sometimes don't even appear on desktop as usable drive. Again this is my Dell T3400 with X48 chipset, 8gig ram, QX9650, ICH9R which still is not recognized by system profiler. I'm gonna put my money on a problem with dsdt.asl not working properly.
I don't see any errors in console that relate to these disk access issues.

[skydrone]

Still having this problem. Access to 1st SATA device seems to be fine, but the other hard drives are really slow and getting my system freeze for some minutes! :(

[mormegil]

Confirm I have this problem with MSI P45 Neo2 (ICH10R). 2 SATA drives with Win7 on the first and both Leo/SL on the second. I'm using vanilla kexts (besides Null, Sleep, fakesmc, OHR, Platform).

[hubba]

This is how I seemed to fix the issue for a Dell Precision T3400 X48 ICH9 based SL install. You'll need to install from the USB method... ***copy latest kextutility to the root of your USB flash drive... you'll need to copy it to the new SL drive once install is complete
:
PREPARATION
1- From any working Leopard hard drive install Chameleon RC-1 to the GUID formatted target SL drive. (preferably on SATA0)
2- Copy PCefi 10.1 boot file to the root level target SL drive
3- Copy your version of dsdt.aml to both the root AND the EXTRA folder
3- Delete pre-existing files from within EXTRA\EXTENSIONS
4- Copy latest SL files RTC, Disabler, IOACHI, Sleep, fakesmc, OHR, Platform into EXTRA\EXTENSIONS (remember to update UUID info for Platform)

*** limiting to just these file and the clean USB install fixed all SATA issues.

5- Copy modified com.boot.apple.Boot.plist AND smbios.plist to Extra (remember to update UUID section of smbios.plist)
6- Reboot into BIOS and turn off all SATA 1-5 leaving your target SL install drive on SATA0 active

INSTALL
1- Reboot again and select your USB as the target for boot.
2- Install to target SL drive on SATA0
3- Reboot into BIOS and turn all SATA back on and select SL drive as boot drive
4- During Chameleon boot press space until Boot appears near bottom left and type -x -x32
5- you should get the welcome screen and eventually the desktop
6- IMMEDIATELY copy the kextutility from the root of your install USB drive to your desktop & let it rebuild all mkext

That's it... you can now reboot without the -x32 argument and hopefully have stable SATA respose.

[mormegil]

LOL. I'm somehow sceptical it really solves the problem. :P

[hubba]

I've been testing this Dell Precision T3400 x48 motherboard with SL for 2 weeks trying to get stable SATA0-5... minimizing the number of kext withing EXTRA\EXTENSIONS to the minimum seems to be key along with clean install from SL type drive. I've not changed my dsdt.aml in any way and once I removed such 64bit kext like jmicron, ioata, and duplicates like Null + Disabler (didn't realize they were somewhat duplicates) SATA0-5 behaves normally.

Ideally if you apply this "minimal kext" theory to the USB Install flash drive as well... you shouldn't need to disable SATA1-5 prior to install.. as the offending kext isn't present.

Once kextutility repairs all mkext and you reboot into 64bit SL... clicking on the Eject icon now immediately shows 2 DVD drives and all other throughput on hard drives & DVD drives SATA0-5 are normal.

I've only had this latest test running for 1 day.. but rebooted 3-5 times and SATA continues to be stable.

[hubba]

Here's a clue if it helps one of the uber hackintosh crew... if I double click a hard drive on SATA 1... finder opens but spining beach ball appears during the long delay.. unless I launch an app that steals focus from that window... then it immediately updates correctly.

[thorazine74]

Does it happen only in 64 bits or also in 32 bits?
Get rid of all the AHCI injectors, none of them are needed, including the BlockStorageInjector.
Also I would try plugging the system drive on port 1,2,3... to find out if the slow down is caused by non system disks, or by ports others than SATA0.

[cmdematos]

Try modifying plist on AppleAHCIPort.kext to add an entry for your ICH9R. Copy the entry for ICH8R, change just the descriptive entries to ICH9 where these are ICH8 and change just the address of the controller which on the T3400 should be 0x28228086.

I hope this helps.

[hubba]

since AppleAHCIPort.kext - info.plist does not have a section listing ICH9 or ICH9M.. should I copy & paste that one section from netkas's version and ADD it to the info.plist making sure I include the correct device id? (it's actually 2922)

Otherwise I could simply modify the device id string in the "Generic AHCI" section?

Thanks!

[thorazine74]

If you still use the AppleAHCI class it makes no difference the device id (the Generic AHCI matches all controllers anyway) or the controller name (its probably only used for identification purposes).
I have no noticeable problems (just shortly tested) with ICH10 on a P45 in 32 bits, maybe Apple is doing something weird to the controller in 64 bits.
Just a wild guess, but maybe Apple is doing different things on same AHCI controllers depending on the computer class, try changing the computer identification (MacPro, iMac, MacBook, etc.) in smbios.

[hubba]

Seems there are several threads about slow SATA 1-x on other motherboards as well. The following link seems to favor a fix in the dsdt.aml file for several interrupts that are conflicting.

http://www.insanelymac.com/forum/index.php?showtopic=181981&st=120&start=120

Work right now prevents me from testing... but I wanted to pass it along.

Seriously for now I just turned off SATA 1-5 and Snow x64 is rock solid :)

[hubba]

Many thanks to The King & CSHARP for this fix... originally from InsanelyMac.

http://www.insanelymac.com/forum/index.php?showtopic=181981&st=160

Post #162

Open & edit dsdt.dsl
find occurrence of the following and delete any IRQ# within brackets { }:
Device RTC / RTC0
Device TMR / TIMR
Device PIC / IPIC

For example my x38 motherboard dsdt.aml had no IRQ set for RTC… but TMR & PIC did so I deleted the number leaving {} with nothing in the brackets.

Then I saved the dsdt.dsl… converted back to dsdt.aml and all SATA now show no signs of stalling or delay.

Device (TMR)
{
Name (_HID, EisaId ("PNP0100"))
Method (_CRS, 0, NotSerialized)
{
Name (TMRB, ResourceTemplate ()
{
IO (Decode16,
0x0040, // Range Minimum
0x0040, // Range Maximum
0x01, // Alignment
0x20, // Length
)
IRQNoFlags ()
DELETE THE 0-> {0}
})
Return (TMRB)
}
}

Device (PIC)
{
Name (_HID, EisaId ("PNP0000"))
Method (_CRS, 0, NotSerialized)
{
Name (PICB, ResourceTemplate ()
{
IO (Decode16,
0x0020, // Range Minimum
0x0020, // Range Maximum
0x01, // Alignment
0x20, // Length
)
IO (Decode16,
0x00A0, // Range Minimum
0x00A0, // Range Maximum
0x01, // Alignment
0x20, // Length
)
IO (Decode16,
0x04D0, // Range Minimum
0x04D0, // Range Maximum
0x01, // Alignment
0x02, // Length
)
IRQNoFlags ()
DELETE THE 2-> {2}
})
Return (PICB)
}
}