Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Yet another sleep/wake screen problem

20 views
Skip to first unread message

Charlie Gibbs

unread,
Jul 1, 2019, 10:56:12 AM7/1/19
to
It's the same old story - a Linux system newly installed on
a laptop will go to sleep when the lid is closed, but doesn't
wake up properly when the lid is opened again. I've searched
the web and found dozens of messages dealing with problems
like this, with no two exactly the same and few showing a
resolution.

Here's my variant. I have a laptop belonging to a friend
who I'm trying to free from the evil clutches of Windows 10.
It's an Acer Aspire 57332-4406. I shrank the Windows partition
to half its size, booted a Debian 9.8.0_amd64 network install
CD that I had burned on another machine, and successfully
installed Debian in the freed disk partition, using mostly
default options with Xfce as the screen manager. I installed
GRUB in the MBR, setting up the machine for dual booting.
I downloaded and installed Seamonkey and made it the default
web browser. I also installed Thunderbird and successfully
copied the user's profile from the Windows partition.

The machine works fine until I close the lid and open it again.
It seems to wake up, but the screen remains black (although its
backlight is on). I can SSH into the laptop from another machine
and run it remotely. If I enter "shutdown" from the remote
machine the screen will briefly show shutdown messages before
powering down.

Running dmesg shows what looks largely like a successfull
sleep and re-awaken, although sprinkled through the wakeup
process are the following suspicious-looking messages:

ehci-pci 0000:00:1c.0: System wakeup disabled by ACPI
pcieport 0000:00:1c.0: System wakeup disabled by ACPI
rtc_cmos 00:01: System wakeup disabled by ACPI

Are these relevant? Any hints as to where to look next?

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ Fight low-contrast text in web pages! http://contrastrebellion.com

Carlos E.R.

unread,
Jul 1, 2019, 11:44:09 AM7/1/19
to
On 01/07/2019 16.56, Charlie Gibbs wrote:
> It's the same old story - a Linux system newly installed on
> a laptop will go to sleep when the lid is closed, but doesn't
> wake up properly when the lid is opened again. I've searched
> the web and found dozens of messages dealing with problems
> like this, with no two exactly the same and few showing a
> resolution.

...

> ehci-pci 0000:00:1c.0: System wakeup disabled by ACPI
> pcieport 0000:00:1c.0: System wakeup disabled by ACPI
> rtc_cmos 00:01: System wakeup disabled by ACPI
>
> Are these relevant? Any hints as to where to look next?

Just to mention that this group seems to have very little traffic, about
seven threads a year. Perhaps you should post instead to
comp.os.linux.misc and alt.os.linux.

About your question, sorry, I'm not familiar with Debian. Yes, those
messages look suspicious.

I think I had a similar problem once, and it was a failing xscreensaver.
Killing it via ssh or ctrl-alt-f1 restored the display.

You should also try ctrl-alt-f1 trick, see if the display is visible there.


--
Cheers, Carlos.

Charlie Gibbs

unread,
Jul 1, 2019, 12:16:18 PM7/1/19
to
On 2019-07-01, Carlos E.R. <robin_...@es.invalid> wrote:

> On 01/07/2019 16.56, Charlie Gibbs wrote:
>
>> It's the same old story - a Linux system newly installed on
>> a laptop will go to sleep when the lid is closed, but doesn't
>> wake up properly when the lid is opened again. I've searched
>> the web and found dozens of messages dealing with problems
>> like this, with no two exactly the same and few showing a
>> resolution.
>
> ...
>
>> ehci-pci 0000:00:1c.0: System wakeup disabled by ACPI
>> pcieport 0000:00:1c.0: System wakeup disabled by ACPI
>> rtc_cmos 00:01: System wakeup disabled by ACPI
>>
>> Are these relevant? Any hints as to where to look next?
>
> Just to mention that this group seems to have very little traffic, about
> seven threads a year. Perhaps you should post instead to
> comp.os.linux.misc and alt.os.linux.

I'll try that if I get no joy here.

> About your question, sorry, I'm not familiar with Debian. Yes, those
> messages look suspicious.
>
> I think I had a similar problem once, and it was a failing xscreensaver.
> Killing it via ssh or ctrl-alt-f1 restored the display.
>
> You should also try ctrl-alt-f1 trick, see if the display is visible there.

That makes the screen light up. Tell me more about ctrl-alt-f1. Is this
an xscreensaver thing? I tried killing xscreensaver from the remote machine,
but that didn't make any difference: the screen still wouldn't light when I
opened the lid, but ctrl-alt-f1 still made it come back.

Carlos E.R.

unread,
Jul 1, 2019, 2:04:10 PM7/1/19
to
On 01/07/2019 18.16, Charlie Gibbs wrote:
> On 2019-07-01, Carlos E.R. <robin_...@es.invalid> wrote:


>> Just to mention that this group seems to have very little traffic, about
>> seven threads a year. Perhaps you should post instead to
>> comp.os.linux.misc and alt.os.linux.
>
> I'll try that if I get no joy here.
>
>> About your question, sorry, I'm not familiar with Debian. Yes, those
>> messages look suspicious.
>>
>> I think I had a similar problem once, and it was a failing xscreensaver.
>> Killing it via ssh or ctrl-alt-f1 restored the display.
>>
>> You should also try ctrl-alt-f1 trick, see if the display is visible there.
>
> That makes the screen light up. Tell me more about ctrl-alt-f1. Is this
> an xscreensaver thing? I tried killing xscreensaver from the remote machine,
> but that didn't make any difference: the screen still wouldn't light when I
> opened the lid, but ctrl-alt-f1 still made it come back.


No, this is standard Linux practice. You get several text mode consoles
on ctrl-alt-f1 to f6. The graphical console may be on ctrl-alt-f7, and
the error console may be on ctrl-alt-f10. Different distros can use
different order/choices.

So if you do ctrl-alt-f1 you may get a working text console with a
prompt for login. Or maybe not, and it is on ctrl-alt-f2. Try. Then
maybe going back to graphics on 7 may work, or not. Debian may use
different numbers.


--
Cheers, Carlos.

Aragorn

unread,
Jul 1, 2019, 3:17:39 PM7/1/19
to
On 01.07.2019 at 20:02, Carlos E.R. scribbled:
Manjaro has the GUI login screen at vc/1, and character-mode login
consoles at vc/2 through vc/6. ;)

--
With respect,
= Aragorn =

Charlie Gibbs

unread,
Jul 1, 2019, 8:55:27 PM7/1/19
to
Ah, right, the alternate consoles. On the box I'm setting up,
ctrl-alt-f1 gives me graphics. Ctrl-alt-f2 gives a screen that
says, "This session is locked. You'll be redirected to the unlock
dialog automatically in a few seconds" - but nothing happens.
Ctrl-alt-f3 through f6 give text-based login screens on tty3
through tty6 respectively. Ctl-alt-f7 gives a blank screen
with a blinking cursor in the upper left-hand corner, and
ctl-alt-f8 through f12 do nothing.

At least I have a way to wake the machine up that's only
slightly arcane. I'll tell my friend, who will probably
be so relieved by the speed of Linux that she won't mind.

Thanks for the hint.

Anssi Saari

unread,
Jul 5, 2019, 2:50:03 PM7/5/19
to
Charlie Gibbs <cgi...@kltpzyxm.invalid> writes:

> Here's my variant. I have a laptop belonging to a friend
> who I'm trying to free from the evil clutches of Windows 10.
> It's an Acer Aspire 57332-4406. I shrank the Windows partition
> to half its size, booted a Debian 9.8.0_amd64 network install
> CD that I had burned on another machine

You might consider running something newer than two years old Debian on
what might be a reasonably new laptop. Not sure though, 57332-4406
doesn't seem like a model number I can find anywhere.
0 new messages