Date: Sun, 28 Oct 2012 22:53:48 -0400 From: Michael Copeland <michael@kryptos-security.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org>, freebsd-ppc@freebsd.org Subject: Re: Quick question about dev.smu dev.smusat on powermac11,2 Message-ID: <CAKLtBCiDtEERNYmKFgYAHBcjzH1EMocirf0r%2BPy%2Bs-gCgdQ=%2Bw@mail.gmail.com> In-Reply-To: <CAKLtBCgU8jDe5-i98hRDxpFtEq0=iUHieAAEMpgjXqn5BtehMQ@mail.gmail.com> References: <CAKLtBCjdNpXKktDX0YAdRn2OPEAeXoP3G9XY-aDuRBCLdXKdPA@mail.gmail.com> <alpine.BSF.2.00.1210281249500.41855@banshee.munuc.org> <CAKLtBCjb830DE4aYt5J8E=Do_NeahxRif6Rp5RON7E8rY3wdOQ@mail.gmail.com> <alpine.BSF.2.00.1210281448390.41855@banshee.munuc.org> <CAKLtBChw-SGaCXkFb4dkmpReL6ZB7ap3cpjcsnET7LTybbQtTw@mail.gmail.com> <alpine.BSF.2.00.1210281623500.41855@banshee.munuc.org> <CAKLtBCgU8jDe5-i98hRDxpFtEq0=iUHieAAEMpgjXqn5BtehMQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 28, 2012 at 5:35 PM, Michael Copeland < michael@kryptos-security.com> wrote: > > > On Sun, Oct 28, 2012 at 5:24 PM, Nathan Whitehorn <nwhitehorn@freebsd.org>wrote: > >> >> >> On Sun, 28 Oct 2012, Michael Copeland wrote: >> >> >>> >>> On Sun, Oct 28, 2012 at 3:50 PM, Nathan Whitehorn < >>> nwhitehorn@freebsd.org> wrote: >>> >>> >>> On Sun, 28 Oct 2012, Michael Copeland wrote: >>> >>> >>> >>> On Sun, Oct 28, 2012 at 3:42 PM, Nathan Whitehorn < >>> nwhitehorn@freebsd.org> wrote: >>> It should work fine (it does on my desktop, which is a >>> G5 of the same model). >>> Since I wrote that >>> program, fan control has moved to the kernel. The fans >>> should be fairly >>> quickly responsive (the >>> algorithm is quite basic) but should never go to full >>> or cause a panic. Which >>> release are you >>> running? There were some improvements to fan control >>> in 9.1. >>> -Nathan >>> >>> On Sun, 28 Oct 2012, Michael Copeland wrote: >>> >>> Is the fan control disabled by default on a GP dual >>> core? Only reason I ask >>> is that the fans on spool up under full load, and that >>> usually results in a >>> panic. >>> I did make a rather simple program and associated >>> script to control the >>> fans, but this happens to result in the fans >>> constantly going up and down >>> by about 300-400 rpm even while doing something simple >>> like portsnap >>> extract. I checked the list after doing that, and >>> found a thread where >>> someone else already did the same thing(a common >>> problem of mine, I usually >>> try to fix it myself without checking the list). I >>> swapped out the program >>> written by Nathan, but my results are the same. It >>> DOES work, but I was >>> only wondering if it's normal for the fan speed to >>> vary so often. >>> >>> Thanks, >>> >>> Michael >>> ______________________________**_________________ >>> freebsd-ppc@freebsd.org mailing list >>> http://lists.freebsd.org/**mailman/listinfo/freebsd-ppc<http://lists.freebsd.org/mailman/listinfo/freebsd-ppc>; >>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@** >>> freebsd.org <freebsd-ppc-unsubscribe@freebsd.org>" >>> >>> Hi Nathan, >>> It's 9.1-PRE, from.. 3 days ago. >>> The fans, without my app running either spin at the lowest >>> rpm, or the fastest. Once >>> it's at max rpm, in 5 >>> minutes it will panic. >>> >>> >>> >>> Interesting -- that should not happen, to say the least. Could you >>> report what the panic is and print >>> out the contents of the dev.smu and dev.smusat registries? >>> >>> You can also disable automatic fan control by the sysctl >>> machdep.manage_fans (although I'd like to >>> find and fix the actual problem here) >>> -Nathan >>> >>> Nothing to report for the panic, the screen isn't refreshed, no dumps >>> either, and i do have that enabled >>> >>> frodoG5# sysctl dev.smu >>> dev.smu.0.%desc: Apple System Management Unit >>> dev.smu.0.%driver: smu >>> dev.smu.0.%pnpinfo: name=smu compat=smu >>> dev.smu.0.%parent: nexus0 >>> dev.smu.0.fans.drive_bay_a_**intake.minrpm: 1000 >>> dev.smu.0.fans.drive_bay_a_**intake.maxrpm: 4000 >>> dev.smu.0.fans.drive_bay_a_**intake.rpm: 1060 >>> dev.smu.0.fans.backside.**minrpm: 1100 >>> dev.smu.0.fans.backside.**maxrpm: 3000 >>> dev.smu.0.fans.backside.rpm: 1549 >>> dev.smu.0.fans.cpu_a_intake.**minrpm: 485 >>> dev.smu.0.fans.cpu_a_intake.**maxrpm: 3200 >>> dev.smu.0.fans.cpu_a_intake.**rpm: 624 >>> dev.smu.0.fans.cpu_b_intake.**minrpm: 485 >>> dev.smu.0.fans.cpu_b_intake.**maxrpm: 3200 >>> dev.smu.0.fans.cpu_b_intake.**rpm: 628 >>> dev.smu.0.fans.cpu_a_exhaust.**minrpm: 500 >>> dev.smu.0.fans.cpu_a_exhaust.**maxrpm: 3200 >>> dev.smu.0.fans.cpu_a_exhaust.**rpm: 619 >>> dev.smu.0.fans.cpu_b_exhaust.**minrpm: 500 >>> dev.smu.0.fans.cpu_b_exhaust.**maxrpm: 3200 >>> dev.smu.0.fans.cpu_b_exhaust.**rpm: 605 >>> dev.smu.0.fans.expansion_**slots_intake.minrpm: 1560 >>> dev.smu.0.fans.expansion_**slots_intake.maxrpm: 4500 >>> dev.smu.0.fans.expansion_**slots_intake.rpm: 1618 >>> dev.smu.0.sensors.slots_power: 18818 >>> dev.smu.0.server_mode: 0 >>> frodoG5# sysctl dev.smusat >>> dev.smusat.0.%desc: SMU Satellite Sensors >>> dev.smusat.0.%driver: smusat >>> dev.smusat.0.%location: addr=0xb0 >>> dev.smusat.0.%pnpinfo: name=sat compat=smu-sat >>> dev.smusat.0.%parent: iicbus2 >>> dev.smusat.0.cpu_a0_vcore: 1 >>> dev.smusat.0.cpu_a1_vcore: 1 >>> dev.smusat.0.cpu_a0_diode_**temp: 43.6C >>> dev.smusat.0.cpu_a1_diode_**temp: 43.4C >>> dev.smusat.0.cpu_a0_core_**current: 24 >>> dev.smusat.0.cpu_a1_core_**current: 20 >>> frodoG5# uname -a >>> FreeBSD frodoG5 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1: Sun Oct 28 >>> 20:21:16 EDT 2012 >>> michael@frodoG5:/usr/obj/usr/**src/sys/FRODOG5 powerpc >>> >>> >>> >> That all looks in order. Any change you could provide the same from when >> the fans are racing? >> -Nathan > > Yeah, I'm getting ready to build something. The output from sysctl was > with my app running. If I disable it, the fans will go full tilt on their > own after a while, no activity. Ok. Without the manual control of the fans, it locks up and you get nothing to report. With it running, it never gets too far above about 70. Not sure what's going on. I'm going to setup debug over firewire and see if I can catch something before it hardlocks. I've no idea why the main console never updates when it locks. I guess I'm not even sure if it's a kernel panic or the hardware itself is actually freezing. It doesn't do it in linux, even under a full load.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKLtBCiDtEERNYmKFgYAHBcjzH1EMocirf0r%2BPy%2Bs-gCgdQ=%2Bw>