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) ser
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.
> 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!
>
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
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
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 PC
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
> machi
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]> "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
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
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]> 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 reass
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
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
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?
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
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 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
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
> >
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
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
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 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 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: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
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
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
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
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
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
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
< 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
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
> 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]> 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
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
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
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
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
>
> 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?
>
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
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
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
>
"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
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
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 b
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 fu
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 "u
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 i
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 supportted
55 matches
Mail list logo
