2017-12-11 11 views
1

임베디드 장치에서 예기치 않은 재부팅이 발생합니다. 현재 ioctl 호출 덕분에 하드웨어 워치 독 문제를 감지 할 수 있습니다. 이제 커널 패닉이 재부팅의 이유인지 여부를 감지 할 수 있기를 바랍니다. 크래시 커널과 크래시 덤프와 관련된 기사를 찾았지만 제대로 작동하지 못했습니다. 커널 패닉 로그를 저장하고 싶지 않습니다. 커널 패닉이 일어나는지 알 수 있습니다.재부팅 후 커널 패닉을 감지하는 방법

나의 현재 아이디어는 mmc의 예약 된 공간에 작성하는 것이 었습니다. 현재 이중 분배 시스템을 처리하기 위해 예약 된 공간을 사용 중입니다. 좋은 생각인데? 커널 패닉 중에 mmc로 쓸 수 있습니까? 확실하지는 않지만이 이벤트에서 일상적인 커널 패닉 훅을 사용할 수있는 것 같습니다.

부트 중에 커널 패닉이 발생했는지 확인할 수있는 표준 방법이 없습니까?

+0

Kenel이 손상되었을 때 File System을 사용하는 것은 좋지 않습니다. 따라서 eMMC에 rootfs가 포함되어 있으므로 액세스하지 않는 것이 좋습니다. 사용할 수있는 커널 패닉 훅이 있는지 확실하지 않습니다. 'panic.c'을 편집하여 일부 LED를 토글하거나 (UART가있는 경우) 일부 명령을 다시 보내거나 LCD에 일부 데이터를 표시 할 수 있습니다. 커널 충돌시 파일 시스템에 대한 액세스를 피하십시오. – Gaurav

+0

나는 led 또는 uart를 사용할 수 없습니다. 내장 된 장치에 물리적으로 액세스 할 수 없습니다. 나는 현재 rtc의 사용하지 않는 레지스터를 사용하여 다음 재부팅시이를 감지 할 수있는 커널 패닉 이벤트를 저장하려고합니다. 이것이 나의 유스 케이스를 다룰 수있는 가장 좋은 방법인지 확신하지 못한다. atomic_notifier_chain_register API를 사용하여 커널 패닉에 대한 훅을 등록합니다. – ArthurLambert

+1

알리미에서 파일 시스템을 엉망으로 만들려는 것보다 훨씬 좋은 아이디어라고 생각됩니다. – tofro

답변

0

여기에 윈도우를 처리하는 방법은 다음과 같습니다

  • (이이나 뭔가 낮은 수준) 디스크를 사용하여 BIOS 루틴에 더 이상 드라이버
  • 쓰기
  • 가 페이지 파일에 커널 덤프를 쓰기를 사용하지 않는 (우리가 아무 것도 손상시키지 않고 연속적으로 알려주는 것으로 알려진 유일한 장소)
  • 다음 부팅시 페이지 파일에 크래시 덤프 서명이 포함되어 있는지 확인하십시오.

Linux에이 개념을 적용 할 수 있습니다 (예 : 스왑 파티션에 쓰고 다음 시작시 스왑 파티션의 내용을 확인하십시오.

+0

Linux에는 해당되지 않습니다. Linux에는 고유 한 메소드가 있습니다. – 0andriy

+0

@ 0andriy : 물론 있습니다. 때때로 한 OS에서 다른 OS로 * 개념 *을 적용 할 수 있습니다. 리눅스에서는 페이지 파일이 아니라 스왑 파티션에 쓸 것입니다. –

+0

그리고 그것이 그 질문에 대한 대답으로 간주 될 수없는 이유입니다. OP에 대한 내 의견을 참조하십시오. – 0andriy