Klystron has a Severe Issue, when Suspending.

In This Earlier Posting, I had written that my Linux laptop named ‘Klystron’ is able to suspend to RAM well and to Resume.

As it turns out, after lengthy experimentation, this was not true. What that system tends to do, after having woken up from Sleep, is to have its clock set ahead by 68 hours. This is a Known Bug. And although there is a script which has been suggested, and which I have gotten to run, which tries to repair this damage in a crude way, that script failed to do so in a complete way.

Even after I have set up This Script to run on Resume, after the first Suspend operation, everything seems to work again well. But after waking up for a second time, I found that the clock is set 136 hours ahead, instead of only being 68 hours ahead. And one reason fw this may happen, could be the fact that the script commands the system clock be set:

date -R --date="-68 hours ago"

This seems to have been a careless mistake, since to set the time to -68 Hours Ago, will actually set the time an additional 68 hours ahead. This can be verified, simply by running the above command from the command-line.

And so I have edited this script, into one which must be compliant with SystemD-based Suspend, instead of with Upstart-based Sleep and Hibernate, and my script needs to be placed into ‘/lib/systemd/system-sleep‘ in order even to get run. And here it is:


# fixing https://bbs.archlinux.org/viewtopic.php?id=173487

case "$1" in
    date +%s > /tmp/suspend.log
    was=`cat /tmp/suspend.log`
    now=`date +%s`
    # time shifts for 68 hours
    if [ $now -gt `expr $was + 244800` ]; then
      date -s "`date -R --date="68 hours ago"`"
    /etc/init.d/nmbd restart


The simple fact that my networking client could be connecting to the network, with false time information, can ‘discredit’ my client in the computerized mind of the router or server. And when a LAN client etc. is discredited, this can lead to connection problems…

For now, I am going to experiment further with trying to correct this. But if I run into further problems with this project, I am likely to abandon it.



I have now chosen against keeping the desktop cube animations.

In This Posting, I wrote that I had enabled a ‘desktop cube’, a compositing effect, on the laptop I name ‘Klystron’. In fact, this KDE effect consisted of two separate effects, the ‘Desktop Cube’, and the ‘Cube Animation’, which look very similar to each other.

Since then, I have discovered that enabling this much compositing (1) prevents me from turning compositing off quickly, with <Alt>+<Shift>+F12, and (2) prevents the screensavers from activating, reducing my screen locking capability to a simple screen locker.

It did not result in any crashes or errors, but presumably to prevent such errors, KDE just did not launch the screensaver.

So even though I felt that it was fun for a while to have these effects enabled, they added rather little to the functionality. I am in favor of using compositing, to whatever extent doing so causes the GPU to take work off the hands of the CPU. But after that, once increased use of these effects interferes in any way with the reliability of the S/W, I will choose against further increases.

And so now I have reversed these desktop effect settings, and gotten my screensaver back.

However, I also double-checked what I had run in to in This Posting, to see whether the GL 3+ Render System now works, belonging to OGRE 1.10 . And alas, the behavior of the OGRE GL 3+ Render System is unchanged. I did not push it to a full crash, but read the debug output again, before it came to that.


(Edit 4/24/2016 : ) This behavior, of not having a screensaver, was logical. With the Desktop Cube effect, the usual KDE output was being rendered to 4 of the faces of a cube, defined as target texture images in OpenGL (Render To Texture, ‘RTT’). This cube was then rendered as a 3D Entity, to the actual screen displayed.

This 3D scene poses the question, of where the screensaver should be inserted. In theory, it would have been possible for the KDE screensaver to be rendered to each of these 4 active cube faces, but not to the actual screen, that acted as the virtual camera position. A simple lock-screen was rendered there.

This was similar, to how the KDE wallpaper was also potentially different, from the Desktop Cube, effect wallpaper. With this effect, there is the standard KDE wallpaper which is seen on each of the active cube faces, which is different from the wallpaper one might choose for the whole scene.

It is a good thing, that the developers added as default behavior, to offer a regular lock screen for the display, when the real screensaver was running, and potentially rendering its animation to 4 of the faces of the cube. Because in the latter place, that screen saver would also have been failing to lock the display.

And one of the behaviors which I have read about, state that there can be problems on some computers, to go into and out of Suspend Mode, if there is active 3D rendering (on the GPU) taking place in the background. A Desktop Cube would be an example, where a 3D rendering pipeline has been inserted, in such a way that it is not removed or deactivated, when the effect seems passive, or when we try to put the laptop into Suspend Mode.

This has sometimes resulted in crashes, because the graphics driver was not up to the Debian version of Suspend Mode, or even because the Index Buffer of the GPU contained garbled data, because the VRAM of the GPU was losing power, in Debian Suspend Mode.