I've finally got around to trying xen (NetBSD-3.0BETA, xen 2.0.7) and
have run into this PR in DOM0.

First sign was xearth coredumping on login. Next was only "clicking"
from xmms, and I've had xpdf core, too.

A little debugging shows that the FPU state is not being correctly
saved or restored during "some" context switches. The following code
appears to exhibit the behaviour reliably:

marvin:ksh$ cat fp2.c
#include <assert.h>
#include <pthread.h>
#include <stdio.h>
#include <time.h>

void *
runloop(void *p)
{
         int i;
         double fi;

         i = 1;
         while (1) {
                 fi = i;
                 if ((int)fi != i) {
                         printf("%9ld %9d %9d\n", clock(), i, (int)fi);
                 }
                 i++;
         }
}

int
main(int argc, char **argv)
{
         pthread_t a, b;

         setlinebuf(stdout);
         assert(pthread_create(&a, NULL, &runloop, NULL) == 0);
         assert(pthread_create(&b, NULL, &runloop, NULL) == 0);
         assert(pthread_join(a, NULL) == 0);

         return 0;
}
marvin:ksh$ gcc -O -Wall -lpthread -o fp2 fp2.c
marvin:ksh$ ./fp2 | head
        19   2810714   4887424
        34   4782167 -2147483648
       152  29109559 -2147483648
       189  36046059 -2147483648
       217  43217401 -2147483648
       295  58190482  60223234
       334  65918432 -2147483648
       415  84428916 -2147483648
       478  93211664  97457195
       507 102074913 -2147483648

I've dug through NetBSD code (on the assumption xen is doing the
right thing), but I'm not 100% sure exactly what I'm looking for.
I guess this would be a nice bug to squash for 3.0 (assuming the
bug is in NetBSD).

Cheers,
--
Paul Ripke