Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

[solved]no video after resume from suspend

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
agrimstad
Posts: 102
Joined: 2007-10-05 00:55
Location: Hollis, NH, USA

[solved]no video after resume from suspend

#1 Post by agrimstad »

System is a desktop, not a laptop. Running stretch 9.1.

Mobo is Asus P8B75-M LE with integrated Intel video chip. System is using the i915 module for video.

systemctl hibernate seems to work perfectly.

After resume from suspend the only thing I can do is to reboot the system after logging in via ssh from another computer. If there's a way as root to restart just video, I don't know about it.

My workaround is to change the gnome settings for the power button from suspend to hibernate. Googling on this problem hasn't turned up anything helpful so far. Any clues what I might try?
Last edited by agrimstad on 2017-09-08 08:36, edited 1 time in total.

User avatar
debiman
Posts: 3063
Joined: 2013-03-12 07:18

Re: no video after resume from suspend

#2 Post by debiman »

while you ssh into the machine, take a look at logs.
dmesg, Xorg logs, systemd journal (with 'journalctl') etc.
hope you can find sth.

oh and _which_ intel gpu? lspci -k?

agrimstad
Posts: 102
Joined: 2007-10-05 00:55
Location: Hollis, NH, USA

Re: no video after resume from suspend

#3 Post by agrimstad »

I looked at the logs you suggested and there was nothing to my eyes that was screaming "fix me!" However, I did
notice this item in the systemd log:
Sep 03 13:38:16 bigtooth gnome-settings-[1772]: unable to get EDID for
xrandr-default: unable to get EDID for output
The EDID problem has seemed to be cosmetic up to this point: there are some extra lines related to EDID when
the system boots and the gnome settings "Displays" panel says my monitor is an unknown Display. Still, things
seem to work OK. I did add the following to grub to quiet the complaints when booting:

GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset"

The interesting part of lspci -k:
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
Subsystem: ASUSTeK Computer Inc. 4th Gen Core Processor DRAM Controller
Kernel driver in use: hsw_uncore
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06\
\
)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics\
\
Controller (rev 06)
Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller
Kernel modules: i915

User avatar
debiman
Posts: 3063
Joined: 2013-03-12 07:18

Re: no video after resume from suspend

#4 Post by debiman »

are you always booting with nomodeset, or only now for testing purposes?
afaik nomodeset disables the loading of graphic drivers (and the lspci output confirms that - there is no "kernel driver in use" for your gpu).
if the answer is "always", then WHY?

EDID refers to the monitor.
does that message come up after resume from suspend?
usually monitors are fully recognized and there should be no problem with edids. is that a special model?
BUT, that message could be related to the 'nomodeset'.

agrimstad
Posts: 102
Joined: 2007-10-05 00:55
Location: Hollis, NH, USA

Re: no video after resume from suspend

#5 Post by agrimstad »

are you always booting with nomodeset, or only now for testing purposes?
afaik nomodeset disables the loading of graphic drivers (and the lspci output confirms that - there is no "kernel driver in use" for your gpu).
if the answer is "always", then WHY?
First, to answer you, I did it out of ignorance. I googled to find a way to get the EDID hex dump to stop and the recipe I used included booting with nomodeset. At the time it seemed to make the problem go away.

Later, after I had even forgotten about this setting, I ran into some minor problems with the gnome settings applet "Display" not working. (http://forums.debian.net/viewtopic.php?f=6&t=134584) In working through that issue, I discovered that nomodeset was a bad idea and stopped doing it. It made those other problems go away.

Yesterday I moved the stretch installation hard drives to my day-to-day chassis from my test chassis. And this morning I discovered that resume is working correctly. So perhaps nomodeset was the cause of THIS problem too. I presume so. I'm going to mark this solved. Thanks for noticing!

Post Reply