Date: Fri, 12 Jun 2015 23:45:42 +0100 From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> To: John Baldwin <jhb@FreeBSD.org>, freebsd-sparc64@freebsd.org Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <557B6116.70900@ilande.co.uk> In-Reply-To: <557ADCAB.9020409@FreeBSD.org> References: <53F73E6F.9080805@ilande.co.uk> <2084808.1lxSgnvf69@ralph.baldwin.cx> <557ADCAB.9020409@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/06/15 14:20, John Baldwin wrote: > On 9/4/14 11:55 AM, John Baldwin wrote: >> On Friday, August 22, 2014 01:58:23 PM Mark Cave-Ayland wrote: >>> Hi all, >>> >>> I'm currently working on a set of patches to enable FreeBSD to boot in >>> -nographic mode under qemu-system-sparc64 and I've just come across the >>> following error during boot: >>> >>> >>> Booting [/boot/kernel/kernel]... >>> jumping to kernel entry at 0xc00a0000. >>> Copyright (c) 1992-2014 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >>> The Regents of the University of California. All rights reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 10.0-RELEASE #0 r260789: Fri Jan 17 11:37:19 UTC 2014 >>> root@snap.freebsd.org:/usr/obj/sparc64.sparc64/usr/src/sys/GENERIC >>> sparc64 >>> gcc version 4.2.1 20070831 patched [FreeBSD] >>> real memory = 134217728 (128 MB) >>> avail memory = 106053632 (101 MB) >>> cpu0: Sun Microsystems UltraSparc-IIi Processor (100.00 MHz CPU) >>> random device not loaded; using insecure entropy >>> random: <Software, Yarrow> initialized >>> kbd0 at kbdmux0 >>> nexus0: <Open Firmware Nexus device> >>> nexus0: <builtin>: incomplete >>> pcib0: <U2P UPA-PCI bridge> mem 0x1fe00000000-0x1fe01ffffff irq >>> 2032,2030,2031,2021 on nexus0 >>> pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 33MHz >>> panic: psycho_attach: unsupported number of ranges >>> cpuid = 0 >>> KDB: stack backtrace: >>> #0 0xc085db60 at psycho_attach+0x780 >>> #1 0xc0569dd8 at device_attach+0x518 >>> #2 0xc056b4e8 at device_probe_and_attach+0x28 >>> #3 0xc056b510 at bus_generic_attach+0x10 >>> #4 0xc087704c at nexus_attach+0x58c >>> #5 0xc0569dd8 at device_attach+0x518 >>> #6 0xc056b4e8 at device_probe_and_attach+0x28 >>> #7 0xc056b87c at bus_generic_new_pass+0x11c >>> #8 0xc056aeb8 at bus_set_pass+0xf8 >>> #9 0xc056af08 at root_bus_configure+0x8 >>> #10 0xc086a9a4 at configure+0x4 >>> #11 0xc04d4e3c at mi_startup+0x1dc >>> #12 0xc00a0028 at btext+0x28 >>> Uptime: 1s >>> >>> >>> Having a look at the source it looks like we're being tripped by the >>> following check in psycho.c: >>> >>> >>> /* >>> * Make sure that the expected ranges are present. The >>> * OFW_PCI_CS_MEM64 one is not currently used though. >>> */ >>> if (i != PSYCHO_NRANGE) >>> panic("%s: unsupported number of ranges", __func__); >>> >>> >>> Now it seems that this occurs because OpenBIOS currently only supports >>> 32-bit PCI memory space (and so doesn't generate the 64-bit PCI memory >>> space entry withing the corresponding property). >>> >>> I could alter OpenBIOS to add a dummy 64-bit PCI memory space entry to >>> the end of the ranges property, however this particular check does seem >>> to be rather excessive and it is also slightly disingenuous to have >>> OpenBIOS include a declaration for a memory space that it cannot use >>> (plus it seems from the comment above that FreeBSD can't actually use it >>> anyway?!). >>> >>> Does anyone know why this particular assertion was added and what it's >>> actually trying to guard against? >> >> I suspect it was added out of an abundance of caution based on whatever real >> hardware it has run on. You can try this (untested) change: > > FYI, I was able to test my earlier patch and have posted an updated patch for > review. In my case the system appears to hang before it goes into single user > mode both in graphics mode and with -nographic. > > https://reviews.freebsd.org/D2791 Hi John, Thanks for the patch. As I could never cross-compile a SPARC64 kernel on a local FreeBSD VM, I wasn't able to test your patch at the time. However if it gets merged then I'll try and find some time to start digging again with a suitable ISO. Many thanks, Mark.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?557B6116.70900>