Deep sleep modes on 7-BETA locks up syscons

[Nate Lawson]

Kevin Oberman wrote:
>> Date: Fri, 9 Nov 2007 09:14:03 +0100
>> From: Simon Barner <barner at FreeBSD.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.
>> As reported on -current, I used to have this problem, but it seems to
>> have been fixed with the latest BIOS update (T61):
>>
>> Before the BIOS update, C3 caused similar lock ups in syscons when
>> running on battery (it did work in X). When on AC, there has never been
>> any problem.
>>
>> I made available some information (dmesg, kernel config, acpi dump,
>> dev.cpu and hw.acpi sysctls) in the hope the provide something usefull.
>>
>> http://people.freebsd.org/~barner/cx/
> 
> Thanks!
> 
> The symptoms are remarkably similar, but there are two differences which
> my post did not make clear.
> 
> 1. I just have to be at C3 and in a syscons to see the problem. It does
>    no matter whether I am on battery or AC line.
> 
> 2. I am running the latest available BIOS for my system. It is from
>    Sept. 2006, but I just checked and it is the latest available.
> 
> The only win I see for APIC is that the audio gets its own IRQ. Hardly
> worth the effort, though I could probably add hints to do at least some
> separation of stuff on IRQ 16, pcib1, vgapci0, bge0, cbb0.
> 
> Thanks again for getting back to me on this.

Perhaps it has something to do with syscons being under Giant and X
changing how video interrupts are handled.  Just a wild theory.

-- 
Nate