Date: Mon, 02 Oct 2006 17:29:57 -0700 From: Nate Lawson <nate@root.org> To: Andrea Bittau <a.bittau@cs.ucl.ac.uk> Cc: freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: hack for getting suspend/resume to half work on an IBM Thinkpad x60s [SMP] Message-ID: <4521AF05.50208@root.org> In-Reply-To: <20061002223055.GA8217@shorty.sorbonet.org> References: <20060921000628.GA1832@shorty.sorbonet.org> <200610021424.18562.jhb@freebsd.org> <20061002223055.GA8217@shorty.sorbonet.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4521AF05.50208>