From owner-freebsd-acpi@FreeBSD.ORG Sat Jun 27 16:05:28 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE8CE1065670 for ; Sat, 27 Jun 2009 16:05:28 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: from mail.bindone.de (mail.bindone.de [80.190.134.51]) by mx1.freebsd.org (Postfix) with SMTP id 68FE08FC18 for ; Sat, 27 Jun 2009 16:05:28 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 61604 invoked by uid 89); 27 Jun 2009 16:05:27 -0000 Received: from unknown (HELO ufo.bindone.de) (mg@bindone.de@87.152.167.4) by mail.bindone.de with ESMTPA; 27 Jun 2009 16:05:27 -0000 Message-ID: <4A464343.8090502@bindone.de> Date: Sat, 27 Jun 2009 18:05:23 +0200 From: Michael Gmelin User-Agent: Thunderbird 2.0.0.17pre (X11/20090202) MIME-Version: 1.0 To: "Paul B. Mahol" References: <4A3E1784.2050406@bindone.de> <3a142e750906232257y4b1e255en9374c05079f04520@mail.gmail.com> <4A41C2CF.4020205@bindone.de> <3a142e750906232353g37b5f001p89948a2fe6a3e66e@mail.gmail.com> <4A41E39E.1090208@bindone.de> <4A41E66D.2080504@bindone.de> <3a142e750906240347o393ea738i54fc9ce215bebab2@mail.gmail.com> <4A44AC9B.504@bindone.de> <3a142e750906270327t765077f8ta4dffed054f70c53@mail.gmail.com> <4A45FF8C.1070604@bindone.de> <3a142e750906270839x41686881j13c7a73ae38586e4@mail.gmail.com> In-Reply-To: <3a142e750906270839x41686881j13c7a73ae38586e4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Two new acpi modules, acpi_wmi and acpi_hp X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 16:05:29 -0000 Paul B. Mahol wrote: > On 6/27/09, Michael wrote: >> Paul B. Mahol wrote: >>> On 6/26/09, Michael wrote: >>>> Paul B. Mahol wrote: >>>>> On 6/24/09, Michael wrote: >>>>>> Besides the other information requested, maybe you can also tell me >>>>>> your >>>>>> exact HP model number >>>>> Here is information you requested. >>>>> >>>> Hi Paul, >>>> >>>> please find attached a patch against the current version of the acpi_hp >>>> driver in CURRENT (source and manpage). It might need some tweaking if >>>> you're testing on 7.2 (headers). I also provided the full acpi_hp.c and >>>> acpi_hp.4 versions in case you can't patch. >>>> >>>> Patch: >>>> patch -d /usr/src < /path/to/acpi_hp.patch >>>> >>>> This patch adds the sysctl dev.acpi_hp.0.verbose (as you suggested) and >>>> should fix /dev/hpcmi on your machine. >>>> >>>> Please tell me if this works, so I can send it to Raul. >>> It works. >>> But I still get acpica error: >>> >>> ACPI Error: Field [C2CA] at 336 exceeds Buffer [C281] size 328 (bits) >>> 20090521 dsopcode-697 >>> ACPI Error (psparse-0633): Method parse/execution failed >>> [\\_SB_.C241.WQBC] (Node 0xc3dcfb60), AE_AML_BUFFER_LIMIT >>> >> This is a bug in the DSDT provided by HP. The error is emitted in the >> underlying acpi layers while reading a buffer that contains more data >> then it should. The only thing you could do about this is patching your >> DSDT. > > How, what to modify? > I already modified and use custom DSTD, because one of thermal sensors > reported absurd temperature most of time ... > > Search for the field C281. Modify C281 to say 336 bits instead of 328. (this should be line 7498 in your DSDT: Name (C281, Buffer (0x29) {}) should be changed to Name (C281, Buffer (0x2A) {}) ) That's the theory, I can't tell if that has any negative side effects. It seems like that's the last BIOS entry instance in the DSDT (same here, my machine provides 57, yours 41 if I recall correctly). So changing this is absolutely your own risk + I don't think it make sense to require all users to change their DSDT anyway. If I had more evidence that this is happening with all HPs I could change the acpi_wmi kernel interface to allow querying the number of instances of the GUID and iterate only over numberofinstances-1 instances to avoid this error. What do you think of the following plan: - Extend acpi_emi to provide a method to query the number of instances of a GUID. This way acpi_hp could know the number of instances and avoid hitting the last instance - Make acpi_hp only iterate over maxinstances-1 instances - Extend cmi_detail to have an additional bit that disables this behaviour (so it behaves like it did before, assuming that there are HP notebooks that don't have these issues) - Document all of this in the man page cheers Michael