Lenovo S10e, charge_full == 0 ?!?
[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
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_fullis 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), includingcharge_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 usecharge_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
[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.
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 mAhEverything 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