This is the next episode of the Samsung saga! I have now got it to resume successfully after hibernation but not after suspend/sleep. The graphics chip causing all the problems is a Via Chrome 9.

The two problems have completely different symptoms:

Resuming from hibernation: screen cycles through colours, keyboard is completely dead. Cause: a misbehaving kernel module (viafb). Solution: a hook script that unloads the module on suspend/hibernate and restores it after thaw/resume.
Resuming from sleep: screen is completely blank but keyboard is active (caps lock switches on the caps led and ctrl-alt-del works normally). Evidently I have a working console but not working video.

There is a pm-utils hook script called 99video which offers itself for troubleshooting video problems but doesn't give any guidance on how to use it.

Bear in mind that I have absolutely no idea how video works. Someone will have to lead me by the hand on this.

simple answer: it's tricky. it's reverse engineered. it never left beta status on linux, and it never will.
https://duckduckgo.com/?q=linux+via+chrome+9

I'm still playing about with this. Today I suspended while in X. To my surprise, when I resumed, I got a completely normal view of my desktop for a moment, then it spontaneously went back to sleep again. When I resumed for the second time, I got a wildly distorted screen with multiply overlapping images of my open xterm, although the cursor looked completely normal and moved normally. Text consoles remained black but I was able to switch between them and the lit-up graphical screen.

Anyone know what's going on here?

Hi,

From what I have read, it seems the Via Linux drivers are very unstable. Maybe, for some reason, X crashes when you resume from suspend. Are you using the xf86-video-openchrome driver? Maybe this could help: https://wiki.archlinux.org/index.php/Via.

1 members found this post helpful.

Yes, it is xf86-video-openchrome, which I understand to be maintained nowadays by the xorg people. I know that early versions of this driver are seriously buggy; I had one that came with Dragora that wouldn't let me switch between X and virtual consoles. The version I use now is the latest off the xorg site and it doesn't cause any problems when switching consoles or when resuming from hibernation (provided it doesn't resume with the viafb kernel module loaded). That's why I feel I should be able to make it resume from sleep too.

I don't think X is crashing. If it did, I'd have a black screen. That's what happens in my virtual consoles, but in X I get a proper display, albeit a distorted one.

I had looked before at the Arch wiki. It's usually a very good source but this page is rather out of date. I shall try with their config options all the same, if only to exclude them. I have already excluded some of pm-utils' video quirks.

I also need to find out if waking and immediately going to sleep again is normal repeatable behaviour. Only experiment will tell me.

I booted with "nomodeset". Again, I started X, opened a terminal and invoked pm-suspend. The laptop went to sleep. After a couple of minutes, I woke it up. The screen came up perfectly, then it went to sleep again.

This time I didn't wake it up immediately. I waited a few more minutes, then woke it. And whaddyaknow! It came up perfectly and stayed up. The virtual consoles are still blank and black but they work otherwise. I was able to shut the machine down normally by blind-typing the shutdown command.

I need to repeat this exact sequence without using nomodeset and see if that makes any difference. Further reports as and when.

OK, I have now split the problem into three, two of which are solvable.

1) Laptop goes to sleep again immediately after waking up. This turns out only to happen when I invoke suspend by pressing the sleep button, not when I call pm-suspend explicitly. Evidently I'm creating two button events, not one, and the second one gets stored and then processed immediately after waking. Either I'm being heavy handed or the button is oversensitive.

2) X shows distorted images. This only happens when I wake the machine up immediately after it has gone to sleep (an unlikely event in real life). If I let it sleep for a while before resuming, X comes up flawlessly.

3) Black screen on virtual consoles although keyboard still works. This is the problem I haven't solved yet. It definitely isn't anything to do with the openchrome driver because that only gets used under X. I know that when X is not involved, the kernel manages the screen directly, but how does it do that? Is there a non-technical explanation available somewhere?

So here's the pattern:

If X is running when I suspend, it's still running when I resume and everything works fine. This is the case even if I gave the suspend command from a virtual console. Resume then takes me back to the same console and it's completely black, but alt+F7 takes me back to my desktop.

If X is not running, I don't seem able to start it on resuming. The screen stays black.

If I shut down X after resuming (ctrl+alt+backspace), and then try to restart it, the same thing happens.

BUT: when I look at the Xorg.0.log afterwards, everything looks normal. There are no obvious errors, no sign of a crash. So it looks as if the screen is working normally after all; I just can't see it! And if that is true in X, it's probably true in the virtual console too.

I've been looking up LCDs in howstuffworks. Apparently they are not self-luminous like a crt display; they depend on having a fluorescent tube lit up behind them. Maybe that's just not coming on by itself. Sound reasonable?

me too, i can't resume after sleep mode in a twinhead machine.

sound is also completely dead. I have installed the codecs.

so I have to set to hibernate all the time.

sleep worked on my desktop flawlessly.

only I can't get the power button to respond correctly. no matter what option I choose in power manager, pushing the power button always results in my machine to power off.

I am using salixOS 14.2.

Interesting pattern. Yes, LCD's need a backlight. Your hypothesis is possible, but then, how to explain the case where X is running. It seems that the backlight is off only for the virtual consoles.

Can you please paste the content of dmesg for the suspend event in both cases: when X is running and when it is not.

OK, relevant parts of dmesg with and without x are attached. Nothing jumps out at me.

Attached Files

	dmesg-nox.txt (5.2 KB, 15 views)
	dmesg-x.txt (5.3 KB, 16 views)

Please start your own thread instead of hijacking mine. That's not just me being stroppy (though hijacking a thread is generally considered rude), but a serious piece of advice, because a post like the one you just made is unlikely ever to get an answer. You'll do much better at getting help if you create an independent post with a reasonably informative title.

The exception would be if you really had exactly the same problem, but the symptoms you describe suggest otherwise.

There definitely was something wrong with the backlight setup. In /sys/class/backlight I found a folder link called acpi_video0, but I couldn't (even as root) change any of the brightness values in it.

If I boot with acpi_backlight=vendor, I get a folder link called /sys/class/backlight/samsung containing editable files. That doesn't solve my main problem but it definitely looks more appropriate.

Also I've discovered something odd: if I now echo a number into the backlight brightness file from a virtual console, it changes the appearance of the screen, but in X it doesn't. So something going wrong with the backlight could in theory cause a problem that only affected virtual consoles.

Yes, no big difference. And yes, seems like the backlight is the culprit here. It is possible that when X is running, it restores the backlight to its saved setting in its screen only but the virtual consoles cannot do that on their own.

My laptop boots into runlevel 3 by default. It boots with maximum brightness, so to decrease the brightness in the tty itself at boot I added the following line in /etc/rc.local:
If you can change the brightness in a similar way, then maybe you can try adding that echo line of yours in a file in /etc/pm/sleep.d so that it is executed at resume. Just read the man pages for pm-suspend to know about naming conventions used in that directory.

To ensure that it runs the command at resume only, use

Another disappointment! I added the following two lines to the resume branch of my viafb hook script:
The first was for diagnosis, the second (hopefully) for treatment. But it turned out that the existing brightness saved for inspection in /root/backlight was already 1, the normal value for this parameter. So it's not that the backlight isn't switched on. And explicitly giving it a positive value doesn't make any difference.

I am now systematically trying out various quirks, singly and in combination. I hope I can find some combo that works. I hate to be beaten!