[Bug 233579] ppc64 r341455 will panic on boot with usefdt=1
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Wed Dec 5 12:43:35 UTC 2018
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233579
--- Comment #7 from Dennis Clarke <dclarke at blastwave.org> ---
Some progress wherein working with Justin Hibbits we arrive at the notion
that usefdt=1 will cause a panic repeatedly.
We have seen that not specifying usefdt=1 may then force the requirement
for kern.smp.disabled=1 in order to proceed.
If neither usefdt=1 nor kern.smp.disabled=1 are specified then the
system may "freeze" later in the boot process.
We only concern ourselves with the usefdt=1 issue for the moment.
It should be clearly stated that kern.smp.disabled=1 always results in a
bootable and running system however usefdt=1 will always result in a panic
thus far.
The panic in r341455 on ppc64 is thus :
smu0: <Apple System Management Unit> on ofwbus0
panic: nexus_setup_intr: NULL interrupt resource!
cpuid = 0
time = 1
KDB: stack backtrace:
0xe000000000007820: at .kdb_backtrace+0x5c
0xe000000000007950: at .vpanic+0x1b4
0xe000000000007a10: at .panic+0x38
0xe000000000007aa0: at .nexus_setup_intr+0x58
0xe000000000007b50: at .bus_generic_setup_intr+0xc8
0xe000000000007c10: at .bus_generic_setup_intr+0xc8
0xe000000000007cd0: at .bus_generic_setup_intr+0xc8
0xe000000000007d90: at .pci_setup_intr+0x50
0xe000000000007e80: at .bus_generic_setup_intr+0xc8
0xe000000000007f40: at .bus_generic_setup_intr+0xc8
0xe000000000008000: at .pci_setup_intr+0x50
0xe0000000000080f0: at .bus_generic_setup_intr+0xc8
0xe0000000000081b0: at .bus_generic_setup_intr+0xc8
0xe000000000008270: at .pci_setup_intr+0xcc
0xe000000000008330: at .smu_attach+0xc4c
0xe000000000008530: at .device_attach+0x420
0xe000000000008610: at .device_probe_and_attach+0xb4
0xe0000000000086a0: at .bus_generic_new_pass+0x12c
0xe000000000008730: at .bus_generic_new_pass+0x114
0xe0000000000087c0: at .bus_generic_new_pass+0x114
0xe000000000008850: at .bus_set_pass+0xc4
0xe0000000000088e0: at .root_bus_configure+0x1c
0xe000000000008960: at .configure+0x14
0xe0000000000089e0: at .mi_startup+0x1f8
0xe000000000008a80: at btext+0xc4
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at .kdb_enter+0x60: ld r2, r1, 0x28
r341455 sys/powerpc/powermac/macgpio.c was modified slightly to merely see
some progress before the panic :
*** sys/powerpc/powermac/macgpio.c.orig Tue Dec 4 05:04:42 2018
--- sys/powerpc/powermac/macgpio.c Tue Dec 4 22:52:22 2018
***************
*** 173,183 ****
--- 173,185 ----
*/
for (child = OF_child(root); child != 0; child = OF_peer(child)) {
dinfo = malloc(sizeof(*dinfo), M_MACGPIO, M_WAITOK | M_ZERO);
+ device_printf(dev, "Trying child %x", child);
if (ofw_bus_gen_setup_devinfo(&dinfo->mdi_obdinfo, child) !=
0) {
free(dinfo, M_MACGPIO);
continue;
}
+ printf("Now here at sys/powerpc/powermac/macgpio.c line
182\n");
if (OF_getencprop(child, "reg", &dinfo->gpio_num,
sizeof(dinfo->gpio_num)) != sizeof(dinfo->gpio_num)) {
***************
*** 215,220 ****
--- 217,223 ----
continue;
}
device_set_ivars(cdev, dinfo);
+ printf("Set ivars in sys/powerpc/powermac/macgpio.c line
220\n");
}
return (bus_generic_attach(dev));
However nothing new was seen and the panic was the exact same.
The idea on the table is to sprinkle more debug output into macgpio.c and
try to capture what really is the order of events. What really is the
the sequence : 'macgpio0... on macio0' ... pci... smu... ?
At this time we do not know.
Therefore the r341508 kernel is being built with :
*** sys/powerpc/powermac/macgpio.c.orig Tue Dec 4 23:52:41 2018
--- sys/powerpc/powermac/macgpio.c Wed Dec 5 11:30:34 2018
***************
*** 161,169 ****
--- 161,172 ----
phandle_t root, child, iparent;
device_t cdev;
uint32_t irq;
+ printf("DEBUG : in %s at %d\n",__FILE__, __LINE__);
sc = device_get_softc(dev);
+ printf("DEBUG : in %s at %d\nDEBUG : sc = %p and sc->sc_node = %p\n",
__FILE__, __LINE__, sc, sc->sc_node);
root = sc->sc_node = ofw_bus_get_node(dev);
+ printf("DEBUG : in %s at %d\nDEBUG : root = sc->sc_node = %p\n",
__FILE__, __LINE__, root);
sc->sc_gpios = bus_alloc_resource_any(dev, SYS_RES_MEMORY,
&sc->sc_gpios_rid, RF_ACTIVE);
***************
*** 172,193 ****
* Iterate through the sub-devices
*/
for (child = OF_child(root); child != 0; child = OF_peer(child)) {
dinfo = malloc(sizeof(*dinfo), M_MACGPIO, M_WAITOK | M_ZERO);
if (ofw_bus_gen_setup_devinfo(&dinfo->mdi_obdinfo, child) !=
0) {
free(dinfo, M_MACGPIO);
continue;
}
if (OF_getencprop(child, "reg", &dinfo->gpio_num,
sizeof(dinfo->gpio_num)) != sizeof(dinfo->gpio_num)) {
/*
* Some early GPIO controllers don't provide GPIO
* numbers for GPIOs designed only to provide
* interrupt resources. We should still allow these
* to attach, but with caution.
*/
-
dinfo->gpio_num = -1;
}
--- 175,200 ----
* Iterate through the sub-devices
*/
for (child = OF_child(root); child != 0; child = OF_peer(child)) {
+ printf("DEBUG : in %s at %d\nDEBUG : begin for",__FILE__,
__LINE__);
dinfo = malloc(sizeof(*dinfo), M_MACGPIO, M_WAITOK | M_ZERO);
+ device_printf(dev, "DEBUG : in %s at %d\nDEBUG : Trying child
%x", __FILE__, __LINE__, child);
if (ofw_bus_gen_setup_devinfo(&dinfo->mdi_obdinfo, child) !=
0) {
+ printf("DEBUG : in %s at %d\n",__FILE__, __LINE__);
free(dinfo, M_MACGPIO);
continue;
}
+ printf("DEBUG : in %s at %d\n",__FILE__, __LINE__);
if (OF_getencprop(child, "reg", &dinfo->gpio_num,
sizeof(dinfo->gpio_num)) != sizeof(dinfo->gpio_num)) {
+ printf("DEBUG : in %s at %d\n",__FILE__, __LINE__);
/*
* Some early GPIO controllers don't provide GPIO
* numbers for GPIOs designed only to provide
* interrupt resources. We should still allow these
* to attach, but with caution.
*/
dinfo->gpio_num = -1;
}
***************
*** 195,213 ****
if (OF_getencprop(child, "interrupts", &irq, sizeof(irq)) ==
sizeof(irq)) {
OF_searchencprop(child, "interrupt-parent", &iparent,
sizeof(iparent));
resource_list_add(&dinfo->mdi_resources, SYS_RES_IRQ,
! 0, MAP_IRQ(iparent, irq), MAP_IRQ(iparent, irq),
! 1);
}
/* Fix messed-up offsets */
! if (dinfo->gpio_num > 0x50)
dinfo->gpio_num -= 0x50;
cdev = device_add_child(dev, NULL, -1);
if (cdev == NULL) {
device_printf(dev, "<%s>: device_add_child failed\n",
dinfo->mdi_obdinfo.obd_name);
ofw_bus_gen_destroy_devinfo(&dinfo->mdi_obdinfo);
--- 202,224 ----
if (OF_getencprop(child, "interrupts", &irq, sizeof(irq)) ==
sizeof(irq)) {
+ printf("DEBUG : in %s at %d\n",__FILE__, __LINE__);
OF_searchencprop(child, "interrupt-parent", &iparent,
sizeof(iparent));
resource_list_add(&dinfo->mdi_resources, SYS_RES_IRQ,
! 0, MAP_IRQ(iparent, irq),
! MAP_IRQ(iparent, irq), 1);
}
/* Fix messed-up offsets */
! if (dinfo->gpio_num > 0x50) {
dinfo->gpio_num -= 0x50;
+ printf("DEBUG : in %s at %d\nDEBUG : dinfo->gpio_num
tweaked back 0x50\n", __FILE__, __LINE__);
+ }
cdev = device_add_child(dev, NULL, -1);
if (cdev == NULL) {
+ printf("DEBUG : in %s at %d\nDEBUG : cdev == NULL\n",
__FILE__, __LINE__);
device_printf(dev, "<%s>: device_add_child failed\n",
dinfo->mdi_obdinfo.obd_name);
ofw_bus_gen_destroy_devinfo(&dinfo->mdi_obdinfo);
***************
*** 215,222 ****
continue;
}
device_set_ivars(cdev, dinfo);
}
!
return (bus_generic_attach(dev));
}
--- 226,234 ----
continue;
}
device_set_ivars(cdev, dinfo);
+ printf("DEBUG : in %s at %d\nDEBUG : device_set_ivars(cdev,
dinfo)\n",__FILE__, __LINE__);
}
! printf("DEBUG : in %s at %d\nDEBUG : end for",__FILE__, __LINE__);
return (bus_generic_attach(dev));
}
Test results should be available shortly.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-ppc
mailing list