Debian's driver for Intel GPUs is shit

After a few years spent with Ubuntu and Linux Mint I decided to give Debian Jessie a try this week. And I have to admit that I also wanted to see systemd in action just to assess it myself and see whether it has some potential to do something good or otherwise.

But the Debian Jessie with either Cinnamon or Mate desktop was unusable on my ThinkPad X301. The graphics was sluggish. Even video playback in VLC was apparently loosing one third of frames even in lower quality movies. The mouse wheel on external USB mouse was lagging. Keyboard has visible lag behind key press and the letter being inserted to terminal/text editor/whatever. The experience was really horrible. Wtf?

Well, I suspected the Cinnamon desktop that I installed in the first place. I thought that it might eat up CPU and put too much strain on GPU. This assumption proved wrong. So the problem was apparently somwhere in XOrg. Sluggish video and lagging inputs worried me because how one problem could possibly cause that. Well, it is possible in the XOrg because one driver can slow down the whole thing and cause problems even in other subsystems.

After a few hours tuning this and that I checked the version of the Intel driver and... Well, the driver is old deprecated shit. And it is present in all current Debian versions (stable... that's a joke:-) ), testing (which is freezed so it is going to be "stable", LOL), and unstable (at least the name suggest that it does not work properly, which is completely true).

This blog post explains everything: http://blogs.fsfe.org/the_unconventional/2014/11/12/debian-x-drivers/

Just for reference: That's what I have.

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
 Subsystem: Lenovo Device 20e4
 Flags: bus master, fast devsel, latency 0, IRQ 47
 Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
 Memory at d0000000 (64-bit, prefetchable) [size=256M]
 I/O ports at 1800 [size=8]
 Expansion ROM at  [disabled]
 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
 Capabilities: [d0] Power Management version 3
 Kernel driver in use: i915

And my solution was:

echo "deb http://ftp.debian.org/debian experimental main" >> /etc/apt/sources.list
apt-get update
apt-get -t experimental install xserver-xorg-video-intel

OpenHantek udev rulez

I have a small and cheap Hantek DSO-2090 USB oscilloscope... And, well, the HW is old, cheap Chinese box that looks extremely ugly. I have not enough bravery to look inside but I do not hope for anything good. But it was cheap enough and when I was moving I really needed to get rid of my old Russian 15 kg, 0.5 cubic meter CRT oscilloscope so I decided to buy this one. It was conscious choice and it works for me pretty well since I am doing only basic electronic measurements here.

But I migrated to a newer Debian system so I had to rebuild my OpenHantek SW, which was pretty painless. Many thanks to the author of this blog post: http://verahill.blogspot.cz/2012/12/298-hantek-dso-2250-usb-with-openhantek.html

But there were still a problem with udev that failed to change group and access rights to the /dev/bus/usb/... file, so I was unable to use OpenHantek as an ordinary user. The solution is obvious, the old udev rule file used SYSFS instead of ATTR. This is my working version:

# Hantek DSO-2090
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/2090/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso2090-firmware.hex -s /usr/local/share/hantek/dso2090-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="04b5", ATTR{idProduct}=="2090", MODE="0660", GROUP="plugdev"

# Hantek DSO-2100
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="547/1006/*", RUN+="/sbin/fxload -t an21 -I /usr/local/share/hantek/dso2100-firmware.hex -s /usr/local/share/hantek/dso2100-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="0547", ATTR{idProduct}=="1002", MODE="0660", GROUP="plugdev"

# Hantek DSO-2150
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/2150/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso2150-firmware.hex -s /usr/local/share/hantek/dso2150-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="04b5", ATTR{idProduct}=="2150", MODE="0660", GROUP="plugdev"

# Hantek DSO-2250
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/2250/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso2250-firmware.hex -s /usr/local/share/hantek/dso2250-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="04b5", ATTR{idProduct}=="2250", MODE="0660", GROUP="plugdev"

# Hantek DSO-5200
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/5200/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso5200-firmware.hex -s /usr/local/share/hantek/dso5200-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="04b5", ATTR{idProduct}=="5200", MODE="0660", GROUP="plugdev"

# Hantek DSO-5200A
SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", ENV{PRODUCT}=="4b4/520A/*", RUN+="/sbin/fxload -t fx2 -I /usr/local/share/hantek/dso520a-firmware.hex -s /usr/local/share/hantek/dso520a-loader.hex -D $env{DEVNAME}"
ATTR{idVendor}=="04b5", ATTR{idProduct}=="520A", MODE="0660", GROUP="plugdev"

Assuming the path to the *.hex file generated by the openhantek-extractfw is /usr/local/share/hantek .

Smokeping slavery madness

So once again I have been hit by an insane portion of weird, flawed and inherently unreliable design in Smokeping.

What the fuck is Smokeping? Well, it is an utility for measuring and graphing latency in network. It should be pretty straight-forward to use. You configure IP addresses and names of boxes to monitor and that't it? Well, not so fast... It is a bit poxy because it is Perl after all. You need some modules, you need to have multiple configuration files, you have to configure probes, bind them to targets, modify arguments for probes in target configs etc. There is quite a lot of how-to's for this and in fact it works almost out of box on most distributions.

But... The Smokeping beast has also a slave mode. Which means: You have one master that holds configurations and it performs measurements and it generate graphs, everything is the same as in standalone mode. But it also commands slaves to perform the same measurements and report results so the master saves the results to .rrd files and it create graphs.

This communication with slaves is performed by CGI in the Smokeping webroot. And here comes the problem: Privileges.

When Smokeping runs as a daemon it is executed under smokeping user, at least on Debian. So all files that it stores (on Debian usually these files end up in /var/lib/smokeping) have smokeping:smokeping user and group and privileges 644. That works for daemon to store data and for CGIs to read them.

But if you need CGIs to store data from slaves, it is not enough. The Smokeping (daemon perhaps?) creates proper .rrd files for the remote measurements from slaves, but these files are updated, so no data in are being displayed in graphs.

Solution:

chmod -R g+w /var/lib/smokeping