From owner-freebsd-acpi@FreeBSD.ORG Sat Sep 8 02:41:34 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 847CD16A46B for ; Sat, 8 Sep 2007 02:41:34 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 544F713C461 for ; Sat, 8 Sep 2007 02:41:34 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 96174 invoked from network); 8 Sep 2007 02:41:35 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 8 Sep 2007 02:41:35 -0000 Message-ID: <46E20A1D.7050608@root.org> Date: Fri, 07 Sep 2007 19:34:05 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: William Grzybowski References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> In-Reply-To: <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x 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, 08 Sep 2007 02:41:34 -0000 William Grzybowski wrote: > On 9/6/07, *Nate Lawson* > wrote: > > Nate Lawson wrote: > > I've done some major rework on the EC driver. This should help with > > various problems, including timeouts while checking battery status or > > temperature. The attached patches are for 6.x and 7.x. Please > test and > > let me know if you get any new errors on dmesg or if it fixes > things for > > you (especially HP/Compaq laptop owners). > > > > If you still have problems, try setting each of these tunables > > individually and then both together (i.e., in > /boot/loader.conf). Note > > that this will be four (4) test runs total, so don't just set both and > > say it doesn't work. > > > > debug.acpi.ec.burst= "1" > > debug.acpi.ec.polled="1" > > > > I've tested both patches on a Panasonic Y4 and UnnamedOEM laptop, no > > problems in either regular or burst mode. > > I tested this patch on my acer notebook (intel chipset) and i did not > notice any changes, unless some errors on dmesg, like: > acpi_ec0: EcCommand: no response to 0x84 > acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE > acpi_ec0: EcCommand: no response to 0x82 > acpi_ec0: EcCommand: no response to 0x80 > ACPI Error (psparse-0626): Method parse/execution failed > [\\_TZ_.THRM._TMP] (Node 0xc3bbdcc0), AE_NO_HARDWARE_RESPONSE > ACPI Error (psparse-0626): Method parse/execution failed > [\\_SB_.ACAD._PSR] (Node 0xc3bc02a0), AE_NO_HARDWARE_RESPONSE Are those errors new or have they always been there? I noticed with the "polled" tunable set, it appears to go away. Is this right or are there errors later in the dmesg? > I tried the 4 test runs which you mentioned , when I boot with both > debug.acpi (burst and polled = 1) I got a kernel panic but i couldn't > save the backtrace, but it was about _sx_xlock_hard in recursed on > non-recursive function, line 209 on acpi_ec.c If you could try this again and get the full panic message, that would help a lot. I need both places the sx was locked, not just one. It usually will report something like "attempt to acquire sx at XXX, previously acquired at YYY". I need both values to figure out what lock order is happening on your system. > I'm send links for 3 verbose boot's (i couldnt for burst and polled > because the panic) if you want to take a look.. > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec.gz > > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-burst.gz > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-polled.gz > One thing I noted in your dmesg for the polled case was the "acpi_ec0: warning: EC done before starting event wait" message. That tells me your system probably needs some extra checking to figure out when the status is actually ready, but that's a complicated case I'm not sure how to solve yet. But did any other errors show up in that case? Did thermal/battery status get reported correctly? One thing you could do to help me is to build the kernel and acpi module with: options KTR options KTR_COMPILE=KTR_DEV options KTR_ENTRIES=65536 Then, boot to multi-user for each of the 4 cases I mentioned above (don't bother for the panic case) and run: ktrdump -rt | sort -n | gzip -9c > foo.ktr I'll then be able to see more detail about how the EC is behaving on your system. Thanks, -- Nate