Re: PATCH: ecng for 6.x and 7.x

William Grzybowski wrote:
> On 9/6/07, *Nate Lawson* <nate_at_root.org <mailto:nate_at_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