On Tue, 2007-09-25 at 13:32 +0530, Kamalesh Babulal wrote:
> Balbir Singh wrote:
> > On 9/25/07, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> >> Exactly same call trace is produced over IA64 Madison (up to 9M cache)
> >> with 8 cpu's.
> >> --
> >
> > Hi, Kamalesh,
> >
> > Could you please repro
Balbir Singh wrote:
> On 9/25/07, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>> Exactly same call trace is produced over IA64 Madison (up to 9M cache) with
>> 8 cpu's.
>> --
>
> Hi, Kamalesh,
>
> Could you please reproduce the problem or share the steps to reproduce
> the problem?
>
> Thanks,
On 9/25/07, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Exactly same call trace is produced over IA64 Madison (up to 9M cache) with 8
> cpu's.
> --
Hi, Kamalesh,
Could you please reproduce the problem or share the steps to reproduce
the problem?
Thanks,
Balbir
-
To unsubscribe from this list:
* Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
> Taking a quick look at [__]{en|de|queue_entity() and the functions
> they call, I see something suspicious in set_leftmost() in
> sched_fair.c:
>
> static inline void
> set_leftmost(struct cfs_rq *cfs_rq, struct rb_node *leftmost)
> {
> s
Lee Schermerhorn wrote:
> I looked around on the MLs for mention of this, but didn't find anything
> that appeared to match.
>
> Platform: HP rx8620 - 16-cpu/32GB/4-node ia64 [Madison]
>
> 2.6.23-rc7-mm1 broken out -- panic occurs when git-sched.patch pushed:
>
> Unable to handle kernel NULL po
5 matches
Mail list logo