PCI range checking under qemu-system-sparc64

[John Baldwin]

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

-- 
John Baldwin