I upgraded to kernel 4.9. It apparently fixed the Wi-Fi issues. I still have occasional display glitches, but they also go away while on battery power.

Kernel upgrade

I upgraded to kernel 4.9+ (i.e. Linus Torvald’s master branch as of today). While I ranted two days ago about some changes in how you install software, no such thing with kernel builds.

The same old habits I had almost ten years ago still appear valid today. It’s like returning to a place you visited a long time ago. Some buildings have changed, but the overall feel of the place is the same. The only thing I had some trouble with is remembering the name of the target for module installation. I tried make module-install, then  make modules-install, then scratched my head for a while, Googled for it. It’s make modules_install. Well, for some reason, this is a mistake I kept making years ago, still can’t remember the name of that target today ;-).

I wonder why this is not a dependency of make install. Anyone knows?

Wi-Fi problem apparently fixed

I can’t reproduce the Wi-Fi issue anymore. I still have the same message in dmesg about “brcmf_cfg80211_reg_notifier: not a ISO3166 code“. But the driver crash itself is apparently gone.

Display glitches still there, but not if on battery

There are still occasional display glitches, but they go away without even rebooting if I’m on battery power. As soon as I connect the charger, they reappear.

This seems to be a known problem with Retina displays that have dual discrete/integrated GPUs with GPU switching. Several readers pointed out previously this article which states:

While GPU switching on pre-Retinas works, it doesn’t yet on Retinas. Once again there is no valid panel resolution stored in the video BIOS, so both GPUs need to probe it. However unlike on pre-Retinas, the AUX channel (which is the DDC equivalent for DisplayPort) is not switchable between GPUs without also switching over the main link. The active GPU therefore has to either cache the panel data or proxy the inactive GPU’s access to the panel. Additionally, both GPUs need to link-train their eDP outputs: the DisplayPort specification has a special provision for closed, embedded connections which allows outputs to be set up with a pre-calibrated, known-good drive current and pre-emphasis level. A solution would thus be to have the inactive GPU set up its output with pre-calibrated values determined by the active GPU.

So for now, I’ll assume this is the problem. If the fix is something as simple as running on battery power, I can certainly live with that for a short while. I’ll check if there is a better fix and update this post if I find it. I’ve tried gpu-switch, but it does not help.

When the problem occurs, it looks like this:

If this looks familiar to you, please leave a comment.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s