Date: Fri, 9 Sep 2022 19:01:06 +0000 From: Julio Merino <julio@meroh.net> To: Justin Hibbits <jhibbits@FreeBSD.org> Cc: "freebsd-ppc@freebsd.org" <freebsd-ppc@freebsd.org> Subject: RE: PowerMac G5 crashes with "instruction storage interrupt" on recent 13 Message-ID: <PH0PR20MB37043177835C8DD8B024A173C0439@PH0PR20MB3704.namprd20.prod.outlook.com> In-Reply-To: <20220909120857.61f65069@ralga-linux> References: <PH0PR20MB3704882DD6DC53BB1CF2F5D2C09B9@PH0PR20MB3704.namprd20.prod.outlook.com> <PH0PR20MB37041E9776E86D61EB63FEBFC0439@PH0PR20MB3704.namprd20.prod.outlook.com> <20220909120857.61f65069@ralga-linux>
next in thread | previous in thread | raw e-mail | index | archive | help
--_000_PH0PR20MB37043177835C8DD8B024A173C0439PH0PR20MB3704namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ah, thanks for the workaround. I applied it on top of 9171b8068b92 and the = kernel was able to boot successfully =96 and it seems stable so far. However, if I apply the hack on top of stable/13=92s HEAD, there is still t= he issue of the fans going crazy at the slightest increase in CPU load but = they do drop back down to quiet when the load subsumes. (For example, a sim= ple =93git log=94 in /usr/src makes the fan spin up within a couple of seco= nds and they stop soon after that.) Any ideas on where this might come from= ? From: Justin Hibbits<mailto:jhibbits@FreeBSD.org> Sent: Friday, September 9, 2022 09:09 To: Julio Merino<mailto:julio@meroh.net> Cc: freebsd-ppc@freebsd.org<mailto:freebsd-ppc@freebsd.org> Subject: Re: PowerMac G5 crashes with "instruction storage interrupt" on re= cent 13 Hi Julio, 971cb62e0b23 is the likely culprit. Alfredo has a patch at https://reviews.freebsd.org/D36234 that you can use until the problem is solved. The alternative is you could build everything into the kernel instead of using modules. The problem appears to be in either lld or the kernel linker. - Justin On Fri, 9 Sep 2022 16:00:33 +0000 Julio Merino <julio@meroh.net> wrote: > Armed with a lot of patience, I was able to bisect where the crashes > are coming from. They seem to be due to these three consecutive and > related commits (because the first one broke the build and required > two extra fixes for powerpc=92s GENERIC64 to build): > > 9171b8068b92 cpuset: Fix the KASAN and KMSAN builds > 01f281d0ee52 Fix the build after 47a57144 > 971cb62e0b23 cpuset: Byte swap cpuset for compat32 on big endian > architectures > > Any idea on how to look into these crashes further? > > Thank you! > > > From: Julio Merino<mailto:julio@meroh.net> > Sent: Sunday, July 31, 2022 07:45 > To: freebsd-ppc@freebsd.org<mailto:freebsd-ppc@freebsd.org> > Subject: PowerMac G5 crashes with "instruction storage interrupt" on > recent 13 > > Hi all, > > I have a PowerMac G5 that=92s running an old build of FreeBSD 13 stable > (from around October of last year) that I=92m trying to upgrade to > recent stable/13. > > Booting into a new kernel brings two issues: the first is that the > fans spin up to jet engine levels right before transferring control > to userspace. An old patch I have locally to mitigate this (which I > got from whichever outstanding bug exists for this in the bug > tracker) doesn=92t seem to work any longer. > > The second is that the kernel crashes (apparently) as soon as it > tries to mount a ZFS pool during early stages of the boot process, > but after successfully transferring control to userspace. Typing this > from a photo of the crash so omitting details that I think aren=92t > going to be relevant here, like addresses, here is what I get: > > ---- > Setting hostid: =85 > ZFS filesystem version: 5 > ZFS storage pool version: features support (500) > > Fatal kernel trap: > > Exception =3D 0x400 (instruction storage interrupt) > =85 > pid =3D 64, comm =3D zpool > > panic: instruction storage interrupt trap > cpuid =3D 1 > time =3D =85 > KDB: stack backtrace: > #0 kdb_backtrace > #1 vpanic > #2 panic > #3 trap > #4 powerpc_interrupt > Uptime: 7s > ---- > > Any thoughts about what I could look into? Any =93recent=94 commits that > you think may be at fault? > > Thanks! > --_000_PH0PR20MB37043177835C8DD8B024A173C0439PH0PR20MB3704namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40">; <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"#954F72" style=3D"word-wrap:bre= ak-word"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Ah, thanks for the workaround. I applied it on top o= f 9171b8068b92 and the kernel was able to boot successfully =96 and it seem= s stable so far.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">However, if I apply the hack on top of stable/13=92s= HEAD, there is still the issue of the fans going crazy at the slightest in= crease in CPU load but they do drop back down to quiet when the load subsum= es. (For example, a simple =93git log=94 in /usr/src makes the fan spin up within a couple of seconds and they stop= soon after that.) Any ideas on where this might come from?</p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <div style=3D"mso-element:para-border-div;border:none;border-top:solid #E1E= 1E1 1.0pt;padding:3.0pt 0in 0in 0in"> <p class=3D"MsoNormal" style=3D"border:none;padding:0in"><b>From: </b><a hr= ef=3D"mailto:jhibbits@FreeBSD.org">Justin Hibbits</a><br> <b>Sent: </b>Friday, September 9, 2022 09:09<br> <b>To: </b><a href=3D"mailto:julio@meroh.net">Julio Merino</a><br> <b>Cc: </b><a href=3D"mailto:freebsd-ppc@freebsd.org">freebsd-ppc@freebsd.o= rg</a><br> <b>Subject: </b>Re: PowerMac G5 crashes with "instruction storage inte= rrupt" on recent 13</p> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Hi Julio,<br> <br> 971cb62e0b23 is the likely culprit. Alfredo has a patch at<br> <a href=3D"https://reviews.freebsd.org/D36234">https://reviews.freebsd.org/= D36234</a> that you can use until the problem<br> is solved. The alternative is you could build everything into the<br> kernel instead of using modules.<br> <br> The problem appears to be in either lld or the kernel linker.<br> <br> - Justin<br> <br> On Fri, 9 Sep 2022 16:00:33 +0000<br> Julio Merino <julio@meroh.net> wrote:<br> <br> > Armed with a lot of patience, I was able to bisect where the crashes<b= r> > are coming from. They seem to be due to these three consecutive and<br= > > related commits (because the first one broke the build and required<br= > > two extra fixes for powerpc=92s GENERIC64 to build):<br> > <br> > 9171b8068b92 cpuset: Fix the KASAN and KMSAN builds<br> > 01f281d0ee52 Fix the build after 47a57144<br> > 971cb62e0b23 cpuset: Byte swap cpuset for compat32 on big endian<br> > architectures<br> > <br> > Any idea on how to look into these crashes further?<br> > <br> > Thank you!<br> > <br> > <br> > From: Julio Merino<<a href=3D"mailto:julio@meroh.net">mailto:julio@= meroh.net</a>><br> > Sent: Sunday, July 31, 2022 07:45<br> > To: freebsd-ppc@freebsd.org<mailto:freebsd-ppc@freebsd.org><br> > Subject: PowerMac G5 crashes with "instruction storage interrupt&= quot; on<br> > recent 13<br> > <br> > Hi all,<br> > <br> > I have a PowerMac G5 that=92s running an old build of FreeBSD 13 stabl= e<br> > (from around October of last year) that I=92m trying to upgrade to<br> > recent stable/13.<br> > <br> > Booting into a new kernel brings two issues: the first is that the<br> > fans spin up to jet engine levels right before transferring control<br= > > to userspace. An old patch I have locally to mitigate this (which I<br= > > got from whichever outstanding bug exists for this in the bug<br> > tracker) doesn=92t seem to work any longer.<br> > <br> > The second is that the kernel crashes (apparently) as soon as it<br> > tries to mount a ZFS pool during early stages of the boot process,<br> > but after successfully transferring control to userspace. Typing this<= br> > from a photo of the crash so omitting details that I think aren=92t<br= > > going to be relevant here, like addresses, here is what I get:<br> > <br> > ----<br> > Setting hostid: =85<br> > ZFS filesystem version: 5<br> > ZFS storage pool version: features support (500)<br> > <br> > Fatal kernel trap:<br> > <br> > Exception =3D 0x400 (instruction storage interrupt)<br> > =85<br> > pid =3D 64, comm =3D zpool<br> > <br> > panic: instruction storage interrupt trap<br> > cpuid =3D 1<br> > time =3D =85<br> > KDB: stack backtrace:<br> > #0 kdb_backtrace<br> > #1 vpanic<br> > #2 panic<br> > #3 trap<br> > #4 powerpc_interrupt<br> > Uptime: 7s<br> > ----<br> > <br> > Any thoughts about what I could look into? Any =93recent=94 commits th= at<br> > you think may be at fault?<br> > <br> > Thanks!<br> > <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_PH0PR20MB37043177835C8DD8B024A173C0439PH0PR20MB3704namp_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?PH0PR20MB37043177835C8DD8B024A173C0439>