Index | Thread | Search

From:
Peter Toth <peter.toth198@gmail.com>
Subject:
Re: acpibat remaining capacity is 0
To:
Mark Kettenis <mark.kettenis@xs4all.nl>
Cc:
tech@openbsd.org
Date:
Tue, 18 Mar 2025 12:20:43 +0100

Download raw body.

Thread
Hi Mark,

Fantastic, tested and works, please see output:

hw.sensors.acpiac0.indicator0=On (power supply)
hw.sensors.acpibat0.volt0=11.10 VDC (voltage)
hw.sensors.acpibat0.volt1=12.55 VDC (current voltage)
hw.sensors.acpibat0.current0=0.00 A (rate)
hw.sensors.acpibat0.amphour0=1.96 Ah (last full capacity)
hw.sensors.acpibat0.amphour1=0.00 Ah (warning capacity)
hw.sensors.acpibat0.amphour2=0.00 Ah (low capacity)
hw.sensors.acpibat0.amphour3=1.96 Ah (remaining capacity), OK
hw.sensors.acpibat0.amphour4=2.10 Ah (design capacity)
hw.sensors.acpibat0.raw0=1 (battery full), OK
hw.sensors.acpibat1.volt0=11.10 VDC (voltage)
hw.sensors.acpibat1.volt1=12.56 VDC (current voltage)
hw.sensors.acpibat1.current0=0.00 A (rate)
hw.sensors.acpibat1.amphour0=1.99 Ah (last full capacity)
hw.sensors.acpibat1.amphour1=0.00 Ah (warning capacity)
hw.sensors.acpibat1.amphour2=0.00 Ah (low capacity)
hw.sensors.acpibat1.amphour3=1.99 Ah (remaining capacity), OK
hw.sensors.acpibat1.amphour4=2.10 Ah (design capacity)
hw.sensors.acpibat1.raw0=1 (battery full), OK
hw.sensors.acpibtn0.indicator0=On (lid open)
hw.sensors.acpitz0.temp0=56.00 degC (zone temperature)

Also checked battery warning and critical in DSDT AML and that is
supposed to return 0 unless EC reads fail for PCI0.LPCB.EC0.ECAV, then
it populates it with defaults. So all values are looking good now.

Thank you!
PT

On Tue, Mar 18, 2025 at 11:30 AM Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Peter Toth <peter.toth198@gmail.com>
> > Date: Tue, 18 Mar 2025 08:49:25 +0100
>
> Hi Peter,
>
> Good find!  The issue is indeed the following AML operation:
>
>     Divide (Local3, 0x64, Local3, Local0)
>
> The 3rd and 4th argument here are where the remainder and result are
> stored.  But the code stores the remainder in the same variable as the
> original dividend.  But changing the order in which the remainder and
> result are calculated and stored won't fix the bug.  With your diff:
>
>     Divide (Local3, 0x64, Local0, Local3)
>
> would fail instead.
>
> So here is a better fix.  Can you confirm that this fixes the issue
> too?
>
>
> Index: dev/acpi/dsdt.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> diff -u -p -r1.273 dsdt.c
> --- dev/acpi/dsdt.c     23 Jan 2025 13:40:26 -0000      1.273
> +++ dev/acpi/dsdt.c     18 Mar 2025 10:24:51 -0000
> @@ -3819,7 +3819,7 @@ aml_parse(struct aml_scope *scope, int r
>         struct aml_scope *mscope, *iscope;
>         uint8_t *start, *end;
>         const char *ch;
> -       int64_t ival;
> +       int64_t ival, rem;
>         struct timespec ts;
>
>         my_ret = NULL;
> @@ -4036,12 +4036,11 @@ aml_parse(struct aml_scope *scope, int r
>                         my_ret = aml_seterror(scope, "Divide by Zero!");
>                         break;
>                 }
> -               ival = aml_evalexpr(opargs[0]->v_integer,
> +               rem = aml_evalexpr(opargs[0]->v_integer,
>                     opargs[1]->v_integer, AMLOP_MOD);
> -               aml_store(scope, opargs[2], ival, NULL);
> -
>                 ival = aml_evalexpr(opargs[0]->v_integer,
>                     opargs[1]->v_integer, AMLOP_DIVIDE);
> +               aml_store(scope, opargs[2], rem, NULL);
>                 aml_store(scope, opargs[3], ival, NULL);
>                 break;
>         case AMLOP_NOT: