Re: ACPI project progress report (final?)
In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: : # I haven't checked ACPI spec 2.0 yet though :-) Wouldn't you know it. I printed the 1.0, and then the errata for it. Now I have to kill another couple of trees to print the 2.0 spec. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
> > It is related with quite wide areas, not only for power management. > > # I'm interested in power management part personally for the first step > > # though. > > Do I understand correctly that things like monitoring cooling fans etc is > also possible? I guess the people running (lots of) servers will be > interested in those features too. Yes, of course :-) ACPI covers the thermal management also. I could imagine that there are quite big needs in this area for server computing. I think this is what you are interested in, from ACPI 1.0b spec. contents; 12. THERMAL MANAGEMENT 12.1 Thermal Control 12.1.1 Active, Passive, and Critical Policies 12.1.2 Dynamically Changing Cooling Temperatures 12.1.3 Hardware Thermal Events 12.1.4 Active Cooling Strength 12.1.5 Passive Cooling Equation 12.1.6 Critical Shutdown You can get ACPI spec. documents from http://www.teleport.com/~acpi/spec.htm # I haven't checked ACPI spec 2.0 yet though :-) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
On Sat, Aug 12, 2000 at 12:35:27AM +0900, Mitsuru IWASAKI wrote: > > I'm not quite sure what it does, but it seems to work fine here on my > > ASUS CUSL2, at least the shutdown part. > > Thank you for your report. It would be helpful to check > http://www.teleport.com/~acpi/whatis1.htm > and it's links. Interesting information, thanks for the pointer. > It is related with quite wide areas, not only for power management. > # I'm interested in power management part personally for the first step > # though. Do I understand correctly that things like monitoring cooling fans etc is also possible? I guess the people running (lots of) servers will be interested in those features too. -- Wilko Bulte [EMAIL PROTECTED] Arnhem, the Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
> I'm not quite sure what it does, but it seems to work fine here on my > ASUS CUSL2, at least the shutdown part. Thank you for your report. It would be helpful to check http://www.teleport.com/~acpi/whatis1.htm and it's links. It is related with quite wide areas, not only for power management. # I'm interested in power management part personally for the first step # though. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
> In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: > : Hi, here is the latest (and maybe final?) report on our ACPI project's > : progress. > : > : We are ready now to merge our work on ACPI into main source tree! > > Bravo! Wonderful work! Thanks. I think we need to implement power management features by ACPI replacing APM at least before BIOS w/o APM become majority... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
> >Folks, there are a lot of exciting and cool things, like Processor > >and Device Power State Control, Thermal Management, Replacement > >PnP system, OS initiated hibernation and many :-) I think now is > >the time to start open and development, not only in Japan, for > >FreeBSD ACPI support! > > This all sounds very useful! Glad to see it's merging into the > current branch! Thanks! I know that we need to have a lot of developers to implement these things :-) # We are a very small team in Japan and capabilities is also limited... Now we got very fundamental facility of ACPI here, I hope that many people will have fun hacking them and be involved in the projects. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
I'm not quite sure what it does, but it seems to work fine here on my ASUS CUSL2, at least the shutdown part. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] When the stomach is satisfied, and lust is spent, man spares a little time for God. -- Will Durant To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: : Hi, here is the latest (and maybe final?) report on our ACPI project's : progress. : : We are ready now to merge our work on ACPI into main source tree! Bravo! Wonderful work! Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report (final?)
At 12:30 AM +0900 8/10/00, Mitsuru IWASAKI wrote: >Hi, here is the latest (and maybe final?) report on our ACPI >project's progress. > >We are ready now to merge our work on ACPI into main source tree! > >[...skipping...] >Folks, there are a lot of exciting and cool things, like Processor >and Device Power State Control, Thermal Management, Replacement >PnP system, OS initiated hibernation and many :-) I think now is >the time to start open and development, not only in Japan, for >FreeBSD ACPI support! This all sounds very useful! Glad to see it's merging into the current branch! --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, 20 Jun 2000, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Narvi >writes: > : You obviously haven't considered the ability to be able to near hot-swap > : motherboard and cpu - or even RAM - in this way. > > The ACPI spec specifically states that one cannot disassemble a > machine in S4 state and expect the state to be saved on reassembly. > Maybe the same sort of mechanism could be used to do this, but then > again, maybe night. > At any rate, being able to save and then restore the state would be the needed inital step in reassembly related state saves/recoveres. > Warner > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, Jun 20, 2000 at 08:14:41PM +0200, Narvi wrote: > > You obviously haven't considered the ability to be able to near hot-swap > motherboard and cpu - or even RAM - in this way. > You're right! I hadn't! (Although I've dreamed about it a few times). Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes: : BTW, have you decided between NetBSD and BSD/OS cardbus code yet? No. There is no BSD/OS cardbus card that I could find in the tree. If I'm being insanely blind, please someone tell me. The short term plan is to get NEWCARD working and then look at wildboar to see if it could be useful. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: > : Hi, here is the latest report on our ACPI project's progress. > > As I told you on the Train in Tokyo: Cool! Way Cool! ACPI should > enable us to properly put the chipsets in laptops to sleep and then > wake them up again. Right now pccard insert/removal can be missed > when you put a laptop to sleep... BTW, have you decided between NetBSD and BSD/OS cardbus code yet? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Windows works, for sufficently small values of "works". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, Jun 20, 2000 at 12:47:38PM -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Bjoern Fischer writes: > : Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), > : turning power off, maybe adding some hardware or moving the machine > : to another location, then switching on again, restoring the system context, > : and the machine will proceed as if nothing had happened, do you? > > The S4 sleep state of ACPI doesn't support changing the hardware > configuration while you are in that state. That would probably explain why W'98 gets confused when you _do_ change the hardware configuration while in suspend state. Pretty silly state to get into, then, if hardware like floppy drives are easy to add or remove, and the box looks as though it's off... Any good theories about how to avoid this problem? Avoid S4 and go all the way to shutdown, with a flag set on the boot disk? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]> Narvi writes: : You obviously haven't considered the ability to be able to near hot-swap : motherboard and cpu - or even RAM - in this way. The ACPI spec specifically states that one cannot disassemble a machine in S4 state and expect the state to be saved on reassembly. Maybe the same sort of mechanism could be used to do this, but then again, maybe night. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]> Mike Smith writes: : 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. They why bother supporting laptops at all? FreeBSD is now more than just a server OS. And the network connection issue is a non issue. If the connections are present when we go to sleep, either the connection will time out or it won't. It is no different than yanking out the ethernet cable. Those that time out will get a connection reset when the application comes back when the system wakes from the S4 state. Those that don't won't care since they will just continue working. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]> Bjoern Fischer writes: : Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), : turning power off, maybe adding some hardware or moving the machine : to another location, then switching on again, restoring the system context, : and the machine will proceed as if nothing had happened, do you? The S4 sleep state of ACPI doesn't support changing the hardware configuration while you are in that state. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]> "Daniel C. Sobral" writes: : Mitsuru IWASAKI wrote: : > : > - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep : >require some hack in boot loader needs help. : : I thought hibernation was entirely controlled by kernel? What do you : need? You have to use the BIOS to put the machine into the state, but when the machine comes out of that state, it goes through the reset vector, at least for S4 (I think S2 and S3 as well, I don't have my copy of the standard handy). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, 20 Jun 2000, Josef Karthauser wrote: > On Mon, Jun 19, 2000 at 05:40:30PM -0700, 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. > > > > That said TCP/IP is very resilient :). I tried suspending to disk > my laptop, unplugging the batteries and ether card, taking it to another > part of the building and the firing it up. > > Pccardd saw the ethernet card, Dhclient saw the dhcp server and got > my ip address back, and my pre-existing remote terminal sessions > continued functioning :) Excellent. > > IMO if the machine is a server and you want to suspend it, who cares > about the clients at the other end? If you did you wouldn't suspend > it in the first place :) > You obviously haven't considered the ability to be able to near hot-swap motherboard and cpu - or even RAM - in this way. > Joe > > [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:40:30PM -0700, 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. > That said TCP/IP is very resilient :). I tried suspending to disk my laptop, unplugging the batteries and ether card, taking it to another part of the building and the firing it up. Pccardd saw the ethernet card, Dhclient saw the dhcp server and got my ip address back, and my pre-existing remote terminal sessions continued functioning :) Excellent. IMO if the machine is a server and you want to suspend it, who cares about the clients at the other end? If you did you wouldn't suspend it in the first place :) Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Mike Smith wrote: > > On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote: > > > In message <[EMAIL PROTECTED]> "Andrew Reilly" writes: > > > : That sounds way too hard. Why not restrict suspend activity to > > > : user-level processes and bring the kernel/drivers back up through > > > : a regular boot process? At least that way the hardware and drivers > > > : will know what they are all up to, even if some of it has changed > > > : in the mean time. > > > > > > Takes too long... That's shutdown, not S4. > > > > Yes. But what is the difference, really? As far as the > > hardware is concerned, it's being booted. If that process can > > be sped up by using the "S4" mechanisms, why can't they be > > applied to a regular boot process too? [I'm thinking about a > > kernel equivelant of the "clean shutdown" flag on file systems.] > > > > Fundamentally, is there no way to get the kernel and drivers to > > go through a full boot phase in a small fraction of the time > > that it takes to repopulate 64M of RAM from disk? (*) > > 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Process migration (was RE: ACPI project progress report)
> On Mon, Jun 19, 2000 at 05:40:30PM -0700, 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. I was thinking about this a little more this afternoon, and it occurred to me that the system state management services that one would like for smooth "suspend" operation on laptops are very nearly the same as the process checkpointing services that one requires for process migration in a cluster environment. That sounds like a "server-class" application for this stuff. I know of at least one research project involving process migration in a cluster (at U Sydney, I think) using FreeBSD. Hey: wouldn't it be cool if, when you manually suspended your laptop, the processes waiting for user input would be suspended to disk, but the CPU-bound one running a simulation would migrate to your main compute server. It might even be finished the next time you logged in... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, 19 Jun 2000, Brooks Davis wrote: :On Tue, Jun 20, 2000 at 10:49:24AM +1000, Andrew Reilly wrote: : :> Processes do still wind up in "sleep" state, completely paged :> out, don't they? : :Observationaly, no. Unless I actually manage to run my system low on :RAM, none of my swap is used even with ~5MB Eterm processes sitting :unused for days. I suppose if I let memory get tight, they might get :ditched in favor of disk cache, but I haven't seen that happen. Someone :with a better grasp of the VM could give a more preciese answer. I find lots my xterms getting swapped out on my office desktop. It's only (!) got 128MB of RAM, and I routinely have two or three dozen xterms running locally, plus a like number from remote machines, plus an instance of the X server and Netscape. It only takes a couple seconds to swap in one of the xterms when I start to use it again, and I often don't notice, because I have to move my hand from the mouse back to hte keyboard. I'm probably not a typical user, of course. David scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, Jun 20, 2000 at 10:49:24AM +1000, Andrew Reilly wrote: > The issue isn't with the size of the disk storage required, but > with the mechanism. Why dedicate 256M to a suspend partition, and > invent a new process saving mechanism, instead of making your > existing swap partition 256M larger and using the existing swap > pager? Because our swapper doesn't work that way. Generally speaking, swappers don't work that way anymore. Systems that suspend to disk are a corner case for FreeBSD. > Processes do still wind up in "sleep" state, completely paged > out, don't they? Observationaly, no. Unless I actually manage to run my system low on RAM, none of my swap is used even with ~5MB Eterm processes sitting unused for days. I suppose if I let memory get tight, they might get ditched in favor of disk cache, but I haven't seen that happen. Someone with a better grasp of the VM could give a more preciese answer. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:40:30PM -0700, 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. Don't the normal TCP timeouts take care of existing connections? I doubt that a "server class" system will be going into suspend mode for any reason, but I would imagine that suspend/resume should look much like network outage for the clients of suspended servers. For the only place that I can see it mattering (laptops), I suspect that suspend/resume should be an X session manager and application level job, and the kernel should just shutdown and boot as normal. I know that there aren't too many X applications that do all of the session management things, but maybe that would change if suspend actions interacted with the popular desktops in the appropriate way. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:30:55PM -0700, Brooks Davis wrote: > On Tue, Jun 20, 2000 at 10:16:08AM +1000, Andrew Reilly wrote: > > (*) Speaking of which: why are we considering doing process > > dumps into a _different_ swap-ish partition, instead of just > > ensuring that all processes are sleeping in the normal swap > > partition? If that was done, then they would just page > > themselves back in as needed, on wake-up. > > Because swap doesn't work that way anymore. They days where every page of > memory had to be backed by disk are long gone. This means that there may > not be anywere to put processes which are in memory unless you allocate > somewhere to save all (or practicaly all) of memory. But to do the proposed state save to disk, there _must_ be enough disk space to back all of the process pages. > In any case, I > haven't seen many laptops capable of using more then 256MB of RAM which > isn't exactly much of a modern disk. My laptop has 256MB of RAM and > ships with up to a 10GB disk. I've retrofitted it with a non-standard > 18GB disk because 10GB looked too small for my needs. Even with the 6.4GB > disk it shipped with, the suspend to disk partition is only 4% of my disk. The issue isn't with the size of the disk storage required, but with the mechanism. Why dedicate 256M to a suspend partition, and invent a new process saving mechanism, instead of making your existing swap partition 256M larger and using the existing swap pager? Processes do still wind up in "sleep" state, completely paged out, don't they? -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Tue, Jun 20, 2000 at 10:16:08AM +1000, Andrew Reilly wrote: > > (*) Speaking of which: why are we considering doing process > dumps into a _different_ swap-ish partition, instead of just > ensuring that all processes are sleeping in the normal swap > partition? If that was done, then they would just page > themselves back in as needed, on wake-up. Because swap doesn't work that way anymore. They days where every page of memory had to be backed by disk are long gone. This means that there may not be anywere to put processes which are in memory unless you allocate somewhere to save all (or practicaly all) of memory. In any case, I haven't seen many laptops capable of using more then 256MB of RAM which isn't exactly much of a modern disk. My laptop has 256MB of RAM and ships with up to a 10GB disk. I've retrofitted it with a non-standard 18GB disk because 10GB looked too small for my needs. Even with the 6.4GB disk it shipped with, the suspend to disk partition is only 4% of my disk. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
> On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote: > > In message <[EMAIL PROTECTED]> "Andrew Reilly" writes: > > : That sounds way too hard. Why not restrict suspend activity to > > : user-level processes and bring the kernel/drivers back up through > > : a regular boot process? At least that way the hardware and drivers > > : will know what they are all up to, even if some of it has changed > > : in the mean time. > > > > Takes too long... That's shutdown, not S4. > > Yes. But what is the difference, really? As far as the > hardware is concerned, it's being booted. If that process can > be sped up by using the "S4" mechanisms, why can't they be > applied to a regular boot process too? [I'm thinking about a > kernel equivelant of the "clean shutdown" flag on file systems.] > > Fundamentally, is there no way to get the kernel and drivers to > go through a full boot phase in a small fraction of the time > that it takes to repopulate 64M of RAM from disk? (*) 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. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Andrew Reilly wrote: > > On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote: > > In message <[EMAIL PROTECTED]> "Andrew Reilly" writes: > > : That sounds way too hard. Why not restrict suspend activity to > > : user-level processes and bring the kernel/drivers back up through > > : a regular boot process? At least that way the hardware and drivers > > : will know what they are all up to, even if some of it has changed > > : in the mean time. > > > > Takes too long... That's shutdown, not S4. > > Yes. But what is the difference, really? As far as the > hardware is concerned, it's being booted. If that process can > be sped up by using the "S4" mechanisms, why can't they be > applied to a regular boot process too? [I'm thinking about a > kernel equivelant of the "clean shutdown" flag on file systems.] If you resume a W2k system from hibernation it will basically boot but with restoring from swap what was running before. > Fundamentally, is there no way to get the kernel and drivers to > go through a full boot phase in a small fraction of the time > that it takes to repopulate 64M of RAM from disk? (*) > > I'm concerned about trying to take short-cuts with booting, > because I've seen both the Toshiba laptop that I'm using now, > and my mother's HP desktop system hang horribly hard when they > should have been coming out of suspend. (Both W'98.) > > I like the idea that my laptop will save power by shutting down > after a while, but I don't want to get into trouble if I forget > whether I was docked or not, or whether the floppy was plugged > in or not, when next I turn it on. > > (*) Speaking of which: why are we considering doing process > dumps into a _different_ swap-ish partition, instead of just > ensuring that all processes are sleeping in the normal swap > partition? If that was done, then they would just page > themselves back in as needed, on wake-up. Yes, W2k pages everything out on hibernate and swaps it in back again when you start using an application that was running before. It's pretty evident once you've used W2k on a Laptop, you can really feel it. > Sorry for blathering. This is just really interesting stuff. It is! :) -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 05:01:46PM -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> "Andrew Reilly" writes: > : That sounds way too hard. Why not restrict suspend activity to > : user-level processes and bring the kernel/drivers back up through > : a regular boot process? At least that way the hardware and drivers > : will know what they are all up to, even if some of it has changed > : in the mean time. > > Takes too long... That's shutdown, not S4. Yes. But what is the difference, really? As far as the hardware is concerned, it's being booted. If that process can be sped up by using the "S4" mechanisms, why can't they be applied to a regular boot process too? [I'm thinking about a kernel equivelant of the "clean shutdown" flag on file systems.] Fundamentally, is there no way to get the kernel and drivers to go through a full boot phase in a small fraction of the time that it takes to repopulate 64M of RAM from disk? (*) I'm concerned about trying to take short-cuts with booting, because I've seen both the Toshiba laptop that I'm using now, and my mother's HP desktop system hang horribly hard when they should have been coming out of suspend. (Both W'98.) I like the idea that my laptop will save power by shutting down after a while, but I don't want to get into trouble if I forget whether I was docked or not, or whether the floppy was plugged in or not, when next I turn it on. (*) Speaking of which: why are we considering doing process dumps into a _different_ swap-ish partition, instead of just ensuring that all processes are sleeping in the normal swap partition? If that was done, then they would just page themselves back in as needed, on wake-up. Sorry for blathering. This is just really interesting stuff. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: > : Maybe I'm wrong because of lack of my understanding on crush dump and > : loader. Please help us :-) > > I think that you might be able to do this. The real tricky part maybe > saving hardware RAM that the drivers expect to be there when you > wakeup. I thinking of video ram and the X server's font cache, to > name one example. It would be the driver's responsibility to save what it can on SLEEP, and rebuild what it couldn't on WAKE. If the driver is simply incapable for some reason, either always or at specific times, it should fail on SLEEP, effectively disabling hybernation on any setup with it (shoganai). -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]> "Andrew Reilly" writes: : That sounds way too hard. Why not restrict suspend activity to : user-level processes and bring the kernel/drivers back up through : a regular boot process? At least that way the hardware and drivers : will know what they are all up to, even if some of it has changed : in the mean time. Takes too long... That's shutdown, not S4. : > Obviously the video driver will need to send a signal or clue to the : > Xserver saying "you own the device, you'd better do something" : : Yeah. The X server has far too much "driver" level code in it : already, so probably needs to be tweaked to re-initialise itself : properly. Yes. Likely. But if we're going to support sleep modes, we'll need to do this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Mon, Jun 19, 2000 at 06:36:14PM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Warner Losh writes: > >In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: > >: Maybe I'm wrong because of lack of my understanding on crush dump and > >: loader. Please help us :-) > > > >I think that you might be able to do this. The real tricky part maybe > >saving hardware RAM that the drivers expect to be there when you > >wakeup. I thinking of video ram and the X server's font cache, to > >name one example. > > Drivers will need a "your hardware may have been zonked" entrypoint, > think about the i8254 counter or all the weird versions of write > only or "write here - read there" I/O registers in existence. That sounds way too hard. Why not restrict suspend activity to user-level processes and bring the kernel/drivers back up through a regular boot process? At least that way the hardware and drivers will know what they are all up to, even if some of it has changed in the mean time. > Obviously the video driver will need to send a signal or clue to the > Xserver saying "you own the device, you'd better do something" Yeah. The X server has far too much "driver" level code in it already, so probably needs to be tweaked to re-initialise itself properly. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Bjoern Fischer wrote: > > Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), > turning power off, maybe adding some hardware or moving the machine > to another location, then switching on again, restoring the system context, > and the machine will proceed as if nothing had happened, do you? That's what hybernation does under Windows. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
< said: > Hmm, this has me thinking again about suspend/resume. In the current > context, can we expect a suspend veto from some function to actually > DTRT? (ie. drivers that have been suspended get a resume call). That's how I originally implemented it, but I'm not sure whether that has been maintained or not. > Or should we make two passes over the suspend method? One with " > intention to suspend at this level", the second to actually perform the > suspension once the first has been accepted? I think this is a good idea, and better than my implementation. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]> Mike Smith writes: : Hmm, this has me thinking again about suspend/resume. In the current : context, can we expect a suspend veto from some function to actually : DTRT? (ie. drivers that have been suspended get a resume call). If the BIOS allows us to do that, yes. I'm fairly sure that doug did the right thing here. The only issue that I ever ran into was that the APM bios shut the machine down anyway, even when we tried to tell it not to. Funny thing about batteries, or something like that:-) : Or should we make two passes over the suspend method? One with " : intention to suspend at this level", the second to actually perform the : suspension once the first has been accepted? No comment. : This will allow non-ACPI-represented drivers to participate in : determining which suspend level(s) can actually be supported by the : hardware... That's true. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
> S4 requires the OS to reinitialise peripherals. Some comments I've seen > from the Linux folks suggest that we'll have to save and restore the PCI > configuration space as well. > > Basically, resume from S4 is not something that is going to be very easy > for us to implement. It'll require every S4-OK driver to re-initialise > in the resume method. (Note that we will also need to add suspend-to and > resume-from arguments to the relevant driver methods.) Hmm, this has me thinking again about suspend/resume. In the current context, can we expect a suspend veto from some function to actually DTRT? (ie. drivers that have been suspended get a resume call). Or should we make two passes over the suspend method? One with " intention to suspend at this level", the second to actually perform the suspension once the first has been accepted? This will allow non-ACPI-represented drivers to participate in determining which suspend level(s) can actually be supported by the hardware... -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
> In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: > : Maybe I'm wrong because of lack of my understanding on crush dump and > : loader. Please help us :-) > > I think that you might be able to do this. The real tricky part maybe > saving hardware RAM that the drivers expect to be there when you > wakeup. I thinking of video ram and the X server's font cache, to > name one example. S4 requires the OS to reinitialise peripherals. Some comments I've seen from the Linux folks suggest that we'll have to save and restore the PCI configuration space as well. Basically, resume from S4 is not something that is going to be very easy for us to implement. It'll require every S4-OK driver to re-initialise in the resume method. (Note that we will also need to add suspend-to and resume-from arguments to the relevant driver methods.) We also have a problem in that we'll need a separate suspend file for system memory, since we can't just up and use swap (which may already be busy). I would be inclined to start with some of the easier states first. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]>, Warner Losh writes: >In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: >: Maybe I'm wrong because of lack of my understanding on crush dump and >: loader. Please help us :-) > >I think that you might be able to do this. The real tricky part maybe >saving hardware RAM that the drivers expect to be there when you >wakeup. I thinking of video ram and the X server's font cache, to >name one example. Drivers will need a "your hardware may have been zonked" entrypoint, think about the i8254 counter or all the weird versions of write only or "write here - read there" I/O registers in existence. Obviously the video driver will need to send a signal or clue to the Xserver saying "you own the device, you'd better do something" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: : Maybe I'm wrong because of lack of my understanding on crush dump and : loader. Please help us :-) I think that you might be able to do this. The real tricky part maybe saving hardware RAM that the drivers expect to be there when you wakeup. I thinking of video ram and the X server's font cache, to name one example. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
imp> In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: imp> : Hi, here is the latest report on our ACPI project's progress. imp> imp> As I told you on the Train in Tokyo: Cool! Way Cool! ACPI should imp> enable us to properly put the chipsets in laptops to sleep and then imp> wake them up again. Right now pccard insert/removal can be missed imp> when you put a laptop to sleep... Yes, many of today's laptop BIOS are expecting that OS shouldn handle this kind of things by executing the AML. Good news, recently I wrote accessing ioport stuff (roughly :-) and experimental code for executing _PTS & _WAK method in kernel space. On P2B based system, it seems working fine :-) Next step is implement accessing other bus spaces, physical memory will be the target (and PCI config, SMBus...). Can anybody help us on this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Hi, From: Bjoern Fischer <[EMAIL PROTECTED]> Subject: Re: ACPI project progress report Date: Mon, 19 Jun 2000 07:01:44 +0200 Message-ID: <[EMAIL PROTECTED]> > Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), > turning power off, maybe adding some hardware or moving the machine > to another location, then switching on again, restoring the system context, > and the machine will proceed as if nothing had happened, do you? Yes, exactly. My rough idea is like this; - do preparation for sleeping state transition for each devices and _PTS (prepare to sleep) control method. - stop all of processes, other sub-system (eg filesystem, memory...) and write contents of memory to dedicated swap partition for "Save-to-Disk" and save system context. - turning power off by manipulating ACPI registers (or just halt the system and user will turning power off). - upon turning power on, BIOS built ACPI tables again if hardware configuration changed during sleeping. Any important device (eg disk controller) configuration changes will cause the restoring system context to fail. - after POST, BIOS passes control to the boot loader in normal case. - load will check whether S4 transition occurred, then restore system context and memory from swap partition. - do _WAK (wakeup) control method, wakeup processes for each devices and re-enable them. Maybe I'm wrong because of lack of my understanding on crush dump and loader. Please help us :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: ACPI project progress report
> > Just a moment. You talk about doing a `Save-to-Disk' (incl. > system halt), turning power off, maybe adding some hardware or > moving the machine to another location, then switching on again, > restoring the system context, and the machine will proceed as if > nothing had happened, do you? > I think FreeBSD supports something similar already. It's a little outdated by modern computing standards, but it used to be called a "halt" or a "reboot". Advantage of those outdated concepts used to be that you could replace your /kernel, adding for example a new driver for the new hardware, or after a cvsup. Just curious, but are you planning to add such functionality to S4? :) Kees Jan == Everyone is responsible for his own actions, and (people tend to forget this) the effect they have on others. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
On Sat, Jun 17, 2000 at 01:56:11PM +0900, Mitsuru IWASAKI wrote: > I think OS-initiated S4 (hibernation) in FreeBSD has enough advantages > because we can do `Save-to-Disk' anywhere even on non-laptop machines > which BIOS doesn't support hibernation. > FreeBSD supports crash dump facility here, so I'm expecting that > `Save-to-Disk' by kernel would not be so difficult. We might need > dedicated swap partition for OS-initiated S4 because used swap areas > need to be protected for the system oprerations after awakening. > The boot loader is the best place for restoring the system context in > FreeBSD I think. Just a moment. You talk about doing a `Save-to-Disk' (incl. system halt), turning power off, maybe adding some hardware or moving the machine to another location, then switching on again, restoring the system context, and the machine will proceed as if nothing had happened, do you? Björn -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L---(++) !E W- N+ o>+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: : Hi, here is the latest report on our ACPI project's progress. As I told you on the Train in Tokyo: Cool! Way Cool! ACPI should enable us to properly put the chipsets in laptops to sleep and then wake them up again. Right now pccard insert/removal can be missed when you put a laptop to sleep... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Hi, > "Daniel C. Sobral" wrote: > > > > Mitsuru IWASAKI wrote: > > > > > > - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep > > >require some hack in boot loader needs help. > > > > I thought hibernation was entirely controlled by kernel? What do you >^^ > Err, BIOS. > > > need? Yes, we need to consider both. In ACPI spec. 1.0b 9.1.4 S4 Sleeping State, this is described that S4 supports two entry mechanisms: OS initiated and BIOS initiated. From: Intel, Microsoft, Toshiba Subject: Advanced Configuration and Power Interface Specification 1.0b Date: Tue, 2 Feb 1999 07:55:24 +0900 > In the OS-initiated S4 sleeping state, the OS is responsible for > saving all system context. Before entering the S4 state, the OS will > save context of all memory. Upon awakening, the OS will then restore > the system context. When the OS re-enumerates buses coming out of the > S4 sleeping state, it will discover any devices that have come and > gone, and configure devices as they are turned on. I think OS-initiated S4 (hibernation) in FreeBSD has enough advantages because we can do `Save-to-Disk' anywhere even on non-laptop machines which BIOS doesn't support hibernation. FreeBSD supports crash dump facility here, so I'm expecting that `Save-to-Disk' by kernel would not be so difficult. We might need dedicated swap partition for OS-initiated S4 because used swap areas need to be protected for the system oprerations after awakening. The boot loader is the best place for restoring the system context in FreeBSD I think. Unfortunately I don't have enough knowledge on crash dump and boot loader to implement OS-initiated S4 transition (actually, this is not related with ACPI at all). I love to see someone say `hey! I'll take this one!' :-) Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
"Daniel C. Sobral" wrote: > > Mitsuru IWASAKI wrote: > > > > - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep > >require some hack in boot loader needs help. > > I thought hibernation was entirely controlled by kernel? What do you ^^ Err, BIOS. > need? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report
Mitsuru IWASAKI wrote: > > - support S2, S3, S4 (hibernation) sleeping transition. S4 sleep >require some hack in boot loader needs help. I thought hibernation was entirely controlled by kernel? What do you need? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report - Nov.
Hi, Doug Rabson wrote: > > Please see > > http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/util/acpiconf?cvsroot=freebsd-jp > > This sounds very promising. I will check out the code soon and try to give > feedback. Creating the ACPI namespace is a necessary first step before its > possible to do full AML interpreting. Thanks! I'm now preparing also own memory management subsystem to avoid memory leakage in kernel space and to utilize VM efficiently. I believe it should be also one of the important things. > > In the beginning of this project, we thought merging them to > > 4.0-RELEASE would be very much exciting, but it seems the codes are > > still young to merge and 4.0-RELEASE feature freeze is comming soon. > > We will try another chance, hopefully we have AML interpreter in > > kernel space at that time. > > I think we should aim to do most of the work in 5.0 after we branch off > 4.0. Perhaps some of it can be back-ported after it become stable in 5.0. OK, we'll do best we can do aiming merge into 5.0-CURRENT. Warner Losh wrote: > Cool. This is indeed good news. Keep up the good reports. > > iwasaki-san to acpi-jp wa domo arigato gozaimasu. We will! We shall keep the reports periodically (maybe monthly? of course depending on our progress). I think that we, folks in Japan, learned enough communications won't hurt anything. # Dou itasimasite :-) Doug Rabson and Warner Losh, thanks for your valuable advice and words of encouragement. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report - Nov.
In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes: : Hi, here is the Nov. progress report from ACPI project in Japan. Cool. This is indeed good news. Keep up the good reports. iwasaki-san to acpi-jp wa domo arigato gozaimasu. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI project progress report - Nov.
On Tue, 30 Nov 1999, Mitsuru IWASAKI wrote: > 5. AML interpreter implementation > We've just started based on Doug Rabson's acpitest program, but > parsing AML and managing objects in the name space are almost > finished. We're going to make configuration utility first with AML > interpreter in the userland, then move it to kernel space after brush > it out. > Please see > http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/util/acpiconf?cvsroot=freebsd-jp This sounds very promising. I will check out the code soon and try to give feedback. Creating the ACPI namespace is a necessary first step before its possible to do full AML interpreting. > > > In the beginning of this project, we thought merging them to > 4.0-RELEASE would be very much exciting, but it seems the codes are > still young to merge and 4.0-RELEASE feature freeze is comming soon. > We will try another chance, hopefully we have AML interpreter in > kernel space at that time. I think we should aim to do most of the work in 5.0 after we branch off 4.0. Perhaps some of it can be back-ported after it become stable in 5.0. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
