Hi Marcus, Sounds interesting! I don't know if you've seen it, but I did a similar patchset back in the day, alas for the common PC desktops with the lm(4) sensors; http://sensors.cnst.su/fanctl/ . However, there hasn't been as much interest in fan control on OpenBSD as I had initially expected when I got into the sensors in the mid-noughties; and nowadays with cloud computing and cheap laptops, netbooks and embedded ARM with automatic fan control and passive cooling, there are easier options for Quiet Computing than using a desktop with an lm(4) chip and active cooling.
I also got the impression that fan control is incompatible with OpenBSD philosophy where system stability and ease-of-use is preferred to having lots of configuration options, especially those where you can allegedly shoot yourself in the foot, so, per my understanding, sadly, noone else was particularly interested in having a generic fan control interface merged into the tree. On a more practical point, there's a variation between the different devices on how to set fan control; for example, the asmc(4) patch you have lets you set a min/max RPM, some wbsio(4)/lm(4) chips let you set a target fan-speed and/or target temperature cruise (personally, I think the target temperature cruise makes the most sense for fan control), other lm(4) chips only let you set PWM duty cycle directly (thus any form of cruise would then have to be implemented in software, which would be less reliable and much more prone to overheating should any of the software components crash), and ThinkPad ACPI simply has levels between 0 and 7 or "8". I've implemented access to most of these hardware fan control features of wbsio(4) / lm(4) in my patch just on top of the sensors framework -- http://sensors.cnst.su/fanctl/ -- and I think it should be pretty intuitive to use and understand if you do care about lm(4)-based fan control. However, these variations in control options are probably the reason why many third-party tools like SpeedFan on Windows have only implemented the most basic PWM duty cycle support for each chip on a hardware level, and instead rely on having the software perform the monitoring/control loop for things like temperature cruise, even where the underlying chips are capable of doing it themselves autonomously (after first being programmed by the software), because this way the user interface and experience is more clear and consistent across the board (at the cost of reduced reliability if SpeedFan app or Windows OS crash). I'd imagine these variations, together with fan control being deemed optional by many developers, make it a somewhat hard sell for integration in base, which is kind of sad, because all those autonomous temperature cruise options in Winbond's lm(4) chips are pretty neat, and something that I'd wish modern laptops would actually offer in any way (as most of today's laptops -- including Apple MacBook macOS ones -- are completely unusable on the lap due to the terrible thermal profiles and a seeming lack of temperature-based control options for their active cooling components). Cheers, Constantine. On Fri, 27 Nov 2020 at 09:08, Marcus Glocker <mar...@nazgul.ch> wrote: > > Hi, > > I recently decided to replace MacOSX on my iMac11,3 27" with OpenBSD. > During the MacOSX times I had to replace the broken HDD with a new SSD. > The new SSD didn't offer pins to attach the sensor cable back, which > was previously attached to the HDD, so I left it loose. This caused > the HDD fan to spin up to maximum over time. On MacOSX there are some > fan control programs with which I could control the fan speed. I > almost forgot about that "fix" over time, but installing OpenBSD on > that machine remembered me of it - You can't overhear it :-) > > That made me play around with asmc(4), where I noticed you can not > only read the fan properties, but also set them. I initially was > thinking to make sysctl(8) able to set fan speeds, but what I could > see is that the fan framework there seems to be designed to read > only. Instead of poking around further in sysctl(8), I had the idea > to create a small fan(4) framework layer, which can be controlled > through a device by using a fanctl(8) user-land program. > > I don't know if there are other fan sensor controllers which would > allow fan properties control. If yes, they potentially could attach > to the same fan framework. If not, the fan framework probably doesn't > make much sense only to be used by asmc(4). > > Some example: > > ... > asmc0 at acpi0: SMC_ (smc-piketon) addr 0x300/0x20: rev 1.59f559, 297 > keys > fan0 at asmc0 > ... > > bigmac# sysctl | grep fan > hw.sensors.asmc0.fan0=998 RPM (ODD, right mid rear) > hw.sensors.asmc0.fan1=3677 RPM (HDD, center mid rear) > hw.sensors.asmc0.fan2=939 RPM (CPU, left lower rear) > > bigmac# ./fanctl > driver=asmc0 > fan0.id=ODD, right mid rear > fan0.act=999 RPM > fan0.min=1000 RPM > fan0.max=3800 RPM > fan0.saf=0 RPM > fan0.tgt=1000 RPM > fan1.id=HDD, center mid rear > fan1.act=3693 RPM > fan1.min=1100 RPM > fan1.max=5500 RPM > fan1.saf=0 RPM > fan1.tgt=3700 RPM > fan2.id=CPU, left lower rear > fan2.act=939 RPM > fan2.min=940 RPM > fan2.max=2100 RPM > fan2.saf=0 RPM > fan2.tgt=940 RPM > > bigmac# ./fanctl fan1.act > fan1.act=3729 > bigmac# ./fanctl fan1.max > fan1.max=5500 > > bigmac# ./fanctl fan1.max=1000 > fan1.max: 5500 -> 1000 > > *silence* :-) > > bigmac# ./fanctl fan1.act > fan1.act=1002 > > Attached a very initial coding, but basically works for me. > > Maybe the idea is totally stupid, and the use cases are very > rare. I don't know. Therefore I would appreciate some feedback. > > Thanks, > Marcus
