<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <tt></tt> <tt>Sachin,</tt><tt></tt> <tt>This may require help from the IBM ppc64 people out there,</tt> <tt>but it appears that the issue at hand has something to do</tt> <tt>with the uniprocessor aspect.</tt><tt></tt> <tt>Your vmlinux is an SMP kernel, but I'm guessing that the wrong</tt> <tt>choice of "runq" addresses is being made below:</tt><tt></tt> <tt> if (symbol_exists("per_cpu__runqueues") &&</tt> <tt> VALID_MEMBER(runqueue_idle)) {</tt> <tt> runqbuf = GETBUF(SIZE(runqueue));</tt> <tt> for (i = 0; i < nr_cpus; i++) {</tt> <tt> if ((kt->flags & SMP) && (kt->flags & PER_CPU_OFF)) {</tt> <tt> runq = symbol_value("per_cpu__runqueues") +</tt> <tt> kt->__per_cpu_offset[i];</tt> <tt> } else</tt> <tt> runq = symbol_value("per_cpu__runqueues");</tt><tt></tt> <tt> readmem(runq, KVADDR, runqbuf,</tt> <tt> SIZE(runqueue), "runqueues entry (per_cpu)",</tt> <tt> FAULT_ON_ERROR);</tt> <tt> tasklist[i] = ULONG(runqbuf + OFFSET(runqueue_idle));</tt> <tt> if (IS_KVADDR(tasklist[i]))</tt> <tt> cnt++;</tt><tt></tt> <tt>I don't know what your "kt->flags" is showing at the</tt> <tt>decision point above, but if you hack the code and force</tt> <tt>it to select the "other" runq value, does it work OK?</tt><tt></tt> <tt>When CONFIG_SMP is not configured into the kernel, then</tt> <tt>the direct value of "per_cpu__runqueues" is used, whereas</tt> <tt>with SMP kernels, the appropriate offset needs to be</tt> <tt>applied. At least that's how it works (has worked?) with</tt> <tt>the other architectures.</tt><tt></tt> <tt>Dave</tt> <tt></tt> </html>