[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Loading DSDT table using 'acpi' or some memory write command?
From: |
Andrei Borzenkov |
Subject: |
Re: Loading DSDT table using 'acpi' or some memory write command? |
Date: |
Mon, 27 Mar 2017 19:55:26 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
27.03.2017 17:12, Nando Eva пишет:
> OK, I found the cause if the problem:
> - the ACPI tables specified to the 'acpi' command are loaded to new addresses
> and a new RSDT and XSDT created with pointers to them. This can be confirmed
> by the 'lsacpi' command.
>
> - the RSDP isn't updated to point to the new RSDT and XSDT.
>
How exactly do you find RSDP? On EFI RSDP should be retrieved from EFI
Configuration Table, which grub tries to update. Please give as much
details as possible.
> So when chainload the OS, the original RSDT and XSDT are referenced from the
> RSDP.
> I'm now manually doing the 'acpi [DSDT]' table load, then a 'lsacpi -2' to
> find the new RSDT+XSDT addresses and updating the RSDP via two write_dword
> memory writes (though not doing checksum correction).
Again - what address are you updating?
> Can a pach be made for grub2 to correct this behaviour to be automated
> without such manual intervention?
We need to understand why it fails first. GRUB *does* attempt to
override RSDP if it finds it.
> Thank you,Nando
>
> On Tuesday, 28 February 2017, 5:21, Nando Eva <address@hidden> wrote:
>
>
> Vladimir 'phcoder' Serbinenko wrote:
>
> I reproduced the bug. I'm investigating
>
>>> Apparently finish_boot_services rewrites acpi tables. It's possible to
>>> workaround this, possibly by using acpi table protocol. >> But it's
>>> certainely not for 2.02 at this point.
> Thank you for investigating the issue. Earlier I did a test to check to see
> if UEFI chainloading was altering ACPI tables. I did this by:
> 1. performing two grub2 "write_dword" console memory commands to enable ASPM
> in the ACPI FADT (FACP on my system) table as per
> http://smackerelofopinion.blogspot.com.au/2011/03/making-sense-of-pcie-aspm.html
>
>
> 2. then chainloaded from Grub2 to windows: chainloader
> /efi/Microsoft/Boot/bootmgfw.efi
> The ASPM enabling change was there as found by using r-w everything and
> reported by 'powercfg /energy', indicating the UEFI chainloading isn't, at
> least for ACPI FADT (FACP), altering the in-memory table.
> As the DSDT table is much larger, I can't really write_dword it. Hence asking
> for some other memory loading module.
> As another lead, I found the mentioned finish_boot_services routine in mm.c,
> quoted below. Would you mind pointing out which code is rewriting the ACPI
> tables?
The whole ACPI tables mangling happens in grub-core/commands/acpi.c