Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

인텔® 제온® 프로세서 E5, 인텔® 제온® 프로세서 E5 v2 또는 인텔® 제온® 프로세서 E7 v2 와 레드햇 엔터프라이즈 리눅스 6 커널의 특정 버전에서 시스템이 중단 / 무응답 또는 커널 패닉이 발생합니다

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 6.1 (kernel-2.6.32-131.26.1.el6 and newer)
  • Red Hat Enterprise Linux 6.2 (kernel-2.6.32-220.4.2.el6 and newer)
  • Red Hat Enterprise Linux 6.3 (kernel-2.6.32-279 series)
  • Red Hat Enterprise Linux 6.4 (kernel-2.6.32-358 series)
  • 다음 어떠한 시리즈 Intel® Xeon® E5, Intel® Xeon® E5 v2, or Intel® Xeon® E7 v2
  • 본 이슈는 64비트 커널 환경에서 확인되고있습니다. 위에 언급한 32비트 커널 버전 또한 본 이슈에 해당되는 것에 유의하시기 바랍니다.
RHEL6.2 kernel version CPU model
2.6.32-220.42.1.el6.x86_64 Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
RHEL6.3 kernel version CPU model
2.6.32-279.19.1.el6.x86_64 Intel(R) Xeon(R) CPU E5-2440 0 @ 2.40GHz
2.6.32-279.22.1.el6.x86_64 Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
2.6.32-279.22.1.el6.x86_64 Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
RHEL6.4 kernel version CPU model
2.6.32-358.el6.x86_64 Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
2.6.32-358.0.1.el6.x86_64 Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
2.6.32-358.6.1.el6.x86_64 Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz
2.6.32-358.6.2.el6.x86_64 Intel(R) Xeon(R) CPU E5-2650L 0 @ 1.80GHz
2.6.32-358.6.2.el6.x86_64 Intel(R) Xeon(R) CPU E5-2603 0 @ 1.80GHz
2.6.32-358.15.1.el6.x86_64 Intel(R) Xeon(R) CPU E5-4617 0 @ 2.90GHz
2.6.32-358.18.1.el6.x86_64 Intel(R) Xeon(R) CPU E5-4617 0 @ 2.90GHz
2.6.32-358.18.1.el6.x86_64 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz

Issue

인터럽트 불가능한 'D' 상태 에서 차단된 프로세스에서 시스템이 응답하지 않거나, 커널 패닉 'hung_task : blocked tasks'을 유발합니다. 아주 드문 상황에서, 0으로 나누기를 시도하기 때문에 커널이 충돌합니다. 일어날 수 있는 증상에 대한 자세한 내용은 진단 단계 섹션을 참조 하십시오. 이 문제는 다음 모든 조건을 충족하는 경우에 발생합니다.

  • Red Hat private Bug 765720 에서 이 변경을 포함한 Red Hat Enterprise Linux 6 커널은 웜 부팅됩니다. (예 : 'shutdown - r' command ) :
[ sched ] x86 : Avoid unnecessary overflow in sched_clock
  • Intel ® Xeon ® E5 시리즈 시스템에서 커널이 웜 부팅 된다.

  • 장기간 (대략 200 일 이상) 전원 사이클 (하드 리셋) 하지 않는 시스템에서 커널이 웜 부팅 된다.

이것은 200일 이상 가동 시간 여부가 커널에 영향을 주는 것이 아니라는 점에 유의 하십시오. 실제로 200일 이상 '하드웨어의 가동 시간' 후 웜 부팅 문제가 발생합니다. 이 문제는 웜 부팅 후 임의의 시점에서 발생 , 일반적으로 몇 분에서 몇 시간의 범위 내입니다.

기본적으로 클럭 소스를 KVM 클럭으로 설정 하는 KVM 게스트는 (RHEL KVM 호스트와 RHEV - H 하이퍼 바이저) 이 문제 의 영향을 받지 않습니다. 다른 가상화 플랫폼은 플랫폼 공급 업체 에 문의하십시오.

업스트림 커널 버전 2.6.18 을 바탕으로 한 Red Hat Enteprise Linux 5 커널은 이 문제의 영향을 받지 않습니다.

이 문제를 일으키기 쉬운 Red Hat Enterprise Linux 6 커널 버전에 대한 자세한 내용은 시스템 구성 섹션을 참조 하십시오.

Resolution

이 문제는 다음 커널 업데이트에서 해결되었습니다.

  • RHEL 6.5 kernel-2.6.32-431.el6. 이 패키지는 다음 에라타에서 확인 가능합니다. RHSA-2013:1645. 관련 Red Hat private Bug는 BZ#975507입니다.
  • RHEL 6.4.z EUS kernel-2.6.32-358.23.2.el6. 이 패키지는 다음 에라타에서 확인 가능합니다. RHSA-2013:1436. 관련 Red Hat private Bug는 BZ#1001954입니다.
  • RHEL 6.3.z EUS kernel-2.6.32-279.37.2.el6. 이 패키지는 다음 에라타에서 확인 가능합니다. RHSA-2013:1450. 관련 Red Hat private Bug는 BZ#1004185입니다.
  • RHEL 6.2.z EUS kernel-2.6.32-220.45.1.el6. 이 패키지는 다음 에라타에서 확인 가능합니다. RHSA-2013:1519. 관련 Red Hat private Bug는 BZ#1024453입니다.

Root Cause

Intel ® Xeon ® Processor E5 Family 6 Model 45 (일명 SandyBridge)에서 웜 리셋에 의해 Time Stamp Counter (TSC)가 초기화되지 않습니다. 이것은 Intel® Xeon® Processor E5 Family Specification Update에 에라타 BT81 로 설명되어 있습니다. 이 에라텀은 아래 사항 을 포함한 모든 Red Hat Enterprise Linux 6 커널 에 영향을줍니다.

Intel® Xeon® Processor E5 v2 Family 6 Model 62 (also known as IvyBridge)에서 웜 리셋에 의해 Time Stamp Counter (TSC)가 초기화되지 않습니다. 이것은 Intel® Xeon® Processor E5 v2 Family Specification 에라타 CA105 에 업데이트 되었습니다.

Intel® Xeon® Processor E7 v2 Family 6 Model 62 (also known as IvyBridge-EX), 웜 리셋에 의해 Time Stamp Counter (TSC)가 초기화되지 않습니다. 이것은 Intel® Xeon® E7-2800/4800/8800 v2 Product Family Specification Update 에라타 CF101 에 업데이트 되었습니다.

[ sched ] x86 : Avoid unnecessary overflow in sched_clock ( ... ) [ 765720 ]

이 변경은 시스템 시작시 TSC 가 초기화 되는 것을 요구하고 있습니다. 그렇지 않으면, 스케줄링에 관련된 커널의 'cyc2ns_offset' 테이블의 값이 대략 200 일 이상 장기간 전원을 끄지 않는 (하드 리셋 ) 시스템에서 조차도 초기화 되지 않습니다 . 이 테이블의 값이 잘못되면 문제진단 단계에 설명된 것 처럼, 다양한 증상을 일으킵니다.

Intel Xeon E5 에라타 BT81 를 해결 하기위한 해결책으로 다음과 같은 업스트림이 커밋되었습니다.

2353b47bffe4e6ab39042f470c55d41bb3ff3846
Round the calculated scale factor in set_cyc2ns_scale ( )

9993bc635d01a6ee7f6b833b4ee65ce7c06350b1
sched/x86 : Fix overflow in cyc2ns_offset

커널 cyc2ns_offset 테이블에 있는 값의 정확도에 의존하지 않기 때문에 기본적으로 클럭 소스 를 KVM 클럭으로 설정 하는 KVM 게스트는 (RHEL KVM 호스트 와 RHEV-H 하이퍼 바이저) 이 문제의 영향을 받지 않습니다.

게스트 커널의 웜 부팅 후 하이퍼 바이저가 가상 컴퓨터를 에뮬레이트 혹은 제공하는 TSC 값에 의존하여 다른 가상화 플랫폼에서 이 문제가 발생할 수 있거나 없습니다.

cyc2ns_offset 테이블이 존재 하지 않기 때문에, 업스트림 커널 버전 2.6.18 을 바탕으로 한 Red Hat Enterprise Linux 5 커널은 이 문제의 영향을 받지 않습니다.

Diagnostic Steps

  • /proc/cpuinfo을 확인합니다. 다음과 같이, CPU 제품군, 모델 이름을 검색합니다.
...
cpu family      : 6
model           : 45
model name      : Intel(R) Xeon(R) CPU E5-2650L 0 @ 1.80GHz
...

다음 증상의 조합이 이 문제의 특징으로 알려져 있습니다.

  • 이 문제에 영향을 주는 시스템은 콘솔 및 '/var/log/messages'에 다음과 같은 일련의 메시지가 기록 될 수 있습니다. 콜 트레이스에서 'do_execve()', 'sched_exec()' 및 'wait_for_completion()' 함수를 확인하십시오.
INFO: task bash:12543 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash          D 0000000000000012     0 12543  12542 0x00000084
ffff880c343b3ce8 0000000000000082 ffff880c343b3d98 ffffffffffffffe9
ffff880c343b3c88 ffffffffa00c9129 ffff880c343f4aa0 0000010100000015
ffff880c343f5058 ffff880c343b3fd8 000000000000fb88 ffff880c343f5058
Call Trace:
[<ffffffffa00c9129>] ? ext4_check_acl+0x29/0x90 [ext4]
[<ffffffffa008fbf0>] ? ext4_file_open+0x0/0x130 [ext4]
[<ffffffff8150ea05>] schedule_timeout+0x215/0x2e0
[<ffffffff8117e514>] ? nameidata_to_filp+0x54/0x70
[<ffffffff81277379>] ? cpumask_next_and+0x29/0x50
[<ffffffff8150e683>] wait_for_common+0x123/0x180
[<ffffffff81063310>] ? default_wake_function+0x0/0x20
[<ffffffff8150e79d>] wait_for_completion+0x1d/0x20
[<ffffffff8106513c>] sched_exec+0xdc/0xe0
[<ffffffff8118a0a0>] do_execve+0xe0/0x2c0
[<ffffffff810095ea>] sys_execve+0x4a/0x80
[<ffffffff8100b4ca>] stub_execve+0x6a/0xc0

만일, 시스템이 중단 된 것처럼 보일 때, 혹은 vmcore (강제 크래시 덤프)을 취득한 경우는 crash 유틸리티를 사용하여 실행 큐와 커널 'cyc2ns_offset' 테이블을 확인합니다.

  • 실행 큐는 조정되기 때문에 적어도 실시간 우선 순위 실행 큐 중 하나에는 예약 할 수 없는 'migration' 스레드가 포함됩니다. 이렇게 하면 차단 된 작업이 'migration' 스레드의 서비스를 계속 기다리고 버리기 때문에 위에 표시되는 'task ... blocked for more than ... seconds' 메시지가 발생합니다.
crash> runq
...
CPU 1 RUNQUEUE: ffff88002be36700
  CURRENT: PID: 0      TASK: ffff88013d523540  COMMAND: "swapper"
  RT PRIO_ARRAY: ffff88002be36888
     [  0] PID: 7      TASK: ffff88013d905500  COMMAND: "migration/1"
     [  0] PID: 10     TASK: ffff88013d522ae0  COMMAND: "watchdog/1"
...
crash> pd ((struct rq *)0xffff88002be36700)->rt.rt_throttled
$1 = 1
  • CPU0에 포함 된 'cyc2ns_offset' 테이블 항목은 나머지 테이블 항목과는 다릅니다. 나머지 항목은 일반적으로 003이 포함됩니다 (10bit가 지워집니다).
crash> px cyc2ns_offset
PER-CPU DATA TYPE:
  unsigned long long per_cpu__cyc2ns_offset;
PER-CPU ADDRESSES:
  [0]: ffff88002be0cb40
  [1]: ffff88002be2cb40
  [2]: ffff88002be4cb40
  [3]: ffff88002be6cb40

crash> rd -x 0xffff88002be0cb40
ffff88002be0cb40:  fffa751c3c9e4b76
crash> rd -x 0xffff88002be2cb40
ffff88002be2cb40:  003a751c3c9e4b76
crash> rd -x 0xffff88002be4cb40
ffff88002be4cb40:  003a751c3c9e4b76
crash> rd -x 0xffff88002be6cb40
ffff88002be6cb40:  003a751c3c9e4b76

매우 드문 상황에서 find_busiest_group() 함수 내에서 0으로 나누는 문제의 대부분을 해결하는 패치 (BZ # 785959)가 RHEL6.3과 RHEL6.4 커널에 포함되어 있는데도 불구하고,이 버그로 인해 나누기가 발생합니다.

PID: 0      TASK: ffff881034a45500  CPU: 5   COMMAND: "swapper"
 #0 [ffff8800456a38f0] machine_kexec at ffffffff81035d6b
 #1 [ffff8800456a3950] crash_kexec at ffffffff810c0d42
 #2 [ffff8800456a3a20] oops_end at ffffffff81511870
 #3 [ffff8800456a3a50] die at ffffffff8100f19b
 #4 [ffff8800456a3a80] do_trap at ffffffff815110d4
 #5 [ffff8800456a3ae0] do_divide_error at ffffffff8100cf7f
 #6 [ffff8800456a3b80] divide_error at ffffffff8100bdfb
    [exception RIP: find_busiest_group+1372]
    RIP: ffffffff81059abc  RSP: ffff8800456a3c30  RFLAGS: 00010246
    RAX: 0000000000000000  RBX: ffff8800456a3e34  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: 0000000000000000  RDI: ffff880045616700
    RBP: ffff8800456a3da0   R8: 0000000000000000   R9: 0000000000000040
    R10: 0000000000000000  R11: 0000000000000000  R12: 00000000ffffff01
    R13: 0000000000016700  R14: ffffffffffffffff  R15: 0000000000000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 #7 [ffff8800456a3da8] rebalance_domains at ffffffff81063536
 #8 [ffff8800456a3e78] run_rebalance_domains at ffffffff81063a1c
 #9 [ffff8800456a3ec8] __do_softirq at ffffffff81076fd1
#10 [ffff8800456a3f38] call_softirq at ffffffff8100c1cc
#11 [ffff8800456a3f50] do_softirq at ffffffff8100de05
#12 [ffff8800456a3f70] irq_exit at ffffffff81076db5
#13 [ffff8800456a3f80] scheduler_ipi at ffffffff8105b3de
#14 [ffff8800456a3fa0] smp_reschedule_interrupt at ffffffff8102df6a
#15 [ffff8800456a3fb0] reschedule_interrupt at ffffffff8100bd73
--- <IRQ stack> ---
...

어떤 프로세스에서 cpu soft lockup 이 발생할 가능성도 있습니다.

BUG: soft lockup - CPU#0 stuck for 67s! [migration/0:5]
BUG: soft lockup - CPU#0 stuck for 67s! [migration/0:5]
BUG: soft lockup - CPU#0 stuck for 67s! [migration/0:5]

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.