"rdmsr" implemented in perl

Today I needed the "rdmsr" tool to determine if machines are configured correctly for Hypervisor usage (VT-X enabled). Just after learning how to detect this (by looking at the cpu-checker ubuntu package), I found out that msr-tools is not available on SLES11. Instead of building the package, I just implemented a minimal version in perl (it will be integrated into a perl tool checking other aspects of the system anyway):

#!/usr/bin/perl
# License: WTFPLv2
# minimal "rdmsr" implementation
$msr = shift
        or die "need msr as parameter";
$msr = hex($msr) if ($msr =~ m/^0x/i);
open(FD, "/dev/cpu/0/msr")
        or die "open /dev/cpu/0/msr: $!";
sysseek(FD, $msr, SEEK_SET)
        or die "sysseek: $!";
sysread(FD, $reg, 8 ) == 8
        or die "sysread: $!";
$reg = reverse($reg);
$hex = unpack('H*', $reg);
$hex =~s/^0*//;
print "$hex\n";

Yes, i know, my perl is horrible :-) but maybe this is useful for someone else anyway.

Raspberry Pi: Another platform for Neutrino-MP

Last night I got video decoding via libilcore working on Raspberry Pi, so now the port of Neutrino-MP is starting to look like it will get usable some time in the future.

Most stuff is encapsulated inside libstb-hal, which means that only a small change in Neutrino-MP (just adding the proper LDFLAGS) was necessary. Later, with proper implementation / packaging of libstb-hal, this might also be unnecessary.

For those who dare to try it, I'd suggest to start with current raspbian, then use the Makefile for native building (after tweaking it to your needs) to build it directly on the Raspi -- this is how I did it :-) ). The stuff is not yet ready for cross compilation (too many hard-coded /opt/vc/lib etc).
You'll first need to build libdvbsi++ -- there's a target in the Makefile for that -- and install all missing devel packages -- hopefully, configure will compain. Otherwise the missing includes will be obvious, I guess.

The next step will be implementation of the audio decoder, which should be not too hard, then the thing will be truly useful :-) .

openSUSE Kernel debuginfo weirdness

Just because I fell into the same trap twice, once when trying kdump a year ago, now when working on systemtap, a short reminder for everyone:

If you want to do something that needs kernel-default-debuginfo installed (like, say, "kdump"/"crash" or "systemtap"), then make sure that you also have kernel-default-devel-debuginfo on your system.

The reason for this is, that the kernel-default-debuginfo package has only the debuginfo for the kernel modules, but it misses the debuginfo for /boot/vmlinux. This debuginfo is in kernel-default-devel-debuginfo package.

This is at least strange, since the vmlinux binary is not in the devel package but in the main kernel package.
But in practice it does not matter if this is a bug or not: you need both debuginfo packages installed to make kdump analysis with "crash" or systemtap work.

ExpressCard hotplug with kernel 3.11

(Executive summary: boot with acpiphp.disable=1)

Kernel 3.11rc has fixed the mei driver suspend problem for me. It brought another quirk, however. ExpressCard hotplug does not work anymore with my trusty old Thinkpad X200s. I need this to use my USB3 card. With 3.11 it only works if it is already plugged in during boot.
To be honest, this has never been 100% automatic before: I always needed to manually load the "pciehp" module to get the slot to work. The other possible driver, "acpiphp" refused to load.
With 3.11, both the acpiphp and the pciehp drivers can no longer be built as modules but are both built in statically.
In addition, now the acpiphp driver claims to support my slot, which it in fact does not, but it still claims the slot and prevents the pciehp driver (which is initialized later) from working. The kernel hackers are working to fix up this mess, but it is probably not going to "just" work in 3.11, so for now the way to get the ExpressCard slot working on a Thinkpad X200s is to pass the boot option

acpiphp.disable=1

to the kernel.

"mei" driver suspend regression in linux-3.10

For all those running kernels from Kernel:HEAD, where 3.10-final has arrived today, be warned that a suspend / resume regression crept in (I spotted and reported that after -rc4 or such, but it has not been fixed).
This regression makes my Thinkpad X200s not resume from suspend to RAM (I have not tried suspend to disk, but it might be affected, too), the machine just freezes hard on resume.
Fortunately, it is relatively easy to work around.
The affected driver is the "mei_me" driver for Intel's Management Engine, which AFAICT allows you to use management functions of the chipset like serial-over lan and similar. I don't need this, but I need a suspend to RAM that works :-)

The work around is to simply unbind the driver after boot, then the machine will suspend and resume fine (blacklisting the module does not work since the driver is built in in the openSUSE kernel).

Find out, which device is bound to the driver:

# find /sys/bus/pci/drivers/mei_me/ -type l|sed 's#^.*/##'
0000:00:03.0

Now unbind (as root):

# echo 0000:00:03.0 > /sys/bus/pci/drivers/mei_me/unbind

...and your next resume will work better.

The systemd journal is a broken piece of crap.

Why, you ask? Well, it is a write-only database, which means there is no tool to actually read or fix a journal files, should they become corrupt. Or even notice the corruption. And they become corrupt all the time.

So I don't care for the theoretical benefit of binary blob logs, as long as they don't work at all. It's as easy as that.

See https://bugzilla.novell.com/817778 for all the gory details.

To add insult to the injury, they are also written in a way that tends to fragment the logfiles very badly and thus the performance reading them (for the unlikely case that they are readable) is abysmal. Maybe it is usable with the latest and greatest SSD but with plain old rotating rust harddrives, it's a PITA.