Am Wed, 4 Sep 2019 16:22:37 +0200 schrieb Jan Beulich : > First of all - does "the code" here mean master/staging, or any > release branch? And then, yes, on release branches there will be > EINVAL, but as said before kexec_crash_area.size will get/remain > set nevertheless (as the error path doesn't zap any of the > earlier parsing outcome). The code is anything since staging-4.10, in my case 4.11 and 4.12. And yes, the side effect is setting the values. I have tried a number of Xen/dom0/kexec-tools/crashkernel= combinations. SLE12SP4 works, SLE15SP1 fails. I was looking for "crash kernel" hints in xl dmesg, only much later I spotted the "KDump:" line. The mentioned entries are not present in /proc/iomem. All of that led to the conclusion that crashkernel=size does not work. It turned out the tooling is not dom0 aware, it fails to translate "console=com1 com1=57600"+"console=hvc0" into "console=ttyS0,57600" for the kdump kernel. This is a common pattern of ignorance. And finally the kdump kernel fails to initialize hardware due to low memory and SWIOTBL? errors. Once drm.ko and usbcore.ko are disabled, the first kdump ever was generated on this system. > > With this change any unknown string will cause EINVAL. > Which is what should happen for unknown (i.e. unsupported) strings, > shouldn't it? Yes. Olaf