Date: Wed, 05 Dec 2018 16:13:18 +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-EukJnhdt46@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 #8 from Dennis Clarke <dclarke@blastwave.org> --- Minor correction .. printf ("%p",foo) has a snit if foo isn't a 64bit data element similar to a pointer thus :=20 *** sys/powerpc/powermac/macgpio.c.orig Tue Dec 4 23:52:41 2018 --- sys/powerpc/powermac/macgpio.c Wed Dec 5 14:31:30 2018 *************** *** 161,169 **** --- 161,171 ---- 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); 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__, (void *)((uint64_t)root)); sc->sc_gpios =3D bus_alloc_resource_any(dev, SYS_RES_MEMORY, &sc->sc_gpios_rid, RF_ACTIVE); Ugly but it works.=20 I think phandle_t is a uint32_t and so a trivial %x could have done the job= .=20 Regardless we now know that the problem is not in macgpio.c and must move onwards to smu. --=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-EukJnhdt46>