On Fri, Oct 27, 2017 at 3:57 PM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: >> Testing shutdown on Acer Aspire ES1-732 (Intel Apollo Lake N4200) on >> Linux 4.14-rc6, this issue is still present. >> >> The FADT has: >> >> [0ACh 0172 12] PM1A Control Block : [Generic Address Structure] >> [0ACh 0172 1] Space ID : 01 [SystemIO] >> [0ADh 0173 1] Bit Width : 10 >> [0AEh 0174 1] Bit Offset : 00 >> [0AFh 0175 1] Encoded Access Width : 02 [Word Access:16] >> [0B0h 0176 8] Address : 0000000000000404 >> >> Full ACPI tables dump: >> https://gist.github.com/dsd/ed80d9fdd32f99e310002b2492cd6e1b >> >> We have tested that writing bit 13 of port 0404 under Windows 10 >> (using an app called RW everything) results in an immediate and >> successful power down. However, writing the same bit under Linux just >> makes the system hang. >> >> I am not really familiar with the guts of x86 systems. When the OS >> writes to this port, which component of the system receives that >> request and acts accordingly? Is it handled by the BIOS? Or an EC, or >> ...? With more background here we may be able to approach the relevant >> component vendor and ask for help. > > Writes to the PM1A register may go straight to the PMC or trigger an > SMM trap. In both cases the platform takes over. Platform means BIOS/firmware? (i.e. Insyde in this case) Or you are referring to the Intel SoC? > Is Apollo Lake the only platform affected or are there any other? All 3 affected product families are Apollo Lake Thanks Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
