Hi, > From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi-owner@xxxxxxxxxxxxxxx] On Behalf Of David > Renz > Subject: Re: ASL issues on HP machine > > 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). It's simpler than what you are mentioning. You only need to read (in case of ACPI spec 6.2) 1-5 and 19-21. Others are talking about the "application of ACPI" from ACPICA's point of view. It just took me 1-2 weeks to translate these chapters into my native language. In case of understanding ASL/AML concept, you only need to be an expert of 19.3. > > 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. ;) TBH, I wasn't worrying about "malicious code", I was always worrying about The known software defects that wouldn't be reported by the community. Many software developers (probably including you) can soon tell if a software is buggy or not by taking a first glance at it. Thanks and best regards Lv > > > > [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 -- 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
