G5 Quad Fans full speed after 1 min

[Jason Bacon]

Until this is fixed, you might just try a warm reboot.  For my dual core 
PowerMac, it's always just a matter of how many reboots are needed 
before it runs without issues.  Sometimes 1, once it was close to 10, 
usually a few.

     JB

On 2020-01-20 02:47, Francis Little wrote:
> 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"
>>
> _______________________________________________
> 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"


-- 
Earth is a beta site.