----- "Dave Anderson" <anderson@xxxxxxxxxx> wrote:
> ----- "Michael Holzheu" <holzheu@xxxxxxxxxxxxxxxxxx> wrote:
>
> > Hello Dave,
> >
> > On Mon, 2010-04-26 at 10:29 -0400, Dave Anderson wrote:
> > > I'd prefer not to leave them out of the various internal task
> arrays,
> > > especially the active_set[] array. Regardless of their on/offline
> > > status, they do still exist as tasks, have runqueues, etc.
> >
> > Ok, fine.
> >
> > > If you're just worried about "bt -a", then why not just catch
> > > the offline status in the for loop inside "if (active)" section
> > > of cmd_bt()?
> >
> > Good idea! The following attached patch also works for me.
> >
> > Michael
>
> That looks good -- queued for the next release.
>
> Thanks,
> Dave
Sorry -- I take it back. Running a test shows that it breaks "bt -a"
on Xen dumpfiles where the cpus are marked offline prior to dumping
the kernel memory.
I think this should be moved to the processor-specific backtrace functions,
which can just display "OFFLINE" or something to that effect.
Dave
>
> > ---
> > kernel.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > --- a/kernel.c
> > +++ b/kernel.c
> > @@ -1989,6 +1989,8 @@ cmd_bt(void)
> > free_all_bufs();
> > continue;
> > }
> > + if (!(kt->cpu_flags[c] & ONLINE))
> > + continue;
> > if ((tc = task_to_context(tt->panic_threads[c]))) {
> > pc->flags |= IN_FOREACH;
> > DO_TASK_BACKTRACE();
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
