From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 25 00:27:05 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC0F916A4CF for ; Tue, 25 Jan 2005 00:27:05 +0000 (GMT) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9710D43D48 for ; Tue, 25 Jan 2005 00:27:04 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id E59ED3F411; Mon, 24 Jan 2005 22:27:01 -0200 (BRST) Received: from coe.ufrj.br ([146.164.53.65]) by localhost (roma.coe.ufrj.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54075-05; Mon, 24 Jan 2005 22:26:39 -0200 (BRST) Received: from [200.217.142.65] (unknown [200.217.142.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by coe.ufrj.br (Postfix) with ESMTP id 010763F410; Mon, 24 Jan 2005 22:26:36 -0200 (BRST) Message-ID: <41F59242.7090900@jonny.eng.br> Date: Mon, 24 Jan 2005 22:26:42 -0200 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Dillon References: <86pszu639o.fsf@borg.borderworlds.dk> <86brbe6052.fsf@borg.borderworlds.dk> <200501242240.j0OMeIXP043763@apollo.backplane.com> In-Reply-To: <200501242240.j0OMeIXP043763@apollo.backplane.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at coe.ufrj.br cc: ctodd@chrismiller.com cc: hackers@freebsd.org cc: Christian Laursen cc: Dominic Marks Subject: Re: Resuming from a crashdump X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2005 00:27:06 -0000 Isn't it much easier to simply reload the full memory dump (hibernation file, not dump device) into RAM and continue from that point? This should be done by /boot/loader, not by a full kernel, as the memory dump will also contain the kernel. At this point, all you have to do is to restore the hardware state, which may (or may not) be just the same as recovering from suspend state. One could flush disk cache, but this is not strictly necessary, as this cache will come back together in the wakeup. Pending interrupts are a problem, but I think they could be handled just like in the suspend state. In other words, I think of a full system hibernation as a procedure like this: 1.1) Reserve some memory to allow space for /boot/loader in the return (could be always reserved?) 1.2) Start suspend procedures, leaving only the hibernation device alive 1.3) Set a flag in the loader area to say we are shutting down 1.3) Dump all memory to the hibernation device 1.4) If the loader flag is "shutdown", power off the system 1.5) If the loader flag is "wakeup", go to suspend return procedures The restore/wakeup is like this: 2.1) /boot/loader detects the hibernation device contains valid data 2.2) Clear the shutdown flag 2.3) Instead of loading the kernel, start loading the hibernation device into memory 2.4) Now, do a "return from suspend" into 1.4) It's dumb, but it's easier this way. Now one only have to deal with hardware state. Matthew Dillon wrote: > I think this is doable but not universal. A kernel core dump can't be > used for that sort of thing (it overwrites swap and swap might contain > portions of the user processes in it). > > The kernel would have to write out a special save-to-disk file containing > the VM image, file handles, signal state, register set, and so forth for > each process in the system. Basically it would need to take DragonFly's > checkpointing code (as a basis), extend it suitably, and use it to dump > each process. > > Additional state would also have to be saved.... bound UDP sockets and > sockets in a LISTEN state would have to be saved and restored. This is > doable. > > But the following is far more difficult: > > * tty associations - restore > * tty state - restore > * job control and process group state - restore > * open pipes - restore > * open fifos - restore > * open socketpairs - restore > * established connections - throw away > > And this is very difficult: > > * X windows state, established connections to X from applications, and > so forth. However, it might be possible to quiece X out of its video > mode, remap the framebuffer, and then switch back into it. But it > would still be a nasty problem. > > - > > Also, it could take just as long to restore the mess as it would just > to reboot normally and restart your applications. After all, the system > is likely to be disk-bound either way. > > -Matt > Matthew Dillon > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Jonny -- João Carlos Mendes Luís - Networking Engineer - jonny@jonny.eng.br