From owner-freebsd-emulation@FreeBSD.ORG Mon Feb 23 21:22:58 2009 Return-Path: Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 197FF1065691; Mon, 23 Feb 2009 21:22:58 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id D6E288FC14; Mon, 23 Feb 2009 21:22:56 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 770EA1E00260; Mon, 23 Feb 2009 22:22:55 +0100 (CET) Received: from saturn.kn-bremen.de (noident@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.14.2/8.13.8) with ESMTP id n1NLJXEl079856; Mon, 23 Feb 2009 22:19:33 +0100 (CET) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.14.2/8.13.6/Submit) id n1NLJXei079855; Mon, 23 Feb 2009 22:19:33 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Mon, 23 Feb 2009 22:19:33 +0100 To: Gary Jennejohn Message-ID: <20090223211933.GA79361@saturn.kn-bremen.de> Mail-Followup-To: Gary Jennejohn , freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org References: <20090222013747.GA21709@saturn.kn-bremen.de> <20090223154724.7d687b13@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090223154724.7d687b13@ernst.jennejohn.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: testing qemu svn r6636 on FreeBSD; future of qemu on FreeBSD... X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:22:59 -0000 On Mon, Feb 23, 2009 at 03:47:24PM +0100, Gary Jennejohn wrote: > On Sun, 22 Feb 2009 02:37:47 +0100 > Juergen Lock wrote: > > > been experimental and you should use raw images if you want reliability; > > raw is also usually faster) - apart from these two issues this snapshot > > is looking pretty good in my (limited) testing so far; you are encouraged > > to test it with your various guests that you have lying around, if it > > works for you as well maybe we can indeed update the FreeBSD qemu-devel > > port again before the next official qemu release gets cut... > > > > Well, I applied the patches and installed qemu. > > I tried installing openSUSELinux 10.3 because I had a DVD laying around. > > I used a 150GB raw image created using qemu-img. I did not use kqemu. > I started qemu with this command line: > > qemu -boot d -cdrom /dev/acd0 -hda linux.img -localtime -m 1G > > Note I have an AMD64 X2 with 4GB of RAM installed running 8-current. > > It got up to the point where it actually started the install and then > croaked with SIGSEGV, I think it was. The error message flashed by > rather quickly. > > That means that I was able to partition the disks and specify some > non-standard packages. It managed to create and format the disk > partitions and figure out from the DVD which packages to install. > > Not too bad, I suppose. A SIGSEGV, hmm. What I do see sometimes especially without kqemu is guest failures related to various kinds of timeouts, i.e. guests not expecting running as slowly... tho a SIGSEGV is probably something different. You could try a few things: a) the same with kqemu (userland), in case its a tcg bug (or indeed a timeout; remember to rebuild qemu in case you built it without the kqemu knob enabled or otherwise kqemu won't get used), and also b) another time with -kernel-kqemu in case its a tcg bug affecting guest kernel code (altho of course in both cases kqemu can cause its own kind of failures, even more so with amd64 guests...) c) try the same with the original qemu-devel port and also with qemu 0.9.1 (the qemu port), in case its a regression (possibly caused by the tcg conversion?) d) see if you can enable coredumps in the guest in order to find out more about your particular failure. Oh and if you do any of these you may want to also Cc the qemu list with your findings, they are probably interested as well... Thanx, Juergen