Date: Thu, 08 Nov 2007 11:25:16 -0800 From: Nate Lawson <nate@root.org> To: Kevin Oberman <oberman@es.net> Cc: acpi@freebsd.org Subject: Re: Deep sleep modes on 7-BETA locks up syscons Message-ID: <4733629C.2010707@root.org> In-Reply-To: <20071108191739.9E90D45029@ptavv.es.net> References: <20071108191739.9E90D45029@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4733629C.2010707>