Subject: Re: port-xen/30977: FPU troubles
To: None <port-xen-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: Paul Ripke <stix@stix.id.au>
List: netbsd-bugs
Date: 11/22/2005 21:22:02
The following reply was made to PR port-xen/30977; it has been noted by GNATS.

From: Paul Ripke <stix@stix.id.au>
To: gnats-bugs@netbsd.org
Cc: cube@cubidou.net, port-xen@netbsd.org
Subject: Re: port-xen/30977: FPU troubles
Date: Wed, 23 Nov 2005 08:15:04 +1100

 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