[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Eee PC screen blank on wakeup

I am running Debian squeeze on a Eee PC 1015B.  I can sleep the system
with pm-suspend, but when I wake it up, I get a blank screen.  The OS
doesn't seem to be coming back at all (i.e. the machine just freezes on
wake up), since I get nothing on netconsole when I wake it up.  With the
kernel console log level set to 8 (via dmesg -n 8), the console shows
this on suspend:

[  188.174330] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  188.401118] atl1c 0000:02:00.0: atl1c: eth0 NIC Link is Up<100 Mbps Full Duplex>
[  188.710339] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  188.936808] atl1c 0000:02:00.0: atl1c: eth0 NIC Link is Up<100 Mbps Full Duplex>
[  191.721237] PM: Syncing filesystems ... done.
[  191.745161] PM: Preparing system for mem sleep
[  191.745299] Freezing user space processes ... (elapsed 0.00 seconds) done.
[  191.746346] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
[  191.746802] PM: Entering mem sleep
[  191.746876] Suspending console(s) (use no_console_suspend to debug)

Nothing unusual there.

I'm also getting erratic screen flickering semi-frequently.  Not just
blinking on and off, but liney white noise, like what you can get from
a loose monitor connection.  I'm not sure whether this is related, or
actually just a loose connection.  I suspect it's unrelated, since I get
at the BIOS screen, before the OS has even *started*.

A more likely related problem is the machine (or at least the display)
freezing after it's been on for a while, but this happens rather

I've tried the --quirk-* options to pm-suspend that seemed relevant:

  * --quirk-s3-bios --quirk-s3-mode
  * --quirk-vbe-post
  * --quirk-vbemode-restore
  * --quirk-vbestate-restore

Same symptom.

I tried creating /etc/pm/config.d/00sleep_module with the following
as described here:

I installed the newer kernel from backports and tried that, which boots
to what looks like white noise (like VRAM corruption) almost right away
(in the virtual console, before X is started).

I'm thinking I should next try to get the backports kernel to boot
properly and see if it sleeps properly, but I'll try any other

Aidan Gauland

Reply to: