☰

Linux 커널 패닉의 원인 확인

tag-icon • tag-icon kernel kernel-modules kernel-panic crash
Linux 커널 패닉의 원인 확인

저는 Ubuntu 12.04 파생 버전(amd64)을 실행하고 있는데 최근에 매우 이상한 문제에 직면했습니다. 예기치 않게 X가 잠시 동안(1~3분?) 완전히 정지된 후 시스템이 재부팅됩니다. 시스템이 오버클럭되었지만 Windows에서 매우 안정적인 것으로 확인되었습니다. 이로 인해 커널 패닉이 발생하거나 모듈 중 하나에 문제가 발생한 것으로 생각됩니다. Linux에서도 높은 CPU 로드에도 불구하고 충돌 없이 LINPACK을 실행할 수 있습니다. 컴퓨터가 유휴 상태일 때에도 충돌이 무작위로 발생하는 것처럼 보입니다.

시스템 충돌의 원인을 어떻게 디버깅할 수 있나요?

이것이 독점적인 NVIDIA 드라이버일지도 모른다는 예감을 갖고 해당 드라이버의 안정적인 버전(버전 304)으로 되돌렸지만 여전히 충돌이 발생했습니다.

충돌 후 올바른 디버깅 절차를 안내해 줄 수 있는 사람이 있습니까? 나는 썸 드라이브를 부팅하고 모든 충돌 후 구성 파일을 게시하고 싶지만 그것이 무엇인지 잘 모르겠습니다. 시스템 충돌의 원인이 무엇인지 어떻게 알 수 있나요?

일반적으로 범인이 되는 로그 묶음입니다.

.xsession-오류:http://pastebin.com/EEDtVkVm

/var/log/Xorg.0.log:http://pastebin.com/ftsG5VAn

/var/log/kern.log:http://pastebin.com/Hsy7jcHZ

/var/log/시스템 로그:http://pastebin.com/9Fkp3FMz

사고기록조차 아예 찾을 수가 없어요.

충돌을 유발하는 것은 그리 간단하지 않으며 GPU가 동시에 여러 항목을 그리려고 할 때 발생하는 것 같습니다. YouTube 비디오를 전체 화면으로 재생하고 잠시 동안 반복하거나 여러 GIF를 스크롤하고 Skype 알림 팝업이 표시되면 충돌이 발생하는 경우가 있습니다. 나는 이것에 대해 완전히 혼란스러워합니다.

CPU는 4.8GHz로 오버클럭되었지만 완전히 안정적이며 어제 LINPACK 실행과 9시간의 Prime95 테스트 중에 충돌이 발생하지 않았습니다.

고쳐 쓰다

내 커널 버전 3.2.0-35에 대한 커널 디버그 기호와 kdump, crash, 및 을 설치했습니다 . 충돌이 발생한 커널 파일을 실행한 다음 충돌 덤프를 실행 linux-crashdump하면 다음과 같은 결과가 표시됩니다 .apport-unpackcrashVmCore

      KERNEL: /usr/lib/debug/boot/vmlinux-3.2.0-35-generic
    DUMPFILE: Downloads/crash/VmCore
        CPUS: 8
        DATE: Thu Jan 10 16:05:55 2013
      UPTIME: 00:26:04
LOAD AVERAGE: 2.20, 0.84, 0.49
       TASKS: 614
    NODENAME: mightymoose
     RELEASE: 3.2.0-35-generic
     VERSION: #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012
     MACHINE: x86_64  (3499 Mhz)
      MEMORY: 8 GB
       PANIC: "[ 1561.519960] Kernel panic - not syncing: Fatal Machine check"
         PID: 0
     COMMAND: "swapper/5"
        TASK: ffff880211251700  (1 of 8)  [THREAD_INFO: ffff880211260000]
         CPU: 5
       STATE: TASK_RUNNING (PANIC)

log유틸리티에서 실행하면 crash로그 하단에 다음이 표시됩니다.

[ 1561.519943] [Hardware Error]: CPU 4: Machine Check Exception: 5 Bank 3: be00000000800400
[ 1561.519946] [Hardware Error]: RIP !INEXACT! 33:<00007fe99ae93e54> 
[ 1561.519948] [Hardware Error]: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 
[ 1561.519950] [Hardware Error]: PROCESSOR 0:206a7 TIME 1357862746 SOCKET 0 APIC 1 microcode 28
[ 1561.519951] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 1561.519953] [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 3: be00000000800400
[ 1561.519955] [Hardware Error]: TSC 539b174de9d ADDR 3fe98d264ebd MISC 1 
[ 1561.519957] [Hardware Error]: PROCESSOR 0:206a7 TIME 1357862746 SOCKET 0 APIC 0 microcode 28
[ 1561.519958] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 1561.519959] [Hardware Error]: Machine check: Processor context corrupt
[ 1561.519960] Kernel panic - not syncing: Fatal Machine check
[ 1561.519962] Pid: 0, comm: swapper/5 Tainted: P   M     C O 3.2.0-35-generic #55-Ubuntu
[ 1561.519963] Call Trace:
[ 1561.519964]  <#MC>  [<ffffffff81644340>] panic+0x91/0x1a4
[ 1561.519971]  [<ffffffff8102abeb>] mce_panic.part.14+0x18b/0x1c0
[ 1561.519973]  [<ffffffff8102ac80>] mce_panic+0x60/0xb0
[ 1561.519975]  [<ffffffff8102aec4>] mce_reign+0x1f4/0x200
[ 1561.519977]  [<ffffffff8102b175>] mce_end+0xf5/0x100
[ 1561.519979]  [<ffffffff8102b92c>] do_machine_check+0x3fc/0x600
[ 1561.519982]  [<ffffffff8136d48f>] ? intel_idle+0xbf/0x150
[ 1561.519984]  [<ffffffff8165d78c>] machine_check+0x1c/0x30
[ 1561.519986]  [<ffffffff8136d48f>] ? intel_idle+0xbf/0x150
[ 1561.519987]  <<EOE>>  [<ffffffff81509697>] ? menu_select+0xe7/0x2c0
[ 1561.519991]  [<ffffffff815082d1>] cpuidle_idle_call+0xc1/0x280
[ 1561.519994]  [<ffffffff8101322a>] cpu_idle+0xca/0x120
[ 1561.519996]  [<ffffffff8163aa9a>] start_secondary+0xd9/0xdb

bt출력 역추적:

PID: 0      TASK: ffff880211251700  CPU: 5   COMMAND: "swapper/5"
 #0 [ffff88021ed4aba0] machine_kexec at ffffffff8103947a
 #1 [ffff88021ed4ac10] crash_kexec at ffffffff810b52c8
 #2 [ffff88021ed4ace0] panic at ffffffff81644347
 #3 [ffff88021ed4ad60] mce_panic.part.14 at ffffffff8102abeb
 #4 [ffff88021ed4adb0] mce_panic at ffffffff8102ac80
 #5 [ffff88021ed4ade0] mce_reign at ffffffff8102aec4
 #6 [ffff88021ed4ae40] mce_end at ffffffff8102b175
 #7 [ffff88021ed4ae70] do_machine_check at ffffffff8102b92c
 #8 [ffff88021ed4af50] machine_check at ffffffff8165d78c
    [exception RIP: intel_idle+191]
    RIP: ffffffff8136d48f  RSP: ffff880211261e38  RFLAGS: 00000046
    RAX: 0000000000000020  RBX: 0000000000000008  RCX: 0000000000000001
    RDX: 0000000000000000  RSI: ffff880211261fd8  RDI: ffffffff81c12f00
    RBP: ffff880211261e98   R8: 00000000fffffffc   R9: 0000000000000f9f
    R10: 0000000000001e95  R11: 0000000000000000  R12: 0000000000000003
    R13: ffff88021ed5ac70  R14: 0000000000000020  R15: 12d818fb42cfe42b
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
--- <MCE exception stack> ---
 #9 [ffff880211261e38] intel_idle at ffffffff8136d48f
#10 [ffff880211261ea0] cpuidle_idle_call at ffffffff815082d1
#11 [ffff880211261f00] cpu_idle at ffffffff8101322a

어떤 아이디어가 있나요?

답변1

시작하려면 두 가지 제안이 있습니다.

당신은 첫 번째 것을 좋아하지 않을 것입니다. 오버클럭된 시스템이 아무리 안정적이라고 생각하더라도 이것이 첫 번째 의심입니다. 문제를 보고하는 개발자라면 누구나 같은 말을 할 것입니다. 안정적인 테스트 워크로드가 반드시 동일한 명령을 사용하는 것은 아니므로 어쨌든 메모리 하위 시스템에 동일한 양의 스트레스를 가합니다. 오버클럭을 중단하세요. 사람들이 문제가 오버클럭으로 인해 발생한 것이 아니라고 믿게 하려면 오버클럭을 하지 않을 때 발생하도록 하여 깨끗한 오류 보고서를 얻을 수 있도록 하십시오. 이는 다른 사람들이 문제를 해결하기 위해 얼마나 많은 노력을 기울이는지에 큰 영향을 미칠 것입니다. 버그 없는 소프트웨어를 갖는다는 것은 자랑스러운 일이지만, 특히 하드웨어 설정에 문제가 있는 사람들의 보고서는 실망스럽고 시간 낭비일 수 있으며 실제 버그와 전혀 관련이 없을 수도 있습니다.

두 번째는 당신이 언급한 곳으로 이동하지 않는 죄송한 데이터를 얻는 것입니다. 실행 중에만 충돌이 발생하는 경우에는 신뢰할 수 없는 커널이 파일 시스템을 손상시키는 것을 원하지 않기 때문에 생각보다 낫습니다. 다음은 몇 가지 방법입니다.

  • 사용네트워크 덤프네트워크를 통해 서버에 저장합니다. 나는 몇 년 동안 이 작업을 수행해 본 적이 없기 때문에 이 소프트웨어가 여전히 존재하고 최신 커널에서 작동하는지 확신할 수 없지만 간단하고 시도해 볼 가치가 있습니다.
  • 직렬 콘솔 사용을 시작합니다(보관된 버전,현재 버전), 두 컴퓨터(이전 컴퓨터 또는 USB 직렬 어댑터)에 작동하는 직렬 포트가 필요하고, 출력을 저장하도록 다른 컴퓨터를 구성할 수 있는 널 모뎀 케이블이 필요합니다.
  • 덤프 파일요즘 멋진 아이들이 사용하는 것 같고 꽤 유연해 보이지만 설정이 복잡해 보이기 때문에 내 취향은 아닙니다. 간단히 말해서 무엇이든 할 수 있는 다른 커널을 시작하고 이전 커널의 메모리 내용을 확인하는 작업이 포함되지만 기본적으로 전체 프로세스를 빌드해야 하며 고정된 옵션이 많이 보이지 않습니다.  고쳐 쓰다:실제로 우분투에는 linux-crashdump라는 좋은 배포판이 있습니다.보관된 버전,현재 버전).

디버그 정보가 있으면 ksymoops(보관된 버전,현재 버전 (광고 포함)) 이를 사용하여 주소를 기호 이름으로 변환하고 커널이 어떻게 충돌하는지 이해할 수 있습니다. 기호 덤프가 아무런 의미가 없다면 최소한 여기나 Linux 배포판의 메일링 리스트/버그 추적기에 보고하는 것이 도움이 될 것입니다.

crash크래시 덤프 에서 입력을 시도 log하고 bt추가 정보(패닉 및 스택 추적 중에 기록된 정보)를 얻을 수 있습니다. 당신의 Fatal Machine check출신인 것 같아요여기, 하지만. 코드를 탐색하면 프로세서가 보고합니다.기계 점검 예외- 하드웨어 문제. 다시 말하지만, 나의 첫 번째 내기는 오버클러킹 때문입니다. log더 자세한 내용을 알려주는 더 구체적인 메시지가 출력에 있을 수 있는 것 같습니다 .

또한 해당 코드에서 mce=3커널 매개변수로 부팅하면 충돌이 중지됩니다. 하지만 진단 단계를 제외하고는 권장하지 않습니다. Linux 커널이 이 버그가 충돌할 가치가 있다고 생각한다면 아마도 맞을 것입니다.

답변2

a) rsyslog 데몬이 커널 메시지를 파일에 기록하는지 확인합니다.

vi /etc/rsyslog.conf

그리고 다음을 추가하세요

kern.*                 /var/log/kernel.log

rsyslog서비스를 다시 시작하십시오 .

/etc/initd.d/rsyslog restart

b) 로드된 모듈을 기록해 둡니다.

`lsmod >/your/home/dir`

c) 패닉은 재현될 수 없으므로 패닉이 발생할 때까지 기다립니다.

d) 긴급 상황 발생 시 Live 또는 긴급 CD를 사용하여 시스템을 부팅합니다.

pvse) 영향을 받는 시스템의 파일 시스템을 마운트합니다(/var 및 /home이 별도의 파일 시스템이 아닌 경우 일반적으로 /로 충분합니다). (LVM을 시작하기 위해 영향을 받는 시스템에서 LVM을 사용하는 경우 명령을 실행해야 합니다 vgs.)lvsmount -t ext4 /dev/sdXN /mnt

f) /mnt/var/log/해당 디렉토리 로 이동하여 kernel.log파일을 확인합니다. 이를 통해 특정 모듈이나 다른 모듈에서 긴급 상황이 발생했는지 판단할 수 있는 충분한 정보를 얻을 수 있습니다.

답변3

프로세서가 오버클럭되었나요? 현재 BIOS의 오버클러킹 메뉴에서 승수를 사용할 때 동일한 문제에 직면했습니다. 약 20x의 다양한 승수로 인해 이런 일이 발생합니다. 18.5x(3.7GHz)로 낮췄더니 문제가 사라졌습니다. 마더보드/전원 공급 장치 문제인 것 같습니다.

답변4

이전 장치에 mikrotik 라우터를 설치했습니다. 팬이 회전을 멈추고 프로세서가 과열됩니다. 그런 다음 라우터는 때때로 커널 패닉을 일으키기 시작했습니다. CPU 팬을 교체한 후 모든 것이 순조롭게 진행되었습니다.

컴퓨터를 오버클러킹하고 있으므로 이것이 원인일 수 있습니다.

관련 정보