[Crash-utility] Re: Problem with using crash 4.0-2.21 on ppc
Badari Pulavarty
pbadari at us.ibm.com
Wed Feb 22 23:51:20 UTC 2006
On Wed, 2006-02-22 at 15:31 -0800, Haren Myneni wrote:
> Haren Myneni wrote:
>
> >
> >
> > crash-utility-bounces at redhat.com wrote on 02/22/2006 07:31:43 AM:
> >
> > > Rachita Kothiyal wrote:
> > >
> > > >
> > > > > Rachita Kothiyal wrote:
> > > >
> > > >
> > > > >
> > > > > This happens in get_idle_threads() when perusing the runqueues
> > array,
> > > > > where each per-cpu runqueue data structure contains a pointer to the
> > > > > idle (swapper) task for that CPU. Now, this process requires
> > that the
> > > > > per-cpu address manipulations are working correctly in order to
> > find the
> > > > > each cpu's runqueue data structure. It looks like the ppc64 change
> > > > > for per-cpu data accesses is suspect here:
> > > > >
> > > > > > Fix to recognize post-2.6.15 ppc64 kernels moving the
> > per_cpu_offsets
> > > > > > to the "paca" structure. Without this patch, crash fails with the
> > > > > > following error messages: "crash: cannot determine idle task
> > addresses
> > > > > > from init_tasks[] or runqueues[]" and "crash: cannot resolve
> > > > > > init_task_union". (pbadari at us.ibm.com)
> > > > >
> > > >
> > > > Right, but I thought this patch fixed this problem.
> > > > (I am using crash-4.0-2.21, and it includes this patch)
> > >
> > > Right -- me too... ;-)
> >
> > Badari tested his patch on live system. He can give more information
> > anyway.
> >
> > However, I used his patch for testing PPC64 vmcore before I post my
> > patch. Did not see any issue when invoking crash tool. Tested on
> > 2.6.16-rc2-gi9.
> >
> > I will also verify if I have the same vmcore.
> >
> > Thanks
> > Haren
> >
> Dave,
>
> I used Badari's patch (first version) for my testing on PPC64 kdump
> vmcore. Later, this patch was changed to use paca[CPU#].hw_cpu_id to
> determine whether the CPU exists (CPU hotplug case). The reason it
> failed on vmcore is, when the kdump boot happens, this hw_cpu_id is set
> to -1 for secondary cpus when they stopped. Hence, not setting
> per_cpu_offset for these CPUs and causing this issue.
>
> Instead of looking for hw_cpu_id, this patch will look for the
> corresponding data_offset. If 0, means CPU does not exists.
>
> Rachita, please let us know if still an issue. Badari, is there any
> issue with this patch?
Haren,
Yes. My first version of the patch did exactly this. Later, while
discussing with you we decided that checking for "-1" for CPU ID
is the right thing to identify the presence of the CPU.
Yep. you are right on kdump boot, you do set cpuid to -1 when
they are stopped.
So, I guess I am okay with your fix.
Thanks,
Badari
More information about the Crash-utility
mailing list