Deep sleep modes on 7-BETA locks up syscons

[Kevin Oberman]

> Date: Thu, 08 Nov 2007 12:46:31 -0800
> From: Nate Lawson <nate at root.org>
> 
> Kevin Oberman wrote:
> >> Date: Thu, 08 Nov 2007 11:25:16 -0800
> >> From: Nate Lawson <nate at 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.

It's taken a while for me to get to it, but turning off APIC does "fix"
the problem. I can certainly turn off APIC, bit I'd really like to figure
out why it only affected syscons sessions as well as whether it can be
fixed so that it is not an issue. (APIC does not seem to buy much as the
shared IRQ just seems to move from 11 to 16, but still has all of the
same devices...cbb, bge, vgapci, and all of the pci bridges.

Thanks, Nate!
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20071109/d1015a75/attachment.pgp