login
Search
A recent thread on the lkml explored the current state of suspend and resume in the Linux kernel. Nigel Cunningham responded to a patch for uswsusp exclaiming, "guys! Why can't you see yet that all this uswsusp business is sheer lunacy?" He went on to reiterate his concerns that the important logic involved in suspending will take place in the kernel, and that trying to move it to userspace won't work. Andrew Morton joined in, "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," going on to add, "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 ;)"
The discussion went on to examine why the suspend process can be so slow, and then moved on to look at the underlying problems remaining get suspend and resume solid and stable. Nigel reported, "one of the largest issues I'm regularly dealing with is people reporting problems with drivers." While the underlying suspend and restore logic is working, many drivers for various devices are still unable to be successfully suspended and then restored. It was agreed that these bugs should be tracked in bugzilla, and that someone needed to follow up on them. Andrew Morton replied, "known issue... I'll be spending more time on it, short-term, hopefully," adding, "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."
From: Nigel Cunningham [email blocked]
To: Stefan Seyfried [email blocked]
Subject: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Tue, 26 Sep 2006 07:34:03 +1000
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
From: Andrew Morton [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Mon, 25 Sep 2006 14:45:58 -0700
On Tue, 26 Sep 2006 07:34:03 +1000
Nigel Cunningham [email blocked] 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 ;)
From: Pavel Machek [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Tue, 26 Sep 2006 00:45:00 +0200
Hi!
On Mon 2006-09-25 14:45:58, Andrew Morton wrote:
> On Tue, 26 Sep 2006 07:34:03 +1000
> Nigel Cunningham [email blocked] 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
From: Andrew Morton [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Mon, 25 Sep 2006 16:06:48 -0700
On Tue, 26 Sep 2006 00:45:00 +0200
Pavel Machek [email blocked] 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...
From: Pavel Machek [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Tue, 26 Sep 2006 01:21:51 +0200
Hi!
On Mon 2006-09-25 16:06:48, Andrew Morton wrote:
> On Tue, 26 Sep 2006 00:45:00 +0200
> Pavel Machek [email blocked] 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
From: Andrew Morton [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Mon, 25 Sep 2006 17:22:40 -0700
On Tue, 26 Sep 2006 01:21:51 +0200
Pavel Machek [email blocked] 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 blocked] 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 ;)
From: Adrian Bunk [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Tue, 26 Sep 2006 22:14:37 +0200
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
From: "Rafael J. Wysocki" [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Tue, 26 Sep 2006 22:35:13 +0200
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
From: Nigel Cunningham [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Wed, 27 Sep 2006 07:38:31 +1000
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
From: Adrian Bunk [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Wed, 27 Sep 2006 00:31:46 +0200
On Wed, Sep 27, 2006 at 07:38:31AM +1000, Nigel Cunningham wrote:
>
> 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
From: Nigel Cunningham [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Wed, 27 Sep 2006 09:05:15 +1000
Hi.
On Wed, 2006-09-27 at 00:31 +0200, Adrian Bunk wrote:
>
> 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
From: "Rafael J. Wysocki" [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Wed, 27 Sep 2006 01:31:46 +0200
On Wednesday, 27 September 2006 01:05, 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?
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
From: Adrian Bunk [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Wed, 27 Sep 2006 01:39:03 +0200
On Wed, Sep 27, 2006 at 01:31:46AM +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.
> 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
From: Andrew Morton [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Tue, 26 Sep 2006 17:16:44 -0700
On Wed, 27 Sep 2006 01:39:03 +0200
Adrian Bunk [email blocked] 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.
From: Nigel Cunningham [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Wed, 27 Sep 2006 15:39:10 +1000
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
From: Andrew Morton [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Tue, 26 Sep 2006 23:00:40 -0700
On Wed, 27 Sep 2006 15:39:10 +1000
Nigel Cunningham [email blocked] wrote:
>
> :) 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)
From: "Rafael J. Wysocki" [email blocked]
Subject: Re: When will the lunacy end? (Was Re: [PATCH] uswsusp: add pmops->{prepare,enter,finish} support (aka "platform mode"))
Date: Wed, 27 Sep 2006 09:47:33 +0200
On Wednesday, 27 September 2006 08:00, Andrew Morton wrote:
>
> 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
Don't know why Andrew Morton
Don't know why Andrew Morton wants to continue to use the current suspend code. I've not looked at the code, so i don't know which one is bettere at that leve, but according to my experience Nigel swsusp2 works better than the vanilla kernel one.
Current code
Because 99.99% of every distribution out there uses that code and mechanism. Legacy is a powerful thing which is why we avoid putting crap in in the first place or else people depend on it forever (see devfs debates).
But a lot of people think the
But a lot of people think the current swsusp is crap and the only person really defending it is Pavel. AFAIK distributions have only started really looking at suspend/resume recently, a year or so ago no one even touched it because they just assumed it wouldn't work reliably enough.
In the lkml thread Andrew said that his notebook sits seemingly idel for ~15s when he suspends it and he thought that was normal. I know that debugging suspend/resume is harder than most other code because you have to shutdown the devices you normally use for that debugging, but when people say "Man swsusp really sucks" and most Linux users, developers, etc shrug their shoulders and just say "Yea", don't you think that's a problem?
"Legacy == good" not reliably true
Note I did not say that what is already there is necessarily good, just that it is supported and present in most distributions. Personally I think kernel interest in desktop and laptop issues is 99% lacking which is what got me interested in kernel development in the first place. Unfortunately that remains true.
Mostly I agree, although it d
Mostly I agree, although it does seem as if desktop/laptop support has picked up a lot of interest recently. Hell just last week a friend of mine installed Ubuntu on a new notebook and everything worked out of the box, I was amazed. Well suspend/resume didn't work, but I didn't put any time into debugging it either. =)
And for some reason people think that once it's in it should stay there, look at the recent mixup with the modular /proc/config.gz patch. Initially the argument was "Why should this be included?" but then Andrew accidentally pushed it through to Linus and instead of backing out the patch the argument changed to "It's in already so why should we back it out?". Wouldn't it make more sense to back it out and continue the original discussion?
Hell maybe we can get Andrew to accidentally apply the Suspend2 patches to his tree and kill the suspend2/uswsusp argument completely.
ck tree
And accidentally include my -ck tree before I quit kernel development forever? ...
Blacklist
I really really hope that some framework for blacklisting is set up. On my laptop I can set my laptop to hibernate (and standby), but it cannot wake up.
So it would be much better if these options only were avaible for hardware where it is known to work.
The Problem is: You can't tel
The Problem is: You can't tell *that* generally if it works with some hardware or not.
For instance suspend to ram works for me - but I got the impression whenever I change anything in the kernel config it stops working. Don't know why.
It definitely won't work at all if I use framebuffer. Or USB Modules are loaded. But then these things are not Hardware dependant, are they?
Driver bugs here.
Contact the lkml list, Pavel or Nigel and ask them what you need to send them so they can get your configuration debugged. If you are having it then likely so is some one else. Nice thing about laptops, they are much more standardized than desktops ( though that still leaves alot standard configurations out there.)
zapfioqj
anszkosm [URL=http://ayxccuax.com]uqzecujo[/URL] icfjqohv http://frkaubbv.com zhsbcqbl pvyysjhg
All Linux distros have there
All Linux distros have there own tweak to implement the suspend in an optimized way. But I always hate the slow speed of resume from that suspended state.
- http://www.shobhit.info