From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 8 20:46:42 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E7DD16A419 for ; Thu, 8 Nov 2007 20:46:42 +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 63BCD13C4AA for ; Thu, 8 Nov 2007 20:46:42 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 99338 invoked from network); 8 Nov 2007 20:46:35 -0000 Received: from 209-128-117-003.bayarea.net (HELO ?10.0.1.144?) (nate-mail@209.128.117.3) by root.org with ESMTPA; 8 Nov 2007 20:46:35 -0000 Message-ID: <473375A7.3080804@root.org> Date: Thu, 08 Nov 2007 12:46:31 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kevin Oberman References: <20071108194729.F3E5B4500E@ptavv.es.net> In-Reply-To: <20071108194729.F3E5B4500E@ptavv.es.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: Re: Deep sleep modes on 7-BETA locks up syscons X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2007 20:46:42 -0000 Kevin Oberman wrote: >> Date: Thu, 08 Nov 2007 11:25:16 -0800 >> From: Nate Lawson >> >> Kevin Oberman wrote: >>> I have already sent much of this to -current@, but ACPI is clearly >>> involved and I'll admit that I don't fully understand all of the >>> implications of sleep (Cx) states. >>> >>> Recently I discovered that I could no longer boot up on battery. (As it >>> turned out, I could not shut down, either.) The boot proceeds to devd >>> which kicks off power_profile which resets the cx_state. I use >>> performance_cx_lowest="HIGH" and economy_cx_lowest="LOW" which drops >>> cx_state to C4 when on battery. >>> >>> States of C1 and C2 don't cause a problem and C3 and C4 do. (C4 is only >>> available when on battery.) >>> >>> At that point things slow to a crawl. I have never had the patience to >>> see if it would ever finish the boot, but it took many minutes just to >>> start ipfw and load the rules. When anything made it to the screen, it >>> appeared several lines at a time. >>> >>> If I am up and switch cx_state to C3 or C4 while running X, things work >>> fine, but, if I exit X while the cx_state is still C3 or C4, the system >>> switches back to the vty and spits out a few lines before locking up >>> again. After several minutes I was able to log in to another vty and >>> change the cx_state which started things running normally. >>> >>> This is a T43 (Pentium-M @2GHz) running ULE on 7-BETA2 of Nov. 4. The >>> problem has not been there for too long, but I can't say for sure when I >>> last ran on battery when not in X. >>> >>> I don't know if this is a syscons issue or some ugly interaction between >>> syscons and ULE or an ACPI issue. >>> >>> If anyone else has seen this or has any ideas, I'd love to hear about it. >> Does changing timers help? sysctl kern.timecounter.hardware = TSC or >> other options from kern.timecounter.choice >> >> I'm wondering if the local APIC timer is the problem. > > Crap! I need to remember when I make fairly fundamental changes on my > system! I entirely forgot that I turned on APIC on my system for the > first time as it didn't work when I first got the system. I'm pretty > sure that this is what tickled it. > > Unfortunately, setting the timecounter to TSC does not seem to make a > difference. :-( But I do appreciate the APIC suggestion. I'm about to > build a new kernel without APIC to confirm this. Ok. hint.apic.0.disabled="1" also works to disable it without a recompile. -- Nate