For anyone that cares: I just replaced my GPG (Gnu Privacy Guard)
key that I use for signing my emails and Debian uploads.

My previous key was already 9 years old and used a 1024-bit DSA key.
That seemed like a good idea at the time, but for some time these small
keys and signatures using SHA-1 have been considered weak and their use
is discouraged. By the end of this year, Debian will be actively
removing the weak keys from their keyring, so about time I got a
stronger key as well (not sure why I didn't act on this before, perhaps
it got lost on a TODO list somewhere).

In my work as a DebianMaintainer for the OpenTTD and related
packages, I occasionally come across platform-specific problems.
That is, compiling and running OpenTTD works fine on my own x86 and
amd64 systems, but when I my packages to Debian, it turns out there is
some problem that only occurs on more obscure platforms like MIPS, S390
or GNU Hurd.

This morning, I saw that my new grfcodec package is not working on
a bunch of architectures (it seems all of the failing architectures are
big endian). To find out what's wrong, I'll need to have a machine
running one of those architectures so I can debug.

In the past, I've requested access to Debian's "porter" machines, which
are intended for these kinds of things. But that's always a hassle,
which requires other people's time to set up, so I'm using QEMU to set
up a virtual machine running the MIPS architecture now.

Note that in Aurélien's tutorial, he used a "qemu" flavoured
installer. It seems this is not longer available in Squeeze, just a few
others (malta, r4k-ip22, r5k-ip32, sb1-bcm91250a). I just picked
the first one and apparently that one works on QEMU.

As Aurélien also noted, you can ignore the error about a missing
boot loader, since QEMU will be directly loading the kernel anyway.

After installation is completed and the virtual system is rebooting,
terminate QEMU:

$ killall qemu-system-mips

(I haven't found another way of terminating a -nographic QEMU...)

Booting the system

Booting the system is very similar to booting the installer, but we
leave out the initrd and point the kernel to the real root filesystem
instead.

Note that this boots using the installer kernel. If you later upgrade
the kernel inside the system, you'll need to copy the kernel out from
/boot in the virtual system into the host system and use that to boot.
QEMU will not look inside the virtual disk for a kernel to boot
automagically.

To be able to debug a bug in OpenTTD that only occured on
SPARC machines, I needed an old SPARC machine so I could reproduce
and hopefully fix the bug. After some inquiring at our local
hackerspace, Bitlair (which had a few SPARC32 machines lying around,
but I needed SPARC64), I got in touch with The_Niz from
NURDSpace, the hackerspace in Wageningen. Surprisingly, it turned out
I actually knew The_Niz already through work :-)

In any case, The_Niz was kind enough to lend me a SPARC Ultra1
workstation and Sun keyboard, and r3boot gave me a Sun monitor
I could use (of course Sun hardware doesn't use a regular VGA
connector...).

There was one caveat, though: The NVRAM battery in the Ultra1 was dead.
The NVRAM chip stores the boot settings (like the BIOS settings in a
regular PC), but also the serial number and MAC address of the machine
(called the IDPROM info). Without those settings, you'll have to
manually select the boot device on every boot (by typing commands at a
prompt) and netbooting does not work, for lack of a MAC address (I
presume regular networking, e.g., from within Linux, does not work
either, but I haven't tested that yet).

Sun has taken an interesting approach to their NVRAM chip. Where most
machines just use a piece of EEPROM (Flash) memory, which does not need
power to remember its contents, Sun has used a piece of RAM memory
(which needs power to remember its contents) combined with a small
rechargeable battery.

This means that when the machine is not used for a
long time or is very old, the battery will eventually die, causing the
machine to spit out messages like "The IDPROM contents are
invalid and "Internal loopback test -- Did not receive expected
loopback packet".

I needed to install Debian on this Ultra1, so I needed some way to boot
the installer. Since netbooting did not work, my first attempt was to
ignore the NVRAM problem and just get the machine to boot off a Debian
boot cd. This did not quite work out: the cdrom player in the Ultra1 (a
4x burner connected through SCSI) didn't like any of the CD-Rs and
CD-RWs I threw at it. It spat out errors like "Illegal Instruction",
"Program Terminated" or "SProgram Terminated" (where the first "S" is
the start of "SILO", the SPARC bootloader).

As we all remember from a long time ago, the early generation CD-ROM
players were quite picky with burnt CDs, so also this one. I found some
advice online to burn my CDs at a lower speed (apparently the drive was
rumoured to break on discs burned at 4x or higher), but my drive or
CD-Rs didn't support writing slower than 8x... I could write my CD-RW
at 4x and at one occasion I managed to boot the installer from a CD-RW
and succesfully (but very, very slowly) scan the CD-RW contents, but
then it broke with read errors when trying to actually load files from
the CD-RW.

So, having no usable CD-ROM drive to boot from, I really had to get
netboot going. Apparently it is possible (and even easy and not so
expensive) to replace the NVRAM chip, but I didn't feel like waiting for
one to be shipped. There is a FAQ available online with extensive
documentation about the NVRAM chip and instructions on how to reprogram
the IDPROM part with valid contents.

So, I reckoned that the battery was only needed when the machine was
powered down, so I should be able to reprogram the IDPROM info and then
just not poweroff the system, right?

Turns out that works perfectly. I reprogrammed the IDPROM using the MAC
address I read off the sticker on the NVRAM chip and made up a dummy
serial number. For some reason, the mkpl command did not work, I had
to use the more verbose mkp command. Afterwards, I gave the reset
command and the "Internal loopback test" error was gone and the machine
started netbooting, using RARP and TFTP.

By now, I've managed to install Debian, get Xorg working and reproduce
the bug in OpenTTD, so time for fixing it :-D

Recently, I was having some problems with the internal speakers on my
Lenovo Thinkpad X201. Three times now, the internal speakers just
stopped producing sound. The headphone jack worked, it's just the
speakers which were silent. Nothing helped: fiddling with volume
controls, reloading alsa modules, rebooting my laptop, nothing fixed the
sound...

When trying to see if the speakers weren't physically broken, I
discovered that booting into Windows actually fixed the problem and
restored the sound from the speakers. It's of course a bit of a defeat
to accept Windows a fix for my problem, but I was busy with other
things, so it sufficed for a while.

When migrating my laptop to my new Intel SSD, I broke my Windows
installation, so when the problem occured again, I had no choice but to
actualy investigate it.

I'll skip right to the conclusion here: I had broken my sound by
pressing the mute button on my keyboard... Now, before you think I'm
stupid, I had of course checked my volume controls and the device really
was unmuted! But it turns out the mute button in Thinkpads combined with
Linux is a bit weird...

This is how you would expect a mute button to be implemented: You press
the mute button, it sends a keypress to the operating system, which then
tells the audio driver to mute.

This is how it works on my Thinkpad: You press the mute button, causing
the EC (embedded controller) in the thinkpad to directly mute the
speakers. This is not visible from the normal volume
controls in the software, since it happens on a very low level (though
the thinkpad_acpi kernel module can be used to expose this special
mute state through a /proc interface and special audio device).

In addition to muting the speakers, it also sends a MUTE acpi keypress
to the operating system. This keypress then causes the audio driver to
mute the audio stream (actually, it's pulseaudio that does that).

Now, here's the fun part: If you now unmute the audio stream through the
software volume controls, everything looks like it should work, but the
hardware is still muted! It never occured to me to press the mute button
again, since the volume wasn't muted (or at least didn't look like
it).

I originally thought that the mute button handling was even more
complex, when I found some register polling code that faked
keypresses, but it seems that's only for older Thinkpads (phew!).

In any case, the bottom line is: If you have a Thinkpad whose speakers
suddely stop working, try pressing the mute button!