First steps were the usual round of updates to install, update to WordPress 3.2.1 and a new theme with some little tweaks from me. This even included the usage of one of Google’s web fonts. World of wonders, this even worked in the three browsers, that I tried (Firefox, Chrome and IE8).

Of course, the usual problem solving was also necessary. Blogging clients like Blogilo or ScribeFire wouldn’t get the older posts list from the site. To fix this PHP’s memory limit needed to be changed. With WordPress 2.9 16M was enough. Now with WordPress 3.2.1 after some tries I set the limit to 36M, the maximum, which my provider allowes.

I tried this with my PC at work, which is equipped with an old GeForce FX 5200 Nvidia graphics card. To get the kernel with that card going, the legacy Nvidia driver 173.14.25 is required. In the current Gentoo Portage tree unfortunately there is only 173.14.22. That is not too much of a problem however. As a very Quick’n Dirty solution simply copy nvidia-drivers-173.14.22.ebuild to nvidia-drivers-173.14.25.ebuild, execute

ebuild nvidia-drivers-173.14.22.ebuild digest

and then emerge the driver, after you have compiled the 2.6.33 kernel.

The Pulseaudio<->ALSA problem however is not fixed, although it appears to take longer until the problem shows up. What is worse, my previous workaround (compiling the ALSA 1.0.20 driver and install the modules over the kernel modules) does not work any, since the ALSA driver won’t compile with the new kernel, since some include files have been moved in the kernel tree.

So I guess I’ll stay with kernel 2.6.32 for the time being until I receive my new PC in the not to distant future.

I use these two cards to record the audio from DVB-C (the first) and for the analog broadcast (the second):

05:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
    Subsystem: KNC One Device 0022

05:02.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
    Subsystem: Hauppauge computer works Inc. WinTV Series

This first picture compares the volume levels. The above half is from the digital broadcast and the lower half from the analog broadcast, both showing about 1 hour from the same show. Both recording are normalized to -0.2db of maximum level with Audacity.

As you can see, the analog broadcast has a certain dynamic range left, while the digital broadcast is completely flat. Apparently, the signal, which is used to create the digital stream is passed through a compressor, which reduces the dynamic range to a minimum. Not very nice. Apparently not every station does this compressor thing. Another station from Berlin I’m occasionally listening to in digital has a lot more dynamic range left.

This next picture provides a detailed waveform view. The upper shows a very clean signal from the digital broadcast, as is to be expected. On the lower half the noise is apparent in the analog broadcast, which is overlayed on the normal signal. An analog broadcast simply can’t provide the same absolute maximum dynamic range as a the digital signal can. Another problem probably is, that the old BTTV TV-card doesn’t carry very high quality electronic components, which adds to the level of noise.

The last picture compares the frequency ranges, which each broadcast type offers. There is nothing much left above 15KHz. In the analog broadcast the peak at 19KHz is stereo pilot signal used to indicate stereo broadcasts. This is not a usable audio signal.

Our local cable operator is trying pretty aggressively to get new customers and are trying to convince the customers of the advantages of digital TV and radio. From the above pictures the digital advantage is not really visible, except maybe for the better signal-noise ratio. Additional problem is the requirement of SmartCards, if you want to listen to private radios. With the digital receiver provided by the cable operator, where you insert the SmartCard, you can either watch TV or listen to radio, not both at the same time. So, the remaining receivers in the house hold need to use the analog signal anyway. Who would spend another 5€ per month for another SmartCard?

And indeed with this workaround ACPI wakeup works again. Looking at the output of cat /proc/driver/rtc

rtc_time    : 11:44:20
rtc_date    : 2010-02-17
alrm_time   : 07:21:16
alrm_date   : ****-**-17
alarm_IRQ   : no
alrm_pending    : no
24hr        : yes
periodic_IRQ    : no
update_IRQ  : no
HPET_emulated   : no
DST_enable  : no
periodic_freq   : 1024
batt_status : okay

the HPET_emulated line should report no.

Another fix was released with the xorg-server 1.7.5. Since the switch to xorg-server 1.7 I was basically unable to switch from the X11 display running with 1600×1200 resolution to a virtual console. Switching to a virtual console resulted in a dark display complaining about illegal operating parameters. This was particular annoying, when shutting the system down.

As a workaround with earlier xorg-servers I switched X11 resolution to 1280×1024 with “Ctrl + Alt + Keypad -” and then switched to a virtual console. Now the virtual console was operable.

The fix for xorg-server 1.7 was announced in this email. Unfortunately stupid me didn’t think about the xfce4-display-settings utility (I’m a XFCE4 user), then I would have been able to switch resolutions graphically.

I experienced three glitches so far on my Gentoo installation. I hope these are not cases of RTFM.

Portaudio with ALSA cmipci-driver

With a freshly rebooted kernel I’m pretty quickly seeing these messages in /var/log/message.

pulseaudio[4338]: alsa-util.c: Dies ist wahrscheinlich ein Fehler im ALSA-Treiber 'snd_cmipci'. Bitte melden Sie diesen Punkt den ALSA-Entwicklern.
pulseaudio[4338]: alsa-util.c: snd_pcm_dump():
pulseaudio[4338]: alsa-util.c: Hardware PCM card 0 'C-Media CMI8738' device 0 subdevice 0
pulseaudio[4338]: alsa-util.c: Its setup is:
pulseaudio[4338]: alsa-util.c:   stream       : PLAYBACK
pulseaudio[4338]: alsa-util.c:   access       : MMAP_INTERLEAVED
pulseaudio[4338]: alsa-util.c:   format       : S16_LE
pulseaudio[4338]: alsa-util.c:   subformat    : STD
pulseaudio[4338]: alsa-util.c:   channels     : 2
pulseaudio[4338]: alsa-util.c:   rate         : 44100
pulseaudio[4338]: alsa-util.c:   exact rate   : 44100 (44100/1)
pulseaudio[4338]: alsa-util.c:   msbits       : 16
pulseaudio[4338]: alsa-util.c:   buffer_size  : 16384
pulseaudio[4338]: alsa-util.c:   period_size  : 8192
pulseaudio[4338]: alsa-util.c:   period_time  : 185759
pulseaudio[4338]: alsa-util.c:   tstamp_mode  : ENABLE
pulseaudio[4338]: alsa-util.c:   period_step  : 1
pulseaudio[4338]: alsa-util.c:   avail_min    : 15503
pulseaudio[4338]: alsa-util.c:   period_event : 0
pulseaudio[4338]: alsa-util.c:   start_threshold  : -1
pulseaudio[4338]: alsa-util.c:   stop_threshold   : 1073741824
pulseaudio[4338]: alsa-util.c:   silence_threshold: 0
pulseaudio[4338]: alsa-util.c:   silence_size : 0
pulseaudio[4338]: alsa-util.c:   boundary     : 1073741824
pulseaudio[4338]: alsa-util.c:   appl_ptr     : 231533
pulseaudio[4338]: alsa-util.c:   hw_ptr       : 212998

I think with Linux 2.6.30 I experienced these problem for the first time, both for the onboard 82801EB/ER (ICH5/ICH5R) audio controller and the add-on C-Media CM8738 controller. Since then I’ve been reinstalling the ALSA driver 1.0.20 from http://www.alsa-project.org each time I recompiled a new kernel. 1.0.21 showed the same problem. Pulseaudio progessed in this period from 0.9.15 to 0.9.21, the latest being the one I’m currently using.

What changed with 2.6.32 however is, that onboard 82801EB/ER (ICH5/ICH5R) now appears to be working. After listening with onboard audio for a bit, I remembered, why I installed an elcheapo PCI-card. The onboard audio carries such an amount of noise, that it is unbearable.

NFS

When I tried to mount a locally exported file system on a remote system, these segmentation fault showed up in /var/log/messages:

kernel: rpc.mountd[3885]: segfault at 13 ip 0804c133 sp bfc98530 error 4 in rpc.mountd[8048000+12000]

This could be fixed be recompiling net-fs/nfs-utils-1.2.1.

ACPI-Wakup

I’m using the below command sequence to let my PC wake-up and boot at 7:15 in the morning, so that it’s ready, when I come into the company. This worked flawlessly until I switched to 2.6.32.

# echo 0 > /sys/class/rtc/rtc0/wakealarm
# echo $(date -u '+%s' -d 'tomorrow 7:15') > /sys/class/rtc/rtc0/wakealarm
# cat /proc/driver/rtc 
rtc_time    : 17:07:41
rtc_date    : 2009-12-11
alrm_time   : 07:15:00
alrm_date   : 2009-12-12
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

Here is someone, who apparently experiences this as well.

Anyway Inkscape sports such a plethora of keyboard and mouse functions, that I thought, it would be probably very useful to have a small booklet in paper form beside your keyboard.

Therefore I basically copied the Inkscape keyboard and mouse reference into OpenOffice and created this OpenOffice file, designed to be printed on A4 paper. The actual shuffling of the pages to print the file as booklet is not done within OpenOffice, but by transforming PostScript files using the psutils. I guess pretty much every Linux distribution should have them on board.

To actually create the booklet I’ve saved the OpenOffice source into this PDF file with OpenOffice’s “Export to PDF” function. Then, I used evince from the Gnome Desktop Environment to create a file randomly called t.ps by printing to a PostScript file (inkspace-key.ps). The final booklet file is created by executing the following commands:

psbook -s16 inkscape-keys.ps t.ps
pstops '2:0L@.7(21cm,0)+1L@.7(21cm,14.85cm)' t.ps tt.ps
ps2pdf14 tt.ps

The psbook reorders the pages in such a way, that once printed double sided in landscape format, the resulting stack of pages can simply be folded in the middle. The pstops command then rotates, scales and positions each A4 page, so that two pages are printed on each side of a piece of paper. ps2pdf then creates a new PDF file (tt.pdf).

At home I’m using a Canon Pixma ip4000 printer. For this booklet I don’t use the printers ability to print double sided, since front and back page then have a slight offset. I use evince again to first print the odd numbered paged, re-feed the printed pages as they are stacked back into the feeder and print the back sides with the even pages. Now you should have a booklet, that you can simply fold in the middle. This is the resulting PDF file the above three command executions as an example.

You might need to fiddle a bit with the “0″ and “14.85cm” parameters for the pstops command, so that the front and the back of a page properly align.

In preparation of sending the Samsung hard disk back to the dealer as a warranty issue, I cleared the whole disk with a “dd” command (dd if=/dev/zero of=/dev/sdb bs=64k). I monitored the process by running vmstat 10 in another terminal window. The resulting bo-column (block out) is reflected by the diagram to the right.

The whole operation took roughly 4 hours and 10 minutes. The drive operated at full for the first third, than things obviously got flaky. The same effect I saw with my file system copy operations. Large periods where the drive operates with only 4 — 6 Mb/s output rate.

Hopefully this will be prove enough for the dealer to replace the drive.

Update: In the meantime I’ve received a replacement drive. Just to see, if this drive was ok, I repeated the zeroing of the complete drive. I’m assuming, that the minor hiccup at the beginning doesn’t mean any problems.

According to the changelogs of the recently released Linux kernels, there were quite a bit of changes in the ext3/ext4 file systems. Therefore in the beginning of October I moved all my file systems from XFS to Ext4 in the hope for things to get better. Once the data was restored the situation was as bad as before, it even felt a bit worse. During this backup and restore process for the first time it dawned on me, that my Samsung F1 hard disk might be the culprit. In particular once I looked at the S.M.A.R.T. data with GSmartControl.

When I looked at the data for the first time after the restore operation, the data looked much than in this screenshot. There recoverd ECC and Soft Errors in 6-7 digit numbers. However never ever did I see that the disk reported an error to the operating system.

And, what I probably should have considered earlier, that the transfer to the external ESATA drive always worked with top performance, the copy back process to the original disk than was awful again. I even went so far to copy the OS to another external USB drive to remove the OS from the equation. I booted from the USB drive and redid the backup and restore operation. Again with the same result, that the Samsung disk showed a very bad write performance. This was when I finally decided to order another hard drive. Tom’s Hardware gave Samsung Spinpoint F3 pretty good marks and that’s the one I ordered then.

And what can I say? My problems were gone, completely and utterly gone. Look at the little Gkrellm screenshots on the right. The left half shows the copy process from the old, “bad” disk (top half) to “good” new disk. As you can see, the new disk is even faster than the old one. The right half however shows the copy process from the “good” F3 disk to the “bad”, old F1 disk. Here you can observe the very low write performance of the old F1 disk (top half).

Then I obtained the Samsung hutil disk utility and did a low level reformatting of the old F1 disk and also did self diagnostic with a complete surface scan. Both operation didn’t show any problem whatsoever. I redid some copy operations to the old F1 and the new F3 disks and logged the output from vmstat and created the below diagrams.

Each time the data was copied with the following command line:

tar -c -b 128 -f - source-dir | tar -x --checkpoint=1000 -b 128 -C /destination-dir/

The data was collected with vmstat 10 | tee /tmp/logfile. Roughly 120Gb were transferred.

This the diagram for the copy process to the “good” new F3 disk (bi is “block in” for the read op, bo is “block out” for the write op). The source disk was the old F1 disk. The whole process took about 38 minutes. This is the raw text file from the vmstat command. As you can see the read performance of the old F1 disk is perfectly fine.

And here is the diagram for copy process from the new F3 to the old F1 disk. Simply bloody awful write transfer rate. The whole operation took about 98 minutes. This is the raw text file from the vmstat command. The spikes are probably due to the hard disk write cache. Now wonder, that the whole desktop might get sluggish with such a bad behavior.

I’m so annoyed, that I didn’t draw the right conclusions earlier. I could have spared me more than 1½ year of frustration with Linux in general.

In the end I made these changes (relative to the directory /usr/share/X11/xkb/keycodes):

--- keycodes.dir.org    2009-09-03 08:31:32.000000000 +0200
+++ keycodes.dir    2009-10-06 12:58:54.000000000 +0200
@@ -46,6 +46,7 @@
 -------- -------- sony(nwp5461)
 -d------ -------- evdev(evdev)
 -------- -------- evdev(pc98)
+-------- -------- evdev(type6)
 -d------ -------- xfree86(xfree86)
 -------- -------- xfree86(basic)
 -------- -------- xfree86(102)
-- keycodes/evdev.org   2009-09-03 08:31:32.000000000 +0200
+++ keycodes/evdev  2009-10-06 12:59:32.000000000 +0200
@@ -311,3 +311,10 @@
     include "evdev(evdev)"
 };

+// Sun Type 6
+xkb_keycodes "type6" {
+    include "evdev(evdev)"
+    <RCTL> = 108;
+    <RALT> = 134;
+    <RWIN> = 105;
+};
--- rules/evdev.org 2009-09-03 08:31:34.000000000 +0200
+++ rules/evdev 2009-10-06 13:00:04.000000000 +0200
@@ -105,6 +105,7 @@
 ! $dvoraklayouts = br ca de ee es fr gb no pl se us

 ! model        =   keycodes
+  type6        =   evdev(type6)
   pc98     =   evdev(pc98)
   *        =   evdev

With the above changes I was additionally able to modify the file /etc/hal/fdi/policy/10-x11-input.fdi so that HAL will do the right thing, once this keyboard is plugged in (see the line with input.product).

<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keys">
      <merge key="input.xkb.rules" type="string">evdev</merge>
      <merge key="input.xkb.layout" type="string">de</merge>
      <match key="input.product" contains="HID 0430:0005">
        <merge key="input.xkb.model" type="string">type6</merge>
      </match>
    </match>
  </device>
</deviceinfo>

Make sure, that your desktop environment uses the system settings and doesn’t override it with session local settings, when you log into your desktop. If everything is correct, the /var/log/Xorg.0.log should contain something like this:

...
(II) config/hal: Adding input device HID 0430:0005
(**) HID 0430:0005: always reports core events
(**) HID 0430:0005: Device: "/dev/input/event0"
(II) HID 0430:0005: Found keys
(II) HID 0430:0005: Configuring as keyboard
(II) XINPUT: Adding extended input device "HID 0430:0005" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "type6"
(**) Option "xkb_layout" "de"
...

While the above changes may be the 100% solution, there is still the danger, that the changes are overwritten, when new keyboard tables are installed. For Gentoo Linux it is therefore advisable to extend the CONFIG_PROTECT variable in /etc/make.conf with the directories /usr/share/X11/xkb/keycodes and /usr/share/X11/xkb/rules.

The simplest solution however may be to copy the file /usr/share/X11/xkb/keycodes/evdev to a new file /usr/share/X11/xkb/keycodes/evdev-new, edit the keycode changes into this file and then load the keycodes by executing “setxkbmap -keycodes evdev-new(type6)” somewhere in the login process (.xprofile or .xinitrc or whereever).

In the company I’m using a SUN Type6 USB keyboard. I’ve tried a couple of keyboards, but this still has the nicest feel of them all. The Linux evdev assigns the symbols Super_R (1 in the right picture), Menu (2 in the picture) and ISO_Level3_Shift (3 in the picture) in order to the three key right of the Space key. For me personally the ISO_Level3_Shift is a little bit far to right and I’m missing a right Control key. With Xorg server 1.5.3 I was able to remap the Super_R key to ISO_Level3_Shift and the right most key to Control_R by using setxkbmap and xmodmap.

$ setxkbmap -symbols "pc+de+inet(evdev)+level3(rwin_switch)"
$ xmodmap remapctrl

The file remapctrl contains the lines:

keycode 108 = Control_R Multi_key
clear control
add control = Control_L Control_R

All good and dandy. Then I switched to Xorg server 1.6.3.901-r1 (on Gentoo Linux).

It still sort of works. When I press the remapped ISO_Level3_Shift and “q” on the keyboard I’m getting the expected “@“. The same should be true for the “~” key. However the “~” is a dead key to produce characters like “ã” with two key strokes. Here, the newly remapped ISO_Level3_Shift has no effect and the same with all other dead keys.

When I remap the Menu key to ISO_Level3_Shift however with

$ setxkbmap -symbols "pc+de+inet(evdev)+level3(menu_switch)"

then all the dead keys like “~” work again as expected. I guess to need to fiddle with /usr/share/X11/xkb/keycodes/evdev to get a final fix.

Missing icon in systray

Some time in the past I switched from Amarok 1.4 to Mpd with the client Gmpc as my preferred music listening solution. Originally the icon in the Xfce4 systray looked ok as on the right side in the picture to the right (the light blue musical note).

After having installed the icon set Tango and after having switched the icon set a couple of times, I ended up with a systray, which looked like the left side in the picture (some generic icon for the Gmpc).

I then went searching, why in some icon sets the Gmpc systray icon was displayed correctly, while in others it was replaced with some generic icon.

After a bit of digging I found, that the Tango icon set, that I installed doesn’t inherit from the icon set hicolor, which appears to be the mother of all icon sets. Gmpc installs its icons in the hicolor directory structure. As I looked at the file /usr/share/icons/Tango/index.theme it read like this:

[Icon Theme]
Name=Tango
Comment=Tango Icon Theme
Inherits=gnome,crystalsvg
Example=x-directory-normal

After I changed “Inherits=gnome,crystalsvg” to “Inherits=hicolor,gnome,crystalsvg” everything looked fine in the systray again.

Wrong framerate on virtual consoles

Again, in the company I inherited a newer flat screen display panel compared to the old one, which had a resolution of 1280×1024. The new one now is capable of 1600×1200 pixels. After reconfiguring /etc/X11/xorg.conf and reboot into the X11 session everything was fine. However, now each time, when I’m shutting down the system or when I switch to one of the virtual Linux consoles, I’m getting an error message from the display, that the vertical and horizontal sync frequencies are out of range. Very annoying.

After some experimentation I have found a workaround. Before shutting down or changing the virtual console, I change the X11 resolution of the X11 server to the 1024×768 size with the key combination CTRL+ALT+Keypad- or CTRL-ALT-Keypad+. I’m wondering, if it has something to do with the fact, that I’m using a Nvidia graphics card. I think a came across similar problem reports in Ubuntu forums, which also mentioned Nvidia cards.