From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 25 02:21:15 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 AECAC16A4CE for ; Tue, 25 Jan 2005 02:21:15 +0000 (GMT) Received: from coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B2FD43D53 for ; Tue, 25 Jan 2005 02:21:15 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from localhost (localhost [127.0.0.1]) by coe.ufrj.br (Postfix) with ESMTP id 21D493F413 for ; Tue, 25 Jan 2005 00:21:14 -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 61198-06 for ; Tue, 25 Jan 2005 00:20:56 -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 6DDB23F410 for ; Tue, 25 Jan 2005 00:20:55 -0200 (BRST) Message-ID: <41F5AD11.9090508@jonny.eng.br> Date: Tue, 25 Jan 2005 00:21:05 -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: hackers@freebsd.org References: <86pszu639o.fsf@borg.borderworlds.dk> <86brbe6052.fsf@borg.borderworlds.dk> <200501242240.j0OMeIXP043763@apollo.backplane.com> <41F59242.7090900@jonny.eng.br> <41F5A2DE.5000306@gamersimpact.com> In-Reply-To: <41F5A2DE.5000306@gamersimpact.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at coe.ufrj.br Subject: FreeBSD disk hibernation - Was: 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 02:21:15 -0000 Ryan Sommers wrote: > João Carlos Mendes Luís wrote: > >> 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. > > > Restoring the hardware state requires restoring the state inside each > and every hardware device. For certain devices this is trivial. However, > I believe for devices with much more complex internal state machines > this is way beyond the scope of the loader. This is not to be done by the loader. Loader will only load the file into memory. It's this "running image" that will restore hardware state. > Now, that isn't to say the loader couldn't start executing the kernel > somewhere other than "the beginning" and instead at a point where the > kernel would specifically know it was awoken from hibernation and > cleanup/reinitialize any devices. Almost this. Just note that we are not dealing with a kernel anymore. If we have, someday, a swapable kernel, parts of it may be in the swap, and not in core. > My little knowledge on this subject aside. I'd love to have full > suspend/resume functionality. It'd make my life as a mobile freebsd user > much much easier. However, I wouldn't want it at the expense of every > kernel. It would need to be something completely modular. It will require every driver used to be able to restore hardware state, and this may impact every kernel a bit. Other than this, it should be modular. BTW: This is not useful only for laptops. Some desktops could benefit from this also. I like to hibernate windows XP desktops just to continue processing from the same point on the next day, and do not waste energy doing this. Maybe even some servers (mostly processing servers, not network servers) could use this capability to survive energy blackouts, hibernating when the UPS goes on battery for some time. I've thought on this before windows XP come with an implementation, but I don't have enough knowledge to even start the hardware device state setup. :-( Jonny -- João Carlos Mendes Luís - Networking Engineer - jonny@jonny.eng.br