** Description changed: [Impact] - Crash kernels do not advise some subsystems to perform a reset by default. - [Description] - Kernel has the "reset_devices" parameter that drivers can opt-in, and perform special activity in case this parameter is parsed from command-line. For example, in kdump kernels it hints the drivers that they (maybe) are booting from a non-healthy condition and needs to issue some reset to the adapter. Users currently (kernel v4.19) are: hpsa, ipr, megaraid_sas, mpt3sas, smartpqi, xenbus. + * Kdump does not configure by default the crash kernel to perform a + device reset by default, by passing the "reset_devices" parameter. Also, + the systemd service "kdump-tools-dump" is tightly-coupled with + KDUMP_CMDLINE_APPEND and it shouldn't, to prevent user confusion. + + * Kernel has the "reset_devices" parameter that drivers can opt-in, and + perform special activity in case this parameter is parsed from command- + line. For example, in kdump kernels it hints the drivers that they are + booting from a non-healthy condition and needs to issue some form of + reset to the adapter, like clearing DMA mapping in their firmware for + example. Users currently (kernel v5.2) are: aacraid, hpsa, ipr, + megaraid_sas, mpt3sas, smartpqi, xenbus. This should be enabled by default in the kdump config file to be added in the kdump kernel command-line for all versions. + * The systemd service"kdump-tools-dump" is responsible for triggering the execution of the makedumpfile tool ultimately. Kdump from Xenial+ releases rely on systemd as their init system, so this service is the way to trigger the kdump mechanism. Currently it is configured as any other parameter in KDUMP_CMDLINE_APPEND, meaning if user decides to change the line they need to remember adding the systemd service back. It's not really a parameter that should be easily manipulated in kdump line, since there's no use for it except to instruct systemd to load kdump; the only + reasonable case for removing it is to debug kdump itself. + + [Test Case] + 1) Deploy a Disco VM e.g. with uvt-kvm 2) Install the kdump-tools package 3) Run `kdump-config test`and check for the 'reset_devices' parameter: $ kdump-config test ... kexec command to be used: /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1 systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" /var/lib/kdump/vmlinuz + Also, by changing the KDUMP_CMDLINE_APPEND we can see "systemd.unit + =kdump-tools.service" to be removed. + + [Regression Potential] - The regression potential is very low, since it doesn't need any changes in makedumpfile code and we're only adding a parameter on the crashkernel cmdline. - The fix will be tested with autopkgtests and normal kdump use-case scenarios. + + The regression potential is low, since it doesn't need any changes in + makedumpfile code and we're only adding a parameter on the crash kernel + command-line. The risks are related with bad behavior with the kernel + when using "reset_devices", like if the driver has bugs in this path. + It's considered safer to have the option (and this way prevent problems + for booting a unhealthy kernel with potential stuck DMAs in the devices) + than not having it. + + Regarding the other change, about the systemd service, it'll only affect + users the are debugging kdump itself and it has no known regression + potential.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800566 Title: Make reset_devices parameter default for kdump and decouple kdump systemd service from the KDUMP_CMDLINE_APPEND To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800566/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
