From owner-acpi-jp@jp.FreeBSD.org Thu Aug  7 01:53:15 2003
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) id h76GrFf48081;
	Thu, 7 Aug 2003 01:53:15 +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 h76GrDT48076
	for <acpi-jp@jp.FreeBSD.org>; Thu, 7 Aug 2003 01:53:14 +0900 (JST)
	(envelope-from nate@rootlabs.com)
Received: (qmail 73715 invoked by uid 1000); 6 Aug 2003 16:53:08 -0000
From: Nate Lawson <nate@root.org>
To: "Michael W. Oliver" <michael@gargantuan.com>
cc: acpi-jp@jp.FreeBSD.org
In-Reply-To: <20030806072535.L73306@root.org>
Message-ID: <20030806095131.Q73637@root.org>
References: <20030725095421.D44638@root.org> <200307301352.20579.michael@gargantuan.com>
 <20030730134529.Y58089@root.org> <200308031819.58241.michael@gargantuan.com>
 <20030806072535.L73306@root.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Wed, 6 Aug 2003 09:53:08 -0700
X-Sequence: acpi-jp 2556
Subject: [acpi-jp 2556] Re: cvs commit: src/sys/dev/acpica acpi_ec.c
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: nate@root.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+030802

On Wed, 6 Aug 2003, Nate Lawson wrote:
> On Sun, 3 Aug 2003, Michael W. Oliver wrote:
> > +--- On Wednesday, July 30, 2003 16:46,
> > | Nate Lawson proclaimed:
> > | On Wed, 30 Jul 2003, Michael W. Oliver wrote:
> > | > | While I see a large max delay (21 ms), I don't see any errors.  Do
> > | > | you get any errors of AE_NO_HARDWARE_RESPONSE?
> >
> > FYI, I snipped this from my periodic run from this morning:
>
> Does that mean your system was under heavy load?  The ATA driver (and most
> other disk drivers) hold Giant and so heavy interrupt load can cause
> immense latency.
>
> > acpi_ec0: info: new max delay is 51000 us
> > acpi_ec0: EcRead: Failed waiting for EC to send data.

FYI, try setting hw.acpi.ec.poll_delay to something much greater than 50
(try 1000) and see what the largest delay you get is while running
periodic.

-Nate
