Latest Kernel Update Fails To Solve One Specific Problem.

According to my recent postings, the Linux laptop I name ‘Klystron’ has received a kernel update to version 4.4.0-30-generic. In This Posting, I had written of a specific bug that happened on the laptop, whenever I told it to Suspend To RAM. Specifically, after Resuming, the system clock would end up set exactly 68 hours into the future.

According to my latest test, This latest kernel update did not solve that problem. Therefore, for the time being, I will need to rely on a script which I specifically adapted, to correct the error whenever it happens.



Klystron, Kernel Update a Success

The laptop which I name ‘Klystron’, received a Kernel Update on July 7. This brought its kernel version to 4.4.0-30-generic as far as I can tell.

Prior to this update, one of the problems the laptop was still experiencing, was due to its Realtek WiFi chip-set, and the kernel module ‘RTL8723BE’. It had a malfunction in how it was connecting to my WiFi, which should have set in twice again, since July 7, according to earlier observations I had made. This bug had become quite predictable.

But since the latest kernel update, this malfunction has not been taking place anymore.

So I would say, that this kernel update was a huge, welcome success.

A separate question I have not yet answered, was whether its Suspend Behavior has also been corrected. This will be slightly more complicated for me to test, because as the above posting suggests, I had adapted a script, which seems to correct it. If the problem had been resolved in the kernel update, my script would simply not do anything. And the end result would remain, that the problem is not apparent.

In order to see whether the kernel update actually resolved that issue, I would first need to disable my script, and then try a few Suspend Cycles, since this problem was also not taking place with 100% consistency.

I have not yet committed myself to doing that.



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

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.