recent FreeBSD 13.0-CURRENT has fans screaming again on PowerMac quad
Justin Hibbits
chmeeedalf at gmail.com
Fri Jun 19 14:34:50 UTC 2020
On Fri, 19 Jun 2020 15:55:30 +0200
Michael Tuexen <tuexen at freebsd.org> wrote:
> > On 19. Jun 2020, at 14:22, Dennis Clarke via freebsd-ppc
> > <freebsd-ppc at freebsd.org> wrote:
> >
> >
> > Dear ppc64 big endian types:
> >
> > Sort of the same problem we had before. Except now the screaming
> > fans seem to mysteriously die down for about thirty seconds before
> > they start up again and run full blast for five minutes. It makes
> > the machine a nasty blower fan thing to put down the hallway and
> > run a 30 meter CAT6 ethernet to it just to deal with it at all.
> >
> > Anyone else seeing this ? It is really quite horrible to listen to.
> >
> > At the moment there is nothing running at all with the exception of
> > a svnlite checkout of http://svn.freebsd.org/base/head and the
> > machine is screaming as if its life may end at any moment.
> > Thankfully I have spare parts for when these fans blow up :
> >
> >
> > dclarke at enceladus:~ $ uptime
> > 12:21PM up 33 mins, 2 users, load averages: 0.97, 0.84, 0.48
> >
> > dclarke at enceladus:~ $ uname -apKU
> > FreeBSD enceladus 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362037: Thu
> > Jun 11 06:09:20 UTC 2020
> > root at releng1.nyi.freebsd.org:/usr/obj/usr/src/powerpc.powerpc64/sys/GENERIC64
> > powerpc powerpc64 1300097 1300097
> >
> > dclarke at enceladus:~ $ cat /etc/rc.conf
> > clear_tmp_enable="YES"
> > syslogd_flags="-ss"
> > hostname="enceladus"
> > ifconfig_bge0="inet 172.16.35.8 netmask 255.255.255.192"
> > defaultrouter="172.16.35.1"
> > sshd_enable="YES"
> > ntpd_enable="YES"
> > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
> > dumpdev="AUTO"
> > powerd_enable="YES"
> > dclarke at enceladus:~ $
> > dclarke at enceladus:~ $
> >
> > top -CSP shows :
> >
> > last pid: 1113; load averages: 1.00, 0.70, 0.35
> > up 0+00:29:42 12:17:57 55 processes: 3
> > running, 51 sleeping, 1 waiting CPU 0: 8.6% user, 0.0% nice,
> > 44.7% system, 0.3% interrupt, 46.3% idle CPU 1: 0.3% user, 0.0%
> > nice, 2.8% system, 0.6% interrupt, 96.4% idle CPU 2: 0.0% user,
> > 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle CPU 3: 0.0%
> > user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem:
> > 28M Active, 696M Inact, 626M Wired, 344M Buf, 6406M Free Swap:
> > 3615M Total, 3615M Free
> >
> > PID USERNAME THR PRI NICE SIZE RES STATE C TIME
> > CPU COMMAND 11 root 4 155 ki31 0B 192K RUN 0
> > 112:42 307.44% idle 1104 root 1 103 0 32M 19M
> > CPU3 3 4:57 87.60% svnlite 12 root 22 -52 -
> > 0B 1056K WAIT 1 0:12 2.65% intr 7 root 2 -16 -
> > 0B 96K - 0 0:04 1.17% cam 19 root 6 20
> > - 0B 288K psleep 2 0:02 0.50% bufdaemon 1050 dclarke
> > 1 20 0 23M 5252K select 0 0:01 0.23% sshd 1113
> > dclarke 1 20 0 16M 4408K CPU0 0 0:00 0.01%
> > top 931 root 1 20 0 23M 4676K select 2 0:00
> > 0.01% ntpd 1109 dclarke 1 20 0 23M 5260K select 2
> > 0:00 0.00% sshd 15 root 15 -68 - 0B 720K -
> > 0 0:00 0.00% usb 971 root 1 20 0 19M 5696K
> > select 3 0:00 0.00% sendmail 761 root 1 20 0
> > 14M 2384K select 2 0:00 0.00% syslogd 0 root 21 -16
> > - 0B 1008K swapin 3 0:00 0.00% kernel 1062 root
> > 1 20 0 15M 4944K pause 2 0:00 0.00% csh 1107 root
> > 1 20 0 23M 11M select 1 0:00 0.00% sshd
> > 1048 root 1 39 0 23M 11M select 2 0:00
> > 0.00% sshd 940 root 1 20 0 14M 1260K select 3
> > 0:00 0.00% powerd 1057 dclarke 1 20 0 15M 3848K
> > wait 1 0:00 0.00% su 1058 dante 1 20 0 15M
> > 3988K wait 3 0:00 0.00% sh 1051 dclarke 1 20 0
> > 15M 3988K wait 3 0:00 0.00% sh 1 root 1 20 0
> > 13M 1228K wait 3 0:00 0.00% init 1061 dante 1
> > 20 0 15M 3848K wait 1 0:00 0.00% su 13 root
> > 3 -8 - 0B 144K - 3 0:00 0.00% geom 978 root
> > 1 20 0 14M 2400K nanslp 3 0:00 0.00% cron 1110
> > dclarke 1 20 0 15M 4028K wait 1 0:00 0.00% sh
> > 23 root 1 -16 - 0B 48K pmac_t 3 0:00 0.00%
> > pmac_thermal 1037 root 1 52 0 14M 2808K ttyin 2
> > 0:00 0.00% getty 1035 root 1 52 0 14M 2808K
> > ttyin 0 0:00 0.00% getty 1033 root 1 52 0
> > 14M 2808K ttyin 1 0:00 0.00% getty 1032 root 1 52
> > 0 14M 2808K ttyin 3 0:00 0.00% getty 968 root
> > 1 20 0 22M 4108K select 2 0:00 0.00% sshd 1036 root
> > 1 52 0 14M 2808K ttyin 3 0:00 0.00% getty
> >
> > There must be a trivial fix to all this as we had it all working
> > pretty darn well some few months ago.
> Disable SMP?
>
> Best regards
> Michael
> >
> > --
> > Dennis Clarke
> > RISC-V/SPARC/PPC/ARM/CISC
> > UNIX and Linux spoken
> > GreyBeard and suspenders optional
> > _______________________________________________
> > 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"
If it's SMP timebase sync related, the problem actually looks
relatively easy to solve, at least for G4 and PowerMac11,2 G5's
(PowerMac7,3 looks trickier), from examining the Linux source and the
OFW device tree. The PowerMac11,2 (which the Quad is), and the G4s,
use a GPIO to disable and enable the timebase, so a very similar thing
can be done with the powermac platform driver as is done with the
mpc85xx platform driver, which effectively is:
All CPUs rendezvous in the smp_timebase_sync() function
BSP disables timebase, sets the timebase sync to non-zero
APs check for non-zero timebase, set their timebases to it
All CPUs rendezvous at the end
BSP re-enables timebase, and unleashes CPUs
A couple hours of work for someone with the hardware, I'd say. I can
probably provide a patch to be tested by someone in the next few days,
if someone else doesn't get around to it first.
- Justin
More information about the freebsd-ppc
mailing list