Linux 커널 패닉의 원인 확인

Ubuntu 12.04 파생 제품 (amd64)을 실행 중이며 최근에 정말 이상한 문제가 발생했습니다. 파란색에서 X가 잠시 (1-3 분?) 완전히 정지 한 다음 시스템이 재부팅됩니다. 이 시스템은 오버 클럭킹되었지만 Windows에서 확인 된대로 매우 안정적이므로 커널 패닉이나 모듈 중 하나에 문제가 있다고 생각합니다. Linux에서도 LINPACK을 실행할 수 있으며 CPU에 엄청난 부하를 주더라도 충돌이 발생하지 않습니다. 기계가 유휴 상태 인 경우에도 충돌이 무작위로 발생하는 것 같습니다.

시스템 충돌을 어떻게 디버깅 할 수 있습니까?

독점적 인 NVIDIA 드라이버 일 수 있다는 생각에 안정된 버전의 드라이버 버전 304로 되돌 렸으며 여전히 충돌이 발생합니다.

누구든지 충돌 후 좋은 디버깅 절차를 안내해 줄 수 있습니까? 썸 드라이브로 부팅하고 충돌 후 구성 파일을 모두 게시하게되어 기쁩니다. 그 파일이 무엇인지 잘 모르겠습니다. 시스템 충돌 원인을 어떻게 알 수 있습니까?

다음은 일반적인 범인의 로그입니다.

.xsession-errors : http://pastebin.com/EEDtVkVm

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

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

/ var / log / syslog : http://pastebin.com/9Fkp3FMz

충돌 사고 기록을 전혀 찾지 못하는 것 같습니다.

충돌을 트리거하는 것은 그렇게 간단하지 않습니다. GPU가 한 번에 여러 항목을 그리려고 할 때 발생하는 것 같습니다. YouTube 동영상을 전체 화면으로 표시하고 잠시 반복하거나 수많은 GIF를 스크롤하면 Skype 알림이 표시되는 경우가 가끔 있습니다. 이 머리에 머리를 완전히 긁 었어.

CPU는 4.8GHz로 오버 클럭되었지만, 완전히 안정적이며 어제 한 번의 충돌없이 엄청난 LINPACK 실행과 9 시간의 Prime95에서 살아 남았습니다.

최신 정보

내가 설치 한 kdump, crash그리고 linux-crashdump뿐만 아니라 내 커널 버전 3.2.0-35에 대한 커널 디버그 기호. 내가 실행하면 apport-unpack온 커널 파일을 추락하고 crash온 VmCore충돌 덤프, 여기에 내가 무엇을보고입니다 :

      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

어떤 아이디어?

시작해야 할 두 가지 제안이 있습니다.

당신이 좋아하지 않을 첫 번째. 오버 클럭킹 시스템이 얼마나 안정적이라고 생각하든 그것은 나의 첫 용의자 일 것입니다. 그리고 당신이 문제를보고하는 개발자는 같은 것을 말할 것입니다. 안정적인 테스트 워크로드가 반드시 동일한 지침을 사용하지 않아도 메모리 하위 시스템에 많은 스트레스를줍니다. 오버 클럭킹을 중지하십시오. 사람들이 문제가 오버 클로킹이 아니라고 생각하게하려면 오버 클로킹하지 않을 때 문제가 발생하도록하여 버그 리포트를 깨끗하게 얻을 수 있습니다. 이것은 다른 사람들이이 문제를 해결하기 위해 얼마나 많은 노력을 기울일 것인지에 큰 차이를 만들 것입니다. 버그가없는 소프트웨어를 사용하는 것은 자부심의 대상이지만, 특히 의심스러운 하드웨어 설정을 가진 사람들의 보고서는 실제 버그와 전혀 관련이없는 시간 낭비입니다.

두 번째는 oops 데이터를 얻는 것입니다.이 데이터는 언급 한 곳으로 가지 않습니다. X11을 실행하는 동안 충돌이 발생하면 로컬 콘솔이 거의 작동하지 않는다고 생각합니다 (어쨌든 고통 스럽습니다). 직렬 콘솔, 네트워크 또는 로컬 디스크 (이보다 까다로운 저장)를 통해이 작업을 수행해야합니다 신뢰할 수없는 커널이 파일 시스템을 손상시키지 않기 때문에 들릴 수 있습니다). 이를 수행하는 몇 가지 방법이 있습니다.

• netdump 를 사용 하여 네트워크를 통해 서버에 저장하십시오. 나는 몇 년 동안 이것을하지 않았 으므로이 소프트웨어가 여전히 현대 커널과 관련이 있고 확실하지는 않지만 확실하게 가치가 있습니다.
• 시리얼 콘솔을 사용하여 부팅 ; 구식 컴퓨터 또는 USB 직렬 어댑터에 상관없이 두 컴퓨터 모두에 무료 직렬 포트와 널 모뎀 케이블이 필요합니다. 출력을 저장하도록 다른 머신을 구성합니다.
• kdump 는 오늘날 멋진 아이들이 사용하는 것처럼 보이며 설정이 복잡해 보이기 때문에 선호하지는 않지만 유연합니다. 요컨대, 무엇이든 할 수 있고 이전 커널의 메모리 내용을 검사 할 수있는 다른 커널을 부팅하는 것이 필요하지만 전체 프로세스를 본질적으로 빌드해야하며 거기에 많은 통조림 옵션이 표시되지 않습니다. 업데이트 : 실제로 좋은 배포판이 있습니다. 우분투에서 linux-crashdump

디버그 정보를 얻으면 ksymoops 라는 도구 를 사용하여 주소를 기호 이름으로 바꾸고 커널이 어떻게 충돌하는지 알 수 있습니다. 그리고 기호화 된 덤프가 당신에게 아무런 의미가 없다면, 적어도 여기 또는 Linux 배포의 메일 링리스트 / 버그 추적기에보고하는 것이 도움이됩니다.

에서 crash당신의 크래시 덤프에, 당신은 입력을 시도 할 수 log와 bt비트 더 많은 정보를 (일들이 공포와 스택 백 트레이스 중에 기록) 얻을 수 있습니다. 그래도 당신 Fatal Machine check은 여기 에서 오는 것 같습니다 . 코드를 감추는 과정에서 프로세서가 하드웨어 문제인 Machine Check Exception을 보고했습니다 . 다시 말하지만, 내 첫 번째 베팅은 오버 클럭킹 때문입니다. 더 많은 것을 알 수있는 더 구체적인 메시지가 log출력에있는 것처럼 보입니다 .

또한이 코드에서 mce=3커널 매개 변수로 부팅하면 충돌이 멈추는 것처럼 보이지만 진단 단계를 제외하고는 권장하지 않습니다. 리눅스 커널이이 오류가 무너질 가치가 있다고 생각한다면 아마 옳을 것입니다.

a) rsyslog 데몬이 커널 메시지를 파일에 기록하고 있는지 확인

vi /etc/rsyslog.conf

그리고 다음을 추가하십시오

kern.*                 /var/log/kernel.log

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

/etc/initd.d/rsyslog restart

b)로드 된 모듈을 기록해 두십시오

`lsmod >/your/home/dir`

c) 공황을 재현 할 수 없으므로 일어날 때까지 기다리십시오.

d) 패닉이 발생하면 라이브 또는 비상 CD를 ​​사용하여 시스템을 부팅합니다

및 / 집에 별도의 파일 시스템이 아닌 경우 / var에 전자) 파일 시스템을 마운트 (보통 /는 영향을받는 시스템) 충분 ( pvs, vgs, lvs명령은 LV를 불러옵니다 영향을받는 시스템에 LVM을 사용하는 경우 실행해야) mount -t ext4 /dev/sdXN /mnt

f) /mnt/var/log/디렉토리로 이동 하여 kernel.log파일을 확인 하십시오. 이것은 특정 모듈이나 다른 것에 패닉이 발생하는지 알아낼 수있는 충분한 정보를 제공합니다.

프로세서가 오버 클럭 되었습니까? BIOS의 오버 클로킹 메뉴에서 멀티 플라이어를 사용할 때 오늘도 이와 동일한 문제가있었습니다. 20 배 정도의 다양한 승수로 인해 이런 일이 발생합니다. 나는 그것을 18.5x (3.7GHz)로 낮추었 고 문제는 사라졌다. 마더 보드 / 전원 문제인 것 같습니다.

프로세서 문제는 TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [하드웨어 오류] : PROCESSOR 0 : 206a7 TIME 1357862746 SOCKET 0 APIC 1 마이크로 코드 28입니다. 프로세서 0은 커널이 충돌을 처리하는 데 사용한 것입니다. (멀티 CPU 시스템의 문제) 및 소켓 0은 문제가되는 프로세서입니다 (단 1을 가지고 있다고 가정하지만). 잘못되었거나 오버 클럭킹을 기록한 것처럼 결함의 원인이됩니다. 나는 당신이 prime95를 통해 그것을 받았다고 말했지만 시스템이 몇 살인 지에 대한 더 많은 정보가 없기 때문에 몇 가지 빨대를 잡고 열 페이스트가 어떻게 보이며 LGA를 확인했는지 확인했다. CPU) 괜찮아 보입니까? LGA에서 구부러진 핀이나 페이스트가 있다고 생각합니다. 여기서도 근본 원인이됩니다.

그래도 문제가 해결되지 않으면 SMBIOS를 사용하여 패닉이 정확히 발생하는 위치를 찾을 수 있습니다 .TSC 539b174de9d ADDR 3fe98d264ebd MISC 1은 기본적으로 SMBIOS 데이터이며 충돌이 발생한 위치를 보여줍니다. 기계가 가동되면 명령 행에서 echo "TSC 539b174de9d ADDR 3fe98d264ebd MISC 1"| sudo mcelog --ascii --dmi는 출력을 얻습니다. 이것은 하드웨어 오류 및 처리중인 DIMM을 알려줍니다. 이는 DIMM 장애가 그러나 충돌은 CPU를 가리 킵니다.

우리는 오래된 장비에 mikrotik 라우터를 설치했습니다. 팬이 회전을 멈추고 프로세서가 가열되었습니다. 그런 다음 라우터는 때때로 커널 패닉을 시작합니다. CPU 팬을 교체 한 후 모든 것이 잘 진행되었습니다.

머신 오버 클러킹 때문에 가능한 원인 일 수 있습니다.