단일 "rcu_sched 감지 CPU 정지" 경고가 시스템 로그에 나타나는 원인은 무엇입니까?

단일 "rcu_sched 감지 CPU 정지" 경고가 시스템 로그에 나타나는 원인은 무엇입니까?

환경: Linux [호스트 이름] 3.2.0-4-amd64 #1 SMP Debian 3.2.96-2 x86_64 GNU/Linux 하드웨어: AMD Opteron(tm) 프로세서 6344, 6x2MiB L2, 2x8MiB L3, 6코어 ht(논리 코어 12개) ) )

오늘 시스템 로그에 다음과 같은 경고가 표시되었습니다.

Feb 28 09:58:53 amalthea kernel: [4367033.060016] INFO: rcu_bh detected stall on CPU 10 (t=0 jiffies)
Feb 28 09:58:53 amalthea kernel: [4367033.060018] sending NMI to all CPUs:

다음은 CPU 상태 덤프입니다. 로그에는 이 문제를 일으키는 "나쁜" 내용이 없는 것 같습니다.

서버는 여전히 실행 중이고 (분명히) 정지된 프로세스 등이 없으며 경고가 발생한 후 한 시간 정도 동안 다시 발생하지 않았습니다.

좀 찾아봤는데RCU 스톨 감지기에 대한 정보(나에게는 너무 기술적이다.진짜이해합니다) 다음을 볼 수 있습니다.

  1. CPU가 멈췄어요t=0 jiffies
  2. CPU가 "감지되지 않음"

파일에는 이것이 거짓 긍정일 수 있음을 나타내는 설명이 있습니다.

["상태 덤프가 시작되기 전에 정지가 종료됨"]은 드물지만 실제로는 발생합니다. 도제로 패스트 스톨 플래그 지정 가능이 경우 정지 경고와 유예 기간 초기화가 상호 작용하는 방식에 따라 달라집니다. 이러한 유형의 문제에는 불필요한 stop_machine()과 같은 메서드를 사용하지 않고는 이 잘못된 긍정을 완전히 제거하는 것이 불가능하다는 점에 유의하세요.

(강조는 내 것)

"상태 덤프가 시작되기 전에 중지"라는 메시지는 표시되지 않지만 위에 표시된 두 로그 줄 뒤에 나타나는 대규모 CPU 덤프 외에는 진단 방식으로 다른 정보를 얻을 수 없는 것 같습니다.

도움이 된다면 CPU 덤프에서 더 많은 정보를 게시할 수 있습니다. 전문가는 아니지만 아무것도 찾지 못했습니다.

이 문제의 원인은 무엇입니까? t=0 jiffies로그에 추가 진단 정보를 인쇄하지 않고 데이터 포인트만을 기준으로 거짓 긍정을 얻을 수 있습니까 ?

(이 질문은 다음과 다릅니다.rcu_sched가 CPU 정지를 감지했습니다., 이는 "실제 문제"를 나타내는 것 같습니다. )

답변1

이는 다음 세 가지 이유 중 하나로 인해 발생할 가능성이 높습니다.

  1. 트리거하기 어려운 커널 버그입니다. 그러나 RCU는 커널의 핵심이므로 거의 모든 사람이 버그에 직면할 가능성이 높기 때문에 이것이 가능하지 않다고 생각합니다.
  2. 나쁜 기억. 불량 메모리 모듈로 인한 메모리 손상으로 인해 이와 같은 이상한 일이 쉽게 발생할 수 있습니다.
  3. 메모리 자체 이외의 이유로 발생하는 일시적인 메모리 오류입니다. 위와 비슷하지만 다시 일어날 가능성은 없습니다. 이는 ECC 메모리가 방지하려고 시도하는 유형입니다(그러나 ECC 로직에서 문제가 전적으로 가능하기 때문에 완전히는 아닙니다).

이런 일이 다시 발생하지 않는 한 아마도 이것이 사례 3이라고 가정하고 계속 진행할 수 있습니다. 이런 일이 다시 발생하면 주변 커널 메시지에서 유사점을 찾거나 RAM을 확인하십시오.

답변2

NVidia Jetson 보드에서 이 오류(CPU 정지)가 발생했습니다.

NVidia와 대화하고 Jetson을 조사한 후 일부 카드가 Bluetooth 장치를 통해서만 초당 80,000개의 인터럽트를 수신하고 있음을 발견했습니다. 이 장치에 해당하는 모듈을 비활성화하면 CPU가 정지되는 것을 방지할 수 있습니다.

수신 중인 인터럽트 수를 확인하려면 /proc/interrupts를 확인하세요. RJ45도 사용되기 때문에 중단이 발생하고 인터럽트가 너무 많아 Linux 커널 교착 상태가 발생합니다(이것은 커널 자체가 아닐 수도 있지만 Bluetooth를 처리하는 드라이버에 주의하세요). 및 RJ45).

다음은 "net" 또는 "ip"를 참조하는 여러 함수를 볼 수 있는 예입니다. 또한 el1_irqIRQ가 처리 중이라는 메시지 도 표시됩니다 .

따라서 Austin의 목록을 기반으로 (1)에 정의된 문제가 있습니다.

Feb  1 08:53:16 ve5 kernel: [ 1459.074481] INFO: rcu_preempt self-detected stall on CPU
Feb  1 08:53:16 ve5 kernel: [ 1459.074646]      0-...: (8 GPs behind) idle=ea9/140000000000001/0 softirq=32059/32059 fqs=2112 
Feb  1 08:53:16 ve5 kernel: [ 1459.074794]       (t=5250 jiffies g=10249 c=10248 q=48)
Feb  1 08:53:16 ve5 kernel: [ 1459.074906] Task dump for CPU 0:
Feb  1 08:53:16 ve5 kernel: [ 1459.074926] ksoftirqd/0     R  running task        0     3      2 0x00000002
Feb  1 08:53:16 ve5 kernel: [ 1459.074943] Call trace:
Feb  1 08:53:16 ve5 kernel: [ 1459.074963] [<ffffff800808bdb8>] dump_backtrace+0x0/0x198
Feb  1 08:53:16 ve5 kernel: [ 1459.074972] [<ffffff800808c37c>] show_stack+0x24/0x30
Feb  1 08:53:16 ve5 kernel: [ 1459.074983] [<ffffff80080ecf70>] sched_show_task+0xf8/0x148
Feb  1 08:53:16 ve5 kernel: [ 1459.074991] [<ffffff80080efc70>] dump_cpu_task+0x48/0x58
Feb  1 08:53:16 ve5 kernel: [ 1459.075001] [<ffffff80081c1acc>] rcu_dump_cpu_stacks+0xb8/0xec
Feb  1 08:53:16 ve5 kernel: [ 1459.075012] [<ffffff8008132450>] rcu_check_callbacks+0x728/0xa48
Feb  1 08:53:16 ve5 kernel: [ 1459.075020] [<ffffff8008138cac>] update_process_times+0x34/0x60
Feb  1 08:53:16 ve5 kernel: [ 1459.075030] [<ffffff800814a218>] tick_sched_handle.isra.5+0x38/0x70
Feb  1 08:53:16 ve5 kernel: [ 1459.075037] [<ffffff800814a29c>] tick_sched_timer+0x4c/0x90
Feb  1 08:53:16 ve5 kernel: [ 1459.075044] [<ffffff80081399e0>] __hrtimer_run_queues+0xd8/0x360
Feb  1 08:53:16 ve5 kernel: [ 1459.075051] [<ffffff800813a330>] hrtimer_interrupt+0xa8/0x1e0
Feb  1 08:53:16 ve5 kernel: [ 1459.075061] [<ffffff8008bffe98>] arch_timer_handler_phys+0x38/0x58
Feb  1 08:53:16 ve5 kernel: [ 1459.075071] [<ffffff8008126f10>] handle_percpu_devid_irq+0x90/0x2b0
Feb  1 08:53:16 ve5 kernel: [ 1459.075078] [<ffffff80081214f4>] generic_handle_irq+0x34/0x50
Feb  1 08:53:16 ve5 kernel: [ 1459.075085] [<ffffff8008121bd8>] __handle_domain_irq+0x68/0xc0
Feb  1 08:53:16 ve5 kernel: [ 1459.075092] [<ffffff8008080d44>] gic_handle_irq+0x5c/0xb0
Feb  1 08:53:16 ve5 kernel: [ 1459.075099] [<ffffff8008082c28>] el1_irq+0xe8/0x194
Feb  1 08:53:16 ve5 kernel: [ 1459.075108] [<ffffff8008231de4>] kmem_cache_alloc+0x114/0x2c0
Feb  1 08:53:16 ve5 kernel: [ 1459.075118] [<ffffff8008db94a4>] dst_alloc+0x6c/0xb0
Feb  1 08:53:16 ve5 kernel: [ 1459.075127] [<ffffff8008df6a2c>] rt_dst_alloc+0x74/0xe8
Feb  1 08:53:16 ve5 kernel: [ 1459.075134] [<ffffff8008df7ca0>] ip_route_input_noref+0x3c0/0x8f8
Feb  1 08:53:16 ve5 kernel: [ 1459.075144] [<ffffff8008e34a00>] arp_process+0x3e8/0x708
Feb  1 08:53:16 ve5 kernel: [ 1459.075152] [<ffffff8008e34e70>] arp_rcv+0x118/0x1a8
Feb  1 08:53:16 ve5 kernel: [ 1459.075161] [<ffffff8008da9c20>] __netif_receive_skb_core+0x3b8/0xad8
Feb  1 08:53:16 ve5 kernel: [ 1459.075169] [<ffffff8008dad010>] __netif_receive_skb+0x28/0x78
Feb  1 08:53:16 ve5 kernel: [ 1459.075175] [<ffffff8008dad08c>] netif_receive_skb_internal+0x2c/0xb0
Feb  1 08:53:16 ve5 kernel: [ 1459.075182] [<ffffff8008dadcb4>] napi_gro_receive+0x15c/0x188
Feb  1 08:53:16 ve5 kernel: [ 1459.075192] [<ffffff800894dd90>] eqos_napi_poll_rx+0x358/0x430
Feb  1 08:53:16 ve5 kernel: [ 1459.075199] [<ffffff8008daf2e4>] net_rx_action+0xf4/0x358
Feb  1 08:53:16 ve5 kernel: [ 1459.075206] [<ffffff8008081054>] __do_softirq+0x13c/0x3b0
Feb  1 08:53:16 ve5 kernel: [ 1459.075215] [<ffffff80080baf38>] run_ksoftirqd+0x48/0x58
Feb  1 08:53:16 ve5 kernel: [ 1459.075225] [<ffffff80080e07c8>] smpboot_thread_fn+0x160/0x248
Feb  1 08:53:16 ve5 kernel: [ 1459.075232] [<ffffff80080dbe64>] kthread+0xec/0xf0
Feb  1 08:53:16 ve5 kernel: [ 1459.075239] [<ffffff80080838a0>] ret_from_fork+0x10/0x30

관련 정보