Compaq Presario SR1000 / SR1116FR, MSI MS-6577 (Xenon) Gamila/Giovani/Neon series
ACPI fix!
Yes, you read that right, the bug that HP/Compaq never fixed is finally no more, 16 years later. You probably don't care but here it is anyway.
Bug
Basically the bug is as follow: you want to use Linux on this machine, but it doesn't power off when you shut it down, you cannot put it to sleep, nouveau driver for NVidia GPUs doesn't load, etc…
At boot, you may be greeted by the following message:
(the date and revision will vary depending on the version of the kernel you are using, but it's still an issue in 2021)
Basically, ACPI is broken. This machine of course supports ACPI, but for some reason the Linux kernel cannot find the RSDP.
RSDP is the pointer to the ACPI RSDT table, the first ACPI table that gets loaded. This pointer is found in the first MiB of memory by looking for the "RSD PTR " string. If you dump your memory, it is actually present… well, where's the problem then?
The problem lies in the fact that the ACPI on this machine is version 1.0, there's no support for version 2.0, however, the RSDP declares revision 2. Revision 2 is only used for ACPI version 2.0 or higher, ACPI 1.0 should have revision 0 in the RSDP.
So Linux sees this, tries to parse the RSDP as the extended variant for ACPI 2.0 or newer… and obviously fails. Actually it doesn't really fail, it's just that it tries to validate the checksum for the extended structure and of course it's not correct. The checksum for the base structure is good, it is computed at boot time by the BIOS.
Workaround
One workaround is to disable the checksum in the "drivers/acpi/acpica/tbxfroot.c" file of the Linux kernel and rebuild it. It works, but it's not really an easy and nice way to do it and you have to do that for each kernel update.
Another workaround is to use the "acpi_rsdp" kernel command line parameter. Its purpose is to point to the RSDP when hot-loading a kernel with kexec under certain circumstances which do not apply in our case, however a nice side effect is that it doesn't go through validating the RSDP (I'm not sure if it's an oversight of the developer that added this feature but it plays in our favor).
The offset in memory for the RSDP in version 3.26 of the BIOS (last one released by HP) is 0xf7f70, so basically you have to add "acpi_rsdp=0xf7f70" to the kernel command line parameter (appending it to "GRUB_CMDLINE_LINUX_DEFAULT" of "/etc/default/grub" and regenerating the grub configuration with `update-grub2` for example).
Note that the kernel still thinks the machine is ACPI 2.0 compliant and will try to load the XSDT table by default (which doesn't exist in ACPI 1.0) instead of the RSDT table, so you also have to append "acpi=rsdt" to force using the RSDT table.
After that your system should work properly.
Actual BIOS fix
But… can we actually fix the bug instead of relying on a workaround? Yes! Just gotta edit the BIOS.
Not going into too many details but basically you have to extract the "System BIOS" part of the BIOS image using Award BIOS Editor (awdbedit), and then open the "System BIOS" with a hex editor, find the "RSD PTR " string, and replace the 0x02 right after "HP-CPC" by 0x00, save, and inject back into the original BIOS image with Award BIOS Editor.
While I was at it, and because at first I didn't know what was the exact problem, I remember fixing a few things in the ACPI tables, basically extracting the "ACPI table" part, decompiling with `iasl`, fixing the AML, recompiling and reinjecting into the original BIOS image.
Also, to differentiate between the buggy BIOS and the fixed BIOS, I incremented the version number from 3.26 to 3.27.
In order to dump and flash the BIOS I often like using Flashrom when I can… turns out the EEPROM on that board isn't supported properly, so here's also a patch for Flashrom to support it (this one you have to recompile manually).
References:
https://bugs.launchpad.net/ubuntu/+s...el/+bug/446641
https://wiki.osdev.org/RSDP
https://git.kernel.org/pub/scm/linux...ica/tbxfroot.c
ACPI fix!
Yes, you read that right, the bug that HP/Compaq never fixed is finally no more, 16 years later. You probably don't care but here it is anyway.
Bug
Basically the bug is as follow: you want to use Linux on this machine, but it doesn't power off when you shut it down, you cannot put it to sleep, nouveau driver for NVidia GPUs doesn't load, etc…
At boot, you may be greeted by the following message:
Code:
[ 0.000000] ACPI Error: A valid RSDP was not found 20090521 tbxfroot-219
Basically, ACPI is broken. This machine of course supports ACPI, but for some reason the Linux kernel cannot find the RSDP.
RSDP is the pointer to the ACPI RSDT table, the first ACPI table that gets loaded. This pointer is found in the first MiB of memory by looking for the "RSD PTR " string. If you dump your memory, it is actually present… well, where's the problem then?
The problem lies in the fact that the ACPI on this machine is version 1.0, there's no support for version 2.0, however, the RSDP declares revision 2. Revision 2 is only used for ACPI version 2.0 or higher, ACPI 1.0 should have revision 0 in the RSDP.
So Linux sees this, tries to parse the RSDP as the extended variant for ACPI 2.0 or newer… and obviously fails. Actually it doesn't really fail, it's just that it tries to validate the checksum for the extended structure and of course it's not correct. The checksum for the base structure is good, it is computed at boot time by the BIOS.
Workaround
One workaround is to disable the checksum in the "drivers/acpi/acpica/tbxfroot.c" file of the Linux kernel and rebuild it. It works, but it's not really an easy and nice way to do it and you have to do that for each kernel update.
Another workaround is to use the "acpi_rsdp" kernel command line parameter. Its purpose is to point to the RSDP when hot-loading a kernel with kexec under certain circumstances which do not apply in our case, however a nice side effect is that it doesn't go through validating the RSDP (I'm not sure if it's an oversight of the developer that added this feature but it plays in our favor).
The offset in memory for the RSDP in version 3.26 of the BIOS (last one released by HP) is 0xf7f70, so basically you have to add "acpi_rsdp=0xf7f70" to the kernel command line parameter (appending it to "GRUB_CMDLINE_LINUX_DEFAULT" of "/etc/default/grub" and regenerating the grub configuration with `update-grub2` for example).
Note that the kernel still thinks the machine is ACPI 2.0 compliant and will try to load the XSDT table by default (which doesn't exist in ACPI 1.0) instead of the RSDT table, so you also have to append "acpi=rsdt" to force using the RSDT table.
After that your system should work properly.
Actual BIOS fix
But… can we actually fix the bug instead of relying on a workaround? Yes! Just gotta edit the BIOS.
Not going into too many details but basically you have to extract the "System BIOS" part of the BIOS image using Award BIOS Editor (awdbedit), and then open the "System BIOS" with a hex editor, find the "RSD PTR " string, and replace the 0x02 right after "HP-CPC" by 0x00, save, and inject back into the original BIOS image with Award BIOS Editor.
While I was at it, and because at first I didn't know what was the exact problem, I remember fixing a few things in the ACPI tables, basically extracting the "ACPI table" part, decompiling with `iasl`, fixing the AML, recompiling and reinjecting into the original BIOS image.
Also, to differentiate between the buggy BIOS and the fixed BIOS, I incremented the version number from 3.26 to 3.27.
In order to dump and flash the BIOS I often like using Flashrom when I can… turns out the EEPROM on that board isn't supported properly, so here's also a patch for Flashrom to support it (this one you have to recompile manually).
References:
https://bugs.launchpad.net/ubuntu/+s...el/+bug/446641
https://wiki.osdev.org/RSDP
https://git.kernel.org/pub/scm/linux...ica/tbxfroot.c