From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LcPEc-0002fd-EF
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 14:15:58 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LcPEa-0002di-Ef
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 14:15:57 -0500
Received: from [199.232.76.173] (port=39909 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LcPEa-0002dS-8t
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 14:15:56 -0500
Received: from mout1.freenet.de ([195.4.92.91]:52268)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <gary.jennejohn@freenet.de>) id 1LcPEZ-0001EW-Sm
	for qemu-devel@nongnu.org; Wed, 25 Feb 2009 14:15:56 -0500
Date: Wed, 25 Feb 2009 20:15:50 +0100
From: Gary Jennejohn <gary.jennejohn@freenet.de>
Message-ID: <20090225201550.3d3032b5@ernst.jennejohn.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: testing qemu svn r6636 on FreeBSD;
	future of qemu on FreeBSD...
Reply-To: gary.jennejohn@freenet.de, qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Juergen Lock <nox@jelal.kn-bremen.de>
Cc: freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, qemu-devel@nongnu.org

On Mon, 23 Feb 2009 22:19:33 +0100
Juergen Lock <nox@jelal.kn-bremen.de> wrote:

> 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...)
>  

Neither of these work.  The only way I can get past loading the kernel
is with -no-kqemu.

I still see the segmentation fault in Yast.call.  Now I know that it's
in line 486, if that's of any interest.

Sorry, I'm not going to invest any more time in this.

---
Gary Jennejohn