PROBLEM: conflict between apm and system clock on Inspiron 8100

PROBLEM: conflict between apm and system clock on Inspiron 8100

[mike heffner]

Hi,

  I have found a problem with the use of apm on my
dell inspiron 8100 running kernel 2.4.18-10.  Any
access to the apm kernel routine (for example cat
/proc/apm) causes the system clock to run slow.  About
1% slow if I run the battstat applet in gnome.  I
suspect that somehow the clock interrupt is getting
missed during the apm bios/kernel call.  Looking
though the apm.c I don't see how to fix this.  I tried
the switch apm=allow_int, but that showed no change. 
I have found some vague (don't mention apm) references
to this problem on the web, but no solutions.  Does
anyone understand this problem?

Thanks,
Mike
mdheffner@yahoo.com

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[Alan Cox]

On Mon, 2002-08-26 at 09:14, mike heffner wrote:
> the switch apm=allow_int, but that showed no change. 
> I have found some vague (don't mention apm) references
> to this problem on the web, but no solutions.  Does
> anyone understand this problem?

The 8100 seems to turn off interrupts itself and read the battery very
slowly causing lost ticks (its taking > 1/100th of a second to do the
read). 

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[mike heffner]

> 
> The 8100 seems to turn off interrupts itself and
> read the battery very
> slowly causing lost ticks (its taking > 1/100th of a
> second to do the
> read). 

Well, isn't that a nice feature.  Is there a
workaround for this hardware?

Thanks
Mike

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[Alan Cox]

On Mon, 2002-08-26 at 18:00, mike heffner wrote:
> Well, isn't that a nice feature.  Is there a
> workaround for this hardware?

A thinkpad ;)

In theory you could try writing some code to measure the elapsed time by
other means and then correct the kernel for the number of lost ticks.
Not trivial. Or for that matter dont run battstat

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[Frank.Otto]

Alan Cox wrote:
> On Mon, 2002-08-26 at 18:00, mike heffner wrote:
> > Well, isn't that a nice feature.  Is there a
> > workaround for this hardware?
>  
>  A thinkpad ;)

Unfortunately, that's not true -- I just got an IBM Thinkpad R32
which exhibits the same behaviour as Mike's Dell Inspiron 8100,
it's only a tad worse. When I have the battstat_applet running (which
checks the battery every second), kernel time runs about 3% slow
compared to the RTC (which seems to be half-way accurate on my machine).

The cause seems to be definitely APM. If I shut off battstat_applet
and apmd, kernel time and RTC are in sync. With only apmd, I lose about
15 seconds per hour. With battstat_applet, I lose 2 minutes per hour.
With
  while true; do cat /proc/apm >/dev/null; done
the system runs at about 1/4 of the right speed. Using a kernel with ACPI
eliminates the problem (of course, you lose almost all power management
functionality too).

BTW, I have set CONFIG_APM_ALLOW_INT, and on startup the kernel even says
"IBM machine detected. Enabling interrupts during APM calls." Doesn't
seem to help, though.

Alan Cox continues:
>  In theory you could try writing some code to measure the elapsed time by
>  other means and then correct the kernel for the number of lost ticks.
>  Not trivial. Or for that matter dont run battstat

I've hacked together a small daemon that tries to adjust the value
and speed of the kernel clock (via adjtimex) to the RTC. An ugly solution,
I know, but better than nothing. If anyone is interested, mail me.

Regards,
Frank

-- 
Please CC replies to me since I'm not on the list.

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[mike heffner]

Hi Frank,

 From your e-mail it seems that the kernel is the
problem, not the bios.  Is that your understanding?  I
started pestering Dell for a bios without this
problem.  Should I be digging through the kernel code
instead?

Mike

--- Frank.Otto@tc.pci.uni-heidelberg.de wrote:
> Alan Cox wrote:
> > On Mon, 2002-08-26 at 18:00, mike heffner wrote:
> > > Well, isn't that a nice feature.  Is there a
> > > workaround for this hardware?
> >  
> >  A thinkpad ;)
> 
> Unfortunately, that's not true -- I just got an IBM
> Thinkpad R32
> which exhibits the same behaviour as Mike's Dell
> Inspiron 8100,
> it's only a tad worse. When I have the
> battstat_applet running (which
> checks the battery every second), kernel time runs
> about 3% slow
> compared to the RTC (which seems to be half-way
> accurate on my machine).
> 
> The cause seems to be definitely APM. If I shut off
> battstat_applet
> and apmd, kernel time and RTC are in sync. With only
> apmd, I lose about
> 15 seconds per hour. With battstat_applet, I lose 2
> minutes per hour.
> With
>   while true; do cat /proc/apm >/dev/null; done
> the system runs at about 1/4 of the right speed.
> Using a kernel with ACPI
> eliminates the problem (of course, you lose almost
> all power management
> functionality too).
> 
> BTW, I have set CONFIG_APM_ALLOW_INT, and on startup
> the kernel even says
> "IBM machine detected. Enabling interrupts during
> APM calls." Doesn't
> seem to help, though.
> 
> Alan Cox continues:
> >  In theory you could try writing some code to
> measure the elapsed time by
> >  other means and then correct the kernel for the
> number of lost ticks.
> >  Not trivial. Or for that matter dont run battstat
> 
> I've hacked together a small daemon that tries to
> adjust the value
> and speed of the kernel clock (via adjtimex) to the
> RTC. An ugly solution,
> I know, but better than nothing. If anyone is
> interested, mail me.
> 
> Regards,
> Frank
> 
> -- 
> Please CC replies to me since I'm not on the list.


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[Frank Otto]

Hi Mike,

On Wed, Aug 28, 2002 at 10:00:33AM -0700, mike heffner wrote:
> Hi Frank,
> 
>  From your e-mail it seems that the kernel is the
> problem, not the bios.  Is that your understanding?  I
> started pestering Dell for a bios without this
> problem.  Should I be digging through the kernel code
> instead?

Frankly, I don't know. The behaviour of the BIOS sure is bad,
but I don't know the APM specifications, so the BIOS might still
be operating within these limits. Good luck though for getting a
better BIOS from Dell. If you have any success, please let me know.

I doubt that this can be fixed in the kernel. If the kernel enables
interrupts during APM calls but the BIOS still turns them off, what
should the kernel do about this? Well, there still exists the possibilty
that the kernel's method for enabling interrupts during APM calls is
flawed in some way, or doesn't work with certain BIOSes. In this case,
it might be possible to fix it in the kernel.

Cheers,
Frank

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[Stephen Rothwell]

Hi Frank,

On Wed, 28 Aug 2002 17:04:33 +0200 Frank.Otto@tc.pci.uni-heidelberg.de wrote:
>
> Alan Cox wrote:
> > On Mon, 2002-08-26 at 18:00, mike heffner wrote:
> > > Well, isn't that a nice feature.  Is there a
> > > workaround for this hardware?
> >  
> >  A thinkpad ;)
> 
> Unfortunately, that's not true -- I just got an IBM Thinkpad R32
> which exhibits the same behaviour as Mike's Dell Inspiron 8100,
> it's only a tad worse. When I have the battstat_applet running (which
> checks the battery every second), kernel time runs about 3% slow
> compared to the RTC (which seems to be half-way accurate on my machine).

Don't do that then.  Why would you need to check the battery status
every second?  Check every 30 seconds.  Does your battery even update its
status more often than that?

> The cause seems to be definitely APM. If I shut off battstat_applet
> and apmd, kernel time and RTC are in sync. With only apmd, I lose about
> 15 seconds per hour. With battstat_applet, I lose 2 minutes per hour.
> With
>   while true; do cat /proc/apm >/dev/null; done
> the system runs at about 1/4 of the right speed. Using a kernel with ACPI
> eliminates the problem (of course, you lose almost all power management
> functionality too).

Interesting ... Howlong does "cat /proc/apm" take?
On my Thinkpad T22 I get:

# time cat /proc/apm
1.16 1.2 0x03 0x01 0x00 0x01 99% -1 ?

real	0m0.009s
user	0m0.000s
sys	0m0.010s

while ...

# time ./tppow
Battery 0 present power units mW[h] design capacity 38880 last full charge capacity 29260
status 0x0 rate 0 cap 29172 voltage 12485

real	0m0.311s
user	0m0.100s
sys	0m0.000s

tppow is a C implementation of the disassembled APCI method for reading the
battery status. It does not disable interrupts but does talk to the
embedded controller in the Thinkpad.

> BTW, I have set CONFIG_APM_ALLOW_INT, and on startup the kernel even says
> "IBM machine detected. Enabling interrupts during APM calls." Doesn't
> seem to help, though.

This just means that we enter the BIOS with interrupts enabled, it doesn't
stop the BIOS from disabling interrupts ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[Frank Otto]

Hello Stephen,

On Thu, Aug 29, 2002 at 12:11:03PM +1000, Stephen Rothwell wrote:
> Hi Frank,
> 
> On Wed, 28 Aug 2002 17:04:33 +0200 Frank.Otto@tc.pci.uni-heidelberg.de wrote:
> > it's only a tad worse. When I have the battstat_applet running (which
> > checks the battery every second), kernel time runs about 3% slow
> > compared to the RTC (which seems to be half-way accurate on my machine).
> 
> Don't do that then.  Why would you need to check the battery status
> every second?  Check every 30 seconds.  Does your battery even update its
> status more often than that?

I know it's stupid to check the battery every second, but frankly,
I haven't found a way to configure this in battstat_applet (of course,
it's possible by fixing the sources). Luckily, there's also battery_applet
for the gnome-panel, which has the same functionality, and additionally
lets you configure the update time. However, it doesn't look so spiffy :)

> > The cause seems to be definitely APM. If I shut off battstat_applet
> > and apmd, kernel time and RTC are in sync. With only apmd, I lose about
> > 15 seconds per hour. With battstat_applet, I lose 2 minutes per hour.
> > With
> >   while true; do cat /proc/apm >/dev/null; done
> > the system runs at about 1/4 of the right speed. Using a kernel with ACPI
> > eliminates the problem (of course, you lose almost all power management
> > functionality too).
> 
> Interesting ... Howlong does "cat /proc/apm" take?
> On my Thinkpad T22 I get:
> 
> # time cat /proc/apm
> 1.16 1.2 0x03 0x01 0x00 0x01 99% -1 ?
> 
> real	0m0.009s
> user	0m0.000s
> sys	0m0.010s

Stupid me hasn't thought of trying this, and I don't have my Thinkpad
right here now. Also -- what method does the `time' command use to measure
the time? It doesn't check the RTC, does it? And if the kernel clock stands
still during the /proc/apm access, `time' couldn't notice that real time
has passed, could it? Anyway, I'll try the `time' method this evening.

> while ...
> 
> # time ./tppow
> Battery 0 present power units mW[h] design capacity 38880 last full charge capacity 29260
> status 0x0 rate 0 cap 29172 voltage 12485
> 
> real	0m0.311s
> user	0m0.100s
> sys	0m0.000s
> 
> tppow is a C implementation of the disassembled APCI method for reading the
> battery status. It does not disable interrupts but does talk to the
> embedded controller in the Thinkpad.

When I built a kernel 2.4.19 with ACPI, I also applied the latest patches from
acpi.sourceforge.net . This gave me /proc/acpi/battery/BAT0/state, reading
from which didn't slow down the kernel clock at all. (Sadly, ACPI doesn't
seem to report any events on my machine, so I'll stick with APM.)

> > BTW, I have set CONFIG_APM_ALLOW_INT, and on startup the kernel even says
> > "IBM machine detected. Enabling interrupts during APM calls." Doesn't
> > seem to help, though.
> 
> This just means that we enter the BIOS with interrupts enabled, it doesn't
> stop the BIOS from disabling interrupts ...

Does this mean that the BIOS is buggy, or does this behaviour still
comply to the APM specifications? Just wondering.

Regards,
Frank

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[mike heffner]

Hi Stephen,

  I have timed the "cat /proc/apm" to take at least
36ms on my inspiron 8100 using an external clock.  I
shut down my ntp daemon so the clock is free running. 
I then did "ntpdate -q clock".  With no calls to apm
the number returned is rather stable over a few
minuites with multiple ntpdate calls.  I then execute
10 times "cat /proc/apm" and do "ntpdate -q clock"
again.  I take the difference and divide by 10.  That
gives me an average of about 36ms, or 3 to 4
interrupts missed for each call.
  Last night I also ran though all of Dell's BIOSs.  I
installed each of the 8 or so of them on there web
site.  A few of them broke apm, but none fixed this
problem.  If we are sure the BIOS is the problem, I
will continue to pester Dell.  So just to verify, you
are *not* disabling interrupts in the kernel for an
apm call?  I am still trying to understand the code.
  I have also tried kernel 2.4.2-2.  I don't remember
this problem with an earlier installation I had on
this laptop.  It turns out it is still a problem with
that kernel version.  I am currently using 2.4.18-10.

Thanks,
Mike

--- Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Frank,
> 
> On Wed, 28 Aug 2002 17:04:33 +0200
> Frank.Otto@tc.pci.uni-heidelberg.de wrote:
> >
> > Alan Cox wrote:
> > > On Mon, 2002-08-26 at 18:00, mike heffner wrote:
> > > > Well, isn't that a nice feature.  Is there a
> > > > workaround for this hardware?
> > >  
> > >  A thinkpad ;)
> > 
> > Unfortunately, that's not true -- I just got an
> IBM Thinkpad R32
> > which exhibits the same behaviour as Mike's Dell
> Inspiron 8100,
> > it's only a tad worse. When I have the
> battstat_applet running (which
> > checks the battery every second), kernel time runs
> about 3% slow
> > compared to the RTC (which seems to be half-way
> accurate on my machine).
> 
> Don't do that then.  Why would you need to check the
> battery status
> every second?  Check every 30 seconds.  Does your
> battery even update its
> status more often than that?
> 
> > The cause seems to be definitely APM. If I shut
> off battstat_applet
> > and apmd, kernel time and RTC are in sync. With
> only apmd, I lose about
> > 15 seconds per hour. With battstat_applet, I lose
> 2 minutes per hour.
> > With
> >   while true; do cat /proc/apm >/dev/null; done
> > the system runs at about 1/4 of the right speed.
> Using a kernel with ACPI
> > eliminates the problem (of course, you lose almost
> all power management
> > functionality too).
> 
> Interesting ... Howlong does "cat /proc/apm" take?
> On my Thinkpad T22 I get:
> 
> # time cat /proc/apm
> 1.16 1.2 0x03 0x01 0x00 0x01 99% -1 ?
> 
> real	0m0.009s
> user	0m0.000s
> sys	0m0.010s
> 
> while ...
> 
> # time ./tppow
> Battery 0 present power units mW[h] design capacity
> 38880 last full charge capacity 29260
> status 0x0 rate 0 cap 29172 voltage 12485
> 
> real	0m0.311s
> user	0m0.100s
> sys	0m0.000s
> 
> tppow is a C implementation of the disassembled APCI
> method for reading the
> battery status. It does not disable interrupts but
> does talk to the
> embedded controller in the Thinkpad.
> 
> > BTW, I have set CONFIG_APM_ALLOW_INT, and on
> startup the kernel even says
> > "IBM machine detected. Enabling interrupts during
> APM calls." Doesn't
> > seem to help, though.
> 
> This just means that we enter the BIOS with
> interrupts enabled, it doesn't
> stop the BIOS from disabling interrupts ...
> 
> -- 
> Cheers,
> Stephen Rothwell                   
> sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[Stephen Rothwell]

Hi Mike,

On Thu, 29 Aug 2002 10:19:41 -0700 (PDT) mike heffner <mdheffner@yahoo.com> wrote:
>
>   I have timed the "cat /proc/apm" to take at least
> 36ms on my inspiron 8100 using an external clock.  I
> shut down my ntp daemon so the clock is free running. 
> I then did "ntpdate -q clock".  With no calls to apm
> the number returned is rather stable over a few
> minuites with multiple ntpdate calls.  I then execute
> 10 times "cat /proc/apm" and do "ntpdate -q clock"
> again.  I take the difference and divide by 10.  That
> gives me an average of about 36ms, or 3 to 4
> interrupts missed for each call.

Interesting ... My timings were, of course, very suspect ...

>   Last night I also ran though all of Dell's BIOSs.  I
> installed each of the 8 or so of them on there web
> site.  A few of them broke apm, but none fixed this
> problem.  If we are sure the BIOS is the problem, I
> will continue to pester Dell.  So just to verify, you
> are *not* disabling interrupts in the kernel for an
> apm call?  I am still trying to understand the code.
>   I have also tried kernel 2.4.2-2.  I don't remember
> this problem with an earlier installation I had on
> this laptop.  It turns out it is still a problem with
> that kernel version.  I am currently using 2.4.18-10.

OK, for the Dells, we autodetect the 4000 series and allow
interrupts during BIOS calls, but not the 8000's (unless
your RedHat patched kernel does this).  So could you try
booting with "apm=allow_ints" on the command line (or load
the apm modules with "allow_ints=1"). and try again.  If
this changes things, then we need to add the 8100 to the
list of things we automatically allow interrupts for.

The default from the very beginning has been to disable interrupts
and on most machines this works fine.  The option of leaving
interrupts enabled was introduced when we discovered that the
Thinkpads won't resume if you disable them ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[mike heffner]

Hi Shephen,

I tried this early on, but I just tried it again to
make sure.  There is no noticeable effect from setting
apm=allow_ints at the boot prompt.  So either my
command is not getting set, or the BIOS itself is
restricting the interrupts?  Is there a way to check
that I did indeed allow interrupts?
  I don't know much about BIOS hacking, any
suggestions about how to get the code for the BIOS
(other than disassembling it)?  I bet Dell isn't going
to give it to me.  I am struggling to get them to even
understand the problem.

Thanks,
Mike


--- Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> OK, for the Dells, we autodetect the 4000 series and
> allow
> interrupts during BIOS calls, but not the 8000's
> (unless
> your RedHat patched kernel does this).  So could you
> try
> booting with "apm=allow_ints" on the command line
> (or load
> the apm modules with "allow_ints=1"). and try again.
>  If
> this changes things, then we need to add the 8100 to
> the
> list of things we automatically allow interrupts
> for.
> 
> The default from the very beginning has been to
> disable interrupts
> and on most machines this works fine.  The option of
> leaving
> interrupts enabled was introduced when we discovered
> that the
> Thinkpads won't resume if you disable them ...
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

Re: PROBLEM: conflict between apm and system clock on Inspiron 8100

[Frank Otto]

Hi Stephen,

On Thu, Aug 29, 2002 at 12:11:03PM +1000, Stephen Rothwell wrote:
> 
> Interesting ... Howlong does "cat /proc/apm" take?
> On my Thinkpad T22 I get:
> 
> # time cat /proc/apm
> 1.16 1.2 0x03 0x01 0x00 0x01 99% -1 ?
> 
> real	0m0.009s
> user	0m0.000s
> sys	0m0.010s

On my Thinkpad R32, the timings vary:

real:  anything between 15ms and 40ms
user:  mostly 0ms, sometimes 10ms
sys:   mostly 20ms, sometimes 30ms

To get average values, I did this:

blackmagic:~> time for i in `seq 1 600`; do cat /proc/apm >/dev/null; done

real    0m14.775s
user    0m0.700s
sys     0m12.650s

However, these values are rather bogus; I also measured the time with
my digital wristwatch. Result: 60.60s
                               ======
To measure the overhead of the shell command itself, I did this:

blackmagic:~> cat /proc/apm >/tmp/apm 
blackmagic:~> time for i in `seq 1 600`; do cat /tmp/apm >/dev/null; done

real    0m1.769s
user    0m0.900s
sys     0m0.690s

For the sake of simplicity, this overhead can be neglected. So:
reading /proc/apm 600 times roughly takes 60 real seconds, which
means that reading it once takes about 100ms. This is huge, isn't it?

BTW, I tried this both with apm_allow_ints enabled and disabled.
Didn't make much difference. (And my Thinkpad didn't hang after
the BIOS calls with apm_allow_ints disabled, so maybe IBM has fixed
a bug? By introducing another one ;-)

I think I haven't mentioned yet that I'm using a vanilla 2.4.19 kernel.

> while ...
> 
> # time ./tppow
> Battery 0 present power units mW[h] design capacity 38880 last full charge capacity 29260
> status 0x0 rate 0 cap 29172 voltage 12485
> 
> real	0m0.311s
> user	0m0.100s
> sys	0m0.000s
> 
> tppow is a C implementation of the disassembled APCI method for reading the
> battery status. It does not disable interrupts but does talk to the
> embedded controller in the Thinkpad.

Interesting. Where can I get `tppow'? Would it even be safe to use it
on a different Thinkpad?

Thanks,
Frank