coredump를 이용하여 kernel crash에 대응하기
구동중인 OS가 갑자기 kernel panic등으로 crash되었을때, crashdump를 이용하면 crash되었을때의 memory를 file로 dump할 수 있다. system log등에 아무런 기록이 없을때 이 crashdump 파일은 문제 원인을 파악하는데 큰 도움을 준다.
kernel(OS) crash의 원인
먼저 kernel crash의 원인이 살펴보자. crash는 kernel(os)이 스스로 제어/복구 할 수 없는 상황이 되었을때 발생한다. kernel이 error(event)를 감지하였을때 Linux의 경우 kernel panic, Windows의 경우 BSOD(Blue Screen Of Death)등을 console에 띄우고, 더이상 진행할 수 없으므로 장렬히 전사(hang/reboot)하게 되는것이다. 원인은 매우 다양하다.
- RAM 불량 : 물리적으로 메모리가 불량인 경우인데, 경험적으론 생각보다 꽤 많이 발생했다. 모든 프로그램이 메모리에 적제되니 특정 경우와 관련없이 random하게 발생한다. 이 경우 memtest86+(http://www.memtest.org/)를 이용하여 문제가 없는지 확인할 수 있다. 다만, 검사소요시간이 꽤나 긴 편이었다.
- 그밖의 장치(device) 문제 : Graphic Card, Network Card, Disk(Raid controller) 등 하드웨어 관련된 이슈이다. 물리적으로 불량일 경우도 있겠고, 그를 제어하는 firmware/driver의 문제일수도 있다. 후자의 경우 firwamre/driver update(patch)를 통해 문제를 해결할 수 있으니 관련 change log등을 찾아보자.
- Software 이슈 : kernel이나 그 Module (예를 들어, filesystem의 module), 혹은 특정 process의 문제(bug)일수도 있다. 이 역시 소프트웨어 문제이므로 그와 관련한 bug report, changelog 등을 찾아 update(patch)함으로 해결해야 한다.
원인 분석
위와 같이 hardware/firmware/software 에 걸쳐 발생할 수 있어, 원인을 분석하기가 쉽지 않다.
- 시스템 로그 확인 : 로그는 대부분의 문제를 파악하고 분석하는데 매우 큰 도움을 준다. os(kernel)가 /var/log/messages등의 시스템 로그에 관련 정보(error)를 남기진 않았는지 꼼꼼하게 살펴보자.
- BIOS event log 확인 : hardware의 경우라면 bios event log에 로그가 기록되어 있을 수 있다. bios 상에서 확인 가능하며 각 vendor사 마다 os/web에서 접근하도록 software를 배포하기도 한다.
- kernel crash dump 확인 : kernel이 crash되었을때 메모리를 image로 dump하여 이 dump된 image를 분석할 수도 있다.
위에서 언급했듯, 이 문서는 마지막의 kernel crash dump로 확인하는 방법에 대해 다룰것이다.
crash dump
kexec
kexec를 이용하면 현재 커널에서 BIOS, 부트로더 등을 거치지 않고 새로운 커널로 부팅 할 수 있다. 이는 crash dump에서 매우 중요한 역할을 한다. kernel crash가 발생했을 경우 kexec를 이용하여 새로운 커널(second kernel, capture kernel)로 부팅을 하게 되고, 메모리를 dump하는것이다. 단, kexec를 실행하기 위해선 second kernel이 load될 메모리가 미리 설정되어 있어야 한다.
설치 과정은 아래와 같다.
# apt-get install kexec-tools
# vi /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=256M"
# update-grub
grub에서의 kernel parameter에 crashkernel을 추가한다. 이제 second kernel은 256M 메모리를 가지고 부팅될 것이다. 메모리는 initrd와 사용하는 kernel module양에 따라서 다르다. 그리고 dump시 필터링을 담당하는 makedumpfile에서 물리적 메모리에 비례(4K당 2bit)하여 사용한다고 한다. 이에 맞게끔 설정해야하니 테스트가 꼭 필요하겠다. 다른 kdump 문서를 보면 crashkernel을 auto로 설정한 경우를 볼수 있는데, 이는 일반 커널일 경우이다. auto라면 기본 128M에서 총 물리메모리의 양에 비례하여 알아서 설정해한다고 한다.
이제 리부팅하여 crashkernel을 예약하자.
# reboot
아래의 명령으로 crashkernel이 잘 잡혀있는지 확인할수 있다.
# cat /proc/cmdline
root=/dev/sda5 ro quiet crashkernel=256M
# grep -i crash /proc/iomem
03000000-0affffff : Crash kernel
이제 kexec를 사용할 환경은 마련되었다. 새로운 커널을 load해보자.
# cat /sys/kernel/kexec_loaded
0
# kexec -l --command-line="root=/dev/sda5 ro quiet" --initrd=/boot/initrd.img-3.16.0-4-amd64 /boot/vmlinuz-3.16.0-4-amd64
# cat /sys/kernel/kexec_loaded
1
보면 알겠지만 bootloader에서 설정한 그대로를 넣으면 된다. kernel과 initrd를 지정하고, kernel parameter를 command-line에 옵션으로 추가한다. load가 정상적으로 진행된다면 /sys/kernel/kexec_loaded가 1로 변경되어 있을것이다.
이제 load된 2nd kernel를 실행해보자.
# kexec -e
정상적으로 실행된다면 콘솔화면으로 2nd kernel로 부팅되는것을 볼수 있다. free 명령으로 memory를 보면 256M로 잡혀있는것을 확인할수 있다.
그러나 위 방법은 panic시 kexec가 수행되지 않는다. kexec로 -l (load)대신 -p (load-panic)을 수행하면 panic시 load될 kernel을 지정할수 있다.
# kexec -p --command-line="root=/dev/sda5 ro quiet" --initrd=/boot/initrd.img-3.16.0-4-amd64 /boot/vmlinuz-3.16.0-4-amd64
# cat /sys/kernel/kexec_crash_loaded
kexec_loaded가 아닌 kexec_crash_loaded로 load여부를 확인할 수 있다. (일반적으로 capture kernel을 load할때 kernel parameter값으로 “irqpoll maxcpus=1”을 추가하도록 권장한다.)
이제 적제된 커널로 부팅해보자. panic시 2nd kernel로 진입되도록 설정했으니 panic을 일으키면 된다. sysrq를 이용한다.
# echo c > /proc/sysrq_trigger
정상적으로 처리된다면 2nd kernel로 부팅되는것을 확인할수 있을것이다. 위처럼 crash로 등록되어 진입할 경우에는 전과 다르게 /proc/vmcore라는 파일이 생성됨을 확인할수 있을것이다. 파일 사이즈는 “총 메모리의 양 - crashkernel(256M)”일 것이다. 이게 memory dump파일이다. 이 파일을 DISK로 복사하면 dumpfile을 얻을수 있다.
사실 위 kexec만으로도 dump는 가능하다. 그런데 kernel panic시 dumpfile을 옮기고 리부팅하는 작업을 직접 수동으로 처리해야한다. 따라서 위 작업을 스크립트로 생성해 놓고 등록해둬야 한다. 대략적으로 아래와 같겠다.
- 부팅시 kexec -p 등록
- 만약 /proc/vmcore가 있다면 (2nd kernel로 진입한다면) 2-1. /proc/vmcore를 다른 partition으로 복사 2-2. reboot -f
kdump-tools
kdump-tools를 사용하면 더 간단히 진행할 수 있다. 즉 kdump-tools는 kexec -p 작업과 dumpfile을 처리하고 reboot하는 작업 등을 설정파일을 이용하여 간단히 설정 할수 있게 도와준다.
# apt-get install kdump-tools
kdump-tools를 설치하게 되면 kexec-tools, makedumpfiles가 dependacy로 걸려있다. kexec-tools는 알겠고, makedumpfiles는? /proc/vmcore에 필터링을 걸수 있게 한다. 즉 용량이 매우 큰 vmcore를 그대로 복사하지 않고, 필요한 부분만 골라 복사하도록 하는 것이다. 이때 filtering 기능에따라 debug kernel이 필요할 수도 있다고 한다. (debug kernel은 dump file을 분석할때도 필요함). 물론 압축을 한다던지 그런 기능들도 모두 포함되어 있다.
# vi /etc/default/kdump-tools
USE_KDUMP=1
#KDUMP_KERNEL=
#KDUMP_INITRD=
KDUMP_COREDIR="/var/crash"
#KDUMP_CMDLINE_APPEND="irqpoll maxcpus=1 nousb systemd.unit=kdump-tools.service"
#DEBUG_KERNEL=
#MAKEDUMP_ARGS="-c -d 31"
위의 설정말고도 많지만 그냥 default를 이용해도 대부분은 정상작동 할것이다. 위처럼 #(comment out)으로 처리했을경우 grub등에서 parsing해와 알아서 등록해준다.
설정에 대한 확인도 kdump-config를 이용하면 편리하다.
# kdump-config show
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr:
current state: Ready to kdump
kernel link:
/usr/lib/debug/boot/vmlinux-3.16.0-4-amd64
kexec command:
/sbin/kexec -p --command-line="placeholder root=UUID=bf86b836-d9c9-4e68-8613-cc7ba3c56895 ro quiet irqpoll maxcpus=1 nousb systemd.unit=kdump-tools.service" --initrd=/boot/initrd.img-3.16.0-4-amd64 /boot/vmlinuz-3.16.0-4-amd64
# kdump-config load
[ ok ] loaded kdump kernel.
이제 sysrq를 이용하여 crash를 유발하면 2nd kernel로 진입됨을 확인할수 있다. /proc/vmcore를 /var/crash로 복사하는데 설정값에 따라 아까 언급한 makedumpfiles로 filtering을 걸수도 있다. scp, ftp등으로 원격으로 파일을 복사하게 설정할수도 있다. 위와 같이 설정했다면 /var/crash/YYYYMMDD 디렉토리에 dumpfile을 생성한뒤, reboot을 진행한다.
XEN에서의 crash dump
아래의 내용은 debian jessie(kernel 3.16.7) , xen 4.4에서 테스트를 진행하였다.
DomU의 crash dump
일반적인 Linux와 같이 위와 같이 설정하면 된다. (PVM의 경우 작동하지 않을수 있다. 확인필요)
In guest kexec works for PVHVM/HVM guests but does not work for PV guests. 출처 : https://lists.xen.org/archives/html/xen-devel/2014-04/msg01708.html
그러나 아래와 같이 xen configure파일을 설정하면 훨씬 간편히 처리할 수 있다.
on_crash="coredump-restart"
vm이 crash되었을 경우 coredump를 찍고 restart한다. coredump는 dom0의 /var/xen/dump에 저장된다. makedumpfiles을 이용하여 filtering하지 않으니 VM Memory양만큼 dumpfile이 생성될것이다.
이제 crash 툴로 원인을 분석하면 된다.
Dom0의 crash dump
Dom0의 경우 일반적인 crash dump설정과는 다르다. xen의 경우 xen micro kernel -> Linux(Dom0) Kernel로 부팅이 된다. 자 이럴 경우 crashkernel parameter를 어디에 둬야 할까? 또 kexec load할 kernel은 xen kernel일까? linux kernel일까? 공식문서 (http://xenbits.xen.org/docs/4.4-testing/misc/kexec_and_kdump.txt) 를 참고하면 다 된다고 한다. 즉 아래와 같다.
- first xen kernel -> first linux(dom0) kernel -> (kexec, crash) -> 2nd xen kernel -> 2nd linux kernel
- first xen kernel -> first linux(dom0) kernel -> (kexec, crash) -> 2nd linux kernel
그런데 테스트해본바로는 첫번째경우는 정상적으로 처리되지 않았다. (사실 저 문서가 엄청 오래되었다. 문서대로 진행되는 경우가 한개도 없다;;) 그리고 생각해보면 구지 첫번째와 같이 처리할 이유가 없다. 예약하는 메모리양만 많아질뿐… crashkernel의 경우는 xen커널의 parameter값으로 들어가야한다.
여기서부턴 시행착오가 많았다. 정리된 문서도 없을 뿐더러, 정리된 문서는 죄다 예전 문서여서인지 제대로 실행되지 않았다. 그만큼 오류가 많을수 있다. 참고하길 바란다.
crashkernel 등록
xen kernel의 parameter로 등록하면 된다.
# vi /etc/default/grub
GRUB_CMDLINE_XEN="dom0_max_vcpus=2 dom0_vcpus_pin crashkernel=256M"
# update-grub
생성된 grub.cfg는 아래와 같은 모양새일것이다.
multiboot /boot/xen-4.4-amd64.gz placeholder dom0_max_vcpus=2 dom0_vcpus_pin crashkernel=256M dom0_mem=2G,max:3G
module /boot/vmlinuz-3.16.0-4-amd64 placeholder root=UUID=bf86b836-d9c9-4e68-8613-cc7ba3c56895 ro quiet
module --nounzip /boot/initrd.img-3.16.0-4-amd64
여러 문서들에서 xen 커널의 parameter로 등록하라고 나와있었다. (http://www.gossamer-threads.com/lists/xen/devel/353159 , ) linux(dom0) kernel의 parameter로 설정해보았는데, 정상적으로 2nd kernel이 load되지 않았다. (segmentation fault) crashkernel옵션을 crashkernel=256M@64M와 같이 size@offset으로도 설정할 수 있다. 몇몇 시스템의 경우는 offset을 지정하지 않았을 경우 문제가 된다고 한다. offset은 메모리예약의 시작점이다. offset을 지정하면 해당 사이즈(physical address기준)부터 시작되어 메모리가 예약된다. > On some systems, it might be necessary to reserve memory with a certain fixed offset. If the offset is set, the reserved memory will begin there
linux kernel paramter로 등록하지 않았으니 dom0에서 확인도 달라진다. 예를 들면 /proc/cmdline과 dmesg에는 당연히 관련 메시지가 없을것이다. 이건 xen console에서 확인할 수 있다.
# xl dmesg | grep -i command
(XEN) Command line: placeholder dom0_max_vcpus=1 dom0_vcpus_pin crashkernel=256M dom0_mem=2G,max:3G
# xl dmesg | grep -i kdump
(XEN) Kdump: 256MB (262144kB) at 0x46db29000
그리고 xl info명령으로 확인해보면 total_memory에서 256M가 더 빠져있음을 확인할 수 있다.
kexec-tools 설치
jessie의 공식 repo에 있는 kexec-tools를 설치하였는데, 정상적으로 처리되지 않았다. grub등에서 crashkernel을 먼저 등록하라는 error message만 뜬다. Dom0(linux)의 kexec에선 xen kernel의 parameter로 설정한 crashkernel을 읽어들일수 없는 것이다. 여기서 한동안 진도가 나가지 않았었는데, 간단했다. compile을 진행하니 정상적으로 처리되는것이다. kexec는 내부적으로 xen 관련 소스가 있는데 공식 repo에 있는 package는 이걸 포함하지 않았다. compile시 –with-xen 옵션을 줘야한다. 설치 이후에는 일반적인 kexec-tools와 동일하게 작동했다. kexec -p로 등록, sysrq로 crash 유발, dump 생성, crash로 분석.. 모두 정상적으로 잘 된다.
kdump-tools 설치
kdump에서 또 문제가 발생한다. 오류는 위와 동일하다. crashkernel을 인식못하는 문제이다. kdump에선 아래의 부분을 확인하는데 모두 fail났다.
- /sys/kernel/kexec_crash_loaded 확인 원래 1로 변경되야하는데 Dom0에서는 변경되지 않았다. 이부분은 kexec-tools와 연관있어보이는데, 찾질 못했다.
- /proc/cmdline에서의 crashkernel 인자값 확인 이 부분을 보면 xen에서의 설정을 고려하지 않았음을 알수 있다.
일단 kdump-tools process가 위 문제로 구동되지 않는다. /usr/sbin/kdump-tools를 수정하여 check하는 부분을 주석처리하여 skip하도록 변경하였다.
case "$1" in
test)
DRY_RUN="true"
#check_kdump_support;
locate_debug_kernel;
locate_kdump_kernel;
kdump_load;
kdump_test
;;
show)
DRY_RUN="true"
#check_kdump_support;
kdump_show
;;
load)
#check_kdump_support;
locate_debug_kernel;
locate_kdump_kernel;
kdump_load;
;;
또 하나 발견한 문제는 makedumpfile 부분에서이다. 가상화서버라면 많은 memory를 사용할텐데 이러면 dumpfile도 매울 클것이다. 그런데 다른 모든 VM들의 memory까지 dump할 필요는 없다. makedumpfile manpage를 보니 아래와 같은 설정할수도 있다.
-X Exclude all the user domain pages from Xen kdump's VMCORE, and extracts the part of xen and domain-0. If VMCORE con‐
tains VMCOREINFO for Xen, it is not necessary to specify --xen-syms and --xen-vmcoreinfo. -E option must be speci‐
fied with this option.
Example:
# makedumpfile -E -X /proc/vmcore dumpfile
수동으로 위와 같이 실행해보았는데 결과는 segmentation fault이다……. 2nd kernel을 dom0로 설정해야하는건인가? 아직 이부분은 해결되지 않았다.
issue
일부서버에서 아래와 같은 이슈가 발견되었다. crash시 2nd kernel loading까지 잘 넘어가는데 그 후 바로 kernel panic이 발생하고 진행되지 않았다.
[ 102.721579] SysRq : Trigger a crash
[ 102.725118] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 102.732986] IP: [<ffffffff8136ffc2>] sysrq_handle_crash+0x12/0x20
[ 102.739102] PGD 1719cc067 PUD 1719e0067 PMD 0
[ 102.743616] Oops: 0002 [#1] SMP
[ 102.746891] Modules linked in: openvswitch gre vxlan xen_gntdev xen_evtchn xenfs xen_privcmd nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver nfs lockd sunrpc fscache bridge stp llc intel_powerclamp coretemp crc32_pclmul ghash_clmulni_intel cdc_ether aesni_intel usbnet xfs iTCO_wdt iTCO_vendor_support mii evdev aes_x86_64 ttm lrw drm_kms_helper gf128mul glue_helper ablk_helper cryptd drm lpc_ich serio_raw pcspkr mfd_core shpchp i2c_i801 tpm_tis button tpm i7core_edac ioatdma edac_core processor thermal_sys blktap(O) ipmi_watchdog ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler fuse drbd lru_cache libcrc32c autofs4 ext4 crc16 mbcache jbd2 btrfs xor raid6_pq dm_mod md_mod sg sr_mod sd_mod cdrom ata_generic crc32c_intel ata_piix libata lpfc crc_t10dif crct10dif_generic ehci_pci uhci_hcd ehci_hcd megaraid_sas usbcore usb_common crct10dif_pclmul scsi_transport_fc scsi_tgt igb i2c_algo_bit scsi_mod i2c_core crct10dif_common dca ptp pps_core bnx2
[ 102.834663] CPU: 0 PID: 1009 Comm: bash Tainted: G O 3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1+deb8u5
[ 102.844652] Hardware name: IBM System x3650 M3 -[794552K]-/00D4062, BIOS -[D6E157AUS-1.15]- 06/13/2012
[ 102.853951] task: ffff880171baa190 ti: ffff8801707f8000 task.ti: ffff8801707f8000
[ 102.861427] RIP: e030:[<ffffffff8136ffc2>] [<ffffffff8136ffc2>] sysrq_handle_crash+0x12/0x20
[ 102.869972] RSP: e02b:ffff8801707fbec0 EFLAGS: 00010282
[ 102.875284] RAX: 000000000000000f RBX: ffffffff818a4d20 RCX: 0000000000000000
[ 102.882413] RDX: ffff88017f40eda0 RSI: ffff88017f40d478 RDI: 0000000000000063
[ 102.889546] RBP: 0000000000000063 R08: 0000000000000437 R09: ffffffff81a6e0fc
[ 102.896675] R10: 0000000000000437 R11: 0000000000000003 R12: 0000000000000000
[ 102.903804] R13: 0000000000000004 R14: 0000000000000001 R15: 0000000000000000
[ 102.910936] FS: 00007fde82297700(0000) GS:ffff88017f400000(0000) knlGS:0000000000000000
[ 102.919019] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 102.924763] CR2: 0000000000000000 CR3: 0000000172955000 CR4: 0000000000002660
[ 102.931894] Stack:
[ 102.933913] ffffffff8137067c 0000000000000002 0000000000e2e408 0000000000000002
[ 102.941390] ffff8801707fbf58 ffffffff81370b1b ffff880171406640 ffffffff81206919
[ 102.948866] ffff8801707fbf58 ffff8801715a7500 ffffffff811a8212 ffff8800028bbe00
[ 102.956344] Call Trace:
[ 102.958798] [<ffffffff8137067c>] ? __handle_sysrq+0xfc/0x160
[ 102.964541] [<ffffffff81370b1b>] ? write_sysrq_trigger+0x2b/0x30
[ 102.970636] [<ffffffff81206919>] ? proc_reg_write+0x39/0x70
[ 102.976297] [<ffffffff811a8212>] ? vfs_write+0xb2/0x1f0
[ 102.981609] [<ffffffff811a8d52>] ? SyS_write+0x42/0xa0
[ 102.986833] [<ffffffff8151168d>] ? system_call_fast_compare_end+0x10/0x15
[ 102.993705] Code: f8 ff ff 44 01 ed 41 39 6c 24 34 75 de 4c 89 e7 e8 24 f8 ff ff eb d4 66 90 66 66 66 66 90 c7 05 c5 57 6f 00 01 00 00 00 0f ae f8 <c6> 04 25 00 00 00 00 01 c3 0f 1f 44 00 00 66 66 66 66 90 53 8d
[ 103.013988] RIP [<ffffffff8136ffc2>] sysrq_handle_crash+0x12/0x20
[ 103.020188] RSP <ffff8801707fbec0>
[ 103.023678] CR2: 0000000000000000
[ 103.027077] ---[ end trace 9e2de84d1f3c78f2 ]---
[ 103.031795] Kernel panic - not syncing: Fatal exception
[ 103.042388] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
[ 0.000000] do_IRQ: 0.124 No irq handler for vector (irq -1)
[ 0.003389] do_IRQ: 0.172 No irq handler for vector (irq -1)
[ 0.616731] ERST: Can not request [mem 0x7f6ef000-0x7f6f0bff] for ERST.
Loading, please wait...
[ 1.027158] Kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
[ 1.039064] CPU: 0 PID: 63 Comm: systemd-udevd Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1+deb8u5
[ 1.048625] Hardware name: IBM System x3650 M3 -[794552K]-/00D4062, BIOS -[D6E157AUS-1.15]- 06/13/2012
[ 1.057927] ffff880476753aa8 ffffffff8150b4c5 ffffffff8174ad60 ffffffff8150831d
[ 1.065395] 0000000000000008 ffff880476753ab8 ffff880476753a58 0000005000000000
[ 1.072864] 0000000000000000 0000000000000000 0000000000001000 0000000000000002
[ 1.080333] Call Trace:
[ 1.082781] [<ffffffff8150b4c5>] ? dump_stack+0x41/0x51
[ 1.088094] [<ffffffff8150831d>] ? panic+0xc8/0x1fc
[ 1.093060] [<ffffffff812cdfbd>] ? swiotlb_tbl_map_single+0x2bd/0x2c0
[ 1.099588] [<ffffffff81185ccd>] ? alloc_pages_current+0x9d/0x150
[ 1.105768] [<ffffffff812ce6f5>] ? swiotlb_alloc_coherent+0xd5/0x140
[ 1.112207] [<ffffffffa0364b79>] ? uhci_start+0x139/0x5b8 [uhci_hcd]
[ 1.118648] [<ffffffffa0232154>] ? usb_add_hcd+0x2f4/0x870 [usbcore]
[ 1.125089] [<ffffffffa0243a49>] ? usb_hcd_pci_probe+0x189/0x530 [usbcore]
[ 1.132048] [<ffffffff812e2fbf>] ? local_pci_probe+0x3f/0xa0
[ 1.137792] [<ffffffff812e42aa>] ? pci_device_probe+0xda/0x130
[ 1.143710] [<ffffffff813a2d9d>] ? driver_probe_device+0x9d/0x3d0
[ 1.149890] [<ffffffff813a319b>] ? __driver_attach+0x8b/0x90
[ 1.155635] [<ffffffff813a3110>] ? __device_attach+0x40/0x40
[ 1.161378] [<ffffffff813a0e9b>] ? bus_for_each_dev+0x5b/0x90
[ 1.167211] [<ffffffff813a2430>] ? bus_add_driver+0x180/0x250
[ 1.173045] [<ffffffffa036b000>] ? 0xffffffffa036afff
[ 1.178184] [<ffffffff813a38eb>] ? driver_register+0x5b/0xe0
[ 1.183929] [<ffffffffa036b0c3>] ? uhci_hcd_init+0xc3/0x1000 [uhci_hcd]
[ 1.190629] [<ffffffff8100213c>] ? do_one_initcall+0xcc/0x200
[ 1.196463] [<ffffffff810daeca>] ? load_module+0x20da/0x26b0
[ 1.202207] [<ffffffff810d6ab0>] ? store_uevent+0x40/0x40
[ 1.207693] [<ffffffff810db5fd>] ? SyS_finit_module+0x7d/0xa0
[ 1.213527] [<ffffffff8151168d>] ? system_call_fast_compare_end+0x10/0x15
[ 1.220404] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)
[ 1.230574] ---[ end Kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer
특이한점은 kexec -l로 loading후 kexec -e로 excute하면 정상적으로 2nd kernel 구동이 가능했다. crashkernel로 진입할 때가 문제인듯 보인다.
아래와 같이 crashkernel의 주소(offset)를 manual로 설정하니 정상적으로 작동했다. offset을 설정하므로 kdump로 예약되는 물리주소가 fix하게 변경됨을 확인할수 있다.
# xl dmesg | grep -i crashkernel
placeholder dom0_max_vcpus=4 dom0_vcpus_pin crashkernel=256M@64M dom0_mem=4G,max:5G crashkernel=256M@64M
# xl dmesg | grep -i kdump
(XEN) Kdump: 256MB (262144kB) at 0x4000000
이처럼 시스템에 따라 kdump가 제대로 작동하지 않을수 있다. kdump 설정을 한뒤에는 crash를 유발하여 꼭 테스트를 진행해봐야 할 듯 하다.