Hi Keith,

Thanks again for the quick response.

Sounds like moving forward to the 2.4.20 kernel that comes with MontaVista
3.1 Pro for arm_xscale and applying the kdb-v4.3-2.4.20-common-1.bz2 and
kdb-v4.3-2.4.20-xscale-1.bz2 patches is our best bet.

We were using the 2.4.19 kernel because we had one that was already
patched for xscale and had done other work on top of that kernel that
would have to be redone if we switched kernels.  We were not aware of the
information you have provided below when we decided to add kdb to the
kernel.

Looks like Jan has responded as well so I'll sign off for now... thanks
again. :)


On Fri, 18 Jun 2004, Keith Owens wrote:

> Date: Fri, 18 Jun 2004 08:30:48 +1000
> From: Keith Owens <[EMAIL PROTECTED]>
> To: marks <[EMAIL PROTECTED]>
> Cc: Jan Rovins <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: Fw: xscale arm kernel 2.4.19-rmk7-ds3 with kdb integrated -
>     question/help
>
> On Thu, 17 Jun 2004 14:55:08 -0700 (PDT),
> marks <[EMAIL PROTECTED]> wrote:
> >I've looked at the kernel code a bit (my first experience with kernel code
> >and kdb so bear with me).  I don't find anything named kdb_task_has_cpu
> >but I do see a task_has_cpu.  I'm attempting to determine if any of the
> >applied patches changed the definition of task_has_cpu or any code that
> >uses task_has_cpu.  Is task_has_cpu the correct item for me to be
> >examining?
>
> I was looking at kdb v4.2 for xscale on 2.4.20, you appear to be
> working on kdb v4.0 for 2.4.19.  Why such an old kernel/kdb?
>
> kdb_task_has_cpu() was added in kdb v4.1 to workaround several
> scheduler bugs that made task_has_cpu() unreliable.  You are hitting
> one of these scheduler bugs, task_has_cpu() is always returning true on
> your system.
>
> >Also, I'd like to understand the output from the "ps" command in kdb a bit
> >better.  From what I see there is only one task in state "R" (running).
> >All other tasks are in state "S" or state "D" (see the State column).
> >This seems to me to indicate only one active task.
> >
> >Which column are you looking at that shows "All the tasks are marked as
> >being active on cpu 0"?
>
> The column with a heading of '[*]', which marks the task as owning the
> cpu (task_has_cpu).  You can have multiple tasks marked R (for running
> _or_ runnable) but only one task can be active on a cpu at a time.
>
> Upgrade to kdb v4.2 for xscale on 2.4.20 if possible.  If that is not
> possible then you will have to make task_has_cpu() reliable on your
> arch.  From memory, the problem is that task_has_cpu() checks
> (tsk)->cpus_runnable != ~0UL but uni-processor systems do not change
> the value of cpus_runnable when they switch a task off a cpu.
>
> kernel/sched.c only calls task_release_cpu() for SMP builds which means
> that cpus_runnable will always show cpu 0 for all tasks, even those
> that are not on cpu 0 right now.  That breaks task_has_cpu() which
> breaks kdb.  Which is why I added kdb_task_has_cpu() to get it right.
>
>

-- 
Thanks,

Mark Sincerbox
Adax, Inc.
1-510-548-7047 x129



---------------------------
Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.

Reply via email to