you can check whether your modifications did work:
there should be (probably among others) an entry fan_control. If you “cat” it, it should show a one.
then something failed:
simon@laptop:~$ cd /sys/module/acpi
acpi/ acpi_cpufreq/ acpi_pad/ acpiphp/
simon@laptop:~$ cd /sys/module/acpi/parameters/
acpica_version ec_delay ec_storm_threshold
aml_debug_output ec_event_clearing immediate_undock
ec_busy_polling ec_polling_guard
is the module called acpi, or acpid (note the d)…
stupid me, the module is called thinkpad_acpi, isn’t it:
simon@laptop:/sys/module$ cat thinkpad_acpi/parameters/fan_control
N
so that doesn’t look exactly like a 1…
Should the file in /etc/modprobe.d/acpid.conf and it’s content then be changed to thinkpad_acpi as well? On the other hand ps does show an acpid (which simply could be a daemon to control something):
simon@laptop:/sys/module$ ps aux | grep acpi
root 67 0.0 0.0 0 0 ? S< 21:42 0:00 [acpi_thermal_pm]
root 558 0.0 0.0 0 0 ? S< 21:43 0:00 [ktpacpid]
root 2003 0.0 0.0 4396 1784 ? Ss 21:43 0:00 /usr/sbin/acpid
simon 13313 0.0 0.0 15220 2152 pts/2 R+ 22:06 0:00 grep acpi
I’m loosing track a little…
Well, there’s a difference between the process name and the module name. They don’t need to be in sync, actually, they won’t be in sync. Acpid is the (generic) process for handling acpi events, and the module thinkpad_acpi understands your hardware and translates its events to the generic acpi implementation (might be simplified, but this should be it…)
So, the filename acpid.conf is irrelevant (except for it’s location and the suffix .conf), BUT, inside, the options will have to be
N, I would expect, means “no”, so, no fan control (what ever this means… Might be that the bios is in charge, and no operating system based program, might be it means no fan control at all… I really don’t know… Just give it a try with 1, or even Y
1 Like
I did two reboots, trying 1 and Y. Both led to Y in thinkpad_acpi/parameters/fan_control and now I can again echo any level value without any error message, but still also without any effect. cat-ing always shows level 1 and 250rpm…
So fan control doesn’t seem to work.
yes, sounds like it’s broken. Only one thing. When you started compiling, did the fan actually get faster (acustically), or did the fan sound like always turning at the same speed?
It always stays at level 1, which is not even noticeable. Thus later on the throttling kicks in. I’ll try to see if I can do the uefi update tomorrow to see if it changes anything.
This is really getting off-topic in here 
but the Thinkpads normally have an embedded controller which handles fan control independent of the OS. If you override this by loading some module though you better be sure that it really does what it’s supposed to be…at least this would explain the build failures perfectly.
I assumed so as well. Unfortunately as explained above the fan doesn’t react at all to different CPU loads, leading the CPU to throttle during compilation.
Well so far it does (unfortunately) nothing. :-/
Well one theory was that the throttling caused the segfault and thus the idea to manually try to speed up the fan (which didn’t work). Thus so far we couldn’t verify this theory. If you have an idea for another cause and how to test it, let me know. I’m kind of frustrated by now… 
Did you try to blacklist the module so it won’t take control over the fan at all?
Well, I didn’t activate it until this evening.
Ok I see. And if you try to compile it in a VM from windows where the fan control is supposed to be working?
I don’t have any windows. (would I otherwise bother to compile a google free open source version of FP OS? 
)
Well, but it’s possible your machine suffers in general from an overheating problem due to bad application of thermal paste:
Yet one thing you could try is set the cpu governor to powersave to force it to stay in the low frequency regions. Would take much longer to compile this way I guess but could workaround the issue.
While it obviously can be the fact that the thermal paste was badly applied in my laptop I haven’t experienced any other issues so far (please be also aware that the Yoga 13 is an ideapad, while the Yoga 12 is a thinkpad – so no idea how similar the production steps are at all).
I have tried to change the governor before, but it doesn’t support any other than the one it uses if I recall correctly.
I’ll try to collect some experience from other Yoga 12 owners in thinkpad forums to see how the fan works for them.
It’s just a brand name, quality and investors change. Maybe sending it in for service is also a good approach. If it is out of warranty have a look yourself (p. 81) 
Also possible: Get cheap used desktop hardware as a headless build server you can use with ssh.
Agree. What I wanted to say is that there is not much relation between the Yoga 13 and 12. If it it wasn’t a single incident reported on the forum you linked, but a line problem, it still probably wouldn’t effect the 12 – I believe.
If nothing else helps it might worth a try. It’s younger than a year, so shouldn’t be a problem.
But as mentioned before first I’d like to update the UEFI (which apparently doesn’t work via USB, but only via CD) and to check with other owners if I find some in a thinkpad forum.
I would like to not have to. I hoped that my laptop could fulfil all my needs.
Just for reference, I did the UEFI update to 1.22 and now it’s actually the first time ever that I hear the fan of the laptop. Nevertheless sensors and cat /proc/acpi/ibm/fan still only show level 1 and 257rpm…
Anyway, I hope that this has fixed all thermal issues (still I’m wondering if I should contact support as in the process of trying out building the glue of the rubber feet has melted away and probably the pcb/soldering points don’t like the extreme temperature differences either). I’ll give compiling a new try soon… Thanks to everybody who has helped out so far.
Edit: After more than 7h I finally successfully completed my first build. 