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
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
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]
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
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.
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
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
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 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
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
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
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
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
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] 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
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
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 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
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.
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
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
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
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
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,
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
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
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] 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: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: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 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
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
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]
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
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
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
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
Hi, here is the Nov. progress report from ACPI project in Japan.
1. Summary of our activities in this month:
- setup CVS repository and CVSup collection for developing
environment (jp-acpi collection on cvsup.jp.FreeBSD.org).
- improve device driver (S1 and S5 state transition are
53 matches
Mail list logo
