Deep sleep modes on 7-BETA locks up syscons
Nate Lawson
nate at root.org
Thu Nov 8 11:26:25 PST 2007
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
More information about the freebsd-acpi
mailing list