Re: [PATCH] ehea: Add kdump support

In message [ref] you wrote:

Michael Ellerman wrote on 26.11.2007 09:16:28:

quoted

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.

quoted

 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.

quoted

 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?

quoted

 d) <something else>

Firmware change? But that's not something you will get very soon.

Christoph R.