Overwrite FACP ACPI Table to Fix Missing ASPM

Question

I have bought a HP EliteBook 2570p notebook. The energy consumption is a bit high because HP has disabled ASPM in the ACPI FACP table. As described here http://forum.techinferno.com/hp-busines … #post38399, this problem can be solved by overwriting the wrong values. I think the person there is using a FreeDOS environment before booting the other operating systems to write directly in the memory. I though it should also be possible to load a patched FACP table like a patched DSDT table. So I extracted the table:
acpidump > acpi.dat
acpixtract -a acpi.dat
iasl -d facp.dat
In facp.dst I changed the value 'PCIe ASPM Not Supported (V4)' from 1 to 0 and recompiled the table:
iasl -sa facp.dsl
This results in facp.aml, which I copied into /boot.
In Grub, I tried to load the new table with the entry
acpi /facp.aml
before the linux line.
After booting, unfortunately the new table is not loaded when I extract the ACPI tables again.
Does someone know if it is not possible to load a fixed FACP table in Grub? If it's not possible, is there an other way to fix this problem?
Edit: I have tested now the Grub acpi function with a modified DSDT table. This doesn't work, either. So I think it's a problem with Grub.
Last edited by Ununnilium (2014-11-24 09:03:27)

Answer 1

http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/DocBook/libata/ch07.html#excatATAbusErr wrote:
ATA bus error means that data corruption occurred during transmission over ATA bus (SATA or PATA). This type of errors can be indicated by
ICRC or ABRT error as described in the section called “ATA/ATAPI device error (non-NCQ / non-CHECK CONDITION)”.
Controller-specific error completion with error information indicating transmission error.
On some controllers, command timeout. In this case, there may be a mechanism to determine that the timeout is due to transmission error.
Unknown/random errors, timeouts and all sorts of weirdities.
As described above, transmission errors can cause wide variety of symptoms ranging from device ICRC error to random device lockup, and, for many cases, there is no way to tell if an error condition is due to transmission error or not; therefore, it's necessary to employ some kind of heuristic when dealing with errors and timeouts. For example, encountering repetitive ABRT errors for known supported command is likely to indicate ATA bus error.
Once it's determined that ATA bus errors have possibly occurred, lowering ATA bus transmission speed is one of actions which may alleviate the problem.
I'd also add; make sure you have good backups when ATA errors are frequent