From owner-freebsd-acpi@FreeBSD.ORG Thu May 6 10:43:54 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E51ED16A4CE for ; Thu, 6 May 2004 10:43:54 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4858F43D39 for ; Thu, 6 May 2004 10:43:54 -0700 (PDT) (envelope-from len.brown@intel.com) Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i46Hi1SP011701; Thu, 6 May 2004 17:44:01 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i46HhdPv030713; Thu, 6 May 2004 17:44:17 GMT Received: (from dhcppc4 [10.127.52.99])M2004050610433108427 ; Thu, 06 May 2004 10:43:32 -0700 From: Len Brown To: Mike Silbersack In-Reply-To: <20040506113610.D2198@odysseus.silby.com> References: <200405052004.i45K4EnF029671@repoman.freebsd.org> <20040506025051.V630@odysseus.silby.com> <20040506084132.L41848@root.org> <20040506113610.D2198@odysseus.silby.com> Content-Type: text/plain Organization: Message-Id: <1083865408.2292.172.camel@dhcppc4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Date: 06 May 2004 13:43:28 -0400 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) cc: acpi@freebsd.org Subject: Re: power savings and usb X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 17:43:55 -0000 On Thu, 2004-05-06 at 12:37, Mike Silbersack wrote: > On Thu, 6 May 2004, Nate Lawson wrote: > > > > Gah, except that my experiment in clockswitching made the usb stack mad, > > > so it's constantly priniting "usb0: X scheduling overruns", where X > > > appears to be a number containing one or two bits of entropy per second. > > > I will have to go visit ohci.c with a cluebat when I get a chance. > > > > > > Er, it stopped when I plugged in the power cord, and starts again when I > > > unplugged it. Is it possible that ohci.c is reading some USB voltage > > > value instead of the overrun bit that it thinks it is reading? > > > > hw.acpi.cpu.cx_supported: C1/0 C2/84 C3/120 > > hw.acpi.cpu.cx_lowest: 1 > > hw.acpi.cpu.cx_history: 9175/0 173443/9175 0/0 > > > > This means I am requesting a lowest sleep of C2 (idx 1 of the options > > supported). The history values show that I haven't used C3 at all and am > > using C2 at a rate of about 95%. > > > > ohci may have problems with C3. On my uhci, it demotes to C2 without > > causing problems. You can override this by setting in /etc/rc.conf: > > > > economy_cx_lowest="1" > > > > -Nate > > Something else must be happening, because: > > hw.acpi.cpu.cx_supported: C1/1 C2/99 C3/288 > hw.acpi.cpu.cx_lowest: 0 > hw.acpi.cpu.cx_history: 5558639/0 0/0 0/0 > > But, since I went and killed the scheduling overrun interrupts at the > source, we don't need to worry anymore. :) I expect that C2/99 means the FADT lists C2 latency as 99usec. Similarly for 288 usec C3 latency. This compares to the ACPI spec limits of 100 and 1000, respectively. This is relativly high latency, and the OS may decided that it isn't worth paying it. -Len