hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP]

Nate Lawson nate at root.org
Mon Oct 2 17:30:08 PDT 2006


Andrea Bittau wrote:
> On Mon, Oct 02, 2006 at 02:24:18PM -0400, John Baldwin wrote:
>> well as resuming the local APIC.  Can you test this w/o SMP and make sure it 
>> works?
> 
> I'll give it a shot as soon as I get some time.
> 
>> Probably we need to get onto the BSP via sched_bind() during suspend and then 
>> stop the other CPUs using stop_cpus().  The hard part, however, is properly 
> 
> Yea I do that in acpi_SetSleepState().  Essentially I copied the shutdown code.
> 
>> resuming the darn things.  Do you know what mode the CPUs come back up in?  
>> It looks like we need to resend startup IPIs to them from your patch.
> 
> Yea it all comes back in real mode.  I've tried using the standard freebsd "boot
> code" for waking up the second CPU.  There were some issues with the BSP not
> using PTD_Idle.  I don't know enough about computers and freebsd to know what
> exactly that means.  Also, when the second CPU came back, if it entered the
> scheduler, it would die, so I had to leave it in the idle loop by setting the
> cpu_hlt mask.
> 
> Anyway, the correct way to do it I think is to generalize the save state &
> wakeup code used by the BSP in acpi_sleep_machdep().  That is, the second core
> should save its state and wake up the same way as the BSP does.  It should not
> use the "come to life mechanism" used at boot-time.  The reason is that the
> memory is setup properly and the second core should have saved registers which
> make sense so less "initialization and setup" needs to be performed.

I disagree.  Instead of trying to capture all that register state, 
including MSRs, MTRRs, etc., it seems easier just to reinitialize from 
scratch.  We'll need to do that anyway once suspend-to-disk is 
implemented since that kind of resume is equivalent to a hard power cycle.

-- 
Nate


More information about the freebsd-mobile mailing list