From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IjWiM-0001vf-SE for qemu-devel@nongnu.org; Sun, 21 Oct 2007 05:03:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IjWiM-0001ur-BM for qemu-devel@nongnu.org; Sun, 21 Oct 2007 05:03:18 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IjWiL-0001uW-LE for qemu-devel@nongnu.org; Sun, 21 Oct 2007 05:03:17 -0400 Received: from honiara.magic.fr ([195.154.193.36]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IjWiK-00046l-T1 for qemu-devel@nongnu.org; Sun, 21 Oct 2007 05:03:17 -0400 Subject: Re: [Qemu-devel] I got a kernel booted under qemu-system-ppc ! From: "J. Mayer" In-Reply-To: <471A77D9.8030008@aurel32.net> References: <200710181912.57825.rob@landley.net> <20071019151916.GA17481@hall.aurel32.net> <1192815587.11576.32.camel@jma4.dev.netgem.com> <20071019193925.GA30604@hall.aurel32.net> <471A0F52.9050206@aurel32.net> <471A1585.1060206@aurel32.net> <471A77D9.8030008@aurel32.net> Content-Type: text/plain; charset=ISO-8859-15 Date: Sun, 21 Oct 2007 11:01:59 +0200 Message-Id: <1192957319.16781.45.camel@rapid> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: qemu-devel@nongnu.org, Milton Miller On Sat, 2007-10-20 at 23:49 +0200, Aurelien Jarno wrote: > Aurelien Jarno a =E9crit : > > Aurelien Jarno a =E9crit : > >> Aurelien Jarno a =E9crit : > >> > >>> I have used QEMU CVS with a Debian Sid image. It basically works, I= am > >>> even able to login via SSH, but I have noticed two problems: > >>> > >>> - Some process hang, stay into "D" state and become unkillable. It = seems > >>> it can happen to all processes, but it is always reproducible wit= h > >>> uptime or top. I still don't know if it is a problem of the kerne= l or > >>> if it comes from the emulation. > >> This problem arise when using floating point instructions. It can be > >> easily triggered by running the following testcase: > >> > >> #include > >> > >> int main() > >> { > >> double a =3D 1.34; > >> printf("%.2f", a); > >> return 0; > >> } > >> > >=20 > > This is actually not enough to trigger the bug. The testcase works if > > the bug has already been trigger in another process before, for examp= le > > uptime. > >=20 >=20 > I finally found a testcase that trigger the bug in any case: >=20 > #include >=20 > int main() > { > printf("%d %f\n", 7, 0.40); > return 0; > } >=20 > The bug could also be trigger with sprintf(), so this is not directly > related to I/O. It happens when printing an integer followed by a float= , > even when the two are printed in two different calls to printf(). OK, thanks. I'll do test with this program. It seems that floats are OK when running 2.4 kernels, it maybe a difference in recent glibc. I'll try to investigate more about it. --=20 J. Mayer Never organized