[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
| I did some initial testing on your patchset (minus patch 5) and noticed
| that it seems to be missing the patch to address kill -1 semantics
| (here is the earlier version).
I thought I double checked, but still missed the other patchset that
addresse
> [ ... ]
>
> [] rb_erase+0x300/0x7e0
> [] __dequeue_entity+0x70/0xa0
> [] set_next_entity+0x40/0xa0
> [] set_curr_task_fair+0x40/0xa0
> [] sched_move_task+0x2d0/0x340
> [] cpu_cgroup_attach+0x20/0x40
>
> [ ... ]
argh... it's a consequence of the 'current is not kept within the tree" indeed.
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 13:56:14 +0300
> The _find calls calculate the hash value using the
> xfrm_state_hmask, without the xfrm_state_lock. But the
> value of this mask can change in the _resize call under
> the state_lock, so we risk to fail in finding
On 14/12/2007, Dhaval Giani <[EMAIL PROTECTED]> > >
> Actually no, its another bug. Thanks for the program!
>
Humm... this crash is very likely to be caused by the same bug. It
just reveals itself in a different place, but effectivelly the pattern
looks similar. Anyway, the rb-tree gets corrupted.
Serge E. Hallyn wrote:
From c257cb67ce00c8769730cfa92379a53009d99b28 Mon Sep 17 00:00:00 2001
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed, 5 Dec 2007 14:02:45 -0800
Subject: [RFC] [PATCH -mm] reiser4: replace uid==0 check with capability
Reiser4 gives root some reserved blocks. Repl
On Fri, Dec 14, 2007 at 09:06:07PM +0530, Dhaval Giani wrote:
> On Fri, Dec 14, 2007 at 11:24:28PM +0900, [EMAIL PROTECTED] wrote:
> > >> just to be sure SMP does matter here (most likely yes, I guess).
> > >>
> > >
> > >NUMA? I am not able to reproduce it here locally on an x86 8 CPU box.
> > >
>
On Fri, Dec 14, 2007 at 11:24:28PM +0900, [EMAIL PROTECTED] wrote:
> >> just to be sure SMP does matter here (most likely yes, I guess).
> >>
> >
> >NUMA? I am not able to reproduce it here locally on an x86 8 CPU box.
> >
> yes. I used NUMA. 2 Nodes/4CPU x 2
>
OK, I got hold of an IA64 box, non
>> just to be sure SMP does matter here (most likely yes, I guess).
>>
>
>NUMA? I am not able to reproduce it here locally on an x86 8 CPU box.
>
yes. I used NUMA. 2 Nodes/4CPU x 2
Hmm..
Thanks,
-Kame
___
Containers mailing list
[EMAIL PROTECTED]
https
On Fri, Dec 14, 2007 at 01:47:13PM +0100, Dmitry Adamushko wrote:
> On 14/12/2007, KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> > Here is much easier test.
> > (I'm sorry I'll be absent tomorrow.)
> >
> > the number of cpus is 8. ia64/NUMA.
> >
> > The hang occurs when the number of tasks is not
-
>have you tried :
>
>[EMAIL PROTECTED] testpro]#taskset 01 ./batech-test.sh
>
yes
>hang?
>
no.
>just to be sure SMP does matter here (most likely yes, I guess).
>
maybe. As far as I tested, there was no hang if the number of cpus is 1.
Regards,
-Kame
___
On 14/12/2007, KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> Here is much easier test.
> (I'm sorry I'll be absent tomorrow.)
>
> the number of cpus is 8. ia64/NUMA.
>
> The hang occurs when the number of tasks is not smaller than available cpus.
> Can be a hint ?
>
> [ ... ]
>
> [EMAIL PROTECTED]
On Fri, Dec 14, 2007 at 07:58:37PM +0900, KAMEZAWA Hiroyuki wrote:
> Here is much easier test.
Thanks for the test! Let me see if I can reproduce it here.
--
regards,
Dhaval
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.o
Here is much easier test.
(I'm sorry I'll be absent tomorrow.)
the number of cpus is 8. ia64/NUMA.
The hang occurs when the number of tasks is not smaller than available cpus.
Can be a hint ?
==
[EMAIL PROTECTED] testpro]# cat yield.c
#include
int main()
{
while (1)
sch
(Cc:-ed other folks as well)
* KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> Hi,
>
> While I was testing 2.6.24-rc5-mm1's fair group scheduler (with cgroup),
> the system hangs. please confirm. it's reproducible on my box.
>
> My test program is attached.
>
> What happens:
> the system han
(Cc:-ed other folks as well)
* KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> Tested again, and got NULL access and panic.
>
> This is my guess from stack dump. (raw stack dump is attached below.)
> ==
>
> static struct task_struct *pick_next_task_fair(struct rq *rq)
> {
> struct cfs_r
Tested again, and got NULL access and panic.
This is my guess from stack dump. (raw stack dump is attached below.)
==
static struct task_struct *pick_next_task_fair(struct rq *rq)
{
struct cfs_rq *cfs_rq = &rq->cfs;
struct sched_entity *se;
if (unlikely(!cfs_rq->nr_runnin
16 matches
Mail list logo
