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.
Cheers,
--
Ducrot Bruno
http://www.poupinou.org Page profaissionelle
http://toto.tu-me-saoules.com Haume page
> From: Ducrot Bruno [mailto:[email protected]]
> 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
On Tue, 17 Dec 2002, Grover, Andrew wrote:
> > From: Ducrot Bruno [mailto:[email protected]]
> > 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
> From: Kai Germaschewski [mailto:[email protected]]
> > 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?
Ok that's reasonable.
My belief is that S4bios is a stopgap measure until S4 gets better. That
said, I think you are right - it should go in for now, and then at some
point in the future someone will say, "S4bios?? who needs *that* anymore??"
and it will get pulled out. ;-)
So I'll look to merge it, unless someone upstream beats me to it.
Regards -- Andy
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:[email protected]]
> > > 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
> 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