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