Date: Fri, 07 Sep 2007 19:34:05 -0700 From: Nate Lawson <nate@root.org> To: William Grzybowski <william88@gmail.com> Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: PATCH: ecng for 6.x and 7.x Message-ID: <46E20A1D.7050608@root.org> In-Reply-To: <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com> References: <46E0777A.8070901@root.org> <46E07AAF.2060000@root.org> <632825b40709070752o6fe867a2s3e7647e5444b1b5b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
William Grzybowski wrote: > On 9/6/07, *Nate Lawson* <nate@root.org <mailto:nate@root.org>> 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.gz>; > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-burst.gz > http://www.inf.ufpr.br/wg06/dmesg-acpi-ec-polled.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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46E20A1D.7050608>