Re: APM driver patch okay?

[Andreas Steinmetz <ast@domdv.de>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1803 bytes --]

Sorry if the code was to unreadable for you.
I did just try to keep the apm code overhead small and I'm no friend of "local
local" variables. If the code is now better readable that's fine with me.

If you remove the apm module as far as I can see the system can't be in apm
idle state as during module removal the system is not idle, so the system idle
task is not called, so apm is in busy state as apm_cpu_idle() is called via the
system idle task function pointer and asserts that apm_do_busy() is called on
function exit when apm_do_idle was called.

As I can't get useful temperature data out of my laptop (CPU temp 5°C) I do have
to rely on not really measurable things like fan behaviour and estimated
battery lifetime. With the patch I'm back to 2.2 behaviour which is better than
unpatched 2.4 behaviour.

Even if the idle patch may not improve things for biosses that do work
correctly I can't see any degradation in this case. For broken biosses it is an
improvement in any case.

Furthermore the patch removes confusion where the apm kernel thread and the
idle task were both racing for idle time with the result that an idle system
seemed 'heavily loaded' by the apm kernel thread. This may even have caused
unexpected behaviour for processes that use system load information for
processing decisions.

I would suggest to submit the patch in the early 2.4.18pre stages for wider
testing after the hard lockup on module removal is solved as there seem to be no
other complaints.

Regarding the hard lockup there could be a problem in apm_exit(). Assuming that
sys_idle could be NULL if apm initialization was not complete a safer way would
be:

if (idle_threshold < 100 && sys_idle) {
        pm_idle = sys_idle;
        sys_idle = NULL;
}


Andreas Steinmetz
D.O.M. Datenverarbeitung GmbH