From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 25 01:37:34 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 E09F516A4CE for ; Tue, 25 Jan 2005 01:37:34 +0000 (GMT) Received: from node15.coopprint.com (node15.cooperativeprinting.com [208.4.77.15]) by mx1.FreeBSD.org (Postfix) with SMTP id 3712F43D54 for ; Tue, 25 Jan 2005 01:37:34 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 98126 invoked by uid 0); 25 Jan 2005 01:35:24 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.157.250) by node15.coopprint.com with SMTP; 25 Jan 2005 01:35:24 -0000 Message-ID: <41F5A2DE.5000306@gamersimpact.com> Date: Mon, 24 Jan 2005 19:37:34 -0600 From: Ryan Sommers User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= References: <86pszu639o.fsf@borg.borderworlds.dk> <86brbe6052.fsf@borg.borderworlds.dk> <200501242240.j0OMeIXP043763@apollo.backplane.com> <41F59242.7090900@jonny.eng.br> In-Reply-To: <41F59242.7090900@jonny.eng.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: hackers@freebsd.org 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 01:37:35 -0000 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. 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. 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. -- Ryan Sommers ryans@gamersimpact.com