Am 2017-08-29 18:03, schrieb Moore, Robert:
-----Original Message-----
From: David Renz [mailto:David.Renz@xxxxxxxxxxxxxxxxxx]
Sent: Sunday, August 27, 2017 3:13 PM
To: Moore, Robert <robert.moore@xxxxxxxxx>
Cc: linux-acpi@xxxxxxxxxxxxxxx; acpi@xxxxxxxxxxxxxxx;
david.renz@xxxxxx;
Box, David E <david.e.box@xxxxxxxxx>; Schmauss, Erik
<erik.schmauss@xxxxxxxxx>; linux-acpi-owner@xxxxxxxxxxxxxxx
Subject: Re: ASL issues on HP machine
Am 2017-08-25 18:43, schrieb Moore, Robert:
> I can address a couple of these immediately.
>
>
> ASL_MSG_NOT_REFERENCED
> This is seen on the HP machine.
>
> FAILED [LOW] AMLAsm
> ASL_MSG_NOT_REFERENCED: Test 1, Assembler remark in line 1141 Line |
> AML source
> ----------------------------------------------------------------------
> ----------
> 01138| Store (Buffer (0x18) {}, Local7)
> 01139| CreateDWordField (Local7, 0x00, A119)
> 01140| CreateDWordField (Local7, 0x04, A120)
> 01141| CreateDWordField (Local7, 0x08, A121)
> | ^
> | Remark 2089: Object is not referenced (Name [A121] is
within
> a
> method [A037])
>
>
> Here is the actual disassembled A037 method, found in SSDT3:
>
> Method (A037, 1, NotSerialized)
> {
>
> ... /* Some other stuff here */
>
> CreateDWordField (Local7, 0x00, A119)
> CreateDWordField (Local7, 0x04, A120)
> CreateDWordField (Local7, 0x08, A121)
> CreateDWordField (Local7, 0x0C, A122)
> CreateDWordField (Local7, 0x10, A123)
> CreateDWordField (Local7, 0x14, A124)
> A119 = Local4
> A125 (0x3A, Local7)
> }
>
> Not only is the symbol A121 created and not referenced, all of the
> fields A120 through A124 are not referenced.
>
> These are essentially "unused variables", so they have no effect on
> operation of the method other than consuming a tiny bit more memory
> during the execution of the method.
>
>
>
>
> AE_AML_BUFFER_LIMIT:
> This is seen on the HP machine.
>
>> [ 12.291867] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL]
>> size 160 (bits) (20150930/dsopcode-236)
>> [ 12.291875] ACPI Error: Method parse/execution failed [\HWMC]
(Node
>> ffff880197cb5b30), AE_AML_BUFFER_LIMIT (20150930/psparse-542)
>
> All of these messages are caused by either whatever driver is calling
> the HWMC method, or the HWMC method itself.
One should be able to narrow this down to whether a driver (and which
driver) calling the HWMC method OR the HWMC method itself being the
reason, isn't it? But I guess this could only be done by performing
kernel debugging on this machine to monitor the ACPI activity / event
taking place 'live', right?
[Moore, Robert]
For the most part, yes. The driver may be passing in a bad argument to
HWMC, or the HWMC method itself is looking beyond the end of what is
in fact a well-formed argument.
I'm familiar with 6502 and x86/x864 machine code, several programming
languages and Linux, but I honestly admit that I don't possess much
knowledge about the ACPI sub-system itself and the AML language/syntax.
So apart from this concrete issue with the ACPI code on my HP machine
which might produce unwanted effects, I appreciate the opportunity to
extend my knowledge regarding this field (I took a look at the more than
900 pages of the current ACPI specifications and got the impression that
understanding this thoroughly will probably require a considerable
amount of time).
1) What is "the driver" exactly? Is it part of the ACPI sub-system?
If you refer to a "driver", which doesn't belong to the ACPI sub-system,
then a driver calling the HWC method would imply that you refer to a
driver running on an OS with ACPI support being enabled, is this
correct?
In this case kernel debugging would show (assuming this would not be
prevented) the interaction between this driver / the OS and the ACPI
sub-system, right?
2) Is it correct that the ACPI sub-system is active / running and able
to access other parts of the system no matter whether the OS supports it
or not (or whether one would disable the support)? This is what two
persons possessing a profound knowledge about low-level hardware topics
said, so I'd be curious to hear a definite statement on this from
someone who actively works on the ACPI development.
I would assume that simply performing ACPI debugging has its limits when
trying to narrow down issues like this. Both VirtualBox and QEMU support
specifying individual ACPI tables for a VM - So wouldn't it be the most
simple solution to specify the according / affected table(s) (all of
them can be downloaded from my GoogleDrive folder) to a VM running a
Linux system with a kernel customized for debugging, and then compare
the verbose debugging output 1) with these tables specified against the
output 2) without these tables specified?
I can hardly imagine that the ACPI team at Intel does not have
experience in doing so, as this is surely a well-working method to debug
ACPI-related issues in general.
3) Assuming that this ACPI code is not 'malicious code' / an 'ACPI based
rootkit' but simply erraneous ACPI code (if this should be the case,
then such a rootkit would surely prevent that it gets overwritten by
performing a BIOS update), would flashing the ACPI would overwrite the
ACPI code as well? Previously I talked with a LibreBoot developer, who
certainly knew what he was talking about this, and he ensured me that
certain parts of the BIOS won't be overwritten when performing a BIOS
flash - But in this context we didn't discuss whether the ACPI code
belongs to the parts which won't be overwritten or not, so also in this
case a true expert's statement would definitely be appreciated. ;)
[Moore, Robert]
We develop the ACPICA OS-independent code in our group. We are not a
customer service organization, and we have little contact with HP
itself. We cannot offer help in this area.
The accepted path is to report issues like this to the computer
vendor, in this case HP.
Well, I already guessed that you are not a customer service
organization... Could you at least provide me a contact address (without
posting it on the mailing list), so that I could forward this to a
competent department at HP (instead of first having to contact their
customer service)?
By the way, if the ACPI code is "OS-independent", when why should there
be (e. g.) the keyword "linux" in my system's ACPI code?
Kind regards and thanks in advance
David Renz
--
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
