From: Stefan Seyfried <[email protected]>
Add an ioctl to the userspace swsusp code that enables the usage of the
pmops->prepare, pmops->enter and pmops->finish methods (the in-kernel
suspend knows these as "platform method"). These are needed on many machines
to (among others) speed up resuming by letting the BIOS skip some steps or
let my hp nx5000 recognise the correct ac_adapter state after resume again.
Signed-off-by: Stefan Seyfried <[email protected]>
---
Patch is against 2.6.18. AFAIK little has changed in this area recently, so
it should still apply. I have two machines that are pretty broken without it,
so it is rather urgent for me :-)
Please apply.
diff -rup a/kernel/power/power.h b/kernel/power/power.h
--- a/kernel/power/power.h 2006-09-20 05:42:06.000000000 +0200
+++ b/kernel/power/power.h 2006-09-25 08:42:46.000000000 +0200
@@ -78,7 +78,12 @@ int snapshot_image_loaded(struct snapsho
#define SNAPSHOT_FREE_SWAP_PAGES _IO(SNAPSHOT_IOC_MAGIC, 9)
#define SNAPSHOT_SET_SWAP_FILE _IOW(SNAPSHOT_IOC_MAGIC, 10, unsigned int)
#define SNAPSHOT_S2RAM _IO(SNAPSHOT_IOC_MAGIC, 11)
-#define SNAPSHOT_IOC_MAXNR 11
+#define SNAPSHOT_PMOPS _IOW(SNAPSHOT_IOC_MAGIC, 12, unsigned int)
+#define SNAPSHOT_IOC_MAXNR 12
+
+#define PMOPS_PREPARE 1
+#define PMOPS_ENTER 2
+#define PMOPS_FINISH 3
/**
* The bitmap is used for tracing allocated swap pages
diff -rup a/kernel/power/user.c b/kernel/power/user.c
--- a/kernel/power/user.c 2006-09-20 05:42:06.000000000 +0200
+++ b/kernel/power/user.c 2006-09-12 18:45:34.000000000 +0200
@@ -11,6 +11,7 @@
#include <linux/suspend.h>
#include <linux/syscalls.h>
+#include <linux/reboot.h>
#include <linux/string.h>
#include <linux/device.h>
#include <linux/miscdevice.h>
@@ -302,6 +303,33 @@ OutS3:
up(&pm_sem);
break;
+ case SNAPSHOT_PMOPS:
+ switch (arg) {
+
+ case PMOPS_PREPARE:
+ if (pm_ops->prepare) {
+ error = pm_ops->prepare(PM_SUSPEND_DISK);
+ }
+ break;
+
+ case PMOPS_ENTER:
+ kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
+ error = pm_ops->enter(PM_SUSPEND_DISK);
+ break;
+
+ case PMOPS_FINISH:
+ if (pm_ops && pm_ops->finish) {
+ pm_ops->finish(PM_SUSPEND_DISK);
+ }
+ break;
+
+ default:
+ printk(KERN_ERR "SNAPSHOT_PMOPS: invalid argument %ld\n", arg);
+ error = -EINVAL;
+
+ }
+ break;
+
default:
error = -ENOTTY;
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
On Monday, 25 September 2006 09:13, Stefan Seyfried wrote:
> From: Stefan Seyfried <[email protected]>
>
> Add an ioctl to the userspace swsusp code that enables the usage of the
> pmops->prepare, pmops->enter and pmops->finish methods (the in-kernel
> suspend knows these as "platform method"). These are needed on many machines
> to (among others) speed up resuming by letting the BIOS skip some steps or
> let my hp nx5000 recognise the correct ac_adapter state after resume again.
>
> Signed-off-by: Stefan Seyfried <[email protected]>
ACK
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
Hi!
> From: Stefan Seyfried <[email protected]>
>
> Add an ioctl to the userspace swsusp code that enables the usage of the
> pmops->prepare, pmops->enter and pmops->finish methods (the in-kernel
> suspend knows these as "platform method"). These are needed on many machines
> to (among others) speed up resuming by letting the BIOS skip some steps or
> let my hp nx5000 recognise the correct ac_adapter state after resume again.
>
> Signed-off-by: Stefan Seyfried <[email protected]>
ACK, but please supply documentation patch, too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Monday, 25 September 2006 10:17, Pavel Machek wrote:
> Hi!
>
> > From: Stefan Seyfried <[email protected]>
> >
> > Add an ioctl to the userspace swsusp code that enables the usage of the
> > pmops->prepare, pmops->enter and pmops->finish methods (the in-kernel
> > suspend knows these as "platform method"). These are needed on many machines
> > to (among others) speed up resuming by letting the BIOS skip some steps or
> > let my hp nx5000 recognise the correct ac_adapter state after resume again.
> >
> > Signed-off-by: Stefan Seyfried <[email protected]>
>
> ACK, but please supply documentation patch, too.
I'll update the documentation along with the patch for supporting swap files
in uswsusp. It's almost ready, but I need to test it for a while before I let
it go.
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
Hi.
On Mon, 2006-09-25 at 09:13 +0200, Stefan Seyfried wrote:
> + case SNAPSHOT_PMOPS:
> + switch (arg) {
> +
> + case PMOPS_PREPARE:
> + if (pm_ops->prepare) {
> + error = pm_ops->prepare(PM_SUSPEND_DISK);
> + }
> + break;
> +
> + case PMOPS_ENTER:
> + kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
> + error = pm_ops->enter(PM_SUSPEND_DISK);
> + break;
> +
> + case PMOPS_FINISH:
> + if (pm_ops && pm_ops->finish) {
> + pm_ops->finish(PM_SUSPEND_DISK);
> + }
> + break;
> +
> + default:
> + printk(KERN_ERR "SNAPSHOT_PMOPS: invalid argument %ld\n", arg);
> + error = -EINVAL;
> +
> + }
> + break;
> +
> default:
> error = -ENOTTY;
Guys! Why can't you see yet that all this uswsusp business is sheer
lunacy? All of the important code is done in the kernel, and must be
done in the kernel. Moving the little bit of high level logic that can
be done in userspace to userspace doesn't mean you're doing the
suspending in userspace.
If you have to use userspace for suspending, use it for the things that
don't matter, like the user interface, not the things that will break
suspending and resuming if they break.
</rant>
Nigel
On Tue, 26 Sep 2006 07:34:03 +1000
Nigel Cunningham <[email protected]> wrote:
> </rant>
metoo! I'd suggest that it'd be better to be expending the grey cells on
making the present suspend stuff nice and solid, stable and fast.
I mean, right now a suspend-to-disk spends more time futzing around doing
mysterious-but-probably-pointless stuff than it does writing memory to
disk. I've no idea what it's doing with all that time, but I'll wager it's
not very useful to anyone ;)
Hi!
Nigel said:
> When will the lunacy end?
When people stop asking me for graphical progress.
Alternatively, when you strip down suspend2 patches so that they are
smaller than 2 * (sizeof(swsusp + uswsusp kernel parts)).
> > + case SNAPSHOT_PMOPS:
> > + switch (arg) {
> > +
> > + case PMOPS_PREPARE:
> > + if (pm_ops->prepare) {
> > + error = pm_ops->prepare(PM_SUSPEND_DISK);
> > + }
> > + break;
...
> > + default:
> > + printk(KERN_ERR "SNAPSHOT_PMOPS: invalid argument %ld\n", arg);
> > + error = -EINVAL;
> > +
> > + }
> > + break;
> > +
> > default:
> > error = -ENOTTY;
>
> Guys! Why can't you see yet that all this uswsusp business is sheer
> lunacy? All of the important code is done in the kernel, and must be
> done in the kernel. Moving the little bit of high level logic that can
> be done in userspace to userspace doesn't mean you're doing the
> suspending in userspace.
Of course you are right. Fortunately for us, that high level logic is
80% of code. Unfortunately for you, that high level logic is where the
ugly parts are.... such as "press esc to abort". such as "image found,
do you want to reboot and try again or destroy it?".
> If you have to use userspace for suspending, use it for the things that
> don't matter, like the user interface, not the things that will break
> suspending and resuming if they break.
PMOPS_PREPARE (& friends) is "tell ACPI to light up that moon
symbol". Useful suspend can be done without that, but ACPI will be
confused on resume.
We could do it unconditionaly, but some machines have broken ACPI bioses.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
On Mon 2006-09-25 14:45:58, Andrew Morton wrote:
> On Tue, 26 Sep 2006 07:34:03 +1000
> Nigel Cunningham <[email protected]> wrote:
>
> > </rant>
>
> metoo! I'd suggest that it'd be better to be expending the grey cells on
> making the present suspend stuff nice and solid, stable and fast.
[Un?]fortunately, Novell has some suggestions how I should expend my
grey cells in this area.
Anyway you want:
nice)
not sure if me + Rafael can do much here. Perhaps someone else
has to go through the code and rewrite it one more time? Or do
you have specific areas where suspend is really ugly?
solid)
apart from HIGHMEM64G fiasco, and related agpgart fiasco long
time before that... these are driver problems...
stable)
I believe we are doing pretty well in this area. We did not
have too many regressions, did we? (And notice that nice+fast
are actually both conflicting goals with stable).
fast)
frankly, that is not my priority for in-kernel
suspend. uswsusp will always be few seconds faster, thanks to
LZW. If we do 40MB/sec or 50MB/sec during write is not that
important. Patches are always welcome.
> I mean, right now a suspend-to-disk spends more time futzing around doing
> mysterious-but-probably-pointless stuff than it does writing memory to
> disk. I've no idea what it's doing with all that time, but I'll wager it's
> not very useful to anyone ;)
I liked the previous description more ;-).
Anyways this boils down to "find which drivers are delaying suspend
and fix them".
Okay, we could:
* avoid sending drivers down/up/down again during suspend... but that
will be ugly tree manipulating code, and all devices doing DMA must be
down, anyway... so it is probably easier to do it on per-driver basis
(as is done now) than in generic code
* tweak memory copying loops to make them slighty faster. But as
memory speeds are in GB/sec ranges, I'm not sure it is worth
optimizing.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 26 Sep 2006 00:45:00 +0200
Pavel Machek <[email protected]> wrote:
> Anyways this boils down to "find which drivers are delaying suspend
> and fix them".
The first step would be "find some way of identifying where all the time is
being spent".
Right now, netconsole gets disabled (or makes the machine hang) and most of
these machines don't have serial ports and the printk buffer gets lost
during resume.
The net result is that the machine takes a long time to suspend and resume,
and you don't have a clue *why*.
And this is a significant issue, IMO. In terms of
niceness-of-user-interface, being able to suspend in twelve seconds instead
of twenty seven rates fairly highly...
Hi!
On Mon 2006-09-25 16:06:48, Andrew Morton wrote:
> On Tue, 26 Sep 2006 00:45:00 +0200
> Pavel Machek <[email protected]> wrote:
>
> > Anyways this boils down to "find which drivers are delaying suspend
> > and fix them".
>
> The first step would be "find some way of identifying where all the time is
> being spent".
>
> Right now, netconsole gets disabled (or makes the machine hang) and most of
> these machines don't have serial ports and the printk buffer gets lost
> during resume.
>
> The net result is that the machine takes a long time to suspend and resume,
> and you don't have a clue *why*.
>
> And this is a significant issue, IMO. In terms of
> niceness-of-user-interface, being able to suspend in twelve seconds instead
> of twenty seven rates fairly highly...
Your machines spend 15 seconds in drivers? Ouch, I did not realize
_that_.
(My machine suspends in 7 seconds, perhaps 2-3 of that are playing
with drivers, so I just failed to see where the problem is).
Are these your big SMP servers? Any SCSI involved?
Rafael has "fakesuspend" patches somewhere, but you can probably just
swapoff -a, then echo disk > /sys/power/state. If you are lucky, that
should be slow, too... fortunately you'll have useful dmesg buffer
when you are done. CONFIG_PRINTK_TIMING or something, and you should
have enough clues...?
15 seconds spend within drivers is definitely _not_ okay.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 26 Sep 2006 01:21:51 +0200
Pavel Machek <[email protected]> wrote:
> Hi!
>
> On Mon 2006-09-25 16:06:48, Andrew Morton wrote:
> > On Tue, 26 Sep 2006 00:45:00 +0200
> > Pavel Machek <[email protected]> wrote:
> >
> > > Anyways this boils down to "find which drivers are delaying suspend
> > > and fix them".
> >
> > The first step would be "find some way of identifying where all the time is
> > being spent".
> >
> > Right now, netconsole gets disabled (or makes the machine hang) and most of
> > these machines don't have serial ports and the printk buffer gets lost
> > during resume.
> >
> > The net result is that the machine takes a long time to suspend and resume,
> > and you don't have a clue *why*.
> >
> > And this is a significant issue, IMO. In terms of
> > niceness-of-user-interface, being able to suspend in twelve seconds instead
> > of twenty seven rates fairly highly...
>
> Your machines spend 15 seconds in drivers? Ouch, I did not realize
> _that_.
>
> (My machine suspends in 7 seconds, perhaps 2-3 of that are playing
> with drivers, so I just failed to see where the problem is).
>
> Are these your big SMP servers? Any SCSI involved?
It's my long-suffering Vaio laptop.
> Rafael has "fakesuspend" patches somewhere, but you can probably just
> swapoff -a, then echo disk > /sys/power/state. If you are lucky, that
> should be slow, too... fortunately you'll have useful dmesg buffer
> when you are done. CONFIG_PRINTK_TIMING or something, and you should
> have enough clues...?
That would help.
> 15 seconds spend within drivers is definitely _not_ okay.
I assumed it was the same for everyone else ;)
On Mon, Sep 25, 2006 at 05:22:40PM -0700, Andrew Morton wrote:
> On Tue, 26 Sep 2006 01:21:51 +0200
> Pavel Machek <[email protected]> wrote:
> > 15 seconds spend within drivers is definitely _not_ okay.
>
> I assumed it was the same for everyone else ;)
No, it is not. Although i must admit that Pavel actually seems to _never_
have the bad hardware, and i seem to _always_ get the bad hardware, that
is slow to suspend :-)
(it might sometimes also be software setup problems, not only hardware)
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
On Tue, Sep 26, 2006 at 12:34:35AM +0200, Pavel Machek wrote:
> PMOPS_PREPARE (& friends) is "tell ACPI to light up that moon
> symbol". Useful suspend can be done without that, but ACPI will be
> confused on resume.
Just to make sure Andrew does not get confused: it also ensures on many
machines, that changed hardware (unplugged AC adapters) gets correctly
detected and that kacpid does not run wild after resume.
I personally would not really care too much about the moon symbol on the
thinkpads, but i care about the ac_adapter state being right :-)
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
Hi!
> > Your machines spend 15 seconds in drivers? Ouch, I did not realize
> > _that_.
> >
> > (My machine suspends in 7 seconds, perhaps 2-3 of that are playing
> > with drivers, so I just failed to see where the problem is).
...
> It's my long-suffering Vaio laptop.
>
> > Rafael has "fakesuspend" patches somewhere, but you can probably just
> > swapoff -a, then echo disk > /sys/power/state. If you are lucky, that
> > should be slow, too... fortunately you'll have useful dmesg buffer
> > when you are done. CONFIG_PRINTK_TIMING or something, and you should
> > have enough clues...?
>
> That would help.
Is "swapoff -a; echo disk > /sys/power/state" slow for you? If so, we
have something reasonably easy to debug, if not, we'll try something
else...
> > 15 seconds spend within drivers is definitely _not_ okay.
>
> I assumed it was the same for everyone else ;)
Ok, then I see why you was upset ;-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 2006-09-26 at 01:21 +0200, Pavel Machek wrote:
> Your machines spend 15 seconds in drivers? Ouch, I did not realize
> _that_.
My laptop spends some substantial amount of time aimilarly mooning me
when I suspend it. The phases are timed roughly like this:
16 seconds doing things to devices
2 seconds memory
4 seconds doing more things to devices
10 seconds writing to disk
(Yes, it takes about 32 seconds to suspend.)
<b
On Tue, 26 Sep 2006 12:24:34 +0200
Pavel Machek <[email protected]> wrote:
> Is "swapoff -a; echo disk > /sys/power/state" slow for you? If so, we
> have something reasonably easy to debug, if not, we'll try something
> else...
sony:/home/akpm# swapoff -a
sony:/home/akpm# time (echo disk > /sys/power/state)
echo: write error: no such device
(; echo disk > /sys/power/state; ) 0.00s user 0.08s system 1% cpu 5.259 total
It took an additional two-odd seconds to bring the X UI back into a serviceable
state.
It'd be nice to increase that 1% CPU utilisation...
Ar Maw, 2006-09-26 am 09:45 -0700, ysgrifennodd Bryan O'Sullivan:
> 16 seconds doing things to devices
Flushing the cache of a busy disk is 7 seconds a disk just to begin
with.
On Tue, 2006-09-26 at 18:44 +0100, Alan Cox wrote:
> Ar Maw, 2006-09-26 am 09:45 -0700, ysgrifennodd Bryan O'Sullivan:
> > 16 seconds doing things to devices
>
> Flushing the cache of a busy disk is 7 seconds a disk just to begin
> with.
This is an idle machine whose only activity is to have woken up from an
earlier swsusp. If I scribble on the disk a lot, it increases the
amount of time that swsusp takes, but only by a handful of seconds
(about the 7 you indicate, depending on the amount of dirty data).
<b
On Tuesday, 26 September 2006 02:22, Andrew Morton wrote:
> On Tue, 26 Sep 2006 01:21:51 +0200
> Pavel Machek <[email protected]> wrote:
>
> > Hi!
> >
> > On Mon 2006-09-25 16:06:48, Andrew Morton wrote:
> > > On Tue, 26 Sep 2006 00:45:00 +0200
> > > Pavel Machek <[email protected]> wrote:
> > >
> > > > Anyways this boils down to "find which drivers are delaying suspend
> > > > and fix them".
> > >
> > > The first step would be "find some way of identifying where all the time is
> > > being spent".
> > >
> > > Right now, netconsole gets disabled (or makes the machine hang) and most of
> > > these machines don't have serial ports and the printk buffer gets lost
> > > during resume.
> > >
> > > The net result is that the machine takes a long time to suspend and resume,
> > > and you don't have a clue *why*.
> > >
> > > And this is a significant issue, IMO. In terms of
> > > niceness-of-user-interface, being able to suspend in twelve seconds instead
> > > of twenty seven rates fairly highly...
> >
> > Your machines spend 15 seconds in drivers? Ouch, I did not realize
> > _that_.
> >
> > (My machine suspends in 7 seconds, perhaps 2-3 of that are playing
> > with drivers, so I just failed to see where the problem is).
> >
> > Are these your big SMP servers? Any SCSI involved?
>
> It's my long-suffering Vaio laptop.
>
> > Rafael has "fakesuspend" patches somewhere, but you can probably just
> > swapoff -a, then echo disk > /sys/power/state.
Eg. here: http://marc.theaimsgroup.com/?l=linux-acpi&m=115506915023030&q=raw
(with the usage info).
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
On Tuesday, 26 September 2006 00:45, Pavel Machek wrote:
> Hi!
>
> On Mon 2006-09-25 14:45:58, Andrew Morton wrote:
> > On Tue, 26 Sep 2006 07:34:03 +1000
> > Nigel Cunningham <[email protected]> wrote:
> >
> > > </rant>
> >
> > metoo! I'd suggest that it'd be better to be expending the grey cells on
> > making the present suspend stuff nice and solid, stable and fast.
>
> [Un?]fortunately, Novell has some suggestions how I should expend my
> grey cells in this area.
>
> Anyway you want:
>
> nice)
> not sure if me + Rafael can do much here. Perhaps someone else
> has to go through the code and rewrite it one more time? Or do
> you have specific areas where suspend is really ugly?
>
> solid)
> apart from HIGHMEM64G fiasco, and related agpgart fiasco long
> time before that... these are driver problems...
>
> stable)
> I believe we are doing pretty well in this area. We did not
> have too many regressions, did we? (And notice that nice+fast
> are actually both conflicting goals with stable).
>
> fast)
> frankly, that is not my priority for in-kernel
> suspend. uswsusp will always be few seconds faster, thanks to
> LZW. If we do 40MB/sec or 50MB/sec during write is not that
> important. Patches are always welcome.
Actually, swsusp with the speed-up patches requires quite a lot of RAM to
write to disk asynchronously. This effectively means that on my box the image
size should not exceed 3/8 of the total RAM size, or the synchronous writing
will start due to the lack of memory.
uswsusp doesn't seem to have this problem.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
On Tue, Sep 26, 2006 at 12:45:00AM +0200, Pavel Machek wrote:
>...
> solid)
> apart from HIGHMEM64G fiasco, and related agpgart fiasco long
> time before that... these are driver problems...
>...
One point that seems to be a bit forgotten is that driver problems do
actually matter a lot:
I for one do not care much whether I can abort suspending (I can always
resume) or whether dancing penguins are displayed during suspending -
but the fact that my saa7134 card only outputs the picture but no sound
after resuming from suspend-to-disk is a real show-stopper for me.
> Pavel
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tuesday, 26 September 2006 22:14, Adrian Bunk wrote:
> On Tue, Sep 26, 2006 at 12:45:00AM +0200, Pavel Machek wrote:
> >...
> > solid)
> > apart from HIGHMEM64G fiasco, and related agpgart fiasco long
> > time before that... these are driver problems...
> >...
>
> One point that seems to be a bit forgotten is that driver problems do
> actually matter a lot:
>
> I for one do not care much whether I can abort suspending (I can always
> resume) or whether dancing penguins are displayed during suspending -
> but the fact that my saa7134 card only outputs the picture but no sound
> after resuming from suspend-to-disk is a real show-stopper for me.
Certainly, but neither me, nor Pavel can fix all drivers with suspend-related
problems.
I think the only way to get the drivers' problems fixed eventually is to file
bug reports in bugzilla and generally complain about them to the people
who write/maintain these drivers.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
Hi.
On Tue, 2006-09-26 at 22:35 +0200, Rafael J. Wysocki wrote:
> On Tuesday, 26 September 2006 22:14, Adrian Bunk wrote:
> > On Tue, Sep 26, 2006 at 12:45:00AM +0200, Pavel Machek wrote:
> > >...
> > > solid)
> > > apart from HIGHMEM64G fiasco, and related agpgart fiasco long
> > > time before that... these are driver problems...
> > >...
> >
> > One point that seems to be a bit forgotten is that driver problems do
> > actually matter a lot:
> >
> > I for one do not care much whether I can abort suspending (I can always
> > resume) or whether dancing penguins are displayed during suspending -
> > but the fact that my saa7134 card only outputs the picture but no sound
> > after resuming from suspend-to-disk is a real show-stopper for me.
Agreed that some things are more important than others. But to some
people, user interface does matter. After all, we want (well I want)
people considering converting from Windows to see that free software can
be better than proprietary stuff, not just imitate what they're doing.
Suspend2 doesn't actually provide dancing penguins while suspending -
it's a simple progress bar in either pure text or overlayed on an image
of your choosing.
The support for aborting is really just fall out from the work on
debugging and testing failure paths.
> Certainly, but neither me, nor Pavel can fix all drivers with suspend-related
> problems.
(Or me - Suspend2 doesn't touch drivers, though I do from time to time
include driver patches that a good number of people seem to need, while
I wait for them to be merged upstream).
> I think the only way to get the drivers' problems fixed eventually is to file
> bug reports in bugzilla and generally complain about them to the people
> who write/maintain these drivers.
Amen.
Nigel
On Wed, Sep 27, 2006 at 07:38:31AM +1000, Nigel Cunningham wrote:
> Hi.
>
> On Tue, 2006-09-26 at 22:35 +0200, Rafael J. Wysocki wrote:
> > On Tuesday, 26 September 2006 22:14, Adrian Bunk wrote:
> > > On Tue, Sep 26, 2006 at 12:45:00AM +0200, Pavel Machek wrote:
> > > >...
> > > > solid)
> > > > apart from HIGHMEM64G fiasco, and related agpgart fiasco long
> > > > time before that... these are driver problems...
> > > >...
> > >
> > > One point that seems to be a bit forgotten is that driver problems do
> > > actually matter a lot:
> > >
> > > I for one do not care much whether I can abort suspending (I can always
> > > resume) or whether dancing penguins are displayed during suspending -
> > > but the fact that my saa7134 card only outputs the picture but no sound
> > > after resuming from suspend-to-disk is a real show-stopper for me.
>
> Agreed that some things are more important than others. But to some
> people, user interface does matter. After all, we want (well I want)
> people considering converting from Windows to see that free software can
> be better than proprietary stuff, not just imitate what they're doing.
>
> Suspend2 doesn't actually provide dancing penguins while suspending -
> it's a simple progress bar in either pure text or overlayed on an image
> of your choosing.
>
> The support for aborting is really just fall out from the work on
> debugging and testing failure paths.
>...
Sorry if this sounded as if I was against improvements of suspend.
That was not my intention.
But as long as there are driver problems, suspend as a whole can not be
called solid. The core itself might be solid or not, but without working
drivers this doesn't buy users much.
A user might be impressed by a progress bar on a nifty image, but if one
or more of his drivers have problems with suspend the user won't get a
good impression of Linux.
How many driver problems with suspend are buried in emails and
Bugzillas (will problems like kernel Bugzilla #6035 ever be debugged?)?
> Nigel
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wednesday, 27 September 2006 00:31, Adrian Bunk wrote:
> On Wed, Sep 27, 2006 at 07:38:31AM +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Tue, 2006-09-26 at 22:35 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, 26 September 2006 22:14, Adrian Bunk wrote:
> > > > On Tue, Sep 26, 2006 at 12:45:00AM +0200, Pavel Machek wrote:
> > > > >...
> > > > > solid)
> > > > > apart from HIGHMEM64G fiasco, and related agpgart fiasco long
> > > > > time before that... these are driver problems...
> > > > >...
> > > >
> > > > One point that seems to be a bit forgotten is that driver problems do
> > > > actually matter a lot:
> > > >
> > > > I for one do not care much whether I can abort suspending (I can always
> > > > resume) or whether dancing penguins are displayed during suspending -
> > > > but the fact that my saa7134 card only outputs the picture but no sound
> > > > after resuming from suspend-to-disk is a real show-stopper for me.
> >
> > Agreed that some things are more important than others. But to some
> > people, user interface does matter. After all, we want (well I want)
> > people considering converting from Windows to see that free software can
> > be better than proprietary stuff, not just imitate what they're doing.
> >
> > Suspend2 doesn't actually provide dancing penguins while suspending -
> > it's a simple progress bar in either pure text or overlayed on an image
> > of your choosing.
> >
> > The support for aborting is really just fall out from the work on
> > debugging and testing failure paths.
> >...
>
> Sorry if this sounded as if I was against improvements of suspend.
> That was not my intention.
>
> But as long as there are driver problems, suspend as a whole can not be
> called solid. The core itself might be solid or not, but without working
> drivers this doesn't buy users much.
>
> A user might be impressed by a progress bar on a nifty image, but if one
> or more of his drivers have problems with suspend the user won't get a
> good impression of Linux.
Very true, but is there a good solution to this problem? If you have any
ideas, please go forward with them. :-)
> How many driver problems with suspend are buried in emails and
> Bugzillas (will problems like kernel Bugzilla #6035 ever be debugged?)?
I've been trying to follow them for quite some time and some of them has
been resolved recently. Still to follow a bug report _I_ need to know there
is one. I mean, if a bug is redirected to
[email protected], for example, who will be notified
of the report?
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
Hi.
On Wed, 2006-09-27 at 00:31 +0200, Adrian Bunk wrote:
> On Wed, Sep 27, 2006 at 07:38:31AM +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Tue, 2006-09-26 at 22:35 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, 26 September 2006 22:14, Adrian Bunk wrote:
> > > > On Tue, Sep 26, 2006 at 12:45:00AM +0200, Pavel Machek wrote:
> > > > >...
> > > > > solid)
> > > > > apart from HIGHMEM64G fiasco, and related agpgart fiasco long
> > > > > time before that... these are driver problems...
> > > > >...
> > > >
> > > > One point that seems to be a bit forgotten is that driver problems do
> > > > actually matter a lot:
> > > >
> > > > I for one do not care much whether I can abort suspending (I can always
> > > > resume) or whether dancing penguins are displayed during suspending -
> > > > but the fact that my saa7134 card only outputs the picture but no sound
> > > > after resuming from suspend-to-disk is a real show-stopper for me.
> >
> > Agreed that some things are more important than others. But to some
> > people, user interface does matter. After all, we want (well I want)
> > people considering converting from Windows to see that free software can
> > be better than proprietary stuff, not just imitate what they're doing.
> >
> > Suspend2 doesn't actually provide dancing penguins while suspending -
> > it's a simple progress bar in either pure text or overlayed on an image
> > of your choosing.
> >
> > The support for aborting is really just fall out from the work on
> > debugging and testing failure paths.
> >...
>
> Sorry if this sounded as if I was against improvements of suspend.
> That was not my intention.
>
> But as long as there are driver problems, suspend as a whole can not be
> called solid. The core itself might be solid or not, but without working
> drivers this doesn't buy users much.
>
> A user might be impressed by a progress bar on a nifty image, but if one
> or more of his drivers have problems with suspend the user won't get a
> good impression of Linux.
>
> How many driver problems with suspend are buried in emails and
> Bugzillas (will problems like kernel Bugzilla #6035 ever be debugged?)?
I fully agree. One of the largest issues I'm regularly dealing with is
people reporting problems with drivers.
Regards,
Nigel
On Wednesday, 27 September 2006 01:05, Nigel Cunningham wrote:
> Hi.
>
> On Wed, 2006-09-27 at 00:31 +0200, Adrian Bunk wrote:
> > On Wed, Sep 27, 2006 at 07:38:31AM +1000, Nigel Cunningham wrote:
> > > Hi.
> > >
> > > On Tue, 2006-09-26 at 22:35 +0200, Rafael J. Wysocki wrote:
> > > > On Tuesday, 26 September 2006 22:14, Adrian Bunk wrote:
> > > > > On Tue, Sep 26, 2006 at 12:45:00AM +0200, Pavel Machek wrote:
> > > > > >...
> > > > > > solid)
> > > > > > apart from HIGHMEM64G fiasco, and related agpgart fiasco long
> > > > > > time before that... these are driver problems...
> > > > > >...
> > > > >
> > > > > One point that seems to be a bit forgotten is that driver problems do
> > > > > actually matter a lot:
> > > > >
> > > > > I for one do not care much whether I can abort suspending (I can always
> > > > > resume) or whether dancing penguins are displayed during suspending -
> > > > > but the fact that my saa7134 card only outputs the picture but no sound
> > > > > after resuming from suspend-to-disk is a real show-stopper for me.
> > >
> > > Agreed that some things are more important than others. But to some
> > > people, user interface does matter. After all, we want (well I want)
> > > people considering converting from Windows to see that free software can
> > > be better than proprietary stuff, not just imitate what they're doing.
> > >
> > > Suspend2 doesn't actually provide dancing penguins while suspending -
> > > it's a simple progress bar in either pure text or overlayed on an image
> > > of your choosing.
> > >
> > > The support for aborting is really just fall out from the work on
> > > debugging and testing failure paths.
> > >...
> >
> > Sorry if this sounded as if I was against improvements of suspend.
> > That was not my intention.
> >
> > But as long as there are driver problems, suspend as a whole can not be
> > called solid. The core itself might be solid or not, but without working
> > drivers this doesn't buy users much.
> >
> > A user might be impressed by a progress bar on a nifty image, but if one
> > or more of his drivers have problems with suspend the user won't get a
> > good impression of Linux.
> >
> > How many driver problems with suspend are buried in emails and
> > Bugzillas (will problems like kernel Bugzilla #6035 ever be debugged?)?
>
> I fully agree. One of the largest issues I'm regularly dealing with is
> people reporting problems with drivers.
Well, can we please have these reports forwarded to LKML or placed
in the bugzilla?
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
On Wed, Sep 27, 2006 at 01:31:46AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 27 September 2006 01:05, Nigel Cunningham wrote:
> > On Wed, 2006-09-27 at 00:31 +0200, Adrian Bunk wrote:
> > > On Wed, Sep 27, 2006 at 07:38:31AM +1000, Nigel Cunningham wrote:
> > > > Hi.
> > > >
> > > > On Tue, 2006-09-26 at 22:35 +0200, Rafael J. Wysocki wrote:
> > > > > On Tuesday, 26 September 2006 22:14, Adrian Bunk wrote:
> > > > > > On Tue, Sep 26, 2006 at 12:45:00AM +0200, Pavel Machek wrote:
> > > > > > >...
> > > > > > > solid)
> > > > > > > apart from HIGHMEM64G fiasco, and related agpgart fiasco long
> > > > > > > time before that... these are driver problems...
> > > > > > >...
> > > > > >
> > > > > > One point that seems to be a bit forgotten is that driver problems do
> > > > > > actually matter a lot:
> > > > > >
> > > > > > I for one do not care much whether I can abort suspending (I can always
> > > > > > resume) or whether dancing penguins are displayed during suspending -
> > > > > > but the fact that my saa7134 card only outputs the picture but no sound
> > > > > > after resuming from suspend-to-disk is a real show-stopper for me.
> > > >
> > > > Agreed that some things are more important than others. But to some
> > > > people, user interface does matter. After all, we want (well I want)
> > > > people considering converting from Windows to see that free software can
> > > > be better than proprietary stuff, not just imitate what they're doing.
> > > >
> > > > Suspend2 doesn't actually provide dancing penguins while suspending -
> > > > it's a simple progress bar in either pure text or overlayed on an image
> > > > of your choosing.
> > > >
> > > > The support for aborting is really just fall out from the work on
> > > > debugging and testing failure paths.
> > > >...
> > >
> > > Sorry if this sounded as if I was against improvements of suspend.
> > > That was not my intention.
> > >
> > > But as long as there are driver problems, suspend as a whole can not be
> > > called solid. The core itself might be solid or not, but without working
> > > drivers this doesn't buy users much.
> > >
> > > A user might be impressed by a progress bar on a nifty image, but if one
> > > or more of his drivers have problems with suspend the user won't get a
> > > good impression of Linux.
> > >
> > > How many driver problems with suspend are buried in emails and
> > > Bugzillas (will problems like kernel Bugzilla #6035 ever be debugged?)?
> >
> > I fully agree. One of the largest issues I'm regularly dealing with is
> > people reporting problems with drivers.
>
> Well, can we please have these reports forwarded to LKML or placed
> in the bugzilla?
The main question is:
Who will track these bugs, debug them (who is e.g. responsible for
kernel Bugzilla #6035?) and repeatingly poke maintainers to fix such
issues?
If you are saying you will do this job, I can try to redirect such bug
reports to the kernel Bugzilla, create a "suspend driver problems" meta
bug there, assign it to you and create the dependencies that it tracks
the already existing bugs in the kernel Bugzilla.
> Greetings,
> Rafael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi.
On Wed, 2006-09-27 at 01:31 +0200, Rafael J. Wysocki wrote:
> On Wednesday, 27 September 2006 01:05, Nigel Cunningham wrote:
> > Hi.
> >
> > On Wed, 2006-09-27 at 00:31 +0200, Adrian Bunk wrote:
> > > On Wed, Sep 27, 2006 at 07:38:31AM +1000, Nigel Cunningham wrote:
> > I fully agree. One of the largest issues I'm regularly dealing with is
> > people reporting problems with drivers.
>
> Well, can we please have these reports forwarded to LKML or placed
> in the bugzilla?
I usually redirect the people straight to the driver authors, but I can
do that.
Regards,
Nigel
On Wed, 27 Sep 2006 01:39:03 +0200
Adrian Bunk <[email protected]> wrote:
> Who will track these bugs, debug them (who is e.g. responsible for
> kernel Bugzilla #6035?) and repeatingly poke maintainers to fix such
> issues?
Known issue... I'll be spending more time on it, short-term, hopefully.
> If you are saying you will do this job, I can try to redirect such bug
> reports to the kernel Bugzilla, create a "suspend driver problems" meta
> bug there, assign it to you and create the dependencies that it tracks
> the already existing bugs in the kernel Bugzilla.
For now, yes, please let's make sure that these things are in bugzilla -
the important thing here is to capture the identity of the reporter.
On Wednesday, 27 September 2006 01:39, Adrian Bunk wrote:
> On Wed, Sep 27, 2006 at 01:31:46AM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, 27 September 2006 01:05, Nigel Cunningham wrote:
> > > On Wed, 2006-09-27 at 00:31 +0200, Adrian Bunk wrote:
> > > > On Wed, Sep 27, 2006 at 07:38:31AM +1000, Nigel Cunningham wrote:
> > > > > Hi.
> > > > >
> > > > > On Tue, 2006-09-26 at 22:35 +0200, Rafael J. Wysocki wrote:
> > > > > > On Tuesday, 26 September 2006 22:14, Adrian Bunk wrote:
> > > > > > > On Tue, Sep 26, 2006 at 12:45:00AM +0200, Pavel Machek wrote:
> > > > > > > >...
> > > > > > > > solid)
> > > > > > > > apart from HIGHMEM64G fiasco, and related agpgart fiasco long
> > > > > > > > time before that... these are driver problems...
> > > > > > > >...
> > > > > > >
> > > > > > > One point that seems to be a bit forgotten is that driver problems do
> > > > > > > actually matter a lot:
> > > > > > >
> > > > > > > I for one do not care much whether I can abort suspending (I can always
> > > > > > > resume) or whether dancing penguins are displayed during suspending -
> > > > > > > but the fact that my saa7134 card only outputs the picture but no sound
> > > > > > > after resuming from suspend-to-disk is a real show-stopper for me.
> > > > >
> > > > > Agreed that some things are more important than others. But to some
> > > > > people, user interface does matter. After all, we want (well I want)
> > > > > people considering converting from Windows to see that free software can
> > > > > be better than proprietary stuff, not just imitate what they're doing.
> > > > >
> > > > > Suspend2 doesn't actually provide dancing penguins while suspending -
> > > > > it's a simple progress bar in either pure text or overlayed on an image
> > > > > of your choosing.
> > > > >
> > > > > The support for aborting is really just fall out from the work on
> > > > > debugging and testing failure paths.
> > > > >...
> > > >
> > > > Sorry if this sounded as if I was against improvements of suspend.
> > > > That was not my intention.
> > > >
> > > > But as long as there are driver problems, suspend as a whole can not be
> > > > called solid. The core itself might be solid or not, but without working
> > > > drivers this doesn't buy users much.
> > > >
> > > > A user might be impressed by a progress bar on a nifty image, but if one
> > > > or more of his drivers have problems with suspend the user won't get a
> > > > good impression of Linux.
> > > >
> > > > How many driver problems with suspend are buried in emails and
> > > > Bugzillas (will problems like kernel Bugzilla #6035 ever be debugged?)?
> > >
> > > I fully agree. One of the largest issues I'm regularly dealing with is
> > > people reporting problems with drivers.
> >
> > Well, can we please have these reports forwarded to LKML or placed
> > in the bugzilla?
>
> The main question is:
>
> Who will track these bugs, debug them (who is e.g. responsible for
> kernel Bugzilla #6035?) and repeatingly poke maintainers to fix such
> issues?
>
> If you are saying you will do this job, I can try to redirect such bug
> reports to the kernel Bugzilla, create a "suspend driver problems" meta
> bug there, assign it to you and create the dependencies that it tracks
> the already existing bugs in the kernel Bugzilla.
Yes, please do this.
[I must say I'm a bit afraid of that but anyway someone has to do it ... ;-)]
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
Hi.
On Wed, 2006-09-27 at 07:12 +0200, Rafael J. Wysocki wrote:
> > > Well, can we please have these reports forwarded to LKML or placed
> > > in the bugzilla?
> >
> > The main question is:
> >
> > Who will track these bugs, debug them (who is e.g. responsible for
> > kernel Bugzilla #6035?) and repeatingly poke maintainers to fix such
> > issues?
> >
> > If you are saying you will do this job, I can try to redirect such bug
> > reports to the kernel Bugzilla, create a "suspend driver problems" meta
> > bug there, assign it to you and create the dependencies that it tracks
> > the already existing bugs in the kernel Bugzilla.
>
> Yes, please do this.
>
> [I must say I'm a bit afraid of that but anyway someone has to do it ... ;-)]
:) Can I please get copies too?
Regards,
Nigel
On Wed, 27 Sep 2006 15:39:10 +1000
Nigel Cunningham <[email protected]> wrote:
> > > If you are saying you will do this job, I can try to redirect such bug
> > > reports to the kernel Bugzilla, create a "suspend driver problems" meta
> > > bug there, assign it to you and create the dependencies that it tracks
> > > the already existing bugs in the kernel Bugzilla.
> >
> > Yes, please do this.
> >
> > [I must say I'm a bit afraid of that but anyway someone has to do it ... ;-)]
>
> :) Can I please get copies too?
Here are some:
http://bugme.osdl.org/show_bug.cgi?id=5528
http://bugzilla.kernel.org/show_bug.cgi?id=5945
http://bugzilla.kernel.org/show_bug.cgi?id=6101
http://bugzilla.kernel.org/show_bug.cgi?id=5962
http://bugzilla.kernel.org/show_bug.cgi?id=7057
http://bugzilla.kernel.org/show_bug.cgi?id=7067
http://bugzilla.kernel.org/show_bug.cgi?id=7077
(Some are probably fixed: I desparately need to go through all these
and refresh everything)
On Wednesday, 27 September 2006 08:00, Andrew Morton wrote:
> On Wed, 27 Sep 2006 15:39:10 +1000
> Nigel Cunningham <[email protected]> wrote:
>
> > > > If you are saying you will do this job, I can try to redirect such bug
> > > > reports to the kernel Bugzilla, create a "suspend driver problems" meta
> > > > bug there, assign it to you and create the dependencies that it tracks
> > > > the already existing bugs in the kernel Bugzilla.
> > >
> > > Yes, please do this.
> > >
> > > [I must say I'm a bit afraid of that but anyway someone has to do it ... ;-)]
> >
> > :) Can I please get copies too?
>
> Here are some:
Thanks.
> http://bugme.osdl.org/show_bug.cgi?id=5528
Unresolved, seems to be related to the fact that the support for PowerMac
suspend is still incomplete.
> http://bugzilla.kernel.org/show_bug.cgi?id=5945
Unresolved, the reporter didn't say if the problem is still present in
recent kernels.
> http://bugzilla.kernel.org/show_bug.cgi?id=6101
Old kernel, unidentified driver problem, more information needed from the
reporter.
> http://bugzilla.kernel.org/show_bug.cgi?id=5962
Probably a duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=5534
(resolved), confirmation from the reporter needed.
> http://bugzilla.kernel.org/show_bug.cgi?id=7057
Assigned to Pavel, should be rejected.
> http://bugzilla.kernel.org/show_bug.cgi?id=7067
Duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=6494,
should be fixed by the AHCI suspend patches.
> http://bugzilla.kernel.org/show_bug.cgi?id=7077
Unresolved, assigned to Alan Cox.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
Hi!
> > > > If you are saying you will do this job, I can try to redirect such bug
> > > > reports to the kernel Bugzilla, create a "suspend driver problems" meta
> > > > bug there, assign it to you and create the dependencies that it tracks
> > > > the already existing bugs in the kernel Bugzilla.
> > >
> > > Yes, please do this.
> > >
> > > [I must say I'm a bit afraid of that but anyway someone has to do it ... ;-)]
> >
> > :) Can I please get copies too?
>
> Here are some:
>
> http://bugme.osdl.org/show_bug.cgi?id=5528
> http://bugzilla.kernel.org/show_bug.cgi?id=5945
> http://bugzilla.kernel.org/show_bug.cgi?id=6101
> http://bugzilla.kernel.org/show_bug.cgi?id=5962
> http://bugzilla.kernel.org/show_bug.cgi?id=7057
> http://bugzilla.kernel.org/show_bug.cgi?id=7067
> http://bugzilla.kernel.org/show_bug.cgi?id=7077
Hmm, this series scares me, I wonder if 7087 will be suspend bug, too?
Anyway I went through them and closed the historic ones.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > > > I fully agree. One of the largest issues I'm regularly dealing with is
> > > > people reporting problems with drivers.
> > >
> > > Well, can we please have these reports forwarded to LKML or placed
> > > in the bugzilla?
> >
> > The main question is:
> >
> > Who will track these bugs, debug them (who is e.g. responsible for
> > kernel Bugzilla #6035?) and repeatingly poke maintainers to fix such
> > issues?
> >
> > If you are saying you will do this job, I can try to redirect such bug
> > reports to the kernel Bugzilla, create a "suspend driver problems" meta
> > bug there, assign it to you and create the dependencies that it tracks
> > the already existing bugs in the kernel Bugzilla.
>
> Yes, please do this.
>
> [I must say I'm a bit afraid of that but anyway someone has to do it ... ;-)]
Ok, feel free to cc-me, so you are not alone ;-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > Is "swapoff -a; echo disk > /sys/power/state" slow for you? If so, we
> > have something reasonably easy to debug, if not, we'll try something
> > else...
>
> sony:/home/akpm# swapoff -a
> sony:/home/akpm# time (echo disk > /sys/power/state)
> echo: write error: no such device
> (; echo disk > /sys/power/state; ) 0.00s user 0.08s system 1% cpu 5.259 total
>
> It took an additional two-odd seconds to bring the X UI back into a serviceable
> state.
Console switches take long... yes it would be nice to fix X :-).
But we did not reproduce that 12 seconds problem. Can you try patches
from
http://marc.theaimsgroup.com/?l=linux-acpi&m=115506915023030&q=raw
?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue 2006-09-26 09:45:08, Bryan O'Sullivan wrote:
> On Tue, 2006-09-26 at 01:21 +0200, Pavel Machek wrote:
>
> > Your machines spend 15 seconds in drivers? Ouch, I did not realize
> > _that_.
>
> My laptop spends some substantial amount of time aimilarly mooning me
> when I suspend it. The phases are timed roughly like this:
>
> 16 seconds doing things to devices
> 2 seconds memory
> 4 seconds doing more things to devices
> 10 seconds writing to disk
>
> (Yes, it takes about 32 seconds to suspend.)
But you should still have logs of that first 16 seconds, as they
happen before memory snasphots, right? dmesg after resume should be
enough.
Can you enable printk timing, and get us the log? Perhaps
bugzilla.kernel.org?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, 27 Sep 2006 11:09:02 +0200
Pavel Machek <[email protected]> wrote:
> Hi!
>
> > > Is "swapoff -a; echo disk > /sys/power/state" slow for you? If so, we
> > > have something reasonably easy to debug, if not, we'll try something
> > > else...
> >
> > sony:/home/akpm# swapoff -a
> > sony:/home/akpm# time (echo disk > /sys/power/state)
> > echo: write error: no such device
> > (; echo disk > /sys/power/state; ) 0.00s user 0.08s system 1% cpu 5.259 total
> >
> > It took an additional two-odd seconds to bring the X UI back into a serviceable
> > state.
>
> Console switches take long... yes it would be nice to fix X :-).
>
> But we did not reproduce that 12 seconds problem. Can you try patches
> from
>
> http://marc.theaimsgroup.com/?l=linux-acpi&m=115506915023030&q=raw
>
OK, that compiles.
I think we should get this documented and merge it (or something like it) into
mainline. This is one area where it's worth investing in debugging tools.
If you agree, are we happy with it in its present form?
From: "Rafael J. Wysocki" <[email protected]>
Add a swsusp debugging mode. This does everything that's needed for a suspend
except for actually suspending. So we can look in the log messages and work
out a) what code is being slow and b) which drivers are misbehaving.
(1)
# echo testproc > /sys/power/disk
# echo disk > /sys/power/state
This should turn off the non-boot CPU, freeze all processes, wait for 5
seconds and then thaw the processes and the CPU.
(2)
# echo test > /sys/power/disk
# echo disk > /sys/power/state
This should turn off the non-boot CPU, freeze all processes, shrink
memory, suspend all devices, wait for 5 seconds, resume the devices etc.
Cc: Pavel Machek <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
include/linux/pm.h | 4 +++-
kernel/power/disk.c | 37 ++++++++++++++++++++++++++++---------
2 files changed, 31 insertions(+), 10 deletions(-)
diff -puN include/linux/pm.h~swsusp-debugging include/linux/pm.h
--- a/include/linux/pm.h~swsusp-debugging
+++ a/include/linux/pm.h
@@ -116,7 +116,9 @@ typedef int __bitwise suspend_disk_metho
#define PM_DISK_PLATFORM ((__force suspend_disk_method_t) 2)
#define PM_DISK_SHUTDOWN ((__force suspend_disk_method_t) 3)
#define PM_DISK_REBOOT ((__force suspend_disk_method_t) 4)
-#define PM_DISK_MAX ((__force suspend_disk_method_t) 5)
+#define PM_DISK_TEST ((__force suspend_disk_method_t) 5)
+#define PM_DISK_TESTPROC ((__force suspend_disk_method_t) 6)
+#define PM_DISK_MAX ((__force suspend_disk_method_t) 7)
struct pm_ops {
suspend_disk_method_t pm_disk_mode;
diff -puN kernel/power/disk.c~swsusp-debugging kernel/power/disk.c
--- a/kernel/power/disk.c~swsusp-debugging
+++ a/kernel/power/disk.c
@@ -72,7 +72,7 @@ static inline void platform_finish(void)
static int prepare_processes(void)
{
- int error;
+ int error = 0;
pm_prepare_console();
@@ -85,6 +85,12 @@ static int prepare_processes(void)
goto thaw;
}
+ if (pm_disk_mode == PM_DISK_TESTPROC) {
+ printk("swsusp debug: Waiting for 5 seconds.\n");
+ mdelay(5000);
+ goto thaw;
+ }
+
/* Free memory before shutting down devices. */
if (!(error = swsusp_shrink_memory()))
return 0;
@@ -121,13 +127,21 @@ int pm_suspend_disk(void)
if (error)
return error;
+ if (pm_disk_mode == PM_DISK_TESTPROC)
+ goto Thaw;
+
suspend_console();
error = device_suspend(PMSG_FREEZE);
if (error) {
resume_console();
printk("Some devices failed to suspend\n");
- unprepare_processes();
- return error;
+ goto Thaw;
+ }
+
+ if (pm_disk_mode == PM_DISK_TEST) {
+ printk("swsusp debug: Waiting for 5 seconds.\n");
+ mdelay(5000);
+ goto Done;
}
pr_debug("PM: snapshotting memory.\n");
@@ -144,16 +158,17 @@ int pm_suspend_disk(void)
power_down(pm_disk_mode);
else {
swsusp_free();
- unprepare_processes();
- return error;
+ goto Thaw;
}
- } else
+ } else {
pr_debug("PM: Image restored successfully.\n");
+ }
swsusp_free();
Done:
device_resume();
resume_console();
+ Thaw:
unprepare_processes();
return error;
}
@@ -250,6 +265,8 @@ static const char * const pm_disk_modes[
[PM_DISK_PLATFORM] = "platform",
[PM_DISK_SHUTDOWN] = "shutdown",
[PM_DISK_REBOOT] = "reboot",
+ [PM_DISK_TEST] = "test",
+ [PM_DISK_TESTPROC] = "testproc",
};
/**
@@ -304,17 +321,19 @@ static ssize_t disk_store(struct subsyst
}
}
if (mode) {
- if (mode == PM_DISK_SHUTDOWN || mode == PM_DISK_REBOOT)
+ if (mode == PM_DISK_SHUTDOWN || mode == PM_DISK_REBOOT ||
+ mode == PM_DISK_TEST || mode == PM_DISK_TESTPROC) {
pm_disk_mode = mode;
- else {
+ } else {
if (pm_ops && pm_ops->enter &&
(mode == pm_ops->pm_disk_mode))
pm_disk_mode = mode;
else
error = -EINVAL;
}
- } else
+ } else {
error = -EINVAL;
+ }
pr_debug("PM: suspend-to-disk mode set to '%s'\n",
pm_disk_modes[mode]);
_
On Wednesday, 27 September 2006 23:08, Andrew Morton wrote:
> On Wed, 27 Sep 2006 11:09:02 +0200
> Pavel Machek <[email protected]> wrote:
>
> > Hi!
> >
> > > > Is "swapoff -a; echo disk > /sys/power/state" slow for you? If so, we
> > > > have something reasonably easy to debug, if not, we'll try something
> > > > else...
> > >
> > > sony:/home/akpm# swapoff -a
> > > sony:/home/akpm# time (echo disk > /sys/power/state)
> > > echo: write error: no such device
> > > (; echo disk > /sys/power/state; ) 0.00s user 0.08s system 1% cpu 5.259 total
> > >
> > > It took an additional two-odd seconds to bring the X UI back into a serviceable
> > > state.
> >
> > Console switches take long... yes it would be nice to fix X :-).
> >
> > But we did not reproduce that 12 seconds problem. Can you try patches
> > from
> >
> > http://marc.theaimsgroup.com/?l=linux-acpi&m=115506915023030&q=raw
> >
>
> OK, that compiles.
>
> I think we should get this documented and merge it (or something like it) into
> mainline. This is one area where it's worth investing in debugging tools.
>
> If you agree, are we happy with it in its present form?
I am. ;-)
Hi!
> > http://marc.theaimsgroup.com/?l=linux-acpi&m=115506915023030&q=raw
>
> OK, that compiles.
Does it also help you find the problem?
> I think we should get this documented and merge it (or something like it) into
> mainline. This is one area where it's worth investing in debugging tools.
>
> If you agree, are we happy with it in its present form?
Well, I thought about it, but then I thought you would not like such a
patch. Yes, it certainly makes my life easier.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, 27 Sep 2006 23:34:43 +0200
Pavel Machek <[email protected]> wrote:
> Hi!
>
> > > http://marc.theaimsgroup.com/?l=linux-acpi&m=115506915023030&q=raw
> >
> > OK, that compiles.
>
> Does it also help you find the problem?
argh. pooter is five miles away and attention span is infinitesimal.
> > I think we should get this documented and merge it (or something like it) into
> > mainline. This is one area where it's worth investing in debugging tools.
> >
> > If you agree, are we happy with it in its present form?
>
> Well, I thought about it, but then I thought you would not like such a
> patch. Yes, it certainly makes my life easier.
OK, let's run with it. If that's the final version. Perhaps add some nice
words in the documentation?
Hi!
> > > > http://marc.theaimsgroup.com/?l=linux-acpi&m=115506915023030&q=raw
> > >
> > > OK, that compiles.
> >
> > Does it also help you find the problem?
>
> argh. pooter is five miles away and attention span is infinitesimal.
What is "pooter"?
I meant the "15 seconds spent in mistery place" during suspend problem.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, Sep 27, 2006 at 07:12:33AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 27 September 2006 01:39, Adrian Bunk wrote:
>...
> >
> > Who will track these bugs, debug them (who is e.g. responsible for
> > kernel Bugzilla #6035?) and repeatingly poke maintainers to fix such
> > issues?
> >
> > If you are saying you will do this job, I can try to redirect such bug
> > reports to the kernel Bugzilla, create a "suspend driver problems" meta
> > bug there, assign it to you and create the dependencies that it tracks
> > the already existing bugs in the kernel Bugzilla.
>
> Yes, please do this.
>
> [I must say I'm a bit afraid of that but anyway someone has to do it ... ;-)]
OK, thanks.
I've created #7216, assigned it to you and added Pavel and Nigel to
the Cc.
If in doubt I added a bug to the list, so it might contain some false
positives.
> Greetings,
> Rafael
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thursday, 28 September 2006 01:21, Adrian Bunk wrote:
> On Wed, Sep 27, 2006 at 07:12:33AM +0200, Rafael J. Wysocki wrote:
> > On Wednesday, 27 September 2006 01:39, Adrian Bunk wrote:
> >...
> > >
> > > Who will track these bugs, debug them (who is e.g. responsible for
> > > kernel Bugzilla #6035?) and repeatingly poke maintainers to fix such
> > > issues?
> > >
> > > If you are saying you will do this job, I can try to redirect such bug
> > > reports to the kernel Bugzilla, create a "suspend driver problems" meta
> > > bug there, assign it to you and create the dependencies that it tracks
> > > the already existing bugs in the kernel Bugzilla.
> >
> > Yes, please do this.
> >
> > [I must say I'm a bit afraid of that but anyway someone has to do it ... ;-)]
>
> OK, thanks.
>
> I've created #7216, assigned it to you and added Pavel and Nigel to
> the Cc.
Thanks.
> If in doubt I added a bug to the list, so it might contain some false
> positives.
OK
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller