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
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,
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
52 matches
Mail list logo
