RE: [PATCH] S4bios for 2.5.52.

RE: [PATCH] S4bios for 2.5.52.

[Grover, Andrew]

> From: Ducrot Bruno [mailto:poup-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org] 
> This patch add s4bios support for 2.5.52.
> 
> S4bios is an alternative for the ACPI S4 system suspend 
> state, but is a bit
> more easy to implement.  It suppose though that the BIOS 
> support this feature.
> For some BIOS, creating a so-called suspend partition with the help
> of lphdisk is OK.
> 
> Plus, it permit for Pavel to have a nice graphic display at 
> suspend/resume. 
> 
> echo 4 > /proc/acpi/sleep is for swsusp;
> echo 4b > /proc/acpi/sleep is for s4bios.

I still am not clear on why we would want s4bios in 2.5.x, since we have S4.
Like you said, S4bios is easier to implement, but since Pavel has done much
of the heavy lifting required for S4 proper, I don't see the need.

Regards -- Andy

RE: [PATCH] S4bios for 2.5.52.

[Grover, Andrew]

> From: Ducrot Bruno [mailto:poup@poupinou.org] 
> This patch add s4bios support for 2.5.52.
> 
> S4bios is an alternative for the ACPI S4 system suspend 
> state, but is a bit
> more easy to implement.  It suppose though that the BIOS 
> support this feature.
> For some BIOS, creating a so-called suspend partition with the help
> of lphdisk is OK.
> 
> Plus, it permit for Pavel to have a nice graphic display at 
> suspend/resume. 
> 
> echo 4 > /proc/acpi/sleep is for swsusp;
> echo 4b > /proc/acpi/sleep is for s4bios.

I still am not clear on why we would want s4bios in 2.5.x, since we have S4.
Like you said, S4bios is easier to implement, but since Pavel has done much
of the heavy lifting required for S4 proper, I don't see the need.

Regards -- Andy

RE: [PATCH] S4bios for 2.5.52.

[Kai Germaschewski]

On Tue, 17 Dec 2002, Grover, Andrew wrote:

> > From: Ducrot Bruno [mailto:poup-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org] 
> > This patch add s4bios support for 2.5.52.

> > echo 4 > /proc/acpi/sleep is for swsusp;
> > echo 4b > /proc/acpi/sleep is for s4bios.
> 
> I still am not clear on why we would want s4bios in 2.5.x, since we have S4.
> Like you said, S4bios is easier to implement, but since Pavel has done much
> of the heavy lifting required for S4 proper, I don't see the need.

Let me counter this, I have to admit that I didn't try the patch yet, but
my laptop does S4 BIOS, and I'd definitely prefer that to swsusp, since
it's much faster and also I somewhat have more faith into S4 BIOS than
swsusp (as in: after resuming, it'll most likely either work or crash, but
not cause any weird kinds of corruption). Since it does not need not much
more to support it than S3, I don't see why you wouldn't want to give
users the option?

--kai

RE: [PATCH] S4bios for 2.5.52.

[Kai Germaschewski]

On Tue, 17 Dec 2002, Grover, Andrew wrote:

> > From: Ducrot Bruno [mailto:poup@poupinou.org] 
> > This patch add s4bios support for 2.5.52.

> > echo 4 > /proc/acpi/sleep is for swsusp;
> > echo 4b > /proc/acpi/sleep is for s4bios.
> 
> I still am not clear on why we would want s4bios in 2.5.x, since we have S4.
> Like you said, S4bios is easier to implement, but since Pavel has done much
> of the heavy lifting required for S4 proper, I don't see the need.

Let me counter this, I have to admit that I didn't try the patch yet, but
my laptop does S4 BIOS, and I'd definitely prefer that to swsusp, since
it's much faster and also I somewhat have more faith into S4 BIOS than
swsusp (as in: after resuming, it'll most likely either work or crash, but
not cause any weird kinds of corruption). Since it does not need not much
more to support it than S3, I don't see why you wouldn't want to give
users the option?

--kai

Re: [PATCH] S4bios for 2.5.52.

[Ducrot Bruno]

On Tue, Dec 17, 2002 at 04:14:41PM -0600, Kai Germaschewski wrote:
> On Tue, 17 Dec 2002, Grover, Andrew wrote:
> 
> > > From: Ducrot Bruno [mailto:poup-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org] 
> > > This patch add s4bios support for 2.5.52.
> 
> > > echo 4 > /proc/acpi/sleep is for swsusp;
> > > echo 4b > /proc/acpi/sleep is for s4bios.
> > 
> > I still am not clear on why we would want s4bios in 2.5.x, since we have S4.
> > Like you said, S4bios is easier to implement, but since Pavel has done much
> > of the heavy lifting required for S4 proper, I don't see the need.
> 
> Let me counter this, I have to admit that I didn't try the patch yet, but
> my laptop does S4 BIOS, and I'd definitely prefer that to swsusp, since
> it's much faster and also I somewhat have more faith into S4 BIOS than
> swsusp (as in: after resuming, it'll most likely either work or crash, but
> not cause any weird kinds of corruption). Since it does not need not much
> more to support it than S3, I don't see why you wouldn't want to give
> users the option?
> 

In fact, I agree with Andrew.  But Pavel insist and want it,
and since it is really straightforward to have it in 2.5
because Pavel have already done all the work, why not giving
him a little gift for Christmas ?

A final word:  S4bios is way much _slower_ by nature than S4OS, especially
at suspend path, which is what we don't want if we have to go to S4 due
to an emergency.

Kai, if you see that S4OS is slower, it is probably a bug that have to be
fixed in swsusp.

Cheers,

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

Re: [PATCH] S4bios for 2.5.52.

[Ducrot Bruno]

On Tue, Dec 17, 2002 at 04:14:41PM -0600, Kai Germaschewski wrote:
> On Tue, 17 Dec 2002, Grover, Andrew wrote:
> 
> > > From: Ducrot Bruno [mailto:poup@poupinou.org] 
> > > This patch add s4bios support for 2.5.52.
> 
> > > echo 4 > /proc/acpi/sleep is for swsusp;
> > > echo 4b > /proc/acpi/sleep is for s4bios.
> > 
> > I still am not clear on why we would want s4bios in 2.5.x, since we have S4.
> > Like you said, S4bios is easier to implement, but since Pavel has done much
> > of the heavy lifting required for S4 proper, I don't see the need.
> 
> Let me counter this, I have to admit that I didn't try the patch yet, but
> my laptop does S4 BIOS, and I'd definitely prefer that to swsusp, since
> it's much faster and also I somewhat have more faith into S4 BIOS than
> swsusp (as in: after resuming, it'll most likely either work or crash, but
> not cause any weird kinds of corruption). Since it does not need not much
> more to support it than S3, I don't see why you wouldn't want to give
> users the option?
> 

In fact, I agree with Andrew.  But Pavel insist and want it,
and since it is really straightforward to have it in 2.5
because Pavel have already done all the work, why not giving
him a little gift for Christmas ?

A final word:  S4bios is way much _slower_ by nature than S4OS, especially
at suspend path, which is what we don't want if we have to go to S4 due
to an emergency.

Kai, if you see that S4OS is slower, it is probably a bug that have to be
fixed in swsusp.

Cheers,

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page

RE: [ACPI] Re: [PATCH] S4bios for 2.5.52.

[Nigel Cunningham]

> Kai, if you see that S4OS is slower, it is probably a bug
> that have to be
> fixed in swsusp.

There does seem to be a problem with the rw_swap_page_sync routine. Perhaps
not on Pavel's machine (:>), but I've experienced painfully slow suspends
too. Performance was helped immensely by applying a concept that I'll credit
Lyle Seaman for - unrolling rw_swap_page_sync and submitting all the IO for
pages then looping again and waiting on each sync. I found with writing 7000
or so pages (a suspend from init S) that something gets triggered to force
the sync about every 3900 pages anyway.

Regards,

Nigel

RE: [ACPI] Re: [PATCH] S4bios for 2.5.52.

[Nigel Cunningham]

> Kai, if you see that S4OS is slower, it is probably a bug
> that have to be
> fixed in swsusp.

There does seem to be a problem with the rw_swap_page_sync routine. Perhaps
not on Pavel's machine (:>), but I've experienced painfully slow suspends
too. Performance was helped immensely by applying a concept that I'll credit
Lyle Seaman for - unrolling rw_swap_page_sync and submitting all the IO for
pages then looping again and waiting on each sync. I found with writing 7000
or so pages (a suspend from init S) that something gets triggered to force
the sync about every 3900 pages anyway.

Regards,

Nigel