Hi!
> > > > > > > Two things which I think would be nice to consider are:
> > > > > > >1) Encryption - I'd actually prefer if my luks device did not
> > > > > > >remember the key accross a hibernation;
> >
> > Why exactly (assuming that the hibernation image is encrypted)?
>
> I was
Hi!
Two things which I think would be nice to consider are:
1) Encryption - I'd actually prefer if my luks device did not
remember the key accross a hibernation;
Why exactly (assuming that the hibernation image is encrypted)?
I was assuming the hibernation
* Rafael J. Wysocki ([EMAIL PROTECTED]) wrote:
> On Sunday, 12 August 2007 01:43, Dr. David Alan Gilbert wrote:
> > * Pavel Machek ([EMAIL PROTECTED]) wrote:
> > > Hi!
> > >
> > > > > > Two things which I think would be nice to consider are:
> > > > > >1) Encryption - I'd actually prefer if
* Rafael J. Wysocki ([EMAIL PROTECTED]) wrote:
On Sunday, 12 August 2007 01:43, Dr. David Alan Gilbert wrote:
* Pavel Machek ([EMAIL PROTECTED]) wrote:
Hi!
Two things which I think would be nice to consider are:
1) Encryption - I'd actually prefer if my luks device did not
Hello,
We already have a sample at:
http://wiki.tuxonice.net/EncryptedSwapAndRoot
It stores the keys of mounted partitions on an encrypted swap, which
has the same encryption with different keyset.
It also shows how to resume from encrypted swap, And you can
optionally store the keys on hardware
On 8/11/07, Dr. David Alan Gilbert <[EMAIL PROTECTED]> wrote:
> * Pavel Machek ([EMAIL PROTECTED]) wrote:
> > Hi!
> >
> > > > > Two things which I think would be nice to consider are:
> > > > >1) Encryption - I'd actually prefer if my luks device did not
> > > > >remember the key
On Sunday, 12 August 2007 01:43, Dr. David Alan Gilbert wrote:
> * Pavel Machek ([EMAIL PROTECTED]) wrote:
> > Hi!
> >
> > > > > Two things which I think would be nice to consider are:
> > > > >1) Encryption - I'd actually prefer if my luks device did not
> > > > >remember the key
On 8/11/07, Dr. David Alan Gilbert [EMAIL PROTECTED] wrote:
* Pavel Machek ([EMAIL PROTECTED]) wrote:
Hi!
Two things which I think would be nice to consider are:
1) Encryption - I'd actually prefer if my luks device did not
remember the key accross a hibernation; I
Hello,
We already have a sample at:
http://wiki.tuxonice.net/EncryptedSwapAndRoot
It stores the keys of mounted partitions on an encrypted swap, which
has the same encryption with different keyset.
It also shows how to resume from encrypted swap, And you can
optionally store the keys on hardware
On Sunday, 12 August 2007 01:43, Dr. David Alan Gilbert wrote:
* Pavel Machek ([EMAIL PROTECTED]) wrote:
Hi!
Two things which I think would be nice to consider are:
1) Encryption - I'd actually prefer if my luks device did not
remember the key accross a hibernation;
* Pavel Machek ([EMAIL PROTECTED]) wrote:
> Hi!
>
> > > > Two things which I think would be nice to consider are:
> > > >1) Encryption - I'd actually prefer if my luks device did not
> > > >remember the key accross a hibernation; I want to be forced to
> > > >reenter the
* Pavel Machek ([EMAIL PROTECTED]) wrote:
Hi!
Two things which I think would be nice to consider are:
1) Encryption - I'd actually prefer if my luks device did not
remember the key accross a hibernation; I want to be forced to
reenter the phrase. However I
Hi!
> > > Two things which I think would be nice to consider are:
> > >1) Encryption - I'd actually prefer if my luks device did not
> > >remember the key accross a hibernation; I want to be forced to
> > >reenter the phrase. However I don't know what the best thing
> > >
Hi!
Two things which I think would be nice to consider are:
1) Encryption - I'd actually prefer if my luks device did not
remember the key accross a hibernation; I want to be forced to
reenter the phrase. However I don't know what the best thing
to do to
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
Hi,
Sorry for joining late, just a small annotation:
On Tue, Jul 17, 2007 at 01:18:13PM -0700, [EMAIL PROTECTED] wrote:
> non-ACPI hibernate
>
> since the box powers off
> it uses zero power while suspended
> another OS could be run before a resume
> hardware can be swapped,
Hi,
Sorry for joining late, just a small annotation:
On Tue, Jul 17, 2007 at 01:18:13PM -0700, [EMAIL PROTECTED] wrote:
non-ACPI hibernate
since the box powers off
it uses zero power while suspended
another OS could be run before a resume
hardware can be swapped, suspend
On Sunday, 29 July 2007 08:53, Vojtech Pavlik wrote:
> On Mon, Jul 16, 2007 at 12:38:11AM +0200, Rafael J. Wysocki wrote:
>
> > > Or the user unplugs their flash drive after hibernation rather than
> > > before.
> > >
> > > Two things which I think would be nice to consider are:
> > >1)
On Mon, Jul 16, 2007 at 12:38:11AM +0200, Rafael J. Wysocki wrote:
> > Or the user unplugs their flash drive after hibernation rather than before.
> >
> > Two things which I think would be nice to consider are:
> >1) Encryption - I'd actually prefer if my luks device did not
> >
On Mon, Jul 16, 2007 at 12:38:11AM +0200, Rafael J. Wysocki wrote:
Or the user unplugs their flash drive after hibernation rather than before.
Two things which I think would be nice to consider are:
1) Encryption - I'd actually prefer if my luks device did not
remember the
On Sunday, 29 July 2007 08:53, Vojtech Pavlik wrote:
On Mon, Jul 16, 2007 at 12:38:11AM +0200, Rafael J. Wysocki wrote:
Or the user unplugs their flash drive after hibernation rather than
before.
Two things which I think would be nice to consider are:
1) Encryption - I'd
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 Sat, 21 Jul 2007, Pavel Machek wrote:
So it will be break at least battery status and "AC plugged in"
status, because those are handled by ACPI and we do not know how to
control them by hand.
It seems that it should be possible to initialize ACPI as if the system
just booted up normally.
Hi!
> >>>So it will be break at least battery status and "AC plugged in"
> >>>status, because those are handled by ACPI and we do not know how to
> >>>control them by hand.
> >>
> >>It seems that it should be possible to initialize ACPI as if the system
> >>just booted up normally. Then battery
On Sat, 21 Jul 2007, Pavel Machek wrote:
Hi!
Pavel Machek <[EMAIL PROTECTED]> writes:
[snip]
So it will be break at least battery status and "AC plugged in"
status, because those are handled by ACPI and we do not know how to
control them by hand.
It seems that it should be possible to
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
1 - 100 of 414 matches
Mail list logo
