After finding the PaPiRus ePaper panel, I picked up a Raspberry Pi Zero W to drive it. To be perfectly honest, the early Raspberry Pis never really excited me. However, the Raspberry Pi Zero’s small footprint caught my attention. Add in WiFi and Bluetooth, as found on the Zero W, and you have a solid IoT starter board.
Thanks to the popularity of the Raspberry Pi, both Funtoo and Gentoo have guides on setting up Funtoo/Gentoo on a Raspberry Pi. Getting a base system up and running is straightforward. Though, if you have to compile anything it will take a while.
Tired of waiting for a 3D XPoint based SSD to become available, I decided to grab a 512GB Intel SSD 600p for my XPS 15 9550. The intent was to switch over from Windows 10 to Linux on the 9550 while preserving the original SSD should I want to go back.
The actual SSD swap was not too difficult. A Torx T5 and small Phillips screwdriver are needed to remove the back of the 9550 and the m.2 SSD. This being my first NVMe system, I ran into a few gotchas while getting Linux installed. Though, the bulk of the issues are related to Broadcom’s poor Linux support. Continue reading
If you’re having issues getting your Bluetooth device to automatically reconnect between KDE sessions (or rebooting your computer), try opening a terminal (e.g. Konsole) and clear the contents of your /var/lib/bluetooth directory. After doing this you will need to restart the bluetooth daemon. For reference, in a Gentoo/Funtoo system,the following will accomplish this:
Note that the above needs to be run as root (or use sudo). After removing the contents of your /var/lib/bluetooth directory, you will need re-pair your device in the Bluetooth manager. When paring your device, make sure it is set a trusted device.
Now, KDE should automatically reconnect the Bluetooth device after rebooting your computer. Note that the device may not reconnect until after you have logged in. To reconnect sooner, try using a command line Bluetooth device manager.
After acquiring a Broadwell generation Core i3 NUC (the NUC5i3RYK to be exact) and installing Linux, KDE/X.Org would lockup and crash frequently. Checking dmesg, the following messages appeared:
[drm] stuck on render ring
[drm] GPU HANG:…
From the dmesg report, it is clear the crashes were caused by the GPU hanging. After further inspection of the dmesg logs, it appears this is due to a bug between Intel’s graphics and IOMMU drivers. The easiest way to work around this is to disable Intel IOMMU support.
Since I had compiled IOMMU support into my kernel, removing IOMMU support involved a kernel recompile. When configuring your kernel using menuconfig, make sure that “Support for Intel IOMMU using DMA Remapping Devices” under “Device Drivers > IOMMU Hardware Support” is unchecked. This is equivalent to ensuring that INTEL_MMU = n in your .config file. For the NUC, that was all that was required to keep the GPU driver from crashing and taking X.Org and KDE down with it.