Battery status reading problems
Reading the battery status still consumes insane amounts of CPU time (cpufreqd polling the battery only every 10 seconds has eaten 3:06 of raw CPU after about 30 minutes!). It also very annoyingly pauses the whole system, so that even typing becomes slow.
Also, I'm sometimes (rarely) getting messages like these:
osl-0898 [37] os_wait_semaphore : Failed to acquire semaphore[c12ce560|1|0], AE_TIME
osl-0898 [41] os_wait_semaphore : Failed to acquire semaphore[c12ce560|1|0], AE_TIMEThis is using 2.4.22 on a Sharp Mebius PC-MT1-H5.
--J.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line · Jan Rychter
Reading the battery status still consumes insane amounts of CPU time
Recently, a bug has been fixed by some nice person at intel - the AML code was executed twice. Although half of the time is still not perfect, it is a lot better now.
You can find the patch at http://bugme.osdl.org/show_bug.cgi?id=726 , I hope it will find its way into official sources soon.
While we are on the topic: I got a battery from a friend which caused my system to throw exceptions AE_TIME in thermal zone(!) code, which didn't work anymore afterwards (wrong temperature). I don't know
what happened to this battery, but it cannot be loaded, design capacity is multiplicated by 10 each time I query the "info" and the serial number is either "Bad" or empty. If anybody is interested, I can post my DSDT or logfiles. But the problem is with windows as well ...
The battery is original Sony, by the way ...
Markus
Signature · 10 lines
__________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign [email protected] X Against HTML Mail / \ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.58.0309192257480.1613-KjnUIgV0B0bsKMwAuzqOxrNldLUNz+W/@public.gmane.org
Quoted 8 lines · Markus Gaugusch
Quoted 1 line · Jan Rychter
Reading the battery status still consumes insane amounts of CPU time
Recently, a bug has been fixed by some nice person at intel - the AML code was executed twice. Although half of the time is still not perfect, it is a lot better now.
But on Windows, there is no slowdown noticeable. Is that just the different implementation or is there still something (too) slow in the Intel ACPI CA code?
Bas.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Bas Mevissen
Quoted 4 lines · Markus Gaugusch
Quoted 1 line · Jan Rychter
Reading the battery status still consumes insane amounts of CPU time
Quoted 8 lines
Quoted 4 lines
Recently, a bug has been fixed by some nice person at intel - the AML code was executed twice. Although half of the time is still not perfect, it is a lot better now.
But on Windows, there is no slowdown noticeable. Is that just the different implementation or is there still something (too) slow in the Intel ACPI CA code?
I don't think, that the code is slow, but during execution of the battery query (which takes some time, because it is on a slow bus) the kernel seems to hang - probably a kernel thread would cure this problem, but I'm no expert in this area.
Markus
Signature · 10 lines
__________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign [email protected] X Against HTML Mail / \ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.53.0309220954120.9385-sxQ525G0OhRQK2oVCIMtW7NldLUNz+W/@public.gmane.org
Quoted 4 lines · Markus Gaugusch
I don't think, that the code is slow, but during execution of the battery query (which takes some time, because it is on a slow bus) the kernel seems to hang - probably a kernel thread would cure this problem, but I'm no expert in this area.
Several vendors implement the actual battery reading logic as an SMI trap and disable interrupts during their slow chat with the battery. There isnt much anyone can do about that bit alas (except read it a lot less often)
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): 1064230622.8592.14.camel-Z+iYsftfazAXoXS6vNje7nviChZXdy279dF7HbQ/[email protected]
Quoted 11 lines · Alan Cox
Quoted 4 lines · Markus Gaugusch
I don't think, that the code is slow, but during execution of the battery query (which takes some time, because it is on a slow bus) the kernel seems to hang - probably a kernel thread would cure this problem, but I'm no expert in this area.
Several vendors implement the actual battery reading logic as an SMI trap and disable interrupts during their slow chat with the battery. There isnt much anyone can do about that bit alas (except read it a lot less often)
I would expect more batery read are done via the Embeded Controller, and pass by his firmware in order to know what to do exactly, that is pass the query to the i2c bus of that embedded controller. Therefore, slow read may be indication of:
- i2c bus is more or less busy (unfortunately, that one most likely handle other sensors like thermal, etc.). Contention happens and since thermal zone is (ab)used, that will happen likely I think, looking the OP mail.
- firmware bug for that embedded controller.
I'm ok though for the fact that some OEM will do read battery via obscur SMI methods, Dell being the one that abuse that kind of method.
Cheers,
Signature · 10 lines
Ducrot Bruno -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
Quoted 6 lines · Alan Cox
Several vendors implement the actual battery reading logic as an SMI trap and disable interrupts during their slow chat with the battery. There isnt much anyone can do about that bit alas (except read it a lot less often)
OK. I'll check with Win XP and Linux with latest ACPI CA to see if I notice a speed difference between Windows and Linux. The XP battery indicator detects AC/battery power changes in a few seconds, so I expect the batery status polling in Windows to occur at the same speed.
(or does the AC/battery power work with an event? The my assumption won't hold then)
Bas.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): [email protected]
Am Di, 2003-09-23 um 14.14 schrieb Bas Mevissen:
Quoted 11 lines
Quoted 4 lines · Alan Cox
Several vendors implement the actual battery reading logic as an SMI trap and disable interrupts during their slow chat with the battery. There isnt much anyone can do about that bit alas (except read it a lot less often)
OK. I'll check with Win XP and Linux with latest ACPI CA to see if I notice a speed difference between Windows and Linux. The XP battery indicator detects AC/battery power changes in a few seconds, so I expect the batery status polling in Windows to occur at the same speed. (or does the AC/battery power work with an event? The my assumption won't hold then)
I could very well accept CPU load.
I would even accept delays, given they are small.
But I experienced kernel hangs, i.e. short periods of no I/O activity at all when querying the battery status. And even that could be acceptable. What was not acceptable were very bizarre happenings that lokked like lost interrupts!? Events that did not cause the reaction they should have. Less severe were lost mouse events but more severe was packet loss on network.
So for me it looks more like a bug in the ACPI code than just a performnce issue or hardware misdesign.
The other thing that leads to this assumption is that so many of us see this happening, with various notebooks by various manufacturers. It is not bound to certain or limited number of "bad" machines.
Quoted 1 line
Bas.
CU
nils faerber
Signature · 11 lines
kernel concepts Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen D1 : +49-170-2729106 -- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): 1064334307.14784.92.camel-65LrUGLyukAb1SvskN2V4Q@public.gmane.org
Quoted 4 lines · Nils Faerber
What was not acceptable were very bizarre happenings that lokked like lost interrupts!? Events that did not cause the reaction they should have. Less severe were lost mouse events but more severe was packet loss on network.
Ah! No I remember again, why I disabled the battery monitor - it was not only causing problems with sound, but also lost keyboard input (I'm a very fast typer :)
I think that this confirms your assumptions.
Markus
Signature · 10 lines
__________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign [email protected] X Against HTML Mail / \ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Salut Nils,
Quoted 8 lines · Nils Faerber
Am Di, 2003-09-23 um 14.14 schrieb Bas Mevissen:
Quoted 7 lines
Quoted 4 lines · Alan Cox
Several vendors implement the actual battery reading logic as an SMI trap and disable interrupts during their slow chat with the battery. There isnt much anyone can do about that bit alas (except read it a lot less often)
(or does the AC/battery power work with an event? The my assumption won't hold then)
I commented on that before!
Quoted 8 lines
I could very well accept CPU load.
I would even accept delays, given they are small.
But I experienced kernel hangs, i.e. short periods of no I/O activity at all when querying the battery status. And even that could be acceptable. What was not acceptable were very bizarre happenings that lokked like lost interrupts!? Events that did not cause the reaction they should have. Less severe were lost mouse events but more severe was packet loss on network.
That are the things that follow from, what Alan is saying - interrupts are disabled over some time.
Quoted 5 lines
So for me it looks more like a bug in the ACPI code than just a performnce issue or hardware misdesign.
The other thing that leads to this assumption is that so many of us see this happening, with various notebooks by various manufacturers. It is not bound to certain or limited number of "bad" machines.
Sorry to tell you, that I have no problems with my Acer TM630. I did try a bash-loop with a uspleep 10, always querrying the battery-state, that did not consume any interrupts on my maschine. May you collect, what various notebooks you claim are affected?
cheers
hartwig felger
Hartwig Felger informatics
- --
1024D/339FD693 Hartwig Felger <[email protected]> Key fingerprint = FB2F 3EE9 345A D55B 6FF2 0EC1 F5B0 684F 339F D693 For the pulic keys, please visit my page.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/cIzk9bBoTzOf1pMRAhgYAJ0ahmECCs2WUEBv+ahfJib4gunLiACgwfik DKz65xiT5jrtei4LU7EGe9k=
=FEqF
-----END PGP SIGNATURE-----
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.58.0309232001000.1228-KnfdeQs3A3X/[email protected]
Hartwig Felger:
Quoted 28 lines
Salut Nils,
Quoted 8 lines · Nils Faerber
Am Di, 2003-09-23 um 14.14 schrieb Bas Mevissen:
Quoted 7 lines
Quoted 4 lines · Alan Cox
Several vendors implement the actual battery reading logic as an SMI trap and disable interrupts during their slow chat with the battery. There isnt much anyone can do about that bit alas (except read it a lot less often)
(or does the AC/battery power work with an event? The my assumption won't hold then)
I commented on that before!
Quoted 8 lines
I could very well accept CPU load.
I would even accept delays, given they are small.
But I experienced kernel hangs, i.e. short periods of no I/O activity at all when querying the battery status. And even that could be acceptable. What was not acceptable were very bizarre happenings that lokked like lost interrupts!? Events that did not cause the reaction they should have. Less severe were lost mouse events but more severe was packet loss on network.That are the things that follow from, what Alan is saying - interrupts are disabled over some time.
Quoted 5 lines
So for me it looks more like a bug in the ACPI code than just a performnce issue or hardware misdesign.
The other thing that leads to this assumption is that so many of us see this happening, with various notebooks by various manufacturers. It is not bound to certain or limited number of "bad" machines.
Quoted 4 lines
Sorry to tell you, that I have no problems with my Acer TM630. I did try a bash-loop with a uspleep 10, always querrying the battery-state, that did not consume any interrupts on my maschine. May you collect, what various notebooks you claim are affected?
[...]
For the reference, I have always had performance problems with reading the battery status on my Sharp Mebius. I can't use any "battery applets" nor cpufreqd because of that -- they eat too much CPU power and cause the whole machine to slow down.
I got bored with reporting this all over again, and since this issue has been largely ignored by developers, I decided I can do without battery information after all.
--J.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Jan Rychter
For the reference, I have always had performance problems with reading the battery status on my Sharp Mebius. I can't use any "battery applets" nor cpufreqd because of that -- they eat too much CPU power and cause the whole machine to slow down.
I got bored with reporting this all over again, and since this issue has been largely ignored by developers, I decided I can do without battery information after all.
My Dell Inspiron 8100 gives me the same problems.
I didn't really check wether Windows shows the same problems. I don't use Windows much. :-)
Regards,
Toon.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
A message that is not in the archive (sent off-list or not yet received): 20030926085542.GA28731-UrA3525iEjFfB9KAG+eifygtU7bT7/[email protected]
Quoted 11 lines · Toon van der Pas
Quoted 9 lines · Jan Rychter
For the reference, I have always had performance problems with reading the battery status on my Sharp Mebius. I can't use any "battery applets" nor cpufreqd because of that -- they eat too much CPU power and cause the whole machine to slow down.
I got bored with reporting this all over again, and since this issue has been largely ignored by developers, I decided I can do without battery information after all.
Quoted 6 lines
My Dell Inspiron 8100 gives me the same problems.
I didn't really check wether Windows shows the same problems. I don't use Windows much. :-)Regards,
Toon.
Same with my Dell 8100: under 2.6.0-test3 (acpi), the gnome panel battery capplet uses 23% of the CPU and 2.7% of the memory while the wmacpi program uses only 2.6% of the CPU and .4% of the memory.
With the same kernel compiled for apm rather than acpi, bath the battstat capplet usage and the wmapm usage drop to 0.0%.
Sounds like an ACPI (software?) problem to me.
Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Just for the record: I have this problem on my Sony Vaio FX405 Laptop (Athlon CPU/Via Chipset/Phoenix Bios).
Markus
Signature · 10 lines
__________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign [email protected] X Against HTML Mail / \ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
Hi!
Quoted 8 lines
OK. I'll check with Win XP and Linux with latest ACPI CA to see if I notice a speed difference between Windows and Linux. The XP battery indicator detects AC/battery power changes in a few seconds, so I expect the batery status polling in Windows to occur at the same speed.
(or does the AC/battery power work with an event? The my assumption won't hold then)
Yes, thats event driven IIRC.
Signature · 9 lines
Pavel Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need... ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf