RCU 없이 dmesg 읽기 — 레벨·타임스탬프·반복 panic

임베디드에서 커널 링 버퍼를 볼 때 흔한 막힘은 메시지가 너무 많다, 언제 찍혔는지 헷갈린다, 같은 실패가 반복되는지 안 보인다입니다. RCU·스케줄러 내부까지 내려가지 않아도, loglevel · 타임스탬프 · 반복 패턴만으로도 1차 판독이 됩니다.

이 글의 축은 셋뿐입니다. 레벨은 어떻게 보나? · 타임스탬프는? · 반복 panic은 어떻게? 보드별 실측 일화·가격·제휴는 없습니다.

근거는 dmesg(1)(util-linux)와 커널 Message logging with printk입니다.

레벨은 어떻게 보나?

한 줄 답: printk 우선순위는 0(emerg)…7(debug) 이고, 숫자가 작을수록 더 심각합니다. 콘솔에 바로 나올지는 console_loglevel과 메시지 레벨의 비교로 결정됩니다. 읽기 단계에서는 dmesg -l / -x / -n으로 범위를 좁히십시오.

printk 문서의 레벨 표(요약):

이름문자열별칭
KERN_EMERG"0"pr_emerg()
KERN_ALERT"1"pr_alert()
KERN_CRIT"2"pr_crit()
KERN_ERR"3"pr_err()
KERN_WARNING"4"pr_warn()
KERN_NOTICE"5"pr_notice()
KERN_INFO"6"pr_info()
KERN_DEBUG"7"pr_debug() 등

실무 읽기 패턴(dmesg(1)):

# 에러·경고만 (예)
dmesg --level=err,warn

# err 이상(더 심각한 crit/alert/emerg 포함) — util-linux의 + 문법
dmesg --level=err+

# facility·priority 숫자를 사람이 읽는 접두로
dmesg -x

# 콘솔에 찍히는 하한만 바꾼다(링 버퍼 출력/클리어는 안 함)
dmesg -n 5
# 또는: echo … > /proc/sys/kernel/printk  (printk 문서)

주의할 점:

  1. 필터(-l)와 콘솔 레벨(-n)은 다른 축입니다. -l은 지금 화면에 무엇을 보여줄지, -n은 앞으로 콘솔에 무엇을 올릴지입니다.
  2. 메시지가 링 버퍼에 남는 것과 콘솔에 즉시 보이는 것은 분리됩니다. printk 문서는 우선순위가 console_loglevel보다 높으면(숫자로는 더 작으면) 콘솔에 찍힌다고 설명합니다.
  3. BusyBox dmesg는 util-linux보다 옵션이 적을 수 있습니다. 타깃에서 dmesg --help 로 지원 플래그를 확인하십시오.
  4. dmesg_restrict 등으로 권한 거부가 날 수 있습니다(dmesg(1) EXIT STATUS · syslog(2)).

하지 말 것: “우리 보드에서는 level 3만 보면 된다” 같은 창작 보드 규칙으로 일반화하기. 기본값은 커널 설정·런타임 printk 쿼드러플에 따라 다릅니다.

타임스탬프는?

한 줄 답: 기본 출력은 대개 부팅 이후 초(raw) 이고, 사람 읽기용은 -T/--ctime, ISO는 --time-format=iso, 간격은 -d/delta입니다. 서스펜드/리줌 뒤 -T·iso는 부정확할 수 있다고 man 페이지가 명시합니다.

dmesg(1) 기준 형식 축:

옵션의미주의
(기본 / raw)부팅 이후 초로그 비교·스크립트에 흔함
-T / --ctime사람이 읽는 시각SUSPEND/RESUME 후 부정확할 수 있음
--time-format=isoISO-8601 형태ctime과 같은 서스펜드 이슈
-d / delta메시지 간격--notime과 쓰면 델타만
-e / --reltime로컬 시각 + 델타변환 부정확 가능(-T 참고)
-t / --notime타임스탬프 숨김본문만 볼 때

임베디드에서 쓰는 순서 예:

# 1) 부팅 상대 시각으로 전체 훑기
dmesg

# 2) 실패 구간만 레벨로 자른 뒤 간격 보기
dmesg --level=err+ -d

# 3) 호스트와 시각을 맞춰 비교할 때(지원 시)
dmesg --time-format=iso

# 4) 실시간 추적(커널 ≥3.5, /dev/kmsg 가독)
dmesg -w

읽기 팁:

  1. 부팅 직후 드라이버 실패는 raw 초로 “몇 초 구간에 몰렸는지”를 먼저 보십시오.
  2. 월·일·시계로 보고 싶을 때만 -T/iso를 쓰고, 서스펜드를 쓰는 기기면 man의 경고를 전제로 두십시오.
  3. 같은 증상이 짧은 delta로 연쇄하는지, 긴 공백 뒤 재발인지로 다음 절(반복)로 이어집니다.

반복 panic은 어떻게?

한 줄 답: “panic 문자열 한 줄”만 보지 말고, 같은 call site·같은 선행 err가 타임스탬프 간격으로 반복되는지를 확인하십시오. 필터는 err+·키워드·-w로 범위를 줄이고, RCU 이론 대신 재현 단위(부팅 1회 / N초마다 / 특정 ioctl 후) 를 먼저 적으십시오.

관측 체크리스트(문서·관행; 특정 SoC 일화 아님):

[ ] dmesg --level=err+ -d          # 심각 메시지만 + 간격
[ ] dmesg -x | grep -E 'panic|Oops|BUG:|Internal error'
[ ] 첫 panic/Oops 직전 20~50줄의 err/warn 선행 여부
[ ] raw 초 또는 delta로 "같은 패턴이 몇 번·몇 초 간격인가"
[ ] dmesg -w 로 재현 중 실시간 확인(가능하면)
[ ] 링 버퍼가 작아 앞부분이 밀렸는지(필요 시 버퍼/로그 수집 경로 점검)

반복을 나눌 때 쓰는 구분:

패턴보이는 것다음 질문
부팅마다 1회비슷한 초 구간에 동일 드라이버/장치 문자열프로브·클럭·전원·DT 쪽인가
짧은 delta로 다발같은 err가 연속, 곧이어 panic/Oops재시도 루프·하드 오류인가
긴 공백 뒤 재발유휴 후 또는 특정 작업 후워크로드·온도·버스 타임아웃인가
콘솔만 조용링에는 있으나 콘솔 레벨이 가림-n / /proc/sys/kernel/printk 확인

printk·dmesg가 주는 한계도 분명히 하십시오.

  1. 원인 규명의 전부가 아닙니다. 스택·레지스터·락업 디버거는 별 도구(kgdb, crash dump 등) 영역이고, 이 글 범위 밖입니다.
  2. RCU stall 문구가 보여도 여기서는 “stall이 있다” 수준만 기록하고, RCU 내부 알고리즘 추적은 하지 않습니다(브리프: deep dive 금지).
  3. 권한이 막히면 dmesg_restrict·실행 사용자부터 확인하십시오.

한 줄 정리: 레벨로 자르고(-l/-x) → 시각·간격으로 묶고(raw/-d/-T) → 같은 panic·Oops가 반복되는 단위만 적는다. RCU 논문 없이도 1차 분류는 가능합니다.

FAQ

BusyBox dmesg와 util-linux dmesg가 옵션이 다른가요?
자주 다릅니다. --level=err+, --time-format=iso, -w 등은 util-linux 기준입니다. 타깃 바이너리의 --help를 기준으로 삼으십시오.

-n을 올리면 과거 로그도 다시 보이나요?
아니요. -n/--console-level은 콘솔 출력 하한을 바꿀 뿐, 링 버퍼를 다시 인쇄하거나 지우지 않습니다(dmesg(1)).

-T가 틀리면 무엇을 믿나요?
재부팅 직후·서스펜드 없는 구간에서는 -T/iso가 편하고, 의심되면 raw 부팅 초와 delta로 상대 순서를 고정하십시오. man이 SUSPEND/RESUME 부정확을 경고합니다.

panic 한 줄만 저장하면 충분한가요?
부족합니다. 직전 err/warn·반복 간격·재현 조건이 없으면 다음 디버그 루프가 길어집니다. 최소한 err+ 구간과 타임스탬프를 함께 남기십시오.

출처