[Top][All Lists]

[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 
> 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 
> 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]