Skip to contentSkip to conversation

Lenovo S10e, charge_full == 0 ?!?

DISCUSSION Matthew Palmer 3 participants 4 messages May 31, 2009 – Jun 1, 2009 ACPI

lore
Share & tools
lore
#0 lore raw

[Please Cc me; I'm not subscribed to the list]

Hi,

I've just bought a Lenovo S10e ideapad, and it's going nicely except that /sys/class/power_supply/BAT0/charge_full is 0, rather than something pleasantly large and reassuring. This is causing battery monitors to produce all sorts of crazy results. The rest of the battery parameters seem OK (nothing abnormally 0 in uevent), including charge_full_design. I've charged and dischaged the battery a couple of times, just to make sure it's not some sort of "initialisation" problem.

I've tried with both 2.6.26-2 (out of Debian Lenny), and also 2.6.29-2 (from Debian Sid), and the results are the same. I'd try a git tree kernel, but wihch one? Linus' tree? The Linux ACPI tree? If anyone recognises this problem and can point me at a likely candidate for a fix, I'm happy to try it out, but randomly firing away at kernel trees, given the likely build speed on this little netbook, is likely to be an exercise in frustration.

Failing that, does anyone have any pointers as to where I could start in tracking this down? It seems like it'll be a fairly straightforward bug -- the driver's probably just looking in the wrong place for the value, and needs a re-education. I'm completely unfamiliar with ACPI and the kernel code relating to ACPI, though, so perhaps it's a lot more complicated than that. Worst case, if all else fails, I'm thinking that a "fix" might be to check if charge_full == 0, and if so use charge_full_design. It's ugly, but better than the current (hah!) situation.

- Matt

#1 lore raw
Quoted 3 lines · Matthew Palmer

[Please Cc me; I'm not subscribed to the list]

Hi,

Will you please check whether the output of "cat /proc/acpi/battery/*/*" is normal?
Of course you can open a new bug at
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
and attach the output of acpidump, "cat /proc/acpi/battery/*/*". Thanks.

Quoted 30 lines

I've just bought a Lenovo S10e ideapad, and it's going nicely except that /sys/class/power_supply/BAT0/charge_full is 0, rather than something pleasantly large and reassuring. This is causing battery monitors to produce all sorts of crazy results. The rest of the battery parameters seem OK (nothing abnormally 0 in uevent), including charge_full_design. I've charged and dischaged the battery a couple of times, just to make sure it's not some sort of "initialisation" problem.

I've tried with both 2.6.26-2 (out of Debian Lenny), and also 2.6.29-2 (from Debian Sid), and the results are the same. I'd try a git tree kernel, but wihch one? Linus' tree? The Linux ACPI tree? If anyone recognises this problem and can point me at a likely candidate for a fix, I'm happy to try it out, but randomly firing away at kernel trees, given the likely build speed on this little netbook, is likely to be an exercise in frustration.

Failing that, does anyone have any pointers as to where I could start in tracking this down? It seems like it'll be a fairly straightforward bug -- the driver's probably just looking in the wrong place for the value, and needs a re-education. I'm completely unfamiliar with ACPI and the kernel code relating to ACPI, though, so perhaps it's a lot more complicated than that. Worst case, if all else fails, I'm thinking that a "fix" might be to check if charge_full == 0, and if so use charge_full_design. It's ugly, but better than the current (hah!) situation.

- Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw

[All: Cc's please, I'm not subscribed]

Hi Yakui,

Quoted 6 lines · yakui_zhao
Quoted 3 lines · Matthew Palmer

[Please Cc me; I'm not subscribed to the list]

Hi,

Will you please check whether the output of "cat /proc/acpi/battery/*/*" is normal?

The tricky part there is: what exactly counts as "normal"? As best I can tell by comparing it to the output of my other laptop, the only possible weirdnesses are:

alarm: unsupported
last full capacity: 0 mAh

Everything else looks reasonably similar. Since it's only about 20 lines long, I've pasted the whole output into the end of this e-mail. Perhaps there's something that's unobviously wrong.

Quoted 3 lines

Of course you can open a new bug at
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
and attach the output of acpidump, "cat /proc/acpi/battery/*/*".

I'm not sure I care enough to create yet another never-to-be-used-again bugzilla account. I plan on nailing this problem down myself, with assistance, rather than just reporting a bug and hoping someone else fixes it for me. I've placed the acpidump output at
http://hezmatt.org/~mpalmer/tmp/acpidump_s10e.txt if anyone can make any sense of it. (If there's a "Dummies Guide to Interpreting acpidump Output" somewhere, I'd love to know about it).

- Matt

---[BEGIN: /proc/acpi/battery/*/* ]---

alarm:                   unsupported
present:                 yes
design capacity:         4876 mAh
last full capacity:      0 mAh
battery technology:      rechargeable
design voltage:          10800 mV
design capacity warning: 487 mAh
design capacity low:     146 mAh
capacity granularity 1:  10 mAh
capacity granularity 2:  25 mAh
model number:            LE60_S
serial number:            
battery type:            LION
OEM info:                Sanyo
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            871 mA
remaining capacity:      4359 mAh
present voltage:         12026 mV

---[END]---

Signature · 2 lines
<Igloo> I remember going to my first tutorial in room 404. I was most upset
when I found it.
#3 lore raw
Quoted 27 lines · Matthew Palmer

[All: Cc's please, I'm not subscribed]

Hi Yakui,

Quoted 6 lines · yakui_zhao
Quoted 3 lines · Matthew Palmer

[Please Cc me; I'm not subscribed to the list]

Hi,

Will you please check whether the output of "cat /proc/acpi/battery/*/*" is normal?

The tricky part there is: what exactly counts as "normal"? As best I can tell by comparing it to the output of my other laptop, the only possible weirdnesses are:

alarm: unsupported
last full capacity: 0 mAh

Everything else looks reasonably similar. Since it's only about 20 lines long, I've pasted the whole output into the end of this e-mail. Perhaps there's something that's unobviously wrong.

Quoted 3 lines

Of course you can open a new bug at
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
and attach the output of acpidump, "cat /proc/acpi/battery/*/*".

Quoted 5 lines

I'm not sure I care enough to create yet another never-to-be-used-again bugzilla account. I plan on nailing this problem down myself, with assistance, rather than just reporting a bug and hoping someone else fixes it for me. I've placed the acpidump output at
http://hezmatt.org/~mpalmer/tmp/acpidump_s10e.txt

I can not access this url.
Filing a new bug report makes it easier for us to track this bug. so I think it's still worth doing, btw, you can attach the acpidump there.

thanks,
rui