From owner-acpi-jp@jp.FreeBSD.org Thu Aug 28 03:04:12 2003
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) id h7RI4Cx76483;
	Thu, 28 Aug 2003 03:04:12 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from rootlabs.com (root.org [67.118.192.226])
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) with SMTP/inet id h7RI4Aa76475
	for <acpi-jp@jp.FreeBSD.org>; Thu, 28 Aug 2003 03:04:10 +0900 (JST)
	(envelope-from nate@rootlabs.com)
Received: (qmail 31793 invoked by uid 1000); 27 Aug 2003 18:04:05 -0000
From: Nate Lawson <nate@root.org>
To: "Sergey A. Osokin" <osa@freebsd.org>
cc: acpi-jp@jp.FreeBSD.org
In-Reply-To: <20030827115225.GM41860@freebsd.org.ru>
Message-ID: <20030827110003.H31602@root.org>
References: <20030827115225.GM41860@freebsd.org.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Wed, 27 Aug 2003 11:04:05 -0700
X-Sequence: acpi-jp 2611
Subject: [acpi-jp 2611] Re: HP Omnibook 6100 and acpi
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: nate@root.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+030821

On Wed, 27 Aug 2003, Sergey A. Osokin wrote:
> I use FreeBSD 5.1-CURRENT (from 2003 Aug 25) on my HP
> Omnibook 6100 and have a problem with ACPI.
> I added following lines into my /etc/sysctl.conf
> hw.acpi.sleep_button_state=S3
> hw.acpi.lid_switch_state=S3
> hw.acpi.standby_state=S3
> then tried to close cover and computer goes in suspend
> mode. Then tried to open cover - computer resumed, I think all
> works fine (because I can remotely go to it), but TFT blank.
>
> Any idea?

You can try suspending/resuming while in X since it generally does a good
job of resetting the display.  However, even X does not reset the display
and/or re-enable the backlight for some video chips.  It is a known
deficiency that our VGA driver does not ever reset console mode correctly.

> And another problem: I have some debug messages from ACPI
> subsystem, for example:
>
> acpi_ec0: info: new max delay is 640 us
> acpi_acad0: acline initialization start
> acpi_acad0: On Line
> acpi_acad0: acline initialization done, tried 1 times
> acpi_cmbat1: battery initialization start
> acpi_cmbat0: battery initialization start
> acpi_ec0: info: new max delay is 11000 us
> acpi_cmbat0: battery initialization done, tried 2 times
> acpi_cmbat1: battery initialization failed, giving up
> acpi_ec0: info: new max delay is 51000 us
> acpi_ec0: EcCommand: no response to 0x84
> acpi_ec0: GPE query failed - AE_NO_HARDWARE_RESPONSE
> acpi_ec0: EcRead: Failed waiting for EC to send data.
>     ACPI-0438: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_RESPONSE
>     ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.EC0_.SMWR] (Node 0xc25e5120), AE_NO_HARDWARE_RESPONSE
>     ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.BAT1.CHBP] (Node 0xc25e4a00), AE_NO_HARDWARE_RESPONSE
>     ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.EC0_.SMSL] (Node 0xc25e50e0), AE_NO_HARDWARE_RESPONSE
>     ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.ISA0.EC0_._Q09] (Node 0xc25e5060), AE_NO_HARDWARE_RESPONSE

This indicates that your embedded controller started taking longer and
longer to respond while battery initialization was in progress.  Please
send full dmesg so I can know if your laptop is using _GLK.  It may be
that the EC locks the global lock for too long while processing the
battery initialization.  Also helpful would be the output of:
acpidump -o my.dsdt > my.asl

-Nate
