Larkbox fan does not work rigth on Linux

Hello all,

After installing Linux on the larkbox, the fan only starts spining when a user logs in and does not stop anymore. In any other case fan is not working and temperatures even without load reaches 70 celsius degrees.

Any help will be more than wellcome.

Yes, I have the same problem: I installed Ubuntu 20.04 just now and the CPU cores stay at 85 degrees, the Larkbox becomes very slow and still the fan is doing absolutely nothing.

Chuwi please help!

I’ve literally just gotten my larkbox today and put the latest debian on it (I don’t use windows).

So far so good although I haven’t been using mine an awful lot(!) I’m not getting any problems - less one. It is a bit concerning that I haven’t heard the fan on my larkbox start up although if I am reading it correctly in the bios it is set to be enabled at 60C.

I read about the overheating problems of the larkbox before I got mine so the first thing I did was to enable the fan in the bios (by default it was disabled which is worrying). I also kept a table fan pointing directly at the larkbox while installing debian bullseye on it. I’m in the UK and the weather has changed drastically just recently - it has cooled down a lot; had I had my larkbox last week instead of this week maybe the overheating problems would have shown up more quickly.

I’ve not been using the larkbox for long but so far the highest tempeature I got with mine was 55C according to lm-sensors.

I do see lots of options in the bios for sensors but I don’t know if they should be enabled or not;

Sensor Device 1 [disabled]
Sensor Device 2 [disabled]
Sensor Device 3 [disabled]
Sensor Device 4 [Enabled]
 Active thermal trip point 60
 Passive thermal trip point 65
 S3/CS Thermal trip point 70
 Hot thermal trip point 75
 Critical thermal trip point 80

Random thought and wild speculation: Maybe some larkboxes have different BIOS versions than others? (Prehaps older larkboxes have a slightly older bios?). Also maybe those sensors in the bios (1-3) which are disabled don’t exist; prehaps whatever sensor is in the larkbox the one that is enabled (4) and enabling the other 3 since maybe they don’t exist would cause problems?

ljones

Yeah I also looked at all these BIOS settings. They’re the same with me: FAN device was set to ’ disabled’ for some reason and only ‘Sensor Device 4’ is set to ‘Enabled’.

I suggest you also email Chuwi about this problem. Their email address is aftersale@chuwi.com. The more emails they get on this problem, the more likely they will understand that this is a serious problem.

Can you please let me know here if you find a solution to this problem? Thanks.

I sent them an email although I don’t know if they will reply at all.

It could just all be a BIOS bug. Broken and/or buggy bioses are not uncommon and can even be found on normal standard PC motherboards. I’ve seen a few recent motherboards for example which have horribly buggy and broken implementations of ACPI for example.

ljones

Looked at the bios a little more and I also see the following;

dptf processor [enabled]

and

active thermal trip point 95
passive thermal trip point 110

Mine also seems to be set up in bios to use the passive thermal option (“Passive policy 2.0”). The active policy is disabled. So does that mean the fan would only be enabled at 110C? That seems far too high!

Update: After a little more digging I’ve found that dptf isn’t completely supported in linux and I’m guessing the larkbox uses exactly that. Was reading this here. Got wintel to thank for that x.x .

ljones

1 Like

@ljones, thank you, that’s very interesting, bearing in mind that Chuwi claimed the box to be compatible with Linux and Ubuntu (as well as Windows). In the Drivers thread, you can download the Windows drivers pack that includes the ACPI Fan one. I wonder if they have something similar for Ubuntu, but we’re still yet to hear from them about it.

Linux users please bump up my thread to inform chuwi to officially collaborate with any linux distro and that will bring support to most of the linux distro’s for their devices.

Please comment on my thread too.

This is a detailed thread, if we follow official Intel git link then it is just a matter to building it as a package and loading it as userspace app to make it run dptf.

For this chuwi will need to collaborate with an official linux distro.

Good luck.

I’ve noticed reading /sys/class/thermal/thermal_zone1/temp causes my fan to turn on and off based on its current temperature (approximately on at 60C and off at 55C).

Is your fan responsive to thermals while the below command is running? My setup: Debian 10. UEFI. Default BIOS Settings. BIOS Version GB01_ZW_1_03 07/09/2020

while true ; do cat /sys/class/thermal/thermal_zone?/temp ; sleep 1 ; done

If this “fix” happens to work for someone else, maybe there’s a clue in the Thermal Sysfs Driver impl about what’s happening. Some sort of missing ACPI interrupt causing kernel to operate with stale state?

thermal_zone1’s configuration may correlate with “Sensor Device 4”. There are 4 other thermal zones corresponding to each of the 4 cores. Reading those reads the CPU temps, but does not have any impact on the state of the fan.

@braikin I confirm that similar command (I use watch instead of while and sleep) works just as well in Ubuntu, so when I run a separate terminal window with it (which doubles as a temperature monitor), fan turns on and off as necessary (around 55C).
@spikerguy I’ve tried installing dptfxtract and acpica-tools (from apt), ran it to generate “thermal-conf.xml.*” files, but they don’t seem to contain any reference to the target temperatures, but rather look like a default config. Then I’ve built thermal_daemon from Intel git (not from the fork) and installed it, and similar to the workaround above, the fan now starts and stops depending on the current temperature when I restart this service (for a similar reason, I presume), but not just from running it.

Apon reading the dptf webpage again I noticed something in the comments section;

"Kernel patched are merged to 5.8. The thermald patches are merged to master branch and tagged as pre-release for 2.3. "

I’m running debian bullseye with kde on my larkbox. The kernel version is 5.8.0.1-amd64 . So maybe some of what is in that post on that website is already in the kernel?

I have my larkbox on right now, it isn’t doing much apart from just running kde and running psensor. The temps are sticking to around ~47C.

Haven’t ever heard the fan spin up on my larkbox though; the only alternative would be (unless it really is working ok and just very quiet) that it is a faulty fan.

ljones

1 Like

I haven’t tried the “fix” above in bullseye, but a stock setup with latest official bullseye live cd the fan didn’t work for me.

I wrapped my command in a systemd service to make sure its restated if it happens to die:

/etc/systemd/system/chuwifan.service

[Unit]
Description=Enables Chuwi Larkbox Fan Control
Documentation=https://forum.chuwi.com/t/larkbox-fan-does-not-work-rigth-on-linux

[Service]
ExecStart=/bin/sh -c 'while true ; do cat /sys/class/thermal/thermal_zone?/temp > /dev/null ; sleep 2 ; done'
Restart=always

[Install]
WantedBy=multi-user.target
systemctl enable chuwifan.service
systemctl start chuwifan.service

I’ll live with this fix for now. I haven’t testing if passive cooling (cpu thermal throttling), or critical temperature power-offs work.

If I’m curious, I’ll poke around kernel’s acpi/thermal.c some more. cat /sys/class/thermal/thermal_zone0/temp does nothing but delegate to a read of the temperature variable via ACPI.

Random guess: The dptf bios configuration for sensor 4 requests the driver (OS?) read the sensor every 0.5 seconds. Maybe due to lack of complete dptf support linux isn’t doing that, but the larkbox requires it. That could explain why manually reading the temp fixes the problem.

1 Like

I’m spent a little more time looking into kernel code. I was hoping to find a module parameter or kernel command line to replace the ugly while true loop above but no luck.

The thermal zone from which reading the temperature fixes the fan is implemented by int3403_thermal. Although the linux thermal core supports polling, the int340x always registers with the thermal core as interrupt driven. If the int340x driver supported polling, that would probably resolve this bug. But, I’d guess Chuwi is abusing/overloading the ACPI read temp of this thermal zone to do their hardware management.

Also, none of this means their isn’t some other configuration of BIOS settings that might fix this, but be careful modifying sensor 4, you may disable the fan in windows too.

Edit: also i did my analysis of 4.19.132, but int340x is still interrupt only as-of 5.9-rc6.

On my fresh Kali Linux just done that :
#apt-get install thermald
#systemctl enable thermald
#systemctl start thermald
My fan works same as Windows 10

1 Like

Out of curiosity does the fan change state? e.g. cur_state of path type:Fan is 1 only when the fan actually spins:

grep . /sys/class/thermal/cooling_device?/* 2>/dev/null

My fan always reads as on and can’t actually be controlled via sysfs. If yours behaves the same thermald very likely isn’t directly controlling the fan, but instead just tripping the same bug my while loop does.

But, If it works all the same, great! It should also handle thermal throttling if the kernel’s acpi task isn’t already. I’ll try to test too.

Edit: thermald works on my PC, but only with the --exclusive-control flag added. works is relative. It does not control the fan, but it does read the temp for SENS4, which happens to work. E.g. you cannot edit/create thremald’s configuration to change trigger points for the fan.

Also, apparently I cannot reply to the same thread more than 3 times (thanks Chuwi!). So I cannot reply with any more help.