Battery status reading problems

Battery status reading problems

[Jan Rychter]

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_TIME

This 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

Re: Battery status reading problems

[Markus Gaugusch]

On Sep 18, Jan Rychter <jan-JAsPCFd0eodBDgjK7y7TUQ@public.gmane.org> wrote:
> 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
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Battery status reading problems

[Bas Mevissen]

Markus Gaugusch wrote:
> On Sep 18, Jan Rychter <jan-JAsPCFd0eodBDgjK7y7TUQ@public.gmane.org> wrote:
> 
>>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

Re: Battery status reading problems

[Markus Gaugusch]

On Sep 22, Bas Mevissen <ml-Y9IUUvl1dgU0Iwp8Nzs06g@public.gmane.org> wrote:

> Markus Gaugusch wrote:
> > On Sep 18, Jan Rychter <jan-JAsPCFd0eodBDgjK7y7TUQ@public.gmane.org> wrote:
> >
> >>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?
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

-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Battery status reading problems

[Alan Cox]

On Llu, 2003-09-22 at 08:56, Markus Gaugusch wrote:
> 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

Re: Battery status reading problems

[Ducrot Bruno]

On Mon, Sep 22, 2003 at 12:37:03PM +0100, Alan Cox wrote:
> On Llu, 2003-09-22 at 08:56, Markus Gaugusch wrote:
> > 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,

-- 
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

Re: Battery status reading problems

[Bas Mevissen]

Alan Cox wrote:
>  
> 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

Re: Battery status reading problems

[Nils Faerber]

Am Di, 2003-09-23 um 14.14 schrieb Bas Mevissen:
> Alan Cox wrote:
> > 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.

> Bas.
CU
  nils faerber

-- 
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

Re: Battery status reading problems

[Markus Gaugusch]

On Sep 23, Nils Faerber <nils-t93Ne7XHvje5bSeCtf/tX7NAH6kLmebB@public.gmane.org> wrote:
> 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

-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Battery status reading problems

[liste-9nAOAgdJVo4b1SvskN2V4Q]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salut Nils,

On Tue, 23 Sep 2003, Nils Faerber wrote:
> Am Di, 2003-09-23 um 14.14 schrieb Bas Mevissen:
> > Alan Cox wrote:
> > > 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!

> 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.

> 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 <hgfelger-9nAOAgdJVo4b1SvskN2V4Q@public.gmane.org>
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

Re: Battery status reading problems

[Jan Rychter]

[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]

Hartwig Felger:
> Salut Nils,
> On Tue, 23 Sep 2003, Nils Faerber wrote:
> > Am Di, 2003-09-23 um 14.14 schrieb Bas Mevissen:
> > > Alan Cox wrote:
> > > > 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!
> 
> > 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.
> 
> > 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?

[...]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Re: Battery status reading problems

[Toon van der Pas]

On Thu, Sep 25, 2003 at 10:38:57PM -0700, Jan Rychter wrote:
> 
> 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

Re: Re: Battery status reading problems

[David G Hamblen]

On Fri, 26 Sep 2003, Toon van der Pas wrote:

> On Thu, Sep 25, 2003 at 10:38:57PM -0700, Jan Rychter wrote:
> >
> > 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.

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

Re: Re: Battery status reading problems

[Markus Gaugusch]

Just for the record: I have this problem on my Sony Vaio FX405 Laptop
(Athlon CPU/Via Chipset/Phoenix Bios).

Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Battery status reading problems

[Pavel Machek]

Hi!
> 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.
-- 
				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