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