Date: Tue, 25 Jan 2005 00:25:58 -0200 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= <jonny@jonny.eng.br> To: Bruce M Simpson <bms@spc.org> Cc: hackers@freebsd.org Subject: Re: FreeBSD disk hibernation - Was: Resuming from a crashdump Message-ID: <41F5AE36.4090107@jonny.eng.br> In-Reply-To: <20050125014935.GD47638@dhcp120.icir.org> References: <86pszu639o.fsf@borg.borderworlds.dk> <86brbe6052.fsf@borg.borderworlds.dk> <Pine.BSI.4.58L.0501241423530.27294@vp4.netgate.net> <200501242240.j0OMeIXP043763@apollo.backplane.com> <41F59242.7090900@jonny.eng.br> <41F5A2DE.5000306@gamersimpact.com> <20050125014935.GD47638@dhcp120.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce M Simpson wrote:
> On Mon, Jan 24, 2005 at 07:37:34PM -0600, Ryan Sommers wrote:
>
>>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.
>
>
> I think what we're also looking at is aborting any pending bus-mastering
> transactions. This could probably be done as a part of the newbus
> suspend/resume routines for bus and device drivers, but it also means
> that the other entry points need to be able to deal with the carpet
> being dragged out from under them like this.
As I said, the first step should be to enter a pre-suspend state,
where only hard disk devices should be kept alive. All other devices
should be sleeping then, and so there will be no pending requests.
> In the case of a networking driver, particularly Ethernet, things are
> somewhat easier, and the more help you get from the hardware the better;
> but some cards like those based around ATM SARS just plain aren't designed
> to deal with the carpet being dragged out - they expect to keep rolling
> through their descriptor rings, segmenting and transmitting what they see.
The carpet will not be dragged out. The card wil be specifically
shut down before this. ;-)
Of course, a techo-nerd-maniac could devise some form of network
hibernating, or a NFS based hibernate file. Just like crash dump, I
don't think this is possible or even necessary.
> If we could take a clean subsystem-by-subsystem approach to marshaling
> kernel state to disk, that would be good. What gives me particular pain
> here is dealing with things like the filesystem. How does one deal with
> open files, etc, with pending I/O?
There's no need to deal with it! Just save the whole kernel core!
Jonny
--
João Carlos Mendes Luís - Networking Engineer - jonny@jonny.eng.br
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41F5AE36.4090107>