Contribute
Register

battery icon confused about (un)plugged state when full

Status
Not open for further replies.
romanaOne

romanaOne

Joined
Aug 3, 2014
Messages
101
Motherboard
Thinkpad T440p
CPU
i7-4710MQ (replaced stock i5)
Graphics
HD4600
Mac
  1. MacBook
  2. MacBook Pro
Classic Mac
  1. Power Mac
  2. PowerBook
Mobile Phone
  1. Android
  2. Other
Sometimes when running for a long time plugged in, it decides it is not plugged in. Unplugging the power and plugging it back in corrects it but rebooting does not. It does not immediatedly happen just as the battery icon reaches 100% but can go hours plugged in so I'm not sure "Logic bug with charging/discharging status (AC adapter detection)" applies.

I didn't patch anything battery-related. There is no FBST method, so I'm not sure what is needed to fix this.

I also have some external display quirkiness: if I boot with HDMI monitor attached, the built-in display is black. After sleep, it is fixed: both displays look fine.

I recently upgraded to from,err, legacy methods to WhateverGreen so there may be some cruft I forgot to remove in config.plist.
Both of these quirks were present before the upgrade.
 

Attachments

  • CLOVER.zip
    1.9 MB · Views: 70
  • IOReg.zip
    657.8 KB · Views: 50
  • kextcache_out.zip
    1.1 KB · Views: 58
  • kextstat_pmset_out.zip
    1.6 KB · Views: 62
  • patchmatic_out.zip
    43.2 KB · Views: 55
romanaOne said:
Sometimes when running for a long time plugged in, it decides it is not plugged in. Unplugging the power and plugging it back in corrects it but rebooting does not. It does not immediatedly happen just as the battery icon reaches 100% but can go hours plugged in so I'm not sure "Logic bug with charging/discharging status (AC adapter detection)" applies.

I didn't patch anything battery-related. There is no FBST method, so I'm not sure what is needed to fix this.

I also have some external display quirkiness: if I boot with HDMI monitor attached, the built-in display is black. After sleep, it is fixed: both displays look fine.

I recently upgraded to from,err, legacy methods to WhateverGreen so there may be some cruft I forgot to remove in config.plist.
Both of these quirks were present before the upgrade.
Click to expand...
"Problem Reporting" files are incomplete (old files in ACPI/origin).
Read FAQ, "Problem Reporting" again. Carefully. Attach all requested files/output.
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/
Use the gen_debug.sh tool mentioned in the FAQ, that way it is less likely you'll omit something.
 
gen_debug.sh output files attached.
 

Attachments

  • debug_28247.zip
    1.9 MB · Views: 81
romanaOne said:
gen_debug.sh output files attached.
Click to expand...

You should debug your AC adapter object (_PSR method).
You can use ACPIDebug.kext to see if it is being called and what it is returning.
Refer to the ACPI specification for details.
 
So I tried debugging....
Never done this before, so I just put \RMDT.PUSH("start_PSR") at the beginning of _PSR and rebooted to test.

While the system is booted plugged-in but thinks it is unplugged, I noticed this ACPI Error in the system log right after _PSR begins (By "system log," I mean output of log show --last 10m --debug --info):

Code: 
2018-11-25 11:00:26.189582-0500 0xcb       Default     0x0                  0      0    kernel: (ACPIDebug) ACPIDebug: "start _PSR"
2018-11-25 11:00:26.190740-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2018-11-25 11:00:26.190741-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2018-11-25 11:00:26.190743-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [\_PR_.CPU0._PSS]
2018-11-25 11:00:26.190744-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [\_PR_.CPU0._PSS]
2018-11-25 11:00:26.190746-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_NOT_FOUND
2018-11-25 11:00:26.190747-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_NOT_FOUND
2018-11-25 11:00:26.190749-0500 0x76       Default     0x0                  0

In the DSDT, _PSR calls ADJP which wants \_PR_.CPU0._PSS.

Not in my current DSDT and SSDTs, so I tried grep _PSS /EFI/CLOVER/ACPI/origin/*.aml and it looks like there is _PSS in /EFI/CLOVER/ACPI/origin/SSDT-x2_0-Cpu0Ist.aml. Disassembly reveals a _PSS method in scope \_PR.CPU0 and more warnings about unresolved External refs, but deal with them when/if I get more ACPI errors.... So just I threw SSDT-x2_0-Cpu0Ist.aml in /EFI/CLOVER/ACPI/patched and rebooted a couple of times. Seems to be correctly detecting the AC adapter at boot now, no ACPI errors so far with the plug in or out. Left it plugged in for a few hours at 100 percent charge; still ok.

Solved, I think.

Looks like other Clevo (System76 customizes and sticks their name on laptops made by Clevo) owners have also had trouble with _PSR and AC Adapter : https://forums.gentoo.org/viewtopic-t-737975.html
 
romanaOne said:
So I tried debugging....
Never done this before, so I just put \RMDT.PUSH("start_PSR") at the beginning of _PSR and rebooted to test.

While the system is booted plugged-in but thinks it is unplugged, I noticed this ACPI Error in the system log right after _PSR begins (By "system log," I mean output of log show --last 10m --debug --info):

Code: 
2018-11-25 11:00:26.189582-0500 0xcb       Default     0x0                  0      0    kernel: (ACPIDebug) ACPIDebug: "start _PSR"
2018-11-25 11:00:26.190740-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2018-11-25 11:00:26.190741-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform) ACPI Error:
2018-11-25 11:00:26.190743-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [\_PR_.CPU0._PSS]
2018-11-25 11:00:26.190744-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform) [\_PR_.CPU0._PSS]
2018-11-25 11:00:26.190746-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_NOT_FOUND
2018-11-25 11:00:26.190747-0500 0x76       Default     0x0                  0      0    kernel: (AppleACPIPlatform)  Namespace lookup failure, AE_NOT_FOUND
2018-11-25 11:00:26.190749-0500 0x76       Default     0x0                  0

In the DSDT, _PSR calls ADJP which wants \_PR_.CPU0._PSS.

Not in my current DSDT and SSDTs, so I tried grep _PSS /EFI/CLOVER/ACPI/origin/*.aml and it looks like there is _PSS in /EFI/CLOVER/ACPI/origin/SSDT-x2_0-Cpu0Ist.aml. Disassembly reveals a _PSS method in scope \_PR.CPU0 and more warnings about unresolved External refs, but deal with them when/if I get more ACPI errors.... So just I threw SSDT-x2_0-Cpu0Ist.aml in /EFI/CLOVER/ACPI/patched and rebooted a couple of times. Seems to be correctly detecting the AC adapter at boot now, no ACPI errors so far with the plug in or out. Left it plugged in for a few hours at 100 percent charge; still ok.

Solved, I think.

Looks like other Clevo (System76 customizes and sticks their name on laptops made by Clevo) owners have also had trouble with _PSR and AC Adapter : https://forums.gentoo.org/viewtopic-t-737975.html
Click to expand...

I would suggest just simplifying _PSR:
Code: 
            Method (_PSR, 0, NotSerialized)  // _PSR: Power Source
            {
                Return (ACFG)
            }
 
Code: 
 Method (_PSR, 0, NotSerialized)  // _PSR: Power Source
            {
                If (LEqual (^^WMI.HKDR, Zero)) //WMI: Some Windows thing?
                {
                    If (LOr (\_TZ.TZ0.PPFG, LOr (^^PCI0.LPCB.EC.B15C, GPSF))) {}
                    ElseIf (And (PSF1, 0x30))
                    {
                        ADJP (Zero) //What's this? ADJP not in the ACPI spec.
                    }
                }

                Return (ACFG)
            }

Ok, it works fine when I recompile DSDT with only Return (ACFG) in _PSR. So now I have DSDT.aml in my patched folder.

Just for fun, I took out the patched DSDT and I'm trying it as a Clover patch instead:

find:
00 ADJP (Zero)
00 41 44 4A 50 00

and replace it with
00 Return (ACFG)
00 A4 41 43 46 47

I had to prepend 00 to make the patch only match the ADJP(Zero) in _PSR. (All other calls to ADJP (Zero) have something not 00 before them.)
 
romanaOne said:
Code: 
 Method (_PSR, 0, NotSerialized)  // _PSR: Power Source
            {
                If (LEqual (^^WMI.HKDR, Zero)) //WMI: Some Windows thing?
                {
                    If (LOr (\_TZ.TZ0.PPFG, LOr (^^PCI0.LPCB.EC.B15C, GPSF))) {}
                    ElseIf (And (PSF1, 0x30))
                    {
                        ADJP (Zero) //What's this? ADJP not in the ACPI spec.
                    }
                }

                Return (ACFG)
            }

Ok, it works fine when I recompile DSDT with only Return (ACFG) in _PSR. So now I have DSDT.aml in my patched folder.

Just for fun, I took out the patched DSDT and I'm trying it as a Clover patch instead:

find:
00 ADJP (Zero)
00 41 44 4A 50 00

and replace it with
00 Return (ACFG)
00 A4 41 43 46 47

I had to prepend 00 to make the patch only match the ADJP(Zero) in _PSR. (All other calls to ADJP (Zero) have something not 00 before them.)
Click to expand...

I would recommend using rename/replace pattern, as documented in my ACPI hotpatch guide.
 
So the ADJP --> XDJP (extra bytes to ensure matching only ADJP in _PRS) is:
find:
00 ADJP (Zero)
00 41 44 4A 50 00

and replace it with
00 XDJP (Zero)
00 58 44 4A 50 00

I'm not sure about variable type and scope below. Err, it compiles.
Is ACFG an integer? Why this "Name(ACFG, One)" rigamorole? Does it just mean ACFG = 1?

iasl complains that Arg0 is never used. I guess that's ok, since XDJP just returns ACFG no matter what.
Code: 
DefinitionBlock("", "SSDT", 2, "hack", "_XDJP", 0)
{

 External(_SB.AC.ACFG, IntObj)
 Method (_SB.AC.XDJP, 1, Serialized)  // XDJP: change ADJP to not fail
            {
                Return (ACFG)
            }
}
//EOF
 
romanaOne said:
So the ADJP --> XDJP (extra bytes to ensure matching only ADJP in _PRS) is:
find:
00 ADJP (Zero)
00 41 44 4A 50 00

and replace it with
00 XDJP (Zero)
00 58 44 4A 50 00

I'm not sure about variable type and scope below. Err, it compiles.
Is ACFG an integer? Why this "Name(ACFG, One)" rigamorole? Does it just mean ACFG = 1?

iasl complains that Arg0 is never used. I guess that's ok, since XDJP just returns ACFG no matter what.
Code: 
DefinitionBlock("", "SSDT", 2, "hack", "_XDJP", 0)
{

 External(_SB.AC.ACFG, IntObj)
 Method (_SB.AC.XDJP, 1, Serialized)  // XDJP: change ADJP to not fail
            {
                Return (ACFG)
            }
}
//EOF
Click to expand...

My suggestion was to use rename/replace on _PSR, not AGDP.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top