Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 05 Nov 2005 17:34:13 -0800
From:      Nate Lawson <nate@root.org>
To:        Mike Silbersack <silby@silby.com>
Cc:        acpi@FreeBSD.org
Subject:   Re: cvs commit: src/sys/conf files src/sys/modules/acpi/acpi Makefile src/sys/dev/acpica acpi_battery.c acpi_smbat.c acpi_smbus.h      acpiio.h
Message-ID:  <436D5D95.3040901@root.org>
In-Reply-To: <20051105191616.M870@odysseus.silby.com>
References:  <200511052355.jA5NtuPg026403@repoman.freebsd.org> <20051105191616.M870@odysseus.silby.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Moving to the acpi@ list.

Mike Silbersack wrote:
> 
> Hm, since I cvsup'd from last week's releng_6 to today's, I noticed two 
> acpi-related things.
> 
> 1.  The smart battery support seems to work properly for me.  However, 
> the sysctls hw.acpi.battery.life, hw.acpi.battery.time, and 
> hw.acpi.battery.state take forever to read, so a sysctl -a | grep acpi 
> (or any other use of sysctl -a) takes far longer than it used to.

Sprinkle some printfs into sys/dev/acpica/acpi_smbat.c, in particular 
the bst and bif functions.  Are they timing out?  Where is the time 
spent, reading from the EC?

> 2.  Now, powerd seems to be causing ~30% system cpu load - top shows it 
> switching between the "nanslp" and "ecpoll" wait states.  This may be 
> due to some other recent change to acpi, I'm not sure how to best test.

ecpoll is the sleep label in acpi_ec.c for accessing the embedded 
controller.  The only thing powerd does that is related to acpi is read 
the AC line status.  So perhaps that hits your ec and it is timing out. 
  Can you try the powerd from -current?  It waits for events from devd 
instead of polling the AC line status.

-- 
Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?436D5D95.3040901>