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 exactly
Hi again.
On Tue, 2006-12-05 at 11:51 +, Matt Sealey wrote:
> 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 menti
Hi.
On Tue, 2006-12-05 at 23:18 +0100, Rafael J. Wysocki wrote:
> > > It happens because we shouldn't count the stopped task as freezeable any
> > > more after we've set PF_FREEZE for it and we can fix that by adding
> > >
> > > if (p->state == TASK_STOPPED && freezing(p))
> > > conti
Hi guys.
On Wed, 2006-12-06 at 00:45 +0100, Pavel Machek wrote:
> 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
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
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. (N
Hi,
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 differs by one bit ;-).
>
> Ok, something is still weird. B
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 differs by one bit ;-).
Ok, something is still weird. Bash reports spurious...
[2]+ Stopped vi
...after resume.
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..d56e49
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
> > --- a/kernel/power/process.c
> > +++ b/kernel/power/proc
On Tuesday, 5 December 2006 22:26, Rafael J. Wysocki wrote:
> 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-->
>
> Well, now the task that was stopped b
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 s
Hi,
Okay, I have replaced my [1/2] with the patch below ...
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
Hi,
On Tuesday, 5 December 2006 16:27, Pavel Machek wrote:
> 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
> > > > wou
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 -
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
Hi,
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 patch seems to work okay. Can you replace
> > > your 1
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!
> > > 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 _v
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);
> > }
> >
> > - schedu
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
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
Hi,
On Tuesday, 5 December 2006 12:24, 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
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,
> >
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
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?
> >
> > W
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 th
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
29 matches
Mail list logo
