1148 replies to this topic

[olegpronin]

1736315[/url]']
I have yet to ever get Sleep/Resume to ever work on either SL or Lion. I have everything else working. What variations of each kexts are you using to using it to work?

I understood right that sleep does not work for you? Post here kernel log.

• Something seems wrong with the IOAHCISerialATAPI driver. Upon wakeup from suspend the disk activity light flashes every 2 seconds or so apparently with the driver trying to stat the dvd-rom drive. Putting a disk in the drive fixes this.

Does it still a problem? I have no this issue.

[bcc9]

I have yet to ever get Sleep/Resume to ever work on either SL or Lion. I have everything else working. What variations of each kexts are you using to get it to work?

If you follow post #1, then sleep works in 10.6 for all releases. Sleep also works in 10.5 &10.7...

[bcc9]

Here is a patched DSDT for lion.
This version fixes the UPBI and UPBS methods for dynamic battery status.
(VoodooBattery now works with this DSDT). There should no longer be any temptation to use a rolled-back version of AppleACPIPlatform. (In general I recommend avoiding mixing&matching of system kexts from different OSX releases, even though hackintosh users often do this. You never know what problems you're introducing with mismatched kexts).

I've also removed almost all of the graphics injection strings, as chameleon rc5 has been handling the injection of these for a while now. When I originally wrote the graphics injection strings, chameleon did not have code to dynamically compute NVCAP like it does now. So, be sure to configure <key>GraphicsEnabler</key><string>Yes</string> as well as <key>PCIRootUID</key> <string>1</string> in your com.apple.Boot.plist.

Does it still a problem? I have no this issue.

You're right, I'm not seeing the disk-activity light problem after resume from suspend anymore. I wonder when that got fixed...

Edit: new version of this dsdt in the 10.7 thread:
http://www.insanelym...howtopic=272546

[olegpronin]

ok, I can confirm, now it works with lion's GPE-patched appleacpiplatform kext + voodoobattery. But I don't like voodoobattery actually - it injects ACAdapter too and mainly the starting of mac is much longer than with AppleACPIBattery kext...

Btw, AppleACPIBattery.kext panics at the start or random panics after system startup with patched AppleACPIPlatform from Lion. (but as I understand, it's the problem if AppleACPIBattery kext.)

Thanks a lot for fixing DSDT, there genius things were done.

update. I found that you added hdmi sound thing, thank you. Anyway I continue to use the voodoohda driver because it has no problems with volume (nvram thing bugs - here the video record what I'm talking about, only Russian interface, but you'll understand all. http://cl.ly/0y0q3L3M3O1t0N2x1D1P ). I still have no idea why AppleHDA has these problems.

[bcc9]

ok, I can confirm, now it works with lion's GPE-patched appleacpiplatform kext + voodoobattery. But I don't like voodoobattery actually - it injects ACAdapter too and mainly the starting of mac is much longer than with AppleACPIBattery kext...

Can you explain? I haven't noticed any startup time differences between using VoodooBattery vs not using anything.
I'm not attached to Voodoobattery, can you point me to the source code for appleacpibattery & the current release, so that I can compare? I couldn't find the source last I checked.
It would be nice if there was a fully working replacement for voodoobattery as I don't like depending upon abandon-ware.

Btw, AppleACPIBattery.kext panics at the start or random panics after system startup with patched AppleACPIPlatform from Lion. (but as I understand, it's the problem if AppleACPIBattery kext.)

So it sounds like VoodooBattery is clearly the way to go at least until someone troubleshoots that.

Thanks a lot for fixing DSDT, there genius things were done.

Thanks, figuring out that the battery status update methods needed to be rewritten to do 8 bit I/O to avoid the "Method parse/execution failed" errors was a key part...

update. I found that you added hdmi sound thing, thank you.

hdmi audio won't actually work however, as av-signal-type is failing to be set to 0x8 as required. If someone could figure this final piece out they'd be my hero

Anyway I continue to use the voodoohda driver because it has no problems with volume (nvram thing bugs - here the video record what I'm talking about, only Russian interface, but you'll understand all. http://cl.ly/0y0q3L3M3O1t0N2x1D1P ). I still have no idea why AppleHDA has these problems.

Hmm, I hadn't noticed volume problems with AppleHDA. Sure enough, looks a little buggy. I always just adjust the volume using the dell hotkeys on this laptop which works OK.

[olegpronin]

Can you explain? I haven't noticed any startup time differences between using VoodooBattery vs not using anything.
I'm not attached to Voodoobattery, can you point me to the source code for appleacpibattery & the current release, so that I can compare? I couldn't find the source last I checked.
It would be nice if there was a fully working replacement for voodoobattery as I don't like depending upon abandon-ware.

I have no explanation.. When I used AppleACPIBattery, it started very quickly. When VooodooBattery - before launching the interface it freezes a little (no hdd led), after 4-5 seconds it starts and works normal.

I decided to delete AC Adapter inject from VooodooBattery and added it to DSDT using Method _PRW. I don't know if it's better or not, start up still the same.
Sources of latest AppleACPIBattery was attached.

Thanks, figuring out that the battery status update methods needed to be rewritten to do 8 bit I/O to avoid the "Method parse/execution failed" errors was a key part...

yes, I figured it out in your DSDT. Very good research!

hdmi audio won't actually work however, as av-signal-type is failing to be set to 0x8 as required. If someone could figure this final piece out they'd be my hero smile.gif

Can't help with HDMI since I have no device with HDMI at all here

Hmm, I hadn't noticed volume problems with AppleHDA. Sure enough, looks a little buggy. I always just adjust the volume using the dell hotkeys on this laptop which works OK.

Did you try to do the same thing like in the video?
One more thing - when laptop is just turned up, I don't know why, but at first start of changing volumes, it jumps always to maximum position.

UPDATE. Incredible! I searched a little in internet and found AppleACPIBattery kext for lion. yes, I know it doesn't show the information in profile, but the startup is more quickly.

Attached kext.

UPDATE2. I think it was my bad about AppleACPIBattery - I believe the previous kext was compiled in the old SDK. That's why it had KP.

UPDATE3. bcc9, but if you can look on the sources and check out why error when collecting system information about battery and fix it, will be superb!

Attached Files

•  AppleACPIBatteryManager.source.zip   62.37KB   72 downloads
•  1498_AppleACPIBatteryManager.kext.zip   36.16KB   148 downloads

[bcc9]

Did you try to do the same thing like in the video?

Yes, I can see that the menu bar volume slider doesn't match the one in system preferences->audio. But I said I don't use the menu bar slider, I use the dell volume hotkeys. Those hotkeys (and the OSD for the volume) DO track the system preferences->audio slider properly.

So your problem seems to be rather cosmetic, or at least there is a good workaround, and I wouldn't ditch AppleHDA just for that.
VoodooHDA is a problem since slice stated long ago that he has stopped supporting it (and there have been no updates since). When possible, I'd rather use a kext that is supported by apple than one that was hacked from freebsd and isn't support by anyone.

[olegpronin]

This is not a cosmetic. I don't want to discuss much about it, we use what we want to use just one thing - slice still uses voodoohda and doesn't plan to move back.

I use sometimes different audio software and this glitch kills me, because yes I use the Sensor keyboard and programs use system pref changing volume. Each time after I used volume in pref, first time pressing on sensor board gives me maximum volume and doesn't matter that volume was before.

[Cyrus the Great]

Here is a patched DSDT for lion.
This version fixes the UPBI and UPBS methods for dynamic battery status.
(VoodooBattery now works with this DSDT). There should no longer be any temptation to use a rolled-back version of AppleACPIPlatform.

hi bbc9 thanks for your genuine discovery
my laptop is hp dv6-1125 and i am try to replace my bat0 section with one from your dsdt but not work for me .i can not understand with section of my bat0 must be changed plz can look in my dsdt.
thanks for your help.

Attached Files

•  DSDT.aml.zip   21.54KB   30 downloads

[bcc9]

hi bbc9 thanks for your genuine discovery
my laptop is hp dv6-1125 and i am try to replace my bat0 section with one from your dsdt but not work for me .i can not understand with section of my bat0 must be changed plz can look in my dsdt.
thanks for your help.

In your DSDT, look at for example, in the UPBI method, the Store operations. In these operations:
Store (^^PCI0.LPC.EC0.BTDC, Index (PBIF, One))
Store (^^PCI0.LPC.EC0.BATV, Index (PBIF, 0x04))
you're referencing the field definitions:
BTDC, 16,
BATV, 16,
which are 16 bit. Per the ACPI spec, the EmbeddedControl region must use byte access. So you rewrite those fields as pairs of 8 bit fields and do the access byte at a time. Take a look at the differences in my dsdt for the BTDC, BTFC, BTCT, BTRC, BTPV fields for examples on how to do this. I don't have time to do these edits for other platforms myself.

[Cyrus the Great]

thanks for your help.
i am do it but it seems the solutions not work with hp.

[bcc9]

thanks for your help.
i am do it but it seems the solutions not work with hp.

Since it's clear from your DSDT that your system is attempting 16bit I/O for the battery status, it seems like you have exactly the same problem.

[Cyrus the Great]

Since it's clear from your DSDT that your system is attempting 16bit I/O for the battery status, it seems like you have exactly the same problem.

i split all 16 bit refrence to 8 bit and add it to bat section but after reboot again no battery available

[juanerson]

In your DSDT, look at for example, in the UPBI method, the Store operations. In these operations:
Store (^^PCI0.LPC.EC0.BTDC, Index (PBIF, One))
Store (^^PCI0.LPC.EC0.BATV, Index (PBIF, 0x04))
you're referencing the field definitions:
BTDC, 16,
BATV, 16,
which are 16 bit. Per the ACPI spec, the EmbeddedControl region must use byte access. So you rewrite those fields as pairs of 8 bit fields and do the access byte at a time. Take a look at the differences in my dsdt for the BTDC, BTFC, BTCT, BTRC, BTPV fields for examples on how to do this. I don't have time to do these edits for other platforms myself.

THANK YOU SO MUCH... it worked perfect in my dsdt, now I have battery support in Lion & Snow, so this is certainly "the real fix" as you said my friend. Also I want to say, THANK YOU AGAIN for all your contributions, Legend. God bless you.

[bcc9]

THANK YOU SO MUCH... it worked perfect in my dsdt, now I have battery support in Lion & Snow, so this is certainly "the real fix" as you said my friend. Also I want to say, THANK YOU AGAIN for all your contributions, Legend. God bless you.

Awesome. It's good to hear back on some success (when all one hears about is failures it makes you wonder if you're missing something).

[JBraddock]

In your DSDT, look at for example, in the UPBI method, the Store operations. In these operations:
Store (^^PCI0.LPC.EC0.BTDC, Index (PBIF, One))
Store (^^PCI0.LPC.EC0.BATV, Index (PBIF, 0x04))
you're referencing the field definitions:
BTDC, 16,
BATV, 16,
which are 16 bit. Per the ACPI spec, the EmbeddedControl region must use byte access. So you rewrite those fields as pairs of 8 bit fields and do the access byte at a time. Take a look at the differences in my dsdt for the BTDC, BTFC, BTCT, BTRC, BTPV fields for examples on how to do this. I don't have time to do these edits for other platforms myself.

When I look at the methods used under Device (BAT0), I can see the followings:

In the UPBI method:

Store (^^PCI0.LPC.EC0.BCLB, Local0)
Store (^^PCI0.LPC.EC0.BCHB, Local1)
***
Store (^^PCI0.LPC.EC0.BVLB, Local0)
Store (^^PCI0.LPC.EC0.BVHB, Local1)

When I check BCLB, BCHB, BVLB and BVHB in Device (EC0), they already have 8 as the value:

BCLB,   8, 
		 BCHB,   8, 
					  Offset (0x74), 
		 BVLB,   8, 
		 BVHB,   8, 
					 Offset (0x7E),

This is the UPBS method:

Method (UPBS, 0, NotSerialized)
			{
				Store (^^PCI0.LPC.EC0.MBST, Index (PBST, Zero))
				^^PCI0.LPC.EC0.SMRD (0x09, 0x16, 0x0A, RefOf (Local0))
				Store (Local0, Index (PBST, One))
				^^PCI0.LPC.EC0.SMRD (0x09, 0x16, 0x0F, RefOf (Local1))
				Store (Local1, Index (PBST, 0x02))
				^^PCI0.LPC.EC0.SMRD (0x09, 0x16, 0x09, RefOf (Local2))
				Store (Local2, Index (PBST, 0x03))
			}

Am I doing something wrong? May be my problem is related to something else?

Thanks,

[bcc9]

Am I doing something wrong? May be my problem is related to something else?

There's no way for anyone to tell for sure from those limited fragments.... Make sure none of the fields accessed from the embedded controller are > 8 bits, not just under the UPBI method.

[Cyrus the Great]

hi bcc9
i find that this value refer to 16 bit also but how can i split it to 8 bit:MBRM

Store (^^PCI0.LPC.EC0.MBRM, Local5)
				If (LNot (And (Local5, 0x8000)))
				{

and also when changing MBRM this is refer to it how can i fix it:

If (LLessEqual (^^PCI0.LPC.EC0.MBRM, 0x96))
							{
								Store (Zero, Local0)
							}

thanks for your help

[olegpronin]

Latest chameleon RC5 trunk, edited for Lion hibernation support. test please.<br /><br />for disabling secure vm write this:<br /><br />

sudo defaults write /Library/Preferences/com.apple.virtualMemory DisableEncryptedSwap -boolean yes

<br />and restart

Update. Work all good.

Attached Files

•  i386.zip   928.19KB   29 downloads

[JBraddock]

There's no way for anyone to tell for sure from those limited fragments.... Make sure none of the fields accessed from the embedded controller are > 8 bits, not just under the UPBI method.

Thank you. I'll keep looking.