Date: Wed, 05 Dec 2018 12:43:33 +0000 From: bugzilla-noreply@freebsd.org To: ppc@FreeBSD.org Subject: [Bug 233579] ppc64 r341455 will panic on boot with usefdt=1 Message-ID: <bug-233579-21-MNBT23u1HY@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-233579-21@https.bugs.freebsd.org/bugzilla/> References: <bug-233579-21@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D233579 --- Comment #7 from Dennis Clarke <dclarke@blastwave.org> --- Some progress wherein working with Justin Hibbits we arrive at the notion that usefdt=3D1 will cause a panic repeatedly. We have seen that not specifying usefdt=3D1 may then force the requirement= =20 for kern.smp.disabled=3D1 in order to proceed. If neither usefdt=3D1 nor kern.smp.disabled=3D1 are specified then the system may "freeze" later in the boot process. We only concern ourselves with the usefdt=3D1 issue for the moment. It should be clearly stated that kern.smp.disabled=3D1 always results in a bootable and running system however usefdt=3D1 will always result in a panic thus far.=20 The panic in r341455 on ppc64 is thus :=20 smu0: <Apple System Management Unit> on ofwbus0 panic: nexus_setup_intr: NULL interrupt resource! cpuid =3D 0 time =3D 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 :=20 *** 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 =3D OF_child(root); child !=3D 0; child =3D OF_peer(chil= d)) { dinfo =3D malloc(sizeof(*dinfo), M_MACGPIO, M_WAITOK | M_ZE= RO); + device_printf(dev, "Trying child %x", child); if (ofw_bus_gen_setup_devinfo(&dinfo->mdi_obdinfo, child) != =3D 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)) !=3D 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.=20 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.=20 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 =3D device_get_softc(dev); + printf("DEBUG : in %s at %d\nDEBUG : sc =3D %p and sc->sc_node =3D = %p\n", __FILE__, __LINE__, sc, sc->sc_node); root =3D sc->sc_node =3D ofw_bus_get_node(dev); + printf("DEBUG : in %s at %d\nDEBUG : root =3D sc->sc_node =3D %p\n", __FILE__, __LINE__, root); sc->sc_gpios =3D bus_alloc_resource_any(dev, SYS_RES_MEMORY, &sc->sc_gpios_rid, RF_ACTIVE); *************** *** 172,193 **** * Iterate through the sub-devices */ for (child =3D OF_child(root); child !=3D 0; child =3D OF_peer(chil= d)) { dinfo =3D malloc(sizeof(*dinfo), M_MACGPIO, M_WAITOK | M_ZE= RO); if (ofw_bus_gen_setup_devinfo(&dinfo->mdi_obdinfo, child) != =3D 0) { free(dinfo, M_MACGPIO); continue; } if (OF_getencprop(child, "reg", &dinfo->gpio_num, sizeof(dinfo->gpio_num)) !=3D 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. */ -=20 dinfo->gpio_num =3D -1; } --- 175,200 ---- * Iterate through the sub-devices */ for (child =3D OF_child(root); child !=3D 0; child =3D OF_peer(chil= d)) { + printf("DEBUG : in %s at %d\nDEBUG : begin for",__FILE__, __LINE__); dinfo =3D malloc(sizeof(*dinfo), M_MACGPIO, M_WAITOK | M_ZE= RO); + device_printf(dev, "DEBUG : in %s at %d\nDEBUG : Trying chi= ld %x", __FILE__, __LINE__, child); if (ofw_bus_gen_setup_devinfo(&dinfo->mdi_obdinfo, child) != =3D 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)) !=3D 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 =3D -1; } *************** *** 195,213 **** if (OF_getencprop(child, "interrupts", &irq, sizeof(irq)) = =3D=3D=20 sizeof(irq)) { OF_searchencprop(child, "interrupt-parent", &iparen= t, sizeof(iparent)); resource_list_add(&dinfo->mdi_resources, SYS_RES_IR= Q, ! 0, MAP_IRQ(iparent, irq), MAP_IRQ(iparent, irq), ! 1); } /* Fix messed-up offsets */ ! if (dinfo->gpio_num > 0x50) dinfo->gpio_num -=3D 0x50; cdev =3D device_add_child(dev, NULL, -1); if (cdev =3D=3D 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)) = =3D=3D=20 sizeof(irq)) { + printf("DEBUG : in %s at %d\n",__FILE__, __LINE__); OF_searchencprop(child, "interrupt-parent", &iparen= t, sizeof(iparent)); resource_list_add(&dinfo->mdi_resources, SYS_RES_IR= Q, ! 0, MAP_IRQ(iparent, irq), ! MAP_IRQ(iparent, irq), 1); } /* Fix messed-up offsets */ ! if (dinfo->gpio_num > 0x50) { dinfo->gpio_num -=3D 0x50; + printf("DEBUG : in %s at %d\nDEBUG : dinfo->gpio_num tweaked back 0x50\n", __FILE__, __LINE__); + } cdev =3D device_add_child(dev, NULL, -1); if (cdev =3D=3D NULL) { + printf("DEBUG : in %s at %d\nDEBUG : cdev =3D=3D NU= LL\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); } !=20 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-233579-21-MNBT23u1HY>