Updated: November 13, 2017
The golden rule of computing is, you should never check your system error log for errors if your system is working fine. That's the quick route to madness. You will end up trying to figure out solutions to trivial issues that do not affect your day-to-day usage. But then, you may suddenly have your desktop freeze. If you're lucky, it recovers. If not, you will have to reboot to gain back your session.
Now that you should check the logs, you discover the following error in the logs just prior to the problem: *ERROR* Atomic update failure on pipe A ... Sounds ominous, and it is the topic of our article today. Let's see what gives here and how we can fix this.
Before we can solve anything, let's understand the problem first. I have noticed this type of error in several Linux distributions, with different desktop environments and different kernel versions, including some rather recent ones. It accompanies the aforementioned freeze in the desktop activity. In some cases, the system recovers quickly. In others, a reboot is required to work around the issue. A complete error message looks something like this:
[drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe A (start=432557 end=432558) time 347 us, min 763, max 767, scanline start 753, end 770
It is related to Intel's i915 graphics driver, and it indicates there is some kind of a problem in its functionality. A generic search for the driver function intel_pipe_update_end points to an open bug with a range of recent Intel processors and their HD graphics piece. Specifically, it relates to the Panel Self-Refresh (PSR) implementation.
At this point, we should consult Intel's reference manual to understand a little more what gives. Apparently, hardware-based panel refresh supports automatic entry and exit from self-refresh. It is also an atomic operation, which means the processor will wait for it to complete until it finishes. Instinctively, we can assume there is some kind of an issue here, because if it takes to long for the screen to refresh, it may appear frozen.
Perhaps the driver misses buffers, or something else in the driver blocks the self-refresh functionality. This is not a guaranteed reason for the problem, but it a decent rule of thumb for what we are facing. And now, we can, with some confidence, attempt to apply a workaround that may help mitigate the freeze issues until a complete solution is provided with a driver update as part of normal distro update cycle. Hopefully.
As a first step, you should install Intel's proprietary firmware (Intel microcode) using your distro's package management system. Some distributions automatically offer and enable these blobs, while in others, you will have to manually download and setup the firmware.
This does not mean your problem will go away if you do apply the firmware, but you will at least make sure there's the smallest discrepancy between what Intel expects and what your distro supports. In general, this should be your starting point. If the problem does not go away, we need something slightly more rigorous.
This change can be affected as a parameter that can be passed on to the i915 driver during boot time. You can do this on the GRUB (bootloader) command line, or create a configuration file for when the driver is loaded. I think the second method is easier to implement.
Similar to what we did when we handled the network disconnects with my Realtek driver on the Lenovo G50 machine, we need a driver configuration file. Under /etc/modprobe.d/, you will need to create a configuration file i915.conf, if it does not already exist. Then, inside this file, you will need to add the following line:
options i915 enable_psr=0
The next time the driver is loaded, PSR will be disabled, and it should be a workaround for until the driver update is released. You can reload the driver into memory without a reboot by stopping the desktop session, or if you find this too complicated, just reboot. This should mitigate the freezes.
I am not aware of any side effects, but I assume that you may experience some small performance degradation, as software buffers are always slower than hardware buffers, but at least, you should enjoy an uninterrupted session. Moreover, it would appear the issue affects all distributions, kernel and desktop be as they may, so there isn't an easy way to dodge it other than the driver modprobe hack. For now.
Sometimes, in the heat of frustration and time constraints, we may be tempted to quickly lift possible solutions off the Web and implement them, hoping to alleviate whatever is making us miserable. I believe that configuration changes to the system should be applied carefully, and only with a full understanding of the effect.
In our case, it would appear the HD graphics driver may suffer from some hang under certain conditions, and this could be related to the panel self-refresh mode. You should test with Intel's firmware enable, and then use the modprobe configuration change as a workaround. Last on our todo list is to wait for the vendor to release a full, formal fix. And remember, do not be tempted to read the system logs if everything works fine. Be warned for 'tis Pandora's box. Until next time.