vboxadd-timesync makes Etch/64 guests Xorg crash

[Stéphane Charette]

After installing the Guest Additions in Debian Etch 64-bit, I find that X continuously restarts every few seconds. The problem is exasperated by typing on the keyboard into a guest window (like bash, or into gedit).

The workaround I've discovered is to disabled timesync. Once the VirtualBox timesync is disabled, X no longer restarts. For example, if I run this, X wont restart anymore:

/etc/init.d/vboxadd-timesync stop

If at any point in time I run "/etc/init.d/vboxadd-timesync start", then X immediately starts crashing again.

I've run into this exact problem with 2 different computers running Ubuntu 8.04-64bit and Debian Etch 64-bit as host. I've confirmed the "workaround" works the same in both situations.

[Stéphane Charette]

I had vboxadd-timesync disabled. Then, from a bash command prompt within X, I ran the command "/etc/init.d/vboxadd-timesync start". X immediately crashed and restarted. Here is the tail of /var/log/Xorg.0.log.old. I'll attach the entire file to this bug report.

Backtrace: 0: /usr/bin/X(xf86SigHandler+0x6d) [0x4720bd] 1: /lib/libc.so.6 [0x2b61b22af110] 2: /usr/bin/X(WaitForSomething+0xa12) [0x544a42] 3: /usr/bin/X(Dispatch+0x8b) [0x44804b] 4: /usr/bin/X(main+0x44d) [0x430f9d] 5: /lib/libc.so.6(libc_start_main+0xda) [0x2b61b229c4ca] 6: /usr/bin/X(FontFileCompleteXLFD+0xa2) [0x43029a]

Fatal server error: Caught signal 11. Server aborting

[Stéphane Charette]

X crash log

[Michael Thayer]

Could you please check to see if this still happens when you disable the vboxvideo and vboxmouse X11 drivers?

[Stéphane Charette]

In /etc/X11/xorg.conf I changed the video driver to "vesa" and the mouse driver to "mouse". Rebooted.

Then I enabled timesync. (Normally the vboxadd-timesync script is disabled on this VM to prevent crashes -- I have to manually run it.)

X immediately started to crash again within a few seconds of starting timesync. Same backtrace as above. So I would say vboxvideo and vboxmouse is not related to this problem.

[Stéphane Charette]

session information from my debian etch vm

[Frank Mehnert]

vboxadd-timesync daemon for x86_64

[Frank Mehnert]

I've added a modified version of vboxadd-timesync to this defect. Please could you download the file, replace the binary of your Etch guest with this one, start the time service daemon again and check if the X server still crashes? So far we assume that this is some bug in the X server leading to a crash if the system time walks backwards. Of course this should not happen but the current implementation of the daemon is quite simple: It periodically reads the time from the host and uses the settimeofday() syscall to change the guest system time. The new binary uses the adjtime() syscall to prevent negative time offsets.

[Stéphane Charette]

Using the old vboxadd-timesync: When I look at the clock in the upper-right corner of the desktop, I see the time go up quite fast, and then about every 4 seconds or so I see the time go backwards a few seconds as it gets adjusted back. The X desktop stays up for a long time, unless I start typing into a window. Then, anywhere between 3 and 20 keystrokes, X dies as described above.

With the new vboxadd-timesync attached to this bug report by Frank: The clock in the upper-right corner of the desktop is moving ahead faster than it should be, just as before, but it no longer gets adjusted back. Every once in a while I see it hesitate, but it does it so rarely that within 2 minutes, my clocks (host and guest) are now 5 minutes apart. Within 20 keystrokes, X has crashed. Log file looks more-or-less the same:

Backtrace: 0: /usr/bin/X(xf86SigHandler+0x6d) [0x4720bd] 1: /lib/libc.so.6 [0x2b02836b7110] 2: /usr/bin/X(WaitForSomething+0xa12) [0x544a42] 3: /usr/bin/X(Dispatch+0x8b) [0x44804b] 4: /usr/bin/X(main+0x44d) [0x430f9d] 5: /lib/libc.so.6(libc_start_main+0xda) [0x2b02836a44ca] 6: /usr/bin/X(FontFileCompleteXLFD+0xa2) [0x43029a]

Fatal server error: Caught signal 11. Server aborting

Frank, have you seen this problem firsthand? Did this fix work for you? I have 2 computers -- a desktop and a laptop -- and both of them exhibit the same problem when running Debian Etch. For that reason, I thought this would be easy to repro. Let me know if that is not the case.

[Stéphane Charette]

X log file showing crash while using the new timesync executable

[Frank Mehnert]

Actually I still was not able to reproduce the problem since I currently don't have a Debian/Etch/64 VM. I'm using Debian/Etch/32 for a long time and never saw such problems. The binary I attached here uses adjtime() which does a very slow adjustment (about 5 milliseconds during 10 seconds). Therefore, if your host and your guest are drifting away very fast, adjtime() will not help. Can you say anything about how fast your guest drifts from the host if the timesync daemon is not started?

[Stéphane Charette]

Last time I sync'd the clocks manually (right-mouse-click on time, select "Adjust Date & Time") was around 9:30 this morning. The clocks have now drifted apart by just over 2 hours. The guest clock is running about twice as fast as it should be. Actual time is 12:15, guest says it is 14:28.

[Frank Mehnert]

Does your guest clock really run twice as fast as it should or does your guest just assumes the clock runs as UTC? Please

• disable the vboxadd-timesync daemon (add exit 0 to the beginning of that file)
• remove the file /etc/adjtime
• set UTC=no in /etc/default/rcS
• reboot the guest
• set the guest time to the host time with date -s 12:00 (if replace 12:00 by the current time of your host).
• reboot the guest again

Now make sure again that the timesync daemon is not running and check the guest time. If the guest time really drifts very fast, then I would advise you to recompile your host kernel and recompile the host vboxdrv module (/etc/init.d/vboxdrv setup). Because in that case, it is _very_ likely that the guest clock runs too fast because the vboxdrv module does not fit to the host kernel. I've read several of such reports before and very often the problem could be solved by recompiling the vboxdrv modules against the correct host kernel headers.

[Stéphane Charette]

Yes, the clock runs that fast. Only in this guest. My Ubuntu and Windows guests are fine. But Debian Etch 64-bit runs fast. If I leave it up and running for several days (like over the weekend) then the clock gets several days ahead into the future.

I didn't build this kernel. It is the kernel that is installed by default when installing Debian Etch. I don't want to start compiling custom kernels. Truth is, I wouldn't even know how to start.

As for "the guest runs too fast because the vboxdrv module does not fit to the host kernel": Doesn't the guest additions get built when installed, and get built according to the installed kernel? I've installed, removed, and re-installed the guest additions many times on these two computers. Same result each time. On the laptop, I've even formatted the host and re-installed a different host os, and when I install Debian Etch as a guest the behaviour is the same.

[Frank Mehnert]

Hmm, are you sure that your Ubuntu and Windows guests are not just running fine because the timesync daemon is enabled for these VMs? Could you double check your Ubuntu guest by disabling the timesync daemon for this VM as well?

If you didn't compile your own kernel (I'm talking about the host kernel here) but used the distribution-specific package then this should be fine. But to be 100% sure please check the Ubuntu guest with disabled timesync daemon.

Regarding the last paragraph: I was talking about vboxdrv which is the support driver for the host.

Please remove /etc/adjtime of your guest and reboot the guest. Check if the Etch guest still runs that fast.

[Stéphane Charette]

Replying to frank:

Hmm, are you sure that your Ubuntu and Windows guests are not just running fine because the timesync daemon is enabled for these VMs? Could you double check your Ubuntu guest by disabling the timesync daemon for this VM as well?

I disabled vboxadd-timesync on my Ubuntu 8.04-32 guest and rebooted. Time is fine. After about 10 minutes of uptime, I can see the seconds in the guest update about 1/2 second off from the host.

I disabled vboxadd-timesync on my Ubuntu 8.10-32-beta guest and rebooted. Time is fine. Same comment as the Ubuntu 8.04-32 guest mentionned above. (Note at this time I have both of those guests running at the same time.)

Now for the next test -- I boot up my Debian Etch-64 guest without timesync support. Note that this is my only Debian guest, and my only 64-bit guest. All my other Windows, OS/2 and linux guests are 32-bit. The clock on this guest is updating very fast. About 2 seconds slip by on this guest for every real-world second. I manually set the correct time, and within a few minutes the clock is already 10 minutes too fast into the future. Meanwhile, the other two guests mentionned above are still running as well, and their clocks are fine, even though timesync is not running on any of my guests.

If you didn't compile your own kernel (I'm talking about the host kernel here) but used the distribution-specific package then this should be fine. But to be 100% sure please check the Ubuntu guest with disabled timesync daemon.

I'm running VB 2.0.2 downloaded from the VB web site. Neither my host nor any of my guests have recompiled kernels. I haven't recompiled a linux kernel since my old Slackware and Redhat days many years ago. I have no idea how to do that with Ubuntu or Debian, nor would I want to have to do it.

Regarding the last paragraph: I was talking about vboxdrv which is the support driver for the host.

Please remove /etc/adjtime of your guest and reboot the guest. Check if the Etch guest still runs that fast.

I'll try that and reply to the comment above with the details.

[Stéphane Charette]

Replying to frank:

Does your guest clock really run twice as fast as it should or does your guest just assumes the clock runs as UTC? Please

• disable the vboxadd-timesync daemon (add exit 0 to the beginning of that file)
• remove the file /etc/adjtime
• set UTC=no in /etc/default/rcS
• reboot the guest
• set the guest time to the host time with date -s 12:00 (if replace 12:00 by the current time of your host).
• reboot the guest again

OK. Timesync is disabled, removed adjtime, changed UTC=yes to UTC=no, reboot, set time, reboot. Still goes too fast.

Now make sure again that the timesync daemon is not running and check the guest time. If the guest time really drifts very fast, then I would advise you to recompile your host kernel and recompile the host vboxdrv module (/etc/init.d/vboxdrv setup). Because in that case, it is _very_ likely that the guest clock runs too fast because the vboxdrv module does not fit to the host kernel. I've read several of such reports before and very often the problem could be solved by recompiling the vboxdrv modules against the correct host kernel headers.

So why does every single one of my guests (OS/2 v4.51, Windows XP, Windows Vista, Ubuntu 7.04, Ubuntu 7.10, Ubuntu 8.04, Ubuntu 8.10) run fine, even without the timesync app? The only one that isn't working from a time point of view is Debian Etch-64.

I'm running vboxdrv setup now. Have to shutdown my guests. vboxdrv setup is done, no warnings of any kind:

• Stopping VirtualBox kernel module * done.
• Removing old VirtualBox kernel module * done.
• Recompiling VirtualBox kernel module * done.
• Starting VirtualBox kernel module * done.

$ uname -a Linux renard 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux

Note the linux kernel used by Ubuntu is from late August, while VirtualBox 2.0.2 is from early September, so the kernel hasn't changed since I installed VirtualBox on my host.

I restarted my Debian Etch 64-bit guest now that vboxdrv has been recompiled, and the Debian Etch guest clock is still running twice as fast. If I enable the vboxadd-timesync application, X immediately starts crashing like before.

[Stéphane Charette]

Update: This is still happening for me with VirtualBox 2.0.4 with the new 2.0.4 guest additions installed. Same as before: stopping vboxadd-timesync fixes the problem with X crashing, though it does introduce time skew.

[Stéphane Charette]

Cut-and-paste from the forum:

I found a better workaround to the time & crash problem when using Debian Etch-64 as a guest. On the Debian Etch-64 guest, do the following:

1) edit the /boot/grub/menu.lst file (you'll need root privilege) 2) find the "kernel /boot/vmlinuz-..." line near the bottom of the file; there will likely be at least 2 of these lines, the 2nd one is typically for single-mode-user recovery 3) at the end of the kernel line, add the parameter noapic 4) shutdown and restart the guest

This way vbadd-timesync no longer causes crashes, the time doesn't run away at a gallop, and the keyboard doesn't go into overdrive inserting 20 keystrokes every time I press a key.

This "solution" works for me on both my desktop and my laptop, each of which are running Ubuntu 8.10-64bit host and Debian Etch-64bit guest.

[Frank Mehnert]

Interesting. Please could you attach a VBox.log file of your Etch-64 session?

[Stéphane Charette]

log file when everything works (noapic)

[Frank Mehnert]

Thanks for the log file. Still not able to reproduce. Does this happen as well if you remove the noapic parameter from the guest kernel and disable the I/O APIC in the VM settings?

[Stéphane Charette]

Removed "noapic" from boot line in menu.lst and disabled "IO APIC" in VirtualBox. Restarted guest: everything is fine, no crashes, and the clock is holding steady. This is yet even simpler of a solution than telling people to modify their menu.lst file. :)

Re-enabled "IO APIC" in VirtualBox and restarted guest. Clock is seen to be running fast when X starts, and X crashes after about 10 or 15 seconds, as described in this ticket.

Note that my two systems where this reproduces are Intel Core2 Quad 2.4GHz, and Intel Core2 Duo 2.2GHz, so actual SMP computers running smp kernels. I've re-disabled IO APIC in VB, and the guest has now been up for several minutes without problem.

I'll attach the last few log files just in case they contain something useful.

[Stéphane Charette]

last few log files, some with io apic disabled (ok), some with io apic enabled (crash)

[Frank Mehnert]

Please reopen if this bug is still present. VBox 3.1.2 guest additions use adjtime() to synchronize the guest time but this version has a bug which makes the guest time sometimes drift away from the host. This is fixed in 3.1.4 Beta. At least the guest shouldn't crash anymore.