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>
index | next in thread | previous in thread | raw e-mail
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)home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BFE5494D-2CF2-4F79-AB26-1B0D668EDF1B>