Nick Piggin wrote:
Your one liner would fix the problem too, of course. The important
thing at this stage is that it gets fixed for 2.6.11.
Sorry, have been off the net last week.
Thank you for the patches. Have tested Ingo's one liner.
It works fine for me, as expected.
Bodo
-
To unsubscribe from
Nick Piggin wrote:
Your one liner would fix the problem too, of course. The important
thing at this stage is that it gets fixed for 2.6.11.
Sorry, have been off the net last week.
Thank you for the patches. Have tested Ingo's one liner.
It works fine for me, as expected.
Bodo
-
To unsubscribe from
Nick Piggin wrote:
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules off, and
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules off, and wait_task_inactive did
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> When a task is put to sleep, it is dequeued from the runqueue
> while it is still running. The problem is that the runqueue
> lock can be dropped and retaken in schedule() before the task
> actually schedules off, and wait_task_inactive did not account
Nick Piggin wrote:
Something like the following (untested) extension of Bodo's work
could be the minimal fix for 2.6.11. As I've said though, I'd
consider it a hack and prefer to do something about the locking.
That could be done after 2.6.11 though. Depends how you feel.
I think this is the right
Nick Piggin wrote:
Something like the following (untested) extension of Bodo's work
could be the minimal fix for 2.6.11. As I've said though, I'd
consider it a hack and prefer to do something about the locking.
That could be done after 2.6.11 though. Depends how you feel.
I think this is the right
* Nick Piggin [EMAIL PROTECTED] wrote:
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules off, and wait_task_inactive did not account
for
Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules off, and wait_task_inactive did not
Nick Piggin wrote:
Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules off, and
Nick Piggin wrote:
Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew, IMO this is another bug to hold 2.6.11 for.
Sure. I wouldn't consider Bodo's patch to be the one to use though..
No. Something similar could be done that works on all architectures
and all wait_task_inactive
Bodo Stroesser wrote:
Nick Piggin wrote:
Bodo Stroesser wrote:
I don't see how this could help because AFAIKS, child->saving is only
set and cleared while the runqueue is locked. And the same runqueue lock
is taken by wait_task_inactive.
Sorry, that not right. There are some routines called by
Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
Bodo Stroesser wrote:
Nick Piggin wrote:
Bodo Stroesser wrote:
I don't see how this could help because AFAIKS, child->saving is only
set and cleared while the runqueue is locked. And the same runqueue lock
is taken by
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> Bodo Stroesser wrote:
> > Nick Piggin wrote:
> >
> >> Bodo Stroesser wrote:
>
> >> I don't see how this could help because AFAIKS, child->saving is only
> >> set and cleared while the runqueue is locked. And the same runqueue lock
> >> is taken by
Nick Piggin wrote:
Bodo Stroesser wrote:
Working with the new UML skas0 mode on my Xeon HT host, sporadically I
saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment
register,
that had the wrong contents.
This again is caused by a problem in
Nick Piggin wrote:
Bodo Stroesser wrote:
Working with the new UML skas0 mode on my Xeon HT host, sporadically I
saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment
register,
that had the wrong contents.
This again is caused by a problem in
Nick Piggin [EMAIL PROTECTED] wrote:
Bodo Stroesser wrote:
Nick Piggin wrote:
Bodo Stroesser wrote:
I don't see how this could help because AFAIKS, child-saving is only
set and cleared while the runqueue is locked. And the same runqueue lock
is taken by wait_task_inactive.
Andrew Morton wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
Bodo Stroesser wrote:
Nick Piggin wrote:
Bodo Stroesser wrote:
I don't see how this could help because AFAIKS, child-saving is only
set and cleared while the runqueue is locked. And the same runqueue lock
is taken by wait_task_inactive.
Bodo Stroesser wrote:
Nick Piggin wrote:
Bodo Stroesser wrote:
I don't see how this could help because AFAIKS, child-saving is only
set and cleared while the runqueue is locked. And the same runqueue lock
is taken by wait_task_inactive.
Sorry, that not right. There are some routines called by
Nick Piggin wrote:
Andrew Morton wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
Andrew, IMO this is another bug to hold 2.6.11 for.
Sure. I wouldn't consider Bodo's patch to be the one to use though..
No. Something similar could be done that works on all architectures
and all wait_task_inactive
Bodo Stroesser wrote:
Working with the new UML skas0 mode on my Xeon HT host, sporadically I saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment
register,
that had the wrong contents.
This again is caused by a problem in the host linux: A
Working with the new UML skas0 mode on my Xeon HT host, sporadically I saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment register,
that had the wrong contents.
This again is caused by a problem in the host linux: A ptraced child going to
stop
Working with the new UML skas0 mode on my Xeon HT host, sporadically I saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment register,
that had the wrong contents.
This again is caused by a problem in the host linux: A ptraced child going to
stop
Bodo Stroesser wrote:
Working with the new UML skas0 mode on my Xeon HT host, sporadically I saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment
register,
that had the wrong contents.
This again is caused by a problem in the host linux: A
24 matches
Mail list logo
