Comment 16 for bug 1570775

------- Comment From <email address hidden> 2016-07-13 11:52 EDT-------
Hmm, just one hour ago the s390-tools maintainer submitted a patch for the manpage of cio_ignore to clarify that the example command "cio_ignore -u -k" modifies(!) the current cio_ignore blacklist.
It was not obvious until today, that it really modifies something!

What does it mean:
1. Under z/VM, if somebody had invoked "cio_ignore -u -k" via installation of kdump-tools, performs no reboot AND attaches additional CCW devices, they will not show up in the channel subsystem (e.g. via lscss) until they are unblacklisted (e.g. via cio_ignore -r <busid>)
2. Similar for LPAR, if you define additional CCW devices via dynamic I/O configuration change in HCD.
3. If someone performs a "cio_ignore -p" after invoking "cio_ignore -u -k" (e.g. via installation of kdump-tools), the change becomes effective and visible also for existing unused devices, and all unused CCW devices are blacklisted and no more visible.
4. After a reboot, the cio_ignore blacklist is concurrent to what has been specified via kernel parameter line. (Which means: Everything is fine again.)

My recommendation:
1. Go ahead with the actual implementation as of today, since it is worth to have a kdump when required, even with the above misbehaviour (which can be worked around).
2. When a new version of cio_ignore (within s390-tools) is available, you should pick up this new s390-tools version and also fix the postinst script in kdump-tools package picking by adjusting the cio_ignore parameters.

We will open a new bug to fix the postinst script again, when an updated version of s390-tools is available.