cvs commit: src/sys/dev/acpica acpi.c

[Eric Anderson]

Nate Lawson wrote:
> Eric Anderson wrote:
> 
>> John Baldwin wrote:
>>
>>>
>>> Actually, we already reprogram all the APIC intpins on resume in 
>>> ioapic_resume() from saved state.  There's actually not anything for 
>>> ioapic_suspend() to do, so I've mostly left this as a marker until 
>>> the current resume code is tested.
>>
>>
>> I now see that when it is trying to come out of resume, it panics.  I 
>> can't see it, and my serial access doesn't seem to work at that point 
>> (I booted with boot -h, maybe I should have set some additional 
>> options) - but if I type 'call doadump' on the keyboard, it dumps.  
>> However, I have no idea what to do with it now that it's dumped :)
> 
> 
> That's getting somewhere.  Use savecore(8) to get a copy of the dump 
> image.  Then run dmesg on it to get console messages and gdb 
> /boot/kernel/kernel vmcore and type "bt" to get a backtrace and "print 
> panicstr" to get the panic message.

The 'call doadump' must be failing, or something.  The machine runs the 
disk like mad for hours, and never stops.  I can't see the screen (acpi 
or something turned it off), otherwise I would tell you more.

So, two questions:
1) How can I get it to leave my screen alone when suspending, so I can 
see what's happening on it's way back up during resume?

2) How can I get the debugger to use the serial port at this point?  It 
works once I've booted up, etc, but when resuming the serial port never 
comes back alive.  I have comconsole setup in my loader.conf, and that 
seems to switch the bootup and such, but once I try to resume, it kills 
the serial and the console keyboard so I have nothing.

Eric




-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
A lost ounce of gold may be found, a lost moment of time never.
------------------------------------------------------------------------