Contribute
Register

New Brightness kext, IntelBacklight.kext

Status
Not open for further replies.
During the process of setting up El Cap on a new install on my T440s I ran into a kernel panic related to IntelBacklight.
Not sure if it will happen again or if the info isn't even useful to you but I figured it couldn't hurt.

Still working on getting USB changes done and rebuilding DSDT with it so it may all be due to not having everything working correctly.
 

Attachments

  • IntelBacklight-Panic.txt
    8 KB · Views: 115
  • ludacrisvp’s MacBook Air.ioreg
    1.4 MB · Views: 100
During the process of setting up El Cap on a new install on my T440s I ran into a kernel panic related to IntelBacklight.
Not sure if it will happen again or if the info isn't even useful to you but I figured it couldn't hurt.

Still working on getting USB changes done and rebuilding DSDT with it so it may all be due to not having everything working correctly.

I feel like this panic is happening due to both the stock backlight handler and yours being loaded together.

during boot you see it abort loading claiming that the patch is missing and then a few seconds later it loads. I have to wonder if this is the issue. (I do have the basic PNLF patch applied to my DSDT)
Code:
Oct  9 22:55:46 ludacrisvps-MacBook-Air kernel[0]: IntelBacklight: IntelBacklightPanel not found (PNLF patch missing?)... aborting
Oct  9 22:56:08 ludacrisvps-MacBook-Air kernel[0]: IntelBacklight: Version 1.0.0d1 starting on OS X Darwin 15.0.
 
I feel like this panic is happening due to both the stock backlight handler and yours being loaded together.

during boot you see it abort loading claiming that the patch is missing and then a few seconds later it loads. I have to wonder if this is the issue. (I do have the basic PNLF patch applied to my DSDT)
Code:
Oct  9 22:55:46 ludacrisvps-MacBook-Air kernel[0]: IntelBacklight: IntelBacklightPanel not found (PNLF patch missing?)... aborting
Oct  9 22:56:08 ludacrisvps-MacBook-Air kernel[0]: IntelBacklight: Version 1.0.0d1 starting on OS X Darwin 15.0.

That log indicates PNLF patch is not implemented correctly...

I'd have to see all info...

Download patchmatic: https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads/RehabMan-patchmatic-2015-0107.zip
Extract the 'patchmatic' binary from the ZIP. Copy it to /usr/bin, such that you have the binary at /usr/bin/patchmatic.

In terminal,
Code:
if [ -d ~/Downloads/RehabMan ]; then rm -R ~/Downloads/RehabMan; fi
mkdir ~/Downloads/RehabMan
cd ~/Downloads/RehabMan
patchmatic -extract

Note: It is easier if you use copy/paste instead of typing the commands manually.

Post contents of Downloads/RehabMan directory (as ZIP).

Also, post ioreg: http://www.tonymacx86.com/audio/58368-guide-how-make-copy-ioreg.html. Please, use the IORegistryExplorer v2.1 attached to the post! DO NOT reply with an ioreg from any other version of IORegistryExplorer.app.

And output from:
Code:
kextstat|grep -y acpiplat
kextstat|grep -y appleintelcpu
kextstat|grep -y applelpc

Also, post EFI/Clover folder.
 
That log indicates PNLF patch is not implemented correctly...
I'd have to see all info...
Download patchmatic
Post contents of Downloads/RehabMan directory (as ZIP).

Also, post ioreg.

And output from:
Code:
kextstat|grep -y acpiplat
kextstat|grep -y appleintelcpu
kextstat|grep -y applelpc

Also, post EFI/Clover folder.

Code:
ludacrisvps-MacBook-Air:~ ludacrisvp$ kextstat|grep -y acpiplat
   13    2 0xffffff7f829ed000 0x66000    0x66000    com.apple.driver.AppleACPIPlatform (4.0) 295F7A91-2DF7-3FFE-9550-A0C1A6F9D575 <12 11 7 6 5 4 3 1>
ludacrisvps-MacBook-Air:~ ludacrisvp$ kextstat|grep -y appleintelcpu
ludacrisvps-MacBook-Air:~ ludacrisvp$ kextstat|grep -y applelpc
  105    0 0xffffff7f82663000 0x3000     0x3000     com.apple.driver.AppleLPC (3.1) 0C90B22D-637B-3000-8C44-B7955D57E10A <88 12 5 4 3>

My testing seems to show that using the basic PNLF patch from your patch repo causes panic nearly every boot when attempting to use this IntelBacklight kext. I removed the basic patch then applied the Haswell/Broadwell combo patch which was made for ACPIBacklight kext, now it doesn't panic at all and my brightness range is much better (exactly what I saw in Yosemite). Meaning that using the basic patch (when I didn't panic) there were only a few brightness levels before it was either MAX or OFF, using the haswell / broadwell patch has a larger ramp of brightness between OFF and MAX and it seems to be a smoother ramp too.

Part of me wonders if part of the issue with the basic patch is that it doesn't apply inside the iGPU (_SB.PCI0.IGPU.PLNF) instead it is just tacked on the end of the DSDT as (_SB.PNLF). You can see this in the Clover/acpi/origin/new mb/2.34/DSDT-pnlf-basic.dsl file compared to the one I'm using now. You can see this difference reflected in the two ioregs that are attached as well. The ignored folder contains all SSDTs that I believed to be of no value to inject as they were CPU related.
 

Attachments

  • ludacrisvp’s MacBook Air - haswell broadwell patch.ioreg
    1.6 MB · Views: 89
  • CLOVER.zip
    4.8 MB · Views: 90
  • RehabMan.zip
    33 KB · Views: 78
  • ludacrisvp’s MacBook Air - pnlf basic patch.ioreg
    1.4 MB · Views: 88
Code:
ludacrisvps-MacBook-Air:~ ludacrisvp$ kextstat|grep -y acpiplat
   13    2 0xffffff7f829ed000 0x66000    0x66000    com.apple.driver.AppleACPIPlatform (4.0) 295F7A91-2DF7-3FFE-9550-A0C1A6F9D575 <12 11 7 6 5 4 3 1>
ludacrisvps-MacBook-Air:~ ludacrisvp$ kextstat|grep -y appleintelcpu
ludacrisvps-MacBook-Air:~ ludacrisvp$ kextstat|grep -y applelpc
  105    0 0xffffff7f82663000 0x3000     0x3000     com.apple.driver.AppleLPC (3.1) 0C90B22D-637B-3000-8C44-B7955D57E10A <88 12 5 4 3>

My testing seems to show that using the basic PNLF patch from your patch repo causes panic nearly every boot when attempting to use this IntelBacklight kext. I removed the basic patch then applied the Haswell/Broadwell combo patch which was made for ACPIBacklight kext, now it doesn't panic at all and my brightness range is much better (exactly what I saw in Yosemite). Meaning that using the basic patch (when I didn't panic) there were only a few brightness levels before it was either MAX or OFF, using the haswell / broadwell patch has a larger ramp of brightness between OFF and MAX and it seems to be a smoother ramp too.

I would have to see the configuration you're using that causes the panic... and ioreg, etc.
The files you provided are not using the basic patch.

Make sure you're rebuilding cache properly.

Boot without caches, then:
Code:
sudo touch /System/Library/Extensions && sudo kextcache -u /

The ignored folder contains all SSDTs that I believed to be of no value to inject as they were CPU related.

Best to include all OEM SSDTs.
 
I would have to see the configuration you're using that causes the panic... and ioreg, etc.
The files you provided are not using the basic patch.

Make sure you're rebuilding cache properly.

Boot without caches, then:
Code:
sudo touch /System/Library/Extensions && sudo kextcache -u /

Best to include all OEM SSDTs.

including all OEM SSDTs causes my power management to not be the X86PlatformPlugin and uses the older style ... at least that is how my system was behaving.

I'm just going to use the more in depth patch that gives me the better range.

this was more of a heads up that you can get panics using the basic patch, there is no more effort needed to use the other more in-depth patch for me.

Should the basic patch apply inside the iGPU rather than being tacked on at the end of the DSDT? could that avoid panics as the PNLF device would be seen at the same time as the iGPU rather than being detected later?
 
including all OEM SSDTs causes my power management to not be the X86PlatformPlugin and uses the older style ... at least that is how my system was behaving.

Include all OEM SSDTs + ssdtPRgen.sh generated SSDT.aml.

I'm just going to use the more in depth patch that gives me the better range.

Same results with IntelBacklight.kext.

this was more of a heads up that you can get panics using the basic patch, there is no more effort needed to use the other more in-depth patch for me.

No panics here. Using the generic patch on several systems, HD3000/HD4000/HD4400.

Should the basic patch apply inside the iGPU rather than being tacked on at the end of the DSDT?

Where it goes is irrelevant.

could that avoid panics as the PNLF device would be seen at the same time as the iGPU rather than being detected later?

The IntelBacklightHandler attaches to the IGPU (based on PCI matching). It waits up to 2 seconds for the IntelBacklightPanel (attaching to PNLF) to show up. Two seconds should be plenty of time. I cannot see where it doesn't bail out gracefully if the PNLF device fails to show up (eg. when people install IntelBacklight.kext, but fail to patch for PNLF).

You're welcome to insert the generic PNLF into IGPU (as the fancier patch) and report back.

You might also try the debug IntelBacklight.kext as I can't seem to correlate the backtrace with code that makes sense in the Release version.

The only thing I can think of is if the system starts trying to set brightness before all the coordination is done between IntelBacklightHandler and IntelBacklightPanel. I would have to think about how to avoid that if that is the case...

Note: ACPIBacklight.kext on 10.11 goes through the startup same process.
 
Hi Rehabman,

After a few days using your new kext, I have this situation that at boot time previous settings are lost and screen brightness is set to maximum which is really annoying. Yes, I read, the comment that you made about losing the preset values...

It would be really handy and solves this issue if you could add the possibility of setting the boot time luminosity thru your RMCF method to a user defined value as opposed to the LMAX. The parameters that are defined there, unless I am mistaken, does not provide such a possibility.

Thanks.

PS:FYI, mine is HD4400.
 
Hi Rehabman,

After a few days using your new kext, I have this situation that at boot time previous settings are lost and screen brightness is set to maximum which is really annoying. Yes, I read, the comment that you made about losing the preset values...

It would be really handy and solves this issue if you could add the possibility of setting the boot time luminosity thru your RMCF method to a user defined value as opposed to the LMAX. The parameters that are defined there, unless I am mistaken, does not provide such a possibility.

Thanks.

PS:FYI, mine is HD4400.

Problem is your NVRAM implementation. Make sure you have Clover setup for correct NVRAM.
 
Kext is only for 10.11+ because in 10.10 it's not working (kext loads i can see that in ioreg)
 
Status
Not open for further replies.
Back
Top