Substitution DSDT via GRUB2
Why is all this necessary? The reason is that my current Gigabyte Q1105M laptop is unstable under Linux. The problem is clearly somewhere at the level of BIOS and manifests itself in spontaneous hangs tightly. On average once every few hours. And this is definitely not overheating and no driver failure. It is treated only by turning off one of the cores in BIOS, which for obvious reasons is no good. A complete exhaustive search of all the sources of the problem finally ended up in the DSDT curve, which is quite typical for the second-tier notebook manufacturers. By the way, there is no such information on the Internet for a specific laptop model at all. In short, the DSDT is a piece of BIOS that is responsible for the operation of functions specific to this laptop or motherboard, such as lighting control or coolers, and is often buggy and / or Windows-oriented. Light-type methods of masking under Win7 when loading did not roll, so I had to edit. Correction of bugs in DSDT did not cause any special problems, the benefit of information on this topic in bulk and in this post I will not touch on this. But it was unexpectedly difficult to slip the table into the kernel. The system used - Arch Linux, respectively, guided by their manuals. There are three ways to insert a replacement DSDT core:
The first method is not supported almost since the time of 2.4 kernels, so it is not suitable. The second is real, but to my shame, the author did not master the recompilation of the kernel with the modified config. If there is a desire, then it is necessary to dig in the direction of getting a diff for .config with DSDT connected and prescribing it in the PKGBUILD. There will be a desire - I will tell you more. The method is wildly cumbersome and inconvenient and takes time to recompile the kernel after each system update. The third method is the newest and most convenient, but for some reason is not described in the Arch Wiki. It requires installing and slightly adjusting GRUB2. It is put on a manual without a single problem, the GRUB-legacy config is picked up automatically. Reboot, check - everything should work. GRUB2 is configured in a rather wild way via the
And after that
Critical places:
On this with a config, everything seems to be. After that, run
There will be several lines describing the progress, there should write about a successfully found table:
If not, then there is an error somewhere. After the reboot, everything should work fine. How to check? The stupidest way is to try recompiling the active DSDT again. If there are no compilation errors, then everything went well.
- initrd
- Compile to kernel
- Through the loader - a new way and where few is described
The first method is not supported almost since the time of 2.4 kernels, so it is not suitable. The second is real, but to my shame, the author did not master the recompilation of the kernel with the modified config. If there is a desire, then it is necessary to dig in the direction of getting a diff for .config with DSDT connected and prescribing it in the PKGBUILD. There will be a desire - I will tell you more. The method is wildly cumbersome and inconvenient and takes time to recompile the kernel after each system update. The third method is the newest and most convenient, but for some reason is not described in the Arch Wiki. It requires installing and slightly adjusting GRUB2. It is put on a manual without a single problem, the GRUB-legacy config is picked up automatically. Reboot, check - everything should work. GRUB2 is configured in a rather wild way via the
/etc/grub.d directory. There you need to create a config for connecting DSDT:/etc/grub.d/01_acpi
#! /bin/sh -e # Uncomment to load custom ACPI table GRUB_CUSTOM_ACPI="/boot/dsdt.aml" # DON'T MODIFY ANYTHING BELOW THIS LINE! libdir=/usr/share . ${libdir}/grub/grub-mkconfig_lib # Load custom ACPI table if [ x${GRUB_CUSTOM_ACPI} != x ] && [ -f ${GRUB_CUSTOM_ACPI} ] \ && is_path_readable_by_grub ${GRUB_CUSTOM_ACPI}; then echo "Found custom ACPI table: ${GRUB_CUSTOM_ACPI}" >&2 prepare_grub_to_access_device `${grub_probe} --target=device ${GRUB_CUSTOM_ACPI}` | sed -e "s/^/ /" cat << EOF acpi (\$root)`make_system_path_relative_to_its_root ${GRUB_CUSTOM_ACPI}` EOF fi And after that
# chmod a+x /etc/grub.d/01_acpiCritical places:
- The path to the DSDT. It is logical to put it in
/boot, closer to the bootloader. If the name does not match - then fix it. - Variable
$LIBDIRand the path to a library. It depends on the system, it is necessary to check whether the file is there where indicated.
On this with a config, everything seems to be. After that, run
# grub-mkconfig -o /boot/grub/grub.cfgThere will be several lines describing the progress, there should write about a successfully found table:
Found custom ACPI table: /boot/dsdt.amlIf not, then there is an error somewhere. After the reboot, everything should work fine. How to check? The stupidest way is to try recompiling the active DSDT again. If there are no compilation errors, then everything went well.
')
Source: https://habr.com/ru/post/165897/
All Articles