Re: [Fastboot] Re: [PATCH] ppc64: kexec support for ppc64

[Maneesh Soni <maneesh@in.ibm.com>]

On Sat, May 07, 2005 at 10:19:41PM +0530, Suparna Bhattacharya wrote:
> On Fri, May 06, 2005 at 04:05:46PM -0700, Andrew Morton wrote:
> > R Sharada <sharada@in.ibm.com> wrote:
> > >
> > > This patch implements the kexec support for ppc64
> > 
> > Well that's pretty neat.   How well does this work?
> > 
> > I assume you'll be working on kdump-via-kexec for ppc64?
> > 
> > 
> > This kdump/kexec stuff has been hanging around for far too long, IMO.  I'd
> > like to think about what we can do to get things moving along a bit more.
> > 
> > I have two issues with it:
> > 
> > a) Vague feelings that the low-level ia32 changes may cause APIC/etc
> >    breakage with some PCs.
> 
> Do you suspect impact during normal operation, or only upon kexec-on-panic ?
> If its the former, then wider testing with CONFIG_KEXEC turned on is
> really important.

Following are the kexec patches which modify the concerned area and 
are _not_ under CONFIG_KEXEC. So it is also important to test such 
codepath with and without CONFIG_KEXEC. We have been testing various 
x86 machines with these patches and so far we have not observed any 
problems related to machine shutdown or APIC/IOAPIC shutdown.

x86-rename-apic_mode_exint.patch
x86-local-apic-fix.patch
x86-i8259-shutdown.patch
x86_64-i8259-shutdown.patch
x86-apic-virtwire-on-shutdown.patch
x86_64-apic-virtwire-on-shutdown.patch
x86-machine_shutdown.patch
x86_64-machine_shutdown.patch

> > b) Much more significantly: I still do not believe that it has been
> >    demonstrated that the whole kdump-via-kexec scheme will have a
> >    sufficiently high success rate for this to become Linux's way of doing
> >    crashdumps.
> > 

Following are the links to kdump testing results and kexec-tools patches

http://lse.sourceforge.net/kdump/kdump-test.html

http://lse.sourceforge.net/kdump/patches/kexec-tools-1.101-kdump.patch

> >    And it would not be good if in six months time we decide that the
> >    practical problems in getting it all working sufficiently well are
> >    insurmountable and we have to revert it all and start working on
> >    something else.

At this point of time we have device initialisation problem in hand which
causes intermittent failures in second kernel boot in case of kexec-on-panic.

> >    Recently I've seem a couple of "kdump worked for me" reports, which are
> >    greatly appreciated, but I don't think they're statistically
> >    significant.
> > 
> >    So am I right to have this concern?  If so, how can we settle this? 
> >    (ie: who's going to do it?  ;))
> > 
> 
>
[..]
> > 
> > Perhaps we could declare that kexec is sufficiently useful and mature in
> > its own right and just merge up those bits while we work on kdump.  This
> > also gives us a bit of pipelining: continue to test and stabilise kexec
> > while kdump remains in development.
> 
> Several months back, I would likely have agreed with that.
> 
> Now, I'm not so sure. After the kdump redesign, a large part of the kdump
> support is actually provided by kexec-on-panic which is an integral part
> of kexec. The additional bits for dump capture alone may not be a whole
> lot ... But, I'd let Maneesh/Vivek comment on that.

That's right. After the kexec rework, significant chunk of kdump 
functionality particularly related to panic codepath, which halts 
other CPU's and saves register states, is merged with kexec, as 
kexec-on-panic functionality.

kdump code in kernel is mainly reduced to dump capturing functionality 
only. If kexec-on-panic can successfully boot second kernel, there are 
remote chances of /proc/vmcore or /dev/oldmem not getting generated.


Thanks
Maneesh


-- 
Maneesh Soni
Linux Technology Center, 
IBM India Software Labs,
Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-25044990