Contribute
Register

Guide To Install Yosemite on HP Laptops with Clover UEFI

cocoa2014 said:
OK, I decided to do a 'fresh install' again to reproduce this problem. I will post related files later. Thank you.

And about system memory, I can't find any option in my BIOS to setup HD4000's memory size. So, I guess, every time the systems boots up, system memory size may change. Is this possible?
Click to expand...

Generally no, it won't change. But any change in BIOS options or a BIOS upgrade can cause SystemMemory addresses to change (not the size, but the location), which are reflected in native DSDT, but not your patched DSDT.

Also, it could have something to do with your using -xcpm. Since Apple does not use XCPM on Ivy CPUs for real Apple products, we should not be surprised if there are bugs when we use it on Ivy.
 
RehabMan said:
Generally no, it won't change. But any change in BIOS options or a BIOS upgrade can cause SystemMemory addresses to change (not the size, but the location), which are reflected in native DSDT, but not your patched DSDT.

Also, it could have something to do with your using -xcpm. Since Apple does not use XCPM on Ivy CPUs for real Apple products, we should not be surprised if there are bugs when we use it on Ivy.
Click to expand...

I have tried boot without -xcpm, it won't boot at all. Maybe the so called 'pstate error' reported previously by other 9470m users. Now, I have to use that flag.

Edit: By the way, I can adjust brightness without ACPIBacklight.kext. What a strange thing.
 
cocoa2014 said:
Thank you for analysing my problem again.I have uploaded something at http://www.tonymacx86.com/hp-proboo...e-hp-laptops-clover-uefi-316.html#post1019665 (#3158)Is it enough?I downloaded Yosemite from Mac App Store.
Click to expand...

Section of backtrace that is related to ACPIBacklight:
Code: 
0xffffff809932bdf0 : 0xffffff7f813be320 
[B]0xffffff809932be10 : 0xffffff7f82838b85 <-- this is what we need to look at...
0xffffff809932be50 : 0xffffff7f82838c37 
0xffffff809932be70 : 0xffffff7f82837c03 [/B]
0xffffff809932bea0 : 0xffffff80008d9d03

Doing math based on:
Code: 
com.darwin.driver.ACPIBacklight(2.0.3)[29388338-9088-340C-80DF-362CB4BEACF6]@0xffffff7f82836000->0xffffff7f82839fff

0xffffff7f82838b85 - 0xffffff7f82836000 = 0x2b85....

So... it maps to this assembly:
Code: 
0000000000002b34	be20000000      	movl	$0x20, %esi
0000000000002b39	e800000000      	callq	__ZN8OSNumber10withNumberEyj
0000000000002b3e	488945d8        	movq	%rax, -0x28(%rbp)
0000000000002b42	4180bed000000000	cmpb	$0x0, 0xd0(%r14)
0000000000002b4a	488d0d27030000  	leaq	0x327(%rip), %rcx       ## literal pool for: "XBCM"
0000000000002b51	488d1d2f030000  	leaq	0x32f(%rip), %rbx       ## literal pool for: "_BCM"
0000000000002b58	480f45d9        	cmovneq	%rcx, %rbx
0000000000002b5c	4885c0          	testq	%rax, %rax
0000000000002b5f	7428            	je	0x2b89
0000000000002b61	498bbe98000000  	movq	0x98(%r14), %rdi
0000000000002b68	488b07          	movq	(%rdi), %rax
0000000000002b6b	488d55e0        	leaq	-0x20(%rbp), %rdx
0000000000002b6f	488d4dd8        	leaq	-0x28(%rbp), %rcx
0000000000002b73	41b801000000    	movl	$0x1, %r8d
0000000000002b79	4531c9          	xorl	%r9d, %r9d
0000000000002b7c	4889de          	movq	%rbx, %rsi
0000000000002b7f	ff90c0080000    	callq	*0x8c0(%rax) ;<<-- this is the call...
[B]0000000000002b85	85c0            	testl	%eax, %eax[/B]  ;<<-- this is the return address

Which maps to this C++ code in ACPIBacklight.kext:
Code: 
void ACPIBacklightPanel::setACPIBrightnessLevel(UInt32 level)
{
    //DbgLog("%s::%s()\n", this->getName(),__FUNCTION__);
    
	OSObject * ret = NULL;
	OSNumber * number = OSNumber::withNumber(level, 32);
    const char* method = _extended ? "XBCM" : "_BCM";

	if (number && kIOReturnSuccess == [B]backLightDevice->evaluateObject(method, &ret, (OSObject**)&number, 1)[/B])
    {
        OSSafeRelease(ret);

        ////DbgLog("%s: setACPIBrightnessLevel %s(%u)\n", this->getName(), method, level);

        // just FYI... set RawBrightness property to actual current level
        setProperty(kRawBrightness, queryACPICurentBrightnessLevel(), 32);
    }
    else
        IOLog("ACPIBacklight: Error in setACPIBrightnessLevel %s(%u)\n",  method, level);
    OSSafeRelease(number);
}

I made the actual call bold.

It is the code which calls _BCM and/or XBCM (XBCM in our case because of the DSDT patching).

So... it is crashing in the bowels of AppleACPIPlatform.kext, which implies some sort of DSDT issue, or lower level issue than that (eg. CPU management).
 
RehabMan said:
Section of backtrace that is related to ACPIBacklight:
Code: 
0xffffff809932bdf0 : 0xffffff7f813be320 
[B]0xffffff809932be10 : 0xffffff7f82838b85 <-- this is what we need to look at...
0xffffff809932be50 : 0xffffff7f82838c37 
0xffffff809932be70 : 0xffffff7f82837c03 [/B]
0xffffff809932bea0 : 0xffffff80008d9d03

Doing math based on:
Code: 
com.darwin.driver.ACPIBacklight(2.0.3)[29388338-9088-340C-80DF-362CB4BEACF6]@0xffffff7f82836000->0xffffff7f82839fff

0xffffff7f82838b85 - 0xffffff7f82836000 = 0x2b85....

So... it maps to this assembly:
Code: 
0000000000002b34    be20000000          movl    $0x20, %esi
0000000000002b39    e800000000          callq    __ZN8OSNumber10withNumberEyj
0000000000002b3e    488945d8            movq    %rax, -0x28(%rbp)
0000000000002b42    4180bed000000000    cmpb    $0x0, 0xd0(%r14)
0000000000002b4a    488d0d27030000      leaq    0x327(%rip), %rcx       ## literal pool for: "XBCM"
0000000000002b51    488d1d2f030000      leaq    0x32f(%rip), %rbx       ## literal pool for: "_BCM"
0000000000002b58    480f45d9            cmovneq    %rcx, %rbx
0000000000002b5c    4885c0              testq    %rax, %rax
0000000000002b5f    7428                je    0x2b89
0000000000002b61    498bbe98000000      movq    0x98(%r14), %rdi
0000000000002b68    488b07              movq    (%rdi), %rax
0000000000002b6b    488d55e0            leaq    -0x20(%rbp), %rdx
0000000000002b6f    488d4dd8            leaq    -0x28(%rbp), %rcx
0000000000002b73    41b801000000        movl    $0x1, %r8d
0000000000002b79    4531c9              xorl    %r9d, %r9d
0000000000002b7c    4889de              movq    %rbx, %rsi
0000000000002b7f    ff90c0080000        callq    *0x8c0(%rax) ;<<-- this is the call...
[B]0000000000002b85    85c0                testl    %eax, %eax[/B]  ;<<-- this is the return address

Which maps to this C++ code in ACPIBacklight.kext:
Code: 
void ACPIBacklightPanel::setACPIBrightnessLevel(UInt32 level)
{
    //DbgLog("%s::%s()\n", this->getName(),__FUNCTION__);
    
    OSObject * ret = NULL;
    OSNumber * number = OSNumber::withNumber(level, 32);
    const char* method = _extended ? "XBCM" : "_BCM";

    if (number && kIOReturnSuccess == [B]backLightDevice->evaluateObject(method, &ret, (OSObject**)&number, 1)[/B])
    {
        OSSafeRelease(ret);

        ////DbgLog("%s: setACPIBrightnessLevel %s(%u)\n", this->getName(), method, level);

        // just FYI... set RawBrightness property to actual current level
        setProperty(kRawBrightness, queryACPICurentBrightnessLevel(), 32);
    }
    else
        IOLog("ACPIBacklight: Error in setACPIBrightnessLevel %s(%u)\n",  method, level);
    OSSafeRelease(number);
}

I made the actual call bold.

It is the code which calls _BCM and/or XBCM (XBCM in our case because of the DSDT patching).

So... it is crashing in the bowels of AppleACPIPlatform.kext, which implies some sort of DSDT issue, or lower level issue than that (eg. CPU management).
Click to expand...

Super... :)
 
cocoa2014 said:
I have done a fresh install, and reproduced this problem. New trouble shoot files are also uploaded.
If I can help more, I will always be available.

View attachment 134047
View attachment 134048
Click to expand...

Same crash. I don't think a bug in ACPIBacklight.kext, but rather problem in lower level... The only thing I can think of changing in this code is to do the ACPI call in the workloop thread instead of whatever thread doIntegerSet is called on. I don't have time to make the required code changes right now though...

SystemMemory addresses match between origin and patched, so must be some other issue.

Given that you're the only one with this issue... and your machine is the only Ivy machine that we use -xcpm on...

Suspect power management problem/ XCPM...

Some things to try:
- install all kexts to /S/L/E (using injection for the main install is not a good idea)
- change config.plist/SSDT/DropOem=false (this will inject the OEM SSDTs, resulting in a more complete PM setup)
- remove -xcpm from config.plist/Boot/Arguments
- you may need to change SMBIOS (try MacBookPro9,1 or MacBookPro9,2)
 
Hi ,
Sleep function doesn't work on my laptop, is that common? Even when I put manualy (apple+sleep) it does not slepp att all.

View attachment Leo Mackie.ioreg
 
powbhz said:
Hi ,
Sleep function doesn't work on my laptop, is that common? Even when I put manualy (apple+sleep) it does not slepp att all.

View attachment 134067
Click to expand...

Did you wait long enough?

Did you check for assertions? ("pmset -g assertions" in Terminal)
 
On my Probook 6470b the HWMonitor icon in menubar is invisible after updating to 10.10.3 ?

But HWMonitor is still working

Update.
Using Killall Dock in terminal the icon turned visible :)
 
arehep said:
On my Probook 6470b the HWMonitor icon in menubar is invisible after updating to 10.10.3 ?

But HWMonitor is still working
Click to expand...

same here ..just change thr icon
 
You must log in or register to reply here.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top