January 15, 2013 at 16:47DSDT spoofing through GRUB2
- Tutorial
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 BIOS level and manifests itself in spontaneous freezes tightly. On average once every few hours. And this is definitely not overheating and not a driver failure. It is treated only by disabling one of the kernels in the BIOS, which for obvious reasons is not suitable. After exhaustive search of all the sources of the problem, I finally found myself in the DSDT curve, which is very typical for second-tier laptop manufacturers. By the way, on a specific laptop model, there is no such information on the Internet at all. In short, DSDT is a piece of BIOS that is responsible for the operation of functions specific to a given laptop or motherboard such as backlight control or coolers and is often buggy and / or oriented to work with Windows. Light methods such as disguise under Win7 did not work when loading, so I had to edit it. Fixing bugs in DSDT did not cause any problems, since I will not deal with this information in bulk in this post. But slipping a table into the kernel was unexpectedly difficult. The system used is Arch Linux, accordingly oriented on their manuals. There are three ways to insert a replacement DSDT into the kernel:
The first method has not been supported almost since the 2.4 kernels, so it is not good. The second is real, but to my shame, the author did not master the recompilation of the kernel with the modified config. If you want, then you need to dig in the direction of getting the diff for .config with the DSDT connected and writing it to PKGBUILD. There will be a desire - I will tell in more detail. 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. For it, you need to install and slightly configure GRUB2. It is set according to the 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 through a directory
And after that
Critical places:
That's all with the config, it seems. After this, we start.
There will be several lines with a description of the progress, there should write about the table that was successfully found:
If not, then somewhere an error. After the reboot, everything should work fine. How to check? The dumbest 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 bootloader - a new way and little described
The first method has not been supported almost since the 2.4 kernels, so it is not good. The second is real, but to my shame, the author did not master the recompilation of the kernel with the modified config. If you want, then you need to dig in the direction of getting the diff for .config with the DSDT connected and writing it to PKGBUILD. There will be a desire - I will tell in more detail. 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. For it, you need to install and slightly configure GRUB2. It is set according to the 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 through a directory
/etc/grub.d. 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 DSDT. It is logical to stick it in
/boot, closer to the bootloader. If the name does not match, then fix it. - Variable
$LIBDIRand path to some library. It depends on the system, you need to check whether the file is where it is indicated.
That's all with the config, it seems. After this, we start.
# grub-mkconfig -o /boot/grub/grub.cfgThere will be several lines with a description of the progress, there should write about the table that was successfully found:
Found custom ACPI table: /boot/dsdt.amlIf not, then somewhere an error. After the reboot, everything should work fine. How to check? The dumbest way is to try recompiling the active DSDT again. If there are no compilation errors, then everything went well.