On 10/30/2014 09:58 PM, Hedi Berriche wrote: > On Thu, Oct 30, 2014 at 17:06 Prarit Bhargava wrote: > | There have been several times where I have had to rebuild a kernel to > | cause a panic when hitting a WARN() in the code in order to get a crash > | dump from a system. Sometimes this is easy to do, other times (such as > | in the case of a remote admin) it is not trivial to send new images to the > | user. > | > | A much easier method would be a switch to change the WARN() over to a > | panic. This makes debugging easier in that I can now test the actual > | image the WARN() was seen on and I do not have to engage in remote > | debugging. > > Do we want to leave it to usersspace[1] to ensure panic_on_warn is out > of the way in when the kdump kernel boots? or would a self-contained > approach be more preferable i.e. test whether we're a kdump kernel > before bothering with panic_on_warn? Hmm ... this is a good point. Vivek, do you have a preference? I'm willing to code it either way. I should be able to put in a is_kdump_kernel() check without any problems but I'm not sure if that is the right thing to do here. P. > > Cheers, > Hedi. > > [1] kexec-tools in the case of the boot param by filtering it out of the > kdump kernel cmdline. In the case of sysctl.conf, it would depend on > whether there are distros out there that include it in the kdump > initrd. > -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
