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]
[E
"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
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
>
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 inse
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, s
>
> 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?
>
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
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
[[ cc trimmed ]]
S4 state is the lowest power, longest wakeup latency state supported
by acpi. In this state all devices are powered down. The OS context
is preserved. That's how it is different from the G3 state
(shutdown/power off). It is not safe to take the computer apart when
in S4 state
> [[ cc trimmed ]]
>
> S4 state is the lowest power, longest wakeup latency state supported
> by acpi. In this state all devices are powered down. The OS context
> is preserved. That's how it is different from the G3 state
> (shutdown/power off). It is not safe to take the computer apart when
In message <[EMAIL PROTECTED]> Mike Smith writes:
: Can we guarantee that we can find this area? On eg. the Dell i7500 that
: I've been playing most with, it's a file on a FAT filesystem, and the
: BIOS will only "find" it if the filesystem is in the 'active' partition
: at boot time.
General
> 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 w
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 re
> 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 requir
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, ye
< 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 bee
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 th
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 ev
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, ev
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 driver
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
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
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
wake
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 hard
> 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
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 wou
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 sleepi
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-c
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 large
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
> > > :
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
> "serve
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
On Mon, Jun 19, 2000 at 09:34:01PM -0600, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Mike Smith writes:
> : Can we guarantee that we can find this area? On eg. the Dell i7500 that
> : I've been playing most with, it's a file on a FAT filesystem, and the
> : BIOS will only "find" it if
In message <[EMAIL PROTECTED]> Josef Karthauser writes:
: On Mon, Jun 19, 2000 at 09:34:01PM -0600, Warner Losh wrote:
: > In message <[EMAIL PROTECTED]> Mike Smith writes:
: > : Can we guarantee that we can find this area? On eg. the Dell i7500 that
: > : I've been playing most with, it's a fil
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" oper
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 s
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 wi
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
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?
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 the
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
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 [
> 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 man
> >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!
>
> > 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) ser
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
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'
> 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.
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 Dev
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
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
> 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
> >
52 matches
Mail list logo
