Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Jan 2020 18:35:09 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        Jason Bacon <bacon4000@gmail.com>
Cc:        freebsd-ppc@freebsd.org
Subject:   Re: G5 Quad Fans full speed after 1 min
Message-ID:  <BFE5494D-2CF2-4F79-AB26-1B0D668EDF1B@yahoo.com>
In-Reply-To: <08867d39-807a-494b-9ea5-d29d483e9c29@gmail.com>
References:  <CAGSRtz76TC44UiECMepLAZjXE=H33sg4OFLJpmZpNCSEwE=ETQ@mail.gmail.com> <21533290-667C-472E-89F7-D1E7DE773193@yahoo.com> <08867d39-807a-494b-9ea5-d29d483e9c29@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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:
>>=20
>>> Hi,
>>>=20
>>> My G5 Quad is running current from a few days ago, but this issue =
has been
>>> happening for a long time.
>>>=20
>>> After about 1 min of uptime, the fans go full speed.
>>>=20
>>> As soon as I query anything like CPU temp or fan rpm with sysctl, =
the fans
>>> return to a normal speed.
>>>=20
>>> 1 min later the fans go full speed again.
>>>=20
>>> 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.
>>=20
>>    (Most folks notice this via shutdown timeouts and the fans
>>    going fast unnecessarily. But it is involved earlier as well.)
>> END QUOTE
>>=20
>> 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.
>>=20
>> (I've no access to a single-socket, multi-core PowerMac,
>> so I just do not know for that kind of context.)
>>=20
>> 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.
>>=20
>> . . .
>=20
> On my dual CPU PowerMac G5, this issue happens for 80 - 90% of boots.
>=20
> 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=3D233863

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

=3D=3D=3D
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?BFE5494D-2CF2-4F79-AB26-1B0D668EDF1B>