Re: Updated ec-burst.diff patch

> Date: Tue, 1 Jul 2003 01:07:53 -0700 (PDT)
> From: Nate Lawson <nate_at_root.org>
> Sender: owner-freebsd-current_at_freebsd.org
> 
> Please download and try the new version.  It correctly implements burst
> mode to the best of the 2.0 spec.  Like the previous message, please
> report the appropriate dmesgs ("acpi_ec0*" and "EC Waited*") and any
> errors or regression.  I've tested "du -a /" while plugging/unplugging the
> power cable on my laptop many times with no errors.
> 
> I haven't received any feedback yet.  This WILL hit the tree in a few
> weeks because it fixes known problems.  Test it now or test it then.  :)

I don't know if you want/need more data, but I am attaching the
output from my T30. I am including the results both before and after
the patch. The errors are about the same for each although the patched
version printed additional information.

One side note is that I get the errors for BAT0, BAT1, LID._PSW and
SLPB._PSW and these are all things that behave "imperfectly" with
ACPI. 

The battery is not too back, but with the gnome Battery Charge Monitor
V2.2.2 (which claims to support ACPI), the battery charge seems to
cycle from the total of both batteries to just the primary to no
battery to both, etc. Very wird. The gkrellm battery display (which
probably uses the apm interface) seems to work fine as does the output
of the apm(8) command. I have not tried repeatedly issuing sysctls to
display the hw.acpi.battery values to see if they are unstable.

The lid and sleep switch both get initially set to S1 which is pretty
useless and not available on the T30. This may explain why it gets
errors (or not).

In the log with the patch I put the unit to sleep (acpiconf -s 3) and
the behavior is the same as always...prtty much works, but spins down
the disk too fast and does not turn off the backlight on the
display. On waking, it fails to re-init the USBs.

If I could get sleep to work, I could switch to ACPI.

Do the machdep.apm_*_delay sysctls do anything when ACPI is running or
is there any other mechanism to delay transition to S3?
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634