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
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 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'
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
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.
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
>
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 applications that attempt to allocate memory while you're doing
it.
I disagree a little bi
On Fri, 20 Jul 2007, 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 acpi
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 specially to run in the reserved a
On Jul 19, 2007, at 12:31 PM, [EMAIL PROTECTED] wrote:
On Thu, 19 Jul 2007, Milton Miller wrote:
(2) Upon start-up (by which I mean what happens after the user has
pressed
the power button or something like that):
* check if the image is present (and valid) _without_ enabling
ACPI (we
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 acpi to enter into S4.
> >> (2) ho
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 acpi to enter into S4.
(2) how to identify which memory needs to be saved
(3) how to communicate where to sav
On Thursday, 19 July 2007 17:46, Milton Miller wrote:
>
> Hi. I've found this thread from the kjump thread on the kexec mailing
> list. I'll respond to that one later, but I wanted to respond to
> several messages in this thread. [Actually, there is a brief outline
> of a response near the
On Thu, 19 Jul 2007, Milton Miller wrote:
(2) Upon start-up (by which I mean what happens after the user has pressed
the power button or something like that):
* check if the image is present (and valid) _without_ enabling ACPI (we
don't
do that now, but I see no reason for not doi
91 matches
Mail list logo
