console.c unblank_screen problem

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

@@ -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);

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,

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]

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 ?

Alain

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

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

Look at the s option in the man pages for xset, that may help.

     Rafael

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