Date: Sun, 19 Jan 2020 03:13:06 -0800 From: Mark Millard <marklmi@yahoo.com> To: Francis Little <oggy@farscape.co.uk> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: G5 Quad Fans full speed after 1 min Message-ID: <21533290-667C-472E-89F7-D1E7DE773193@yahoo.com> In-Reply-To: <CAGSRtz76TC44UiECMepLAZjXE=H33sg4OFLJpmZpNCSEwE=ETQ@mail.gmail.com> References: <CAGSRtz76TC44UiECMepLAZjXE=H33sg4OFLJpmZpNCSEwE=ETQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. I've not seen this type of problem since mid 2019-May on any of: 1 G5 with 2 sockets, 1 core each 2 G5's, 2 sockets, 2 cores each 2 G4's, 2 sockets, 1 core each (The mid-May time frame is when I adjusted the code to deal with the faster time increment on the slower 32-bit processors for the model that I have access to. I had to be more careful to avoid biasing the approximate symmetry to be less symmetric. On the G5's its been longer since I've seen this problem, based on earlier source code.) Unfortunately the "lab" the machines are in is powered down currently. FYI: Prior to this technique, I had a pure hack that was observed to avoid the problem. But it changed code used all the time --code that I did not want to have any hack's in if I could avoid it. FYI: I also run with other PowerMac related patches. Generally this mftb() time adjustment is one of the newest patches, possibly the newest. So my test context may be biased by the other patches. > If I boot to OS X 10.5 and load the system, the fans are stable. I've not done any investigation of the issue for the older contexts. But, if I remember right, I did see the problem on occasion back in that time frame. > Does anyone else get this? My understanding is everyone booting a fairly modern standard FreeBSD gets this sometimes for the kind of context that you specified. (I'm not sure of the variability if the frequency of the problem happening for that kind of context.) I certainly saw it before I investigated avoiding it. === 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?21533290-667C-472E-89F7-D1E7DE773193>