I'm experiencing a panic during boot on sparc64 11-CURRENT (r296811). This install was booting without problems on 11-CURRENT r296149, and booting the old kernel avoids the panic. Update procedure was as described in the handbook (23.6 Rebuilding World). Whilst I'm not familiar with the Sparc64 source, the panic seems to be occurring around addition of nexus0 and I noticed that a change was commited to nexus-related code in r296250; could this be related? Boot messages as follows: Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... jumping to kernel entry at 0xc00b0000. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 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 11.0-CURRENT #0 r296811: Mon Mar 14 09:31:43 GMT 2016 root@Computer:/usr/obj/usr/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. real memory = 4294967296 (4096 MB) avail memory = 4172685312 (3979 MB) cpu0: Sun Microsystems UltraSparc-IIIi Processor (1600.00 MHz CPU) cpu1: Sun Microsystems UltraSparc-IIIi Processor (1600.00 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random: unblocking device. random: entropy device external interface kbd0 at kbdmux0 nexus0: <Open Firmware Nexus device> pcib0: <Sun Host-PCI bridge> mem 0x4000e600000-0x4000e60afff,0x4000e410000-0x4000e41701f,0x7ce00000000-0x7ce000000ff,0x4000e780000-0x4000e78ffff irq 1842,1840,1841,1844,1827 on nexus0 panic: schizo_attach: could not allocate register bank 0 cpuid = 0 KDB: stack backtrace: vpanic() at vpanic+0x1b4 panic() at panic+0x20 schizo_attach() at schizo_attach+0x190 device_attach() at device_attach+0x5a8 device_probe_and_attach() at device_probe_and_attach+0x64 bus_generic_attach() at bus_generic_attach+0x10 nexus_attach() at nexus_attach+0x590 device_attach() at device_attach+0x5a8 device_probe_and_attach() at device_probe_and_attach+0x64 bus_generic_new_pass() at bus_generic_new_pass+0x11c bus_set_pass() at bus_set_pass+0xf8 root_bus_configure() at root_bus_configure+0x8 configure() at configure+0x4 mi_startup() at mi_startup+0x1d0 btext() at btext+0x28 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x80: ta %xcc, 1 db>
Further to my original report, replacing BUS_SPACE_MAXADDR with ~0ULL in line 236 of head/sys/sparc64/sparc64/nexus.c (i.e. part reversal of r296250) gives a kernel which boots. Looking in more detail, head/sys/sparc64/include/bus.h defines BUS_SPACE_MAXADDR as 0xFFFFFFFF, rather than ~0ULL, hence the change in behaviour. I've noticed that this seems to differ from some of the other 64 bit architectures (e.g. arm64 and powerpc64), which have 0xFFFFFFFFFFFFFFFFUL, but I don't know whether this is just as expected.
A commit references this bug: Author: marius Date: Sun Apr 10 22:43:37 UTC 2016 New revision: 297792 URL: https://svnweb.freebsd.org/changeset/base/297792 Log: Since r296250 it is no longer possible for devices to use bus space addresses exceeding 32 bit, so bump BUS_SPACE_MAXADDR to 64 bit. The whole situation is sub par, though; prior to r296250 and despite what their names imply, BUS_SPACE_MAX* were primarily, even almost exclusively used for bus_dma(9). Now these macros also have a vital role for bus_space(9). However, it does not necessarily hold that both bus DMA and space addresses universally have the same limits per platform. As for sparc64, 64 bit clearly is beyond what can be addressed via the various IOMMUs. With this change in place, we now rely on the parent bus DMA tags of the host-to-foo drivers causing the child tags to be capped as necessary. PR: 207998 Changes: head/sys/sparc64/include/bus.h