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
* 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
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 d
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 accros
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 accr
* 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
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
> > >
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
regist
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 thin
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 under
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 th
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, susp
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) Encr
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
> >rememb
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 d
>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 return
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
> > > threa
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 "fr
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 t
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 choo
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 tr
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
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 sam
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
> 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
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 ch
> > > 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. :-)
>
> W
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
> 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 to
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
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
FUS
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 matt
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
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 sti
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 an
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? Or
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 kerne
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
> 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 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 particu
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
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 ta
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 t
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 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 admi
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. T
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 s
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 ini
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 th
> 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'
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 initialize ACPI as if the
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 concer
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 initialize ACPI as if the system
just booted up n
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
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 d
> 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!
> from my point of view the ACPI S4 sleep mode has far more in common with
> suspend-to-ram then with the suspend-to-disk that I'm talking about
>
> non-ACPI hibernate
>
> since the box powers off
> it uses zero power while suspended
> another OS could be run before a resume
>
Hi!
> >Part of the problem here is that ACPI already has its own terminology,
> >and you're trying to invent a new one instead of using the existing
> >one.
> >
> >I agree, it would be good to have a non-ACPI-specific hibernation mode,
> >something which would look to ACPI like a normal shutdown.
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? Ho
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 wh
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 f
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 appro
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. O
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 50% of RAM. In that
On Friday, 20 July 2007 23:33, Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> >> Or add a small bit of infrastructure that errors writes at make_request
> >> if you don't have a magic "i am a direct block device write from
> >> userspace" flag on t
On Friday, 20 July 2007 23:34, [EMAIL PROTECTED] wrote:
> On Fri, 20 Jul 2007, Alan Stern wrote:
>
> > On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
> >
> >>> Userspace can submit I/O requests. Someone will have to audit every
> >>> driver to make sure that such I/O requests don't cause a quiesced
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 50% of RAM. In that case you
have
to free some memory _before_ identifying memory to save and you must n
On Fri, 20 Jul 2007, Alan Stern wrote:
On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
Userspace can submit I/O requests. Someone will have to audit every
driver to make sure that such I/O requests don't cause a quiesced
device to become active. If the device is active, it will make the
memory
On Friday, 20 July 2007 18:15, Alan Stern wrote:
> On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
>
> > or the userspace helper functions that setup the instructions for the
> > hibernate warn you if you are telling it to mount a filesystem that it
> > knows is ext3 and is in use by the system goi
Alan Stern <[EMAIL PROTECTED]> writes:
> On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
>> > Userspace can submit I/O requests. Someone will have to audit every
>> > driver to make sure that such I/O requests don't cause a quiesced
>> > device to become active. If the device is active, it will mak
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 50% of RAM. In that case you
> >>> have
> >>> to free some memory _before_ identifying memory to save and you must not
> >>> race with appl
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes:
[snip]
>> Or add a small bit of infrastructure that errors writes at make_request
>> if you don't have a magic "i am a direct block device write from
>> userspace" flag on the bio.
>>
>> The hibernate may fail, but you don't corrupt the media.
>>
Am Freitag 20 Juli 2007 schrieb Alan Stern:
> On Fri, 20 Jul 2007, Oliver Neukum wrote:
>
> > Am Freitag 20 Juli 2007 schrieb Alan Stern:
> > > Some drivers need the ability to schedule. Some will need the ability
> > > to allocate memory (although GFP_ATOMIC is probably sufficient). Some
> >
On Friday, 20 July 2007 16:48, Huang, Ying wrote:
> On Fri, 2007-07-20 at 09:01 -0500, Milton Miller wrote:
> > Simplifying kjump: the proposal for v3.
> >
> > The current code is trying to use crash dump area as a safe, reserved
> > area to run the second kernel. However, that means that the k
On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
> > Userspace can submit I/O requests. Someone will have to audit every
> > driver to make sure that such I/O requests don't cause a quiesced
> > device to become active. If the device is active, it will make the
> > memory snapshot inconsistent with
On Friday, 20 July 2007 19:31, Jeremy Maitin-Shepard wrote:
> Milton Miller <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> (7) how to avoid corrupting filesystems mounted by the hibernated kernel
> >>>
> >>> I didn't realize this was a discussion item. I thought the options were
> >>> clear, fo
On Friday, 20 July 2007 18:56, Milton Miller wrote:
> On Jul 20, 2007, at 6:17 AM, Rafael J. Wysocki wrote:
> > On Friday, 20 July 2007 01:07, [EMAIL PROTECTED] wrote:
> >> On Thu, 19 Jul 2007, Rafael J. Wysocki wrote:
> >>> On Thursday, 19 July 2007 17:46, Milton Miller wrote:
> The currently
On Friday, 20 July 2007 18:08, Milton Miller wrote:
> On Jul 19, 2007, at 3:28 PM, Rafael J. Wysocki wrote:
> > On Thursday, 19 July 2007 17:46, Milton Miller wrote:
> >> The currently identified problems under discussion include:
> >> (1) how to interact with acpi to enter into S4.
> >> (2) how to
On Fri, 20 Jul 2007, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
We can't do this unless we have frozen tasks (this way, or another)
before
carrying out the entire operation.
What can't we do? We've already worked with the drivers to quesce the
hardware and put any informat
On Fri, 20 Jul 2007, Oliver Neukum wrote:
> Am Freitag 20 Juli 2007 schrieb Alan Stern:
> > Some drivers need the ability to schedule. Some will need the ability
> > to allocate memory (although GFP_ATOMIC is probably sufficient). Some
> > will need timers to run.
>
> Some will have to reques
Am Freitag 20 Juli 2007 schrieb Alan Stern:
> Some drivers need the ability to schedule. Some will need the ability
> to allocate memory (although GFP_ATOMIC is probably sufficient). Some
> will need timers to run.
Some will have to request firmware. It can add up to some megabytes.
In additio
On Fri, 20 Jul 2007, Milton Miller wrote:
> > That's exactly my point. As far as I know nobody has done a survey,
> > but I bet you'd find _many_ drivers are buggy either in this way or the
> > converse (forcing an I/O request to fail immediately instead of waiting
> > until the suspend is over w
On Fri, 20 Jul 2007, Milton Miller wrote:
On Jul 20, 2007, at 6:17 AM, Rafael J. Wysocki wrote:
On Friday, 20 July 2007 01:07, [EMAIL PROTECTED] wrote:
> On Thu, 19 Jul 2007, Rafael J. Wysocki wrote:
> > On Thursday, 19 July 2007 17:46, Milton Miller wrote:
> > > The currently identified pr
On Jul 20, 2007, at 1:17 PM, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
On Jul 20, 2007, at 11:20 AM, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
We can't do this unless we have frozen tasks (this way, or another)
before
carrying out the entire operation.
On Fri, 20 Jul 2007, Milton Miller wrote:
> On Jul 20, 2007, at 11:20 AM, Alan Stern wrote:
> > On Fri, 20 Jul 2007, Milton Miller wrote:
> >>> We can't do this unless we have frozen tasks (this way, or another)
> >>> before
> >>> carrying out the entire operation.
> >>
> >> What can't we do? We
On Jul 20, 2007, at 11:20 AM, Alan Stern wrote:
On Fri, 20 Jul 2007, Milton Miller wrote:
We can't do this unless we have frozen tasks (this way, or another)
before
carrying out the entire operation.
What can't we do? We've already worked with the drivers to quesce
the
hardware and put any
Milton Miller <[EMAIL PROTECTED]> writes:
[snip]
(7) how to avoid corrupting filesystems mounted by the hibernated kernel
>>>
>>> I didn't realize this was a discussion item. I thought the options were
>>> clear, for some filesystem types you can mount them read-only, but for
>>> ext3 (and
On Jul 20, 2007, at 6:17 AM, Rafael J. Wysocki wrote:
On Friday, 20 July 2007 01:07, [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007, Rafael J. Wysocki wrote:
On Thursday, 19 July 2007 17:46, Milton Miller wrote:
The currently identified problems under discussion include:
(1) how to interact with
On Fri, 20 Jul 2007 [EMAIL PROTECTED] wrote:
> or the userspace helper functions that setup the instructions for the
> hibernate warn you if you are telling it to mount a filesystem that it
> knows is ext3 and is in use by the system going to sleep.
One can argue that the ext3 implementation is
On Fri, 20 Jul 2007, Milton Miller wrote:
> > We can't do this unless we have frozen tasks (this way, or another)
> > before
> > carrying out the entire operation.
>
> What can't we do? We've already worked with the drivers to quesce the
> hardware and put any information to resume the device
On Jul 19, 2007, at 3:28 PM, Rafael J. Wysocki wrote:
On Thursday, 19 July 2007 17:46, Milton Miller wrote:
The currently identified problems under discussion include:
(1) how to interact with acpi to enter into S4.
(2) how to identify which memory needs to be saved
(3) how to communicate where
On Fri, 20 Jul 2007, Huang, Ying wrote:
On Fri, 2007-07-20 at 09:01 -0500, Milton Miller wrote:
Simplifying kjump: the proposal for v3.
The current code is trying to use crash dump area as a safe, reserved
area to run the second kernel. However, that means that the kernel
has to be linked s
On Fri, 20 Jul 2007, Milton Miller wrote:
On Jul 19, 2007, at 12:31 PM, [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007, Milton Miller wrote:
>
> This means that the first kernel will need to know why it got resumed.
> Was the system powered off, and this is the resume from the user? Or
>
1 - 100 of 208 matches
Mail list logo
