Re: [Xen-devel] xen-2.0 20040923 and previous: rpm crash in xenU - Peri Hankey - com.xensource.lists.xen-devel

15 messages in com.xensource.lists.xen-develRe: [Xen-devel] xen-2.0 20040923 and ...

From	Sent On	Attachments
Peri Hankey	24 Sep 2004 04:05
Ian Pratt	24 Sep 2004 05:40
Peri Hankey	24 Sep 2004 05:53
Flavio Leitner	24 Sep 2004 06:22
Ian Pratt	25 Sep 2004 03:33
Peri Hankey	25 Sep 2004 11:48
Ian Pratt	27 Sep 2004 08:53
Flavio Leitner	27 Sep 2004 09:17
Ian Pratt	27 Sep 2004 09:21
Flavio Leitner	27 Sep 2004 09:27
Peri Hankey	27 Sep 2004 10:04
Flavio Leitner	27 Sep 2004 10:17
Peri Hankey	28 Sep 2004 03:33
Ian Pratt	28 Sep 2004 05:39
Peri Hankey	28 Sep 2004 06:57

Subject:	Re: [Xen-devel] xen-2.0 20040923 and previous: rpm crash in xenU
From:	Peri Hankey (mp...@thegreen.co.uk)
Date:	09/28/2004 06:57:37 AM
List:	com.xensource.lists.xen-devel

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.