xen-2.0 20040923 and previous: rpm crash in xenU

xen-2.0 20040923 and previous: rpm crash in xenU

[Peri Hankey]

Hello

I have previously mentioned a floating point exception in rpm which 
seemed at one point to be connected with block-device handling in xenU 
systems, as both problems occurred at the same time. As I now get only 
the rpm floating point exception (sporadically), I have examined it further:

... # strace rpm

[lots of strace output omitted]

gettimeofday({1096021305, 741150}, NULL) = 0
nanosleep({0, 20000000}, {1076798912, 1075195904}) = 0
gettimeofday({1096021305, 741150}, NULL) = 0
--- SIGFPE (Floating point exception) @ 0 (0) ---
+++ killed by SIGFPE +++

Does anyone else have problems of this kind? It may of course be a bug 
in rpm but I would then expect it to appear in xen0 as well. This did 
happen,but only in xen2.0-20040909 and xen2.0-20040910.

So the implication (to me) is that there is a problem which sometimes 
causes rpm to crash in gettimeofday, which did affect both xen0 and xenU 
   in xen2.0-20040909 and xen2.0-20040910, and which now only affects xenU.

Any ideas?







-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Ian Pratt]

I'd certainly recommend upgrading to a more recent xen2.0 release
and trying to repeat.

You're not sending large amounts of output from dom0 to a serial
line are you? I've observed this causing time (in all domains) to
be somewhat jerky, but this is to be expected as the serial line
is intended only for synchronous debug output.

Are dom0 and domU both on the same CPU? I presume you're using 2.6?

Ian

> I have previously mentioned a floating point exception in rpm which 
> seemed at one point to be connected with block-device handling in xenU 
> systems, as both problems occurred at the same time. As I now get only 
> the rpm floating point exception (sporadically), I have examined it further:
> 
> ... # strace rpm
> 
> [lots of strace output omitted]
> 
> gettimeofday({1096021305, 741150}, NULL) = 0
> nanosleep({0, 20000000}, {1076798912, 1075195904}) = 0
> gettimeofday({1096021305, 741150}, NULL) = 0
> --- SIGFPE (Floating point exception) @ 0 (0) ---
> +++ killed by SIGFPE +++
> 
> Does anyone else have problems of this kind? It may of course be a bug 
> in rpm but I would then expect it to appear in xen0 as well. This did 
> happen,but only in xen2.0-20040909 and xen2.0-20040910.
> 
> So the implication (to me) is that there is a problem which sometimes 
> causes rpm to crash in gettimeofday, which did affect both xen0 and xenU 
>    in xen2.0-20040909 and xen2.0-20040910, and which now only affects xenU.
> 
> Any ideas?


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Peri Hankey]

I am running the xen-2.0 dated 23 Sep 2004 (yesterday), on 2.6.8.1, 
single CPU, no serial line connected. Changes since my build didn't look 
very relevant ot me, but I'll rebuild and try again.

Thanks
Peri


Ian Pratt wrote:

>I'd certainly recommend upgrading to a more recent xen2.0 release
>and trying to repeat.
>
>You're not sending large amounts of output from dom0 to a serial
>line are you? I've observed this causing time (in all domains) to
>be somewhat jerky, but this is to be expected as the serial line
>is intended only for synchronous debug output.
>
>Are dom0 and domU both on the same CPU? I presume you're using 2.6?
>
>Ian
>
>  
>
>>I have previously mentioned a floating point exception in rpm which 
>>seemed at one point to be connected with block-device handling in xenU 
>>systems, as both problems occurred at the same time. As I now get only 
>>the rpm floating point exception (sporadically), I have examined it further:
>>
>>... # strace rpm
>>
>>[lots of strace output omitted]
>>
>>gettimeofday({1096021305, 741150}, NULL) = 0
>>nanosleep({0, 20000000}, {1076798912, 1075195904}) = 0
>>gettimeofday({1096021305, 741150}, NULL) = 0
>>--- SIGFPE (Floating point exception) @ 0 (0) ---
>>+++ killed by SIGFPE +++
>>
>>Does anyone else have problems of this kind? It may of course be a bug 
>>in rpm but I would then expect it to appear in xen0 as well. This did 
>>happen,but only in xen2.0-20040909 and xen2.0-20040910.
>>
>>So the implication (to me) is that there is a problem which sometimes 
>>causes rpm to crash in gettimeofday, which did affect both xen0 and xenU 
>>   in xen2.0-20040909 and xen2.0-20040910, and which now only affects xenU.
>>
>>Any ideas?
>>    
>>
>
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Flavio Leitner]

On Fri, Sep 24, 2004 at 01:53:32PM +0100, Peri Hankey wrote:
> I am running the xen-2.0 dated 23 Sep 2004 (yesterday), on 2.6.8.1, 
> single CPU, no serial line connected. Changes since my build didn't look 
> very relevant ot me, but I'll rebuild and try again.
> 

The same setup here, the same bug.

open("/usr/lib/rpm/rpmrc", O_RDONLY|O_LARGEFILE) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=12460, ...}) = 0
old_mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x404d7000
select(4, [3], NULL, NULL, {1, 0})      = 1 (in [3], left {1, 0})
gettimeofday({1096035236, 887402}, NULL) = 0
nanosleep({0, 20000000}, {1075431556, 1075070360}) = 0
gettimeofday({1096035236, 887402}, NULL) = 0
--- SIGFPE (Floating point exception) @ 0 (0) ---
+++ killed by SIGFPE +++

The xen0 and xenU is not running on the same processor.

 

-- 
Flávio Bruno Leitner <fbl@conectiva.com.br>
[ E74B 0BD0 5E05 C385 239E  531C BC17 D670 7FF0 A9E0 ]


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Ian Pratt]

> I have previously mentioned a floating point exception in rpm which 
> seemed at one point to be connected with block-device handling in xenU 
> systems, as both problems occurred at the same time. As I now get only 
> the rpm floating point exception (sporadically), I have examined it further:
>
> gettimeofday({1096021305, 741150}, NULL) = 0
> nanosleep({0, 20000000}, {1076798912, 1075195904}) = 0
> gettimeofday({1096021305, 741150}, NULL) = 0
> --- SIGFPE (Floating point exception) @ 0 (0) ---
> +++ killed by SIGFPE +++
> 

I've tried hard to reproduce this but failed. It might be worth
having a look at the rpm source to check that the nanosleep is
wrapped in a while loop, and where the presumed division by zero
is really coming from.

Since the strace prints the arguments that gettimeofday is passed
rather than returns, we can't really tell from the trace what
gettimeofday is actually returning. If there's a following call
in the trace using the same struct we can probably deduce it.

I've appended the test program I've used to debug this and other
time issues. You might want to run it on your system just to
check.

Thanks,
Ian


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

/**************************************************************************/


/* rpcc: get full 64-bit Pentium TSC value */
static __inline__ unsigned long long int rpcc(void) 
{
    unsigned int __h, __l;
    __asm__ __volatile__ ("rdtsc" :"=a" (__l), "=d" (__h));
    return (((unsigned long long)__h) << 32) + __l;
}


/*
 * find_cpu_speed:
 *   Interrogates /proc/cpuinfo for the processor clock speed.
 * 
 *   Returns: speed of processor in MHz, rounded down to nearest whole MHz.
 */
#define MAX_LINE_LEN 50
int find_cpu_speed(void)
{
    FILE *f;
    char s[MAX_LINE_LEN], *a, *b;
    int mhz = 2400;

    if ( (f = fopen("/proc/cpuinfo", "r")) == NULL ) goto out;

    while ( fgets(s, MAX_LINE_LEN, f) )
    {
        if ( strstr(s, "cpu MHz") )
        {
            /* Find the start of the speed value, and stop at the dec point. */
            if ( !(a=strpbrk(s,"0123456789")) || !(b=strpbrk(a,".")) ) break;
            *b = '\0';
            fclose(f);
            return(atoi(a));
        }
    }

 out:    
    fprintf(stderr, "find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume %d Mhz",mhz);
    return mhz;

}

int mhz;

int looper (int N)
{
    int i,a=12345;
    for(i=0;i<N;i++)
	a*=a;
    return a;
}


main()
{
    int stride;
    unsigned long long start=0,stop=0, last=0, now, gt_firsteventtime;
    unsigned long long xnow, xlast, skip;
    unsigned long long firsteventtime=0, lasteventtime, lastfirsteventtime = 0;
    struct timeval a,b;
    int count=0, okcount=0;

    /* Required in order to print intermediate results at fixed period. */
    mhz = find_cpu_speed();
    printf("CPU speed = %d MHz\n", mhz);


#define SLEEP (20*1000)

    while(1)
    {
	struct timespec z = { 0, SLEEP*1000 };

	gettimeofday(&a, NULL);
	while(nanosleep(&z,&z)); // loop until success
	gettimeofday(&b, NULL);

	last = (((long long)a.tv_sec) * 1000000) + a.tv_usec;
	now  = (((long long)b.tv_sec) * 1000000) + b.tv_usec;

	if ( now - last < SLEEP )
	{
	    printf("nanosleep(%dus): gtod %d\n",
		   SLEEP, now-last );
	}

	fprintf(stderr,".");	
    }



    gettimeofday(&a, NULL);
    xlast = rpcc();
    last = (((long long)a.tv_sec) * 1000000) + a.tv_usec;
    while(1)
    {
	struct timespec z = { 0, SLEEP*1000 };

	while(nanosleep(&z,&z)); // loop until success
	gettimeofday(&a, NULL);
	xnow = rpcc();
        now = (((long long)a.tv_sec) * 1000000) + a.tv_usec;

	if ( now - last < SLEEP )
	{
	    printf("nanosleep(%d): gtod %d  rpcc %d\n",
		   SLEEP, now-last, (xnow-xlast)/mhz );
	}

	last = now;
	xlast = xnow;

	if((count++ % 64) == 0)fprintf(stderr,".");
    }


    start = rpcc();
    while(1)
    {
	gettimeofday(&a, NULL);
	xnow = rpcc();

	if(xnow < xlast)
	    printf("** %lld %lld **\n", xnow, xlast);

        now = (((long long)a.tv_sec) * 1000000) + a.tv_usec;

	if(now<last)
	{
	    printf("backwards!\n");
	    exit(-1);
	}

	if(now==last) 
	{
	    count++;
	    lasteventtime = rpcc();
	    if( firsteventtime == 0 ) 
	    {
		firsteventtime = lasteventtime;
		gt_firsteventtime = now;
		skip = (xnow-xlast)/mhz;
	    }

	}

	if(now>last)
	{
	    if(count>5)
	    {
		printf("[%lld.%lld %lld] duplicates= % 5d (% 5lldus)\t prev OK= % 6d\t fe %lldus (d=%lldus) skip = %lld\n",
		       gt_firsteventtime/1000000,gt_firsteventtime%1000000,
		       firsteventtime,
		       count, (lasteventtime-firsteventtime)/mhz,
		       okcount,(firsteventtime-start)/mhz,
		       (firsteventtime-lastfirsteventtime)/mhz,
		       skip);
		okcount = 0;
		lastfirsteventtime = firsteventtime;
	    }
	    count = 0;
	    firsteventtime = 0;
	    okcount++;
	}
	
	last = now;
	xlast = xnow;
    }

   
#if 0
    while(1)
    {
int i;
        gettimeofday(&a, NULL);
for(i=0;i<10000;i++);
	gettimeofday(&b, NULL);
        start = (((long long)a.tv_sec) * 1000000) + a.tv_usec;
	stop  = (((long long)b.tv_sec) * 1000000) + b.tv_usec;

        if(1||stop<start) printf("crap : %ld\n",stop-start);
    }
	
    while(1)
    {
	gettimeofday(&a, NULL);
	start = (((long long)a.tv_sec) * 1000000) + a.tv_usec;

	looper(1000000);

	gettimeofday(&a, NULL);
	stop = (((long long)a.tv_sec) * 1000000) + a.tv_usec;

	printf("%ld\n",stop-start);

    }


#endif
 



}


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Peri Hankey]

Thanks for sending the test - one point of interest is that my 
/proc/cpuinfo doesn't match your expectations - presumably an AMD 
Athlon(tm) XP 2400+ is running at 2400MHz. The main point however is 
that the results are indeed different in the two domains:

----------------  xen0 ------------------------

[me@xen0 testing]$ ./time-test
find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
MhzCPU speed = 2400 MHz
...........................................................................................................
...........................................................................................................
... (lots of dots)

[me@xen0 testing]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(tm) XP 2400+
stepping        : 1
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : yes
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu msr pae mce cx8 apic sep mca cmov pat pse36 mmx 
sse syscall mmxext 3dnowext 3dnow
bogomips        : 4010.80

----------------  xenU ------------------------

[me@xenU testing]$ ./time-test
find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
MhzCPU speed = 2400 MHz
nanosleep(20000us): gtod 0
.nanosleep(20000us): gtod 0
.nanosleep(20000us): gtod 0
.nanosleep(20000us): gtod 0
.nanosleep(20000us): gtod 0
.nanosleep(20000us): gtod 0
.nanosleep(20000us): gtod 0
.nanosleep(20000us): gtod 0
... (lots of gtod 0s)

[me@xenU testing]$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(tm) XP 2400+
stepping        : 1
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : yes
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu msr pae mce cx8 apic sep mca cmov pat pse36 mmx 
sse syscall mmxext 3dnowext 3dnow
bogomips        : 3263.69

I hope this will help nail it down - I notice also that the bogomips 
measure is different. No time for more just now - but I have a more 
general question about lvm2 cows and snapshots, which I will put in a 
separate message. 'A snapshot is not a cow' as the liftman said to Babar 
the Elephant. In fact the problem is that snapshots hold on to each 
other's tails.

Thanks for your help.
Peri


Ian Pratt wrote:

>>I have previously mentioned a floating point exception in rpm which 
>>seemed at one point to be connected with block-device handling in xenU 
>>systems, as both problems occurred at the same time. As I now get only 
>>the rpm floating point exception (sporadically), I have examined it further:
>>
>>gettimeofday({1096021305, 741150}, NULL) = 0
>>nanosleep({0, 20000000}, {1076798912, 1075195904}) = 0
>>gettimeofday({1096021305, 741150}, NULL) = 0
>>--- SIGFPE (Floating point exception) @ 0 (0) ---
>>+++ killed by SIGFPE +++
>>
>>    
>>
>
>I've tried hard to reproduce this but failed. It might be worth
>having a look at the rpm source to check that the nanosleep is
>wrapped in a while loop, and where the presumed division by zero
>is really coming from.
>
>Since the strace prints the arguments that gettimeofday is passed
>rather than returns, we can't really tell from the trace what
>gettimeofday is actually returning. If there's a following call
>in the trace using the same struct we can probably deduce it.
>
>I've appended the test program I've used to debug this and other
>time issues. You might want to run it on your system just to
>check.
>
>Thanks,
>Ian
>
>
>#include <stdlib.h>
>#include <stdio.h>
>#include <sys/time.h>
>#include <time.h>
>
>/**************************************************************************/
>
>
>/* rpcc: get full 64-bit Pentium TSC value */
>static __inline__ unsigned long long int rpcc(void) 
>{
>    unsigned int __h, __l;
>    __asm__ __volatile__ ("rdtsc" :"=a" (__l), "=d" (__h));
>    return (((unsigned long long)__h) << 32) + __l;
>}
>
>
>/*
> * find_cpu_speed:
> *   Interrogates /proc/cpuinfo for the processor clock speed.
> * 
> *   Returns: speed of processor in MHz, rounded down to nearest whole MHz.
> */
>#define MAX_LINE_LEN 50
>int find_cpu_speed(void)
>{
>    FILE *f;
>    char s[MAX_LINE_LEN], *a, *b;
>    int mhz = 2400;
>
>    if ( (f = fopen("/proc/cpuinfo", "r")) == NULL ) goto out;
>
>    while ( fgets(s, MAX_LINE_LEN, f) )
>    {
>        if ( strstr(s, "cpu MHz") )
>        {
>            /* Find the start of the speed value, and stop at the dec point. */
>            if ( !(a=strpbrk(s,"0123456789")) || !(b=strpbrk(a,".")) ) break;
>            *b = '\0';
>            fclose(f);
>            return(atoi(a));
>        }
>    }
>
> out:    
>    fprintf(stderr, "find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume %d Mhz",mhz);
>    return mhz;
>
>}
>
>int mhz;
>
>int looper (int N)
>{
>    int i,a=12345;
>    for(i=0;i<N;i++)
>	a*=a;
>    return a;
>}
>
>
>main()
>{
>    int stride;
>    unsigned long long start=0,stop=0, last=0, now, gt_firsteventtime;
>    unsigned long long xnow, xlast, skip;
>    unsigned long long firsteventtime=0, lasteventtime, lastfirsteventtime = 0;
>    struct timeval a,b;
>    int count=0, okcount=0;
>
>    /* Required in order to print intermediate results at fixed period. */
>    mhz = find_cpu_speed();
>    printf("CPU speed = %d MHz\n", mhz);
>
>
>#define SLEEP (20*1000)
>
>    while(1)
>    {
>	struct timespec z = { 0, SLEEP*1000 };
>
>	gettimeofday(&a, NULL);
>	while(nanosleep(&z,&z)); // loop until success
>	gettimeofday(&b, NULL);
>
>	last = (((long long)a.tv_sec) * 1000000) + a.tv_usec;
>	now  = (((long long)b.tv_sec) * 1000000) + b.tv_usec;
>
>	if ( now - last < SLEEP )
>	{
>	    printf("nanosleep(%dus): gtod %d\n",
>		   SLEEP, now-last );
>	}
>
>	fprintf(stderr,".");	
>    }
>
>
>
>    gettimeofday(&a, NULL);
>    xlast = rpcc();
>    last = (((long long)a.tv_sec) * 1000000) + a.tv_usec;
>    while(1)
>    {
>	struct timespec z = { 0, SLEEP*1000 };
>
>	while(nanosleep(&z,&z)); // loop until success
>	gettimeofday(&a, NULL);
>	xnow = rpcc();
>        now = (((long long)a.tv_sec) * 1000000) + a.tv_usec;
>
>	if ( now - last < SLEEP )
>	{
>	    printf("nanosleep(%d): gtod %d  rpcc %d\n",
>		   SLEEP, now-last, (xnow-xlast)/mhz );
>	}
>
>	last = now;
>	xlast = xnow;
>
>	if((count++ % 64) == 0)fprintf(stderr,".");
>    }
>
>
>    start = rpcc();
>    while(1)
>    {
>	gettimeofday(&a, NULL);
>	xnow = rpcc();
>
>	if(xnow < xlast)
>	    printf("** %lld %lld **\n", xnow, xlast);
>
>        now = (((long long)a.tv_sec) * 1000000) + a.tv_usec;
>
>	if(now<last)
>	{
>	    printf("backwards!\n");
>	    exit(-1);
>	}
>
>	if(now==last) 
>	{
>	    count++;
>	    lasteventtime = rpcc();
>	    if( firsteventtime == 0 ) 
>	    {
>		firsteventtime = lasteventtime;
>		gt_firsteventtime = now;
>		skip = (xnow-xlast)/mhz;
>	    }
>
>	}
>
>	if(now>last)
>	{
>	    if(count>5)
>	    {
>		printf("[%lld.%lld %lld] duplicates= % 5d (% 5lldus)\t prev OK= % 6d\t fe %lldus (d=%lldus) skip = %lld\n",
>		       gt_firsteventtime/1000000,gt_firsteventtime%1000000,
>		       firsteventtime,
>		       count, (lasteventtime-firsteventtime)/mhz,
>		       okcount,(firsteventtime-start)/mhz,
>		       (firsteventtime-lastfirsteventtime)/mhz,
>		       skip);
>		okcount = 0;
>		lastfirsteventtime = firsteventtime;
>	    }
>	    count = 0;
>	    firsteventtime = 0;
>	    okcount++;
>	}
>	
>	last = now;
>	xlast = xnow;
>    }
>
>   
>#if 0
>    while(1)
>    {
>int i;
>        gettimeofday(&a, NULL);
>for(i=0;i<10000;i++);
>	gettimeofday(&b, NULL);
>        start = (((long long)a.tv_sec) * 1000000) + a.tv_usec;
>	stop  = (((long long)b.tv_sec) * 1000000) + b.tv_usec;
>
>        if(1||stop<start) printf("crap : %ld\n",stop-start);
>    }
>	
>    while(1)
>    {
>	gettimeofday(&a, NULL);
>	start = (((long long)a.tv_sec) * 1000000) + a.tv_usec;
>
>	looper(1000000);
>
>	gettimeofday(&a, NULL);
>	stop = (((long long)a.tv_sec) * 1000000) + a.tv_usec;
>
>	printf("%ld\n",stop-start);
>
>    }
>
>
>#endif
> 
>
>
>
>}
>
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Ian Pratt]

> Thanks for sending the test - one point of interest is that my 
> /proc/cpuinfo doesn't match your expectations - presumably an AMD 
> Athlon(tm) XP 2400+ is running at 2400MHz. The main point however is 
> that the results are indeed different in the two domains:

> [me@xenU testing]$ ./time-test
> find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
> MhzCPU speed = 2400 MHz
> nanosleep(20000us): gtod 0
> .nanosleep(20000us): gtod 0
> .nanosleep(20000us): gtod 0

Can you try a newer version of Xen/Linux. There's been a tsc flag
change that may influence this.

It may be an Athlon-only bug, as we can't reproduce on Opteron or
Xeon.

Thanks,
Ian


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Flavio Leitner]

On Sat, Sep 25, 2004 at 07:48:44PM +0100, Peri Hankey wrote:
> ----------------  xen0 ------------------------
> [me@xen0 testing]$ ./time-test
> find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
> MhzCPU speed = 2400 MHz
> ...........................................................................................................
> ...........................................................................................................
> ... (lots of dots)
> ----------------  xenU ------------------------
> [me@xenU testing]$ ./time-test
> find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
> MhzCPU speed = 2400 MHz
> nanosleep(20000us): gtod 0
> .nanosleep(20000us): gtod 0
> .nanosleep(20000us): gtod 0
> .nanosleep(20000us): gtod 0

Running on xen0 or xenU doesn't make any difference, just lots of dots 
and that parser error. That's funny because even rpm can't reproduce that
bug until now.


-- 
Flávio Bruno Leitner <fbl@conectiva.com.br>
[ E74B 0BD0 5E05 C385 239E  531C BC17 D670 7FF0 A9E0 ]


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Ian Pratt]

> On Sat, Sep 25, 2004 at 07:48:44PM +0100, Peri Hankey wrote:
> > ----------------  xen0 ------------------------
> > [me@xen0 testing]$ ./time-test
> > find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
> > MhzCPU speed = 2400 MHz
> > ...........................................................................................................
> > ...........................................................................................................
> > ... (lots of dots)
> > ----------------  xenU ------------------------
> > [me@xenU testing]$ ./time-test
> > find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
> > MhzCPU speed = 2400 MHz
> > nanosleep(20000us): gtod 0
> > .nanosleep(20000us): gtod 0
> > .nanosleep(20000us): gtod 0
> > .nanosleep(20000us): gtod 0
> 
> Running on xen0 or xenU doesn't make any difference, just lots
> of dots 

That's the behaviour we see on all of our machines i.e. nanosleep
works fine. I think Peri's problem may be Athlon related,

> and that parser error. 

The find_cpu_speed printf shouldn't happen any more -- we no
longer clear the TSC bit in the set of features the CPU reports,
hence there should be a 'MHz' line in /proc/cpuinfo


Ian




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Flavio Leitner]

On Mon, Sep 27, 2004 at 05:21:52PM +0100, Ian Pratt wrote:
> > On Sat, Sep 25, 2004 at 07:48:44PM +0100, Peri Hankey wrote:
> > Running on xen0 or xenU doesn't make any difference, just lots
> > of dots 
> 
> That's the behaviour we see on all of our machines i.e. nanosleep
> works fine. I think Peri's problem may be Athlon related,

Just remember that test machine show the same problem before and 
it's a PentiumIII. 

I'll try to reproduce again tomorrow. 

-- 
Flávio Bruno Leitner <fbl@conectiva.com.br>
[ E74B 0BD0 5E05 C385 239E  531C BC17 D670 7FF0 A9E0 ]


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Peri Hankey]

The timer question seems to involve more than just the processor type:

------------todays build: xen0 running Mandrake 10: OK
[me@a4 testing]$ ./time-test
CPU speed = 2008 MHz
...............................................

[me@a4 testing]$ rpm -qa
mktemp-1.5-11mdk
libpwdb0-0.61.2-3mdk
make-3.80-5mdk
gettext-base-0.13.1-1mdk
ifplugd-0.21b-1mdk
libgdbm2-1.8.0-24mdk
...

-------------todays build: a41: xenU running Mandrake 10.0: FAIL
[me@a41 testing]$ ./time-test
CPU speed = 2008 MHz
nanosleep(20000us): gtod 0
.nanosleep(20000us): gtod 0
.nanosleep(20000us): gtod 0
.nanosleep(20000us): gtod 0

[me@a41 testing]$ rpm -qa
Floating point exception (core dumped)
[peri@a41 testing]$

--------------- todays build: a37: xenU running PLD Linux: OK
[me@a37 testing]$ ./time-test
CPU speed = 2008 MHz
............................................................

[peri@a37 testing]$ rpm -qa
FHS-2.3-1
basesystem-1.99-2
acl-2.2.22-2
cracklib-2.7-18
cracklib-dicts-2.7-18
make-3.80-5
pam-0.77.3-11
...

I don't think I've yet seen the rpm crash on the PLD Linux distribution. 
So it looks like a combination of Athlon with some subtle difference in 
the way the libraries are compiled.

But Flavio, are you saying that you have the rpm problem that I have but 
don't see the same test results as me?

And by the way, I was very interested to hear about your conectiva rpm 
for xen - is it downloadable?

Thanks to all
Peri

Ian Pratt wrote:

>>On Sat, Sep 25, 2004 at 07:48:44PM +0100, Peri Hankey wrote:
>>    
>>
>>>----------------  xen0 ------------------------
>>>[me@xen0 testing]$ ./time-test
>>>find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
>>>MhzCPU speed = 2400 MHz
>>>...........................................................................................................
>>>...........................................................................................................
>>>... (lots of dots)
>>>----------------  xenU ------------------------
>>>[me@xenU testing]$ ./time-test
>>>find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
>>>MhzCPU speed = 2400 MHz
>>>nanosleep(20000us): gtod 0
>>>.nanosleep(20000us): gtod 0
>>>.nanosleep(20000us): gtod 0
>>>.nanosleep(20000us): gtod 0
>>>      
>>>
>>Running on xen0 or xenU doesn't make any difference, just lots
>>of dots 
>>    
>>
>
>That's the behaviour we see on all of our machines i.e. nanosleep
>works fine. I think Peri's problem may be Athlon related,
>
>  
>
>>and that parser error. 
>>    
>>
>
>The find_cpu_speed printf shouldn't happen any more -- we no
>longer clear the TSC bit in the set of features the CPU reports,
>hence there should be a 'MHz' line in /proc/cpuinfo
>
>
>Ian
>
>
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Flavio Leitner]

On Mon, Sep 27, 2004 at 06:04:31PM +0100, Peri Hankey wrote:
> But Flavio, are you saying that you have the rpm problem that I have but 
> don't see the same test results as me?

Now I can't reproduce rpm segfault as before, but tomorrow I'll try again
with more time. Probably the reason I can't reproduce it anymore is 
the same reason that the test program didn't fail. 


> And by the way, I was very interested to hear about your conectiva rpm 
> for xen - is it downloadable?

Yes, should be in one mirror with our snapshot. 
The latest is xen-2.0-68430cl.i686.rpm.


-- 
Flávio Bruno Leitner <fbl@conectiva.com.br>
[ E74B 0BD0 5E05 C385 239E  531C BC17 D670 7FF0 A9E0 ]


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Peri Hankey]

Is there any kind of workaround for this nanosleep problem?
-- Peri

Ian Pratt wrote:

>>On Sat, Sep 25, 2004 at 07:48:44PM +0100, Peri Hankey wrote:
>>    
>>
>>>----------------  xen0 ------------------------
>>>[me@xen0 testing]$ ./time-test
>>>find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
>>>MhzCPU speed = 2400 MHz
>>>...........................................................................................................
>>>...........................................................................................................
>>>... (lots of dots)
>>>----------------  xenU ------------------------
>>>[me@xenU testing]$ ./time-test
>>>find_cpu_speed: error parsing /proc/cpuinfo for cpu MHz. Assume 2400 
>>>MhzCPU speed = 2400 MHz
>>>nanosleep(20000us): gtod 0
>>>.nanosleep(20000us): gtod 0
>>>.nanosleep(20000us): gtod 0
>>>.nanosleep(20000us): gtod 0
>>>      
>>>
>>Running on xen0 or xenU doesn't make any difference, just lots
>>of dots 
>>    
>>
>
>That's the behaviour we see on all of our machines i.e. nanosleep
>works fine. I think Peri's problem may be Athlon related,
>
>  
>
>>and that parser error. 
>>    
>>
>
>The find_cpu_speed printf shouldn't happen any more -- we no
>longer clear the TSC bit in the set of features the CPU reports,
>hence there should be a 'MHz' line in /proc/cpuinfo
>
>
>Ian
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>who ports your project to Linux PPC the best. Sponsored by IBM.
>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/xen-devel
>
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Ian Pratt]

> Is there any kind of workaround for this nanosleep problem?

It's a bug, and one that's probably trivial to fix if we can pin
down the combination of CPU and libraries etc that provoke it.

Are you using the latest unstable tree? Does my test program
still indicate a problem for you? If so, please post the output
of /proc/cpuinfo, and information about your distribution and
libraries.

Like the only other pending bug (the network panic bug) it seems
only to effect a minority of users, and we can't seem to
reproduce it locally. Until we get more information I'm afraid
there's not a lot we can do beyond simply reviewing the code.

Thanks,
Ian


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php

Re: xen-2.0 20040923 and previous: rpm crash in xenU

[Peri Hankey]

Here's a summary of results so far. I wasn't able to try your test on 
the fedora xenU system as it was a minimal install - I was planning to 
install extras as needed using poldek (like yum or urpmi, from PLD, 
minimal external dependencies, very handy - but it relies on rpm to do 
the actual installs).

using xen-20040927 (changelog in today's unstable doesn't suggest there 
would be much difference):

xen0 (mandrake 10.0 - 2.6.8.1-xen0)    time-test OK      rpm: OK             /lib/libc.so.6 -> libc-2.3.3.so

xenU (mandrake 10.0 - 2.6.8.1-xenU)    time-test FAIL    rpm: CRASH          /lib/libc.so.6 -> libc-2.3.3.so
xenU (fedora-2      - 2.6.8.1-xenU)    time-test ????    rpm: CRASH          /lib/libc.so.6 -> libc-2.3.3.so 
xenU (PLD Linux     - 2.6.8.1-xenU)    time-test OK      rpm: OK             /lib/libc.so.6 -> libc-2.3.3.so
xenU (Debian Sarge  - 2.6.8.1-xenU)    time-test OK      rpm: NOT AVAILABLE  /lib/libc.so.6 -> libc-2.3.2.so  

No very clear pattern - on the face of it it looks as if the same 
library version produces different results. I suppose that could be a 
result of different compiler flags and optimisation levels.

I don't know if that helps much.

-- Peri

Ian Pratt wrote:

>>Is there any kind of workaround for this nanosleep problem?
>>    
>>
>
>It's a bug, and one that's probably trivial to fix if we can pin
>down the combination of CPU and libraries etc that provoke it.
>
>Are you using the latest unstable tree? Does my test program
>still indicate a problem for you? If so, please post the output
>of /proc/cpuinfo, and information about your distribution and
>libraries.
>
>Like the only other pending bug (the network panic bug) it seems
>only to effect a minority of users, and we can't seem to
>reproduce it locally. Until we get more information I'm afraid
>there's not a lot we can do beyond simply reviewing the code.
>
>Thanks,
>Ian
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>who ports your project to Linux PPC the best. Sponsored by IBM.
>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/xen-devel
>
>
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php