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 well
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
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
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 ne
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 re
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 st
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 a
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 lo
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. Normall
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 that
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, a
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
> >> pe
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) retu
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
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 kee
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 listeni
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 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. Eve
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);
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
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 USB
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 f
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 caus
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 f
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 - I've
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 se
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 see
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
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.
An
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 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 firmwa
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
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.
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? T
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
reliabl
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
> > > p
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
> > complexi
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 mistak
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 suspend-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 th
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 th
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 freezer.
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 way"
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 thi
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.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the
On Fri, 25 May 2007, Pavel Machek wrote:
> >
> > 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 t
On Thu 2007-05-24 15:23:56, Linus Torvalds wrote:
>
>
> On Thu, 24 May 2007, Linus Torvalds wrote:
> >
> > Then, what you do is:
> > - stop user space
> > - suspend
> > - resume
> > - start user space
>
> Btw, this is where things like "udevd" can be really problematic. That
> whole "ueven
Hi!
>
> On Fri, 25 May 2007, Pavel Machek wrote:
> > >
> > > Equally arguably, we should just have a "resume_late()" call that can be
> > > used to do this after everything is up and running.
> >
> > Yes, we can do that. But userland will see devices "not there" for a
> > few seconds after boot
On Thu, 24 May 2007, Linus Torvalds wrote:
>
> Then, what you do is:
> - stop user space
> - suspend
> - resume
> - start user space
Btw, this is where things like "udevd" can be really problematic. That
whole "uevent over netlink" stuff is really nasty for things like this.
It's quite po
On Thu 2007-05-24 15:10:29, Linus Torvalds wrote:
>
>
> On Fri, 25 May 2007, Pavel Machek wrote:
> > >
> > > Equally arguably, we should just have a "resume_late()" call that can be
> > > used to do this after everything is up and running.
> >
> > Yes, we can do that. But userland will see dev
On Fri, 25 May 2007, Pavel Machek wrote:
> >
> > Equally arguably, we should just have a "resume_late()" call that can be
> > used to do this after everything is up and running.
>
> Yes, we can do that. But userland will see devices "not there" for a
> few seconds after boot.
No they won't.
Hi!
> > Well. we'd like to present hardware in working state as soon as we
> > resume (if eth0 was there before resume, it should be there after
> > resume. not 3 seconds after resume); so if someone needs to load the
> > firmware, they should just store it in the kernel memory, and load it
> > du
On Thursday, 24 May 2007 22:27, Linus Torvalds wrote:
>
> On Thu, 24 May 2007, Pavel Machek wrote:
> >
> > If someone does request_firmware from resume function... that's
> > bad. Resume function should be fixed. Pcmcia? ti12xx driver?
>
> Probably pcmcia "ds" driver and CONFIG_PCMCIA_LOAD_CIS.
On Thu, 24 May 2007, Pavel Machek wrote:
>
> If someone does request_firmware from resume function... that's
> bad. Resume function should be fixed. Pcmcia? ti12xx driver?
Probably pcmcia "ds" driver and CONFIG_PCMCIA_LOAD_CIS.
> Well. we'd like to present hardware in working state as soon as
Hi!
> Yeah, but the interesting one is this pair:
>
> events/0 R running 0 4 1 (L-TLB)
>
> sleep.sh D 014F 0 5798 5789 (NOTLB)
> Call Trace:
>[] kobject_uevent_env+0x3a1/0x4a0
>[] wait_for_completion+0x79/0xb0
>[] default_wake_function+0x0/0x10
67 matches
Mail list logo
