RE: ASL issues on HP machine

["Zheng, Lv" <lv.zheng@intel.com>]

Hi,

> From: acpi-request@eclists.intel.com [mailto:acpi-request@eclists.intel.com] On Behalf Of Moore,
> Robert
> Subject: RE: [acpi] ASL issues on HP machine
> 
> 
> 
> > From: David Renz [mailto:David.Renz@ruhr-uni-bochum.de]
> > 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.

If the AML code is trying to access an invalid memory region.
Then we needn't do Windows behavior validation to say "no" to such BIOS issue.
Such sanity check should always be done by ACPICA.

If there is no problem running this table on Windows, I would imagine that is
just because the AML code path is not triggered.
Without giving the details why it is not triggered, the report looks useless.

> 
> 
> >
> >
> > > The exact ASL statement
> > > showing the problem is this:
> > >
> > >
> > >         CreateField (Arg1, 0x80, 0x0400, D128)
> > >
> > >
> > > The input buffer (Arg1) is 160 bits, but this CreateField statement is
> > > attempting to create a field starting at bit offset 0x80 (bit 128) for
> > > length 0x400 (1024). This in fact goes way beyond the size of the
> > > input buffer (out to bit 0x480, which is decimal 1152). Of course, the
> > > ACPICA interpreter detects this and appropriately aborts the method.
> > >
> > > I cannot speak any further to this problem because it is either a
> > > firmware or a driver problem. In either case, the vendor should be
> > > notified.
> >
> > But this is not my task as a customer, don't you think so? The easiest
> > way to shed some light on this would be to send my system's dumped ACPI
> > code to HP, so that they can check whether this is the code which should
> > be on my machine, isn't it? And I would assume that HP won't do that if
> > some custome requests them to do so, but they surely wouldn't refuse
> > this request if someone from the Intel ACPI team would approach them.
> [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.
> 

Agreed. We are not BIOS hygiene team, our focus is not to deal with
malicious AML code, but dealing with bugs/quality issues in ACPI
subsystem.

Thanks
Lv

> 
> 
> >
> >
> >
> > Kinds regards
> >
> > David Renz