148 replies to this topic

[bcc9]

P.S.S. I have another reported case of audio working in ML GM w/ the binary patch I have previously calculated, this time for ALC662. See THIS
Mind to try it as well ? Just swap the codec ID for your IDT. Also try the patch in my previous post as i have suggested to the person by that link.

So you're really confusing me about which of the AppleHDA binary patches are supposed to be working so far with the 10.8 GM release. I only have an alc889 codec to test against at the moment. I've tried a few of the proposed patches but no luck so far.

I think part of the problem with inconsistent working/not working reports is that people aren't sharing their working layout&Platforms .xml files. Are the 10.7.x .xml files working for people under 10.8 without changes to the xml (beyond adding compression)?

I can help re-decipher the codec dispatching code for 10.8, but I'd rather not take the time if this has been completed already by someone else.
Probably should take this to a new thread.

Thank you yet again! I hope that in RTM the bug will be gone for good, because I just don't like the idea of patching so many things after each an every update and keeping it to a minimum would be great (I don't need an RTC patch anymore at least).

Yes, it'll get real old maintaining this patch across a lot of releases; if the OSX code doesn't fix it, one should be able to put a time delay wrapper around the kext plugin to cause its start to delay, instead of using a binary patch.

I did notice that with the gigabyte UEFI bios, the AHCI driver reports the AHCI ports as not hot-pluggable, just like with geninue mac hardware, instead of as hot-pluggable like with the gigabyte legacy bios. I wonder if this is the difference or it's some other side effect. In any case, I still don't see how to control these AHCI port settings outside of he bios, but at least it seems like a solvable problem from the bios end of things.

Actually with the gigabyte UEFI bios, it has a setting to let you mark the AHCI ports as hot-pluggable or not. I can boot using this UEFI bios set either way and I don't run into the "waiting for root device" issue, so the problem seems to be elsewhere.

If you have time, could you maybe assist me in the future with some info/tips/ideas on how one could get Nvidia GPU working on OS X by binpatching the buffer check in the nvidia kexts? Only if you feel like it

I'm not sure what buffer check you're referring to; I didn't have to do any binary patching of the nvidia video driver to get it to work with my now old nvidia hardware. Just a lot of reading was required to get nvidia HDMI audio working (and in the end only for some users). The nvidia OSX drivers are a lot worse to work with than the ATI/AMD and intel ones, as the nvidia code appears obfuscated. I've managed to avoid nvidia video cards since then so I'm probably not the right person to ask.

if you free do you mind to sent PM about developing voodoo ps2 controller ( the touchpad kext )

I'm not the dev for that and I only have one old laptop with a synaptics touchpad (not alps). I haven't touched that driver in 3 years (since made a fix for the touchpad timing out). Would like to keep it that way

[TimeWalker75a]

So you're really confusing me about which of the AppleHDA binary patches are supposed to be working so far with the 10.8 GM release. I only have an alc889 codec to test against at the moment. I've tried a few of the proposed patches but no luck so far.

They're basically the same algo, but for different codec substitutes, so far I came up with the one for AD1984, ALC262, ALC885.

I think part of the problem with inconsistent working/not working reports is that people aren't sharing their working layout&Platforms .xml files. Are the 10.7.x .xml files working for people under 10.8 without changes to the xml (beyond adding compression)?

Indeed, this is what I suspect is the problem here. Take a look at the topic I have linked previously, I have attached a copy of an AppleHDA kext from ML that has been proven to work by two people.

AFAIK the person who has put it together needed to do some changes to the original xmls he was using in 10.7, so they definitely need some tinkering.

I can help re-decipher the codec dispatching code for 10.8, but I'd rather not take the time if this has been completed already by someone else.

Probably should take this to a new thread.

Than we shall continue this discussion in the thread I have linked previously, since the person has decided to call it so

Actually with the gigabyte UEFI bios, it has a setting to let you mark the AHCI ports as hot-pluggable or not. I can boot using this UEFI bios set either way and I don't run into the "waiting for root device" issue, so the problem seems to be elsewhere.

Well, most notebooks have a stripped UEFI that you don't have an acces to basically anything .. just the boot order and password protection section. Also it is locked in Legacy mode by the manufacturer, so this might be an issue.

[Mohamed Khairy]

I'm not the dev for that and I only have one old laptop with a synaptics touchpad (not alps). I haven't touched that driver in 3 years (since made a fix for the touchpad timing out). Would like to keep it that way

-------------------

thanks any way for your work
there is already an developer of iPhone application tries for this alps from the source of linux kernel
and he is working on it and will see result hope it works directly if it doesnt work hope from you to see the code when released and evaluate it
any way it return to you
and thanks for your works as i got benefits from your work on IDT codec + intel HD Graphics 3000 + still waiting root + ati connector edit
thanks very much

[BatcOuntrY]

bcc9, you my friend are one awesome individual. I thank you very much for providing this workaround (and the info on the uefi bios fix) and your time and effort that went into finding it. I was pulling my hair out for a bit there until i was pointed to your thread. I am using a Samsung 830 SSD and your patch worked for me. Once they have a non beta uefi for the z68x-ud3h-b3 I think I will try that route but for now I am a happy camper. So one more time. THANK YOU!

[BugsB]

bcc9, you're a HERO !! How the heck do you figure stuff like this out? THANK YOU !! This has been driving me nuts..

[bcc9]

Hey thanks guys. Glad the patch seems to be working for everyone (since it was such a pain to come up with in the first place
This thread does detail a lot of the investigation I had to go through before coming up with a fix. Already knowing how to debug an OSX kernel, as well as kext initialization, and familiarity with x86_64 assembly helped.

Probably time for some of these fixes to be stickied since there seems to be several other threads where users might be having the same problem without knowing it.

[TimeWalker75a]

You could ask a mod to clean up the thread from unwanted messages that are not related to the topic (about sound in particular) and also sticking it would be a good idea. I have proposed the fix quoting your original post on applelife and it has helped a few to overcome the dreaded error. Props again!

Also, have you, by any chance, tried to make a shell for hda, incorporating the algorithm that I had mentioned?

[bcc9]

You could ask a mod to clean up the thread from unwanted messages that are not related to the topic (about sound in particular) and also sticking it would be a good idea. I have proposed the fix quoting your original post on applelife and it has helped a few to overcome the dreaded error. Props again!

Also, have you, by any chance, tried to make a shell for hda, incorporating the algorithm that I had mentioned?

Perhaps a FAQ post, would be best, along with some cross-referencing to existing FAQs such this one as http://www.insanelym...howtopic=278075
I wouldn't want to see some of the details deleted since they still go into some useful debugging scenarios.

I just did my IDT audio for 10.8 without needing any special algorithm (see http://www.insanelym...dpost&p=1838010)
I do have a perl script that handles the patching AppleHDA for IDT for any release, it's in the package (I can post it separate if it's of interest).
I should probably try to add in alc889 support as well and see whether I can make your algorithm or something simpler automatic. Thanks for your post on the algorithm, btw.

[scorcho]

Here's a script that will patch your IOAHCIBlockStorage kext to cause its start to be delayed by 200ms. 200ms is more than twice as long as I've found necessary to avoid the dreaded "Still waiting for root device" error. This patch can be used instead of the somewhat fragile debug=8 ahcidisk=1 workaround.

This may be the best patch I can come up with - I don't see how to patch the AHCI controller to change its configuration (the hot plug-ability , and ALPM support).

Thank you for this script, as it solved the problem on a Gigabyte motherboard that wasn't set up to use kernel cache. My computer can boot 10.8 off an external ESATA drive connected to the board's Marvel SATAIII controller, but would hang with the 'wait for root device' error when booting off an internal drive connected to Intel's Series 6 SATA chipset.

Curious tidbit, before the patch I could boot off the internal drive after restarting from the external 10.8 drive first. It just wouldn't start up after shutdown.

[Hicks1gb]

Hi, please, can you explain how use this script?
Thanks in advance.

[bcc9]

Curious tidbit, before the patch I could boot off the internal drive after restarting from the external 10.8 drive first. It just wouldn't start up after shutdown.

Interesting, so cold boot exhibited the timing issue but warm boot did not. I guess this would be because the drive winds up being in a different state at kernel boot time between those two cases.

[bcc9]

Hi, please, can you explain how use this script?
Thanks in advance.

Click on it, enter your admin password, reboot. Script is only for 10.8 GM and I didn't add checks for OS version... I (or someone else) could make an installer package for this to make the installation newbie friendly. I probably won't get to that unless this problem remains outstanding once 10.8.1 comes out.

[magnifico]

bcc9 this script is also for asus main ?
Only for error still waiting for root device?

[bcc9]

bcc9 this script is also for asus main ?
Only for error still waiting for root device?

I'm not sure the set of motherboard that need this fix. Hundreds have downloaded the fix, but only a couple have reported back on what motherboard/chipset they needed the fix for. Perhaps it is most systems with sandy bridge chipsets, whose BIOS doesn't include UEFI support.

Yes, as far as I know, the only symptom is the "Still waiting for root device" error.

[magnifico]

I'm not sure the set of motherboard that need this fix. Hundreds have downloaded the fix, but only a couple have reported back on what motherboard/chipset they needed the fix for. Perhaps it is most systems with sandy bridge chipsets, whose BIOS doesn't include UEFI support.

Yes, as far as I know, the only symptom is the "Still waiting for root device" error.

Ah ok....for this problem i use IoAhciBlockstorage.kext ....you thing that i need ?

[bcc9]

Ah ok....for this problem i use IoAhciBlockstorage.kext ....you thing that i need ?

Not sure I understand the question. If you're

• booting from a SATA disk
• from an intel SATA controller
• and the system hangs with "Still waiting for root device", unless you boot with the kext cache turned off

then I think you need this fix.

Or if you're booting with a "legacy" bios, and there is a UEFI bios available for your motherboard, you may be able to simply upgrade your BIOS to solve the problem.

[fgrjhtd]

Click on it, enter your admin password, reboot. Script is only for 10.8 GM and I didn't add checks for OS version... I (or someone else) could make an installer package for this to make the installation newbie friendly. I probably won't get to that unless this problem remains outstanding once 10.8.1 comes out.

Thank you for creating a patch. Apple released a new update 10.8.1. The original patch has been unable to achieve the desired effect. Patch to upgrade ioahciblockstorage to repair power problem

[bcc9]

Thank you for creating a patch. Apple released a new update 10.8.1. The original patch has been unable to achieve the desired effect.

The patch of course will need to be updated for any new releases for which the problem persists. (Well we could get fancy with otool to make the patch adapt dynamically to future releases). Does the problem in fact remain with the stock 10.8.1 beta?

Almost forgot, another longer-term workaround could be a wrapper to IOAHCIBlockStorage

[BugsB]

Almost forgot, another longer-term workaround could be a wrapper to IOAHCIBlockStorage

Can you elaborate?

I actually need to solve the same problem on a non-AHCI Optiplex 745 (see signature). The effected kext is AppleIntelPIIXATA.kext (inside IOATAFamily.kext): with k-cache off or -f booting fine, wit k-cache on "Still waiting for ...". It does not matter if the kext is loaded from within IOATAFamily or directly from S/L/E.

Since I guess you would not know immediately which bytes of that kext to patch, a wrapper sounds as if it would come in handy. (I pretty much doubt that the "somewhat fragile debug=8 ahcidisk=1 workaround" would in any way apply to AppleIntelPIIXATA).

Do you have any suggestion?

[fgrjhtd]

The patch of course will need to be updated for any new releases for which the problem persists. (Well we could get fancy with otool to make the patch adapt dynamically to future releases). Does the problem in fact remain with the stock 10.8.1 beta?

Almost forgot, another longer-term workaround could be a wrapper to IOAHCIBlockStorage

I am sorry my English is not very good. I can probably understand what you mean. So you mean the long-term solution to achieve.
wrapper to IOAHCIBlockStorage I am willing to be tested。