PCI range checking under qemu-system-sparc64

[Mark Cave-Ayland]

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