Bug 207998 - Panic during boot on Sparc64 11-CURRENT (r296811)
Summary: Panic during boot on Sparc64 11-CURRENT (r296811)
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: sparc64 Any
: --- Affects Only Me
Assignee: freebsd-sparc64 (Nobody)
Keywords: regression
Depends on:
Reported: 2016-03-14 20:16 UTC by dal36
Modified: 2016-04-10 22:45 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description dal36 2016-03-14 20:16:42 UTC
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
Comment 1 dal36 2016-03-15 01:28:41 UTC
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.
Comment 2 commit-hook freebsd_committer 2016-04-10 22:44:27 UTC
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

  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