VMware and Virtualbox timer causes on Solaris 10 update 8 and later nanosleep to hang for ever 
Friday, January 13, 2012, 12:42 - Technical Informations, VMware
Posted by Administrator
The system call nanosleep uses the system call cv_timedwait_sig to wait. Starting with Solaris 10 update 8 the system call cv_timedwait_sig uses the system call cv_timedwait_sig_hires to wait which then uses gethrtime() to schedule the wake up time. As this high resolution timer can jump on Solaris 10 running on top of a VMware ESX 3.5, VMware vSphere 4.x, VirtualBox virtual maschine with more than 1 CPU assigned, it can happen if the sleep exactly starts when such a jump occurs, that the end time is so far in the future, that it seems to system call is hanging for ever. As soon as one uses truss, pstack, jstack, ... to analyze the live process, the nanosleep call will wake up on a signal and continue.
To see if the high resolution timer is making jumps you can use the following small program gethrtime_test.c to test:

#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>

int main(int argc, char** argv)
{
     hrtime_t start, end;
     long iters = 1000000000;
     hrtime_t delta;
     delta=10000000;
 
     if (argc > 1) iters = atol(argv[1]);
     if (argc > 2) delta = atol(argv[2]);
     printf("%ld iterations\n", iters);
 
     start = gethrtime();
 
     long i;
     for (i = 0; i < iters; i++)
     {
         end = gethrtime();
 
         if ( start > end || start+delta < end)
             printf("%ld:\n  start %lld\n  end   %lld\n  diff  %lld\n",
                 i, start, end, (end-start));
 
         start=end;
     }
     exit(0);
}

Create the file called gethrtime_test.c and compile it

root@hostname# gcc -o gethrtime_test gethrtime_test.c

Then let it run.

root@hostname# ./gethrtime_test
1000000000 iterations

You should not see any message like

5750624:
  start 415551665195
  end   415150888326
  diff  -400776869
6387810:
  start 416494513021
  end   416509397658
  diff  14884637

Especially negative jumps should never happen.

If you see negative jumps, you can set the following paramters in a VMware virtual machines vmx file and reboot to avoid this:

VMware ESX 3.5

monitor_control.disable_tsc_offsetting=TRUE
monitor_control.disable_rdtscopt_bt=TRUE


VMware vSphere 4.x

timeTracker.forceMonotonicTTAT=TRUE


On VirtualBox I do not know any solution yet.

[ view entry ] ( 1171 views )   |  permalink  |  print article  |   ( 3 / 3240 )

<<First <Back | 1 | 2 | 3 | Next> Last>>