Re: [acpi] patch for embedded controller detection
On Sat, Oct 08, 2022 at 03:10:18PM +0300, Mikhail wrote:
> I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on
> latest -current it shows that battery is absent and AC not connected:
>
> Battery state: absent, 0% remaining, unknown life estimate
> AC adapter state: not connected
> Performance adjustment mode: manual (2900 MHz)
Thinking about this a little bit more, I thought that we can just check
if EC_ID from ECDT is actually present, and if it's not - fail the
attach.
With the patch I see two ECs in my dmesg:
acpiec0 at acpi0
acpiec0: failed to find EC_ID
acpiec0: Failed to read resource settings
[...]
acpiec1 at acpi0
which is of course wrong.
But these things works:
- apm status
- capslock led
- brightness keys
diff /usr/src
commit - 924a158ae16809f41bf3f03c54fb2a8cdfa1d6e8
path + /usr/src
blob - 5ef24d5179de52d5321e578b3b73dd9524e7c1de
file + sys/dev/acpi/acpiec.c
--- sys/dev/acpi/acpiec.c
+++ sys/dev/acpi/acpiec.c
@@ -429,6 +429,14 @@ acpiec_getcrs(struct acpiec_softc *sc, struct acpi_att
/* Check if this is ECDT initialization */
if (ecdt) {
+ /* Get devnode from header */
+ sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root,
+ ecdt->ec_id);
+ if (sc->sc_devnode == NULL) {
+ printf("%s: failed to find EC_ID\n", DEVNAME(sc));
+ return (1);
+ }
+
/* Get GPE, Data and Control segments */
sc->sc_gpe = ecdt->gpe_bit;
@@ -444,10 +452,6 @@ acpiec_getcrs(struct acpiec_softc *sc, struct acpi_att
sc->sc_data_bt = sc->sc_acpi->sc_memt;
sc->sc_ec_data = ecdt->ec_data.address;
- /* Get devnode from header */
- sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root,
- ecdt->ec_id);
-
goto ecdtdone;
}
Re: [acpi] patch for embedded controller detection
On Sat, Oct 08, 2022 at 03:10:18PM +0300, Mikhail wrote:
> I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on
> latest -current it shows that battery is absent and AC not connected:
>
> Battery state: absent, 0% remaining, unknown life estimate
> AC adapter state: not connected
> Performance adjustment mode: manual (2900 MHz)
Digging further, third attempt.
The sequence of actions is following:
first acpi_attach_common() tries to attach EC through ECDT with the
following code:
1206 /*
1207 * Attach table-defined devices
1208 */
1209 SIMPLEQ_FOREACH(entry, >sc_tables, q_next) {
1210 struct acpi_attach_args aaa;
1211
1212 memset(, 0, sizeof(aaa));
1213 aaa.aaa_iot = sc->sc_iot;
1214 aaa.aaa_memt = sc->sc_memt;
1215 aaa.aaa_dmat = sc->sc_ci_dmat;
1216 aaa.aaa_table = entry->q_table;
1217 config_found_sm(>sc_dev, , acpi_print,
acpi_submatch);
1218 }
I see no way how we can set aaa.aaa_node with this code, so it's zero
after memset().
config_found_sm eventually calls acpiec_match for ECDT table, since ECDT
table is presented on my laptop, acpiec_match wins with this probe:
261 /* Check for early ECDT table attach */
262 if (ecdt &&
263 !memcmp(ecdt->hdr.signature, ECDT_SIG, sizeof(ECDT_SIG) - 1))
264 return (1);
then acpiec_attach() is called, and we have following line there:
281 sc->sc_devnode = aa->aaa_node;
and we can't properly eval expressions with NULL as devnode (as I noted,
aaa_node was memset() to zero in acpi_attach_common()).
Since we can't eval the expressions, we can't eval _REG method, which in
turns means that we can't access EC memory region and ECAV (Embedded
Controll AVailable - spent long time deciphering) won't be set in AML,
and from ASL for DSDT, it means that battery status will be returned as
'not present' and plus all other oddities.
I was interested why this "early ECDT" attach procedure isn't working
for me, and found the following:
430 /* Check if this is ECDT initialization */
431 if (ecdt) {
[...]
447 /* Get devnode from header */
448 sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root,
449 ecdt->ec_id);
450
451 goto ecdtdone;
452 }
The reason for the fail is my ECDT, it has wrong ec_id attribute:
Namepath : "\_SB.PC00.LPCB.H_EC"
there is no such device, proper path is "\_SB.PC00.LPCB.EC0"
So, if I remove ecdt table matching code from acpiec_match(), then loop
from acpi_attach_common() will fail to attach it, and actual setup will
be made by this line further down:
1231 aml_find_node(sc->sc_root, "_HID", acpi_foundec, sc);
which works perfectly fine, since it looks for _HID and strcmp() it with
EC Device ID in acpi_foundec(), finding correct node.
If ecdt table match stays, then the line won't take affect, since there
is logic in acpi_foundec() which prevents double attach.
Currently I have no idea how to properly fix this, without breaking
other devices (if you look in 4cfbe39155 why this early ECDT attach was
added).
I've asked for the ACPI fix in Lenovo support forum, to work on this
further, but I suspect such kind of support is like a unicorn - no such
thing.
Re: [acpi] patch for embedded controller detection
On Sat, Oct 08, 2022 at 03:10:18PM +0300, Mikhail wrote:
> I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on
> latest -current it shows that battery is absent and AC not connected:
>
> Battery state: absent, 0% remaining, unknown life estimate
> AC adapter state: not connected
> Performance adjustment mode: manual (2900 MHz)
I'm still digging for this.
Currently I don't understand why there have to be two acpiec devices
(see dmesg in previous mail - one acpiec0 and second "acpiec not
configured", or acpiec1 in patched version), while ASL has only one -
EC0, and having two ECs simply makes no sense. It brought me to match
logic of auto configuration for EC, with inlined patch I'm also able to
see battery status:
Battery state: high, 95% remaining, 178 minutes life estimate
AC adapter state: not connected
Performance adjustment mode: manual (2900 MHz)
This attempt is mostly for archive purpose and in hope, if anyone more
skilled may have immediate thought about the problem.
diff /usr/src
commit - 49f1cedec1baee518af868485e6367f5118073da
path + /usr/src
blob - 5ef24d5179de52d5321e578b3b73dd9524e7c1de
file + sys/dev/acpi/acpiec.c
--- sys/dev/acpi/acpiec.c
+++ sys/dev/acpi/acpiec.c
@@ -255,13 +255,8 @@ acpiec_match(struct device *parent, void *match, void
{
struct acpi_attach_args *aa = aux;
struct cfdata *cf = match;
- struct acpi_ecdt*ecdt = aa->aaa_table;
struct acpi_softc *acpisc = (struct acpi_softc *)parent;
- /* Check for early ECDT table attach */
- if (ecdt &&
- !memcmp(ecdt->hdr.signature, ECDT_SIG, sizeof(ECDT_SIG) - 1))
- return (1);
if (acpisc->sc_ec)
return (0);
dmesg with the patch (now only one acpiec device):
OpenBSD 7.2-current (GENERIC.MP) #21: Wed Oct 12 09:06:10 MSK 2022
mi...@idea.lab.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8363110400 (7975MB)
avail mem = 8092250112 (7717MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439df000 (70 entries)
bios0: vendor LENOVO version "GCCN26WW" date 03/11/2022
bios0: LENOVO 81X7
acpi0 at bios0: ACPI 6.1Undefined scope: \\_SB_.PCI0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT
LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT
BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4)
HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.58 MHz, 06-8c-01
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
cpu2:
Re: [acpi] patch for embedded controller detection
On Sat, Oct 08, 2022 at 05:10:31PM +0200, Mark Kettenis wrote: > > Date: Sat, 8 Oct 2022 16:36:09 +0300 > > From: Mikhail > > > > On Sat, Oct 08, 2022 at 02:56:18PM +0200, Mark Kettenis wrote: > > > The patch isn't quite right, but you're on the right track here. Can > > > you send me the contents of /var/db/acpi for this machine? > > > Alternatively you can use sendbug(1), which will create a report with > > > all the necessary information attached. > > > > Yeah, I should have 'tog blame' the file, the commit explains the > > decision for such var assignment. > > > > ACPI stuff has been sent in direct mail. > > Does the diff below work? No, it doesn't. Battery state: absent, 0% remaining, unknown life estimate AC adapter state: not connected Performance adjustment mode: manual (2900 MHz) OpenBSD 7.2-current (GENERIC.MP) #10: Sun Oct 9 14:41:51 MSK 2022 mi...@idea.lab.local:/sys/arch/amd64/compile/GENERIC.MP real mem = 8363110400 (7975MB) avail mem = 8092237824 (7717MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439df000 (70 entries) bios0: vendor LENOVO version "GCCN26WW" date 03/11/2022 bios0: LENOVO 81X7 acpi0 at bios0: ACPI 6.1Undefined scope: \\_SB_.PCI0 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT BGRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 6MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 6MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 6MB 64b/line 12-way L3 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01 cpu3:
Re: [acpi] patch for embedded controller detection
> Date: Sat, 8 Oct 2022 16:36:09 +0300
> From: Mikhail
>
> On Sat, Oct 08, 2022 at 02:56:18PM +0200, Mark Kettenis wrote:
> > The patch isn't quite right, but you're on the right track here. Can
> > you send me the contents of /var/db/acpi for this machine?
> > Alternatively you can use sendbug(1), which will create a report with
> > all the necessary information attached.
>
> Yeah, I should have 'tog blame' the file, the commit explains the
> decision for such var assignment.
>
> ACPI stuff has been sent in direct mail.
Does the diff below work?
Index: dev/acpi/acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.65
diff -u -p -r1.65 acpiec.c
--- dev/acpi/acpiec.c 10 Aug 2022 16:58:16 - 1.65
+++ dev/acpi/acpiec.c 8 Oct 2022 15:09:17 -
@@ -275,17 +275,19 @@ acpiec_attach(struct device *parent, str
struct acpiec_softc *sc = (struct acpiec_softc *)self;
struct acpi_attach_args *aa = aux;
struct aml_value res;
- int64_t st;
+ int64_t sta;
sc->sc_acpi = (struct acpi_softc *)parent;
sc->sc_devnode = aa->aaa_node;
sc->sc_cantburst = 0;
- if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, ))
- st = STA_PRESENT | STA_ENABLED | STA_DEV_OK;
- if ((st & STA_PRESENT) == 0) {
- printf(": not present\n");
- return;
+ if (sc->sc_devnode) {
+ sta = acpi_getsta(sc->sc_acpi, sc->sc_devnode);
+ if ((sta & (STA_PRESENT | STA_ENABLED | STA_DEV_OK)) !=
+ (STA_PRESENT | STA_ENABLED | STA_DEV_OK)) {
+ printf(": not present\n");
+ return;
+ }
}
printf("\n");
Re: [acpi] patch for embedded controller detection
On Sat, Oct 08, 2022 at 02:56:18PM +0200, Mark Kettenis wrote: > The patch isn't quite right, but you're on the right track here. Can > you send me the contents of /var/db/acpi for this machine? > Alternatively you can use sendbug(1), which will create a report with > all the necessary information attached. Yeah, I should have 'tog blame' the file, the commit explains the decision for such var assignment. ACPI stuff has been sent in direct mail.
Re: [acpi] patch for embedded controller detection
> Date: Sat, 8 Oct 2022 15:10:18 +0300
> From: Mikhail
>
> I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on
> latest -current it shows that battery is absent and AC not connected:
>
> Battery state: absent, 0% remaining, unknown life estimate
> AC adapter state: not connected
> Performance adjustment mode: manual (2900 MHz)
>
> while reviewing the code and ASL dump for DSDT I found strange code path
> in acpiec.c:
>
> 284 if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL,
> ))
> 285 st = STA_PRESENT | STA_ENABLED | STA_DEV_OK;
> 286 if ((st & STA_PRESENT) == 0) {
> 287 printf(": not present\n");
> 288 return;
> 289 }
>
> In my case, for acpiec0, sc->sc_devnode is NULL, and aml_evalinteger
> returns (ACPI_E_BADVALUE), which is (1), so 'if' statement becomes true
> and 'st' got set, further down we check for 'st' value which looks
> useless.
>
> With the patch inlined I was able to see my battery and AC status:
>
> Battery state: high, 100% remaining, unknown life estimate
> AC adapter state: connected
> Performance adjustment mode: manual (2900 MHz)
>
> If I unplug the AC, change is also detected.
>
> Old, new and diff of dmesg's are also inlined. Notable change - new
> acpiec1 device in new dmesg, acpiec0 is detected as 'not present'.
>
> Can somebody with broader understanding of ACPI and auto configuration
> procedure take a look at the patch and assess it?
The patch isn't quite right, but you're on the right track here. Can
you send me the contents of /var/db/acpi for this machine?
Alternatively you can use sendbug(1), which will create a report with
all the necessary information attached.
Cheers,
Mark
[acpi] patch for embedded controller detection
I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on
latest -current it shows that battery is absent and AC not connected:
Battery state: absent, 0% remaining, unknown life estimate
AC adapter state: not connected
Performance adjustment mode: manual (2900 MHz)
while reviewing the code and ASL dump for DSDT I found strange code path
in acpiec.c:
284 if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL,
))
285 st = STA_PRESENT | STA_ENABLED | STA_DEV_OK;
286 if ((st & STA_PRESENT) == 0) {
287 printf(": not present\n");
288 return;
289 }
In my case, for acpiec0, sc->sc_devnode is NULL, and aml_evalinteger
returns (ACPI_E_BADVALUE), which is (1), so 'if' statement becomes true
and 'st' got set, further down we check for 'st' value which looks
useless.
With the patch inlined I was able to see my battery and AC status:
Battery state: high, 100% remaining, unknown life estimate
AC adapter state: connected
Performance adjustment mode: manual (2900 MHz)
If I unplug the AC, change is also detected.
Old, new and diff of dmesg's are also inlined. Notable change - new
acpiec1 device in new dmesg, acpiec0 is detected as 'not present'.
Can somebody with broader understanding of ACPI and auto configuration
procedure take a look at the patch and assess it?
diff /usr/src
commit - 5cb1d9dce18f152bf9f5d7d4251dafe18a5c0c82
path + /usr/src
blob - 5ef24d5179de52d5321e578b3b73dd9524e7c1de
file + sys/dev/acpi/acpiec.c
--- sys/dev/acpi/acpiec.c
+++ sys/dev/acpi/acpiec.c
@@ -275,14 +275,13 @@ acpiec_attach(struct device *parent, struct device *se
struct acpiec_softc *sc = (struct acpiec_softc *)self;
struct acpi_attach_args *aa = aux;
struct aml_value res;
- int64_t st;
+ int64_t st = 0;
sc->sc_acpi = (struct acpi_softc *)parent;
sc->sc_devnode = aa->aaa_node;
sc->sc_cantburst = 0;
- if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, ))
- st = STA_PRESENT | STA_ENABLED | STA_DEV_OK;
+ aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, );
if ((st & STA_PRESENT) == 0) {
printf(": not present\n");
return;
dmesg diff:
--- dmesg.old Sat Oct 8 14:45:40 2022
+++ dmesg.new Sat Oct 8 14:48:25 2022
@@ -1,7 +1,7 @@
-OpenBSD 7.2-current (GENERIC.MP) #7: Sat Oct 8 14:41:01 MSK 2022
+OpenBSD 7.2-current (GENERIC.MP) #8: Sat Oct 8 14:46:04 MSK 2022
mi...@idea.lab.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8363110400 (7975MB)
-avail mem = 8092237824 (7717MB)
+avail mem = 8092213248 (7717MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
@@ -15,7 +15,7 @@
acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT
LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT
BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4)
HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
-acpiec0 at acpi0
+acpiec0 at acpi0: not present
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
@@ -70,9 +70,9 @@
acpiprt23 at acpi0: bus -1 (RP22)
acpiprt24 at acpi0: bus -1 (RP23)
acpiprt25 at acpi0: bus -1 (RP24)
-acpiec at acpi0 not configured
+acpiec1 at acpi0
acpipci0 at acpi0 PC00: 0x 0x0011 0x0001
-acpibat0 at acpi0: BAT0 not present
+acpibat0 at acpi0: BAT0 model "L16M2PB2" serial 411 type LiP oem "SMP"
"VPC2004" at acpi0 not configured
"IDEA2004" at acpi0 not configured
"INTC1043" at acpi0 not configured
@@ -82,7 +82,7 @@
"MSFT0001" at acpi0 not configured
"ACPI000E" at acpi0 not configured
pchgpio0 at acpi0 GPI0 addr 0xfd6e/0x1 0xfd6d/0x1
0xfd6a/0x1 0xfd69/0x1 irq 14, 360 pins
-acpiac0 at acpi0: AC unit offline
+acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
old:
OpenBSD 7.2-current (GENERIC.MP) #7: Sat Oct 8 14:41:01 MSK 2022
mi...@idea.lab.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8363110400 (7975MB)
avail mem = 8092237824 (7717MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439df000 (70 entries)
bios0: vendor LENOVO version "GCCN26WW" date 03/11/2022
bios0: LENOVO 81X7
acpi0 at bios0: ACPI 6.1Undefined scope: \\_SB_.PCI0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT
LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT
BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4)
HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4)
