On 13. 12. 23, 6:57, Baoquan He wrote:
When specifying 'kexec -c -d', kexec_load interface will print loading
information, e.g the regions where kernel/initrd/purgatory/cmdline
are put, the memmap passed to 2nd kernel taken as system RAM ranges,
and printing all contents of struct kexec_segment, etc. These are
very helpful for analyzing or positioning what's happening when
kexec/kdump itself failed. The debugging printing for kexec_load
interface is made in user space utility kexec-tools.
Whereas, with kexec_file_load interface, 'kexec -s -d' print nothing.
Because kexec_file code is mostly implemented in kernel space, and the
debugging printing functionality is missed. It's not convenient when
debugging kexec/kdump loading and jumping with kexec_file_load
interface.
Now add KEXEC_FILE_DEBUG to kexec_file flag to control the debugging
message printing. And add global variable kexec_file_dbg_print and
macro kexec_dprintk() to facilitate the printing.
This is a preparation, later kexec_dprintk() will be used to replace the
existing pr_debug(). Once 'kexec -s -d' is specified, it will print out
kexec/kdump loading information. If '-d' is not specified, it regresses
to pr_debug().
Signed-off-by: Baoquan He <bhe@xxxxxxxxxx>
...
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
...
@@ -500,6 +500,13 @@ static inline int crash_hotplug_memory_support(void) { return 0; }
static inline unsigned int crash_get_elfcorehdr_size(void) { return 0; }
#endif
+extern bool kexec_file_dbg_print;
+
+#define kexec_dprintk(fmt, ...) \
+ printk("%s" fmt, \
+ kexec_file_dbg_print ? KERN_INFO : KERN_DEBUG, \
+ ##__VA_ARGS__)
This means you dump it _always_. Only with different levels.
And without any prefix whatsoever, so people see bloat like this in
their log now:
[ +0.000001] 0000000000001000-000000000009ffff (1)
[ +0.000002] 000000007f96d000-000000007f97efff (3)
[ +0.000002] 0000000000800000-0000000000807fff (4)
[ +0.000001] 000000000080b000-000000000080bfff (4)
[ +0.000002] 0000000000810000-00000000008fffff (4)
[ +0.000001] 000000007f97f000-000000007f9fefff (4)
[ +0.000001] 000000007ff00000-000000007fffffff (4)
[ +0.000002] 0000000000000000-0000000000000fff (2)
without actually knowing what that is.
There should be nothing logged if that is not asked for and especially
if kexec load went fine, right?
Can this be redesigned, please?
Actually what was wrong on the pr_debug()s? Can you simply turn them on
from the kernel when -d is passed to kexec instead of all this?
...
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -52,6 +52,8 @@ atomic_t __kexec_lock = ATOMIC_INIT(0);
/* Flag to indicate we are going to kexec a new kernel */
bool kexec_in_progress = false;
+bool kexec_file_dbg_print;
Ugh, and a global flag for this?
thanks,
--
js
suse labs
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
