Hi!
> > They will not trigger 100% of the time, but sporadically and generally at
> > random.
> >
> > At least the freezer problems are reproducible. ;-)
>
> Our experience with powermacs has been that it isn't actually all that
> hard to get it right for the drivers you care about.
So... will
On Thu, 5 Jul 2007, Miklos Szeredi wrote:
> > > Alan Stern writes:
> > >
> > > > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> > > > wanting to resume devices during a system suspend transition? This is
> > > > exactly what happens when those threads aren't frozen.
> >
> > Umm, and CODA which is _very_ similar to fuse was there long before
> > fuse or the freezer ;)
> >
>
> I did userfs around 1994-5.
Yes, fuse didn't in fact have very much original idea in it. It was
just putting all the pieces together to make a stable and useful
userspace filesystem fram
> > Alan Stern writes:
> >
> > > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> > > wanting to resume devices during a system suspend transition? This is
> > > exactly what happens when those threads aren't frozen.
> >
> > So, I wonder why I don't see that error on my po
Miklos Szeredi wrote:
Umm, and CODA which is _very_ similar to fuse was there long before
fuse or the freezer ;)
I did userfs around 1994-5.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
On Thu, 5 Jul 2007, Paul Mackerras wrote:
> Alan Stern writes:
>
> > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> > wanting to resume devices during a system suspend transition? This is
> > exactly what happens when those threads aren't frozen.
>
> So, I wonder why I
On Thursday, 5 July 2007 14:50, Johannes Berg wrote:
> On Thu, 2007-07-05 at 14:51 +0200, Rafael J. Wysocki wrote:
>
> > > > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> > > > wanting to resume devices during a system suspend transition? This is
> > > > exactly what hap
On Thu, 2007-07-05 at 14:51 +0200, Rafael J. Wysocki wrote:
> > > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> > > wanting to resume devices during a system suspend transition? This is
> > > exactly what happens when those threads aren't frozen.
> >
> > So, I wonder wh
> > > PF_FREEZER_SKIP flag. Perhaps we can do similar thing with FUSE.
> >
> > It cannot be just worked around in fuse, as a task might be sleeping
> > on a number of VFS mutexes as well (i_mutex, s_vfs_rename_mutex, etc).
> > It would be a gigantic hack, possible at all.
>
> Well, obviously FUS
On Thursday, 5 July 2007 02:36, Paul Mackerras wrote:
> Alan Stern writes:
>
> > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> > wanting to resume devices during a system suspend transition? This is
> > exactly what happens when those threads aren't frozen.
>
> So, I wo
On Thursday, 5 July 2007 02:43, Paul Mackerras wrote:
> Miklos Szeredi writes:
>
> > OK, let me summarize the situation as I see it now: there are two
> > camps, the pro-freezers and the anti-freezers.
> >
> > Pro-freezers say:
> >
> > - don't remove the freezer, otherwise we'll have to deal w
On Thursday, 5 July 2007 10:37, Miklos Szeredi wrote:
> > > Pro-freezers say:
> > >
> > > - don't remove the freezer, otherwise we'll have to deal with
> > > numerous problems in drivers
> >
> > And these problems will generally be difficult to reproduce reliably
> > and debug.
>
> I see e
On Thursday, 5 July 2007 02:29, Paul Mackerras wrote:
> Rafael J. Wysocki writes:
>
> > They will not trigger 100% of the time, but sporadically and generally at
> > random.
> >
> > At least the freezer problems are reproducible. ;-)
>
> Our experience with powermacs has been that it isn't actua
> > Pro-freezers say:
> >
> > - don't remove the freezer, otherwise we'll have to deal with
> > numerous problems in drivers
>
> And these problems will generally be difficult to reproduce reliably
> and debug.
I see exactly the opposite.
With the freezer I can have very rarely occuring f
Alan Stern writes:
> Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> wanting to resume devices during a system suspend transition? This is
> exactly what happens when those threads aren't frozen.
So, I wonder why I don't see that error on my powerbook?
Paul.
-
To unsubsc
Miklos Szeredi writes:
> OK, let me summarize the situation as I see it now: there are two
> camps, the pro-freezers and the anti-freezers.
>
> Pro-freezers say:
>
> - don't remove the freezer, otherwise we'll have to deal with
> numerous problems in drivers
>
> Anti-freezers say:
>
>
Rafael J. Wysocki writes:
> They will not trigger 100% of the time, but sporadically and generally at
> random.
>
> At least the freezer problems are reproducible. ;-)
Our experience with powermacs has been that it isn't actually all that
hard to get it right for the drivers you care about.
Pau
On Wednesday, 4 July 2007 21:25, Miklos Szeredi wrote:
> > Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> > wanting to resume devices during a system suspend transition? This is
> > exactly what happens when those threads aren't frozen.
>
> OK, let me summarize the situat
> Remember what I wrote a few minutes ago about khubd and ksuspend_usbd
> wanting to resume devices during a system suspend transition? This is
> exactly what happens when those threads aren't frozen.
OK, let me summarize the situation as I see it now: there are two
camps, the pro-freezers and th
On Wed, 4 Jul 2007, Alan Stern wrote:
> > Threads that do no I/O at all don't care about suspend/resume and
> > don't need to be frozen in any case. Threads that issue I/O requests
> > in order to service incoming I/O requests can't be frozen because of
> > the possibility of deadlock. Which lea
On Wed, 4 Jul 2007, Matthew Garrett wrote:
> On Wed, Jul 04, 2007 at 10:38:47AM -0400, Alan Stern wrote:
>
> > Okay, I agree that (1) can be handled without too much effort. But
> > doing it adds an extra test to _every_ driver's I/O pathway. Freezing
> > userspace does not incur all this add
On Wed, 4 Jul 2007, Miklos Szeredi wrote:
> And we won't know if drivers are OK until we remove the freezer,
> catch-22.
>
> So I think we need to disable the freezer at least in -mm and/or
> optionally in -linus.
>
> I applied Matthew's patch, and suspend did in fact stop working
> (thinkpad t6
On Wed, 4 Jul 2007, Paul Mackerras wrote:
> Rafael J. Wysocki writes:
>
> > They are mostly related to kernel threads, that we've already agreed no to
> > freeze (except for the ones that want that, but they will be responsible for
> > getting everything right). The initial patches for that are
On Wednesday, 4 July 2007 17:03, Oliver Neukum wrote:
> Am Mittwoch, 4. Juli 2007 schrieb Miklos Szeredi:
> > > > And we won't know if drivers are OK until we remove the freezer,
> > > > catch-22.
> > >
> > > I disagree. We can learn that by auditing the drivers.
> >
> > In theory, yes. But it
Am Mittwoch, 4. Juli 2007 schrieb Miklos Szeredi:
> > > And we won't know if drivers are OK until we remove the freezer,
> > > catch-22.
> >
> > I disagree. We can learn that by auditing the drivers.
>
> In theory, yes. But it scales far worse than letting everyone
> experiment/report/fix probl
Am Mittwoch, 4. Juli 2007 schrieb Matthew Garrett:
> On Wed, Jul 04, 2007 at 10:38:47AM -0400, Alan Stern wrote:
>
> > Okay, I agree that (1) can be handled without too much effort. But
> > doing it adds an extra test to _every_ driver's I/O pathway. Freezing
> > userspace does not incur all t
On Wed, Jul 04, 2007 at 10:38:47AM -0400, Alan Stern wrote:
> Okay, I agree that (1) can be handled without too much effort. But
> doing it adds an extra test to _every_ driver's I/O pathway. Freezing
> userspace does not incur all this additional overhead.
For runtime PM to work it's already
> On Wednesday, 4 July 2007 13:51, Miklos Szeredi wrote:
> > > Still, my position is this:
> > >
> > > 1) The freezer (in the modified form, with the freezing of kernel threads
> > > limited to the ones that want to be frozen) is needed for hibernation.
> > >
> > > 2) The freezer is generally not
On Tue, 3 Jul 2007, Matthew Garrett wrote:
> On Tue, Jul 03, 2007 at 06:21:42PM -0400, Alan Stern wrote:
> > On Tue, 3 Jul 2007, Matthew Garrett wrote:
> > > We're used to the idea of applications blocking when a resource they're
> > > using goes away - NFS has done it forever.
> >
> > You pers
On Wednesday, 4 July 2007 13:51, Miklos Szeredi wrote:
> > Still, my position is this:
> >
> > 1) The freezer (in the modified form, with the freezing of kernel threads
> > limited to the ones that want to be frozen) is needed for hibernation.
> >
> > 2) The freezer is generally not needed for su
On Wednesday, 4 July 2007 14:41, Theodore Tso wrote:
> On Wed, Jul 04, 2007 at 01:25:55PM +0200, Rafael J. Wysocki wrote:
> > > Don't know what exactly?
> >
> > How many drivers will be adversely affected by the $subject change.
>
> Ok, so how about a CONFIG option which removes the freezer, so w
On 7/4/07, Paul Mackerras <[EMAIL PROTECTED]> wrote:
Rafael J. Wysocki writes:
> They are mostly related to kernel threads, that we've already agreed no to
> freeze (except for the ones that want that, but they will be responsible for
> getting everything right). The initial patches for that ar
On Wed, Jul 04, 2007 at 01:25:55PM +0200, Rafael J. Wysocki wrote:
> > Don't know what exactly?
>
> How many drivers will be adversely affected by the $subject change.
Ok, so how about a CONFIG option which removes the freezer, so we can
find out experimentally how many people without it? We can
> Still, my position is this:
>
> 1) The freezer (in the modified form, with the freezing of kernel threads
> limited to the ones that want to be frozen) is needed for hibernation.
>
> 2) The freezer is generally not needed for suspend, _but_ there are drivers
> in the tree that rely on it being
Rafael J. Wysocki writes:
> They are mostly related to kernel threads, that we've already agreed no to
> freeze (except for the ones that want that, but they will be responsible for
> getting everything right). The initial patches for that are in -mm and more
> will come.
Serious question: which
On Wednesday, 4 July 2007 12:58, Paul Mackerras wrote:
> Rafael J. Wysocki writes:
>
> > Okay, so in fact you don't know.
>
> Don't know what exactly?
How many drivers will be adversely affected by the $subject change.
> It has been a while since I had my head in the USB code. I assume
> it's
Rafael J. Wysocki writes:
> Okay, so in fact you don't know.
Don't know what exactly?
It has been a while since I had my head in the USB code. I assume
it's being maintained by competent people. :)
> And that's my point in this thread.
Well, I'd be interested in hearing from Matthew whether h
On Wednesday, 4 July 2007 05:38, Paul Mackerras wrote:
> Rafael J. Wysocki writes:
>
> > Now, please tell me how many driver writers even thought that something
> > might try to access their devices after .suspend() had been executed (or
> > even whilie it was being executed)?
>
> Well, I believe
On Wednesday, 4 July 2007 02:34, Matthew Garrett wrote:
> On Tue, Jul 03, 2007 at 06:17:04PM -0600, Robert Hancock wrote:
> > Matthew Garrett wrote:
> > >Leave the process blocked and defer any i/o until after resume. Why does
> > >it need to be any more complicated than that?
> >
> > It gets com
Rafael J. Wysocki writes:
> Now, please tell me how many driver writers even thought that something
> might try to access their devices after .suspend() had been executed (or
> even whilie it was being executed)?
Well, I believe that the USB framework copes with this, except
possibly for some cor
On Tue, Jul 03, 2007 at 06:17:04PM -0600, Robert Hancock wrote:
> Matthew Garrett wrote:
> >Leave the process blocked and defer any i/o until after resume. Why does
> >it need to be any more complicated than that?
>
> It gets complicated when this has to be added and TESTED in EVERY
> driver. Th
Matthew Garrett wrote:
On Tue, Jul 03, 2007 at 06:21:42PM -0400, Alan Stern wrote:
On Tue, 3 Jul 2007, Matthew Garrett wrote:
We're used to the idea of applications blocking when a resource they're
using goes away - NFS has done it forever.
You persist in evading my point. I'm not worried abo
On Tue, Jul 03, 2007 at 06:21:42PM -0400, Alan Stern wrote:
> On Tue, 3 Jul 2007, Matthew Garrett wrote:
> > We're used to the idea of applications blocking when a resource they're
> > using goes away - NFS has done it forever.
>
> You persist in evading my point. I'm not worried about applicat
On Tuesday, 3 July 2007 23:36, Matthew Garrett wrote:
> On Tue, Jul 03, 2007 at 11:37:51PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, 3 July 2007 23:20, Matthew Garrett wrote:
> > > We're used to the idea of applications blocking when a resource they're
> > > using goes away - NFS has done it
On Tue, 3 Jul 2007, Matthew Garrett wrote:
> On Tue, Jul 03, 2007 at 05:16:37PM -0400, Alan Stern wrote:
> > On Tue, 3 Jul 2007, Matthew Garrett wrote:
> > > But that's fine - "Are we undergoing a systemwide suspend" is an easy
> > > question to ask. Freezing processes instead means that most of
Am Dienstag, 3. Juli 2007 schrieb Matthew Garrett:
> On Tue, Jul 03, 2007 at 11:37:51PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, 3 July 2007 23:20, Matthew Garrett wrote:
> > > We're used to the idea of applications blocking when a resource they're
> > > using goes away - NFS has done it fo
On Tue, Jul 03, 2007 at 11:37:51PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 3 July 2007 23:20, Matthew Garrett wrote:
> > We're used to the idea of applications blocking when a resource they're
> > using goes away - NFS has done it forever.
>
> Now, please tell me how many driver writers ev
On Tuesday, 3 July 2007 23:20, Matthew Garrett wrote:
> On Tue, Jul 03, 2007 at 05:16:37PM -0400, Alan Stern wrote:
> > On Tue, 3 Jul 2007, Matthew Garrett wrote:
> > > But that's fine - "Are we undergoing a systemwide suspend" is an easy
> > > question to ask. Freezing processes instead means tha
On Tue, Jul 03, 2007 at 05:16:37PM -0400, Alan Stern wrote:
> On Tue, 3 Jul 2007, Matthew Garrett wrote:
> > But that's fine - "Are we undergoing a systemwide suspend" is an easy
> > question to ask. Freezing processes instead means that most of those
> > paths will never be tested.
>
> The ques
On Tue, 3 Jul 2007, Matthew Garrett wrote:
> On Tue, Jul 03, 2007 at 05:10:08PM -0400, Alan Stern wrote:
>
> > No, no -- you have it exactly backwards. Removing the freezer turns
> > STR into something _less_ like runtime suspend, because it adds the
> > requirement that devices must not autom
On Tue, Jul 03, 2007 at 05:10:08PM -0400, Alan Stern wrote:
> No, no -- you have it exactly backwards. Removing the freezer turns
> STR into something _less_ like runtime suspend, because it adds the
> requirement that devices must not automatically be resumed when an I/O
> request arrives.
B
On Tue, 3 Jul 2007, Matthew Garrett wrote:
> See the start of this thread. It's just not clear what the freezer buys
> us - removing it gets rid of a load of subtle issues and complexity, and
> turns system suspend into something that looks more like runtime
> suspend (which might then encourag
On Tue, Jul 03, 2007 at 03:54:55PM -0400, Alan Stern wrote:
> On Tue, 3 Jul 2007, Matthew Garrett wrote:
> > There's nothing wrong with it as such, it's just that our implementation
> > appears to suck in a myriad of small ways that keep cropping up and
> > biting people. Even without the sys_syn
On Tue, 3 Jul 2007, Matthew Garrett wrote:
> > I agree that in general the suspend process should not have to wait for
> > a userspace callback to complete. Indeed, there's no particular
> > reason that anything running during STR should have to wait for
> > something in userspace to complete.
On Tue, Jul 03, 2007 at 03:33:40PM -0400, Alan Stern wrote:
> On Tue, 3 Jul 2007, Matthew Garrett wrote:
>
> > On Tue, Jul 03, 2007 at 12:57:17PM -0400, Alan Stern wrote:
> > > On Tue, 3 Jul 2007, Matthew Garrett wrote:
> > > > For the suspend to RAM case, that sounds absolutely fine.
> > >
> > >
On Tue, 3 Jul 2007, Matthew Garrett wrote:
> On Tue, Jul 03, 2007 at 12:57:17PM -0400, Alan Stern wrote:
> > On Tue, 3 Jul 2007, Matthew Garrett wrote:
> > > On Tue, Jul 03, 2007 at 12:03:33PM -0400, Alan Stern wrote:
> > > > Quite apart from the sync() matter, _any_ synchronous call to a FUSE
>
On Tue, Jul 03, 2007 at 12:57:17PM -0400, Alan Stern wrote:
> On Tue, 3 Jul 2007, Matthew Garrett wrote:
> > On Tue, Jul 03, 2007 at 12:03:33PM -0400, Alan Stern wrote:
> > > Quite apart from the sync() matter, _any_ synchronous call to a FUSE
> > > filesystem during STR will cause trouble. Even
On Tue, 3 Jul 2007, Matthew Garrett wrote:
> On Tue, Jul 03, 2007 at 12:03:33PM -0400, Alan Stern wrote:
> > On Tue, 3 Jul 2007, Matthew Garrett wrote:
> >
> > > Suspend to RAM on a machine with / on a fuse filesystem turns out to be
> > > a screaming nightmare - either the suspend fails because
On Tue, Jul 03, 2007 at 12:03:33PM -0400, Alan Stern wrote:
> On Tue, 3 Jul 2007, Matthew Garrett wrote:
>
> > Suspend to RAM on a machine with / on a fuse filesystem turns out to be
> > a screaming nightmare - either the suspend fails because syslog (for
> > instance) can't be frozen, or the ma
On Tue, 3 Jul 2007, Matthew Garrett wrote:
> Suspend to RAM on a machine with / on a fuse filesystem turns out to be
> a screaming nightmare - either the suspend fails because syslog (for
> instance) can't be frozen, or the machine deadlocks for some other
> reason I haven't tracked down. We co
On Tuesday, 3 July 2007 07:49, Benjamin Herrenschmidt wrote:
> On Tue, 2007-07-03 at 05:29 +0100, Matthew Garrett wrote:
> > Suspend to RAM on a machine with / on a fuse filesystem turns out to be
> > a screaming nightmare - either the suspend fails because syslog (for
> > instance) can't be froz
On Tue, 2007-07-03 at 05:29 +0100, Matthew Garrett wrote:
> Suspend to RAM on a machine with / on a fuse filesystem turns out to be
> a screaming nightmare - either the suspend fails because syslog (for
> instance) can't be frozen, or the machine deadlocks for some other
> reason I haven't track
62 matches
Mail list logo
