Waiting for root device when kernel cache used; only with some disks +FIX

[bcc9]

As for bin patching, I patched the run-time checks of the ahcidisk debug variable.

Basically the driver code is full of statements resembling:

if (ahcidisk & 0x1) kprintf(...)

a patch might be to change this to a unique bit check:

if (ahcidisk & 0x8) kprintf(...)

then if you boot with ahcidisk=8, only that 1 kprintf() is executed.

I bisected the problem that way (using a perl script to make the patching automated).

 

Quite tedious, I normally would just slap a gdb debug session on the problem, but since this is a timing issue...

[DoiX]

As for bin patching, I patched the run-time checks of the ahcidisk debug variable.

Basically the driver code is full of statements resembling:

if (ahcidisk & 0x1) kprintf(...)

a patch might be to change this to a unique bit check:

if (ahcidisk & 0x8) kprintf(...)

then if you boot with ahcidisk=8, only that 1 kprintf() is executed.

I bisected the problem that way (using a perl script to make the patching automated).

 

Quite tedious, I normally would just slap a gdb debug session on the problem, but since this is a timing issue...

 

Ah, i see. Thanks for clearing that up. It's quite tedious indeed, makes me think you're really bothered by this problem.

[bcc9]

It's really a stupid bug... being to fast breaks stuff. Really apple? I'm curious tho if this happens on MBPs/SSDs as well. Guess we have to wait for ML to go live to see.

Well on genuine apple hardware, the ahci controller is configured differently than with these gigabyte motherboards. For example, on the gigabyte, the internal ports are listed as hot pluggable, and ALPM power management is disabled. On apple hardware, I see the opposite. Apple reports these internal gigabyte SATA ports as if they were external...

Some of these differences may affect the timing or disk drive state at the point that the AHCI kext is started.

 

The timing problem is probably not seen on genuine mac hardware, else the problem would have been fixed before 10.8 went gold.

 

Well, i assume you can do the same thing with a patched IOPCIFamily kext, having the sources would make it a lot easier.

I'm not sure why you're bringing up this other kext. Yes we have the source for that one, and so yes it has been a lot easier to debug the problems with that kext.

 

Ah, i see. Thanks for clearing that up. It's quite tedious indeed, makes me think you're really bothered by this problem.

Some of the other kexts I debugged are also binary only and were a lot more involved to debug. If I had not done so, we wouldn't have the custom personality editing for ATI and Intel graphics. working HDMI audio for certain nvidia graphics hardware, and on&on.

It's worth getting to the bottom of these things - else the system only works sometimes or incompletely. Might as well stick to genuine mac hardware if one has no interest in getting one's hands dirty debugging the details.

[DoiX]

 

I'm not sure why you're bringing up this other kext. Yes we have the source for that one, and so yes it has been a lot easier to debug the problems with that kext.

 

I brought it up only to get confirmation that one could do that .

 

 

Some of the other kexts I debugged are also binary only and were a lot more involved to debug. If I had not done so, we wouldn't have the custom personality editing for ATI and Intel graphics. working HDMI audio for certain nvidia graphics hardware, and on&on.

It's worth getting to the bottom of these things - else the system only works sometimes or incompletely. Might as well stick to genuine mac hardware if one has no interest in getting one's hands dirty debugging the details.

 

Like i said earlier, it's a handy skill to know how to do what you do, at least in this community, which kinda lacks devs in my opinion.. at least compared to the golden age of Osx86 scene.

[bcc9]

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).

 

Original 10.8-only patch script: patch-ahci-mlion-0.1.zip

Update: newer version of the fix is attached to post #1.

 

[bcc9]

I brought it up only to get confirmation that one could do that .

Ah yes, for sure it's a lot easier with source! I was for example able to pretty quickly find the original npci=0x2000 workaround to the common "PCI Configuration Begin" hang using the source. It would have taken a bunch more effort to find that workaround without source.

 

Like i said earlier, it's a handy skill to know how to do what you do, at least in this community, which kinda lacks devs in my opinion.. at least compared to the golden age of Osx86 scene.

Yes, though it is understandable that development is slow, given how little support developers get. When one's work is successful, it seems the reward is lots of newbie questions and or your work is just incorporated into someone else's script without attribution. The lack of attribution is not merely a matter of intellectual bad manners, it leads to subsequent improvements and issues not making it back to the developer. Most developers combat this somewhat by making their own web site, but that's not a great solution for US based hackintosh'ing (where the reward for success would be a take-down notice).

 

Oops, I'm getting pretty off topic now.

[DoiX]

Script is working perfectly

 

So you're the brains behind 0x2000. I've read dozens of pages about people complaining about that error and using that flag to fix it.... but none of them even mentioned you (or even know what the hell it does).

 

I was actually wondering (after reading this ) if apple takes action against hackintosh projects in the U.S, it would be silly to leave it slide considering they almost sued the artist in the linked article. Wouldn't it be better for the recognition of devs if InsanelyMac would provide mini sites to them? Like the current blog system but with higher visibility, or even the Wiki system.

 

It's your topic, as far as i'm concerned you can start writing poetry here.

[TimeWalker75a]

The patch has worked for my machine as well, thank you.

Im unable to send you a PM (you have set it so apparently). I know that it's not the right thread to ask, but I figured, since you're good with assembly it's still worth asking.

If this will lead to anything good it may be carried out to a dedicated thread.

 

here it goes...

 

 

Hey,

I have been tinkering with HDA binary from GM build of ML for some time trying to reenable support for my ALC269 and a bunch of other codec. I have previously figured an algo similar to what RevoGirl was using. Sadly, Sam is not with us anymore, so I can't really ask her what has changed dramatically in the binary (apart from that it's not a fat macho-O anymore and IDA Pro won't let me disasm it and so won't OTX). So, since I know you are really good with assembly code I took a wild guess and thought you might help finding a spot on solution.

 

Now, in 10.7 I used to patch the binary like that:

1. substitute the Wolfson codec id 0x1aec87ff with my 0x10ec0269 in 4 occurencec (just 2 now, 1 in function group call and another in widget call, since the binary is arch x86_64 only)

2. instead of doing jg (0f 8f) i changed it to do je (0f 84)

3. instead of making a jump if greater to a procedure group of enabling Wolfson WM8800 codec functiongroup and widget I made it jump to an address that is being called for AD1984 codec (0x11d41984). those eliminating some check. I've recalculated the binary patch by taking the address of a procedure block related to AD1984 - the address of jg (now je) operator of Wolfson codec (now mine) and - 6 bytes. Doing a byteflip so changing the address to which je does the jump to procedure block of AD1984. This has worked flawlesly for the past versions of Lion and up to DP3. In DP4 things got complicated and binary chnaged dramatically.

 

What I've been able to figure out hose far is that the basic principles I used before still apply. I can replace the wolson's id with mine and I can recalculate the addres to AD1984.

Basically for the new binary the patch is the following:

sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x53\x01\x00\x00|\x69\x02\xec\x10\x0f\x84\x8f\x02\x00\x00|g' AppleHDA
sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x2f\x01\x00\x00|\x69\x02\xec\x10\x0f\x84\x53\x02\x00\x00|g' AppleHDA

This patch was confirmed to work by some pals of mine for ALC892 and ALC889 also AL665.

 

What I have found though is that in 10.7 the function group and widget used to be called directly by their respective function names.

This is done after the jump is made to an address specified for AD1984 (and now the patched codec id 0x10ec0269 which also jumps to the same address eg. 0x0003d9d2 and 0x0003ff08 in the below code snippets)

 

This is 10.7:

000000000003d99b	cmpl	$0x11d41984,%ebx
000000000003d9a1	je	0x0003d9d2

000000000003d9d2	movl	$0x000000f0,%edi
000000000003d9d7	callq	0x0003d9dc
000000000003d9dc	testq	%rax,%rax
000000000003d9df	movq	%rax,%rbx
000000000003d9e2	je	0x0003dc2b
000000000003d9e8	movq	%rbx,%rdi
000000000003d9eb	callq	__ZN27AppleHDAFunctionGroupAD1984C1Ev <- note this part
000000000003d9f0	jmp	0x0003dc2b <-all codecs are sent here for a test ?

000000000003dc2b	testq	%rbx,%rbx
000000000003dc2e	jne	0x0003dc4a <-if it returns 0? then jump, else cnt (this wil give assertion error in IOLog, but still will call the same address after the error is displayed)

000000000003dc4a	movq	%rbx,%rax
000000000003dc4d	addq	$0x08,%rsp
000000000003dc51	popq	%rbx
000000000003dc52	popq	%rbp
000000000003dc53	ret

 

000000000003fed1	cmpl	$0x11d41984,%ebx
000000000003fed7	je	0x0003ff08

000000000003ff08	movl	$0x00000530,%edi
000000000003ff0d	callq	0x0003ff12
000000000003ff12	testq	%rax,%rax
000000000003ff15	movq	%rax,%rbx
000000000003ff18	je	0x0004010f
000000000003ff1e	movq	%rbx,%rdi
000000000003ff21	callq	__ZN20AppleHDAWidgetAD1984C1Ev  <- note this part
000000000003ff26	jmp	0x0004010f <-seems like and address where all codecs are getting verified

000000000004010f	testq	%rbx,%rbx
0000000000040112	jne	0x0004012e

000000000004012e	movq	%rbx,%rax
0000000000040131	addq	$0x08,%rsp
0000000000040135	popq	%rbx
0000000000040136	popq	%rbp
0000000000040137	ret

 

in 10.8 this not like that anymore. if I undersigned that correctly instead of calling the function,it stores the function group metaclass address into a register.

then proceeds with indirect register to register addressation and this is the part when I get lost, because I'm only familiar with 8080 assembly code

000000000003f385	cmpl	$0x11d41984,%eax
000000000003f38a	je	0x0003f4fa

000000000003f4fa	leaq	0x0002eccf(%rip),%rax <-here it stores the address of __ZN27AppleHDAFunctionGroupD19849metaClassE; AppleHDAFunctionGroupAD1984::metaClass
000000000003f501	jmp	0x0003f4c0 <- this seems like an address where all the codecs are sent to enable functiongroup

000000000003f4c0	movq	(%rax),%rdi
000000000003f4c3	movq	(%rdi),%rax
000000000003f4c6	call	*0x00000088(%rax) < this seems like a qword ptr call ? [rax+88h] ?
000000000003f4cc	movq	%rax,%rbx
000000000003f4cf	testq	%rbx,%rbx
000000000003f4d2	jne	0x0003f4f0 <- if test returned flag state 0? else proceed to show assertion error in IOlog

000000000003f4f0	movq	%rbx,%rax
000000000003f4f3	addq	$0x08,%rsp
000000000003f4f7	popq	%rbx
000000000003f4f8	popq	%rbp
000000000003f4f9	ret

 

kind of similar with the widget

000000000004171f	cmpl	$0x11d41984,%eax
0000000000041724	je	0x0004187c

000000000004187c	leaq	0x0002d8ad(%rip),%rax <- store metaclass address ?
0000000000041883	jmp	0x0004184d <- again, thi seems like and address to which all the codecs are send for verification ?

000000000004184d	movq	(%rax),%rdi
0000000000041850	movq	(%rdi),%rax
0000000000041853	call	*0x00000088(%rax)
0000000000041859	testq	%rax,%rax
000000000004185c	jne	0x0004187a

000000000004187a	popq	%rbp
000000000004187b	ret

the widget call procedure's final part seem to differ a little compared to 10.7, but the FG call is mostly identical.

now, how do I figure what it calls for in call *0x00000088(%rax) in both the FG and widget cases? I have been pointed out that if you open up the binary in say, HexFiend, and switch to text filed search you now have widget and function group names with corresponding ID in plane ASCII. On my desktop machine I have an ALC888, and I usually patch out the 885 codec. In 10.8 I had to patch the _10EC0885 to _10EC0888 in AppleHDAFunctionGroup_10EC0885 and AppleHDAWidget_10EC0885 (to allow my codec to work, otherwise it would freeze.

sudo perl -pi -e 's|\x5f\x31\x30\x45\x43\x30\x38\x38\x35|\x5f\x31\x30\x45\x43\x30\x38\x38\x38|g' AppleHDA

Now with the perl lines I've provided above for mentioned codecs (AL892 and 889) people don't seem to need any ASCII alterations, which seems weird to me.

 

Could you possibly help me to figure out why is the patch that I calculated worked for the others and not for me? Usually, in 10.7 and in DP3 the same patch was applicable for all 3 codec (ALC889, ALC892, ALC269 and also ALC271 as it's identical to 269) only the IDs needed to be changed.

 

If you need me to provide any additional info or files i will do ASAP.

Thank you in advance.

[bcc9]

Script is working perfectly

Great. So I wonder if your clover problem cleared up too by not using debug=1, or whether you are having some other problem there.

So you're the brains behind 0x2000. I've read dozens of pages about people complaining about that error and using that flag to fix it.... but none of them even mentioned you (or even know what the hell it does).

Yes indeed. I first solved the problem for the 1340 laptop and then the info was relayed to netkas's blog comments and then the information spread all over.

It's a lot like this problem in that a simple kernel boot argument or two has the ability to work around the underlying issue (PCI relocation).

This timing issue seems to affect far less users whoever.

I was actually wondering (after reading this ) if apple takes action against hackintosh projects in the U.S, it would be silly to leave it slide considering they almost sued the artist in the linked article.

Well I wouldn't want to publicly give my lay opinion of hackintosh legalize, but I'd note that alleged DMCA and EULA violations sometimes lead to legal action, especially if money changes hands (and forums that solicit contributions from users resemble that).

Wouldn't it be better for the recognition of devs if InsanelyMac would provide mini sites to them? Like the current blog system but with higher visibility, or even the Wiki system.

Perhaps. Seen a lot of wikis that don't get kept up. A wiki that actually detailed best current practices would be quite cool.

[bcc9]

Some good news -

I upgraded my motherboard to UEFI bios and the timing issue went away (system boots osx 10.8 fine without the AHCI patch or debug options).

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.

[bcc9]

The patch has worked for my machine as well, thank you.

Ok great. But I'm surprised to hear you say that - your last two posts insisted that the bug did not exist as of the 10.8 DP security update. At least for you and numerous other applelife.ru folks. (I did also check the applelife.ru forum and could only find your one post...)

Im unable to send you a PM (you have set it so apparently).

No, it's just my mailbox filed up as people keep PMing me for tech support (instead of posting in the threads like I keep asking). I've cleaned out a few more posts now; the new forum no longer is notifying me when m box is full.

I wish people would stop asking me about mobile ATI/Intel hardware when I've never used such hardware with a hackintosh

I have been tinkering with HDA binary from GM build of ML for some time trying to reenable support for my ALC269 and a bunch of other codec.

Great, I was about to hack mine and I could use some help

I have previously figured an algo similar to what RevoGirl was using.

I didn't pay close attention but I believe s/he was just using information from others (such as my applehda patch). I was the first to identify when the applehda binary changed to necessitate patching the range comparisons, here:

http://www.projectos...indpost&p=14993

and:

http://www.projectos...indpost&p=15205

my patch script is in turn based upon aschar's one-liner:

http://www.projectos...findpost&p=9687

 

all built on top of earlier AppleHDA knowledge such as found in The King's guide of course.

Sadly, Sam is not with us anymore,

Allegedly. At least that user is gone from another forum as had happened repeatedly in the past.

 

IDA Pro won't let me disasm it and so won't OTX). So, since I know you are really good with assembly code I took a wild guess and thought you might help finding a spot on solution.

IDA pro will disassemble 64 bit osx binaries. It's just the hex-rays decompiler not supporting x86_64 (surely there must be an update to hex-rays on the way??)

otx supports x86_64, you just need to compile it from source instead of using the antique .pkg which was for i386/ppc. I was thinking of trying to add vtable & 64 bit relocation table support to otx at which point lacking hex-rays wouldn't be much of a handicap

 

Ok, the rest of your post is pretty involved; looks like I'll have to take a look at the 10.8 AppleHDA code before I can give you a real answer - I haven't had a chance yet.

 

I swear I already saw someone claiming they had the 10.8 GM version of AppleHDA patched correctly for alc889?

[Mohamed Khairy]

thanks bcc9

you always do best

 

this problem was annoying me on my notebook make me must boot with caches on (MBR) and this causes artifact on screen

 

now it load with caches and it is fine

 

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

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

 

[TimeWalker75a]

Ok great. But I'm surprised to hear you say that - your last two posts insisted that the bug did not exist as of the 10.8 DP security update. At least for you and numerous other applelife.ru folks. (I did also check the applelife.ru forum and could only find your one post...)

 

 

Well, I was surprised after installing the GM build - the problem reverted back in this version of ML, however it wasn't there after applying the DP4 A256 updated (security one I have mentioned previously.)

 

I have a Vostro 3450, which has a SecureCore Tiano UEFI bios (you might have seen that in my signature on the other forum), which is identical to the one used in Inspiron N5110, see Mohamed's signature. And apparently we and all the rest of the users w/ SecureCore Taino and some Aptio-based UEFIs share the same problem for quiete some time. I also get artifacts on my HD 3000 if I boot without caches, so it was a crucial warkaround. 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).

I took a look at your script that has a

\x83\x19\xd4\x11 range zeroing-out. This id is not in place anymore, it has been removed as of DP4. It looks like there are jump tables in place now, when a codec is sent to do a jump if equals (if id in the registry and your id matches) it is sent to a table where there are cases defined for each id. There's a by-default case and some otehrcases. It looks like ALC885 AD1984 and AD198B share the same jump table which has a by-default id for AD198B.

 

Also, I was able to patch 10.7.3 and 10.7.4 binary without zeroing AD1983 out, just doing the necessary jump if equals alterations and jumping to AD1984 much like in the snipped I've provided earlier.

It basically goes like this: http://puu.sh/JwsG

1. The check sequence is initiated

2. The first in this sequence is the wolfson codec, if the id is greater proceed (jg) to the other codec to determine the id and a proper place to jump in order to call the functiongroup. You patch this to yours and make it jump if equal and specify the address of (3.) which is the address to where AD1984 is sent if the id mathces.

4. Wil determine if the flag returned 0, and 5. will proceed to call for a functiongroup.

Same thing with te widget: http://puu.sh/JwvD

So to sum up: you just had to alter the first step of the "ladder" to your id and so that it would jump to an address associated w/ AD1984 (instead of actually patching your id in place of AD1984) those eliminating some of the important checks. This will result in 0 assertion errors (at least for my codec, but you had to have hda-gfx onboard-1 to eliminate just one assertion that was related to HDMI audio).

 

Here how it looks in 10.8:

http://puu.sh/JzZ0

the most upper block is FunctionGroupFactory, the first block after it is the wolfson codec id verification. somewhere there in the middle lies the AD1984 which you used to patch out with your id. if the id matches after all the checks it goes to AD1984 metaclass and then to a 0x0003f4c0 where the functiongroup gets created (enabled) for the respective codec. In my patches I jump from the wolfson block directly to AD1984 metaclass.

 

 

In case you still have 10.7.4 around you can try this w/ a clean binary, see if it works for your IDT a swell:

sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x96\x02\x00\x00|\x75\x76\x1d\x11\x0f\x84\xfc\x01\x00\x00|g' AppleHDA
sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x7d\x02\x00\x00|\x75\x76\x1d\x11\x0f\x84\xfc\x01\x00\x00|g' AppleHDA

sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x97\x02\x00\x00|\x75\x76\x1d\x11\x0f\x84\xcc\x01\x00\x00|g' AppleHDA
sudo perl -pi -e 's|\xff\x87\xec\x1a\x0f\x8f\x7e\x02\x00\x00|\x75\x76\x1d\x11\x0f\x84\xcc\x01\x00\x00|g' AppleHDA

In case it does then we can try to escalate the same method to the new 10.8 binary.

 

I swear I already saw someone claiming they had the 10.8 GM version of AppleHDA patched correctly for alc889?

 

 

I saw it somewhere too, but upon downloading the patched kext it turned out to be v2.3.0a57(also this version of binary is somewhat different from the one found in GM build), so the one from stock DP4 install. However upon a quick glance through diff inspection I've found that the binary is definitely not from that version, it had more than 3k diffs, meaning it must have been from DP3 when things still worked as in 10.7. We might be speaking about different things, but I can assure you I have came up w/ the lines provided above by myself by looking at otool disassembly.

 

Thanks for your tip about otx, I like it's output much better. However IDA would be cool too.. I can use the console version to disasm the x86_64, but the graph it generates is a distaster to work with. It just generates plane image where all the lines are mooshed together in one fat undistinguishable nonsense.

 

P.S. I tried to recompile otx (rev 560 from the subversion) w/ 10.7 SDK and standart arch. It will let me load a x86_64 binary, however it crashes upon generating the output. Do I have to have newer otools installed (from the new ML Xcode possibly?) or it's just something on my side of things? ok. nvm, CLI version is sufficient .. something is wrong w/ the GUI one.

 

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.

[Mohamed Khairy]

\x83\x19\xd4\x11 range zeroing-out

 

 

-------

 

when it changed i searched for the thing like it

 

 

83 replaced by 8B

 

this code is near to the codec id that we patch

[DoiX]

@bcc9, Clover problem still persists. I'm not really bothered by it anymore. I didn't think of updating the bios, i'm still on version A06 (the latest one is A11) but probably i still wouldn't have updated because anything newer than A06 breaks sleep for some reason. And i cherish sleep more than UseKernelCache=Yes.

 

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

[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!

[BuXb]

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.