Never Ending Baustelle

I think it was some component of KDE 4.1.x, which required a libX11 with enabled xcb use flag in Gentoo Linux. So I recompiled the library with the correct use flag. However, this in turn cause problems with Java (1.4 versions I think). I noticed it the first time, when I installed the latest Jalbum 8.1* version. When the Jalbum installer is started, it aborts with an assertion:

java: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

This was on my Linux box at home. After some googleing I fixed it by updating some library and completely forgot about it.

Now, at work I wanted to install the new DB2 Express C 9.5.2beta and came across the exact same problem, now with a IBM Java version, which is included in the DB2 installation package (J2RE 5.0 IBM J9 2.3). One fix, that can be found on the Net is the following:

sed -i 's/XINERAMA/FAKEEXTN/g' */jre/bin/xawt/libmawt.so

In case for my DB2 installation, this is somewhat messy, since it would require the unpacking and repackaging of the DB2 Java archive.

The fix, that I used for my original Jalbum installation problem and which is the best solution IMHO, at least for Gentoo people, is to replace the libxcb with a newer version, which contains a workaround for the xcb_xlib_unlock assertion. This means, that first of all x11-libs/libxcb and x11-proto/xcb-proto need to be included in the /etc/portage/keywords file. Then I installed these packages:

# equery l xcb
[ Searching for package 'xcb' in all categories among: ]
* installed packages
[I--] [ ~] x11-libs/libxcb-1.1.90.1 (0)
[I--] [  ] x11-libs/xcb-util-0.2 (0)
[I--] [ ~] x11-proto/xcb-proto-1.2 (0)

You can check with this command line, if you have a libxcb with the appropiate workaround.

# strings /usr/lib/libxcb.so|grep XCB
LIBXCB_ALLOW_SLOPPY_LOCK

Now you can set the LIBXCB_ALLOW_SLOPPY_LOCK environment variable appropriately.

export LIBXCB_ALLOW_SLOPPY_LOCK=1

Now, the 1.4 Java should successfully run. You will still get an error message, but the program won’t abort. This assertion problem should be fixed at least in the current 1.6 Java versions.

In my company at the end of the day I’m putting my PC into S3 sleep state and wake it up next morning. In the past I had been using the /proc/acpci/alarm ACPI device to setup the alarm clock, so that the PC would already be ready when I return to my desk. Sometime in the past with I don’t know which new kernel version I lost the ability to use the alarm function (or due to some reconfiguration in the kernels ACPI parameters). So I manually switched the PC on (what else?).

Apparently I didn’t look hard enough for a solution, then I would have found the below earlier. I found the solution in the KnoppMyth vincinity.

Check if you have a directory rtc0 in the /sys hierachy.

ls /sys/class/rtc/rtc0/

If you don’t have this directory you might need to check, if the appropriate rtc-module is loaded. For me it is rtc-cmos. See to it, that it is correctly loaded during boot.

Apart from other files, there should be a file named wakealarm. Write 0 to file to disable the wakeup function, otherwise write the seconds since the epoch (seconds since Jan 1st 1970) to the file.

disabling
# echo 0 > /sys/class/rtc/rtc0/wakealarm 
wakeup after 5 minutes
# echo $(date '+%s' -d '+ 5 minutes') > \ 
    /sys/class/rtc/rtc0/wakealarm
or wakup tomorrow at 7:15
# echo $(date '+%s' -d 'tomorrow 7:15') > \ 
    /sys/class/rtc/rtc0/wakealarm
# cat /sys/class/rtc/rtc0/wakealarm

You might want to check the output of the file /proc/driver/rtc:

# cat /proc/driver/rtc
rtc_time        : 15:09:52
rtc_date        : 2009-01-07
alrm_time       : 07:15:00
alrm_date       : 2009-01-08
alarm_IRQ       : yes
alrm_pending    : no
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay

What I noticed however, when I write multiple times to wakealarm I’m getting an error message.

# echo 0 > /sys/class/rtc/rtc0/wakealarm
# echo $(date -u '+%s' -d 'tomorrow 7:15') > /sys/class/rtc/rtc/wakealarm
# echo $(date -u '+%s' -d 'tomorrow 7:15') > /sys/class/rtc/rtc/wakealarm
echo: write error: Device or resource busy

This error is cleared by another echo 0 > ....

Der Winter hat uns. Und das, wo es ab morgen wieder zur Arbeit gehen muss.