Yesterday one of my Xen DomU's died with:

Unable to handle kernel paging request at ffff8800064d9000 RIP:
[<ffffffff801b99c7>] leaf_copy_items_entirely+0x15f/0x1fb
PGD 516067 PUD 517067 PMD 54a067 PTE 80100000064d9065
Oops: 0003 [1]
CPU 0
Modules linked in:
Pid: 25320, comm: sshd Not tainted 2.6.21-xen #1
RIP: e030:[<ffffffff801b99c7>] [<ffffffff801b99c7>] leaf_copy_items_entirely+0x15f/0x1fb
RSP: e02b:ffff88000620f228 EFLAGS: 00210282
RAX: 0000000000000b64 RBX: 000000000000fc3c RCX: fffffffffffc60d8
RDX: ffff880003ff8af0 RSI: ffff8800009eaf28 RDI: ffff8800064d9000
RBP: ffff8800064aec3c R08: ffff8800064aec3c R09: 0000000000000000
R10: 0000000000000120 R11: ffff8800049b0000 R12: 0000000000000210
R13: 00000000000000d8 R14: 0000000000000008 R15: ffff88000649f000
FS: 0000000000000000(0000) GS:ffffffff80434000(0063) knlGS:0000000000000000
CS: e033 DS: 002b ES: 002b CR0: 000000008005003b
CR2: 0000000000000000 CR3: 000000000278a000 CR4: 0000000000000660
Process sshd (pid: 25320, threadinfo ffff88000620e000, task ffff880002494990)
Stack: 0000000000000016 ffff880006223d60 ffff88000620f2c8 ffff88000649f0c0
fdf088000620f2c8 ffff880003ff8af0 0000000803ff8af0 0000000000000016
0000000000000000 ffff880006223d60 ffff88000620f2c8 0000000000000016
Call Trace:
[<ffffffff801bb509>] leaf_move_items+0x21f/0x321
[<ffffffff801c19b1>] get_cnode+0x5c/0x61
[<ffffffff801bb683>] leaf_shift_left+0x30/0x95
[<ffffffff801a6e49>] do_balance+0x420/0x271b
[<ffffffff80184dd4>] __getblk+0x1b/0x1c7
[<ffffffff801861b9>] __bread+0x6/0x74
[<ffffffff801c0b45>] reiserfs_prepare_for_journal+0x4f/0x56
[<ffffffff801b4e8d>] fix_nodes+0x501/0x7c6
[<ffffffff801bed82>] reiserfs_delete_item+0x311/0x34e
[<ffffffff801c0725>] direct2indirect+0x34c/0x3fb
[<ffffffff801ad8ff>] reiserfs_get_block+0x9c3/0xf70
[<ffffffff80185482>] ll_rw_block+0x8b/0xa4
[<ffffffff8018560e>] __block_prepare_write+0x173/0x42a
[<ffffffff801acf3c>] reiserfs_get_block+0x0/0xf70
[<ffffffff801858df>] block_prepare_write+0x1a/0x24
[<ffffffff801abfa8>] reiserfs_prepare_write+0xc9/0x126
[<ffffffff80184915>] __generic_cont_expand+0x9f/0xfa
[<ffffffff801b0667>] reiserfs_file_write+0x2e3/0x18e8
[<ffffffff801b5d48>] reiserfs_dirty_inode+0x61/0x68
[<ffffffff80127dfa>] current_fs_time+0x35/0x3a
[<ffffffff80181b0f>] __mark_inode_dirty+0x2f/0x171
[<ffffffff8017a372>] touch_atime+0xbe/0x104
[<ffffffff801489f6>] do_generic_mapping_read+0x3c1/0x407
[<ffffffff80147e55>] file_read_actor+0x0/0x118
[<ffffffff80176316>] __posix_lock_file_conf+0x35f/0x394
[<ffffffff80176db5>] fcntl_setlk+0x214/0x241
[<ffffffff80169a80>] vfs_write+0xad/0x136
[<ffffffff80169f3c>] sys_write+0x45/0x6e
[<ffffffff80117eb8>] ia32_sysret+0x0/0xa
[<ffffffff80117e40>] ia32_syscall+0x0/0x5a

Code: f3 a4 8b 44 24 34 03 04 24 66 41 89 47 02 66 41 29 dd 44 89
RIP [<ffffffff801b99c7>] leaf_copy_items_entirely+0x15f/0x1fb
RSP <ffff88000620f228>
CR2: ffff8800064d9000
BUG: at /usr/src/linux-2.6.21-xen/kernel/exit.c:861 do_exit()

Call Trace:
[<ffffffff8012651e>] do_exit+0x47/0x790
[<ffffffff801207cd>] __wake_up+0x23/0x46
[<ffffffff801145f4>] do_page_fault+0x1206/0x1282
[<ffffffff80108c94>] __switch_to+0x351/0x45d
[<ffffffff80346eb7>] error_exit+0x0/0x69
[<ffffffff801b99c7>] leaf_copy_items_entirely+0x15f/0x1fb
[<ffffffff801b9994>] leaf_copy_items_entirely+0x12c/0x1fb
[<ffffffff801bb509>] leaf_move_items+0x21f/0x321
[<ffffffff801c19b1>] get_cnode+0x5c/0x61
[<ffffffff801bb683>] leaf_shift_left+0x30/0x95
[<ffffffff801a6e49>] do_balance+0x420/0x271b
[<ffffffff80184dd4>] __getblk+0x1b/0x1c7
[<ffffffff801861b9>] __bread+0x6/0x74
[<ffffffff801c0b45>] reiserfs_prepare_for_journal+0x4f/0x56
[<ffffffff801b4e8d>] fix_nodes+0x501/0x7c6
[<ffffffff801bed82>] reiserfs_delete_item+0x311/0x34e
[<ffffffff801c0725>] direct2indirect+0x34c/0x3fb
[<ffffffff801ad8ff>] reiserfs_get_block+0x9c3/0xf70
[<ffffffff80185482>] ll_rw_block+0x8b/0xa4
[<ffffffff8018560e>] __block_prepare_write+0x173/0x42a
[<ffffffff801acf3c>] reiserfs_get_block+0x0/0xf70
[<ffffffff801858df>] block_prepare_write+0x1a/0x24
[<ffffffff801abfa8>] reiserfs_prepare_write+0xc9/0x126
[<ffffffff80184915>] __generic_cont_expand+0x9f/0xfa
[<ffffffff801b0667>] reiserfs_file_write+0x2e3/0x18e8
[<ffffffff801b5d48>] reiserfs_dirty_inode+0x61/0x68
[<ffffffff80127dfa>] current_fs_time+0x35/0x3a
[<ffffffff80181b0f>] __mark_inode_dirty+0x2f/0x171
[<ffffffff8017a372>] touch_atime+0xbe/0x104
[<ffffffff801489f6>] do_generic_mapping_read+0x3c1/0x407
[<ffffffff80147e55>] file_read_actor+0x0/0x118
[<ffffffff80176316>] __posix_lock_file_conf+0x35f/0x394
[<ffffffff80176db5>] fcntl_setlk+0x214/0x241
[<ffffffff80169a80>] vfs_write+0xad/0x136
[<ffffffff80169f3c>] sys_write+0x45/0x6e
[<ffffffff80117eb8>] ia32_sysret+0x0/0xa
[<ffffffff80117e40>] ia32_syscall+0x0/0x5a

Which caused all kinds of problems and eventually causing the DomU to die until I ran fsck. The closest thing I've found is the Crash DomU for reiserfs filesystem bug un Launchpad. Unfortunately it's closed and not fixed. I'm a bit puzzled wether this is caused by bad hardware or it's a real bug...

Today I got yet another GSM modem, this time around from TDC/Vodafone. I thought that I'd just to the same test like I did the with Telia and 3.

wget http://ftp.ing.umu.se/linux/gentoo/releases/x86/2008.0_beta2/installcd/install-x86-minimal-2008.0_beta2.iso -O /dev/null
--2008-06-24 23:02:29-- http://ftp.ing.umu.se/linux/gentoo/releases/x86/2008.0_beta2/installcd/install-x86-minimal-2008.0_beta2.iso
Resolving ftp.ing.umu.se... 130.239.117.84
Connecting to ftp.ing.umu.se|130.239.117.84|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 62447616 (60M) [application/x-iso9660-image]
Saving to: `/dev/null'

100%[====================================================================>] 62,447,616 228K/s in 5m 59s

2008-06-24 23:08:30 (170 KB/s) - `/dev/null' saved [62447616/62447616]

What a coincidence, the download time is same as I got with Telia even down to the second. It's still almost three times slower than 3, but it should be fast enough for causual email checking while on the road.

Arggh it just happened again!

From time to time I run into a strange problem with Xorg on my hardened laptop and the mouse pointer on screen jumps to the upper left corner of the screen and stays there:-(

AFAIR the problem have persisted across several Xorg versions so I'm wondering wether it's something hardware specific or perhaps related to hardened. Though I haven't really had the time to dig into it.

UPDATE: Thx to Gordon Malm for solving the issue. It's indeed caused by CONFIG_PAX_KERNEXEC as described in Using Xorg on Hardened Gentoo.

I've been using Trac for a couple of my own pet projects, but I've started to wonder wether there were better alternatives. Years ago I migrated my own internal wiki to the Trac Wiki. And it's been hosting all my internal docs ever since.

On top of that I've used the SVN integration for a couple of my pet projects. This worked out really nice for some time. But after some time I started to get tired of the wiki and it's strange behaviour when some odd character is entered on some wiki page and it refuses to display and instead just throws some Python errors. This is the point were it's usability fails and some people just give up (I convinced other people to use Trac in the meantime).

Instead I've been looking for alternatives and it seems like Redmine could suit my needs for a simple project website with a simple wiki and a SVN frontend. On top of that I might actually get a ticket system that is useful.

Strangely enough my search have found zero ebuilds for Redmine so I haven't really tried out my own install yet as I'm too lazy:)

If anyone have a decent ebuild or recommendations for alternatives I'd be glad to hear.

Since I got to play around with the Huawei E270 last time I've had a the smaller brother from Huawei the E220 from Telia.

However this time around it was a bit more tricky to get it working correctly. Unless the modem is plugged in during boot I have to use the small huaweiAktBbo.c hack to get the ttyUSB devices working correctly. I'm not completely sure why but this wasn't needed last time around.

I used a setup similar to the 3 modem just using the APN www.internet.mtelia.dk (3 was data.tre.dk) and the dialed number *99# (3 was *99***1#).

Since I tested download speed last time I retried the test:

wget http://ftp.ing.umu.se/linux/gentoo/releases/x86/2008.0_beta2/installcd/install-x86-minimal-2008.0_beta2.iso -O /dev/null
--2008-05-25 18:59:17-- http://ftp.ing.umu.se/linux/gentoo/releases/x86/2008.0_beta2/installcd/install-x86-minimal-2008.0_beta2.iso
Resolving ftp.ing.umu.se... 130.239.117.84
Connecting to ftp.ing.umu.se|130.239.117.84|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 62447616 (60M) [application/x-iso9660-image]
Saving to: `/dev/null'

100%[====================================================================>] 62,447,616 174K/s in 5m 59s

2008-05-25 19:05:19 (170 KB/s) - `/dev/null' saved [62447616/62447616]

With the modem from 3 I downloaded beta1 from the same mirror in just 2m 22s which is almost three times faster than with Telia.

For comparison I tried the same download with my ADSL2 connection from Fullrate and it took just 31 seconds :)