Re: [PATCH] ehea: Add kdump support

[Michael Neuling <mikey@neuling.org>]

In message <OF94123F44.9DB75CE9-ONC125739F.00398E63-C125739F.003B2AFE@de.ibm.com> you wrote:
> Michael Ellerman wrote on 26.11.2007 09:16:28:
> > Solutions that might be better:
> >
> >  a) if there are a finite number of handles and we can predict their
> >     values, just delete them all in the kdump kernel before the driver
> >     loads.
> 
> Guessing the values does not work, because of the handle structure
> defined by the hypervisor.
> 
> >  b) if there are a small & finite number of handles, save their values
> >     in a device tree property and have the kdump kernel read them and
> >     delete them before the driver loads.
> 
> 5*16*nr_ports+1+1=   >82. a ML16 has 4 adapters with up to 16 ports, so the
> number is not small anymore....

I assume this machine with a huge number of adapters has a huge amount
of memory too! :-)

> The device tree functions are currently not exported.

We can add this.

> If you crashdump to a new kernel, will it get the device tree
> representation of the crashed kernel or of the initial one of open
> firmware?

The kexec tools userspace control this.  Normally it just takes the
current device tree plus some modifications (eg. initrd location
changes).

So provided the ehea driver export this info somewhere, it can be
grabbed by the kexec tools and stuffed in the device tree of the new
kernel.  

That being said, the proper place to have this would be original device
tree.

> 
> >  c) if neither of those work, provide a minimal routine that _only_
> >     deletes the handles in the crashed kernel.
> 
> I would hope this has the highest chance to actually work.
> For this we would have to add a proper notifier chain.
> Do you agree?
> 
> >  d) <something else>
> 
> Firmware change? But that's not something you will get very soon.
> 
> Christoph R.
>