From owner-freebsd-sparc64@freebsd.org Thu Apr 14 13:42:10 2016 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7B79B0FA9A for ; Thu, 14 Apr 2016 13:42:10 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (chuckie.co.uk [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B9251DF7 for ; Thu, 14 Apr 2016 13:42:09 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from host81-154-31-210.range81-154.btcentralplus.com ([81.154.31.210] helo=[192.168.1.65]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1aqhWx-0000js-Ox for freebsd-sparc64@freebsd.org; Thu, 14 Apr 2016 14:42:01 +0100 To: "freebsd-sparc64@freebsd.org" References: <570CAFD6.2010004@ilande.co.uk> <570CBA7E.2080509@ilande.co.uk> <570CEF42.9050400@ilande.co.uk> From: Mark Cave-Ayland Message-ID: <570F9E05.40703@ilande.co.uk> Date: Thu, 14 Apr 2016 14:41:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 In-Reply-To: <570CEF42.9050400@ilande.co.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 81.154.31.210 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on s16892447.onlinehome-server.info X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=ham version=3.3.2 Subject: Re: qemu-system-sparc64: entering the debugger X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 13:42:10 -0000 On 12/04/16 13:51, Mark Cave-Ayland wrote: > On 12/04/16 10:06, Mark Cave-Ayland wrote: > >>> So it looks like something has already gone wrong simply trying to dump >>> the process map. Fortunately the number of QEMU translation blocks >>> between the output of the "ps/m" header and the "KDB reentering" is >>> quite small so I've uploaded it to >>> https://www.ilande.co.uk/tmp/qemu/freebsd-tb.txt. >>> >>> Can anyone have a quick look at the link above and give me an idea as to >>> roughly what the code is doing here? > > It seems that if you boot directly into ddb and use ps/m then you end up > with a NULL pointer dereference: > > FreeBSD/sparc64 bootstrap loader, Revision 1.0 > (mca@freebsd, Thu Sep 24 00:27:19 BST 2015) > bootpath="/pci@1fe,0/pci-ata@5/ide1@8200/cdrom@0:a" > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0xd893c0+0x20ffd8 syms=[0x8+0xdc578+0x8+0xcb349] > \ > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel] in 9 seconds... > > Type '?' for a list of commands, 'help' for more detailed help. > OK boot -d > Booting... > jumping to kernel entry at 0xc00b0000. > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > KDB: enter: Boot flags requested debugger > [ thread pid 0 tid 0 ] > Stopped at 0xc0630b00 > db> ps/m > pid ppid pgrp uid state wmesg wchan cmd > 0 0 0 0KDB: reentering > KDB: stack backtrace: > (null)() at 0xc063105c > (null)() at 0xc09e193c > (null)() at 0xc00b1078 > (null)() at 0xc011bb1c > > The NULL pointer reference occurs here: > > 0x00000000c0122008: ldx [ %l2 + 0x3d8 ], %g1 ! %g1 = 0 > 0x00000000c012200c: ldx [ %g1 + 0x18 ], %g1 ! > 0x00000000c0122010: brz,pn %g1, 0xc0122050 > 0x00000000c0122014: nop > > AFAICT the corresponding part of db_ps.c is this: > > if (p->p_session != NULL && SESS_LEADER(p)) > strlcat(state, "s", sizeof(state)); > > Here p->p_session expands to p->p_pgrp->pg_session which gives us the > exception because p->p_pgrp is set to NULL. So I guess this is a bug, > but not the bug I'm looking for... > > (Note: I know this is an oldish checkout, so maybe someone else has > already found and fixed this) I've just tried this with the latest SPARC64 current ISO (FreeBSD-11.0-CURRENT-sparc64-20160408-r297692) and the bug is still there, plus it occurs on my amd64 image too so this isn't just a SPARC64 issue. Also trying to use continue to exit from ddb doesn't seem to work under qemu-system-sparc64 either: $ ./qemu-system-sparc64 -cdrom FreeBSD-11.0-CURRENT-sparc64-20160408-r297692-disc1.iso -boot d -m 512 -nographic OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.1 built on Feb 26 2016 10:39 Type 'help' for detailed information Trying cdrom:f... Not a bootable ELF image Loading a.out image... Loaded 7680 bytes entry point is 0x4000 Jumping to entry point 0000000000004000 for type 0000000000000005... switching to new context: entry point 0x4000 stack 0x00000000ffe84a09 >> FreeBSD/sparc64 boot block Boot path: /pci@1fe,0/pci-ata@5/ide1@8200/cdrom@0:f Boot loader: /boot/loader Consoles: Open Firmware console FreeBSD/sparc64 bootstrap loader, Revision 1.0 (root@releng2.nyi.freebsd.org, Fri Apr 8 06:07:07 UTC 2016) bootpath="/pci@1fe,0/pci-ata@5/ide1@8200/cdrom@0:a" Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0xd1cc40+0x2137d8 syms=[0x8+0xdf260+0x8+0xcddb9] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK boot -d Booting... jumping to kernel entry at 0xc00b0000. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb KDB: enter: Boot flags requested debugger [ thread pid 0 tid 0 ] Stopped at 0xc062b5e0 db> continue db> Can anyone confirm whether or not this works on real hardware or whether it is another QEMU bug? ATB, Mark.