October 10th, 2013
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 .
August 16th, 2013
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.
August 16th, 2013
(Executive summary: boot with
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
to the kernel.
July 1st, 2013
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#^.*/##'
Now unbind (as root):
# echo 0000:00:03.0 > /sys/bus/pci/drivers/mei_me/unbind
…and your next resume will work better.
May 31st, 2013
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.
October 23rd, 2012
Yesterday I finally figured out how to use the virtio console on KVM, which is very easy once you know what to do.
A short explanation of what a “virtio console” is:
On paravirtualized environments like Xen the VM (guest) has no direct hardware access, but also no emulated hardware but instead needs special drivers that know it is running on a hypervisor. The advantage of this approach is that you don’t need to emulate hardware and that the driver for the guest is often much simpler (it does not need to probe hardware, for example, as it talks to the hypervisor via a special interface). This makes for a very convenient default Xen setup where you can just do “xm console ” on the hypervisor and get a functional console without any fiddling.
On fully virtualized environments, usually an emulated serial port is used for that, which is harder to set up. It is not impossible, but definitely not that easy and there is quite some stuff to configure to get it working.
Nowadays even fully virtualized systems often have some paravirtualized drivers available, mostly for performance reasons. One of those paravirtualized drivers available with KVM is the virtio console driver.
So back on topic: how to set up the virtio console driver for a KVM guest
First, edit the configuration of your guest, in my case with “virsh edit factorytest” (factorytest is the name of my guest). Add the following snippet of configuration before the closing “</devices>” tag:
<target type='virtio' port='0'/>
Then a few things need to be done on the KVM guest. In my case of an openSUSE 12.2 guest, the virtio_console module was loaded automatically. However, it surely won’t hurt to put it into INITRD_MODULES in /etc/sysconfig/kernel.
The second thing is “console=hvc0″ needs to go onto the Kernel command line.
The easiest way to accomplish this is to use the YaST bootloader module and add it in the “Boot Loader Options” tab. You need to actually make sure there is “console=tty console=hvc0″ there, because without the “console=tty” the system did not boot up cleanly for me. I guess that the kernel is not happy with only a console that gets added later via a module, but I need to investigate that.
All the rest was handled by systemd and friends just fine, after rebooting the VM guest, I was immedately able to do “virsh console factorytest”, hit “Enter”, get the login prompt and log in.
September 10th, 2012
Now who would have guessed the guys that are good at trademark trolling (they withdrew their trademark application after other users of the name “Neutrino” complained, too, now they are trying to get new variations of the neutrino brand) are apparently not very good when it comes to hardware engineering?
The power supply of my coolstream neo box died of blown out capacitors after only 18 months — which tells you about the hardware quality IMHO. I own a lot of electronics but have never seen this happening after such a short time.
My advice to the coolstream guys: spend a little less effort on trademark trolling and violating the GPL, instead spend a little more effort on quality assurance. I cannot say that I’d recommend this hardware to anyone.
I could probably just replace the capacitors, but that box has been just annoying lately and I have enough other well-working boxes so I’ll probably just leave it dead so I don’t need to get upset whenever I try to use it for something serious.
May 24th, 2012
This time in english
Tomorrow I’m holding the kdump talk at LinuxTag in Berlin, and since I had submitted it in english, I had to translate my short paper anyway, so here it is. It is a rather short “beginner’s guide” but it should get you started. And it’s much better than the slides as there is almost no technical details in them due to the short timeslot (30 minutes) I got.
April 28th, 2012
While investigating inferior LIRC performance today, I checked the timings used by IRMP and found that using those instead of the “measured” ones of LIRC in the config file made LIRC perform much better. See the patch for details.
Looking at the lircd.conf more thoroughly for the first time, I finally found the similarities between the lircd remote control codes and the IRMP codes (at least for the NEC protocol used with this handset):
- IRMP “address”:
- IRMP “command”:
- lircd “pre_data”:
- lircd “code”:
The IRMP Documentation (sorry, german only) describes the NEC protocol as follows:
32 bits of data: 8 address bits + 8 inverted address bits + 8 command bits + 8 inverted command bits
The IRMP “address” is really 8 bit only:
0xBA inverted is
0x45, leading to an “effective address” of
The IRMP “command” is already 8 bit only.
Now double-check with the lirc codes: address
0xA2 inverted =
0x58 inverted =
0xA7, so the scheme seems to apply to both.
Using only the relevant 8 bits:
- IRMP address:
- IRMP command:
- lircd address:
- lircd command:
Looking closely, I found that the difference is actually the LSB / MSB order: IRMP is shifting the bits in reverse order compared to lircd.
So if needed, it should now be pretty easy to extract codes for IRMP from lircd.conf files using a simple perl script or the other way round, at least for NEC codes. Lircd has the advantage that you can easily “learn” your new remote control handset with an interactive program (if you disregard the suboptimal timing data it creates).
March 18th, 2012
(German only, the paper is also only available in german right now).
Zur Zeit halte ich Vorträge über kdump, unter anderem auf dem GUUG Frühjahrsfachgespräch 2012 und den Chemnitzer Linuxtagen 2012.
Da die Dauer der Vorträge meist auf ca. 45 Minuten begrenzt ist, enthalten die Vortragsfolien nur wenig technische Details. Für den Tagungsband des FFG 2012 habe ich jedoch einen Artikel geschrieben, der als Einstieg in das Thema besser geeignet ist. Diesen Artikel gibt es hier.