Introduction
When operating systems built on Linux, you may encounter issues such as sudden reboots caused by kernel panics, OS hangs, or the activation of the OOM Killer—problems where the root cause cannot be identified through logs alone.
In investigations of these OS-level failures, memory dumps play a critical role.
In this article, I will explain—so that even beginners can understand—the purpose of collecting memory dumps in Linux OS environments, how to obtain them using kdump, and the basic analysis methods using crash.
I hope this guide will serve as a helpful first step in incident response and troubleshooting.
Purpose of Collecting a Memory Dump
A memory dump is a snapshot of the Linux OS memory state at the exact moment a failure occurs.
By capturing this snapshot, you can later perform detailed analysis of process states, internal kernel data structures, slab cache usage, and more.
In a typical incident investigation, the root cause is analyzed based on resource utilization metrics and various system logs. However, when the OS hangs or suddenly crashes, sufficient logs may not be recorded, resulting in missing critical information needed to identify the cause.
In such situations, a memory dump becomes an invaluable source of insight.
By collecting a memory dump, you can examine information such as the following:
- Kernel Memory
You can capture the entire kernel space memory, including code, data, and slab allocations.
This also includes page cache and buffer cache contents. - CPU Register State
You can examine the CPU register information at the time of the crash—such as RIP (Instruction Pointer), RSP (Stack Pointer), FLAGS, and others—as well as the execution context of each CPU. - Kernel Stack Trace
You can obtain the stack trace of the CPU that crashed.
It is also possible to inspect the kernel stacks of other CPUs and tasks. - Kernel Modules
You can review the list of loaded kernel modules, along with their load addresses, sizes, and dependency relationships. - Memory Fragmentation Status
You can examine memory zone information (such as DMA and Normal), the availability of free pages, and the usage status of slab/slub allocators. - Device / Driver Status
You can inspect IRQ (Interrupt Request) information, the internal state of device drivers, and kernel data structures related to I/O operations. - Kernel Logs (dmesg)
Because the kernel ring buffer resides in memory, you can retrieve dmesg-equivalent logs directly from the memory dump.
By configuring the system in advance to automatically collect a memory dump when an OS failure occurs, you can significantly streamline post-incident root cause analysis.
It is therefore highly recommended to enable this setting beforehand. Detailed configuration steps will be explained later in this article.
Collecting a Memory Dump Using kdump
In modern Linux environments, kdump is the most commonly used method for collecting memory dumps.
Although other collection methods exist, choosing kdump is generally sufficient unless you have specific or specialized requirements.
When the kdump feature is enabled, a minimal kernel—called the dump capture kernel—is preloaded into memory alongside the regular kernel.
If a fatal error such as a kernel panic occurs and the primary kernel can no longer continue execution, kdump triggers the dump capture kernel to boot. This capture kernel then saves the memory contents at the time of the failure (the crash dump) to storage.
kdump Setting
On RHEL-based operating systems, memory dump collection via kdump is enabled by default. However, in the default configuration, dump files are written to the /var/crash directory. Therefore, it is recommended to change the storage path according to your disk capacity and operational policies.
If possible, prepare a dedicated partition separate from the one used for normal OS operations and configure it as the dump destination. This improves reliability and safety during failure scenarios.
To change the dump location, modify the path setting in /etc/kdump.conf, and then restart the kdump service to apply the configuration changes.
[root@appserver-dev ~]# vi /etc/kdump.conf
[root@appserver-dev ~]#
[root@appserver-dev ~]#
[root@appserver-dev ~]# grep "path " /etc/kdump.conf
~~Truncated~~
#path /var/crash
path /mnt/crash
[root@appserver-dev ~]#
[root@appserver-dev ~]# systemctl restart kdump
[root@appserver-dev ~]# systemctl status kdump
● kdump.service - Crash recovery kernel arming
Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; preset: enabled)
Active: active (exited) since Mon 2025-12-15 06:33:34 JST; 1min 17s ago
Process: 1611 ExecCondition=/bin/sh -c grep -q -e "crashkernel" -e "fadump" /proc/cmdline (code=exited, status=0/SUCCESS)
Process: 1613 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
Main PID: 1613 (code=exited, status=0/SUCCESS)
CPU: 19.272s
~~Truncated~~
Dec 15 06:33:34 appserver-dev kdumpctl[1616]: kdump: Starting kdump: [OK]
Dec 15 06:33:34 appserver-dev systemd[1]: Finished Crash recovery kernel arming.
[root@appserver-dev ~]#
Collecting a Memory Dump When a Kernel Panic Occurs
Now, let’s intentionally trigger a kernel panic and collect a memory dump for testing purposes.
To simulate a kernel panic, you can use SysRq (Magic SysRq)—a mechanism that allows you to send commands directly to the Linux kernel. By enabling this feature, you can reproduce behavior similar to an actual kernel panic.
After temporarily modifying the required settings as shown below, trigger the panic to verify that the memory dump is successfully collected.
[root@appserver-dev ~]# sysctl -w kernel.sysrq=1
kernel.sysrq = 1
[root@appserver-dev ~]# cat /proc/sys/kernel/sysrq
1
[root@appserver-dev ~]#
[root@appserver-dev ~]# echo c > /proc/sysrq-trigger
When a kernel panic is triggered, the system will temporarily stop responding to input.
After some time, reconnect to the system and verify that the vmcore file has been successfully created.
[root@appserver-dev ~]# ls -lh /mnt/crash/127.0.0.1-2025-12-15-06\:53\:37/
total 119M
-rw------- 1 root root 51K Dec 15 06:53 kexec-dmesg.log
-rw------- 1 root root 119M Dec 15 06:53 vmcore
-rw------- 1 root root 46K Dec 15 06:53 vmcore-dmesg.txt
[root@appserver-dev ~]#Memory Dump Analysis
Finally, let’s take a look at how to analyze the memory dump.
Install Analysis Tool
Let’s perform an actual analysis using the crash command, the official debugger for analyzing Linux kernel memory dumps.
Install kernel-debuginfo
First, install the kernel-debuginfo package. The contents of a vmcore file consist only of raw numerical data. However, by specifying kernel-debuginfo when running the crash command, those raw values can be translated into a human-readable format.
[root@appserver-dev ~]# uname -r
5.14.0-570.22.1.el9_6.x86_64
[root@appserver-dev ~]# dnf install https://vault.almalinux.org/9.6/BaseOS/debug/x86_64/Packages/kernel-debuginfo-common-x86_64-5.14.0-570.22.1.el9_6.x86_64.rpm
Last metadata expiration check: 0:02:26 ago on Thu Dec 18 06:59:43 2025.
kernel-debuginfo-common-x86_64-5.14.0-570.22.1.el9_6.x86_64.rpm 8.8 MB/s | 80 MB 00:09
Dependencies resolved.
=======================================================================================================================================================================
Package Architecture Version Repository Size
=======================================================================================================================================================================
Installing:
kernel-debuginfo-common-x86_64 x86_64 5.14.0-570.22.1.el9_6 @commandline 80 M
Transaction Summary
=======================================================================================================================================================================
Install 1 Package
Total size: 80 M
Installed size: 488 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : kernel-debuginfo-common-x86_64-5.14.0-570.22.1.el9_6.x86_64 1/1
Verifying : kernel-debuginfo-common-x86_64-5.14.0-570.22.1.el9_6.x86_64 1/1
Installed:
kernel-debuginfo-common-x86_64-5.14.0-570.22.1.el9_6.x86_64
Complete!
[root@appserver-dev ~]#
[root@appserver-dev ~]# dnf install https://vault.almalinux.org/9.6/BaseOS/debug/x86_64/Packages/kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64.rpm
Last metadata expiration check: 0:04:13 ago on Thu Dec 18 06:59:43 2025.
kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64.rpm 28 MB/s | 709 MB 00:25
Dependencies resolved.
=======================================================================================================================================================================
Package Architecture Version Repository Size
=======================================================================================================================================================================
Installing:
kernel-debuginfo x86_64 5.14.0-570.22.1.el9_6 @commandline 709 M
Transaction Summary
=======================================================================================================================================================================
Install 1 Package
Total size: 709 M
Installed size: 2.8 G
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64 1/1
Running scriptlet: kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64 1/1
Verifying : kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64 1/1
Installed:
kernel-debuginfo-5.14.0-570.22.1.el9_6.x86_64
Complete!
[root@appserver-dev ~]#Install crash
Next, install the crash utility.
[root@appserver-dev ~]# dnf install crash
Last metadata expiration check: 0:02:03 ago on Thu Dec 18 06:15:59 2025.
Dependencies resolved.
=======================================================================================================================================================================
Package Architecture Version Repository Size
=======================================================================================================================================================================
Installing:
crash x86_64 9.0.0-4.el9.alma.1 appstream 4.9 M
Transaction Summary
=======================================================================================================================================================================
Install 1 Package
Total download size: 4.9 M
Installed size: 14 M
Is this ok [y/N]: y
Downloading Packages:
crash-9.0.0-4.el9.alma.1.x86_64.rpm 1.1 MB/s | 4.9 MB 00:04
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 1.0 MB/s | 4.9 MB 00:05
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : crash-9.0.0-4.el9.alma.1.x86_64 1/1
Running scriptlet: crash-9.0.0-4.el9.alma.1.x86_64 1/1
Verifying : crash-9.0.0-4.el9.alma.1.x86_64 1/1
Installed:
crash-9.0.0-4.el9.alma.1.x86_64
Complete!
[root@appserver-dev ~]#
With that, the installation of the required tools is complete.
Analyzing a vmcore File Using crash
Run the crash command to begin analyzing the vmcore file.
If the crash> prompt appears as shown below, the analysis environment has been successfully launched.
[root@appserver-dev ~]# crash /usr/lib/debug/usr/lib/modules/5.14.0-570.22.1.el9_6.x86_64/vmlinux /mnt/crash/127.0.0.1-2025-12-15-06\:53\:37/vmcore
crash 9.0.0-4.el9.alma.1
Copyright (C) 2002-2025 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011, 2020-2024 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
Copyright (C) 2015, 2021 VMware, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 16.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
KERNEL: /usr/lib/debug/usr/lib/modules/5.14.0-570.22.1.el9_6.x86_64/vmlinux
DUMPFILE: /mnt/crash/127.0.0.1-2025-12-15-06:53:37/vmcore [PARTIAL DUMP]
CPUS: 1
DATE: Mon Dec 15 06:53:28 JST 2025
UPTIME: 00:37:39
LOAD AVERAGE: 0.02, 0.04, 0.08
TASKS: 341
NODENAME: appserver-dev
RELEASE: 5.14.0-570.22.1.el9_6.x86_64
VERSION: #1 SMP PREEMPT_DYNAMIC Thu Jun 19 08:10:32 EDT 2025
MACHINE: x86_64 (2794 Mhz)
MEMORY: 4 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
PID: 1512
COMMAND: "bash"
TASK: ffff99b501edd280 [THREAD_INFO: ffff99b501edd280]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash>
Let’s go over some of the useful commands available for analysis.
sys
By running the sys command, you can obtain an overview of the entire system.
The reason for the panic is displayed in the PANIC field.
crash> sys
KERNEL: /usr/lib/debug/usr/lib/modules/5.14.0-570.22.1.el9_6.x86_64/vmlinux
DUMPFILE: /mnt/crash/127.0.0.1-2025-12-15-06:53:37/vmcore [PARTIAL DUMP]
CPUS: 1
DATE: Mon Dec 15 06:53:28 JST 2025
UPTIME: 00:37:39
LOAD AVERAGE: 0.02, 0.04, 0.08
TASKS: 341
NODENAME: appserver-dev
RELEASE: 5.14.0-570.22.1.el9_6.x86_64
VERSION: #1 SMP PREEMPT_DYNAMIC Thu Jun 19 08:10:32 EDT 2025
MACHINE: x86_64 (2794 Mhz)
MEMORY: 4 GB
PANIC: "Kernel panic - not syncing: sysrq triggered crash"
log
By running the log command, you can view the logs recorded just before the panic occurred.
crash> log
[ 0.000000] Linux version 5.14.0-570.22.1.el9_6.x86_64 (mockbuild@x64-builder02.almalinux.org) (gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5), GNU ld version 2.35.2-63.el9) #1 SMP PREEMPT_DYNAMIC Thu Jun 19 08:10:32 EDT 2025
[ 0.000000] The list of certified hardware and cloud instances for Red Hat Enterprise Linux 9 can be viewed at the Red Hat Ecosystem Catalog, https://catalog.redhat.com.
[ 0.000000] Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.14.0-570.22.1.el9_6.x86_64 root=/dev/mapper/almalinux-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap
[ 0.000000] [Firmware Bug]: TSC doesn't count with P0 frequency!
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000dffeffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000dfff0000-0x00000000dfffffff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000011fffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] APIC: Static calls initialized
[ 0.000000] SMBIOS 2.5 present.
[ 0.000000] DMI: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 0.000000] Hypervisor detected: KVM
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[ 0.000003] kvm-clock: using sched offset of 10798080598 cycles
~~Truncated~~
By examining the logs immediately before the kernel panic, you may be able to identify the cause of the panic. Be sure to review them carefully.
[ 16.063243] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 16.335907] e1000: enp0s8 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 29.213133] block dm-0: the capability attribute has been deprecated.
[ 2260.314000] sysrq: Trigger a crash
[ 2260.314468] Kernel panic - not syncing: sysrq triggered crash
[ 2260.314914] CPU: 0 PID: 1512 Comm: bash Kdump: loaded Not tainted 5.14.0-570.22.1.el9_6.x86_64 #1
[ 2260.315346] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 2260.315772] Call Trace:
[ 2260.316137] <TASK>
[ 2260.316483] dump_stack_lvl+0x34/0x48
[ 2260.316988] panic+0x107/0x2bb
[ 2260.317425] ? _printk+0x58/0x73
[ 2260.317858] sysrq_handle_crash+0x16/0x20
[ 2260.318294] __handle_sysrq.cold+0x7c/0x115
[ 2260.318752] write_sysrq_trigger+0x24/0x40
[ 2260.319219] proc_reg_write+0x56/0xa0
[ 2260.319677] ? srso_return_thunk+0x5/0x5f
[ 2260.320115] vfs_write+0xee/0x480
[ 2260.320600] ? syscall_exit_work+0x103/0x130
[ 2260.321069] ? srso_return_thunk+0x5/0x5f
bt
By running the bt command, you can view the backtrace, which shows the history of function calls leading up to the current point.
crash> bt
PID: 1512 TASK: ffff99b501edd280 CPU: 0 COMMAND: "bash"
#0 [ffffbadf4148fc60] machine_kexec at ffffffffa9881637
#1 [ffffbadf4148fcb8] __crash_kexec at ffffffffa9a0c4aa
#2 [ffffbadf4148fd78] panic at ffffffffaa4c6fc4
#3 [ffffbadf4148fdf8] sysrq_handle_crash at ffffffffaa00a386
#4 [ffffbadf4148fe00] __handle_sysrq.cold at ffffffffaa4f99ea
#5 [ffffbadf4148fe30] write_sysrq_trigger at ffffffffaa00aea4
#6 [ffffbadf4148fe40] proc_reg_write at ffffffffa9d0c126
#7 [ffffbadf4148fe58] vfs_write at ffffffffa9c678de
#8 [ffffbadf4148fee8] ksys_write at ffffffffa9c67fbf
#9 [ffffbadf4148ff20] do_syscall_64 at ffffffffaa5208df
#10 [ffffbadf4148ff50] entry_SYSCALL_64_after_hwframe at ffffffffaa600130
RIP: 00007fe3d80fe067 RSP: 00007ffda0decad8 RFLAGS: 00000246
RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fe3d80fe067
RDX: 0000000000000002 RSI: 00005562a423b3b0 RDI: 0000000000000001
RBP: 00005562a423b3b0 R8: 0000000000000000 R9: 00007fe3d8177aa0
R10: 00007fe3d81b0c40 R11: 0000000000000246 R12: 0000000000000002
R13: 00007fe3d81fa780 R14: 0000000000000002 R15: 00007fe3d81f59e0
ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b
crash>ps
By running the ps command, you can view a list of all processes that were active at the time of the panic.
crash> ps
PID PPID CPU TASK ST %MEM VSZ RSS COMM
0 0 0 ffffffffab61a8c0 RU 0.0 0 0 [swapper/0]
1 0 0 ffff99b500235280 IN 0.3 105088 13524 systemd
2 0 0 ffff99b500230000 IN 0.0 0 0 [kthreadd]
3 2 0 ffff99b500233700 IN 0.0 0 0 [pool_workqueue_]
4 2 0 ffff99b500231b80 ID 0.0 0 0 [kworker/R-rcu_g]
5 2 0 ffff99b500263700 ID 0.0 0 0 [kworker/R-sync_]
6 2 0 ffff99b500261b80 ID 0.0 0 0 [kworker/R-slub_]
7 2 0 ffff99b500265280 ID 0.0 0 0 [kworker/R-netns]
10 2 0 ffff99b500268000 RU 0.0 0 0 [kworker/u4:0]
11 2 0 ffff99b50026b700 ID 0.0 0 0 [kworker/R-mm_pe]
13 2 0 ffff99b500290000 ID 0.0 0 0 [rcu_tasks_kthre]
14 2 0 ffff99b500293700 ID 0.0 0 0 [rcu_tasks_rude_]
15 2 0 ffff99b500291b80 ID 0.0 0 0 [rcu_tasks_trace]
16 2 0 ffff99b500295280 IN 0.0 0 0 [ksoftirqd/0]
17 2 0 ffff99b5002b1b80 ID 0.0 0 0 [rcu_preempt]
task “PID”
By running the task command, you can check the state of a specific task by its PID.
In the example below, the command inspects the task with PID 1, which is systemd.
Here, __state = 1 (TASK_INTERRUPTIBLE) indicates that the task was in a normal waiting state.
crash> task 1
PID: 1 TASK: ffff99b500235280 CPU: 0 COMMAND: "systemd"
struct task_struct {
thread_info = {
flags = 2,
syscall_work = 0,
status = 0,
cpu = 0,
preempt_lazy_count = 0
},
__state = 1,
stack = 0xffffbadf40010000,
usage = {
refs = {
counter = 1
}
},
flags = 4194560,
ptrace = 0,
on_cpu = 0,
wake_entry = {
llist = {
next = 0x0
},
{
u_flags = 48,
kmem
By running the kmem command, you can view information about memory usage at the time of the panic.
By running the kmem -i command, you can view information about overall memory usage across the entire OS.
crash> kmem -i
PAGES TOTAL PERCENTAGE
TOTAL MEM 935936 3.6 GB ----
FREE 708275 2.7 GB 75% of TOTAL MEM
USED 227661 889.3 MB 24% of TOTAL MEM
BUFFERS 737 2.9 MB 0% of TOTAL MEM
CACHED 82091 320.7 MB 8% of TOTAL MEM
SLAB 15562 60.8 MB 1% of TOTAL MEM
TOTAL HUGE 0 0 ----
HUGE FREE 0 0 0% of TOTAL HUGE
TOTAL SWAP 541695 2.1 GB ----
SWAP USED 0 0 0% of TOTAL SWAP
SWAP FREE 541695 2.1 GB 100% of TOTAL SWAP
COMMIT LIMIT 1009663 3.9 GB ----
COMMITTED 465654 1.8 GB 46% of TOTAL LIMIT
crash>By running the kmem -s command, you can check memory usage within the kernel (slab allocator).
This is useful for identifying what is consuming large amounts of memory.
crash> kmem -s
CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
ffff99b507ba8200 232 0 0 0 4k nf_conntrack_expect
ffff99b507ba8800 248 14 32 2 4k nf_conntrack
ffff99b50a1b6000 200 0 0 0 4k nf-frags
ffff99b50a1b6600 152 0 0 0 4k fuse_request
ffff99b50a1b6a00 888 0 0 0 8k fuse_inode
ffff99b50a1b6300 528 0 0 0 8k xfs_dqtrx
ffff99b50a1b6700 480 0 0 0 4k xfs_dquot
ffff99b50a1b6900 176 0 23 1 4k xfs_iul_item
ffff99b50a1b6100 208 0 0 0 4k xfs_attri_item
ffff99b50a1b6d00 176 0 0 0 4k xfs_attrd_item
ffff99b50a1b6e00 208 0 285 15 4k xfs_bui_item
ffff99b50a1b6200 176 0 23 1 4k xfs_bud_item
ffff99b50a1b6800 432 0 72 8 4k xfs_cui_item
ffff99b50a1b6c00 176 0 23 1 4k xfs_cud_item
ffff99b50a1b6400 688 0 0 0 16k xfs_rui_item
ffff99b50a1b6500 176 0 0 0 4k xfs_rud_item
ffff99b50a1b6b00 184 0 22 1 4k xfs_icr
ffff99b50a1b6f00 200 596 1260 63 4k xfs_ili
ffff99b50a1c6b00 1032 4671 5370 358 16k xfs_inode
ffff99b50a1c6f00 432 0 45 5 4k xfs_efi_item
ffff99b50a1c6000 440 0 9 1 4k xfs_efd_item
ffff99b50a1c6600 272 0 90 6 4k xfs_buf_itemSummary
In this article, I explained how to collect a memory dump (vmcore) in Linux and covered the basic analysis methods using the crash command.
By using kdump, you can collect a memory dump even in the event of a kernel panic or system hang.
The captured vmcore can then be analyzed by combining it with kernel-debuginfo and the crash utility.
During analysis, using the basic commands—such as bt for checking backtraces, task and ps for understanding process states, and kmem -i / kmem -s for examining memory usage—allows you to systematically isolate and investigate the situation at the time of the failure.
Kernel dump analysis may seem daunting at first, but by proceeding in the order of overall overview → detailed inspection, it can be effectively applied in practical scenarios. Be sure to familiarize yourself with this approach.
English 
Japanese
コメント