From owner-freebsd-stable@FreeBSD.ORG Tue Feb 27 23:09:23 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B3EE516A40E for ; Tue, 27 Feb 2007 23:09:23 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9BE13C4DA for ; Tue, 27 Feb 2007 23:09:23 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 58674 invoked from network); 27 Feb 2007 22:22:38 -0000 Received: from ppp-71-139-18-69.dsl.snfc21.pacbell.net (HELO ?10.0.5.55?) (nate-mail@71.139.18.69) by root.org with ESMTPA; 27 Feb 2007 22:22:38 -0000 Message-ID: <45E4AF37.9000207@root.org> Date: Tue, 27 Feb 2007 14:22:47 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.9 (X11/20070214) MIME-Version: 1.0 To: Ariff Abdullah References: <45E39552.2020607@root.org> <20070227193508.49076f8b.ariff@FreeBSD.org> In-Reply-To: <20070227193508.49076f8b.ariff@FreeBSD.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@FreeBSD.org Subject: Re: PATCH: new acpi embedded controller I/O model X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 23:09:23 -0000 Ariff Abdullah wrote: > On Mon, 26 Feb 2007 18:20:02 -0800 > Nate Lawson wrote: >> If you notice slower performance or get EC "timed out" messages on >> console, you try increasing these sysctls/tunables: >> >> debug.acpi.ec.timeout >> debug.acpi.ec.poll_time Before you go changing the logic, please... Try adjusting these parameters, including other values besides these: debug.acpi.ec.timeout=1000 # 1 sec total debug.acpi.ec.poll_time=100 # 100 usec polling (or try larger like 800) >> Or turn off this sysctl/tunable, disabling the new burst mode: >> debug.acpi.ec.burst=0 Try the above values both with and without burst mode. >> To find any performance problems, you'll need to rebuild the kernel >> and modules with this added to your kernel config: >> >> options KTR >> options KTR_ENTRIES=65536 >> >> Then reboot, load this kernel/acpi.ko, use the system for a while to >> trigger the problem behavior and generate output: >> ktrdump -t | gzip -c > ktr.out.gz Would you please submit the output requested above, along with sysctl debug.acpi.ec so I can know what parameters you were using? > --- sys/dev/acpica/acpi_ec.c Tue Feb 27 19:21:12 2007 > +++ sys/dev/acpica/acpi_ec.c Tue Feb 27 19:22:17 2007 > @@ -936,6 +936,7 @@ > count = ec_poll_time / EC_POLL_DELAY; > if (count <= 0) > count = 1; > + slp_ival = max(hz / 1000, 1); > for (i = 0; i < count; i++) { > EcStatus = EC_GET_CSR(sc); > if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) { > @@ -947,7 +948,15 @@ > Status = AE_OK; > break; > } > - AcpiOsStall(EC_POLL_DELAY); > + if (sc->ec_burstactive) > + AcpiOsStall(EC_POLL_DELAY); > + else { > + if (!cold) > + msleep(&sc->ec_csrvalue, &sc->ec_mtx, PZERO, "ecpoll", > + slp_ival); > + else > + AcpiOsStall(1000); > + } > } > > /* Your patch just goes straight into msleep() instead of doing any DELAY(). Does enabling the "#if 0" code right before your patch help? Please revert your patch and try the above. We need to reduce the amount of variation to track it down. -- Nate