From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCxcS-0005Yg-Db for qemu-devel@nongnu.org; Tue, 05 Mar 2013 14:33:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UCxUK-0005fC-7a for qemu-devel@nongnu.org; Tue, 05 Mar 2013 14:26:52 -0500 Received: from mail-qa0-f43.google.com ([209.85.216.43]:36522) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UCxUJ-0005ev-Uc for qemu-devel@nongnu.org; Tue, 05 Mar 2013 14:25:23 -0500 Received: by mail-qa0-f43.google.com with SMTP id dx4so2116645qab.2 for ; Tue, 05 Mar 2013 11:25:23 -0800 (PST) Sender: Paolo Bonzini Message-ID: <5136469F.7080904@redhat.com> Date: Tue, 05 Mar 2013 20:25:19 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1362499403-16514-1-git-send-email-pbonzini@redhat.com> <1362502791.32301.13.camel@i7.infradead.org> <51364381.902@redhat.com> In-Reply-To: <51364381.902@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/3] wakeup: only reset the CPU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: aliguori@us.ibm.com, seabios , David Woodhouse , qemu-devel@nongnu.org Il 05/03/2013 20:12, Laszlo Ersek ha scritto: > On 03/05/13 17:59, David Woodhouse wrote:> On Tue, 2013-03-05 at 17:03 +0100, Paolo Bonzini wrote: >>> Resuming from suspend-to-RAM should not reset all devices. Only the >>> CPU should get a reset signal. >> >> Hm... on reflection, I don't actually know if this is true. >> >> Perhaps we *should* reset all devices. After all, in a real machine >> they'll all have been turned off and the RAM will have been in >> self-refresh. Surely they have to be reset? >> >> So maybe we should *let* the i440FX PAM registers get reset to point to >> ROM. And fix the firmware to *cope* with that, check to see if the >> shadow RAM already holds an image of a started-up firmware with the >> correct checksum, and jump back to it. >> >> That is: perhaps it's a *SeaBIOS* bug that suspend/resume doesn't work >> if the PAM configuration is reset? > > I think it is indeed a problem with SeaBIOS. Open romlayout.S: [...] > > It checks the CMOS only after looking at HaveRunPost. The value of > HaveRunPost depends on the PAM settings. It's always 0 in ROM, in which > case we continue at handle_post() [src/post.c]. Actually, Peter explained that it is okay. S3 doesn't clear the PAM configuration, but S4 does. The PAM registers are attached to the same power line as the RAM. Paolo