Klystron Kernel Update Ends Suspend To RAM Experiments.

Only a few days ago, because that laptop is fully subscribed to Kanotix, the computer with the network name ‘Klystron’ received another kernel update, this time to version ‘4.4.0-34-generic‘, which for some reason also goes by the name ‘4.4.0-35Kanotix‘. This has had slightly sad, but also good consequences:

  1. I can no longer allow Klystron to Suspend To RAM, as by now, doing so sets the time-last-modified of the super-block of its FS into the future. In fact, after a recent reboot, the log-in manager also reported to me, that it was unable to enter the home directory of the main user. This gave me quite a shock, until I noticed, that I was still able to log in as the auxiliary user, after which a full reboot also fixed the super-block. What this means is that all my experiments with Suspend To RAM must end, including hoping that its WiFi chip-set will work after resuming. But, I had written several times, that the performance of the WiFi had improved, as long as I do not suspend the laptop…
  2. I can now focus on a user-configuration, by which closing the laptop lid locks it, but hopefully, the WiFi will stay connected. In hopes of improving the chances of that, in addition to the fact that support may have already been improved in the latest kernel versions, I have additionally set my router only to use a signal-width of 20MHz, i.e. not to use ‘channel bonding’. My logic behind that is, that higher speeds might look good, as long as the signal strength is good. But to cope with the possibly weaker signal of the lid being closed, a narrower WiFi signal-width, as set from the router, may help improve reliability.

But whether that pans out, only time will be able to tell. Even if it does not, simply having the WiFi disconnect and then reconnect, as I reopen the lid, should not be the end of the world.



Linux Support for RTL8723BE Almost Perfect Now

In This Posting, I was continuing a long thread of comments, which began by saying, Linux support for the Realtek WiFi Chipset, that is served by the (linux) RTL8723BE kernel module, was dodgy at first. I was also experiencing problems with this, which required certain patches on my part.

At the same time, my kernel has been upgraded to version ‘4.4.0-30-generic’, on the affected laptop I name ‘Klystron’, which means that kernel-crackers have also been updating the in-tree kernel modules, including the modules RTL8723BE…

What I find is that by now, the behavior of that WiFi-chipset is stable. There was only one problem with it, which I had lastly been reporting, which stated that after the laptop resumes from Suspended-to-RAM, i.e. from a low-power mode that stops it in mid-session and continues to supply very small amounts of current to the DRAM – still performing refresh-cycles – the newly-connected WiFi was experiencing problems again.

Well I found that changing a script which I had written, which was located in the directory


To a newer version, still based on the same principles, gives improved performance:

# 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 ; then
      date -s "`date -R --date="68 hours ago"`"
    sleep 20; /etc/init.d/nmbd restart


The most important difference in the new script, is the unconditional execution of the script command “sleep 20“. My original intention was, that the script should wait for the network connection to be reestablished, before also restarting the ‘nmbd‘ daemon.

But, I observe that the behavior of the kernel, is not to create a new WiFi connection, until all the scripts located in ‘/lib/systemd/system-sleep‘, which run asynchronously, have exited. This means, that my WiFi also does not come back up, until this one script has finished, which will be more than 20 seconds after I Resume the laptop.

I do not believe strongly anymore, that the actual restart of the ‘nmbd‘ daemon accomplishes much.

But apparently, the simple fact that the WiFi connection waits for 20 seconds before being re-established, is what finally makes my WiFi stable – after a Resume From Standby ! :)

This observation would also seem to confirm, that the last misbehavior of this chip-set was mainly due to the fact that it physically has two antennae attached, and that it makes a selection about which one to use, when the WiFi-connection is (re-)established. Apparently, the physical WiFi connection was not yet stable, ~half a second~ after the Resume. For which reason the Kernel Module has been choosing the weaker antenna, whereas after more than 20 seconds have elapsed, the correct antenna is chosen.



RTL8723BE Again

According to This Posting, when my laptop ‘Klystron’ had an older kernel version, it was suffering from a number of WiFi problems.

These problems seemed to be related to the RTL8723BE kernel module, a Linux implementation of the device driver, for a chip-set that seemed to run fine under Windows. Linux issues with this chip-set are famous.

More recently I have read some follow-up information, that makes the problems I was experiencing more easily explained.

Apparently, the Realtek chip-set in this laptop has not one but two points, at which an antenna wire can be connected – i.e., the possibility of connecting two antennae. The device-driver is supposed to detect which antenna has the stronger signal, and is supposed to switch to whichever one that is.

Apparently, my laptop was not made so cheaply, as only to have one antenna in fact, as some models do. This is evidenced by the fact that when I was running Windows on it, I was able to close and reopen the laptop lid at any time, and not risk losing the signal.

But what can happen with earlier versions of this kernel module under Linux, is that it fails to switch to the antenna with the stronger signal in real-time, instead making a static decision to stay with one of the antenna wires, at least after a connection has been established. And this would explain why, when I closed my laptop lid before, the kernel module would choose to stay with an antenna it had chosen, and one with the now-weaker signal.

On the side, what I now find is that since I have been upgraded to kernel version ‘4.4.0-30-generic‘, the kernel module and its WiFi service seem to have become very stable, until I put the laptop into Suspend Mode. When I Resume from RAM after that, apparently the kernel module receives some amount of corruption, so that it becomes unstable again. But this is not the only problem that laptop runs in to with Suspend to RAM, as also noted Here. Further, I still have this laptop set To suspend to RAM, whenever I close its lid. So there are still no sessions on this machine, with the lid closed, with the WiFi active, and with the laptop plugged in to AC power, as some users leave theirs.

Such a test might be a good thing, to see if the WiFi signal still fades like that, with the new kernel module. That test has not happened yet.



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.