[RFC DSD] How to Use the ACPI _DSD Device Properties UUIDs
by Al Stone
In the three documents that follow, we lay out a process for defining
the use cases of device properties returned by the ACPI _DSD (Device
Specific Data) object in Data Structures associated with the Device
Properties UUID [0] and the Hierarchical Properties Extension UUID [1].
The term "_DSD device properties" below refers to the data formats
associated with those two UUIDs only. All other UUIDs used with _DSD
are outside the scope of what is described here.
The goal of these documents is to: (1) make clear to OS vendors which of
the use cases of _DSD device properties need to be supported; (2) be
clear on what those use cases should mean to the OS; and, (3) have all
OSs use the same definitions for those use cases.
The first document describes basic context and essential terminology for
the process of submitting a use case for the _DSD device properties to a
central location so that it can be reviewed and tracked.
The next document describes a database for storing the use cases of _DSD
device properties that have been reviewed and agreed upon. The idea is
to make this database publicly available so that OS developers and
firmware creators can easily see what is already defined, what is in
use, and what is not defined.
The final document provides a formal language for describing the use
cases of _DSD device properties. The goal is to make it relatively easy
to define new use cases of the _DSD device properties, by stating
clearly what those definitions must look like. This also makes building
automated tools easier, allowing us to keep the process simpler, permit
validation of the content, assist with documentation, and perform basic
record keeping.
Why should you care?
If you write ACPI firmware, you may need to provide a _DSD object; if
you decide to create your own UUID, you will need to clearly document
the content returned by your _DSD UUID so that an OS can use it
properly. However, if you need to use _DSD device properties, the
documents here are intended to make it clear what needs to be done so
that use cases are documented and consistent for all OSs.
If you work with OS drivers using ACPI, you may need to consult one of
the use cases of the _DSD device properties. What these documents lay
out is a standard mechanism for describing these use cases, independent
of OS, with a uniform way to determine what is available, and what their
values are. Ideally, there would be no need to reverse engineer, or
worse, guess at, the device properties available for a specific device.
Finally, we hope to arrive at a time when OS changes requiring use cases
in the _DSD device properties do not get accepted unless they have been
registered and documented as described here. We want to get to the
point where use cases of _DSD device properties are unambiguous, well
documented, visible to all who need them, and usable across any number
of OSs.
If you have any comments, improvements or suggestions, let us know. We
believe the basic content is sound, but more eyes are always better. We
would also like to have this process up and running in July or August;
it has been postponed far too long as it is.
Comment here, or if you would rather, you can find the documents on
github and suggest patches there:
https://github.com/ahs3/dsd/tree/master/documentation
Thanks.
Contributors:
Al Stone <ahs3(a)redhat.com>
Charles Garcia-Tobin <charles.garcia-tobin(a)arm.com>
Darren Hart <darren.hart(a)intel.com>
David Woodhouse <david.woodhouse(a)intel.com>
Rafael Wysocki <rjw.rjwysocki.net>
(apologies if we're missing someone that should be on this list...)
References:
[0]
http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-...
[1]
http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-...
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
5 years
Re: [Devel] acpi: broken suspend to RAM with v4.7-rc1
by Zheng, Lv
Hi,
> From: Andrey Skvortsov [mailto:andrej.skvortzov@gmail.com]
> Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
>
> On 27 Jun, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Andrey Skvortsov [mailto:andrej.skvortzov@gmail.com]
> > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > >
> > > On 24 Jun, Zheng, Lv wrote:
> > > > Hi,
> > > >
> > > > > From: Andrey Skvortsov [mailto:andrej.skvortzov@gmail.com]
> > > > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > > > >
> > > > > Hi Lv,
> > > > >
> > > > > On 13 Jun, Zheng, Lv wrote:
> > > > > > > From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-
> > > > > > > owner(a)vger.kernel.org] On Behalf Of Rafael J. Wysocki
> > > > > > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > > > > > >
> > > > > > > On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov
> wrote:
> > > > > > > > On 10 Jun, Rafael J. Wysocki wrote:
> > > > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov
> wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken
> > > suspend
> > > > > to RAM.
> > > > > > > > > > Laptop doesn't finish suspend to RAM process (disks are
> off,
> > > but
> > > > > > > > > > WiFi and Power LEDs are still on). The only way to get it
> out of
> > > > > > > > > > this state, is to turn the power off.
> > > > > > > > > >
> > > > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25
> > > > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add
> access_width/bit_offset
> > > > > support
> > > > > > > > > > for acpi_hw_write()].
> > > > > > > > > >
> > > > > > > > > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to
> > > RAM
> > > > > > > > > > is working again.
> > > > > > > > > >
> > > > > > > > > > The cause of this problem is that after this commit write
> to
> > > > > PM1A
> > > > > > > > > > Control Block (16-bit register) is done using two 8-bit
> writes.
> > > > > > > > > > If I force this write to be 16-bit, then all is working as
> before.
> > > > > > > > > >
> > > > > > > > > > To get it working 'access_width' for PM1A Control Block
> > > needs to
> > > > > > > > > > be 2 (16-bit), but it's 1 (8-bit).
> > > > > > [Lv Zheng]
> > > > > > Could you send me the acpidump of the machine?
> > > > > Here it is
> > > > >
> > >
> https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid
> > > > > ump.bin
> > > > [Lv Zheng]
> > > > I've been trying to download it these days but all failed.
> > > > Could you send an off-list email to me with this attached?
> > > Strange. I've check now. The link above is working, but I see that
> > > part of the link above is moved to the next line.
> > [Lv Zheng]
> > Maybe this is just because of ISP firewall.
> >
> > > Anyway I resend you all files off-list.
> > [Lv Zheng]
> > Great!
> >
> > >
> > >
> > > > > > > > > > The root of the problem seems to be not the commit
> > > > > > > 66b1ed5aa8dd25
> > > > > > > > > > itself, but the ACPI tables in BIOS where wrong
> access_width
> > > > > > > > > > comes from. I fixed problem in FACP table, put it in initrd
> to
> > > > > > > > > > override FACP table from BIOS. This fixed the issue,
> suspend
> > > to
> > > > > > > > > > RAM is working now again.
> > > > > > > > > >
> > > > > > > > > > But I'm not sure whether is this proper fix for this
> problem.
> > > > > > > > > > Is there any place in the kernel, where such ACPI quirks
> are
> > > placed?
> > > > > > [Lv Zheng]
> > > > > > My question would be:
> > > > > > Does Windows behave correctly for this table?
> > > > > Yes, suspend to RAM is working under Windows Vista.
> > > > > IIRC it worked under Windows XP too.
> > > > >
> > > > > > However there is a real case showing that there are real tables
> need
> > > us to
> > > > > correctly support BitWidth/BitOffset.
> > > > > > Here is the information for you to refer:
> > > > > >
> > >
> http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
> > > > > >
> > > > > > > > >
> > > > > > > > > Well, if the commit in question caused a problem to happen
> for
> > > > > you,
> > > > > > > > > it also might cause similar problems to happen elsewhere.
> > > > > > > > >
> > > > > > > > > It looks like we'll need to revert that commit.
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > or maybe to reset access_width AnyAcc from FACP table only
> for
> > > > > PM1A
> > > > > > > > control register or even for all registers? This will fix the issue
> too.
> > > > > > >
> > > > > > > That's a good idea actually.
> > > > > > >
> > > > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c
> > > > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94
> 100644
> > > > > > > > --- a/drivers/acpi/acpica/tbfadt.c
> > > > > > > > +++ b/drivers/acpi/acpica/tbfadt.c
> > > > > > > > @@ -714,7 +714,14 @@ static void
> > > > > acpi_tb_setup_fadt_registers(void)
> > > > > > > > }
> > > > > > > > }
> > > > > > > > }
> > > > > > > >
> > > > > > > > + /*
> > > > > > > > + * Reset access_width in the GAS for PM1A control
> register
> > > to
> > > > > > > > + * undefined value. Because in some cases this field
> contains
> > > > > > > > + * wrong value.
> > > > > > > > + */
> > > > > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0;
> > > > > > >
> > > > > > > OK, let's see what Bob and Lv think about that.
> > > > > > [Lv Zheng]
> > > > > > There is a commit in 4.7-rc2:
> > > > > >
> > > > >
> > >
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
> > > > > 7f9bef9d
> > > > > > Have you tried if the problem still exists in 4.7-rc2?
> > > > > I've just tried v4.7-rc3. It contains commit 7f9bef9d and the
> problem
> > > > > exists there too.
> > > > [Lv Zheng]
> > > > IMO, for the time being, you can use quirks.
> > > > Booting your kernel with the following parameters:
> > > >
> > > > acpi=rsdt
> > > > Or
> > > > acpi_force_32bit_fadt_addr
> > > > Or
> > > > Both
> > >
> > > Rafael reverted commit, so I'm ok now.
> > >
> > > Actually acpi_force_32bit_fadt_addr will not help here, because it's
> take
> > > effect only if address64 != address32. But here these addresses are
> > > the same, therefore access_width is taken from extended address.
> > >
> > > http://lxr.free-
> electrons.com/source/drivers/acpi/acpica/tbfadt.c#L576
> > [Lv Zheng]
> > In addition to the address check, we may add access width check here.
> > I need to check this with the decision makers.
> Make sense. But then it's necessary to set default access width for
> registers from
> FADT for this check. Because in the old 32-bit part of FADT only address
> and
> length are defined, but not access width.
>
>
> > > acpi=rsdt helps. Thanks for the information about this option. I
> > > missed it, when I read documentation.
> > [Lv Zheng]
> > Great to know that at least 1 quirk works.
> > Back to this bug, it seems we should use fixed access_width for some
> pre-defined PM registers.
> This is what I meant by suggesting to reset xpm1a's
> access_width to zero (or maybe another registers from FADT too) in
> acpi_tb_setup_fadt_registers (see quoted diff above from my previous
> answer).
> If access_width is zero, then code works as before and access_width is
> calculated by acpi_hw_get_access_bit_width (will return reg->bit_width or
> max_bit_width(32) in our case).
>
> Setting access_width to some pre-defined value is an option.
> But it's not as flexible, because ACPI specification doesn't define
> access width and some pre-defined PM registers have variable length
> and only the minimal register length is defined (PM1A Control Reg, PM1B
> Control
> Reg, PM1A event block, PM1B event block).
>
> Previously you pointed to commit that requires usage of access
> width field.
> http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
> I see it's related to APEI, therefore setting access_width for
> registers in FADT will not affect it.
[Lv Zheng]
Yes, I can see your point and it looks reasonable.
For now, I'm going to probe Windows behavior using qemu.
It looks I can achieve this by modifying:
hw/i386/acpi-build.c: http://git.qemu.org/?p=qemu.git;a=blob;f=hw/i386/acpi-build.c
hw/acpi/ich9.c: http://git.qemu.org/?p=qemu.git;a=blob;f=hw/acpi/ich9.c
The result may help us to make more accurate decision.
Thanks and best regards
-Lv
5 years
Again: Lenovo G710 ACPI Tables
by David Renz
It seems like I've misinterpreted those scan results - When searching for "Lenovo" and "Bloatware" or "Crapware" one can find a huge number of articles reporting about this issue, which is not very appealing as I think, but rather harmless. Therefore I think the thread can be closed.
Kind regards
David
5 years, 1 month
Re: [Devel] acpi: broken suspend to RAM with v4.7-rc1
by Zheng, Lv
Hi,
> From: Andrey Skvortsov [mailto:andrej.skvortzov@gmail.com]
> Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
>
> On 24 Jun, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Andrey Skvortsov [mailto:andrej.skvortzov@gmail.com]
> > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > >
> > > Hi Lv,
> > >
> > > On 13 Jun, Zheng, Lv wrote:
> > > > > From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-
> > > > > owner(a)vger.kernel.org] On Behalf Of Rafael J. Wysocki
> > > > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > > > >
> > > > > On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov wrote:
> > > > > > On 10 Jun, Rafael J. Wysocki wrote:
> > > > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken
> suspend
> > > to RAM.
> > > > > > > > Laptop doesn't finish suspend to RAM process (disks are off,
> but
> > > > > > > > WiFi and Power LEDs are still on). The only way to get it out of
> > > > > > > > this state, is to turn the power off.
> > > > > > > >
> > > > > > > > I've bisected the issue to commit 66b1ed5aa8dd25
> > > > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset
> > > support
> > > > > > > > for acpi_hw_write()].
> > > > > > > >
> > > > > > > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to
> RAM
> > > > > > > > is working again.
> > > > > > > >
> > > > > > > > The cause of this problem is that after this commit write to
> > > PM1A
> > > > > > > > Control Block (16-bit register) is done using two 8-bit writes.
> > > > > > > > If I force this write to be 16-bit, then all is working as before.
> > > > > > > >
> > > > > > > > To get it working 'access_width' for PM1A Control Block
> needs to
> > > > > > > > be 2 (16-bit), but it's 1 (8-bit).
> > > > [Lv Zheng]
> > > > Could you send me the acpidump of the machine?
> > > Here it is
> > >
> https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid
> > > ump.bin
> > [Lv Zheng]
> > I've been trying to download it these days but all failed.
> > Could you send an off-list email to me with this attached?
> Strange. I've check now. The link above is working, but I see that
> part of the link above is moved to the next line.
[Lv Zheng]
Maybe this is just because of ISP firewall.
> Anyway I resend you all files off-list.
[Lv Zheng]
Great!
>
>
> > > > > > > > The root of the problem seems to be not the commit
> > > > > 66b1ed5aa8dd25
> > > > > > > > itself, but the ACPI tables in BIOS where wrong access_width
> > > > > > > > comes from. I fixed problem in FACP table, put it in initrd to
> > > > > > > > override FACP table from BIOS. This fixed the issue, suspend
> to
> > > > > > > > RAM is working now again.
> > > > > > > >
> > > > > > > > But I'm not sure whether is this proper fix for this problem.
> > > > > > > > Is there any place in the kernel, where such ACPI quirks are
> placed?
> > > > [Lv Zheng]
> > > > My question would be:
> > > > Does Windows behave correctly for this table?
> > > Yes, suspend to RAM is working under Windows Vista.
> > > IIRC it worked under Windows XP too.
> > >
> > > > However there is a real case showing that there are real tables need
> us to
> > > correctly support BitWidth/BitOffset.
> > > > Here is the information for you to refer:
> > > >
> http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
> > > >
> > > > > > >
> > > > > > > Well, if the commit in question caused a problem to happen for
> > > you,
> > > > > > > it also might cause similar problems to happen elsewhere.
> > > > > > >
> > > > > > > It looks like we'll need to revert that commit.
> > > > > > Hi,
> > > > > >
> > > > > > or maybe to reset access_width AnyAcc from FACP table only for
> > > PM1A
> > > > > > control register or even for all registers? This will fix the issue too.
> > > > >
> > > > > That's a good idea actually.
> > > > >
> > > > > > diff --git a/drivers/acpi/acpica/tbfadt.c
> > > > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
> > > > > > --- a/drivers/acpi/acpica/tbfadt.c
> > > > > > +++ b/drivers/acpi/acpica/tbfadt.c
> > > > > > @@ -714,7 +714,14 @@ static void
> > > acpi_tb_setup_fadt_registers(void)
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > + /*
> > > > > > + * Reset access_width in the GAS for PM1A control register
> to
> > > > > > + * undefined value. Because in some cases this field contains
> > > > > > + * wrong value.
> > > > > > + */
> > > > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0;
> > > > >
> > > > > OK, let's see what Bob and Lv think about that.
> > > > [Lv Zheng]
> > > > There is a commit in 4.7-rc2:
> > > >
> > >
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
> > > 7f9bef9d
> > > > Have you tried if the problem still exists in 4.7-rc2?
> > > I've just tried v4.7-rc3. It contains commit 7f9bef9d and the problem
> > > exists there too.
> > [Lv Zheng]
> > IMO, for the time being, you can use quirks.
> > Booting your kernel with the following parameters:
> >
> > acpi=rsdt
> > Or
> > acpi_force_32bit_fadt_addr
> > Or
> > Both
>
> Rafael reverted commit, so I'm ok now.
>
> Actually acpi_force_32bit_fadt_addr will not help here, because it's take
> effect only if address64 != address32. But here these addresses are
> the same, therefore access_width is taken from extended address.
>
> http://lxr.free-electrons.com/source/drivers/acpi/acpica/tbfadt.c#L576
[Lv Zheng]
In addition to the address check, we may add access width check here.
I need to check this with the decision makers.
>
>
> acpi=rsdt helps. Thanks for the information about this option. I
> missed it, when I read documentation.
[Lv Zheng]
Great to know that at least 1 quirk works.
Back to this bug, it seems we should use fixed access_width for some pre-defined PM registers.
Thanks and best regards
-Lv
5 years, 1 month
ACPI tables of Lenovo G710
by David Renz
Hello,
I'm the owner of a Lenovo G710, and after I saw a huge number of ACPI related error messages in the Linux dmesg log, whose were also confirmed by running Firmware Test Suite Live, I decided to do some research on this, which gave me a really strong impression:
I extracted the ACPI tables using Read&Write Everything (Windows) and submitted them to malwar.com for getting them analyzed. Here you can see what the running of the ACPI code on the malwr.com sandbox (Windows environment) did, and which one normally wouldn't expect as I guess:
File changes:
https://malwr.com/analysis/ZmEyZTNhNzg1ZTg3NDBhM2I2OWEwYTFjM2FiYmVmOTM/#s...
Registry keys changed:
https://malwr.com/analysis/ZmEyZTNhNzg1ZTg3NDBhM2I2OWEwYTFjM2FiYmVmOTM/#s...
Mutexes:
https://malwr.com/analysis/ZmEyZTNhNzg1ZTg3NDBhM2I2OWEwYTFjM2FiYmVmOTM/#s...
Behaviorial analysis (particularly interesting):
https://malwr.com/analysis/ZmEyZTNhNzg1ZTg3NDBhM2I2OWEwYTFjM2FiYmVmOTM/#b...
What is even more unsettling is the fact that I found several sites related to malware, when I searched for the registry keys, files or mutexes changed/created by that ACPI code:
http://www.lavasoft.com/mylavasoft/malware-descriptions/blog/BackdoorWin3...
https://isc.sans.edu/forums/diary/Suspect+Sendori+software/16466/
https://isc.sans.edu/diary.html?date=2013-08-29
You can download the extracted ACPI tables from malwr.com after registering there, but I also uploaded it on Google Drive and gave shared access to it:
https://drive.google.com/open?id=0B62Y5Qk_rdbWRFg1aDZPcEs4bTA
Now I would assume that those are not genuine ACPI tables by Lenovo. I have a few questions in this regard:
1) Obviously I didn't flash my BIOS' ACPI tables with malicious code - So how can those be modified? Would it be possible that the computer's network adapter enters a so-called 'maintenance mode' by receiving packages containing certain 'magic numbers'? At least I've read in various sources that generally it would be possible to do that.
2) I'm not an expert about ACPI code at all (just knowing x86 assembly stuff), but when looking at the disassembled ACPI tables (which I did using iasl under Linux) I could find no hint at all pointing to all those code actions which are being performed. I know that ACPI code is very obscure litterally speaking, but is it possible to hide all this?
3) I downloaded a BIOS image using a secure method, flashed the BIOS while being offline and installed an OS right after rebooting - With no effect at all, the ACPI code was still the same. Shouldn't the ACPI tables be overwritten by flashing the BIOS? If that's not possible, then is it in fact impossible to get rid of this by any means?
Those are the GERM scan results, which don't look nice as well:
http://pastebin.com/A5J3pmpF
Like, "SSDT ZwAcceptConnectPort fffff80003135d20 \SystemRoot\system32\xNtKrnl.exe" sounds rather suspicious.
I guess that there is no chance to find out where those connections lead to, since my system seems to be modified on such a deep level - There's nothing suspicious being visible in Wireshark and Comodo doesn't give any alert as well. But still I'm deeply interested in what the origin of all this might be - And since it seems like it all started with the ACPI code modifying the OS, this information must logically be stored in the ACPI code as well. Would there be any chance to find out some information on this?
I would highly appreciate any thoughts, comments and advices. Maybe someone having a Lenovo G710, too, could extract his ACPI tables, so that a comparison could give some hints about what has been modified.
Finally, I also did some information gathering using the Volatility Tools under Linux, and it seems like this code might affect Linux as well, but I still have to conduct further analysis in this regard to be sure that this is not just a false alert. In any case I have the strong impression that this code demonstrates very high technical skills.
Kind regards and thanks in advance
David
5 years, 1 month
Re: [Devel] acpi: broken suspend to RAM with v4.7-rc1
by Zheng, Lv
Hi,
> From: Andrey Skvortsov [mailto:andrej.skvortzov@gmail.com]
> Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
>
> Hi Lv,
>
> On 13 Jun, Zheng, Lv wrote:
> > > From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-
> > > owner(a)vger.kernel.org] On Behalf Of Rafael J. Wysocki
> > > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> > >
> > > On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov wrote:
> > > > On 10 Jun, Rafael J. Wysocki wrote:
> > > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend
> to RAM.
> > > > > > Laptop doesn't finish suspend to RAM process (disks are off, but
> > > > > > WiFi and Power LEDs are still on). The only way to get it out of
> > > > > > this state, is to turn the power off.
> > > > > >
> > > > > > I've bisected the issue to commit 66b1ed5aa8dd25
> > > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset
> support
> > > > > > for acpi_hw_write()].
> > > > > >
> > > > > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to RAM
> > > > > > is working again.
> > > > > >
> > > > > > The cause of this problem is that after this commit write to
> PM1A
> > > > > > Control Block (16-bit register) is done using two 8-bit writes.
> > > > > > If I force this write to be 16-bit, then all is working as before.
> > > > > >
> > > > > > To get it working 'access_width' for PM1A Control Block needs to
> > > > > > be 2 (16-bit), but it's 1 (8-bit).
> > [Lv Zheng]
> > Could you send me the acpidump of the machine?
> Here it is
> https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid
> ump.bin
[Lv Zheng]
I've been trying to download it these days but all failed.
Could you send an off-list email to me with this attached?
>
> > > > > >
> > > > > > The root of the problem seems to be not the commit
> > > 66b1ed5aa8dd25
> > > > > > itself, but the ACPI tables in BIOS where wrong access_width
> > > > > > comes from. I fixed problem in FACP table, put it in initrd to
> > > > > > override FACP table from BIOS. This fixed the issue, suspend to
> > > > > > RAM is working now again.
> > > > > >
> > > > > > But I'm not sure whether is this proper fix for this problem.
> > > > > > Is there any place in the kernel, where such ACPI quirks are placed?
> > [Lv Zheng]
> > My question would be:
> > Does Windows behave correctly for this table?
> Yes, suspend to RAM is working under Windows Vista.
> IIRC it worked under Windows XP too.
>
> > However there is a real case showing that there are real tables need us to
> correctly support BitWidth/BitOffset.
> > Here is the information for you to refer:
> > http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
> >
> > > > >
> > > > > Well, if the commit in question caused a problem to happen for
> you,
> > > > > it also might cause similar problems to happen elsewhere.
> > > > >
> > > > > It looks like we'll need to revert that commit.
> > > > Hi,
> > > >
> > > > or maybe to reset access_width AnyAcc from FACP table only for
> PM1A
> > > > control register or even for all registers? This will fix the issue too.
> > >
> > > That's a good idea actually.
> > >
> > > > diff --git a/drivers/acpi/acpica/tbfadt.c
> > > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
> > > > --- a/drivers/acpi/acpica/tbfadt.c
> > > > +++ b/drivers/acpi/acpica/tbfadt.c
> > > > @@ -714,7 +714,14 @@ static void
> acpi_tb_setup_fadt_registers(void)
> > > > }
> > > > }
> > > > }
> > > >
> > > > + /*
> > > > + * Reset access_width in the GAS for PM1A control register to
> > > > + * undefined value. Because in some cases this field contains
> > > > + * wrong value.
> > > > + */
> > > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0;
> > >
> > > OK, let's see what Bob and Lv think about that.
> > [Lv Zheng]
> > There is a commit in 4.7-rc2:
> >
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
> 7f9bef9d
> > Have you tried if the problem still exists in 4.7-rc2?
> I've just tried v4.7-rc3. It contains commit 7f9bef9d and the problem
> exists there too.
[Lv Zheng]
IMO, for the time being, you can use quirks.
Booting your kernel with the following parameters:
acpi=rsdt
Or
acpi_force_32bit_fadt_addr
Or
Both
Thanks
-Lv
5 years, 1 month
Suspend to RAM when not supported by BIOS?
by Jo
Hello,
not sure whether this is the best place to ask the question, feel free to
provide any pointer you consider adequate.
I am using two Dell T20, one with Windows Server 2008 R2, the other with
Linux (I tried both CentOS 7.x and Ubuntu 16.04). According to the technical
manual, the Dell T20 does not officially support Suspend-To-RAM. However the
initial installation of the Windows Server was performed on a different
system that was able to suspend and then I moved the entire installation to
the T20, and it continues to suspend properly despite the technical manual.
And I really like suspend as the system is up within seconds when needed.
And in more than a year I never experienced any crash or incident that I
would associate with the "hack".
I tried both clean installs of Windows and Linux on the other T20, but
always the installations claim suspend is not supported - in line with the
official support statement. Now I am wondering how I can trick Linux into
supporting suspend despite the BIOS telling it is not supported. Is there a
configuration option to override the information the BIOS provides? I read
about OSDT, however I have no clue about how to leverage that with Linux.
And for sure I understand this is on my own risk..
Thanks & Best Regards, Joachim
5 years, 1 month
Re: [Devel] [PATCH] ACPICA: Use acpi_os_allocate_zeroed
by Moore, Robert
Got it, thanks. Will appear in next acpica release.
-----Original Message-----
From: Amitoj Kaur Chawla [mailto:amitoj1606@gmail.com]
Sent: Sunday, June 19, 2016 10:53 PM
To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; lenb(a)kernel.org; linux-acpi(a)vger.kernel.org; devel(a)acpica.org; linux-kernel(a)vger.kernel.org
Cc: julia.lawall(a)lip6.fr
Subject: [PATCH] ACPICA: Use acpi_os_allocate_zeroed
acpi_os_allocate_zeroed combines acpi_os_allocate and memset 0.
The Coccinelle semantic patch used to make this change is as follows:
@@
type T;
T *d;
expression e;
statement S;
@@
d =
- acpi_os_allocate
+ acpi_os_allocate_zeroed
(...);
if (!d) S
- memset(d, 0, sizeof(T));
Signed-off-by: Amitoj Kaur Chawla <amitoj1606(a)gmail.com>
---
drivers/acpi/acpica/utcache.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/utcache.c b/drivers/acpi/acpica/utcache.c index f8e9978..862f963 100644
--- a/drivers/acpi/acpica/utcache.c
+++ b/drivers/acpi/acpica/utcache.c
@@ -77,14 +77,13 @@ acpi_os_create_cache(char *cache_name,
/* Create the cache object */
- cache = acpi_os_allocate(sizeof(struct acpi_memory_list));
+ cache = acpi_os_allocate_zeroed(sizeof(struct acpi_memory_list));
if (!cache) {
return (AE_NO_MEMORY);
}
/* Populate the cache object and return it */
- memset(cache, 0, sizeof(struct acpi_memory_list));
cache->list_name = cache_name;
cache->object_size = object_size;
cache->max_depth = max_depth;
--
1.9.1
5 years, 1 month
Re: [Devel] acpi: broken suspend to RAM with v4.7-rc1
by Zheng, Lv
Hi, Rafael
> From: rjwysocki(a)gmail.com [mailto:rjwysocki@gmail.com] On Behalf Of
> Rafael J. Wysocki
> Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
>
> On Mon, Jun 13, 2016 at 12:07 PM, Andrey Skvortsov
> <andrej.skvortzov(a)gmail.com> wrote:
> > Hi Lv,
> >
> > On 13 Jun, Zheng, Lv wrote:
> >> > From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-
> >> > owner(a)vger.kernel.org] On Behalf Of Rafael J. Wysocki
> >> > Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
> >> >
> >> > On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov wrote:
> >> > > On 10 Jun, Rafael J. Wysocki wrote:
> >> > > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend
> to RAM.
> >> > > > > Laptop doesn't finish suspend to RAM process (disks are off, but
> >> > > > > WiFi and Power LEDs are still on). The only way to get it out of
> >> > > > > this state, is to turn the power off.
> >> > > > >
> >> > > > > I've bisected the issue to commit 66b1ed5aa8dd25
> >> > > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset
> support
> >> > > > > for acpi_hw_write()].
> >> > > > >
> >> > > > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to RAM
> >> > > > > is working again.
> >> > > > >
> >> > > > > The cause of this problem is that after this commit write to
> PM1A
> >> > > > > Control Block (16-bit register) is done using two 8-bit writes.
> >> > > > > If I force this write to be 16-bit, then all is working as before.
> >> > > > >
> >> > > > > To get it working 'access_width' for PM1A Control Block needs
> to
> >> > > > > be 2 (16-bit), but it's 1 (8-bit).
> >> [Lv Zheng]
> >> Could you send me the acpidump of the machine?
> > Here it is
> >
> https://dl.dropboxusercontent.com/u/24023626/dell_vostro_1500.acpid
> ump.bin
> >
> >> > > > >
> >> > > > > The root of the problem seems to be not the commit
> >> > 66b1ed5aa8dd25
> >> > > > > itself, but the ACPI tables in BIOS where wrong access_width
> >> > > > > comes from. I fixed problem in FACP table, put it in initrd to
> >> > > > > override FACP table from BIOS. This fixed the issue, suspend to
> >> > > > > RAM is working now again.
> >> > > > >
> >> > > > > But I'm not sure whether is this proper fix for this problem.
> >> > > > > Is there any place in the kernel, where such ACPI quirks are
> placed?
> >> [Lv Zheng]
> >> My question would be:
> >> Does Windows behave correctly for this table?
> > Yes, suspend to RAM is working under Windows Vista.
> > IIRC it worked under Windows XP too.
> >
> >> However there is a real case showing that there are real tables need us
> to correctly support BitWidth/BitOffset.
> >> Here is the information for you to refer:
> >> http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
> >>
> >> > > >
> >> > > > Well, if the commit in question caused a problem to happen for
> you,
> >> > > > it also might cause similar problems to happen elsewhere.
> >> > > >
> >> > > > It looks like we'll need to revert that commit.
> >> > > Hi,
> >> > >
> >> > > or maybe to reset access_width AnyAcc from FACP table only for
> PM1A
> >> > > control register or even for all registers? This will fix the issue too.
> >> >
> >> > That's a good idea actually.
> >> >
> >> > > diff --git a/drivers/acpi/acpica/tbfadt.c
> >> > > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
> >> > > --- a/drivers/acpi/acpica/tbfadt.c
> >> > > +++ b/drivers/acpi/acpica/tbfadt.c
> >> > > @@ -714,7 +714,14 @@ static void
> acpi_tb_setup_fadt_registers(void)
> >> > > }
> >> > > }
> >> > > }
> >> > >
> >> > > + /*
> >> > > + * Reset access_width in the GAS for PM1A control register to
> >> > > + * undefined value. Because in some cases this field contains
> >> > > + * wrong value.
> >> > > + */
> >> > > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0;
> >> >
> >> > OK, let's see what Bob and Lv think about that.
> >> [Lv Zheng]
> >> There is a commit in 4.7-rc2:
> >>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=
> 7f9bef9d
> >> Have you tried if the problem still exists in 4.7-rc2?
> > I've just tried v4.7-rc3. It contains commit 7f9bef9d and the problem
> > exists there too.
>
> I have decided to revert commit 66b1ed5aa8dd25 as in principle other
> registers may be similarly affected on other systems.
[Lv Zheng]
Yes.
I didn't prepare fallback mechanism for this support.
It seems we have to do the reversion.
Please revert it.
Next time I'll prepare a quirk mechanism when this is upstreamed.
For Andrey:
Could you provide me the DMIdecode output of the machine?
Thanks
-Lv
>
> Thanks,
> Rafael
5 years, 1 month
Re: [Devel] acpi: broken suspend to RAM with v4.7-rc1
by Zheng, Lv
Hi, Andrey
> From: linux-acpi-owner(a)vger.kernel.org [mailto:linux-acpi-
> owner(a)vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Subject: Re: acpi: broken suspend to RAM with v4.7-rc1
>
> On Saturday, June 11, 2016 01:49:22 PM Andrey Skvortsov wrote:
> > On 10 Jun, Rafael J. Wysocki wrote:
> > > On Friday, June 10, 2016 11:32:10 PM Andrey Skvortsov wrote:
> > > > Hi,
> > > >
> > > > On my laptop (DELL Vostro 1500) in v4.7-rc1 is broken suspend to RAM.
> > > > Laptop doesn't finish suspend to RAM process (disks are off, but
> > > > WiFi and Power LEDs are still on). The only way to get it out of
> > > > this state, is to turn the power off.
> > > >
> > > > I've bisected the issue to commit 66b1ed5aa8dd25
> > > > [ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support
> > > > for acpi_hw_write()].
> > > >
> > > > If I revert this commit in v4.7-rc1 (or v4.7-rc2), suspend to RAM
> > > > is working again.
> > > >
> > > > The cause of this problem is that after this commit write to PM1A
> > > > Control Block (16-bit register) is done using two 8-bit writes.
> > > > If I force this write to be 16-bit, then all is working as before.
> > > >
> > > > To get it working 'access_width' for PM1A Control Block needs to
> > > > be 2 (16-bit), but it's 1 (8-bit).
[Lv Zheng]
Could you send me the acpidump of the machine?
> > > >
> > > > The root of the problem seems to be not the commit
> 66b1ed5aa8dd25
> > > > itself, but the ACPI tables in BIOS where wrong access_width
> > > > comes from. I fixed problem in FACP table, put it in initrd to
> > > > override FACP table from BIOS. This fixed the issue, suspend to
> > > > RAM is working now again.
> > > >
> > > > But I'm not sure whether is this proper fix for this problem.
> > > > Is there any place in the kernel, where such ACPI quirks are placed?
[Lv Zheng]
My question would be:
Does Windows behave correctly for this table?
However there is a real case showing that there are real tables need us to correctly support BitWidth/BitOffset.
Here is the information for you to refer:
http://permalink.gmane.org/gmane.linux.kernel.commits.head/313870
> > >
> > > Well, if the commit in question caused a problem to happen for you,
> > > it also might cause similar problems to happen elsewhere.
> > >
> > > It looks like we'll need to revert that commit.
> > Hi,
> >
> > or maybe to reset access_width AnyAcc from FACP table only for PM1A
> > control register or even for all registers? This will fix the issue too.
>
> That's a good idea actually.
>
> > diff --git a/drivers/acpi/acpica/tbfadt.c
> > b/drivers/acpi/acpica/tbfadt.c index 6208069..a476e94 100644
> > --- a/drivers/acpi/acpica/tbfadt.c
> > +++ b/drivers/acpi/acpica/tbfadt.c
> > @@ -714,7 +714,14 @@ static void acpi_tb_setup_fadt_registers(void)
> > }
> > }
> > }
> >
> > + /*
> > + * Reset access_width in the GAS for PM1A control register to
> > + * undefined value. Because in some cases this field contains
> > + * wrong value.
> > + */
> > + acpi_gbl_FADT.xpm1a_control_block.access_width = 0;
>
> OK, let's see what Bob and Lv think about that.
[Lv Zheng]
There is a commit in 4.7-rc2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?i...
Have you tried if the problem still exists in 4.7-rc2?
Thanks and best regards
-Lv
5 years, 1 month