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.
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.
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?
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.
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, 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.
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.
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.
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.
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: thermaldworks 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.