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.
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.