Debian Testing/Unstable: FGLRX Just Broke!

I know. Annoying, isn't it?

The X server has just been upgraded to 1.12 in wheezy and sid. Unfortunately, this version uses a new interface which is incompatible with fglrx at present. In other words, you can't install fglrx in wheezy or sid without downgrading (and, I would suggest, pinning) the xserver version.

The next proprietary fglrx driver version, 12.5, is supposed to support the new X.

Meanwhile, over in the land of stable, Squeeze is fine; that's still on 1.7.

Update 4 Jun 2012: AMD announced they're changing their driver release schedule, so they have fewer releases: hence a 12.5 version is no longer on the cards. Thanks AMD. I just tried the 12.6 beta driver (curiously labelled as 8.98), and xserver 1.12 is still broken. However, there are people claiming that it works on 32-bit Debian and all architectures of ArchLinux.

Update 5 Jun 2012: I've just tested Fedora 17 with Xorg server 1.12, and here the Catalyst 12.6 beta driver is working fine.


$ yum info xorg-x11-server-Xorg | grep Version
Version     : 1.12.0


There's only one catch; the *@$%@rds wise overlords at AMD decided it would be a spiffing jibe to take the only working driver and plaster a bold "AMD Testing use only" watermark over the bottom right hand corner of every display.

Thankfully, there's a simple script to hack the fglrx module binary and remove the EnableLogo calls. It just warrants an elementary tweak to correct the module location for Fedora 17, and also to backup the original binary first. The resulting shell script, to be saved, exec perm'd, and run as root, is:


#!/bin/sh
DRIVER=/usr/lib64/xorg/modules/drivers/fglrx_drv.so
cp $DRIVER ${DRIVER}.original
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'); do
sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done

If you'd like to get a feel for what that does, run the following:

$ objdump -d /usr/lib64/xorg/modules/drivers/fglrx_drv.so | grep EnableLogo

The callp lines shown there invoke AMD's wonderful EnableLogo function. To get around this, the awk code in the script is getting those callp lines, and returning the hex for those calls. sed is replacing it with  a series of 0x90 commands - i.e. NOPs.

Quite a neat solution to a messy problem, eh? Thanks go to Kano (post 2).

Update 30 Jun 2012: A kernel update broke my 12.6 beta, forcing me to revert to the OS driver. I tried installing the 12.6 final release from AMD, which claims to support 3.4 kernels. However, building the kernel module failed with "'cpu_possible_map' undeclared" - an error which apparently stems from the 12.4 release. Applying this patch seemed to do the trick.

0. Install 12.6
1. Apply the changes to /usr/lib/modules/fglrx/build_mod/*
2. Run /lib/modules/fglrx/build_mod/make.sh as root
3. Run /lib/modules/fglrx/make_install.sh as root
4. Reboot

Raspberry Pi: Basic Configuration

So now I'm settling in with my Pi, there were a few things that needed sorting. Of course, all the usual goes without saying:

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install vim

Create a user for yourself.

$ sudo adduser <username>

You'll want to be able to run sudo:

$ sudo EDITOR=/usr/bin/vim visudo

Add a new line for your new user beneath the pi user's line, e.g.

ace ALL=(ALL) ALL

Login as yourself:

$ su - <username>

Time to change the root password. Don't forget it.

$ sudo passwd

You can either delete the user 'pi' or change its password - your call.

Now to deal with the resolution. The wiki has a good page explaining how to set the resolution of your Pi. In short, for those using HDMI output:

$ /opt/vc/bin/tvservice -m DMT

Find the correct resolution and refresh rate for your monitor and note the mode number. Then edit (if it doesn't exist, then create) the file /boot/config.txt and set the variables hdmi_group and hdmi_mode as appropriate.

What it didn't make quite as clear is how to deal with the big black borders which are liable to malign your display and compress your image to the wrong resolution. We are of course discussing overscan.

For some reason unknown to me, the default is to set an overscan of 48 on top, right, bottom and left. On my AOC 416V (an atrocious monitor I had lying around), I found all it took to correct the resolution & black borders was to set the hdmi_group to 2 (DMT), hdmi_mode to 68 (1920x1200 @ 60Hz) and -48 overscan on all sides - to undo the default 48 overscan. It all looks something like this: (if you haven't installed vim yet, replace vim with vi)

$ sudo vim /boot/config.txt
hdmi_group 2
hdmi_mode 68
overscan_top -48
overscan_left -48
overscan_bottom -48
overscan_right -48

If your Pi refuses to show a display with your custom settings, you'll have to remove the SD card, put it back in another PC, mount the /boot partition (the smallest one), and edit config.txt again.

Of course, the usual applies - whatever you try on your Pi is at your own risk.

An interesting feature of the Pi is that it doesn't have a battery; in other words, it can't know what time it is after it's powered on. Somebody has written a script at /etc/profile.d/set_recent_time.sh which sets the time at logon, based on the last updated logfile's modification time. There's no denying that it's crude. I'd advise making sure that NTP is configured and working, otherwise you'll constantly be typing date --set='2012-05-27 ....'

Raspberry Pi: Getting Started & First Impressions

One would only have to remove the unnecessary RCA and 3.5 jacks, the positively extravagant dual USB "tower", the ethernet port of yesteryear, and snip the tops off the JTAG headers. Then this little beauty could slip snugly into a wallet, alongside Visa, Mastercard and that well-intentioned gym membership card.

Yes folks, this past week the Raspberry Pi has been rolling off production lines and into expectant sweaty paws around the country. I was fortunate to receive mine a couple of days ago, and today has been my first opportunity to try it out for size.

First impressions: it's small. Really small. I've never before owned a computer which I risk misplacing beneath my TODO list.

Next up, it boots (unlike my main rig, which has its own troubles at present). No problems there, it took a mere minute before I was sitting in front of an LXDE desktop under Debian.

Third, it's nippier than I expected. For a CPU which is said to compare to a 300MHz PII, this handles the rigours of a modern linux desktop quite nicely. Opening the PCManFM file manager takes but a second. Opening the Midori web browser takes a few more. Browsing to a simple webpage spikes the CPU only momentarily.

It's not all good news; a complex webpage maxes the ARM chip for some seconds. The GUI isn't awfully responsive in general. And, one all is said and done, 186MB of accessible RAM is rather limited. This is no cheetah, and struggles even with this basic LXDE desktop environment. However, it is just sufficient to run it bearably - and that's the point.

For those of you firing up your Pis over the coming days and weeks, here's a very brief "getting started" guide - although all the information you need, and much more, is available on the excellent Raspberry Pi wiki (and do take note of the encouragement for contributions).

You'll require:

• a SD card, 2GB or more. Preferably a more expensive card with better read/write performance. In general terms, they're divided into classes, with class 10 being the fastest. Check to see if it's supported before buying.
• a means of connecting it to another computer (such as a USB SD card adapter, which you can pick up very cheaply - around 2 GBP). I used an Integral SDHC USB2 SD card adapter.
• another computer
• a power adapter (make sure it's 5V, and around 1A). Many phone chargers fit the bill perfectly. I had a spare HTC charger lying around that works just fine. 
• a USB keyboard. If you plan to use the GUI, a USB mouse too. Getting a combination wireless USB keyboard and mouse is a good idea, since then you only need to use the one wireless dongle.
• a means of connecting it to your display. This will probably be either a HDMI cable, or a HDMI -> DVI-D adapter cable. Alternatively, you can use an RCA cable, or work out an alternate solution, such as with a HDMI -> DP adapter. 

Then there are the optional components, depending on how you plan to use it. An ethernet cable; a wireless USB dongle (again, check for compatibility on the wiki), a 3.5" audio cable, a USB flash drive for more storage, a powered USB hub to increase the number of USB ports or in case some devices need more power, etc. For the record, a powered USB hub strikes me as a good idea in this case.

To get up and running, you first download one of the Linux distro images (I also recommend starting with Debian). The following instructions assume you're working on Linux:

$ wget http://downloads.raspberrypi.org/images/debian/6/debian6-19-04-2012/debian6-19-04-2012.zip

$ sha1sum debian6-19-04-2012.zip | grep 1852df83a11ee7083ca0e5f3fb41f93ecc59b1c8 && echo "Success" || echo "File is corrupted. You need to download it again"

$ unzip debian6-19-04-2012.zip

$ cd debian6-19-04-2012

Now connect your SD card and verify that it's visible to the computer. There are detailed instructions for this on the wiki. You can use df, mount, lsusb, or a plethora of other methods to find out what the mountpoint of the device is. Once you know this, unmount the device (if it auto-mounted) and copy across the image file:

# dd if=debian6-19-04-2012.img of=/dev/pathToTheDevice bs=1M

Note that if you're performing this step under FreeBSD, replace the sha1sum command with sha1, and use # camcontrol devlist to find out the mountpoint of the SD card.

This gives you your bootable SD card. All that remains is to insert it into the Pi, connect your display cable, your keyboard & mouse, and network if you desire, and finally connect your power adapter cable. Your Pi will start booting automatically.

For those interested, the package you'll receive is rather basic compared to what you might get with a typical off-the-shelf computer. It consists of a small cardboard box with some labels plastered over it, inside of which is an anti-static bag containing the Pi itself. 

It may not be much. But, quite frankly, what more does one need?

Xen: Failed while collecting E820 with: -3 (errno:0)

# xl create /etc/xen/ace2x1
Parsing config file /etc/xen/ace2x1

libxl: error: libxl_create.c:700:do_domain_create: Failed while collecting E820 with: -3 (errno:0)
: Success

I had to add some extra logging into libxl_pci.c to work this one out. It turns out it was choking in e820_sanitize on this test:


    if (!src || !map_limitkb || !balloon_kb || !nr_entries)
        return ERROR_INVAL;

As you can see, if balloon_kb is 0 (which comes from libxl_domain_config), it will fail. That's what was happening in my case.

libxl: error: libxl_pci.c:1182:e820_sanitize: ============== delta_kb: 0 start: 0 start_kb: 0 last: 0 map_limitkb: 200000 balloon_kb: 0 nr_entries: 18 

Hence, this issue can be worked around quite easily by adding a maxmem assignment to the guest config.

memory = '2047'

maxmem = '2048'

The kernel source for this kernel does not seem to be installed

Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.

I regularly reinstall my graphics drivers, but can never seem to remember where the link to the kernel source/headers should be for DKMS to find it automatically. Here it is for reference, assuming your kernel source/headers are placed at /usr/src/linux-<kernelversion>:

# unlink /lib/modules/$(uname -r)/build

# ln -s /usr/src/linux-$(uname -r) /lib/modules/$(uname -r)/build

Synergy 1.3.8 crashes with Shift & other modifier keys

Synergy is one of those reliable applications which rarely goes wrong. However, following an upgrade either to the client or server, my Ubuntu synergy client crashed every time I used a modifier key such as Shift. Oddly enough, I have two synergy clients (one Debian, one Ubuntu), both using the same version (1.3.8), yet only the Ubuntu client suffered from this problem.

This problem is not uncommon, and the accepted solution is to upgrade to the latest beta version of synergy on both the server and the affected client.

Upgrading Ubuntu to 1.4.8 beta was predictably easy; download the .deb and install using your method of choice; either double-click or use dpkg.

Upgrading the synergy server was more complex, since that runs on my FreeBSD box. I originally installed it via the ports collection.

The process I followed was:

$ wget http://synergy.googlecode.com/files/synergy-1.4.8-Source.tar.gz
$ tar xf synergy-1.4.8-Source.tar.gz
$ cd synergy-1.4.8-Source
$ chmod +x configure
$ ./configure

Then I hit an error about a missing XKBlib.h. That clearly wasn't the case, the configure script was just looking in the wrong place:


$ find /usr/ -name XKBlib.h 2>/dev/null
/usr/local/include/X11/XKBlib.h

After messing around with CMakeLists.txt for some time without success, I found a helpful comment on an issue tracker which provided the less-than-obvious workaround:

$ rm -f CMakeCache.txt

$ cmake \

-DCMAKE_INSTALL_PREFIX:PATH=/usr/local \

-DCMAKE_C_FLAGS="${CFLAGS} -I/usr/local/include -L/usr/local/lib" \

-DCMAKE_CXX_FLAGS="${CXXFLAGS} -I/usr/local/include -L/usr/local/lib" \

-G "Unix Makefiles"

After that, I could proceed:

$ ./configure

$ make

$ cd bin

# cp synergys /usr/local/bin/synergys-1.4.8b

# mv /usr/local/bin/synergys /usr/local/bin/synergys-1.3.8

# ln -s /usr/local/bin/synergys-1.4.8b /usr/local/bin/synergys

# pkill synergys

# synergys -c /etc/synergy.conf