From: Armin Wolf <W_Armin@gmx.de>
To: "Jan Claußen" <jan.claussen10@web.de>,
"Guenter Roeck" <linux@roeck-us.net>,
linux-hwmon@vger.kernel.org
Subject: Re: Weird Dell SMM bug since 6.18
Date: Sat, 14 Mar 2026 00:10:26 +0100 [thread overview]
Message-ID: <f9bcdb69-6ad7-409a-afc3-bb5f277ef0ba@gmx.de> (raw)
In-Reply-To: <DH1W16PFES8U.3MBLJIJPV48JQ@web.de>
Am 13.03.26 um 20:06 schrieb Jan Claußen:
> I was actually in a fixed state for some reason and everything worked. I then tried to get back to the broken state and seems that echoing 2 into the pwmX_enable endpoints followed by reboot did the trick.
The developers of CoolerControl said that:
"As mentioned in my previous response above, CC reads the pwmX values first, and if that fails, then it doesn't bother
with checking the pwmX_enable attributes. So, according to the logs, it's never getting to the point of reading the
pwmX_enable files at all, ..."
Reading pwmX when the associated PWM channel is still in automatic control mode will return -ENODATA because
the driver cannot retrieve the current PWM value when the BIOS controls the fan. This likely causes CoolerControl
to ignore the dell-smm hwmon device.
There a two solutions for this:
1. CoolerControl does not ignore PWM channels that cannot be read when in automatic control mode (or adds some special handling for this driver).
2. The dell-smm-hwmon driver stops returning -ENODATA and instead returns a dummy value (like 0).
Guenter, would you be OK with the second approach? I get the feeling that this issue might affect more
fan control daemons.
Thanks,
Armin Wolf
>
> I then reverted the commits you suggested and it indeed fixed the issue. What to do now? Should coolercontrol adjust its code to this change or the commit be get reverted upstream?
>
> My two cents regarding cranking the fans up to max until the control software kicks in: I think medium fan speed should be sufficent. I actually would always default to BIOS control and make the control software in userspace responsible for setting pwmX_enable.
The problem is that on some devices, the "medium" setting is veeeeeery low, so the device might overheat should the fan control daemon somehow fail
to start. Normally this maximum speed is quickly overwritten by the fan control daemon after entering manual control mode, so this should not be a problem
in this case.
Thanks,
Armin Wolf
> Regards,
> Jan
>
next prev parent reply other threads:[~2026-03-13 23:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 12:39 Weird Dell SMM bug since 6.18 Jan Claußen
2026-03-13 16:43 ` Guenter Roeck
2026-03-13 19:06 ` Jan Claußen
2026-03-13 23:10 ` Armin Wolf [this message]
2026-03-16 15:52 ` Guenter Roeck
2026-03-16 20:10 ` Jan Claußen
2026-03-17 0:55 ` Guenter Roeck
2026-03-17 1:29 ` Armin Wolf
2026-03-19 9:49 ` Guy Boldon
2026-03-19 15:52 ` Guenter Roeck
2026-03-22 10:18 ` Guy Boldon
2026-03-23 10:25 ` Armin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f9bcdb69-6ad7-409a-afc3-bb5f277ef0ba@gmx.de \
--to=w_armin@gmx.de \
--cc=jan.claussen10@web.de \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox