[edgy] keyboard broken in X11 on xen dom0

[packet]

Hello!

Booting Kubuntu edgy as Xen dom0 makes my keyboard unusable under X11. It gets very sluggish, meaning that there is a varying delay between key press and printing of a character on the screen and that some characters are doubled.

After logging in to X11, the keyboard first behaves as it should, but at the time kdewallet asks for the wallet passphrase (which is usually the last thing that happens when the session is restored), the keyboard starts to behave like this.

I have installed the following packages:

libc6-xen (2.4-1ubuntu12)
libxen3.0 (3.0.3-0ubuntu1)
python-xen3.0 (3.0.3-0ubuntu1)
xen-docs-3.0 (3.0.3-0ubuntu1)
xen-hypervisor-3.0-i386 (3.0.3-0ubuntu1)
xen-image-xen0-2.6.17-6-generic-xen0 (2.6.17-6)
xen-restricted-modules-2.6.17-6-generic-xen0 (2.6.17-3)
xen-utils-3.0 (3.0.3-0ubuntu1)

The problem seems to be (K)Ubuntu specific, as it does not happen with the Xen 3.0.3 live CD.

I have suspected it might be a kernel/hypervisor problem and tried the latest unstable XEN kernel/hypervisor (from xen-unstable.hg) without replacing the user space tools, but the problem still occurs.

I have also suspected, that my CPU is detected wrong, because I have a Pentium 4 1.8 GHz which the hypervisor rightly detects as such but the dom0 kernel (from the package and also the xen upstream kernel) reports a 2 GHz Pentium.

Read U!

packet

[packet (packet)]

On the console the keyboard works fine. So it's probably a problem in the Xserver that is exposed by Xen.

[packet (packet)]

Sound is also stuttering under Xen, so maybe it really is a timing problem caused by the disagreement over CPU clock speed.

[packet (packet)]

The same setup as above is working in another computer. On this one (the working one), Xen and the Dom0 kernel agree about the CPU clock speed (it's an old 1.3 GHz Athlon, clocked down to 1.0 GHz to reduce heat) and the reported CPU clock speed equals the actual clock setting from the BIOS (i.e. both Xen and Linux report 1.0 GHz).

[packet (packet)]

Seems like I was a bit too fast. It is not working on the other computer, it just takes a bit longer but then not only the keyboard behaves odd, but shortly after the keyboard begins to make trouble, X (or the keyboard, I currently have no mouse) locks up completely. Logging in via ssh still worked but after killing and restarting X the keyboard didn't work anymore.

[packet (packet)]

I think I have found the cause: openntpd. The keyboard begins stuttering in the exact moment that ntpd is stepping time because of a great offset. Keyboard works if I disable ntpd and stops working if I start it then. I have tested this on the second computer and will test it now on the first one. I cannot confirm this now, but it seems like time runs much too fast in dom0 (this is on the computer where the CPU clock speed is reported correctly), and this leads to ntpd stepping the time back for as much as 4 seconds at once.

[packet (packet)]

I was a bit too fast, turns out, that openntpd's "adjusting local clock by" message means adjtime(). I've written a small test program to reproduce this bug.

sudo ./test -4

triggers the bug and

sudo ./test 0

fixes it after doing the first.

The bug can only be triggered with big (i.e. more than one second), negative adjustments. Positive adjustments don't trigger this bug. Attached is the source code for the test program.

[packet (packet)]

I didn't mention it before, but to reproduce this bug it might be necessary to use a PS/2 keyboard, this is what I'm using.

[Chuck Short (zulcss)]

Please try the feisty version.

Thanks
chuck

[Launchpad Janitor (janitor)]

[Expired for xen-3.0 (Ubuntu) because there has been no activity for 60 days.]