G5 Quad Fans full speed after 1 min

[Francis Little]

I'm more than willing to test patches, but I think trying to figure out
what to apply is a little beyond me, I'm more the pull a source from here
and go!

As for my machine, running with SMP off, compile times are terrible, with
SMP on, compiling ports etc is stable enough, just LOUD!

So I'm opting for the put it somewhere I can't hear it for now, and back to
the corn job prodding sysctl once in a while to calm it!

On Mon, 20 Jan 2020 at 02:35, Mark Millard via freebsd-ppc <
freebsd-ppc at freebsd.org> wrote:

>
>
> 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)
>
> _______________________________________________
> freebsd-ppc at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"
>