OpenCloudOS-Kernel/Documentation/admin-guide/kdump/gdbmacros.txt

324 lines
8.6 KiB
Plaintext
Raw Normal View History

[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
#
# This file contains a few gdb macros (user defined commands) to extract
# useful information from kernel crashdump (kdump) like stack traces of
# all the processes or a particular process and trapinfo.
#
# These macros can be used by copying this file in .gdbinit (put in home
# directory or current directory) or by invoking gdb command with
# --command=<command-file-name> option
#
# Credits:
# Alexander Nyberg <alexn@telia.com>
# V Srivatsa <vatsa@in.ibm.com>
# Maneesh Soni <maneesh@in.ibm.com>
#
define bttnobp
set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
set $pid_off=((size_t)&((struct task_struct *)0)->thread_group.next)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
set $init_t=&init_task
set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
set var $stacksize = sizeof(union thread_union)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
while ($next_t != $init_t)
set $next_t=(struct task_struct *)$next_t
printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
printf "===================\n"
set var $stackp = $next_t.thread.sp
set var $stack_top = ($stackp & ~($stacksize - 1)) + $stacksize
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
while ($stackp < $stack_top)
if (*($stackp) > _stext && *($stackp) < _sinittext)
info symbol *($stackp)
end
set $stackp += 4
end
set $next_th=(((char *)$next_t->thread_group.next) - $pid_off)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
while ($next_th != $next_t)
set $next_th=(struct task_struct *)$next_th
printf "\npid %d; comm %s:\n", $next_t.pid, $next_t.comm
printf "===================\n"
set var $stackp = $next_t.thread.sp
set var $stack_top = ($stackp & ~($stacksize - 1)) + stacksize
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
while ($stackp < $stack_top)
if (*($stackp) > _stext && *($stackp) < _sinittext)
info symbol *($stackp)
end
set $stackp += 4
end
set $next_th=(((char *)$next_th->thread_group.next) - $pid_off)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
end
set $next_t=(char *)($next_t->tasks.next) - $tasks_off
end
end
document bttnobp
dump all thread stack traces on a kernel compiled with !CONFIG_FRAME_POINTER
end
define btthreadstack
set var $pid_task = $arg0
printf "\npid %d; comm %s:\n", $pid_task.pid, $pid_task.comm
printf "task struct: "
print $pid_task
printf "===================\n"
set var $stackp = $pid_task.thread.sp
set var $stacksize = sizeof(union thread_union)
set var $stack_top = ($stackp & ~($stacksize - 1)) + $stacksize
set var $stack_bot = ($stackp & ~($stacksize - 1))
set $stackp = *((unsigned long *) $stackp)
while (($stackp < $stack_top) && ($stackp > $stack_bot))
set var $addr = *(((unsigned long *) $stackp) + 1)
info symbol $addr
set $stackp = *((unsigned long *) $stackp)
end
end
document btthreadstack
dump a thread stack using the given task structure pointer
end
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
define btt
set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
set $pid_off=((size_t)&((struct task_struct *)0)->thread_group.next)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
set $init_t=&init_task
set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
while ($next_t != $init_t)
set $next_t=(struct task_struct *)$next_t
btthreadstack $next_t
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
set $next_th=(((char *)$next_t->thread_group.next) - $pid_off)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
while ($next_th != $next_t)
set $next_th=(struct task_struct *)$next_th
btthreadstack $next_th
set $next_th=(((char *)$next_th->thread_group.next) - $pid_off)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
end
set $next_t=(char *)($next_t->tasks.next) - $tasks_off
end
end
document btt
dump all thread stack traces on a kernel compiled with CONFIG_FRAME_POINTER
end
define btpid
set var $pid = $arg0
set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
set $pid_off=((size_t)&((struct task_struct *)0)->thread_group.next)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
set $init_t=&init_task
set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
set var $pid_task = 0
while ($next_t != $init_t)
set $next_t=(struct task_struct *)$next_t
if ($next_t.pid == $pid)
set $pid_task = $next_t
end
set $next_th=(((char *)$next_t->thread_group.next) - $pid_off)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
while ($next_th != $next_t)
set $next_th=(struct task_struct *)$next_th
if ($next_th.pid == $pid)
set $pid_task = $next_th
end
set $next_th=(((char *)$next_th->thread_group.next) - $pid_off)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
end
set $next_t=(char *)($next_t->tasks.next) - $tasks_off
end
btthreadstack $pid_task
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
end
document btpid
backtrace of pid
end
define trapinfo
set var $pid = $arg0
set $tasks_off=((size_t)&((struct task_struct *)0)->tasks)
set $pid_off=((size_t)&((struct task_struct *)0)->thread_group.next)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
set $init_t=&init_task
set $next_t=(((char *)($init_t->tasks).next) - $tasks_off)
set var $pid_task = 0
while ($next_t != $init_t)
set $next_t=(struct task_struct *)$next_t
if ($next_t.pid == $pid)
set $pid_task = $next_t
end
set $next_th=(((char *)$next_t->thread_group.next) - $pid_off)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
while ($next_th != $next_t)
set $next_th=(struct task_struct *)$next_th
if ($next_th.pid == $pid)
set $pid_task = $next_th
end
set $next_th=(((char *)$next_th->thread_group.next) - $pid_off)
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
end
set $next_t=(char *)($next_t->tasks.next) - $tasks_off
end
printf "Trapno %ld, cr2 0x%lx, error_code %ld\n", $pid_task.thread.trap_no, \
$pid_task.thread.cr2, $pid_task.thread.error_code
end
document trapinfo
Run info threads and lookup pid of thread #1
'trapinfo <pid>' will tell you by which trap & possibly
address the kernel panicked.
[PATCH] kdump: Documentation for Kdump This patch contains the documentation for the kexec based crash dump tool. Quick kdump-howto ================================================================ 1) Download and build kexec-tools. 2) Download and build the latest kexec/kdump (-mm) kernel patchset. Two kernels need to be built in order to get this feature working. A) First kernel: a) Enable "kexec system call" feature: CONFIG_KEXEC=y b) Physical load address (use default): CONFIG_PHYSICAL_START=0x100000 c) Enable "sysfs file system support": CONFIG_SYSFS=y d) Boot into first kernel with the command line parameter "crashkernel=Y@X": For example: "crashkernel=64M@16M". B) Second kernel: a) Enable "kernel crash dumps" feature: CONFIG_CRASH_DUMP=y b) Physical load addreess, use same load address as X in "crashkernel" kernel parameter in d) above, e.g., 16 MB or 0x1000000. CONFIG_PHYSICAL_START=0x1000000 c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y 3) Boot into the first kernel. 4) Load the second kernel to be booted using: kexec -p <second-kernel> --crash-dump --args-linux --append="root=<root-dev> maxcpus=1 init 1" 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic, for testing purposes. 6) See Documentation/kdump.txt for how to read the first kernel's memory image and how to analyze it. Signed-off-by: Hariprasad Nellitheertha <hari@in.ibm.com> Signed-off-by: Eric Biederman <ebiederm@xmission.com> Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: randy_dunlap <rdunlap@xenotime.net> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-26 05:58:15 +08:00
end
define dump_record
set var $desc = $arg0
set var $info = $arg1
if ($argc > 2)
set var $prev_flags = $arg2
else
set var $prev_flags = 0
end
set var $prefix = 1
set var $newline = 1
set var $begin = $desc->text_blk_lpos.begin % (1U << prb->text_data_ring.size_bits)
set var $next = $desc->text_blk_lpos.next % (1U << prb->text_data_ring.size_bits)
# handle data-less record
if ($begin & 1)
set var $text_len = 0
set var $log = ""
else
# handle wrapping data block
if ($begin > $next)
set var $begin = 0
end
# skip over descriptor id
set var $begin = $begin + sizeof(long)
# handle truncated message
if ($next - $begin < $info->text_len)
set var $text_len = $next - $begin
else
set var $text_len = $info->text_len
end
set var $log = &prb->text_data_ring.data[$begin]
end
# prev & LOG_CONT && !(info->flags & LOG_PREIX)
if (($prev_flags & 8) && !($info->flags & 4))
set var $prefix = 0
end
# info->flags & LOG_CONT
if ($info->flags & 8)
# (prev & LOG_CONT && !(prev & LOG_NEWLINE))
if (($prev_flags & 8) && !($prev_flags & 2))
set var $prefix = 0
end
# (!(info->flags & LOG_NEWLINE))
if (!($info->flags & 2))
set var $newline = 0
end
end
if ($prefix)
printf "[%5lu.%06lu] ", $info->ts_nsec / 1000000000, $info->ts_nsec % 1000000000
end
if ($text_len)
eval "printf \"%%%d.%ds\", $log", $text_len, $text_len
end
if ($newline)
printf "\n"
end
# handle dictionary data
set var $dict = &$info->dev_info.subsystem[0]
set var $dict_len = sizeof($info->dev_info.subsystem)
if ($dict[0] != '\0')
printf " SUBSYSTEM="
set var $idx = 0
while ($idx < $dict_len)
set var $c = $dict[$idx]
if ($c == '\0')
loop_break
else
if ($c < ' ' || $c >= 127 || $c == '\\')
printf "\\x%02x", $c
else
printf "%c", $c
end
end
set var $idx = $idx + 1
end
printf "\n"
end
set var $dict = &$info->dev_info.device[0]
set var $dict_len = sizeof($info->dev_info.device)
if ($dict[0] != '\0')
printf " DEVICE="
set var $idx = 0
while ($idx < $dict_len)
set var $c = $dict[$idx]
if ($c == '\0')
loop_break
else
if ($c < ' ' || $c >= 127 || $c == '\\')
printf "\\x%02x", $c
else
printf "%c", $c
end
end
set var $idx = $idx + 1
end
printf "\n"
end
end
document dump_record
Dump a single record. The first parameter is the descriptor,
the second parameter is the info, the third parameter is
optional and specifies the previous record's flags, used for
properly formatting continued lines.
end
define dmesg
# definitions from kernel/printk/printk_ringbuffer.h
set var $desc_committed = 1
printk: ringbuffer: add finalization/extension support Add support for extending the newest data block. For this, introduce a new finalization state (desc_finalized) denoting a committed descriptor that cannot be extended. Until a record is finalized, a writer can reopen that record to append new data. Reopening a record means transitioning from the desc_committed state back to the desc_reserved state. A writer can explicitly finalize a record if there is no intention of extending it. Also, records are automatically finalized when a new record is reserved. This relieves writers of needing to explicitly finalize while also making such records available to readers sooner. (Readers can only traverse finalized records.) Four new memory barrier pairs are introduced. Two of them are insignificant additions (data_realloc:A/desc_read:D and data_realloc:A/data_push_tail:B) because they are alternate path memory barriers that exactly match the purpose, pairing, and context of the two existing memory barrier pairs they provide an alternate path for. The other two new memory barrier pairs are significant additions: desc_reopen_last:A / _prb_commit:B - When reopening a descriptor, ensure the state transitions back to desc_reserved before fully trusting the descriptor data. _prb_commit:B / desc_reserve:D - When committing a descriptor, ensure the state transitions to desc_committed before checking the head ID to see if the descriptor needs to be finalized. Signed-off-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20200914123354.832-6-john.ogness@linutronix.de
2020-09-14 20:33:53 +08:00
set var $desc_finalized = 2
set var $desc_sv_bits = sizeof(long) * 8
set var $desc_flags_shift = $desc_sv_bits - 2
set var $desc_flags_mask = 3 << $desc_flags_shift
set var $id_mask = ~$desc_flags_mask
set var $desc_count = 1U << prb->desc_ring.count_bits
set var $prev_flags = 0
set var $id = prb->desc_ring.tail_id.counter
set var $end_id = prb->desc_ring.head_id.counter
while (1)
set var $desc = &prb->desc_ring.descs[$id % $desc_count]
set var $info = &prb->desc_ring.infos[$id % $desc_count]
# skip non-committed record
set var $state = 3 & ($desc->state_var.counter >> $desc_flags_shift)
printk: ringbuffer: add finalization/extension support Add support for extending the newest data block. For this, introduce a new finalization state (desc_finalized) denoting a committed descriptor that cannot be extended. Until a record is finalized, a writer can reopen that record to append new data. Reopening a record means transitioning from the desc_committed state back to the desc_reserved state. A writer can explicitly finalize a record if there is no intention of extending it. Also, records are automatically finalized when a new record is reserved. This relieves writers of needing to explicitly finalize while also making such records available to readers sooner. (Readers can only traverse finalized records.) Four new memory barrier pairs are introduced. Two of them are insignificant additions (data_realloc:A/desc_read:D and data_realloc:A/data_push_tail:B) because they are alternate path memory barriers that exactly match the purpose, pairing, and context of the two existing memory barrier pairs they provide an alternate path for. The other two new memory barrier pairs are significant additions: desc_reopen_last:A / _prb_commit:B - When reopening a descriptor, ensure the state transitions back to desc_reserved before fully trusting the descriptor data. _prb_commit:B / desc_reserve:D - When committing a descriptor, ensure the state transitions to desc_committed before checking the head ID to see if the descriptor needs to be finalized. Signed-off-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20200914123354.832-6-john.ogness@linutronix.de
2020-09-14 20:33:53 +08:00
if ($state == $desc_committed || $state == $desc_finalized)
dump_record $desc $info $prev_flags
set var $prev_flags = $info->flags
end
set var $id = ($id + 1) & $id_mask
if ($id == $end_id)
loop_break
end
end
end
document dmesg
print the kernel ring buffer
end