thinkfan
thinkfan copied to clipboard
Thinkpad T14s: Fan keeps running during suspend
Output from systemctl status thinkfan
before and after suspend:
Apr 06 15:35:09 thinkpad thinkfan[262008]: Temperatures(bias): 53(0) -> Fans: level 3
Apr 06 15:36:33 thinkpad thinkfan[262008]: Going to sleep: Will allow sensor read errors for the next 4 loops.
Apr 06 15:36:49 thinkpad thinkfan[262008]: Received SIGUSR2: Re-initializing fan control.
Apr 06 15:36:49 thinkpad thinkfan[262008]: Temperatures(bias): 49(0) -> Fans: level 2
The fan keeps running at the same speed during suspend.
Hi @JunnanZ, do you actually mean that the fan keeps running during suspend? I.e. your laptop completely turns off (screen, CPU, hard disk etc.) but the fan keeps running? In that case, you have faulty hardware because thinkfan has no influence whatsoever on what happens during suspend.
Or did you mean the switch to level 2
after waking up from suspend has no effect and the fan stays at level 3? In that case please post your config file and the output of cat /proc/acpi/ibm/thermal
before and after suspending.
I have the same issue (Thinkpad T14s Gen3, Intel): When I close the lid with the fan running it will keep running forever, as soon as I open the lid (given I waited a short time), thinkfan kicks in, sees the temperature being down and shuts down the fan.
When I have no thinkfan running and things being on "auto" it doesn't happen.
I wonder if it would be possible to shift to auto upon suspend but I don't know how feasible it is to get that signal into thinkfan. I'll add my configuration as soon as I get home.
My thinkfan.conf:
sensors:
- tpacpi: /proc/acpi/ibm/thermal
indices: [0, 2, 4, 5, 6]
fans:
- tpacpi: /proc/acpi/ibm/fan
levels:
- [0, 0, 53]
- [1, 46, 60]
- [2, 58, 65]
- [3, 62, 70]
- [4, 68, 75]
- [5, 73, 80]
- [6, 78, 85]
- [7, 85, 32767]
Well. That sounds absolutely crazy tbh because when the laptop is on standby no program is being executed and everything except the RAM is supposed to be turned off IN HARDWARE.
That being said, we could try to implement a workaround by switching the fan off in software BEFORE the system goes to sleep...
Or set it to "auto" not off because it might need running for a short while?
I wonder if the BIOS/EFI can't handle the fan state being explicitly set?
I'm experiencing the same issue with the T14 Gen 3 (Intel). Seems the fan is set to "disengaged" by the kill interrupt which is not good enough for "modern S2" sleep. The BIOS has a S3 sleep option, and in fact I'm getting correct fan behavior when entering sleep with it. However, S3 sleep is bugged in the current version of the BIOS 1.29/1.07 and will not wake up instead crashing and causing a system reboot.
I'm not sure if this fan behavior is universal across all S2 sleeping systems but it might be a good idea to offer control over the sleep state default in the config to avoid future problems with more systems moving to "modern" sleep. Then the user can fiddle with it in case of sleep issue, auto, disengaged, 0, etc.
Update:
I was incorrect about thinkfan setting fan state to disengaged on sleep, it appears that thinkfan does not change the fan level whatsoever when getting the kill signal. As a hack to get my fan to spin down safely on S2 sleep I'm currently using this very simple service unit file. Since the fan level is set to auto instead of forced to zero this hack should be fairly safe, even if thinkfan fails to start back up or update the fan speed on wake up or whatever other edge case might exist.
/etc/systemd/system/thinkfan-sleep-hack.service
[Unit]
Description=Set fan to auto so BIOS can shut off fan during S2 sleep
Before=sleep.target
After=thinkfan-sleep.service
[Service]
Type=oneshot
ExecStart=/usr/bin/logger -t '%N' "Setting /proc/acpi/ibm/fan to 'level auto'"
ExecStart=/usr/bin/bash -c '/usr/bin/echo "level auto" > /proc/acpi/ibm/fan'
[Install]
WantedBy=sleep.target
Then make sure to systemctl enable thinkfan-sleep-hack.service
so that sleep.target pulls it in.
it appears that thinkfan does not change the fan level whatsoever when getting the kill signal
There is no way to do anything on a SIGKILL
because it's a signal that cannot be caught. SIGKILL
is not something that should happen during regular operation of any system. It is a way specifically to terminate an application that is so broken/deadlocked that it can't execute its signal handlers any more, and it may cause an app to e.g. leave inconsistent data on disk.
The signal that is meant to terminate an application cleanly is SIGTERM
. It can be handled so that an application gets a chance to clean up after itself. For thinkfan that means setting the fan back to the settings before thinkfan was started. When you send a SIGKILL
to thinkfan your fans may be left on a fixed level (could be 0) indefinitely.
What I meant by "kill signal" above was "signal from kill command". Didn't think too hard about what literal signal was being sent. Looks like pkill is SIGTERM by default, although i can't find what -winch
means but i assume the signal is still SIGTERM.
Below is the thinkfan unit file that puts thinkfan to sleep.
# cat /usr/lib/systemd/system/thinkfan-sleep.service
[Unit]
Description=Notify thinkfan of imminent sleep
Before=sleep.target
[Service]
Type=oneshot
ExecStart=/usr/bin/pkill -x -winch thinkfan
# Hack: Since the signal handler races with the sleep, we need to delay a bit
ExecStart=/usr/bin/sleep 1
[Install]
WantedBy=sleep.target
Wait, figured it out. I think it's sending SIGWINCH which should be on window resize? Not sure why that would be the signal.
wait a minute :raised_eyebrow:
https://github.com/vmatare/thinkfan/commit/c5bcf16734c70514dbc3ff62380645c5f69099b0
Just looked it up, I'm still on version 1.3.1. A tag from back in feb. That SIGPWR change came later in april. So SIGWINCH is still correct for this install.
You're exactly right. SIGWINCH
is a "sort-of" unused signal (or so I thought) which I've been (ab)using to notify thinkfan of imminent sleep. However I've noticed that it's not entirely unused, e.g. if you start thinkfan in a terminal window, a SIGWINCH
is actually sent to thinkfan when you resize the window. That's why I've changed it to SIGPWR
for the upcoming release
Now currently, thinkfan does not do anything special to the fan on sleep. The signal is only there to tell thinkfan that sensor and/or fan I/O errors should be ignored during the next few cycles.
What I meant by "kill signal" above was "signal from kill command". Didn't think too hard about what literal signal was being sent. Looks like pkill is SIGTERM by default, although i can't find what
-winch
means but i assume the signal is still SIGTERM.Below is the thinkfan unit file that puts thinkfan to sleep.
# cat /usr/lib/systemd/system/thinkfan-sleep.service [Unit] Description=Notify thinkfan of imminent sleep Before=sleep.target [Service] Type=oneshot ExecStart=/usr/bin/pkill -x -winch thinkfan # Hack: Since the signal handler races with the sleep, we need to delay a bit ExecStart=/usr/bin/sleep 1 [Install] WantedBy=sleep.target
Thanks for this solution! I was having the same issue on my Thinkpad P15s Gen 2. This should keep it sleeping on battery much longer.
Now to figure out why the system gets so hot when connected to AC power, even when it's done charging. But that's a different issue -- the fan responds to the temperature as it should.
same issue on Lenovo Yoga X390, Manjaro Linux.
I just noticed the issue myself on a new P series Thinkpad. However the problem went away after updating to the latest firmware version. So if anyone is still experiencing this: What firmware version are you currently running (check fwupdmgr get-updates
or dmidecode -t 0
)?
Lenovo Yoga X390, Manjaro Linux
sudo dmidecode -t0
# dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 3.1.1 present.
Handle 0x0011, DMI type 0, 26 bytes
BIOS Information
Vendor: LENOVO
Version: N2LET96W (1.96 )
Release Date: 07/06/2023
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 32 MB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
3.5"/720 kB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 1.96
Firmware Revision: 1.21
sudo fwupdmgr get-updates
Devices with no available firmware updates:
• Internal SPI Controller
• TPM
• UEFI Device Firmware
• UEFI Device Firmware
• UEFI Device Firmware
Devices with the latest available firmware version:
• Intel Management Engine
• MZVLB512HBJQ-000L7
• Prometheus
• Prometheus IOTA Config
• System Firmware
• UEFI dbx
No updates available
Huh... So your BIOS is from 07/06/2023. Maybe there's a chance they'll eventually publish a fixed version, but apparently not all models are treated the same. Looks like we might have to implement a workaround for this :-/
@vmatare Does not work even with the latest update.
Getting SMBIOS data from sysfs.
SMBIOS 3.1.1 present.
Handle 0x0011, DMI type 0, 26 bytes
BIOS Information
Vendor: LENOVO
Version: N2LET97W (1.97 )
Release Date: 08/15/2023
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 32 MB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
3.5"/720 kB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 1.97
Firmware Revision: 1.21
Same issue with a Lenovo X13 Gen 4, if thinkfan has control of the fan and the fan is running when suspend is triggered, it will keep running indefinitely.
Update: I've managed to get it working - YMMV. Thanks to https://github.com/vmatare/thinkfan/issues/181#issuecomment-1353799531
For reference, my system's bios is as follows.
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.4.0 present.
Handle 0x001B, DMI type 0, 26 bytes
BIOS Information
Vendor: LENOVO
Version: N3OET26W (1.09 )
Release Date: 10/31/2023
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 32 MB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
3.5"/720 kB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 1.9
Firmware Revision: 1.10
I have a T16 Gen 1 running Fedora 39 Cinnamon Spin and was also having this problem. I changed the sleep and wakeup unit files to call scripts to stop and continue thinkfan and also set the fan to auto before sleep. You can see the configs here https://gist.github.com/jlongua/849936e07cc417cb00f1ec3ba4ed8dd8
Well. That sounds absolutely crazy tbh because when the laptop is on standby no program is being executed and everything except the RAM is supposed to be turned off IN HARDWARE.
Modern laptops by default enter "Suspend-to-Idle" mode, in which some parts of the hardware isn't switched off and e.g. ACPI thermal loops in the BIOS continue running. The allows for a nice cooloff of residual heat while the system is already suspended. Except the fans must be in AUTO mode for this to work correctly; leaving them in a fixed-speed mode will result in them spinning forever.