Date: Thu, 08 Nov 2007 11:47:29 -0800 From: "Kevin Oberman" <oberman@es.net> To: Nate Lawson <nate@root.org> Cc: acpi@freebsd.org Subject: Re: Deep sleep modes on 7-BETA locks up syscons Message-ID: <20071108194729.F3E5B4500E@ptavv.es.net> In-Reply-To: Your message of "Thu, 08 Nov 2007 11:25:16 PST." <4733629C.2010707@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_1194551249_29324P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Date: Thu, 08 Nov 2007 11:25:16 -0800 > From: Nate Lawson <nate@root.org> > > 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. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1194551249_29324P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFHM2fRkn3rs5h7N1ERAr/XAKCWlEbCULashnVV2GgNjLGY7iFYKQCgnV8r +1Sf8PPKgo847KjJNU0vRYU= =lv4o -----END PGP SIGNATURE----- --==_Exmh_1194551249_29324P--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071108194729.F3E5B4500E>