Date: Sun, 18 Mar 2018 20:50:49 -0700 From: Mark Millard <marklmi26-fbsd@yahoo.com> To: Steve Wills <swills@FreeBSD.org> Cc: Nathan Whitehorn <nwhitehorn@freebsd.org>, freebsd-ppc@freebsd.org Subject: Re: fatal kernel trap Message-ID: <401F7AE1-3B2B-43C8-A643-316596556D62@yahoo.com> In-Reply-To: <7708841b-a124-7cf1-8a17-8d55fa837d59@FreeBSD.org> References: <d2e22843-7fb2-c2c9-1dfc-70d019ca24e7@FreeBSD.org> <CAHSQbTAUwQHu3SQMVC098=s7EBHEgzf6U1w8kmxU9b4fTf3x1A@mail.gmail.com> <f02d76b2-0c09-290b-9f6d-65eff8fd36e8@FreeBSD.org> <a3ec563a-1b76-1525-08d8-d0a5a427fb20@freebsd.org> <7708841b-a124-7cf1-8a17-8d55fa837d59@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Mar-18, at 8:16 PM, Steve Wills <swills at FreeBSD.org> wrote: > Sure. The system has 8GB of RAM and 2 CPUs. The root fs is on UFS and = it also has a disk with ZFS. The panic doesn't happen until very late in = boot, when it's mounting disks. I updated the whole system to r328835 = back in Feb. Then I switched the compiler over gcc 6.3.0 and rebuilt = kernel/world again. Not sure what other info might be helpful, let me = know if there's some particular that might help. >=20 > Steve >=20 > On 03/17/2018 19:57, Nathan Whitehorn wrote: >> Could you provide any other detail on your system? Amount of RAM, = etc.? >> -Nathan >> On 03/17/18 08:39, Steve Wills wrote: >>> Finished bisecting, r329611 boots fine, r329612 does not. >>>=20 >>> Steve >>>=20 >>> On 03/16/2018 10:43, Justin Hibbits wrote: >>>>=20 >>>> On Mar 16, 2018 09:29, "Steve Wills" <swills@freebsd.org = <mailto:swills@freebsd.org>> wrote: >>>>=20 >>>> My PowerMac G5 runs r328835 fine, but upgrading to r330240 = results in: >>>>=20 >>>> fatal kernel trap: >>>>=20 >>>> exception =3D 0x300 (data storage interrupt) >>>> virtual address =3D 0xc186bff8 >>>> dsisr =3D 0x40000000 >>>> srr0 =3D 0x8ef510 (0x8ef510) >>>> srr1 =3D 0x9000000000009032 >>>> lr =3D 0x7be3e4 (0x7be3e4) >>>> curthread =3D 0x11b26560 >>>> pid =3D 38, comm =3D kldload Given that it reports "kldload": Do you have a way to do a simple boot that would avoid loading any .ko files? In my clang-based experiments I ran into .ko files getting a different type of linkage (R_PPC64_JMP_SLOT) for the kldload to resolve (that it did not handle, leading to panics). I ended up adding: device filemon device geom_label to the kernel so that my normal activity could happen without kldload's of .ko files. [This goes back to 2017-Dec-24 or so. I've not been very active on FreeBSD most of the time after that.] I'm not claiming you have R_PPC64_JMP_SLOT use. I'm just illustrating avoiding kldload activity as a possible test. >>>> [ thread pid 38 tid 100087 ] >>>> Stopped at strchr+0x70: lbzu r10, 0x1(r4) >>>> db> >>>>=20 >>>> Note this was transcribed by hand and may have typos. Also note = my >>>> kernel was compiled with gcc 6.3.0, although the previous = kernel was >>>> as well and it works fine. >>>>=20 >>>> Any suggestions would be appreciated. >>>>=20 >>>> Thanks, >>>> Steve >>>>=20 >>>>=20 >>>> Hi Steve, >>>>=20 >>>> I see the same thing with any attempt to upgrade the kernel on my = G5 (PowerMac11,2) from a November 6 build to more recent. I've seen it = since the January timeframe, and haven't yet figured it out. >>>>=20 >>>> - Justin =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?401F7AE1-3B2B-43C8-A643-316596556D62>