Hello Constantine, Thanks for your feedback. And no, I wasn't aware about your previous patch set. Interesting background you have provided on that topic though.
In the meantime I also received internal feedback from other developers, and as you already have mentioned it, there is no interest in adding fan control to base, mainly because of the obvious reasons that a) it adds too much complexity, and b) can lead to miss configurations which harm your hardware instead of protecting it. That's totally understandable and fine for me. I wasn't really aware that similar discussions already did take place in the past, otherwise I wouldn't have brought up the topic once again :-) Cheers, Marcus On Sat, 28 Nov 2020 12:45:20 -0800 "Constantine A. Murenin" <muren...@gmail.com> wrote: > 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 -- [ Marcus Glocker, mar...@nazgul.ch, http://nazgul.ch ]
