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>