[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deep sleep modes on 7-BETA locks up syscons
- To: Kevin Oberman <oberman_(_at_)_es_(_dot_)_net>
- Subject: Re: Deep sleep modes on 7-BETA locks up syscons
- From: Nate Lawson <nate_(_at_)_root_(_dot_)_org>
- Date: Thu, 08 Nov 2007 12:46:31 -0800
- Cc: acpi_(_at_)_freebsd_(_dot_)_org
Kevin Oberman wrote:
>> Date: Thu, 08 Nov 2007 11:25:16 -0800
>> From: Nate Lawson <nate_(_at_)_root_(_dot_)_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.
freebsd-acpi_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-acpi-unsubscribe_(_at_)_freebsd_(_dot_)_org"
Visit your host, monkey.org