From owner-freebsd-hackers Tue Jun 20 1:55:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fedde.littleton.co.us (fedde.littleton.co.us [216.17.174.44]) by hub.freebsd.org (Postfix) with ESMTP id 1DAA537BD95; Tue, 20 Jun 2000 01:55:05 -0700 (PDT) (envelope-from cfedde@fedde.littleton.co.us) Received: from fedde.littleton.co.us (localhost [127.0.0.1]) by fedde.littleton.co.us (8.10.0/8.10.0) with ESMTP id e5K8t4197360; Tue, 20 Jun 2000 02:55:04 -0600 (MDT) Message-Id: <200006200855.e5K8t4197360@fedde.littleton.co.us> To: Maxim Sobolev Cc: Mike Smith , Andrew Reilly , freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: ACPI project progress report In-Reply-To: <394F1CCC.45B8A2C3@FreeBSD.org> From: Chris Fedde Date: Tue, 20 Jun 2000 02:55:04 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Jun 2000 10:27:08 +0300 Maxim Sobolev wrote: +------------------ | Mike Smith wrote: | | > The real issue here is persistent system state across the S4 suspend; ie. | > leaving applications open, etc. IMO this isn't really something worth a | > lot of effort to us, and it has a lot of additional complications for a | > "server-class" operating system in that you have to worry about network | > connections from other systems, not just _to_ other systems. | | Why then brand commercial vendors have such capability in their | "server-class" operating system for a long time? Particularly HP's PA-RISC | servers does have it, at least I remember such feature in the old 30MHz | systems which I managed several years ago (the systems was shipped with | small internal battery, which in the case of power | failure was used to dump system to the disk). | | -Maxim. +------------------ On very old systems with ferrite core memory the whole "core" simply retained whatever was running at the time of a power out. When power was restored the program just started ticking from where it left off with no loss of state. Later attempts at preserving "core" state over power out involved batteries for memory, processor registers and for peripheral buffers. As buffer sizes in controllers grew and processor memory became more volatile it became harder and harder to simply recover that way. The system always came up from bootstrap and never attempted to automatically recover to a previously running system state. These days we tend to think of a "core dump" as a diagnostic tool and not as a state image to be recovered as a part of powering up the computer. But does it have to be that way? Perhaps I am nieve but it seems to me that many "server class" systems could make great use of a hibernation mode which would allow the system to be suspended to wait for some critical event to pass and then to start running exactly as they were at the time of the suspend signal. At worst this could only minimize the recovery time experienced by the server. -- Chris Fedde 303 773 9134 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message