Hi!
Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is
considered by the freezer as unfreezeable. However, there may be a race
between the freezer and the delivery of the continuation signal to the task
resulting in the task running after we have finished freezing
Hi!
Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is
considered by the freezer as unfreezeable. However, there may be a race
between the freezer and the delivery of the continuation signal to the task
resulting in the task running after we have finished freezing
Hi,
On Tuesday, 5 December 2006 11:34, Pavel Machek wrote:
Hi!
Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is
considered by the freezer as unfreezeable. However, there may be a race
between the freezer and the delivery of the continuation signal to the task
On Tuesday, 5 December 2006 06:43, David Brownell wrote:
[ off $SUBJECT ]
On Monday 04 December 2006 11:44 am, Pavel Machek wrote:
But I think I'll need to add TIF_FROZEN for all architectures, because
suspend
to RAM is supposed to work on all of them, isn't it?
Well, yes, it
Hi!
Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is
considered by the freezer as unfreezeable. However, there may be a race
between the freezer and the delivery of the continuation signal to the task
resulting in the task running after we have finished
Hi.
On Mon, 2006-12-04 at 09:10 +0100, Stefan Seyfried wrote:
On Sat, Dec 02, 2006 at 03:41:52PM +1100, Nigel Cunningham wrote:
Hi.
On Fri, 2006-12-01 at 08:39 +0100, Stefan Seyfried wrote:
So if somebody submits a patch that implements a reset_signature
program,
i'll include
On Tue, Dec 05, 2006 at 10:28:08PM +1100, Nigel Cunningham wrote:
Since you mentioned it, what's they point to using these ugly, looong
uuids? /dev/hda2 is so much simpler and easier to read for mere humans.
Try updating a system using, say, the piix driver for the harddisk to the
new libata
Nigel Cunningham wrote:
But this engineer should also know if he depends on the UUID of the swap
partition to find it. If he does not, he can simply do a mkswap to reset
the signature.
Since you mentioned it, what's they point to using these ugly, looong
uuids? /dev/hda2 is so much
Hi!
Actually, what do you think about this patch? It removes special
handling of TASK_TRACED, and should do the trick, too...
Well, I don't think so,
@@ -1702,7 +1702,9 @@ finish_stop(int stop_count)
read_unlock(tasklist_lock);
}
- schedule();
+ do {
Hi!
Actually, what do you think about this patch? It removes special
handling of TASK_TRACED, and should do the trick, too...
I was surprised, but the patch seems to work okay. Can you replace
your 1/2 with this one, and see what breaks?
I don't think anything will _visibly_
Hi,
On Tuesday, 5 December 2006 15:13, Pavel Machek wrote:
Hi!
Actually, what do you think about this patch? It removes special
handling of TASK_TRACED, and should do the trick, too...
Well, I don't think so,
@@ -1702,7 +1702,9 @@ finish_stop(int stop_count)
Hi,
On Tuesday, 5 December 2006 15:26, Rafael J. Wysocki wrote:
On Tuesday, 5 December 2006 15:12, Pavel Machek wrote:
Hi!
Actually, what do you think about this patch? It removes special
handling of TASK_TRACED, and should do the trick, too...
I was surprised, but the
Hi!
(2) the race between the delivery of
the continuation signal and the freezer is damn hard to trigger (still I
think
I can wirte some artificial code that would trigger this, although it
would
involve a kernel thread sending SIGCONT to a user space process - provided
it's
On Tuesday, 5 December 2006 22:03, Rafael J. Wysocki wrote:
Okay, I have replaced my [1/2] with the patch below ...
On Tuesday, 5 December 2006 11:34, Pavel Machek wrote:
--snip--
... and it fails to freeze processes if there's a stopped task (to verify,
run vi, press ^Z, and try to
On Tuesday, 5 December 2006 23:19, Pavel Machek wrote:
Hi!
Actually, what do you think about this patch? It removes special
handling of TASK_TRACED, and should do the trick, too...
diff --git a/kernel/power/process.c b/kernel/power/process.c
index 7bcc976..d56e494 100644
---
Hi,
On Tuesday, 5 December 2006 23:45, Rafael J. Wysocki wrote:
On Tuesday, 5 December 2006 23:36, Pavel Machek wrote:
Hi!
... and it fails to freeze processes if there's a stopped task (to verify,
run vi, press ^Z, and try to suspend).
Ok, here's better version. (Notice it only
Hi!
...after resume.
This is because of how signal_wake_up() works, I think..
But I think it is right approach.
Okay, with the appended patch applied everything seems to work and I don't
see any undesirable side-effects.
I promise to try it... tommorow. Looks very good to me.
But I am seeing the total opposite: PalmOS is doing all of this much better
than it's main competitor. It is enough to use the Internet, Office
applications, keep track of patients, in such a way that it does not get in the
way. I remember Harvard had an expermental online tool that did
18 matches
Mail list logo
