grub-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]