From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 28 11:15:37 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 39CE81065672 for ; Sun, 28 Jun 2009 11:15:37 +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 A82268FC24 for ; Sun, 28 Jun 2009 11:15:36 +0000 (UTC) (envelope-from freebsdusb@bindone.de) Received: (qmail 13085 invoked by uid 89); 28 Jun 2009 11:15:35 -0000 Received: from unknown (HELO ufo.bindone.de) (mg@bindone.de@87.152.188.16) by mail.bindone.de with ESMTPA; 28 Jun 2009 11:15:35 -0000 Message-ID: <4A4750D1.9040505@bindone.de> Date: Sun, 28 Jun 2009 13:15:29 +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> <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> <4A464343.8090502@bindone.de> <3a142e750906280213l2931a573r9479c111742bcfa0@mail.gmail.com> In-Reply-To: <3a142e750906280213l2931a573r9479c111742bcfa0@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: Sun, 28 Jun 2009 11:15:37 -0000 Paul B. Mahol wrote: > On 6/27/09, Michael Gmelin wrote: >> 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. > > I think this is best solution on long run. > >> 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 > > If querying number of instances of GUID is possible go for it. > >> - 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 > > Also if possible, it would be nice if acpi_hp doesn't output > entries which are not available on certain laptops. > Do you mean BIOS entries? Can you give me an example?