G5 Quad Fans full speed after 1 min

[Mark Millard]

On 2020-Jan-19, at 15:24, Jason Bacon <bacon4000 at gmail.com> wrote:

> On 2020-01-19 05:13, Mark Millard via freebsd-ppc wrote:
>> On 2020-Jan-19, at 00:38, Francis Little <oggy at farscape.co.uk> wrote:
>> 
>>> Hi,
>>> 
>>> My G5 Quad is running current from a few days ago, but this issue has been
>>> happening for a long time.
>>> 
>>> After about 1 min of uptime, the fans go full speed.
>>> 
>>> As soon as I query anything like CPU temp or fan rpm with sysctl, the fans
>>> return to a normal speed.
>>> 
>>> 1 min later the fans go full speed again.
>>> 
>>> I've been working round this for some time with a cron job that runs sysctl
>>> with one of the cpu temp sensors to calm the system.
>> QUOTING an old message:
>>    The mftb figures on the various cores can be so far apart that
>>    threads can end-up stuck sleeping, such as syncr, pmac_thermal,
>>    and buf*deamon*  threads. (This can really mess things up by
>>    not updating the storage correctly.) Such is still true of the
>>    ELFv2 context.
>> 
>>    (Most folks notice this via shutdown timeouts and the fans
>>    going fast unnecessarily. But it is involved earlier as well.)
>> END QUOTE
>> 
>> Nothing in the boot sequence is forcing the CPUs/Cores to
>> see any particular time relationship to each other and on
>> the multi-socket PowerMacs it can vary widely (G4 and G5).
>> Sometimes it will happen to end up okay, other times not.
>> 
>> (I've no access to a single-socket, multi-core PowerMac,
>> so I just do not know for that kind of context.)
>> 
>> I run with patched boot-code that has cross-cpu/core time
>> observations and adjustments to non-bsp time to see the
>> bsp time as between the start and end of a round trip to
>> the bsp from each non-bsp to get the bsp's time. It is
>> based on the mid-point of the start and end times for
>> the non-bsp's round trip vs. the bsp's returned time.
>> With at most 4 cores, each non-bsp is done in sequence.
>> The code only does this on PowerMacs, having no access
>> to other types of PowerPC examples to test.
>> 
>> . . .
> 
> On my dual CPU PowerMac G5, this issue happens for 80 - 90% of boots.
> 
> I'd love to test a patch if one is available.  Cutting the speed in half would be problematic for testing large ports.

For the svn diffs against head -r356426 for my code for
this issue, see:

https://lists.freebsd.org/pipermail/freebsd-ppc/2020-January/011239.html
https://lists.freebsd.org/pipermail/freebsd-ppc/2020-January/011240.html

But you likely want to avoid the one instance of:

-extern void *ap_pcpu;
+extern void * volatile ap_pcpu;

It would lead to needing analogous changes in a
bunch of other files. There are notes in those
other list entries about avoiding needing to
update the wider set of files.


I will note that there are more PowerMac related
patch sets around of mine that, if someone tries
them, I'd like to hear how things go:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233863

has 3 other patch attachments that I use for other PowerMac
issues. I originally did the work because the "workaround"
recommended for what was being reported crashed what I had
access to and I was trying to enable the workaround. But it
ended up far more capable than just enabling the workaround.
None of these attachments were involved in the "Closed FIXED"
status change: none of the patch sets are in FreeBSD.

My 3 attachments were before I'd tested my "modern" patches
for the per-core TB value relationships long enough for me
to be willing to put those materials there. (In fact, I
see that I deleted an old, insufficient patch on 2019-05-12.)

For what is there, the svn diff's are about 7 or more
months old compared to svn diffing with head -r356426
where my context is currently synchronized.

(There were 1 or two more patches at one time but
some other change or variation of them removed the
issue that they were for.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)