On Wed, 1 Aug 2007, Pavel Machek wrote:
Hi!
Do we have to block module loading?
No. Registering new drivers is okay, registering new devices is bad.
Of course, some modules do want to register a new device in their init
method. I don't know what we should do about them. Force the
On Wednesday, 1 August 2007 11:22, Pavel Machek wrote:
> Hi!
>
> > > Hmm, wonder why this isn't affecting people with VPNs? Probably
> > > network mounts over VPN are rare, and ever rarer to have fs activity
> > > on them during suspend.
> > >
> > > Anyway, I think it's long overdue to stop
Hi!
> > Hmm, wonder why this isn't affecting people with VPNs? Probably
> > network mounts over VPN are rare, and ever rarer to have fs activity
> > on them during suspend.
> >
> > Anyway, I think it's long overdue to stop thinking about how to "fix"
> > fuse, and concentrate on fixing the
Hi!
> > Do we have to block module loading?
>
> No. Registering new drivers is okay, registering new devices is bad.
>
> Of course, some modules do want to register a new device in their init
> method. I don't know what we should do about them. Force the
> registration to fail, I suppose.
Hi!
> > > The problem with FUSE is related to the fact that the freezer can't
> > > freeze uninterruptible tasks and we said that perhaps we might avoid
> > > it if FUSE was made freezing-aware. Still, no one has gone in this
> > > direction and I don't know of any plans to do that.
> >
> > I
Hi!
The problem with FUSE is related to the fact that the freezer can't
freeze uninterruptible tasks and we said that perhaps we might avoid
it if FUSE was made freezing-aware. Still, no one has gone in this
direction and I don't know of any plans to do that.
I thought we have
Hi!
Do we have to block module loading?
No. Registering new drivers is okay, registering new devices is bad.
Of course, some modules do want to register a new device in their init
method. I don't know what we should do about them. Force the
registration to fail, I suppose. How
Hi!
Hmm, wonder why this isn't affecting people with VPNs? Probably
network mounts over VPN are rare, and ever rarer to have fs activity
on them during suspend.
Anyway, I think it's long overdue to stop thinking about how to fix
fuse, and concentrate on fixing the underlying problem
On Wednesday, 1 August 2007 11:22, Pavel Machek wrote:
Hi!
Hmm, wonder why this isn't affecting people with VPNs? Probably
network mounts over VPN are rare, and ever rarer to have fs activity
on them during suspend.
Anyway, I think it's long overdue to stop thinking about how
On Wed, 1 Aug 2007, Pavel Machek wrote:
Hi!
Do we have to block module loading?
No. Registering new drivers is okay, registering new devices is bad.
Of course, some modules do want to register a new device in their init
method. I don't know what we should do about them. Force the
On Tue, 24 Jul 2007, Huang, Ying wrote:
> >From: Alan Stern [mailto:[EMAIL PROTECTED]
> >It can't. Indeed, in the absence of a freezer, user threads will need
> >devices (more accurately, will submit I/O requests for devices) that
> >have to be kept quiescent or low-power. Drivers will need to
>From: Alan Stern [mailto:[EMAIL PROTECTED]
>It can't. Indeed, in the absence of a freezer, user threads will need
>devices (more accurately, will submit I/O requests for devices) that
>have to be kept quiescent or low-power. Drivers will need to delay
>those requests until the devices are
From: Alan Stern [mailto:[EMAIL PROTECTED]
It can't. Indeed, in the absence of a freezer, user threads will need
devices (more accurately, will submit I/O requests for devices) that
have to be kept quiescent or low-power. Drivers will need to delay
those requests until the devices are returned
On Tue, 24 Jul 2007, Huang, Ying wrote:
From: Alan Stern [mailto:[EMAIL PROTECTED]
It can't. Indeed, in the absence of a freezer, user threads will need
devices (more accurately, will submit I/O requests for devices) that
have to be kept quiescent or low-power. Drivers will need to delay
On Monday, 23 July 2007 23:55, Nigel Cunningham wrote:
> Hi.
>
> On Tuesday 24 July 2007 01:23:15 Alan Stern wrote:
> > On Mon, 23 Jul 2007, Nigel Cunningham wrote:
> >
> > > Take a step back for a second.
> > >
> > > The problem we're facing now is that we're getting some userspace
> > >
Hi.
On Tuesday 24 July 2007 01:23:15 Alan Stern wrote:
> On Mon, 23 Jul 2007, Nigel Cunningham wrote:
>
> > Take a step back for a second.
> >
> > The problem we're facing now is that we're getting some userspace threads,
> > used in processing I/O, that are functioning as exceptions to the
On Mon, 23 Jul 2007 [EMAIL PROTECTED] wrote:
> > For one thing, checking for a suspend-in-progress at the beginning of
> > each and every system call would add overhead to a hot path in the
> > kernel, one which is already very heavily optimized. People wouldn't
> > stand for it.
>
> I thought
On Mon, 23 Jul 2007, Oliver Neukum wrote:
Am Montag 23 Juli 2007 schrieb Miklos Szeredi:
The reason is that we want them to "park" in safe places, ie. where there
are no locks held etc. Thus, these safe places need to be chosen somehow
and since they are not marked throughout the code, we
On Mon, 23 Jul 2007, Alan Stern wrote:
On Sun, 22 Jul 2007 [EMAIL PROTECTED] wrote:
Ok, I did misunderstand you. it sound slike all you need to do to make
sure that locks are not held is to allow system calls to return before
trying to do the suspend/kexec/etc. that sounds like not only a
On Mon, 23 Jul 2007, Nigel Cunningham wrote:
> Take a step back for a second.
>
> The problem we're facing now is that we're getting some userspace threads,
> used in processing I/O, that are functioning as exceptions to the "freeze
> userspace, then freezeable kernel threads" rule. They are
On Sun, 22 Jul 2007 [EMAIL PROTECTED] wrote:
> > You are confusing "userspace" with "user tasks". And not only that,
> > you often use the term "userspace" when you should say "user mode".
> >
> > If you want I can explain the differences.
>
> please do, I have been treating all three as the
Am Samstag 21 Juli 2007 schrieb Alan Stern:
> On Fri, 20 Jul 2007, Oliver Neukum wrote:
>
> > > We already have a pre-suspend notification available for drivers that
> > > need to allocate large amounts of memory.
> >
> > Is that facility fine grained enough?
>
> It's a notifier chain that
> Alan has recently proposed to introduce "suspend locks" to be acquired during
> a suspend/hibernation and such that we can leave uninterruptible tasks that
> don't hold any of them.
Sounds sane. A global rwsem could be acquired for read by drivers,
and for write by suspend/hibernate. Just
On Monday, 23 July 2007 15:08, Miklos Szeredi wrote:
> > > > The reason is that we want them to "park" in safe places, ie. where
> > > > there
> > > > are no locks held etc. Thus, these safe places need to be chosen
> > > > somehow
> > > > and since they are not marked throughout the code, we
> > > The reason is that we want them to "park" in safe places, ie. where there
> > > are no locks held etc. Thus, these safe places need to be chosen somehow
> > > and since they are not marked throughout the code, we choose the obvious
> > > one. :-)
> >
> > Why shouldn't locks be held?
> >
>
Am Montag 23 Juli 2007 schrieb Miklos Szeredi:
> > The reason is that we want them to "park" in safe places, ie. where there
> > are no locks held etc. Thus, these safe places need to be chosen somehow
> > and since they are not marked throughout the code, we choose the obvious
> > one. :-)
>
>
On Monday, 23 July 2007 14:14, Miklos Szeredi wrote:
> > On Monday, 23 July 2007 12:24, Miklos Szeredi wrote:
> > > > > The only thing to do is what Rafael has been working on: unfreeze
> > > > > things, hope the tasks sort themselves out, and try again.
> > > >
> > > > That's what I'm
> On Monday, 23 July 2007 12:24, Miklos Szeredi wrote:
> > > > The only thing to do is what Rafael has been working on: unfreeze
> > > > things, hope the tasks sort themselves out, and try again.
> > >
> > > That's what I'm questioning. Is there a more reliable way and we've
> > > just given up
On Monday, 23 July 2007 12:24, Miklos Szeredi wrote:
> > > The only thing to do is what Rafael has been working on: unfreeze
> > > things, hope the tasks sort themselves out, and try again.
> >
> > That's what I'm questioning. Is there a more reliable way and we've
> > just given up too quickly?
> > The only thing to do is what Rafael has been working on: unfreeze
> > things, hope the tasks sort themselves out, and try again.
>
> That's what I'm questioning. Is there a more reliable way and we've
> just given up too quickly?
There obviously _are_ more reliable ways. A trivial one seems
The only thing to do is what Rafael has been working on: unfreeze
things, hope the tasks sort themselves out, and try again.
That's what I'm questioning. Is there a more reliable way and we've
just given up too quickly?
There obviously _are_ more reliable ways. A trivial one seems to be
On Monday, 23 July 2007 12:24, Miklos Szeredi wrote:
The only thing to do is what Rafael has been working on: unfreeze
things, hope the tasks sort themselves out, and try again.
That's what I'm questioning. Is there a more reliable way and we've
just given up too quickly?
There
On Monday, 23 July 2007 12:24, Miklos Szeredi wrote:
The only thing to do is what Rafael has been working on: unfreeze
things, hope the tasks sort themselves out, and try again.
That's what I'm questioning. Is there a more reliable way and we've
just given up too quickly?
On Monday, 23 July 2007 14:14, Miklos Szeredi wrote:
On Monday, 23 July 2007 12:24, Miklos Szeredi wrote:
The only thing to do is what Rafael has been working on: unfreeze
things, hope the tasks sort themselves out, and try again.
That's what I'm questioning. Is there a more
Am Montag 23 Juli 2007 schrieb Miklos Szeredi:
The reason is that we want them to park in safe places, ie. where there
are no locks held etc. Thus, these safe places need to be chosen somehow
and since they are not marked throughout the code, we choose the obvious
one. :-)
Why
The reason is that we want them to park in safe places, ie. where there
are no locks held etc. Thus, these safe places need to be chosen somehow
and since they are not marked throughout the code, we choose the obvious
one. :-)
Why shouldn't locks be held?
No locks which are
On Monday, 23 July 2007 15:08, Miklos Szeredi wrote:
The reason is that we want them to park in safe places, ie. where
there
are no locks held etc. Thus, these safe places need to be chosen
somehow
and since they are not marked throughout the code, we choose the obvious
Alan has recently proposed to introduce suspend locks to be acquired during
a suspend/hibernation and such that we can leave uninterruptible tasks that
don't hold any of them.
Sounds sane. A global rwsem could be acquired for read by drivers,
and for write by suspend/hibernate. Just need to
Am Samstag 21 Juli 2007 schrieb Alan Stern:
On Fri, 20 Jul 2007, Oliver Neukum wrote:
We already have a pre-suspend notification available for drivers that
need to allocate large amounts of memory.
Is that facility fine grained enough?
It's a notifier chain that gets called at
On Sun, 22 Jul 2007 [EMAIL PROTECTED] wrote:
You are confusing userspace with user tasks. And not only that,
you often use the term userspace when you should say user mode.
If you want I can explain the differences.
please do, I have been treating all three as the same catagory.
Very
On Mon, 23 Jul 2007, Nigel Cunningham wrote:
Take a step back for a second.
The problem we're facing now is that we're getting some userspace threads,
used in processing I/O, that are functioning as exceptions to the freeze
userspace, then freezeable kernel threads rule. They are only
On Mon, 23 Jul 2007, Alan Stern wrote:
On Sun, 22 Jul 2007 [EMAIL PROTECTED] wrote:
Ok, I did misunderstand you. it sound slike all you need to do to make
sure that locks are not held is to allow system calls to return before
trying to do the suspend/kexec/etc. that sounds like not only a
On Mon, 23 Jul 2007, Oliver Neukum wrote:
Am Montag 23 Juli 2007 schrieb Miklos Szeredi:
The reason is that we want them to park in safe places, ie. where there
are no locks held etc. Thus, these safe places need to be chosen somehow
and since they are not marked throughout the code, we
On Mon, 23 Jul 2007 [EMAIL PROTECTED] wrote:
For one thing, checking for a suspend-in-progress at the beginning of
each and every system call would add overhead to a hot path in the
kernel, one which is already very heavily optimized. People wouldn't
stand for it.
I thought that the
Hi.
On Tuesday 24 July 2007 01:23:15 Alan Stern wrote:
On Mon, 23 Jul 2007, Nigel Cunningham wrote:
Take a step back for a second.
The problem we're facing now is that we're getting some userspace threads,
used in processing I/O, that are functioning as exceptions to the freeze
On Monday, 23 July 2007 23:55, Nigel Cunningham wrote:
Hi.
On Tuesday 24 July 2007 01:23:15 Alan Stern wrote:
On Mon, 23 Jul 2007, Nigel Cunningham wrote:
Take a step back for a second.
The problem we're facing now is that we're getting some userspace
threads,
used in
On Mon, 23 Jul 2007, Nigel Cunningham wrote:
Hi Alan.
On Monday 23 July 2007 01:26:23 Alan Stern wrote:
On Sun, 22 Jul 2007, Nigel Cunningham wrote:
Hi.
On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
It seems that you could still potentially get a failure to freeze if one
Hi.
On Monday 23 July 2007 10:04:43 Paul Mackerras wrote:
> Nigel Cunningham writes:
>
> > I guess I want to persist because all of these issues aren't utterly
> > unsolvable. It's just that we don't have the infrastructure yet to
> > figure out the solutions to these issues trivially. Take, for
Nigel Cunningham writes:
> I guess I want to persist because all of these issues aren't utterly
> unsolvable. It's just that we don't have the infrastructure yet to
> figure out the solutions to these issues trivially. Take, for example,
Ever heard of the halting problem? :) It's not just a
On Monday 23 July 2007 09:09:21 Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 23 July 2007 00:42, Nigel Cunningham wrote:
> > Hi Alan.
> >
> > On Monday 23 July 2007 01:26:23 Alan Stern wrote:
> > > On Sun, 22 Jul 2007, Nigel Cunningham wrote:
> > >
> > > > Hi.
> > > >
> > > > On Sunday 22
Hi,
On Monday, 23 July 2007 00:42, Nigel Cunningham wrote:
> Hi Alan.
>
> On Monday 23 July 2007 01:26:23 Alan Stern wrote:
> > On Sun, 22 Jul 2007, Nigel Cunningham wrote:
> >
> > > Hi.
> > >
> > > On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
> > > > It seems that you could
Hi Alan.
On Monday 23 July 2007 01:26:23 Alan Stern wrote:
> On Sun, 22 Jul 2007, Nigel Cunningham wrote:
>
> > Hi.
> >
> > On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
> > > It seems that you could still potentially get a failure to freeze if one
> > > FUSE process depends on
On Sun, 22 Jul 2007, Alan Stern wrote:
On Sun, 22 Jul 2007, Miklos Szeredi wrote:
The only thing to do is what Rafael has been working on: unfreeze
things, hope the tasks sort themselves out, and try again.
Have we some proof, that this will untangle the freezing tasks in a
limited time?
On Sun, 22 Jul 2007, Alan Stern wrote:
On Sat, 21 Jul 2007 [EMAIL PROTECTED] wrote:
wait a min her, it's possible we are misunderstanding each other.
I'd describe it as: You are misunderstanding me. :-)
very possibly :-)
as I see it.
if userspace can aquire locks that prevent the
On Sun, 22 Jul 2007, Miklos Szeredi wrote:
> > The only thing to do is what Rafael has been working on: unfreeze
> > things, hope the tasks sort themselves out, and try again.
>
> Have we some proof, that this will untangle the freezing tasks in a
> limited time? Or will it just make the
> The only thing to do is what Rafael has been working on: unfreeze
> things, hope the tasks sort themselves out, and try again.
Have we some proof, that this will untangle the freezing tasks in a
limited time? Or will it just make the problem harder to trigger?
Miklos
-
To unsubscribe from
On Sat, 21 Jul 2007 [EMAIL PROTECTED] wrote:
> wait a min her, it's possible we are misunderstanding each other.
I'd describe it as: You are misunderstanding me. :-)
> as I see it.
>
> if userspace can aquire locks that prevent the kernel from shutting off
> (or doing anything else in
On Sun, 22 Jul 2007, Nigel Cunningham wrote:
> Hi.
>
> On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
> > It seems that you could still potentially get a failure to freeze if one
> > FUSE process depends on another, and the one that is frozen second just
> > happens to be waiting
On Sun, 22 Jul 2007, Nigel Cunningham wrote:
Hi.
On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
It seems that you could still potentially get a failure to freeze if one
FUSE process depends on another, and the one that is frozen second just
happens to be waiting on the one
On Sat, 21 Jul 2007 [EMAIL PROTECTED] wrote:
wait a min her, it's possible we are misunderstanding each other.
I'd describe it as: You are misunderstanding me. :-)
as I see it.
if userspace can aquire locks that prevent the kernel from shutting off
(or doing anything else in particular)
The only thing to do is what Rafael has been working on: unfreeze
things, hope the tasks sort themselves out, and try again.
Have we some proof, that this will untangle the freezing tasks in a
limited time? Or will it just make the problem harder to trigger?
Miklos
-
To unsubscribe from this
On Sun, 22 Jul 2007, Miklos Szeredi wrote:
The only thing to do is what Rafael has been working on: unfreeze
things, hope the tasks sort themselves out, and try again.
Have we some proof, that this will untangle the freezing tasks in a
limited time? Or will it just make the problem
On Sun, 22 Jul 2007, Alan Stern wrote:
On Sat, 21 Jul 2007 [EMAIL PROTECTED] wrote:
wait a min her, it's possible we are misunderstanding each other.
I'd describe it as: You are misunderstanding me. :-)
very possibly :-)
as I see it.
if userspace can aquire locks that prevent the
On Sun, 22 Jul 2007, Alan Stern wrote:
On Sun, 22 Jul 2007, Miklos Szeredi wrote:
The only thing to do is what Rafael has been working on: unfreeze
things, hope the tasks sort themselves out, and try again.
Have we some proof, that this will untangle the freezing tasks in a
limited time?
Hi Alan.
On Monday 23 July 2007 01:26:23 Alan Stern wrote:
On Sun, 22 Jul 2007, Nigel Cunningham wrote:
Hi.
On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
It seems that you could still potentially get a failure to freeze if one
FUSE process depends on another, and
Hi,
On Monday, 23 July 2007 00:42, Nigel Cunningham wrote:
Hi Alan.
On Monday 23 July 2007 01:26:23 Alan Stern wrote:
On Sun, 22 Jul 2007, Nigel Cunningham wrote:
Hi.
On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
It seems that you could still potentially get
On Monday 23 July 2007 09:09:21 Rafael J. Wysocki wrote:
Hi,
On Monday, 23 July 2007 00:42, Nigel Cunningham wrote:
Hi Alan.
On Monday 23 July 2007 01:26:23 Alan Stern wrote:
On Sun, 22 Jul 2007, Nigel Cunningham wrote:
Hi.
On Sunday 22 July 2007 02:13:56 Jeremy
Nigel Cunningham writes:
I guess I want to persist because all of these issues aren't utterly
unsolvable. It's just that we don't have the infrastructure yet to
figure out the solutions to these issues trivially. Take, for example,
Ever heard of the halting problem? :) It's not just a matter
Hi.
On Monday 23 July 2007 10:04:43 Paul Mackerras wrote:
Nigel Cunningham writes:
I guess I want to persist because all of these issues aren't utterly
unsolvable. It's just that we don't have the infrastructure yet to
figure out the solutions to these issues trivially. Take, for
On Mon, 23 Jul 2007, Nigel Cunningham wrote:
Hi Alan.
On Monday 23 July 2007 01:26:23 Alan Stern wrote:
On Sun, 22 Jul 2007, Nigel Cunningham wrote:
Hi.
On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
It seems that you could still potentially get a failure to freeze if one
On Sat, 21 Jul 2007, Alan Stern wrote:
On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
How would you prevent tasks from being scheduled? How would you
prevent drivers from deadlocking because in order to put their device
in a low-power state they need to acquire a lock which is held by a
user
On Sun, 22 Jul 2007, Huang, Ying wrote:
On Fri, 2007-07-20 at 08:48 -0700, [EMAIL PROTECTED] wrote:
Backuping target memory before kexec and restoring it after kexec is
planed feature for kexec jump. But I will work on image writing/reading
first.
if we can get a list of what memory is safe
On Fri, 2007-07-20 at 08:48 -0700, [EMAIL PROTECTED] wrote:
> > Backuping target memory before kexec and restoring it after kexec is
> > planed feature for kexec jump. But I will work on image writing/reading
> > first.
>
> if we can get a list of what memory is safe to backup/restore then the
>
Hi.
On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
> It seems that you could still potentially get a failure to freeze if one
> FUSE process depends on another, and the one that is frozen second just
> happens to be waiting on the one that is frozen first when it is frozen.
> I
Hi.
On Sunday 22 July 2007 04:12:22 Miklos Szeredi wrote:
> > It seems that you could still potentially get a failure to freeze if one
> > FUSE process depends on another, and the one that is frozen second just
> > happens to be waiting on the one that is frozen first when it is frozen.
> > I
On Saturday, 21 July 2007 20:12, Miklos Szeredi wrote:
> > It seems that you could still potentially get a failure to freeze if one
> > FUSE process depends on another, and the one that is frozen second just
> > happens to be waiting on the one that is frozen first when it is frozen.
> > I admit
> It seems that you could still potentially get a failure to freeze if one
> FUSE process depends on another, and the one that is frozen second just
> happens to be waiting on the one that is frozen first when it is frozen.
> I admit that this situation is unlikely, and perhaps acceptable.
It
It seems that you could still potentially get a failure to freeze if one
FUSE process depends on another, and the one that is frozen second just
happens to be waiting on the one that is frozen first when it is frozen.
I admit that this situation is unlikely, and perhaps acceptable.
A larger
On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
> > How would you prevent tasks from being scheduled? How would you
> > prevent drivers from deadlocking because in order to put their device
> > in a low-power state they need to acquire a lock which is held by a
> > user task?
>
> you give up on
On Sat, 21 Jul 2007, Nigel Cunningham wrote:
> What am I missing in the following suggested solution?
>
> 1) In the freezer code, we implement a new TIF_LATEFREEZE process flag,
> which,
> when set, causes a userspace process to be frozen with kernel threads
> instead of with userspace ones.
Hi.
On Saturday 21 July 2007 21:44:32 Miklos Szeredi wrote:
> > The problem with FUSE is related to the fact that the freezer can't
> > freeze uninterruptible tasks and we said that perhaps we might avoid
> > it if FUSE was made freezing-aware. Still, no one has gone in this
> > direction and I
> The problem with FUSE is related to the fact that the freezer can't
> freeze uninterruptible tasks and we said that perhaps we might avoid
> it if FUSE was made freezing-aware. Still, no one has gone in this
> direction and I don't know of any plans to do that.
I thought we have fully explored
The problem with FUSE is related to the fact that the freezer can't
freeze uninterruptible tasks and we said that perhaps we might avoid
it if FUSE was made freezing-aware. Still, no one has gone in this
direction and I don't know of any plans to do that.
I thought we have fully explored
Hi.
On Saturday 21 July 2007 21:44:32 Miklos Szeredi wrote:
The problem with FUSE is related to the fact that the freezer can't
freeze uninterruptible tasks and we said that perhaps we might avoid
it if FUSE was made freezing-aware. Still, no one has gone in this
direction and I don't
On Sat, 21 Jul 2007, Nigel Cunningham wrote:
What am I missing in the following suggested solution?
1) In the freezer code, we implement a new TIF_LATEFREEZE process flag,
which,
when set, causes a userspace process to be frozen with kernel threads
instead of with userspace ones. When
On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
How would you prevent tasks from being scheduled? How would you
prevent drivers from deadlocking because in order to put their device
in a low-power state they need to acquire a lock which is held by a
user task?
you give up on the suspend
It seems that you could still potentially get a failure to freeze if one
FUSE process depends on another, and the one that is frozen second just
happens to be waiting on the one that is frozen first when it is frozen.
I admit that this situation is unlikely, and perhaps acceptable.
A larger
It seems that you could still potentially get a failure to freeze if one
FUSE process depends on another, and the one that is frozen second just
happens to be waiting on the one that is frozen first when it is frozen.
I admit that this situation is unlikely, and perhaps acceptable.
It isn't
On Saturday, 21 July 2007 20:12, Miklos Szeredi wrote:
It seems that you could still potentially get a failure to freeze if one
FUSE process depends on another, and the one that is frozen second just
happens to be waiting on the one that is frozen first when it is frozen.
I admit that this
Hi.
On Sunday 22 July 2007 02:13:56 Jeremy Maitin-Shepard wrote:
It seems that you could still potentially get a failure to freeze if one
FUSE process depends on another, and the one that is frozen second just
happens to be waiting on the one that is frozen first when it is frozen.
I admit
Hi.
On Sunday 22 July 2007 04:12:22 Miklos Szeredi wrote:
It seems that you could still potentially get a failure to freeze if one
FUSE process depends on another, and the one that is frozen second just
happens to be waiting on the one that is frozen first when it is frozen.
I admit that
On Fri, 2007-07-20 at 08:48 -0700, [EMAIL PROTECTED] wrote:
Backuping target memory before kexec and restoring it after kexec is
planed feature for kexec jump. But I will work on image writing/reading
first.
if we can get a list of what memory is safe to backup/restore then the
On Sun, 22 Jul 2007, Huang, Ying wrote:
On Fri, 2007-07-20 at 08:48 -0700, [EMAIL PROTECTED] wrote:
Backuping target memory before kexec and restoring it after kexec is
planed feature for kexec jump. But I will work on image writing/reading
first.
if we can get a list of what memory is safe
On Sat, 21 Jul 2007, Alan Stern wrote:
On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
How would you prevent tasks from being scheduled? How would you
prevent drivers from deadlocking because in order to put their device
in a low-power state they need to acquire a lock which is held by a
user
Hi.
On Saturday 21 July 2007 08:43:20 [EMAIL PROTECTED] wrote:
> On Fri, 20 Jul 2007, Alan Stern wrote:
>
> > On Fri, 20 Jul 2007, Jeremy Maitin-Shepard wrote:
> >
> when doing a suspend-to-ram you get to a point where you just don't use
> any userspace.
> >>
> >>> What do you mean?
On Fri, 20 Jul 2007, Alan Stern wrote:
On Fri, 20 Jul 2007, Jeremy Maitin-Shepard wrote:
when doing a suspend-to-ram you get to a point where you just don't use
any userspace.
What do you mean? How can you prevent user tasks from running? That's
basically what the freezer does, and the
Alan Stern <[EMAIL PROTECTED]> writes:
> On Fri, 20 Jul 2007, Jeremy Maitin-Shepard wrote:
>> >> when doing a suspend-to-ram you get to a point where you just don't use
>> >> any userspace.
>>
>> > What do you mean? How can you prevent user tasks from running? That's
>> > basically what the
On Sat, 21 Jul 2007, Rafael J. Wysocki wrote:
On Friday, 20 July 2007 23:39, [EMAIL PROTECTED] wrote:
On Fri, 20 Jul 2007, Rafael J. Wysocki wrote:
On Friday, 20 July 2007 17:36, [EMAIL PROTECTED] wrote:
On Fri, 20 Jul 2007, Jim Crilly wrote:
has
requested the image to be not greater than
On Fri, 20 Jul 2007, Jeremy Maitin-Shepard wrote:
> >> when doing a suspend-to-ram you get to a point where you just don't use
> >> any userspace.
>
> > What do you mean? How can you prevent user tasks from running? That's
> > basically what the freezer does, and the whole point of this
On Fri, 20 Jul 2007, Oliver Neukum wrote:
> > We already have a pre-suspend notification available for drivers that
> > need to allocate large amounts of memory.
>
> Is that facility fine grained enough?
It's a notifier chain that gets called at several points during the
suspend transition.
1 - 100 of 182 matches
Mail list logo