There is a problem with the power management code for console.c
The current code calls do_blank_screen(0); on PM_SUSPEND, and
unblank_screen() on PM_RESUME.
The problem happens when X is the current display while putting the
machine to sleep. The do_blank_screen(0) code will do nothing as
the console is not in KD_TEXT mode.
However, unblank_screen has no such protection. That means that
on wakeup, the cursor timer & console blank timers will be re-enabled
while X is frontmost, causing the blinking cursor to be displayed on
top of X, and other possible issues.
I hacked the following pacth to work around this. It appear to work
fine, but since the console code is pretty complex, I'm not sure about
possible side effects and I'd like some comments before submiting it
to Linus:
(Don't worry about the {} I added, I just noticed them and will remove
them before submitting ;)
--- 1.2/drivers/char/console.c Sat Feb 10 18:54:15 2001
+++ edited/drivers/char/console.c Sun Mar 25 17:57:46 2001
@@ -2595,8 +2595,9 @@
int currcons = fg_console;
int i;
- if (console_blanked)
+ if (console_blanked) {
return;
+ }
/* entering graphics mode? */
if (entering_gfx) {
@@ -2660,12 +2661,16 @@
printk("unblank_screen: tty %d not allocated ??\n", fg_console+1);
return;
}
+ currcons = fg_console;
+ if (vcmode != KD_TEXT) {
+ console_blanked = 0;
+ return;
+ }
console_timer.function = blank_screen;
if (blankinterval) {
mod_timer(&console_timer, jiffies + blankinterval);
}
- currcons = fg_console;
console_blanked = 0;
if (console_blank_hook)
console_blank_hook(0);
Benjamin Herrenschmidt wrote:
> There is a problem with the power management code for console.c
>
> The current code calls do_blank_screen(0); on PM_SUSPEND, and
> unblank_screen() on PM_RESUME.
>
> The problem happens when X is the current display while putting the
> machine to sleep. The do_blank_screen(0) code will do nothing as
> the console is not in KD_TEXT mode.
> However, unblank_screen has no such protection. That means that
> on wakeup, the cursor timer & console blank timers will be re-enabled
> while X is frontmost, causing the blinking cursor to be displayed on
> top of X, and other possible issues.
On that theme of power management with X problems, I have been having
trouble with my laptop crashing when the lid is closed, instead of
suspending as it used to. The laptop is a Toshiba Satellite 4070CDT.
The problem appeared around the time I updated the XFree86-4 package to
Red Hat 7's latest update, but I also updated to kernel 2.4.2 around
the same time so I'm not sure of the cause.
Until recently, closing the lid caused the machine to beep three times,
sync data to disk and suspend, then opening the lid resumed. This
worked with or without X displaying.
Now if I switch to a text console and then suspend, it is fine.
If I have X displaying, closing the lid causes the machine to
beep... and beep and beep. About half the time it does suspend after
many more beeps than usual (e.g. 10 seconds pass before deciding to sync
to disk), and in that case it usually resumes ok but sometimes it
resumes and the machine is not responding to keyboard input. When this
happens, a hard reboot is required. (SysRq doesn't work).
The other half of the time it just beeps repeatedly forever. Mouse
input doesn't work, nor does keyboard. Curiously, SysRq-S-U-B still
syncs and reboots the machine with a clean disk from this state.
These effects might have something to do with APM in current kernels
and/or XFree86-4.0.1-1 from Red Hat 7 updates. Has anyone observed
similar recent problems?
-- Jamie
Hi Jamie,
Jamie Lokier <[email protected]> writes:
>
> On that theme of power management with X problems, I have been having
> trouble with my laptop crashing when the lid is closed, instead of
> suspending as it used to. The laptop is a Toshiba Satellite 4070CDT.
Can you please try adding
Option "NoPM"
to the device section of XF86Config or (XF86Config) and then try suspending
and resuming.
This made suspend/resume much more reliable on the Thinkpad 600E with
XFree86 4. Also you could try XFree86 4.0.2, as I know that it actually
does interact with APM (4.0.1 may have as well - I am not sure).
Cheers,
Stephen Rothwell [email protected]
Stephen Rothwell wrote:
> > On that theme of power management with X problems, I have been having
> > trouble with my laptop crashing when the lid is closed, instead of
> > suspending as it used to. The laptop is a Toshiba Satellite 4070CDT.
>
> Can you please try adding
> Option "NoPM"
> to the device section of XF86Config or (XF86Config) and then try suspending
> and resuming.
>
> This made suspend/resume much more reliable on the Thinkpad 600E with
> XFree86 4. Also you could try XFree86 4.0.2, as I know that it actually
> does interact with APM (4.0.1 may have as well - I am not sure).
I'll try Option "NoPM", and XFree86 4.0.2 if I can find a conveniently
RH7 compatible RPM.
I should point out that I've been using _some_ version of XFree86 4
since before version 4.0 was released. (XFree86 3 doesn't support this
laptop's video adapter). Suspend/resume worked fine and reliably until
recently.
Another problem is that occasionally when X starts now, it will freeze
the system. So I suspect a bug was introduced in XFree86 4.0.1.
-- Jamie
Jamie Lokier wrote:
> > > On that theme of power management with X problems, I have been having
> > > trouble with my laptop crashing when the lid is closed, instead of
> > > suspending as it used to. The laptop is a Toshiba Satellite 4070CDT.
> >
> > Can you please try adding
> > Option "NoPM"
> > to the device section of XF86Config or (XF86Config) and then try suspending
> > and resuming.
> >
> > This made suspend/resume much more reliable on the Thinkpad 600E with
> > XFree86 4. Also you could try XFree86 4.0.2, as I know that it actually
> > does interact with APM (4.0.1 may have as well - I am not sure).
>
> I'll try Option "NoPM", and XFree86 4.0.2 if I can find a conveniently
> RH7 compatible RPM.
I tried Option "NoRPM" with XFree86 4.0.1 and it seems to have fixed the
problem! Yay! Closing lid: suspend happens after a few beeps. Open
lid, computer resumes and is working normally. I guess the new code in
XFree86 was problematic. Perhaps it's fixed in 4.0.2, but I haven't
tried that.
I've noticed other changes in suspend/resume. I'm running Gnome now,
and it insists on running xscreensaver whenever I close the lid.
Somehow it is noticing the APM event, because this is very consistent.
Does anyone know how to disable this? The setting "No screensaver"
under the list of screensavers didn't help -- it just runs a blank
screensaver which is even more confusing, because the computer appears
not to have resumed (when it's just a black screensaver).
cheers,
-- Jamie
>
> I should point out that I've been using _some_ version of XFree86 4
> since before version 4.0 was released. (XFree86 3 doesn't support this
> laptop's video adapter). Suspend/resume worked fine and reliably until
> recently.
>
> Another problem is that occasionally when X starts now, it will freeze
> the system. So I suspect a bug was introduced in XFree86 4.0.1.
>
> -- Jamie
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Jamie Lokier wrote:
>
> I've noticed other changes in suspend/resume. I'm running Gnome now,
> and it insists on running xscreensaver whenever I close the lid.
> Somehow it is noticing the APM event, because this is very consistent.
> Does anyone know how to disable this? The setting "No screensaver"
> under the list of screensavers didn't help -- it just runs a blank
> screensaver which is even more confusing, because the computer appears
> not to have resumed (when it's just a black screensaver).
Look at the s option in the man pages for xset, that may help.
--
Rafael
Rafael E. Herrera wrote:
> > I've noticed other changes in suspend/resume. I'm running Gnome now,
> > and it insists on running xscreensaver whenever I close the lid.
> > Somehow it is noticing the APM event, because this is very consistent.
> > Does anyone know how to disable this? The setting "No screensaver"
> > under the list of screensavers didn't help -- it just runs a blank
> > screensaver which is even more confusing, because the computer appears
> > not to have resumed (when it's just a black screensaver).
>
> Look at the s option in the man pages for xset, that may help.
That is about when to blank/power down the display isn't it?
I know that xscreensaver watches for that (according to the man page),
and doesn't draw anything while the monitor's powered down.
But how do I stop xscreensaver from being started in the first place?
-- Jamie
Hello Stephen,
I've just switched from 2.2.18 to 2.4.3 (on a Dell Inpiron 8000, r128 M4
adapter) and I am experimenting some problems with Xfree 4.02 (debian woody)
and (probably) APM. When I resume after a suspend, the X server
hangs. Connecting through ethernet, using strace -p `pid-of-Xfree` wake up
the Xserver. Everything is OK if I use kernel 2.2.18. I've tryed the NoPM
option, but it is ignored by the Xserver:
(WW) R128(0): Option "NoPM" is not used
Any Idea ?
Stephen Rothwell <[email protected]> writes:
> Hi Jamie,
>
> Jamie Lokier <[email protected]> writes:
> >
> > On that theme of power management with X problems, I have been having
> > trouble with my laptop crashing when the lid is closed, instead of
> > suspending as it used to. The laptop is a Toshiba Satellite 4070CDT.
>
> Can you please try adding
> Option "NoPM"
> to the device section of XF86Config or (XF86Config) and then try suspending
> and resuming.
>
> This made suspend/resume much more reliable on the Thinkpad 600E with
> XFree86 4. Also you could try XFree86 4.0.2, as I know that it actually
> does interact with APM (4.0.1 may have as well - I am not sure).
>
> Cheers,
> Stephen Rothwell [email protected]
--
Alain
On Sun, 25 Mar 2001 18:40:03 +0200, Benjamin Herrenschmidt wrote:
>There is a problem with the power management code for console.c
>
>The current code calls do_blank_screen(0); on PM_SUSPEND, and
>unblank_screen() on PM_RESUME.
>
>The problem happens when X is the current display while putting the
>machine to sleep. The do_blank_screen(0) code will do nothing as
>the console is not in KD_TEXT mode.
>However, unblank_screen has no such protection. That means that
>on wakeup, the cursor timer & console blank timers will be re-enabled
>while X is frontmost, causing the blinking cursor to be displayed on
>top of X, and other possible issues.
>
>I hacked the following pacth to work around this. It appear to work
>fine, but since the console code is pretty complex, I'm not sure about
>possible side effects and I'd like some comments before submiting it
>to Linus:
Thanks for this patch. I've been using it on my Dell Latitude laptop
for the last 10 days, and it has been a significant improvement.
Before the patch: After a few days with a 2.4 kernel and RH7.0
(XFree86-4.0.1-1 and XFree86-SVGA-3.3.6-33) the latop would
misbehave at a resume event: when I opened the lid the screen would
unblank and then after less than a second the entire screen would
shift (wrap/rotate) left by about 40% of its width. Restarting X
would only fix this temporarily, as the next resume would have the
same problem. This does not occur with a 2.2 kernel or with the
Accelerated-X server I used before.
With the patch: No problem after 10 days with frequent suspend/resume
cycles. (2.4.2-ac24 + the patch)
[Alan, mind putting this in the next 2.4.3-ac? I've rediffed it
against 2.4.3-ac2.]
/Mikael
--- linux-2.4.3-ac2/drivers/char/console.c.~1~ Wed Apr 4 12:15:28 2001
+++ linux-2.4.3-ac2/drivers/char/console.c Wed Apr 4 12:29:01 2001
@@ -2713,12 +2713,16 @@
printk("unblank_screen: tty %d not allocated ??\n", fg_console+1);
return;
}
+ currcons = fg_console;
+ if (vcmode != KD_TEXT) {
+ console_blanked = 0;
+ return;
+ }
console_timer.function = blank_screen;
if (blankinterval) {
mod_timer(&console_timer, jiffies + blankinterval);
}
- currcons = fg_console;
console_blanked = 0;
if (console_blank_hook)
console_blank_hook(0);
>
>Thanks for this patch. I've been using it on my Dell Latitude laptop
>for the last 10 days, and it has been a significant improvement.
>
>Before the patch: After a few days with a 2.4 kernel and RH7.0
>(XFree86-4.0.1-1 and XFree86-SVGA-3.3.6-33) the latop would
>misbehave at a resume event: when I opened the lid the screen would
>unblank and then after less than a second the entire screen would
>shift (wrap/rotate) left by about 40% of its width. Restarting X
>would only fix this temporarily, as the next resume would have the
>same problem. This does not occur with a 2.2 kernel or with the
>Accelerated-X server I used before.
>
>With the patch: No problem after 10 days with frequent suspend/resume
>cycles. (2.4.2-ac24 + the patch)
>
>[Alan, mind putting this in the next 2.4.3-ac? I've rediffed it
>against 2.4.3-ac2.]
Glad to get some feedback !
I'm still getting other problems related to console.c power management
however. On the PowerBook, occasionally, if suspend is triggered from
a text console, the machine may hang during the sleep process. I don't
quite understand that code in console.c anyway since it seems to trigger
a timer to later call the VESA blank. That timer thing doesn't makes much
sense to me, especially since when the timer fire (if it ever fires),
the machine will probably be sleeping.
The problem with it on powerbooks is that we do suspend the graphic chip
from fbdev layer (later on).
So if after this timer expires, the console code tries to access the chip
in any way, bad things will happen (it will die).
I'm working on workaround at the fbdev level, but I'm curious to know
if that PM code in console.c is useful at all in it's current form,
especially since it plays those tricks with timers which don't seem like
a good idea when the machine is going to sleep.
Ben.
On Wed, 4 Apr 2001 13:09:11 +0200 (MET DST), Mikael Petterson wrote:
> On Sun, 25 Mar 2001 18:40:03 +0200, Benjamin Herrenschmidt wrote:
>
> >There is a problem with the power management code for console.c
> >
> >The current code calls do_blank_screen(0); on PM_SUSPEND, and
> >unblank_screen() on PM_RESUME.
> >
> >The problem happens when X is the current display while putting the
> >machine to sleep. The do_blank_screen(0) code will do nothing as
> >the console is not in KD_TEXT mode.
> >However, unblank_screen has no such protection. That means that
> >on wakeup, the cursor timer & console blank timers will be re-enabled
> >while X is frontmost, causing the blinking cursor to be displayed on
> >top of X, and other possible issues.
> >
> >I hacked the following pacth to work around this. It appear to work
> >fine, but since the console code is pretty complex, I'm not sure about
> >possible side effects and I'd like some comments before submiting it
> >to Linus:
>...
> Before the patch: After a few days with a 2.4 kernel and RH7.0
> (XFree86-4.0.1-1 and XFree86-SVGA-3.3.6-33) the latop would
> misbehave at a resume event: when I opened the lid the screen would
> unblank and then after less than a second the entire screen would
> shift (wrap/rotate) left by about 40% of its width.
>...
> With the patch: No problem after 10 days with frequent suspend/resume
> cycles. (2.4.2-ac24 + the patch)
Correction: While the patch eliminated the X screen wrap problem at resume,
it caused a new problem: now when I exit X the console is left in a blanked
state. This seems to happen if at least one suspend/resume cycle has
occurred before X is terminated.
After some experimentation I came up with the patch below (vs. 2.4.3-ac3)
which _so_far_ behaves ok on my laptop. If the resume-while-in-X problems
resurface or not I won't know until after several more days of testing,
but at least the console is unblanked correctly again.
Does _anyone_ understand this code and its interactions with X? I'm lost...
/Mikael
--- linux-2.4.3-ac3/drivers/char/console.c.~1~ Thu Apr 5 15:57:36 2001
+++ linux-2.4.3-ac3/drivers/char/console.c Thu Apr 5 18:52:43 2001
@@ -2713,23 +2713,23 @@
printk("unblank_screen: tty %d not allocated ??\n", fg_console+1);
return;
}
- currcons = fg_console;
- if (vcmode != KD_TEXT) {
- console_blanked = 0;
- return;
- }
console_timer.function = blank_screen;
if (blankinterval) {
mod_timer(&console_timer, jiffies + blankinterval);
}
-
+ currcons = fg_console;
console_blanked = 0;
if (console_blank_hook)
console_blank_hook(0);
set_palette(currcons);
- if (sw->con_blank(vc_cons[currcons].d, 0))
+ if (sw->con_blank(vc_cons[currcons].d, 0)) {
+ if (vcmode != KD_TEXT)
+ return;
/* Low-level driver cannot restore -> do it ourselves */
update_screen(fg_console);
+ }
+ if (vcmode != KD_TEXT)
+ return;
set_cursor(fg_console);
}