27 June 2010

HPM311DP_061810HF6RC3, 10.6.4 and Internal Mic Problem

from gearlive.com
After spending more time to observe and test my Mini MacBook 311, I can verify problems with the external mic no longer working is not caused by 10.6.4.

Apparently, even if VoodooHDA's necessary dependencies were put in EFI /Extra/Extensions and the kext is indeed able to load and provide system sound, it being not in /System/Library/Extensions causes internal mic to not function.

So that means it's my fault. Actually HPM311DP_061810HF6RC3.pkg, on its own, can hardly be blamed cause it only puts a new Extra folder in EFI containing all the kexts with the additional VoodooHDA related stuff. It does NOT run any scripts that touch /System/Library/Extensions. If you remember the experiment I had sought people's help to test, VoodooHDA needed to be manually eliminated in /System/Library/Extensions with the help of Kext Utility to wrap things up nicely. My apologies for making you test but I deeply appreciated the feedback of those who participated and signaled this issue with the internal mic.

I guess this means, VoodooHDA cannot ever be placed outside of /System/Library/Extensions. :(

Now there are other things I've discovered: my shirking from putting kexts in /S/L/E is entirely rooted in my not so good issues with putting PS2 Controller kexts (ApplePS2 and VoodooPS2) in that location. It caused me kernel panics. 

The current HP Mini 311 PS2 Controllers should not be placed in /S/L/E in my opinion.

Sure, VoodooHDA caused its own share of KP's when put in /S/L/E but I've now discovered that removing CHUD resulted in a more stable system.

In short, we'd just have to make sure we have Retail Pack 0.9 kexts.
1. Download Retail Pack 0.9 and unzip it.
2. Mount EFI:
$ mkdir /Volumes/EFI
$ mount_hfs /dev/disk0s1 /Volumes/EFI
Or if you're not comfortable with Terminal, you can use Alter EFI v1.3 to mount EFI. IMPORTANT: Choose the "Edit kexts" option.
3. Copy the (entire) "Extra" folder from Retail Pack 0.9 and paste it inside EFI. To verify, your EFI root volume should contain two things: (1) boot (2) Extra folder
4. Umount EFI;
$ umount -f /dev/disk0s1
$ rm -rf /Volumes/EFI
Or if you used Alter EFI to do the mounting for you, just click on "Done" on Alter EFI to umount EFI.
5. Copy VoodoHDA.kext from Retail Pack 0.9's kexts folder and paste it in /Sytem/Library/Extensions.
6. Run Kext Utility.
7. Restart.


Anonymous said...

Will you release a new easy-to-install package that performs all that ?

LeMaurien19 said...

^Sorry about that, I was actually having problems with the latest version of Package Maker. But today I'm finally able to create a packaged installer.


Kindly please post feedbacks here. Thanks!

jovy said...

wait, does this mean we dont have to install anything, if we have a working 10.6.3 install? do we just make sure that the files in the retail pack 0.9 is in the efi/extra volume?

thanks in advance.


i updated to 10.6.4 and i just dropped the sleepenabler.kext in the efi/extra folder and havent had any problems since.

LeMaurien19 said...

I'd go with making sure Retail Pack 0.9 is in the EFI volume.

And also, sorry for the confusion, we Mini 311 Mini MacBookers DO NOT need SleepEnabler.kext - neither in /S/L/E nor EFI.
This is because sleep functionality is already taken care of by AppleIntelCPUPowerManagement - it's a native/vanilla Apple kext and it's also what covers sleep and other power/cpu related stuff in real Macs. Before we had to use separate kexts as substitute for this AppleIntelCPUPwrMgmt - VoodooPowerMini, SleepEnabler, Disabler (to prevent this native Apple kext to load). But now, we've reached a new frontier with meklort's CPUIDOverride and CPUIDInject kexts and of course with MowgliBook's DSDT.aml, and so we don't need SleepEnabler anymore.

I was pertaining to the HP Mini 1001TU when I mentioned SleepEnabler. (I know, I'm really sorry, it's all getting mixed up in my head with 2 platforms to maintain)

Though from your experience, SleepEnabler doesn't seem to cause any harm, I still suggest removing it.

Also, it would be better to make sure that the Extensions folder and Extensions.mkext that you're using are the exact same ones from Retail Pack 0.9.
There's an issue with previous releases (as far back as the 1st theproto release upto HF6RC2) in terms of how they create the Extensions.mkext in EFI - it causes, for me at least, blank screen on wake with graphical boot mode in 10.6.3 up.

This newer HF6RC4 does not have this Extensions.mkext issue.

Anonymous said...

Will ethernet work now after returning from sleep?

Anonymous said...

I was under 10.6.2 and updated to 10.6.4 with HPM311DP_063010HF6RC4.

This is what I noticed:

- I can only boot successfully in verbose mode (not a problem for me) exactly as before.

- No more speedstep when idle (big problem for battery life). This was working in 10.6.2.

Any advice about these issues?

LeMaurien19 said...

^SpeedStep is still working. We're using DSDT hack where the CPU's P-states are coded. It's just that CPU-X does not detect it. Use MSR Tools instead.
See "Actual Frequency".

Anonymous said...

Thank you, I was indeed using CPU-X.
I found a Snow Leo version of MSR TOOLS here :


It indeed shows speedstep working up and down under 10.6.4.

Ethernet is still dead after resuming from sleep, just as before (sad).

Overall, this was a flawless update, then. :-)

I am impatient to start testing the H264 hardware acceleration support in 10.6.4 !!!

LeMaurien19 said...

Do keep us informed on your H.264 experiment :D

Anonymous said...

Well, it worked fine, using PLEX and an especially optimized Plex executable : full 1080p MKV playback with little cpu usage, as advertised.
I did not try HDMI, though.