Date: Thu, 08 Nov 2007 12:46:31 -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: <473375A7.3080804@root.org> In-Reply-To: <20071108194729.F3E5B4500E@ptavv.es.net> References: <20071108194729.F3E5B4500E@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman wrote: >> 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. Ok. hint.apic.0.disabled="1" also works to disable it without a recompile. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?473375A7.3080804>