Found the problem.
After disabling CONFIG_APM_CPU_IDLE, the system works fast again.
With pre6 or earlier versions, system works fine though even with
CONFIG_APM_CPU_IDLE enabled.
System is IBM X22 800MHz notebook, 640MB ram.
Thanks,
Jeff
[ [email protected] ]
---------- Forwarded message ----------
Date: Sun, 27 Jan 2002 14:49:06 +0800 (SGT)
From: Jeff Chua <[email protected]>
To: Linux Kernel <[email protected]>
Subject: 2.4.18-pre7 slow
1) keyboard rate is a bit slow on 2.4.18-pre7 compared to 2.4.18-pre6.
2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6 has not such
problem.
Thanks,
Jeff
[ [email protected] ]
> 1) keyboard rate is a bit slow on 2.4.18-pre7 compared to
> 2.4.18-pre6.
> 2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6
> has not such problem.
>
> After disabling CONFIG_APM_CPU_IDLE, the system works fast again.
> With pre6 or earlier versions, system works fine though even with
> CONFIG_APM_CPU_IDLE enabled.
Idle handling in the apm driver was modified in 2.4.18-pre7 .
Back to the drawing board ...
Note that you can disable apm idle handling by setting the
apm idle_threshold parameter to 100. You don't need to
recompile the kernel.
> > 1) keyboard rate is a bit slow on 2.4.18-pre7 compared to
> > 2.4.18-pre6.
> > 2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6
> > has not such problem.
> >
> > After disabling CONFIG_APM_CPU_IDLE, the system works fast again.
> > With pre6 or earlier versions, system works fine though even with
> > CONFIG_APM_CPU_IDLE enabled.
>
> Idle handling in the apm driver was modified in 2.4.18-pre7 .
> Back to the drawing board ...
The keyboard rate one is curious. The vmware one I can easily believe is
caused by Vmware switching in/out of OS's without managing the APM
state of the processor (and leaving it in powersave)
Not sure its drawing board time, just a little investigation.
Alan
> The keyboard rate one is curious. The vmware one I can easily
> believe is caused by Vmware switching in/out of OS's without
> managing the APM state of the processor (and leaving it in
> powersave)
APM idling is done if apm_cpu_idle() is called, and then if
DELTA(current->times.tms_stime)
-------------------------------
DELTA(jiffies)
is greater than the idle threshold of 0.95. Could that ratio be
affected by VMware? If so, how?
--
Thomas
I wrote:
> APM idling is done if apm_cpu_idle() is called, and then if
> DELTA(current->times.tms_stime)
> -------------------------------
> DELTA(jiffies)
> is greater than the idle threshold of 0.95. Could that ratio be
> affected by VMware? If so, how?
Herm ... I think what you meant was that (a guest OS under)
VMware might be telling the APM BIOS to idle the CPU.
In that case, apm management should be shut off in either
VMware or in the guest OS.
> > managing the APM state of the processor (and leaving it in
> > powersave)
>
> APM idling is done if apm_cpu_idle() is called, and then if
> DELTA(current->times.tms_stime)
> -------------------------------
> DELTA(jiffies)
> is greater than the idle threshold of 0.95. Could that ratio be
> affected by VMware? If so, how?
Suppose vmware decides to switch between running Linux and its virtualised
Windows OS. Can it do this during an interrupt - if so what ensures that
vmware isnt switched to after we have done APM idle calls and slowed the
CPU right down ?
If so then I suspect vmware should be issuing APM cpu busy calls itself
On Mon, 2002-01-28 at 05:14, Alan Cox wrote:
> Suppose vmware decides to switch between running Linux and its virtualised
> Windows OS. Can it do this during an interrupt - if so what ensures that
> vmware isnt switched to after we have done APM idle calls and slowed the
> CPU right down ?
>
> If so then I suspect vmware should be issuing APM cpu busy calls itself
Do you see a difference between VMware and other processes
in their susceptibility to this problem? If VMware runs
slowly because it gets scheduled in while the CPU is idle
and the apm driver fails to busyize the CPU, won't the same
thing happen for other processes? If so, then our idle
handling is fundamentally broken. If not, then what makes
VMware special?
On 28 Jan 2002 06:25:05 -0500
Thomas Hood <[email protected]> wrote:
> On Mon, 2002-01-28 at 05:14, Alan Cox wrote:
> > If so then I suspect vmware should be issuing APM cpu busy calls itself
>
> Do you see a difference between VMware and other processes
> in their susceptibility to this problem? If VMware runs
> slowly because it gets scheduled in while the CPU is idle
> and the apm driver fails to busyize the CPU, won't the same
> thing happen for other processes? If so, then our idle
> handling is fundamentally broken. If not, then what makes
> VMware special?
Maybe it's just broken. I have some strange problems with hanging vmware 3
(reproducable) on a SMP machine. On an equal machine vmware 2 runs
flawlessly. There is no APM or the like involved, both under 2.4.18-pre7.
I just don't trust it.
Regards,
Stephan
> > If so then I suspect vmware should be issuing APM cpu busy calls itself
>
> Do you see a difference between VMware and other processes
> in their susceptibility to this problem? If VMware runs
> slowly because it gets scheduled in while the CPU is idle
> and the apm driver fails to busyize the CPU, won't the same
> thing happen for other processes? If so, then our idle
> handling is fundamentally broken. If not, then what makes
> VMware special?
We don't know how VMware switches between virtual machines. If that
switch is done behind Linux back, then VMware is effectively special. It
is virtualising the system and it has to virtualise APM status too. If its
doing the switch when it is a current foreground process then it wouldnt
explain the problem
On Mon, 2002-01-28 at 08:18, Alan Cox wrote:
> We don't know how VMware switches between virtual machines. If that
> switch is done behind Linux back, then VMware is effectively special.
> It is virtualising the system and it has to virtualise APM status too.
> If its doing the switch when it is a current foreground process then
> it wouldnt explain the problem
VMware is essentially a hardware emulator, so if the guest OS is
idling the CPU it should only be idling the virtual CPU, not the
real one.
Having said that, VMware emulates a lot of hardware by making
use of facilities that Linux provides. It emulates a super-VGA
card by making use of X, for example. Do you suppose that
VMware emulates CPU slowing by slowing the real CPU? I hope not.
Since VMware is closed source software we needn't worry our
heads too much about this problem. VMware users have a
workaround: set idle_threshold to 100.
Can we get more info about the keyboard repeat rate slowing?
--
Thomas
On Sun, 27 Jan 2002, Stephan von Krawczynski wrote:
> > 1) keyboard rate is a bit slow on 2.4.18-pre7 compared to 2.4.18-pre6.
> What _exactly_ does this mean? Can you elaborate more on your setup and
> your problem?
Sorry, just got off a long flight from San Diego to Singapore. Anyway,
slow ... means that even without vmware, if I just hit return, the lines
would scroll for about every 10 lines and there'll be a litte pause (<0.3
sec). With pre6, there's no such behavior, and if CONFIG_APM_CPU_IDLE is
not set, the "pause" goes away.
> > 2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6 has not
> such problem.
> 1) linux with vmware and guest system linux
"host" system is linux. "guest" system is linux (actually, I tried with NT
as well, same problem).
The sympton is when I try to ping the "host" from vmware's "guest" system,
the first response came back to the guest's console. Then if I don't type
anything or don't move the mouse on the guest's console, I won't see any
further response on the guest's linux console. Even with a lot of mouse
movement or pressing the keys, the response is still very slow with "ping".
If I ping from the "host" linux console to the "guest" linux system,
responses came back, and does not hang. I'll double check this last point.
Got to recompile the kernel again.
Jeff
On Tue, 29 Jan 2002, Jeff Chua wrote:
> > > 1) keyboard rate is a bit slow on 2.4.18-pre7 compared to 2.4.18-pre6.
> > What _exactly_ does this mean? Can you elaborate more on your setup and
> > your problem?
>
> slow ... means that even without vmware, if I just hit return, the lines
> would scroll for about every 10 lines and there'll be a litte pause (<0.3
> sec). With pre6, there's no such behavior, and if CONFIG_APM_CPU_IDLE is
> not set, the "pause" goes away.
2.0 cps on "guest" linux os just pressing "g". 30 cps on "host" linux os.
>
> > > 2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6 has not
> > such problem.
> > 1) linux with vmware and guest system linux
>
> "host" system is linux. "guest" system is linux (actually, I tried with NT
> as well, same problem).
>
> If I ping from the "host" linux console to the "guest" linux system,
> responses came back, and does not hang. I'll double check this last point.
> Got to recompile the kernel again.
slow from "guest" os to "host" os.
slow from "guest" os to guest's 127.0.0.1
fast from "host" os to "guest" os.
If I set idle_threshold to 100, problem goes away.
APM is not enabled on "guest" os.
Jeff.
On Mon, 2002-01-28 at 15:11, Jeff Chua wrote:
> Sorry, just got off a long flight from San Diego to Singapore. Anyway,
> slow ... means that even without vmware, if I just hit return, the lines
> would scroll for about every 10 lines and there'll be a litte pause (<0.3
> sec). With pre6, there's no such behavior, and if CONFIG_APM_CPU_IDLE is
> not set, the "pause" goes away.
Suggestion: Try setting the idle_threshold to a higher value,
e.g., 98. (The default value is 95.)
Question to all: Would it be a good idea to de-idle the CPU
inside interrupt handlers?
> "host" system is linux. "guest" system is linux (actually, I tried with NT
> as well, same problem).
>
> The sympton is when I try to ping the "host" from vmware's "guest" system,
> the first response came back to the guest's console. Then if I don't type
> anything or don't move the mouse on the guest's console, I won't see any
> further response on the guest's linux console. Even with a lot of mouse
> movement or pressing the keys, the response is still very slow with "ping".
> If I ping from the "host" linux console to the "guest" linux system,
> responses came back, and does not hang. I'll double check this last point.
> Got to recompile the kernel again.
Try disabling APM cpu idling (set apm idle_threshold to 100) in the
_guest_ OS. (Leave it enabled in the host OS.) Tell us what happens.
Also try disabling APM cpu idling (set apm idle_threshold to 100) in
the _host_ OS. (Leave it enabled in the guest OS.) Tell us what
happens.
I repeat: You do not need to recompile the kernel to enable/disable
APM cpu idle: to disable it simply set idle_threshold to 100.
> Question to all: Would it be a good idea to de-idle the CPU
> inside interrupt handlers?
If you call APM routines from inside APM routines weirdness occurs - so
the answer is no. I'd say that unless this is shown to be occuring in
non vmware stuff its up to vmware to handle the apm situation right
>
> On Sun, 27 Jan 2002, Stephan von Krawczynski wrote:
>
> > > 1) keyboard rate is a bit slow on 2.4.18-pre7 compared to
2.4.18-pre6.
> > What _exactly_ does this mean? Can you elaborate more on your
setup and
> > your problem?
>
> Sorry, just got off a long flight from San Diego to Singapore.
Anyway,
> slow ... means that even without vmware, if I just hit return, the
lines
> would scroll for about every 10 lines and there'll be a litte pause
(<0.3
> sec). With pre6, there's no such behavior, and if
CONFIG_APM_CPU_IDLE is
> not set, the "pause" goes away.
Ok, I cannot see this one, I have no APM enabled on my boxes. Sorry.
> > > 2) On vmware 3.0, ping localhost is very slow. 2.4.18-pre6 has
not
> > such problem.
> > 1) linux with vmware and guest system linux
>
> "host" system is linux. "guest" system is linux (actually, I tried
with NT
> as well, same problem).
>
> The sympton is when I try to ping the "host" from vmware's "guest"
system,
> the first response came back to the guest's console. Then if I don't
type
> anything or don't move the mouse on the guest's console, I won't see
any
> further response on the guest's linux console. Even with a lot of
mouse
> movement or pressing the keys, the response is still very slow with
"ping".
This is interesting.
I have not set up a guest linux yet, but I experienced a problem with
Win98 guest which may sound related:
I start the guest win98 and try to open a dos-window. The window opens
but no output is presented (no prompt, no nothing) and guest system
somehow "hangs". Sometimes (rarely) I can make it work again by
hitting keys on the keyboard. The effect started off as window coming
up with prompt, I tried to ping the host system, and the first packet
was somehow slow, but then everything was ok. On the next guest boot,
some output appeared at the dosbox, but the prompt was delayed. Now I
get no prompt no matter what I try.
Host system is 2.4.18-pre7.
Vmware was installed from scratch, win98 guest was installed from
scratch with no additions whatsoever.
ping from host to guest works flawlessly.
> If I ping from the "host" linux console to the "guest" linux system,
> responses came back, and does not hang. I'll double check this last
point.
> Got to recompile the kernel again.
As I never saw this with vmware 2 (even not on 2.4.18-pre7) I would
say version 3 has a real problem somewhere.
Regards,
Stephan
On 28 Jan 02 at 22:20, Alan Cox wrote:
> > Question to all: Would it be a good idea to de-idle the CPU
> > inside interrupt handlers?
>
> If you call APM routines from inside APM routines weirdness occurs - so
> the answer is no. I'd say that unless this is shown to be occuring in
> non vmware stuff its up to vmware to handle the apm situation right
Hi,
unfortunately, majordomo kicked me yesterday evening, so I had to
follow this discussion through web archives, and I have some problems
with understanding why problem happens...
When vmmon switches out of the Linux to the virtual machine, it disables
all (APIC) NMI sources, disables IRQ on the CPU, completely replaces CPU
context (GDT/IDT/...) and switches to VMM, which does not physically
access anything except main memory and things emulated inside VMM
(like accesses to VGA/SVGA framebuffers). When an IRQ arrives to virtual
machine, it disables all IRQs, restores Linux kernel contexts, reenables
NMI sources, and restarts IRQ from vmmon by using INT xx instruction.
And everything this happens in process context (when VMM_RUN ioctl is
invoked).
So this behavior should be completely transparent to Linux kernel,
it should just see VMware process as a HLT instruction executed in vmmon
module, which delays interrupt confirmation/delivery a bit. Only thing
which could cause troubles is SMI arrival - but SMI handler cannot notice
any difference (except that APIC IRQ sources delivered as a NMI to CPU
are disabled), as paging is turned off during SMI handler, and physical
memory contents is same under both vmware and Linux kernel.
So I'm really puzzled.
Best regards,
Petr Vandrovec
[email protected]
P.S.: I'm not trying to say that it is not VMware fault. It probably
is, as I saw same behavior on my old Pentium 120MHz notebook two years
ago - but as problem disappeared as it appeared...
On Mon, 2002-01-28 at 15:11, Jeff Chua wrote:
> Sorry, just got off a long flight from San Diego to Singapore. Anyway,
> slow ... means that even without vmware, if I just hit return, the lines
> would scroll for about every 10 lines and there'll be a litte pause (<0.3
> sec). With pre6, there's no such behavior, and if CONFIG_APM_CPU_IDLE is
> not set, the "pause" goes away.
Suggestion: Try setting the idle_threshold to a higher value,
e.g., 98. (The default value is 95.)
Question to all: Would it be a good idea to de-idle the CPU
inside interrupt handlers?
> "host" system is linux. "guest" system is linux (actually, I tried with NT
> as well, same problem).
>
> The sympton is when I try to ping the "host" from vmware's "guest" system,
> the first response came back to the guest's console. Then if I don't type
> anything or don't move the mouse on the guest's console, I won't see any
> further response on the guest's linux console. Even with a lot of mouse
> movement or pressing the keys, the response is still very slow with "ping".
> If I ping from the "host" linux console to the "guest" linux system,
> responses came back, and does not hang. I'll double check this last point.
> Got to recompile the kernel again.
Try disabling APM cpu idling (set apm idle_threshold to 100) in the
_guest_ OS. (Leave it enabled in the host OS.) Tell us what happens.
Also try disabling APM cpu idling (set apm idle_threshold to 100) in
the _host_ OS. (Leave it enabled in the guest OS.) Tell us what
happens.
I repeat: You do not need to recompile the kernel to enable/disable
APM cpu idle: to disable it simply set idle_threshold to 100.
On Mon, 28 Jan 2002, Thomas Hood wrote:
> Suggestion: Try setting the idle_threshold to a higher value,
> e.g., 98. (The default value is 95.)
With 98, "ping localhost" on "guest" os showed 2 responses, then pause for
few seconds, then response, ...
With 95, I got the 1st response, then nothing. 98 seems better, but still
slow...
With 100, it's perfect.
> Try disabling APM cpu idling (set apm idle_threshold to 100) in the
> _guest_ OS. (Leave it enabled in the host OS.) Tell us what happens.
No difference, still slow. Even with guest os running pre6, it's still
slow.
>
> Also try disabling APM cpu idling (set apm idle_threshold to 100) in
> the _host_ OS. (Leave it enabled in the guest OS.) Tell us what
> happens.
guest os "ping localhost" is perfect.
> I repeat: You do not need to recompile the kernel to enable/disable
> APM cpu idle: to disable it simply set idle_threshold to 100.
Ok got it. But still have to reboot machine as the apm is loaded and can't
"rmmod apm". Complained that it's in use ([kapmd] even after stopping
apmd.
By the way, setting power_off=1 or realmode_power_off=1 does not power off
the h/w.
Thanks,
Jeff.
On Tue, 29 Jan 2002, Stephan von Krawczynski wrote:
> Ok, I cannot see this one, I have no APM enabled on my boxes. Sorry.
If I set apm idle off, vmware guest os "ping localhost" works fine.
> As I never saw this with vmware 2 (even not on 2.4.18-pre7) I would
> say version 3 has a real problem somewhere.
Never had any problem with vmware3 until pre7.
Try to test vmware2 on pre7 with apm cpu_idle enabled. I think you'll see
the same problem. Again, pre6 with apm cpu_idle enabled works fine.
Jeff
On 29 Jan 02 at 20:36, Jeff Chua wrote:
> On Mon, 28 Jan 2002, Thomas Hood wrote:
>
> > Suggestion: Try setting the idle_threshold to a higher value,
> > e.g., 98. (The default value is 95.)
>
> With 98, "ping localhost" on "guest" os showed 2 responses, then pause for
> few seconds, then response, ...
>
> With 95, I got the 1st response, then nothing. 98 seems better, but still
> slow...
>
> With 100, it's perfect.
I've got an idea - if you were saying that ping host->guest is fine,
but other way around it does not work. Can you apply
ftp://platan.vc.cvut.cz/pub/vmware/vmware-ws-1455-update5.tar.gz
to your VMware 3.x? Stock vmware-3.x modules use netif_rx() instead
of netif_rx_ni(), and so network bottom half was not run under some
conditions.
Patch also allows you to run VMware on 2.5.3-pre5, BTW.
Best regards,
Petr Vandrovec
[email protected]
> On 29 Jan 02 at 20:36, Jeff Chua wrote:
> > On Mon, 28 Jan 2002, Thomas Hood wrote:
> >
> > > Suggestion: Try setting the idle_threshold to a higher value,
> > > e.g., 98. (The default value is 95.)
> >
> > With 98, "ping localhost" on "guest" os showed 2 responses, then
pause for
> > few seconds, then response, ...
> >
> > With 95, I got the 1st response, then nothing. 98 seems better,
but still
> > slow...
> >
> > With 100, it's perfect.
>
> I've got an idea - if you were saying that ping host->guest is fine,
> but other way around it does not work. Can you apply
> ftp://platan.vc.cvut.cz/pub/vmware/vmware-ws-1455-update5.tar.gz
> to your VMware 3.x? Stock vmware-3.x modules use netif_rx() instead
> of netif_rx_ni(), and so network bottom half was not run under some
> conditions.
>
> Patch also allows you to run VMware on 2.5.3-pre5, BTW.
We are completely OT here, but anyway it may be common interest:
Applying this patch makes some of my problems go. dos-box does no
longer hang the whole guest system, but succeeds in 4 of 5 runs. If it
does not output anything inside the dos-window and I hit the
fullscreen (ALT-ENTER) everything is normal, ALT-ENTER again shows the
correct win desktop with dos-box and correct output there.
It is almost ok, it does not hang, only a minor quirk left.
Thanks,
Stephan
On Tue, 29 Jan 2002, Petr Vandrovec wrote:
> I've got an idea - if you were saying that ping host->guest is fine,
> but other way around it does not work. Can you apply
> ftp://platan.vc.cvut.cz/pub/vmware/vmware-ws-1455-update5.tar.gz
> to your VMware 3.x? Stock vmware-3.x modules use netif_rx() instead
> of netif_rx_ni(), and so network bottom half was not run under some
> conditions.
Applied patch. Still same problem.
On host
modprobe apm idle_threshold=100, guest ping lo, no problem
modprobe apm idle_threshold=99, guest ping lo, slow
Jeff.
On Tue, 2002-01-29 at 07:36, Jeff Chua wrote:
> Ok got it. But still have to reboot machine as the apm is loaded and can't
> "rmmod apm". Complained that it's in use ([kapmd] even after stopping
> apmd.
That's a bug, I think. You should be able to rmmod the apm module.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Hi Jeff, Greg and other interested parties,
Would you like to try another patch? :-)
This is rather longer than needed, it has some tidy ups from Thomas
Hood as well. I have basically simplified the idle loop and added
a couple of more points where it can escape.
I am not seeing your problems, but then again I am running on an IBM
Thinkpad, so I do BIOS calls with interrupts enabled and the BIOS halts
on idle (as opposed to slowing the CPU). I also have SpeedStep
disabled.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
diff -ruN 2.4.18-pre7/arch/i386/kernel/apm.c 2.4.18-pre7-APM.1/arch/i386/kernel/apm.c
--- 2.4.18-pre7/arch/i386/kernel/apm.c Thu Jan 24 11:33:54 2002
+++ 2.4.18-pre7-APM.1/arch/i386/kernel/apm.c Tue Jan 29 22:56:09 2002
@@ -380,7 +380,7 @@
static int set_pm_idle;
static int suspends_pending;
static int standbys_pending;
-static int waiting_for_resume;
+static int ignore_sys_suspend;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -761,15 +761,6 @@
}
}
-/*
- * If no process has really been interested in
- * the CPU for some time, we want to call BIOS
- * power management - we probably want
- * to conserve power.
- */
-#define IDLE_CALC_LIMIT (HZ * 100)
-#define IDLE_LEAKY_MAX 16
-
static void (*sys_idle)(void);
extern void default_idle(void);
@@ -777,28 +768,24 @@
/**
* apm_cpu_idle - cpu idling for APM capable Linux
*
- * This is the idling function the kernel executes when APM is available. It
- * tries to do BIOS powermanagement based on the average system idle time.
- * Furthermore it calls the system default idle routine.
+ * This is the idling function the kernel executes when APM is available.
+ * It tries to do BIOS power management based on the average system
+ * idle time. Furthermore it calls the system idle routines.
*/
static void apm_cpu_idle(void)
{
- static int use_apm_idle = 0;
- static unsigned int last_jiffies = 0;
- static unsigned int last_stime = 0;
-
- int apm_is_idle = 0;
- unsigned int jiffies_since_last_check = jiffies - last_jiffies;
- unsigned int t1;
+ static int use_apm_idle;
+ static unsigned int last_jiffies;
+ static unsigned int last_stime;
+ int apm_idle_done = 0;
+ unsigned int jiffies_since_last_check;
+
+ jiffies_since_last_check = jiffies - last_jiffies;
recalc:
- if (jiffies_since_last_check > IDLE_CALC_LIMIT) {
- use_apm_idle = 0;
- last_jiffies = jiffies;
- last_stime = current->times.tms_stime;
- } else if (jiffies_since_last_check > idle_period) {
+ if (jiffies_since_last_check > idle_period) {
unsigned int idle_percentage;
idle_percentage = current->times.tms_stime - last_stime;
@@ -809,39 +796,33 @@
last_stime = current->times.tms_stime;
}
- t1 = IDLE_LEAKY_MAX;
-
while (!current->need_resched) {
if (use_apm_idle) {
- unsigned int t;
+ unsigned int t = jiffies;
- t = jiffies;
switch (apm_do_idle()) {
- case 0: apm_is_idle = 1;
- if (t != jiffies) {
- if (t1) {
- t1 = IDLE_LEAKY_MAX;
- continue;
- }
- } else if (t1) {
- t1--;
+ case 0: apm_idle_done = 1;
+ if (t != jiffies)
continue;
- }
break;
- case 1: apm_is_idle = 1;
+ case 1: apm_idle_done = 1;
break;
}
}
+ if (current->need_resched)
+ break;
if (sys_idle)
sys_idle();
else
default_idle();
+ if (current->need_resched)
+ break;
jiffies_since_last_check = jiffies - last_jiffies;
if (jiffies_since_last_check > idle_period)
goto recalc;
}
- if (apm_is_idle)
+ if (apm_idle_done)
apm_do_busy();
}
@@ -1196,7 +1177,7 @@
if (apm_info.connection_version > 0x100)
apm_set_power_state(APM_STATE_REJECT);
err = -EBUSY;
- waiting_for_resume = 0;
+ ignore_sys_suspend = 0;
printk(KERN_WARNING "apm: suspend was vetoed.\n");
goto out;
}
@@ -1295,16 +1276,15 @@
break;
}
/*
- * If we are already processing a SUSPEND,
- * then further SUSPEND events from the BIOS
- * will be ignored. We also return here to
- * cope with the fact that the Thinkpads keep
- * sending a SUSPEND event until something else
- * happens!
+ * If we are already processing a SUSPEND, then
+ * further SUSPEND events from the BIOS should
+ * be ignored. We have to check for this because
+ * Thinkpads keep sending SUSPEND events until
+ * something else happens!
*/
- if (waiting_for_resume)
+ if (ignore_sys_suspend)
return;
- waiting_for_resume = 1;
+ ignore_sys_suspend = 1;
queue_event(event, NULL);
if (suspends_pending <= 0)
(void) suspend(1);
@@ -1313,7 +1293,7 @@
case APM_NORMAL_RESUME:
case APM_CRITICAL_RESUME:
case APM_STANDBY_RESUME:
- waiting_for_resume = 0;
+ ignore_sys_suspend = 0;
last_resume = jiffies;
ignore_bounce = 1;
if ((event != APM_NORMAL_RESUME)
@@ -1381,7 +1361,7 @@
if (exit_kapmd)
break;
/*
- * Ok, check all events, check for idle (and mark us sleeping
+ * Ok, check all events (and mark us sleeping
* so as not to count towards the load average)..
*/
set_current_state(TASK_INTERRUPTIBLE);
@@ -1455,6 +1435,11 @@
return 0;
}
+/*
+ * Note that the drivers may reject a suspend request.
+ * When this happens, no suspend is done, and the ioctl()
+ * returns the EBUSY error code to the user.
+ */
static int do_ioctl(struct inode * inode, struct file *filp,
u_int cmd, u_long arg)
{
On 29 Jan 2002, Thomas Hood wrote:
> On Tue, 2002-01-29 at 07:36, Jeff Chua wrote:
> > Ok got it. But still have to reboot machine as the apm is loaded and can't
> > "rmmod apm". Complained that it's in use ([kapmd] even after stopping
> > apmd.
>
> That's a bug, I think. You should be able to rmmod the apm module.
found the reason why I can't rmmod apm ... xfree is using it. If I start
Xfree first, then modprobe apm, then I can rmmod apm.
Jeff.
On Wed, 30 Jan 2002, Stephen Rothwell wrote:
> Would you like to try another patch? :-)
sure, will try tonight.
> I am not seeing your problems, but then again I am running on an IBM
> Thinkpad, so I do BIOS calls with interrupts enabled and the BIOS halts
> on idle (as opposed to slowing the CPU). I also have SpeedStep
> disabled.
I've a ThinkPad X22.
My .config ...
CONFIG_APM=m
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set
/etc/modules.conf
options apm idle_threshold=95 power_off=1
Jeff
On Wed, 30 Jan 2002, Stephen Rothwell wrote:
> This is rather longer than needed, it has some tidy ups from Thomas
> Hood as well. I have basically simplified the idle loop and added
> a couple of more points where it can escape.
applied, and tested, same problem still persist. Only way right now is to
set idle_threshold to 100.
Sorry for the late reply.
Jeff.