Date: Thu, 23 Jan 2020 12:25:29 -0800 From: Mark Millard <marklmi@yahoo.com> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: Michael Tuexen <tuexen@freebsd.org>, "powerpc@freebsd.org" <powerpc@FreeBSD.org> Subject: Re: panic: data storage interrupt trap when building world on PowerMac G5 Message-ID: <512CA82C-2C11-4394-AEB2-D0CD55C5BA5D@yahoo.com> In-Reply-To: <20200123134114.75d9c771@titan.knownspace> References: <7722F637-2C3D-4199-B2C9-F0616B0A5AE1@freebsd.org> <20200123134114.75d9c771@titan.knownspace>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jan-23, at 11:41, Justin Hibbits <chmeeedalf at gmail.com> wrote: > On Thu, 23 Jan 2020 12:32:03 +0100 > Michael Tuexen <tuexen@freebsd.org> wrote: > >> Dear all, >> >> when trying to build world on a G5 with SMP disabled >> (kern.smp.disabled=1 in /boot/loader.conf), I get the following panic: >> >> http://bsd14.fh-muenster.de/crash.jpeg >> >> It looks like this happens when memory is getting low (top was >> running until the machine panics). The machine runs the kernel from >> r356950. >> >> Any idea what is going wrong? >> >> Best regards >> Michael > > That fault address looks very suspicious. Reading it as hex encoding > of ASCII we get " user ad". > > Is there a reason you still have kern.smp.disabled=1? I fixed the bug > for that (at least in head) back around May, or at least *a* bug for it. At least for multi-socket contexts, PowerMacs still have the "some threads stuck sleeping" problem that leads to stuck processes/threads, such as: syncr, pmac_thermal, and buf*deamon* threads. Most folks notice via the fan behavior from pmac_thermal getting stuck. I've no clue if single-socket/multi-core also has such problems or not. I've had stuck buf*deamon* threads lead to some very nasty consequences back when I had this type of behavior in my context. Multiple folks on the list have indicated using kern.smp.disabled=1 to avoid behavior, such as the fan behavior. In my experiments, the mftb results between some cores for some boots just does not meet any reasonable constraints the way that FreeBSD boots such PowerMacs. The TB registers need to be forcibly constrained to have a more specific relationship when cross-core time relationships are in use. This matches up with one of the official documents for PowerPC's where I ran into: "The TB is a volatile resource and must be initialized during reset." I run with patched code, with changed behavior enabled at run-time only for PowerMacs, that attempts to force a more specific relationship and I've not seen the stuck sleeping problem since then. 2019-May is when that code last changed, to better deal with the faster time tick but slower processors in the 2 socket G4s that I have access to (less bias compared to the relationship I was targeting). Given the PowerMac context, I did not have to worry about (could not test) lots of sockets or lots of cores. So I've no evidence for how well the code would or could be generalized. But for its limited intended context, it seems to avoid the PowerMac "some threads stuck sleeping" problem for multi-socket contexts. It would be nice if my experiment inspired a checked-in change that made PowerMac's better behaved. === 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?512CA82C-2C11-4394-AEB2-D0CD55C5BA5D>