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
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's
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!
Our prototype development is going to finish. AML interpreter
development is almost completed, region access facility (SystemMemory,
SystemIO and
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
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
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
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
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
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 the
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 file on a
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"
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
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
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
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
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
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
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
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.
[[ 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
[[ 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
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.
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
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
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
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,
On Mon, 19 Jun 2000 10:07:26 -0700, Mike Smith [EMAIL PROTECTED] 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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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]
"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, here is the latest report on our ACPI project's progress.
Current status:
The aml interpreter development is going on and we've ported it to
kernel simultaneously. Now that we can build ACPI namespace and
search any named objects from there in kernel space.
The aml interpreter code can
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
48 matches
Mail list logo
