From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46752) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqOUB-0005MX-NG for qemu-devel@nongnu.org; Tue, 10 Dec 2013 09:40:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VqOU4-0007pP-A0 for qemu-devel@nongnu.org; Tue, 10 Dec 2013 09:40:31 -0500 Received: from mail-pd0-f177.google.com ([209.85.192.177]:60442) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VqOU4-0007pA-46 for qemu-devel@nongnu.org; Tue, 10 Dec 2013 09:40:24 -0500 Received: by mail-pd0-f177.google.com with SMTP id q10so7408272pdj.22 for ; Tue, 10 Dec 2013 06:40:23 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <52A72413.9090901@ilande.co.uk> References: <52A72413.9090901@ilande.co.uk> From: Peter Maydell Date: Tue, 10 Dec 2013 14:40:02 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] PPC: Regression booting NetBSD List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland Cc: "qemu-ppc@nongnu.org" , qemu-devel On 10 December 2013 14:24, Mark Cave-Ayland wrote: > I've been running my OpenBIOS test suite on a recent git (commit a1d22a) and > have encountered a QEMU process segfault in 2 out of 3 of my NetBSD 5.0.2 > boot attempts. Does anyone have an idea what could be causing this? Other > OSs don't seem to be affected. > > > build@kentang:~/rel-qemu-git/bin$ ./qemu-system-ppc -cdrom > /home/build/src/qemu/image/ppc/macppccd-5.0.2.iso -boot d -bios > /home/build/src/openbios/openbios-git/openbios-devel/obj-ppc/openbios-qemu.elf.nostrip > qemu: fatal: Trying to execute code outside RAM or ROM at 0x0a64696c > > NIP 0a64696c LR 0a64696d CTR 00000000 XER 00000000 > MSR 00009030 HID0 00000000 HF 00000000 idx 1 [etc] This isn't a QEMU process segfault -- it's just that the guest has attempted to jump to a memory location which is neither RAM nor ROM (you can see the guest NIP is the same address the message prints). This is probably because something has gone wrong some distance further back in guest execution; identifying exactly what that was might require some tedious debugging :-) thanks -- PMM