On 10/28/2014 08:16 AM, Andi Kleen wrote: > On Fri, Oct 24, 2014 at 08:53:27AM -0400, 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 >> BUG(). 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. > > IMHO this would be better and far more generically done with kdb. > You would need two things: > > - Extend the break point command to run another command on a break point. > - Add a command line (or possibly /proc) option to execute some kdb commands at > kernel boot. I suppose ... but that would mean I would have to explain to an end user the elaborate process of enabling kdb, inserting a break point, etc. The whole purpose of this is to let an end user panic on WARN() easily. Asking an end user to enable kdb is magnitudes worse than asking them to recompile a kernel. P. > > Then just set a break point on the warn function and execute magic sysrq c > from kdb. > > -Andi > -- 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
