panic: data storage interrupt trap when building world on PowerMac G5

[Mark Millard]

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 at 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)