Subject: Re: Bogus ACPI battery information in recent current
To: Joerg Sonnenberger <joerg@britannica.bec.de>
From: Sverre Froyen <sverre@viewmark.com>
List: current-users
Date: 12/14/2007 08:54:44
On Friday 14 December 2007, Joerg Sonnenberger wrote:
> On Thu, Dec 13, 2007 at 02:27:50PM -0700, Sverre Froyen wrote:
> > Notice the "last full cap" and the "design cap" values.  There is also a
> > very noticable delay before the output appears.  With my latest good
> > kernel (4.99.40 from 6 Dec),  I get
>
> How long is the delay approximately? I wonder whether this and the other
> reports are related to the retry attempt after long timeouts.

Without your pach: 0 - 5sec,

with your patch: 0 - 60 sec,

often the response is immediate and the next response is delayed.

> Can you try the attached patch as well?

I rebooted several times and noticed a time period after boot when envstat 
returned zero values for the both acadaptor and the battery:

[acpiacad0]
  connected:        OFF
[acpibat0]
         present:        OFF
      design cap:      0.000 Wh
   last full cap:      0.000 Wh
      technology:          0
  design voltage:      0.000 V
        warn cap:      0.000 Wh
         low cap:      0.000 Wh
         voltage:      0.000 V
     charge rate:      0.000 W
  discharge rate:      0.000 W
          charge:      0.000 Wh
        charging:        OFF
    charge state:    UNKNOWN
[acpitz0]
     temperature:     54.000 degC
[aps0]
          aps0 X_ACCEL:        480
          aps0 Y_ACCEL:        512
            aps0 X_VAR:        481
            aps0 Y_VAR:        513
           aps0 TEMP_1:     45.000 degC
           aps0 TEMP_2:     45.000 degC
  aps0 Keyboard Active:         ON
     aps0 Mouse Active:        OFF
         aps0 Lid Open:         ON

after a while it would returning sensible values for the battery (but notice 
that the AC adaptor has not yet been detected):

[acpiacad0]
  connected:        OFF
[acpibat0]
         present:         ON
      design cap:     51.840 Wh
   last full cap:     44.800 Wh
      technology:          1
  design voltage:     10.800 V
        warn cap:      2.240 Wh ( 5.00%)
         low cap:      0.200 Wh ( 0.45%)
         voltage:     12.387 V
     charge rate:        N/A
  discharge rate:        N/A
          charge:     44.140 Wh (98.53%)
        charging:        OFF
    charge state:     NORMAL
[acpitz0]
     temperature:     26.800 degC
[aps0]
          aps0 X_ACCEL:        482
          aps0 Y_ACCEL:        515
            aps0 X_VAR:        482
            aps0 Y_VAR:        516
           aps0 TEMP_1:     45.000 degC
           aps0 TEMP_2:     45.000 degC
  aps0 Keyboard Active:         ON
     aps0 Mouse Active:        OFF
         aps0 Lid Open:         ON

Finally, it would pick up the AC adptor too.

Then, a little later,  powerd, would shut down the computer -- perhaps 
reacting the the delays.

The patch appears to prevent the truly bogus values that I observed without 
it.  As I only rebooted four or five times, however, this may be a case of 
insufficient sampling.

With the patch, I'm seeing much longer delays as noted above.

This may be unrelated, but as I am typing this email, I am noticing occasional 
interface freezes (X windows + KDE) of several tens of seconds.  I'm running 
a kernel with the patch (with the shutdown command in sensor_battery 
commented out).  I'm also seing periodic messages from sensor_battery:

Dec 14 08:49:28 abbor root: /etc/powerd/scripts/sensor_battery: (charge state) 
capacity reached normal state [acpibat0]
Dec 14 08:49:43 abbor root: /etc/powerd/scripts/sensor_battery: (charge state) 
state changed to CRITICAL [acpibat0]

The messages appear much more frequent than the freezes.

> > I've attached the dmesg from 4.99.42, below.  I suspect a pertinent line
> > is:
> >
> > acpiec0 at acpi0 (EC, PNP0C09-0): ACPI Embedded Controller (disabled)
>
> That's a red hering, acpiecdt0 replaces acpiec when found. Before it was
> playing some interesting tricks.

ok

> Joerg