From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 28 09:13:30 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 161A5106566C for ; Sun, 28 Jun 2009 09:13:30 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by mx1.freebsd.org (Postfix) with ESMTP id 8C78C8FC1B for ; Sun, 28 Jun 2009 09:13:29 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz6 with SMTP id 6so291046bwz.43 for ; Sun, 28 Jun 2009 02:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Zn7LeRUUil+j/TBxHy8iirDKYnJTcHPKsxd822w5TxY=; b=Jpbg6FGZMGdFgQZYaIVe9leJk3VEMG0Lfu8jeqN2j00vwaxZW3i1NX64hSaKga3eu1 OnbOIK7S8dWNvo5vkWJTRdAvazD0W3H0oaD9wiTNxlb4SHDqc1MJiEIhK+uh7xDsUf7y A4R64i3ggclB6blTdLMy+L9S5cBYPEB0FZVfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=u3JYgeOXrZFC6TtIMDcQzZuXbDEH+TD1PAAEN2sK4AUF2KvOmLkZpkrVw2Gyy98co2 5rr6dW+SYs2Ywu0fB9kILeNOFflihk1P6H4NFEbFTHE4KM0iWRBsC4RzY0CrPC3xTo+F sSrdPLew9b8grogIpPvYlHn4AT2pO/9dNeRGA= MIME-Version: 1.0 Received: by 10.204.117.20 with SMTP id o20mr3612978bkq.1.1246180408652; Sun, 28 Jun 2009 02:13:28 -0700 (PDT) In-Reply-To: <4A464343.8090502@bindone.de> 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> Date: Sun, 28 Jun 2009 11:13:28 +0200 Message-ID: <3a142e750906280213l2931a573r9479c111742bcfa0@mail.gmail.com> From: "Paul B. Mahol" To: Michael Gmelin 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 09:13:30 -0000 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. -- Paul