Re: PowerMac G5 crashes with "instruction storage interrupt" on recent 13

That seems bizarre.  There haven't been any changes to the controller
thread (powermac_thermal.c) in more than 7 years.  Are there any
problems with sensors?  I tested the change I made back in 2015 on my
dual core G5, with the intent that it would ramp the fans up sooner
(non-linear), and back them down with hysteresis.  So when there's load
that raises the temperature significantly it will ramp the fans up as
quickly as it can, hitting 100% fan long before it can reach maximum
temperature.

- Justin

On Fri, 9 Sep 2022 19:01:06 +0000
Julio Merino <julio@meroh.net> wrote:

> Ah, thanks for the workaround. I applied it on top of 9171b8068b92
> and the kernel was able to boot successfully – and it seems stable so
> far.
> 
> However, if I apply the hack on top of stable/13’s HEAD, there is
> still the 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 simple “git log” 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?
> 
> 
> 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 recent 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’s 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’s running an old build of FreeBSD 13
> > stable (from around October of last year) that I’m 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’t 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’t going to be relevant here, like addresses, here is what I
> > get:
> >
> > ----
> > Setting hostid: …
> > ZFS filesystem version: 5
> > ZFS storage pool version: features support (500)
> >
> > Fatal kernel trap:
> >
> > Exception = 0x400 (instruction storage interrupt)
> > …
> > pid = 64, comm = zpool
> >
> > panic: instruction storage interrupt trap
> > cpuid = 1
> > time = …
> > 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 “recent” commits that
> > you think may be at fault?
> >
> > Thanks!
> >  
>