I occasionally manage my fan speed manually by changing the `level' in `/proc/acpi/ibm/fan'. As of upgrading to 6.1.20, I am now getting the following error when attempting to change the fan speed: $ echo 'level auto' > /proc/acpi/ibm/fan echo: write error: invalid argument While troubleshooting, I tried double checking that fan_control had been set to 1 as noted in the documentation. I recently upgraded my kernel a few versions at once, so unfortunately i can't be sure when this bug originated. It was working with 6.1.15, and since upgrading to 6.1.20 it is no longer working.
Please bisect: https://docs.kernel.org/admin-guide/bug-bisect.html
Please consider attaching the dmesg output of a broken and working kernel, that might be helpful. Yes, a bisection might be good (note, there were recently two commits touching thinkpad_acpi driver, maybe one of them caused the problem). Knowing if mainline (e.g. 6.3-rc3) fails as well would be good to know, too. That being said: I forwarded the report to the responsible developers, maybe someone has a idea and might safe you the trouble with a bisection: https://lore.kernel.org/all/fc081e0f-2b58-b169-5ac1-f7845f48d1bf@leemhuis.info/
Looking at stable patches to thinkpad_acpi.c: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/platform/x86/thinkpad_acpi.c?h=v6.1.15 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/platform/x86/thinkpad_acpi.c?h=v6.1.20 Shows no differences. So this suggests that this problem is caused by a change somewhere else in the kernel. What does: cat /proc/acpi/ibm/fan output with one of the broken kernels?
Created attachment 304000 [details] [PATCH] platform/x86: thinkpad_acpi: Fix fan_write_cmd_level() return While looking at the code behind /proc/acpi/ibm/fan I did notice one very old issue with its return value, which I get may get tripped up now due to changes elsewhere. Can you build a troublesome kernel version with this patch added and see if that helps?
(In reply to Hans de Goede from comment #4) > Created attachment 304000 [details] > [PATCH] platform/x86: thinkpad_acpi: Fix fan_write_cmd_level() return > > While looking at the code behind /proc/acpi/ibm/fan I did notice one very > old issue with its return value, which I get may get tripped up now due to > changes elsewhere. > > Can you build a troublesome kernel version with this patch added and see if > that helps? Never mind, there is a wrapper between the function I was looking at and the actual write callback, so this patch is non-sense. Lets start with "cat /proc/acpi/ibm/fan" output and see from there.
The output on (broken) 16.1.20 $ cat /proc/acpi/ibm/fan status: enabled speed: 0 level: auto I can try to bisect, but it will likely take me a bit of time since it will be my first time doing so. In the meantime, I will be watching the bug. If I can provide any more information please let me know.
(In reply to runrin from comment #6) > The output on (broken) 16.1.20 > > $ cat /proc/acpi/ibm/fan > status: enabled > speed: 0 > level: auto > > I can try to bisect, but it will likely take me a bit of time since it will > be my first time doing so. In the meantime, I will be watching the bug. If I > can provide any more information please let me know. Hmm, can you also try with a working kernel, there should also be a list of supported commands printed. Since that is not printed it seems that with 6.1.20 the fan_control_commands variable in thinkpad_acpi.c is not getting set (left at 0). For starters lets confirm that with a working kernel you indeed get more output for "cat /proc/acpi/ibm/fan"
I think I know what is going on here. To be able to set the fan you need to specify thinkpad_acpi.fan_control=1 on the kernel commandline (or through modprobe.conf). I think this is somehow now longer happening for you. What is the output of: cat /sys/module/thinkpad_acpi/parameters/fan_control ?
Immediately after a reboot: # cat /etc/modprobe.d/thinkpad_acpi.conf options thinkpad_acpi fan_control=1 # cat /sys/module/thinkpad_acpi/parameters/fan_control N # cat /proc/acpi/ibm/fan status: enabled speed: 3900 level: auto # rmmod thinkpad_acpi # modprobe thinkpad_acpi # cat /sys/module/thinkpad_acpi/parameters/fan_control Y # cat /proc/acpi/ibm/fan status: enabled speed: 3900 level: auto commands: level <level> (<level> is 0-7, auto, disengaged, full-speed) commands: enable, disable commands: watchdog <timeout> (<timeout> is 0 (off), 1-120 (seconds)) After a reboot, fan_control is back to `N'. I'm not sure why it's not picking up the parameter on boot, but manually running `rmmod' then `modprobe' seems to fix it temporarily at least.
I guess you are using Arch Linux ? I think they are unconditionally adding thinkpad_acpi to the initrd now because that is necessary in some cases. And likely for some reason Arch Linux' initrd generator is not adding /etc/modprobe.d/* files to the initrd (which if I'm right I personally consider a bug of their initrd generator). Fedora has "lsinitrd" to list the contents of the initrd, not sure if Arch (or your distro if not Arch) has something similar. Try adding 'thinkpad_acpi.fan_control=1' to the kernel commandline, that will likely work.
I'm on Void. Adding 'thinkpad_acpi.fan_control=1' to the kernel commandline did fix the problem. I will report it to the Void maintainers.
Great, lets close this then.