I’m still having massive disk latency issues with Linux. They started after I build myself a Core 2 Duo system and switched to 64bit Linux. I wrote about it here, here and here. This workaround appeared to fix the problem first, but after some time and filling up the disk space the latency problems were back on my XFS file systems.
This whole time I’m mostly succeeding in working around the problem by either delaying the job until the time when I’m not recording some music or video or using the much smaller root-partition as scratch space DVD creation. The programs, which pretty reliable trigger the problem are avidemux2 and dviauthor. I’m using avidemux2 to remove any advertisement from a recorded MPEG2 stream. Once I write the output file beside the original file on the same file system the problem is usually triggered. When I’m writing to /tmp on the much smaller root-partition I get by without triggering the latency problem. The same is true, when dviauthor prepares the DVD file structure. When the DVD structure is prepared on the same file system as the originating file, the problem is triggered and not, when written to /tmp.
During the development cycle of kernel 2.6.30 there was much discussion on the net about fixes of latency problems, however primarily in connection to EXT3 and EXT4 file systems. Still I was hoping, that some fix in 2.6.30 would have improved the latency problem for me and my XFS file systems as well.
It appears however, that it is not the case. avidemux2 and dviauthor still trigger the problem. People on the Gentoo forums seem to agree, that the situation might have improved, but isn’t fixed yet. I need to convince myself to backup the data on my multimedia partition and change the file system to EXT4 to see, if it might change the behaviour. This is really a problem, which decreases my trust in Linux.
I didn’t do any digital photo work for some time with Bibble Pro, however recently I wanted to do something and was greeted with a “Segmentation Fault”. Bibble is a 32bit application, that I’m running on 64bit Gentoo Linux. This is what I got:
$ LD_LIBRARY_PATH=/usr/lib/bibblelabs/bibblepro/libs bibblepro
bibblepro: /usr/lib32/libstdc++.so.5: no version information available (required by bibblepro)
bibblepro: /usr/lib32/libstdc++.so.5: no version information available (required by bibblepro)
AppPath: /usr/bin
SysHome: /usr/lib/bibblelabs/bibblepro/
Userhome set to /root/.bibble
Log
Late init
... messages deleted ...
Speicherzugriffsfehler (Segmentations Fault)
Apparently it has something to with the libstdc++.so.5 (libstdc++.so.5.0.7). Checking the compilation date of the binary package showed, that it was recompiled around the middle of February 2009. With that recompilation something must have gone wrong (newer compiler or whatever). Once I replaced the libstdc++.so.5.0.7 with a version compiled on a native 32bit Gentoo system, Bibble was working just fine again.
BTW, I noticed that there is now a public preview version of Bibble 5. This version is in the making for quite some time now. Bibble 4 is really getting long in the tooth. I hope, they can release something sometime soon.
If you search on delicious for “paper cd case” apart from other you’ll find these two pages (1, 2), which present Web forms. The forms allow you to enter some text and after submitting offers you to download a PDF file, which, when printed, allows you to fold a CD case from paper. Another alternative is this page.
This all works very well. I received some pretty “Wow”s after showing those CD cases to friends. However for the times, when I backup my growing MP3 collection to DVD I wanted a bit more influence, on what can be printed on the case. Therefore I duplicated the folding lines in a SVG file. Once loaded into Inkscape, you have all Inkscape tools available to style the CD case appropriately.
The move to X.Org server 1.5.x was not quite the smooth ride I expected it to be. It took me the better part of a Saturday afternoon to get everything in working order again. Some time ago (actually already 2 month have gone by) I used the opportunity to do this, while fiddling with Ubuntu 8.10 on an externally connected USB drive. I compiled the X-server in a chroot environment on my standard os partition.
The first good thing I noticed after rebooting into my standard Gentoo environment was, that all of my 9 mouse buttons were correctly working. The bad news was, that each time I pressed the Cursor Up key, that the KDE screen snapshot utility would open. I tried multiple changes in the Input section of the /etc/X11/xorg.conf file, all to no avail. The first break through came, when I completely removed all sections from the xorg.conf file having something to do with the keyboard or the mouse. After that it was only additional configuration for the HAL subsystem, to report the correct keyboard type. For this I created the file /etc/hal/fdi/policy/10-x11-input.fdi with this content:
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keys">
<merge key="input.xkb.model" type="string">evdev</merge>
<merge key="input.xkb.layout" type="string">de</merge>
<merge key="input.xkb.rules" type="string">evdev</merge>
</match>
</device>
</deviceinfo>
I think, the best way to diagnose any problems is to look at the /var/log/Xorg.0.log file. For my particular keyboard/mouse the output looks like this:
(II) config/hal: Adding input device HOLTEK Wireless Keyboard/Mouse(2.4G)
(**) HOLTEK Wireless Keyboard/Mouse(2.4G): always reports core events
(**) HOLTEK Wireless Keyboard/Mouse(2.4G): Device: "/dev/input/event2"
(II) HOLTEK Wireless Keyboard/Mouse(2.4G): Found keys
(II) HOLTEK Wireless Keyboard/Mouse(2.4G): Configuring as keyboard
(II) XINPUT: Adding extended input device "HOLTEK Wireless Keyboard/Mouse(2.4G)" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) HOLTEK Wireless Keyboard/Mouse(2.4G): xkb_rules: "evdev"
(**) Option "xkb_model" "evdev"
(**) HOLTEK Wireless Keyboard/Mouse(2.4G): xkb_model: "evdev"
(**) Option "xkb_layout" "de"
(**) HOLTEK Wireless Keyboard/Mouse(2.4G): xkb_layout: "de"
The xkb_* options are the important places here. Before I managed to set xkb_layout to “de” through HAL, the log file would report “us” here, which in turn had the affect of opening the snapshot dialogue when pressing Cursor Up. Another problem was the xkb_rules option. Some blog article I found through googling suggested to set xkb_rules to xorg. This does not work however, since xorg is a symbolic link in the /usr/share/X11/xkb/rules directory and links to base, which is not the correct rules set for the evdev-driver.
These three articles (part1, part2 and part3) from the Cybso blog were very helpful. In particular if you are using lineak. You should look at part 3 and install the lineakd keyboard file for the evdev-driver. These two links were helpful as well (1, 2
The Gentoo folks have created an update guide in the meantime, which wasn’t available, when I started out.
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 > ....