Hi.
On Wed, 2007-05-30 at 16:04 +0200, Rafael J. Wysocki wrote:
> On Wednesday, 30 May 2007 15:17, Nigel Cunningham wrote:
> > On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
> > > On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
> > >
> > > (Trimmed the Cc:s quite heavily
On Wed, 30 May 2007, Rafael J. Wysocki wrote:
>
> Very true. And I think the right order should be to make the midlayers do
> this and then remove the freezer from the STR code path, not the other way
> around. :-)
Yes. After all, STR simply shouldn't _care_.
The rule should be that in a
Hi!
> (Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond
> the original point)
>
> > Notice that we want to be able to suspend while hibernating -- for
> > suspend to both behaviour. So drivers may _not_ rely on system being
> > runnable.
>
> So keep the driver layers
On Wed, 30 May 2007 12:26:57 +0200 Romano Giannetti wrote:
>
> On Tue, 2007-05-29 at 07:55 -0700, Linus Torvalds wrote:
> >
> > On Tue, 29 May 2007, Romano Giannetti wrote:
> > >
> > > - The good (?) news. I have made 7 suspend/resume cycle (to ram, I
> > > haven't tested hibernation) with a
On Wed, May 30, 2007 at 04:04:22PM +0200, Rafael J. Wysocki wrote:
> On Wednesday, 30 May 2007 15:17, Nigel Cunningham wrote:
> > On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
> > > So keep the driver layers read-only and unfreeze the processes after
> > > doing the atomic copy.
> >
On Wednesday, 30 May 2007 15:29, Matthew Garrett wrote:
> On Wed, May 30, 2007 at 11:17:47PM +1000, Nigel Cunningham wrote:
>
> > That aside, keeping the driver layers read-only sounds more complicated
> > than just freezing processes.
>
> It's a problem that effectively has to be solved for STR
On Wednesday, 30 May 2007 15:17, Nigel Cunningham wrote:
> On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
> > On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
> >
> > (Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond
> > the original point)
> >
> >
On Wed, May 30, 2007 at 11:17:47PM +1000, Nigel Cunningham wrote:
> That aside, keeping the driver layers read-only sounds more complicated
> than just freezing processes.
It's a problem that effectively has to be solved for STR anyway if
we're going to suspend without freezing. The midlayers
On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
> On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
>
> (Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond
> the original point)
>
> > Notice that we want to be able to suspend while hibernating -- for
>
On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
(Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond
the original point)
> Notice that we want to be able to suspend while hibernating -- for
> suspend to both behaviour. So drivers may _not_ rely on system being
Hi!
> > > How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
> > > the filesystem VFS callers? Or is that starting to get messy again?
> >
> > Yeah. Getting messy again :)
>
> Indeed. And also misses the point - the point being that we don't actually
> need to freeze anything at
On Tue, 2007-05-29 at 07:55 -0700, Linus Torvalds wrote:
>
> On Tue, 29 May 2007, Romano Giannetti wrote:
> >
> > - The good (?) news. I have made 7 suspend/resume cycle (to ram, I
> > haven't tested hibernation) with a 2.6.21.2 with that patch, applied
> > manually. The system did suspend and
Hi.
On Wed, 2007-05-30 at 16:04 +0200, Rafael J. Wysocki wrote:
On Wednesday, 30 May 2007 15:17, Nigel Cunningham wrote:
On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
(Trimmed the Cc:s quite heavily - I think
On Tue, 2007-05-29 at 07:55 -0700, Linus Torvalds wrote:
On Tue, 29 May 2007, Romano Giannetti wrote:
- The good (?) news. I have made 7 suspend/resume cycle (to ram, I
haven't tested hibernation) with a 2.6.21.2 with that patch, applied
manually. The system did suspend and resume
Hi!
How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
the filesystem VFS callers? Or is that starting to get messy again?
Yeah. Getting messy again :)
Indeed. And also misses the point - the point being that we don't actually
need to freeze anything at all most of
On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
(Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond
the original point)
Notice that we want to be able to suspend while hibernating -- for
suspend to both behaviour. So drivers may _not_ rely on system being
On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
(Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond
the original point)
Notice that we want to be able to suspend while hibernating -- for
On Wed, May 30, 2007 at 11:17:47PM +1000, Nigel Cunningham wrote:
That aside, keeping the driver layers read-only sounds more complicated
than just freezing processes.
It's a problem that effectively has to be solved for STR anyway if
we're going to suspend without freezing. The midlayers
On Wednesday, 30 May 2007 15:17, Nigel Cunningham wrote:
On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
On Wed, May 30, 2007 at 01:49:21PM +0200, Pavel Machek wrote:
(Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond
the original point)
Notice that
On Wednesday, 30 May 2007 15:29, Matthew Garrett wrote:
On Wed, May 30, 2007 at 11:17:47PM +1000, Nigel Cunningham wrote:
That aside, keeping the driver layers read-only sounds more complicated
than just freezing processes.
It's a problem that effectively has to be solved for STR anyway
On Wed, May 30, 2007 at 04:04:22PM +0200, Rafael J. Wysocki wrote:
On Wednesday, 30 May 2007 15:17, Nigel Cunningham wrote:
On Wed, 2007-05-30 at 13:40 +0100, Matthew Garrett wrote:
So keep the driver layers read-only and unfreeze the processes after
doing the atomic copy.
I know
On Wed, 30 May 2007 12:26:57 +0200 Romano Giannetti wrote:
On Tue, 2007-05-29 at 07:55 -0700, Linus Torvalds wrote:
On Tue, 29 May 2007, Romano Giannetti wrote:
- The good (?) news. I have made 7 suspend/resume cycle (to ram, I
haven't tested hibernation) with a 2.6.21.2 with
Hi!
(Trimmed the Cc:s quite heavily - I think this has gone somewhere beyond
the original point)
Notice that we want to be able to suspend while hibernating -- for
suspend to both behaviour. So drivers may _not_ rely on system being
runnable.
So keep the driver layers read-only and
On Wed, 30 May 2007, Rafael J. Wysocki wrote:
Very true. And I think the right order should be to make the midlayers do
this and then remove the freezer from the STR code path, not the other way
around. :-)
Yes. After all, STR simply shouldn't _care_.
The rule should be that in a
Hi.
On Tue, 2007-05-29 at 14:33 -0700, Linus Torvalds wrote:
>
> On Wed, 30 May 2007, Nigel Cunningham wrote:
> >
> > On Tue, 2007-05-29 at 10:19 -0400, Mark Lord wrote:
> > >
> > > How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
> > > the filesystem VFS callers? Or is that
On Wed, 30 May 2007, Nigel Cunningham wrote:
>
> On Tue, 2007-05-29 at 10:19 -0400, Mark Lord wrote:
> >
> > How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
> > the filesystem VFS callers? Or is that starting to get messy again?
>
> Yeah. Getting messy again :)
Indeed. And
Hi.
On Tue, 2007-05-29 at 10:19 -0400, Mark Lord wrote:
> Nigel Cunningham wrote:
> >
> > I'm sorry to say it, but dropping process freezing still seems to me
> > like the better way though. I prefer it because of the reliability
> > aspect. With the current code, having frozen processes, I can
On Tue, 29 May 2007, Romano Giannetti wrote:
>
> - The good (?) news. I have made 7 suspend/resume cycle (to ram, I
> haven't tested hibernation) with a 2.6.21.2 with that patch, applied
> manually. The system did suspend and resume nicely even compiling a
> kernel and opening openoffice.
Nigel Cunningham wrote:
I'm sorry to say it, but dropping process freezing still seems to me
like the better way though. I prefer it because of the reliability
aspect. With the current code, having frozen processes, I can look at
the state of memory, calculate how much I'll need for this or
Linus Torvalds wrote:
On Fri, 25 May 2007, Nigel Cunningham wrote:
Does that mean you never ever power off your laptop (assuming you have
one), and the battery never runs out? Surely you must power it off
completely sometimes?
So? The bootup isn't that much worse than a disk suspend/resume,
On Tue, 2007-05-29 at 13:00 +0100, Michael-Luke Jones wrote:
> Rafael J. Wysocki wrote:
> > On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
> >> The shiny userspace firmware loading causes problems since it exists,
> >> every second box has problems with it, in all sorts of situations. If
> >>
Hi!
> > I guess we should warn the driver authors, then; and decide what driver
> > authors should do.
>
> Drivers really shouldn't do anythign at all.
*)
> > If I'm video4linux driver for grabbing screen, have been suspended, and
> > someone asks me to read a frame, should I
> >
> > a)
On Tuesday, 29 May 2007 14:00, Michael-Luke Jones wrote:
> Rafael J. Wysocki wrote:
> > On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
> >> The shiny userspace firmware loading causes problems since it exists,
> >> every second box has problems with it, in all sorts of situations. If
> >>
Rafael J. Wysocki wrote:
On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
The shiny userspace firmware loading causes problems since it exists,
every second box has problems with it, in all sorts of situations. If
people are still sold to the idea of userspace firmware loading, why
don't we
On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
> On 5/25/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > On Fri, 25 May 2007, Pavel Machek wrote:
> > >
> > > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> > > PEOPLE FOR FIVE YEARS NOW.
> >
> > And people aren't
On Sun, 2007-05-27 at 19:44 +0100, Matthew Garrett wrote:
>
> Anyway. I've tested the following patch on a dual-core x86. No obvious
> issues yet, but I'll try to put it through a few hundred cycles.
[patch to disable freezer deleted]
First of all, excuse me for being a quite lousy tester.
On 5/25/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Fri, 25 May 2007, Pavel Machek wrote:
>
> 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> PEOPLE FOR FIVE YEARS NOW.
And people aren't listening. Have you thought about _why_?
The thing is, it should just work.
On 5/25/07, Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 25 May 2007, Pavel Machek wrote:
2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
PEOPLE FOR FIVE YEARS NOW.
And people aren't listening. Have you thought about _why_?
The thing is, it should just work. Even
On Sun, 2007-05-27 at 19:44 +0100, Matthew Garrett wrote:
Anyway. I've tested the following patch on a dual-core x86. No obvious
issues yet, but I'll try to put it through a few hundred cycles.
[patch to disable freezer deleted]
First of all, excuse me for being a quite lousy tester. Could
On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
On 5/25/07, Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 25 May 2007, Pavel Machek wrote:
2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
PEOPLE FOR FIVE YEARS NOW.
And people aren't listening. Have you
Rafael J. Wysocki wrote:
On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
The shiny userspace firmware loading causes problems since it exists,
every second box has problems with it, in all sorts of situations. If
people are still sold to the idea of userspace firmware loading, why
don't we
On Tuesday, 29 May 2007 14:00, Michael-Luke Jones wrote:
Rafael J. Wysocki wrote:
On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
The shiny userspace firmware loading causes problems since it exists,
every second box has problems with it, in all sorts of situations. If
people are still
Hi!
I guess we should warn the driver authors, then; and decide what driver
authors should do.
Drivers really shouldn't do anythign at all.
*)
If I'm video4linux driver for grabbing screen, have been suspended, and
someone asks me to read a frame, should I
a) return
On Tue, 2007-05-29 at 13:00 +0100, Michael-Luke Jones wrote:
Rafael J. Wysocki wrote:
On Tuesday, 29 May 2007 08:55, Kay Sievers wrote:
The shiny userspace firmware loading causes problems since it exists,
every second box has problems with it, in all sorts of situations. If
people are
Linus Torvalds wrote:
On Fri, 25 May 2007, Nigel Cunningham wrote:
Does that mean you never ever power off your laptop (assuming you have
one), and the battery never runs out? Surely you must power it off
completely sometimes?
So? The bootup isn't that much worse than a disk suspend/resume,
Nigel Cunningham wrote:
I'm sorry to say it, but dropping process freezing still seems to me
like the better way though. I prefer it because of the reliability
aspect. With the current code, having frozen processes, I can look at
the state of memory, calculate how much I'll need for this or
On Tue, 29 May 2007, Romano Giannetti wrote:
- The good (?) news. I have made 7 suspend/resume cycle (to ram, I
haven't tested hibernation) with a 2.6.21.2 with that patch, applied
manually. The system did suspend and resume nicely even compiling a
kernel and opening openoffice. Normally
Hi.
On Tue, 2007-05-29 at 10:19 -0400, Mark Lord wrote:
Nigel Cunningham wrote:
I'm sorry to say it, but dropping process freezing still seems to me
like the better way though. I prefer it because of the reliability
aspect. With the current code, having frozen processes, I can look at
On Wed, 30 May 2007, Nigel Cunningham wrote:
On Tue, 2007-05-29 at 10:19 -0400, Mark Lord wrote:
How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
the filesystem VFS callers? Or is that starting to get messy again?
Yeah. Getting messy again :)
Indeed. And also
Hi.
On Tue, 2007-05-29 at 14:33 -0700, Linus Torvalds wrote:
On Wed, 30 May 2007, Nigel Cunningham wrote:
On Tue, 2007-05-29 at 10:19 -0400, Mark Lord wrote:
How about blocking brk() and mmap(MAP_ANONYMOUS) in addition to
the filesystem VFS callers? Or is that starting to get
On Mon, May 28, 2007 at 09:53:50AM -0700, Linus Torvalds wrote:
>
> Before we suspend a device, we call the subsystem that that device has
> been registered with. Ie, we have code like this:
>
> if (dev->class && dev->class->suspend)
> error = dev->class->suspend(dev,
Hi.
On Mon, 2007-05-28 at 14:03 +0100, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 02:55:07PM +0200, Pavel Machek wrote:
>
> > Well, PPC people are aware of this, and they think they can fix the
> > drivers. We probably want to drop the freezer for suspend long-term,
> > so. PPC machines
On Mon, 28 May 2007, Pavel Machek wrote:
>
> I guess we should warn the driver authors, then; and decide what driver
> authors should do.
Drivers really shouldn't do anythign at all.
> If I'm video4linux driver for grabbing screen, have been suspended, and
> someone asks me to read a frame,
Hi!
> > Well, PPC people are aware of this, and they think they can fix the
> > drivers. We probably want to drop the freezer for suspend long-term,
> > so. PPC machines use small subset of all the drivers, so it apparently
> > is not big problem for them.
>
> I'm fairly certain that PPC uses
On Mon, May 28, 2007 at 02:55:07PM +0200, Pavel Machek wrote:
> Well, PPC people are aware of this, and they think they can fix the
> drivers. We probably want to drop the freezer for suspend long-term,
> so. PPC machines use small subset of all the drivers, so it apparently
> is not big problem
Hi!
> > > This /mostly/ works - I've had my test machine cycling through a suspend
> > > cycle every 10 seconds for the past hour without any difficulties
> > > providing I unload USB first. If USB is loaded, the suspend occasionally
> > > fails with one of the devices returning -EBUSY and
On Mon, May 28, 2007 at 10:11:15AM +0200, Rafael J. Wysocki wrote:
> On Monday, 28 May 2007 03:05, Matthew Garrett wrote:
> > This /mostly/ works - I've had my test machine cycling through a suspend
> > cycle every 10 seconds for the past hour without any difficulties
> > providing I unload USB
Hi!
> > As far as I can tell the PPC code simply shuts down the devices without
> > worrying about userspace at all. If this was reliable, what prevents us
> > from simply disabling the freezer for STR?
>
> Personally, I think that's the right thing to do.
>
> And by "disabling the freezer",
On Monday, 28 May 2007 03:05, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 07:44:02PM +0100, Matthew Garrett wrote:
>
> > Anyway. I've tested the following patch on a dual-core x86. No obvious
> > issues yet, but I'll try to put it through a few hundred cycles.
>
> This /mostly/ works -
On Monday, 28 May 2007 03:05, Matthew Garrett wrote:
On Sun, May 27, 2007 at 07:44:02PM +0100, Matthew Garrett wrote:
Anyway. I've tested the following patch on a dual-core x86. No obvious
issues yet, but I'll try to put it through a few hundred cycles.
This /mostly/ works - I've had my
Hi!
As far as I can tell the PPC code simply shuts down the devices without
worrying about userspace at all. If this was reliable, what prevents us
from simply disabling the freezer for STR?
Personally, I think that's the right thing to do.
And by disabling the freezer, I think we
On Mon, May 28, 2007 at 10:11:15AM +0200, Rafael J. Wysocki wrote:
On Monday, 28 May 2007 03:05, Matthew Garrett wrote:
This /mostly/ works - I've had my test machine cycling through a suspend
cycle every 10 seconds for the past hour without any difficulties
providing I unload USB first.
Hi!
This /mostly/ works - I've had my test machine cycling through a suspend
cycle every 10 seconds for the past hour without any difficulties
providing I unload USB first. If USB is loaded, the suspend occasionally
fails with one of the devices returning -EBUSY and causing it to
On Mon, May 28, 2007 at 02:55:07PM +0200, Pavel Machek wrote:
Well, PPC people are aware of this, and they think they can fix the
drivers. We probably want to drop the freezer for suspend long-term,
so. PPC machines use small subset of all the drivers, so it apparently
is not big problem for
Hi!
Well, PPC people are aware of this, and they think they can fix the
drivers. We probably want to drop the freezer for suspend long-term,
so. PPC machines use small subset of all the drivers, so it apparently
is not big problem for them.
I'm fairly certain that PPC uses USB. In any
On Mon, 28 May 2007, Pavel Machek wrote:
I guess we should warn the driver authors, then; and decide what driver
authors should do.
Drivers really shouldn't do anythign at all.
If I'm video4linux driver for grabbing screen, have been suspended, and
someone asks me to read a frame,
Hi.
On Mon, 2007-05-28 at 14:03 +0100, Matthew Garrett wrote:
On Mon, May 28, 2007 at 02:55:07PM +0200, Pavel Machek wrote:
Well, PPC people are aware of this, and they think they can fix the
drivers. We probably want to drop the freezer for suspend long-term,
so. PPC machines use small
On Mon, May 28, 2007 at 09:53:50AM -0700, Linus Torvalds wrote:
Before we suspend a device, we call the subsystem that that device has
been registered with. Ie, we have code like this:
if (dev-class dev-class-suspend)
error = dev-class-suspend(dev, state);
which
On Sun, May 27, 2007 at 07:44:02PM +0100, Matthew Garrett wrote:
> Anyway. I've tested the following patch on a dual-core x86. No obvious
> issues yet, but I'll try to put it through a few hundred cycles.
This /mostly/ works - I've had my test machine cycling through a suspend
cycle every 10
On Sunday, 27 May 2007 20:44, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 08:32:14PM +0200, Rafael J. Wysocki wrote:
>
> > In particular, please see this message:
> >
> > https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012301.html
>
> Yes, there's also the notifier chain for
On Sun, May 27, 2007 at 08:32:14PM +0200, Rafael J. Wysocki wrote:
> In particular, please see this message:
>
> https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012301.html
Yes, there's also the notifier chain for the hardware. However, very few
drivers seem to use that - adb
On Sunday, 27 May 2007 18:43, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 09:26:00AM -0700, Linus Torvalds wrote:
>
> > And by "disabling the freezer", I think we should just not call it at all.
> > However, sadly, right now it's called from common code. I'll happily take
> > a tested
On Sun, May 27, 2007 at 09:26:00AM -0700, Linus Torvalds wrote:
> And by "disabling the freezer", I think we should just not call it at all.
> However, sadly, right now it's called from common code. I'll happily take
> a tested patch to split that code sequence up, and try to do it in 2.6.23,
On Sun, 27 May 2007, Matthew Garrett wrote:
>
> As far as I can tell the PPC code simply shuts down the devices without
> worrying about userspace at all. If this was reliable, what prevents us
> from simply disabling the freezer for STR?
Personally, I think that's the right thing to do.
On Thu, May 24, 2007 at 03:53:28PM -0700, Linus Torvalds wrote:
> And I repeat: PowerPC had working and stable suspend five _years_ ago,
> without any of that freezing crud. We should rip it out.
As far as I can tell the PPC code simply shuts down the devices without
worrying about userspace
On Thu, May 24, 2007 at 03:53:28PM -0700, Linus Torvalds wrote:
And I repeat: PowerPC had working and stable suspend five _years_ ago,
without any of that freezing crud. We should rip it out.
As far as I can tell the PPC code simply shuts down the devices without
worrying about userspace at
On Sun, 27 May 2007, Matthew Garrett wrote:
As far as I can tell the PPC code simply shuts down the devices without
worrying about userspace at all. If this was reliable, what prevents us
from simply disabling the freezer for STR?
Personally, I think that's the right thing to do.
And
On Sun, May 27, 2007 at 09:26:00AM -0700, Linus Torvalds wrote:
And by disabling the freezer, I think we should just not call it at all.
However, sadly, right now it's called from common code. I'll happily take
a tested patch to split that code sequence up, and try to do it in 2.6.23,
if
On Sunday, 27 May 2007 18:43, Matthew Garrett wrote:
On Sun, May 27, 2007 at 09:26:00AM -0700, Linus Torvalds wrote:
And by disabling the freezer, I think we should just not call it at all.
However, sadly, right now it's called from common code. I'll happily take
a tested patch to split
On Sun, May 27, 2007 at 08:32:14PM +0200, Rafael J. Wysocki wrote:
In particular, please see this message:
https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012301.html
Yes, there's also the notifier chain for the hardware. However, very few
drivers seem to use that - adb seems
On Sunday, 27 May 2007 20:44, Matthew Garrett wrote:
On Sun, May 27, 2007 at 08:32:14PM +0200, Rafael J. Wysocki wrote:
In particular, please see this message:
https://lists.linux-foundation.org/pipermail/linux-pm/2007-May/012301.html
Yes, there's also the notifier chain for the
On Sun, May 27, 2007 at 07:44:02PM +0100, Matthew Garrett wrote:
Anyway. I've tested the following patch on a dual-core x86. No obvious
issues yet, but I'll try to put it through a few hundred cycles.
This /mostly/ works - I've had my test machine cycling through a suspend
cycle every 10
On Friday, 25 May 2007 01:19, Pavel Machek wrote:
> On Thu 2007-05-24 20:16:38, Henrique de Moraes Holschuh wrote:
> > On Fri, 25 May 2007, Pavel Machek wrote:
> > > My proposed solution is "fix pcmcia to load firmware before suspend
> > > even starts"
> >
> > s/pcmcia/all drivers that load
Hi!
> > To answer the question, I guess the answer is that although they're
> > different creatures, they have similarities. This is one of them, which
> > is why I could make the mistake I did. Nothing in the issue being
> > discussed was unique to suspend-to-ram. Perhaps we (or at least I)
Hi!
> > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> > PEOPLE FOR FIVE YEARS NOW.
>
> And people aren't listening. Have you thought about _why_?
>
> The thing is, it should just work. Even without pre-loading.
But it does not work, and as you demonstrated, getting it
Hi!
To answer the question, I guess the answer is that although they're
different creatures, they have similarities. This is one of them, which
is why I could make the mistake I did. Nothing in the issue being
discussed was unique to suspend-to-ram. Perhaps we (or at least I) focus
too
Hi!
2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
PEOPLE FOR FIVE YEARS NOW.
And people aren't listening. Have you thought about _why_?
The thing is, it should just work. Even without pre-loading.
But it does not work, and as you demonstrated, getting it to work
On Friday, 25 May 2007 01:19, Pavel Machek wrote:
On Thu 2007-05-24 20:16:38, Henrique de Moraes Holschuh wrote:
On Fri, 25 May 2007, Pavel Machek wrote:
My proposed solution is fix pcmcia to load firmware before suspend
even starts
s/pcmcia/all drivers that load firmware/ if you are
Hi.
On Thu, 2007-05-24 at 21:49 -0700, Linus Torvalds wrote:
>
> On Fri, 25 May 2007, Nigel Cunningham wrote:
> >
> > Does that mean you never ever power off your laptop (assuming you have
> > one), and the battery never runs out? Surely you must power it off
> > completely sometimes?
>
> So?
On Fri, 25 May 2007, Nigel Cunningham wrote:
>
> Does that mean you never ever power off your laptop (assuming you have
> one), and the battery never runs out? Surely you must power it off
> completely sometimes?
So? The bootup isn't that much worse than a disk suspend/resume, and it's
Howdy.
On Thu, 2007-05-24 at 20:31 -0700, Linus Torvalds wrote:
>
> On Fri, 25 May 2007, Nigel Cunningham wrote:
> > >
> > > That said, I think freezing is crap even for
> > > snapshotting/suspend-to-disk,
> > > but the point of the above rant is to show how insane it is to think that
> > >
On Fri, 25 May 2007, Nigel Cunningham wrote:
> >
> > That said, I think freezing is crap even for snapshotting/suspend-to-disk,
> > but the point of the above rant is to show how insane it is to think that
> > problems and complexity in one area should translate into problems and
> >
Hi.
On Thu, 2007-05-24 at 19:41 -0700, Linus Torvalds wrote:
>
> On Fri, 25 May 2007, Nigel Cunningham wrote:
> >
> > To answer the question, I guess the answer is that although they're
> > different creatures, they have similarities. This is one of them, which
> > is why I could make the
On Fri, 25 May 2007, Nigel Cunningham wrote:
>
> To answer the question, I guess the answer is that although they're
> different creatures, they have similarities. This is one of them, which
> is why I could make the mistake I did. Nothing in the issue being
> discussed was unique to
Hi Linus.
On Thu, 2007-05-24 at 19:10 -0700, Linus Torvalds wrote:
>
> On Fri, 25 May 2007, Nigel Cunningham wrote:
> >
> > First, let me agree with you that for the atomic copy itself, the
> > freezer is unnecessary. Disabling irqs and so on is enough to ensure the
> > atomic copy is atomic. I
On Fri, 25 May 2007, Nigel Cunningham wrote:
>
> First, let me agree with you that for the atomic copy itself, the
> freezer is unnecessary. Disabling irqs and so on is enough to ensure the
> atomic copy is atomic. I don't think any of us are arguing with you
> there.
First off, realize that
Hi Linus.
On Thu, 2007-05-24 at 17:37 -0700, Linus Torvalds wrote:
>
> On Fri, 25 May 2007, Pavel Machek wrote:
> >
> > 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> > PEOPLE FOR FIVE YEARS NOW.
>
> And people aren't listening. Have you thought about _why_?
>
> The
On Fri, 25 May 2007, Pavel Machek wrote:
>
> 2) we need to preload firmware during _suspend_. I AM TELLING THAT TO
> PEOPLE FOR FIVE YEARS NOW.
And people aren't listening. Have you thought about _why_?
The thing is, it should just work. Even without pre-loading.
> Imageine we killed
On Thu 2007-05-24 20:16:38, Henrique de Moraes Holschuh wrote:
> On Fri, 25 May 2007, Pavel Machek wrote:
> > My proposed solution is "fix pcmcia to load firmware before suspend
> > even starts"
>
> s/pcmcia/all drivers that load firmware/ if you are going to go that way.
I'm not "going that
Hi!
> > > Why the HELL cannot you realize that kernel threads are different?
> >
> > Ugh? We are talking about request_firmware() here, right? That's
> > calling userland helper to load the firmware...? Looks like USER
> > thread to me.
>
> Right. And if we had had the nice old /sbin/hotplug
1 - 100 of 180 matches
Mail list logo
