We control the laptop fan through DSDT in Linux and not only
I do not know why, but I always perceived the cooling systems in laptops as a kind of closed black box. The dullness of the algorithms, according to which the fan began to howl hysterically when the processor was still quite cold, was pretty annoying in many laptops, but it seemed to me that all the parameters there were nailed by manufacturers and you can change them only by picking up the BIOS or just inserting any adjustable resistors into right places. I didn’t want to do either one or the other, so I never even seriously thought about it.
No, of course, I heard about all sorts of programs that can interfere with the management of cooling, and someone seems to be using them successfully, but I personally had no luck with them, or rather, I was not lucky with the iron on which I tried to start them. For example, some time ago I tried to configure fancontrol on a rather old HP nc8430 laptop with Ubuntu. As a result, the famous sensor-detect script could not find a single fan in the system, and without this the fancontrol does not work. At various forums, people periodically appear with similar problems, but no one can really help them.
Then I once again abandoned this topic and returned to it only the other day, when I read reviews, looking for a new laptop for myself, and already seemed to choose the good Sony S15 for almost everyone, as I read about it in one of the reviews, never stops at all, even when exactly you can. I no longer want a constantly noisy laptop, but I don’t want to choose as always, considering that I need 15 ", I don’t want the TN matrix anymore, and the budget is limited. You know how it is. Maybe everything is on it "So fancontrol will start and everything will be fine, but if not? No reports on how to install it on this laptop could be found. This prompted me to once again dig up the topic of fan control software and go through a rather complicated but very exciting quest.
I decided that if I manage to deal with the cooling of my HP, then I will probably cope with the new Sony. If not, have to look for another laptop. Googling a little, I managed to find out that under Windows there is a wonderful program Notebook Hardware Control, it is free, everyone praises it. Well, you have to try. Rebooted in Windows, downloaded, launched - the program really works. You can set the temperature at which the fan is turned off altogether, run at low speed, medium and high, and most importantly, you can set the fan motor power in percent for all three modes. It is power, not revolutions per second, but what difference does it make.
')
It turned out that in this laptop, by default, the lowest revolutions correspond to 55% of power. That is, either the fan is completely silent, or it buzzes quite loudly at its 55%, and when the temperature rises even louder: 70%, 80% and 100%. In this case, he is silent only up to 50 degrees, and then immediately begins to work. The processor is quite hot - Core 2 Duo T7600, less than 50 degrees it happens only immediately after switching on, then the temperature quickly becomes higher, even at zero load, and already does not want to fall below 50 C in any way, only if you unwind the fan to full and leave so for a few minutes, and then when the room is not very hot. At the default 55%, the fan simply has no chance to cool the processor back below 50 C. Although it may be necessary to simply try to change the thermal paste, but now it's not about that.
With the help of the program, I just set the minimum power to 30% and raised the minimum temperature at which the fan turns on to 60 C. The body temperature at the same time almost did not change to the touch, as it was quite hot, it remained, but it became much quieter. During the daytime, a fan at 30% power can be heard only if you bring an ear to it. At night in a quiet room it is quite audible, but tolerable. It is much better than it was. If you raise the minimum temperature a little more and put the processor and video card into power saving mode, you can get an absolutely quiet laptop, only the hard drive can be heard rotating, but this can be solved only by replacing it with an SSD, which in general would be good to do. In short, it is possible to fully control the temperature and noise. There would be a fairy tale end, but this is under Windows, and I need it under Linux!
Under Linux there is no such program. And how it works, I honestly still do not fully understand, and at that time I was there only peeped on keywords that were very useful later: ACPI and DSDT. I'll come back to them later. In the meantime, I rebooted back to Ubuntu and began to carefully study the pre-googled path in sysfs: / sys / class / thermal. It turned out that:
As many as 10 cooling_devices and 6 thermal_zones. With thermal zones, everything is more or less clear; the temperatures of the CPU, GPU, some other three points are not particularly important. And the last thermal_zone5 is not at all the temperature, as it turned out by experience, but the current fan power. Bravo HP! Now I understand why sensors-detect did not find anything, it’s such a mess that the devil’s leg breaks. This is how you can simply change any power in thermal_zone5 / temp. The file is read-only, which is understandable.
Now let's look at cooling_device *, why are there 10 of them? Inside each folder there is something like this:
In the type files for cooling_device, Fan is written from 0 to 6, Processor is written in 7-8, and LCD is written in 9-8. Hmm, I know for sure that I have only one fan in my laptop. Processors, one can say, really two and there is one LCD screen, this is true. But these are not cooling devices, why are they here? Okay, we will try to understand further in this mess. In cur_state files, it is either 0 or 1. Yeah, it looks like some sort of spreading bitmask. If you try to write zeros to all cur_state with “echo 0 | sudo tee / sys / thermal / cooling_device * / cur_state ", then the fan will stop. And if you write a unit in cooling_device3 / cur_state, then the fan will spin by 55%. Hooray, I managed to control the fan manually in Ubunt. There could be some demon on the Python, which would put the necessary power at certain temperatures, but firstly, only “standard” powers from the set of 0, 55, 70, 80, 100 can be set this way, and now I It is necessary 30. And secondly, something else in the system changes these bits. We should try to figure out what exactly this is doing and how it can be influenced. In other words, “we have to go deeper”. Then I remembered the first keyword suggested by that Windows program: ACPI.
It seems there is such a demon in Ubunt acpid. Maybe he controls all this? But no, judging by the description, he only watches pressing the off button, lowering the lid, and all that. Indeed, even if it is stopped, the fan will continue to work as if nothing had happened, just as the power varies depending on the temperature. But I also saw in the program that there is a lot of things in ACPI, including a certain DSDT (Differentiated System Description Table) table, which is not really a table, but rather a code in a language called AML (ACPI Machine Language) . More precisely, the code is written in ASL (ACPI Source Language), and then compiled into AML, that is, AML is a bytecode, which, in turn, is easy to decompile back into ASL. I hope I did not confuse you, dear readers. In addition to DSDT, there are other tables - SSDT, etc., they also have AML-code and data, but the most interesting is usually contained in DSDT. In the code of these tables there is a description of all the devices of the computer and the algorithms for controlling their power supply, including, of course, the fan.
Once there is a bytecode, then there must be an interpreter somewhere that will execute it. Indeed, the core of each OS that supports ACPI must contain a virtual machine to execute the DSLT AML code and other tables. There is it in Linux. So there was something that changes these bitiki in cur_state files, this is the kernel itself.
Table code can be taken in sysfs, in the / sys / firmware / acpi / tables / directory. But first you need to install the Intel compiler for ASL / AML, on Debian-based systems this is done like this: “sudo apt-get install iasl”. Then simply by making “sudo cat / sys / firmware / acpi / tables / DSDT> /tmp/dsdt.dat” and “iasl -d /tmp/dsdt.dat”, we will get the source code for DSDT in the /tmp/dsdt.dsl file . ASL, though difficult to read, is a rather simple language in itself, apparently, specially designed so that it is easier to write its interpreter, since for each OS it should be its own. I pretty quickly figured out how to change the fan power, just looking for the very power (55, 70, 80, 100) transferring to hexadecimal system and they were immediately found. The build is done with the iasl -tc /tmp/dsdt.dsl command.
At the same time errors and warnings can come out, and in those lines that you did not touch. Everyone says that this is happening because almost all the BIOS manufacturers use the compiler from Microsoft, and he just ignores many errors, Intel's much more severe. But I have a version that programmers simply refuse to write normally in this stupid language. Among other things, I found in my DSDT a rather annoying typo in the name of the method that returns the current screen backlight level because of this, the kernel always cursed when loading “[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness”, and Out of sleep, the backlight settings always went astray. So even if everything is all right with cooling, you still have a reason to look at your DSDT. The network is full of recipes for how to correct certain errors in DSDT, here I will not dwell on this in detail.
It turns out that if we can decompile, edit and compile back into DSDT bytecode and other tables, then we can do anything with the power of any devices. Now you just need to somehow slip the patched DSDT into the kernel. It is dangerous to do this, you can burn something through negligence, so think 100 times if you need it before you do anything described below.
The entire AML code is stored in the BIOS and the kernel, by default, takes it from there. The first thing that comes to mind is to make your BIOS image with the patched DSDT and flash it. The risk of getting a brick is very high, but with a successful outcome, all changes will be immediately available in all the operating systems that you use. But, of course, there are better and safer ways.
Before writing this article, I looked at what was on Habré on this topic and was very jealous of how easy it is to do in FreeBSD .
For Linux, HowTo is often advised to rebuild the kernel from source by integrating your DSDT there. There are many such instructions, there is nothing complicated, there is about it on Habré too , so I won’t repeat it again.
Previously, before the 2.6 version of the kernel, there was a convenient way to boot through the initrd, but then Linus came and said that it was bad to do so, but it was either good or nothing, and the method was removed. Linus will have to believe, since he says that it is necessary, it means it is necessary.
They say that it is still possible to transfer the required DSDT via the GRUB2 kernel. I really didn't want to rebuild the core and I decided to try it. At first, I only wrote DSDT to the config file, the author of that article worked this way, but the kernel didn’t load it at all, it had something like this in the log:
Accordingly, ACPI did not work at all. A terrible thing, by the way. Wi-fi did not work for me at this, the shutdown button turned off everything at once, and did not start a normal shutdown. In short, you can not use it at all. Then I tried to transfer all the tables in parameters in general, it turned out like this:
This time there was an attempt to load DSDT, but apparently there is some kind of link to the FACS table, which cannot be resolved in this environment. Having suffered a bit with this, after 20 system reboots, I did not manage to make everything work in this way. Spitting on everything, put the core to reassemble and went to bed, in the morning everything worked as it should:
It would be possible to open champagne and celebrate success, but in my head it was a thought that one could do something better. After all, that program under Windows allowed me to change everything on the go. It turns out that it can also be done in Linux, here is the documentation . This method is almost never written on the forums, and the method is really wonderful. Usually, it is necessary to redefine one or two methods, and if at the same time you do not need to reboot, then this is a beauty in general.
I prepared a .aml file with a rewritten method of fan management and, happily anticipating how everything will work fine now, I type “sudo cat ./fan-speeds.aml> / sys / kernel / debug / acpi / custom_method” and ... I get “zsh: permission denied : / sys / kernel / debug / acpi / custom_method ". How is permission denied? I did not forget to make sudo, the / sys / kernel / debug / acpi / directory judging by the permissions is open for writing to root, there are no immutable attributes and other things there. WTF? It turned out that this feature was declared a hole, since supposedly there are such environments where the root can not do everything. For example, it cannot load kernel modules after the system has fully booted. Why and to whom it is necessary, I honestly even suppose to be afraid, but true. It seems that in any Ubunt root, they can definitely do anything, so it’s not very clear why their Security Team also believes that this is a very serious vulnerability. Fortunately, they didn’t cut it out of the kernel at all, but simply turned it off in the default config and made it possible to load separately as a module. Well, to assemble one module is not the same as the whole kernel, and the connection of modules to us in Ubunt, thank God, has not been banned yet.
I already had the kernel sources, so according to the instructions I assembled, installed and enabled the custom_method module. Now everything worked just fine.
It remains as it should, and not diagonally read the ACPI specification at your leisure and think about what else can be improved in a laptop. I’m not exactly afraid of software problems in notebook cooling systems now. I hope that you now too, if you suddenly feared before.
No, of course, I heard about all sorts of programs that can interfere with the management of cooling, and someone seems to be using them successfully, but I personally had no luck with them, or rather, I was not lucky with the iron on which I tried to start them. For example, some time ago I tried to configure fancontrol on a rather old HP nc8430 laptop with Ubuntu. As a result, the famous sensor-detect script could not find a single fan in the system, and without this the fancontrol does not work. At various forums, people periodically appear with similar problems, but no one can really help them.
Then I once again abandoned this topic and returned to it only the other day, when I read reviews, looking for a new laptop for myself, and already seemed to choose the good Sony S15 for almost everyone, as I read about it in one of the reviews, never stops at all, even when exactly you can. I no longer want a constantly noisy laptop, but I don’t want to choose as always, considering that I need 15 ", I don’t want the TN matrix anymore, and the budget is limited. You know how it is. Maybe everything is on it "So fancontrol will start and everything will be fine, but if not? No reports on how to install it on this laptop could be found. This prompted me to once again dig up the topic of fan control software and go through a rather complicated but very exciting quest.
As it is in windows
I decided that if I manage to deal with the cooling of my HP, then I will probably cope with the new Sony. If not, have to look for another laptop. Googling a little, I managed to find out that under Windows there is a wonderful program Notebook Hardware Control, it is free, everyone praises it. Well, you have to try. Rebooted in Windows, downloaded, launched - the program really works. You can set the temperature at which the fan is turned off altogether, run at low speed, medium and high, and most importantly, you can set the fan motor power in percent for all three modes. It is power, not revolutions per second, but what difference does it make.
')
It turned out that in this laptop, by default, the lowest revolutions correspond to 55% of power. That is, either the fan is completely silent, or it buzzes quite loudly at its 55%, and when the temperature rises even louder: 70%, 80% and 100%. In this case, he is silent only up to 50 degrees, and then immediately begins to work. The processor is quite hot - Core 2 Duo T7600, less than 50 degrees it happens only immediately after switching on, then the temperature quickly becomes higher, even at zero load, and already does not want to fall below 50 C in any way, only if you unwind the fan to full and leave so for a few minutes, and then when the room is not very hot. At the default 55%, the fan simply has no chance to cool the processor back below 50 C. Although it may be necessary to simply try to change the thermal paste, but now it's not about that.
With the help of the program, I just set the minimum power to 30% and raised the minimum temperature at which the fan turns on to 60 C. The body temperature at the same time almost did not change to the touch, as it was quite hot, it remained, but it became much quieter. During the daytime, a fan at 30% power can be heard only if you bring an ear to it. At night in a quiet room it is quite audible, but tolerable. It is much better than it was. If you raise the minimum temperature a little more and put the processor and video card into power saving mode, you can get an absolutely quiet laptop, only the hard drive can be heard rotating, but this can be solved only by replacing it with an SSD, which in general would be good to do. In short, it is possible to fully control the temperature and noise. There would be a fairy tale end, but this is under Windows, and I need it under Linux!
How is it under linux
Under Linux there is no such program. And how it works, I honestly still do not fully understand, and at that time I was there only peeped on keywords that were very useful later: ACPI and DSDT. I'll come back to them later. In the meantime, I rebooted back to Ubuntu and began to carefully study the pre-googled path in sysfs: / sys / class / thermal. It turned out that:
lrwxrwxrwx 1 root root 0 Jan 11 2013 cooling_device0 lrwxrwxrwx 1 root root 0 Jan 11 2013 cooling_device1 lrwxrwxrwx 1 root root 0 Jan 11 2013 cooling_device2 lrwxrwxrwx 1 root root 0 Jan 11 2013 cooling_device3 lrwxrwxrwx 1 root root 0 Jan 11 2013 cooling_device4 lrwxrwxrwx 1 root root 0 Jan 11 2013 cooling_device5 lrwxrwxrwx 1 root root 0 Jan 11 2013 cooling_device6 lrwxrwxrwx 1 root root 0 Jan 11 2013 cooling_device7 lrwxrwxrwx 1 root root 0 Jan 11 2013 cooling_device8 lrwxrwxrwx 1 root root 0 Jan 10 21:26 cooling_device9 lrwxrwxrwx 1 root root 0 Jan 11 2013 thermal_zone0 lrwxrwxrwx 1 root root 0 Jan 11 2013 thermal_zone1 lrwxrwxrwx 1 root root 0 Jan 11 2013 thermal_zone2 lrwxrwxrwx 1 root root 0 Jan 11 2013 thermal_zone3 lrwxrwxrwx 1 root root 0 Jan 11 2013 thermal_zone4 lrwxrwxrwx 1 root root 0 Jan 11 2013 thermal_zone5 As many as 10 cooling_devices and 6 thermal_zones. With thermal zones, everything is more or less clear; the temperatures of the CPU, GPU, some other three points are not particularly important. And the last thermal_zone5 is not at all the temperature, as it turned out by experience, but the current fan power. Bravo HP! Now I understand why sensors-detect did not find anything, it’s such a mess that the devil’s leg breaks. This is how you can simply change any power in thermal_zone5 / temp. The file is read-only, which is understandable.
Now let's look at cooling_device *, why are there 10 of them? Inside each folder there is something like this:
drwxr-xr-x 2 root root 0 Jan 10 21:35 power -rw-r--r-- 1 root root 4.0K Jan 10 21:35 cur_state lrwxrwxrwx 1 root root 0 Jan 10 21:35 device -r--r--r-- 1 root root 4.0K Jan 10 21:35 max_state lrwxrwxrwx 1 root root 0 Jan 11 2013 subsystem -r--r--r-- 1 root root 4.0K Jan 10 21:35 type -rw-r--r-- 1 root root 4.0K Jan 11 2013 uevent In the type files for cooling_device, Fan is written from 0 to 6, Processor is written in 7-8, and LCD is written in 9-8. Hmm, I know for sure that I have only one fan in my laptop. Processors, one can say, really two and there is one LCD screen, this is true. But these are not cooling devices, why are they here? Okay, we will try to understand further in this mess. In cur_state files, it is either 0 or 1. Yeah, it looks like some sort of spreading bitmask. If you try to write zeros to all cur_state with “echo 0 | sudo tee / sys / thermal / cooling_device * / cur_state ", then the fan will stop. And if you write a unit in cooling_device3 / cur_state, then the fan will spin by 55%. Hooray, I managed to control the fan manually in Ubunt. There could be some demon on the Python, which would put the necessary power at certain temperatures, but firstly, only “standard” powers from the set of 0, 55, 70, 80, 100 can be set this way, and now I It is necessary 30. And secondly, something else in the system changes these bits. We should try to figure out what exactly this is doing and how it can be influenced. In other words, “we have to go deeper”. Then I remembered the first keyword suggested by that Windows program: ACPI.
ACPI
It seems there is such a demon in Ubunt acpid. Maybe he controls all this? But no, judging by the description, he only watches pressing the off button, lowering the lid, and all that. Indeed, even if it is stopped, the fan will continue to work as if nothing had happened, just as the power varies depending on the temperature. But I also saw in the program that there is a lot of things in ACPI, including a certain DSDT (Differentiated System Description Table) table, which is not really a table, but rather a code in a language called AML (ACPI Machine Language) . More precisely, the code is written in ASL (ACPI Source Language), and then compiled into AML, that is, AML is a bytecode, which, in turn, is easy to decompile back into ASL. I hope I did not confuse you, dear readers. In addition to DSDT, there are other tables - SSDT, etc., they also have AML-code and data, but the most interesting is usually contained in DSDT. In the code of these tables there is a description of all the devices of the computer and the algorithms for controlling their power supply, including, of course, the fan.
Once there is a bytecode, then there must be an interpreter somewhere that will execute it. Indeed, the core of each OS that supports ACPI must contain a virtual machine to execute the DSLT AML code and other tables. There is it in Linux. So there was something that changes these bitiki in cur_state files, this is the kernel itself.
Table code can be taken in sysfs, in the / sys / firmware / acpi / tables / directory. But first you need to install the Intel compiler for ASL / AML, on Debian-based systems this is done like this: “sudo apt-get install iasl”. Then simply by making “sudo cat / sys / firmware / acpi / tables / DSDT> /tmp/dsdt.dat” and “iasl -d /tmp/dsdt.dat”, we will get the source code for DSDT in the /tmp/dsdt.dsl file . ASL, though difficult to read, is a rather simple language in itself, apparently, specially designed so that it is easier to write its interpreter, since for each OS it should be its own. I pretty quickly figured out how to change the fan power, just looking for the very power (55, 70, 80, 100) transferring to hexadecimal system and they were immediately found. The build is done with the iasl -tc /tmp/dsdt.dsl command.
At the same time errors and warnings can come out, and in those lines that you did not touch. Everyone says that this is happening because almost all the BIOS manufacturers use the compiler from Microsoft, and he just ignores many errors, Intel's much more severe. But I have a version that programmers simply refuse to write normally in this stupid language. Among other things, I found in my DSDT a rather annoying typo in the name of the method that returns the current screen backlight level because of this, the kernel always cursed when loading “[Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness”, and Out of sleep, the backlight settings always went astray. So even if everything is all right with cooling, you still have a reason to look at your DSDT. The network is full of recipes for how to correct certain errors in DSDT, here I will not dwell on this in detail.
It turns out that if we can decompile, edit and compile back into DSDT bytecode and other tables, then we can do anything with the power of any devices. Now you just need to somehow slip the patched DSDT into the kernel. It is dangerous to do this, you can burn something through negligence, so think 100 times if you need it before you do anything described below.
How to make the kernel perform patched DSDT
The entire AML code is stored in the BIOS and the kernel, by default, takes it from there. The first thing that comes to mind is to make your BIOS image with the patched DSDT and flash it. The risk of getting a brick is very high, but with a successful outcome, all changes will be immediately available in all the operating systems that you use. But, of course, there are better and safer ways.
Before writing this article, I looked at what was on Habré on this topic and was very jealous of how easy it is to do in FreeBSD .
For Linux, HowTo is often advised to rebuild the kernel from source by integrating your DSDT there. There are many such instructions, there is nothing complicated, there is about it on Habré too , so I won’t repeat it again.
Previously, before the 2.6 version of the kernel, there was a convenient way to boot through the initrd, but then Linus came and said that it was bad to do so, but it was either good or nothing, and the method was removed. Linus will have to believe, since he says that it is necessary, it means it is necessary.
They say that it is still possible to transfer the required DSDT via the GRUB2 kernel. I really didn't want to rebuild the core and I decided to try it. At first, I only wrote DSDT to the config file, the author of that article worked this way, but the kernel didn’t load it at all, it had something like this in the log:
ACPI Exception: AE_NO_ACPI_TABLES, While loading namespace from ACPI tables (20110623/tbxface-642) ACPI: Unable to load the System Description Tables PM: Registering ACPI NVS region at d7fe5600 (76288 bytes) ACPI: Interpreter disabled. Accordingly, ACPI did not work at all. A terrible thing, by the way. Wi-fi did not work for me at this, the shutdown button turned off everything at once, and did not start a normal shutdown. In short, you can not use it at all. Then I tried to transfer all the tables in parameters in general, it turned out like this:
ACPI: RSDP 0009f500 00024 (v03 ) ACPI: XSDT d74ad95c 00084 (v01 00000000 00000000) ACPI: SSDT d74aca78 004B9 (v01 HP CpuPm 00003000 INTL 20100528) ACPI: SSDT d74acf31 000A0 (v01 HP Cpu1Tst 00003000 INTL 20100528) ACPI: SSDT d74acfd1 00232 (v01 HP Cpu0Tst 00003000 INTL 20100528) ACPI: SSDT d74ad203 002E0 (v01 HP HPQSAT 00000001 INTL 20100528) ACPI: SSDT d74ad4e3 00059 (v01 HP HPQNLP 00000001 INTL 20100528) ACPI: TCPA d74ad53c 00032 (v02 HP 30A3 00000001 HP 00000001) ACPI: MCFG d74ad56e 0003C (v01 HP 30A3 00000001 HP 00000001) ACPI: APIC d74ad5aa 00068 (v01 HP 30A3 00000001 HP 00000001) ACPI: HPET d74ad612 00038 (v01 HP 30A3 00000001 HP 00000001) ACPI: SLIC d74ad64a 00176 (v01 HPQOEM SLIC-MPC 00000001 HP 00000001) ACPI: FACS d74ad7c0 00040 ACPI: FACP d74ad800 000F4 (v04 HP 30A3 00000003 HP 00000001) ACPI: DSDT d749d420 0F658 (v01 HP nc8430 00010000 INTL 20100528) ACPI Error: Null physical address for ACPI table [FACS] (20110623/tbutils-459) <...> ACPI Warning: Could not map the FACS table (20110623/utxface-168) ACPI: Unable to enable ACPI This time there was an attempt to load DSDT, but apparently there is some kind of link to the FACS table, which cannot be resolved in this environment. Having suffered a bit with this, after 20 system reboots, I did not manage to make everything work in this way. Spitting on everything, put the core to reassemble and went to bed, in the morning everything worked as it should:
ACPI: RSDP 000f96a0 00024 (v02 HP ) ACPI: XSDT d7fe57c8 0007C (v01 HPQOEM SLIC-MPC 00000001 HP 00000001) ACPI: FACP d7fe5684 000F4 (v04 HP 30A3 00000003 HP 00000001) ACPI: Override [DSDT- nc8430], this is unsafe: tainting kernel ACPI: DSDT @ 0xd7fe5acc Table override, replaced with: ACPI: DSDT c181c9e0 0F658 (v01 HP nc8430 00010000 INTL 20100528) ACPI: FACS d7ff7e80 00040 ACPI: SLIC d7fe5844 00176 (v01 HPQOEM SLIC-MPC 00000001 HP 00000001) ACPI: HPET d7fe59bc 00038 (v01 HP 30A3 00000001 HP 00000001) ACPI: APIC d7fe59f4 00068 (v01 HP 30A3 00000001 HP 00000001) ACPI: MCFG d7fe5a5c 0003C (v01 HP 30A3 00000001 HP 00000001) ACPI: TCPA d7fe5a98 00032 (v02 HP 30A3 00000001 HP 00000001) ACPI: SSDT d7ff5e97 00059 (v01 HP HPQNLP 00000001 MSFT 0100000E) ACPI: SSDT d7ff5ef0 00326 (v01 HP HPQSAT 00000001 MSFT 0100000E) ACPI: SSDT d7ff6a6b 0025F (v01 HP Cpu0Tst 00003000 INTL 20060317) ACPI: SSDT d7ff6cca 000A6 (v01 HP Cpu1Tst 00003000 INTL 20060317) ACPI: SSDT d7ff6d70 004D7 (v01 HP CpuPm 00003000 INTL 20060317) <...> ACPI: Interpreter enabled It would be possible to open champagne and celebrate success, but in my head it was a thought that one could do something better. After all, that program under Windows allowed me to change everything on the go. It turns out that it can also be done in Linux, here is the documentation . This method is almost never written on the forums, and the method is really wonderful. Usually, it is necessary to redefine one or two methods, and if at the same time you do not need to reboot, then this is a beauty in general.
I prepared a .aml file with a rewritten method of fan management and, happily anticipating how everything will work fine now, I type “sudo cat ./fan-speeds.aml> / sys / kernel / debug / acpi / custom_method” and ... I get “zsh: permission denied : / sys / kernel / debug / acpi / custom_method ". How is permission denied? I did not forget to make sudo, the / sys / kernel / debug / acpi / directory judging by the permissions is open for writing to root, there are no immutable attributes and other things there. WTF? It turned out that this feature was declared a hole, since supposedly there are such environments where the root can not do everything. For example, it cannot load kernel modules after the system has fully booted. Why and to whom it is necessary, I honestly even suppose to be afraid, but true. It seems that in any Ubunt root, they can definitely do anything, so it’s not very clear why their Security Team also believes that this is a very serious vulnerability. Fortunately, they didn’t cut it out of the kernel at all, but simply turned it off in the default config and made it possible to load separately as a module. Well, to assemble one module is not the same as the whole kernel, and the connection of modules to us in Ubunt, thank God, has not been banned yet.
I already had the kernel sources, so according to the instructions I assembled, installed and enabled the custom_method module. Now everything worked just fine.
It remains as it should, and not diagonally read the ACPI specification at your leisure and think about what else can be improved in a laptop. I’m not exactly afraid of software problems in notebook cooling systems now. I hope that you now too, if you suddenly feared before.
Source: https://habr.com/ru/post/165401/
All Articles