안녕하세요. Linux kernel 강의를 듣고 있는 수강생입니다 제가 Crash utility 를 이용해서 쉽게 해당 dump 의 최종 프로세스의 cpu 번호는 알 수 있는데, 만약 현장에서 Crash Utility 설치가 불가피해서 사용을 못하고(시간상이나 알수 없는 원인으로 설치가 안될때) 오직 TRACE 32 만으로 SMP(멀티코어) 시스템의 DUMP 발생 원인이 된 프로세스의 CPU 번호를 파악하고 싶을때는 어떤 방법을 이용할 수 있을지 궁금합니다. 예를들어 아래와 같이 상황에서 해당 Soft IRQ 를 발생시킨 CPU 번호를 오로지 TRACE 32 를 이용해서 찾아야 한다고 했을때 , 어떻게 해야하는지 궁금합니다 사실 교수님께서 설명하셨던것 같은데, 기억이 잘 안나서요. 죄송합니다.... 감사합니다.
안녕하세요. 이번 1부- 5강 인터럽트 강의를 듣고 있는 학생입니다. 해당 강의를 들으면서 6. bcmgenet_isr_0 인터럽트 핸들러 디버깅-TRACE32 (Part.1) 를 수강하면서 2-irq-dump 덤프 강의자료로 실습을 진행하는데 TRACE32 의 콜스택이 깨진건지 첨부한 사진과 같이 나옵니다. 처음에는 스택 관련 이슈로 인해서 깨졌다고 생각해서 Crash utility 의 bt -s 명령어 및 log -m 의 출력된 콜스택과 레지스터 셋 정보를 이용해 이전 강의에 들었던 스택 복구를 시도해보았습니다. 하지만 전부 다 콜스택 복구가 안되는것을 확인하여 이것이 어떤 문제인지 궁금해서 질문드립니다. [해당 2-irq-dump를 Load-Dump - Dump1 으로 불러오면 나오는 화면] [불러올때 아래에 뜨는 에러메세지] 말씀드린 것처럼 Crash utility는 정상동작하며, TRACE 32 만 위와 같이 콜스택이 전부 깨져서 나옵니다. 아래는 해당 프로그램을 실행하는 작업환경입니다. Host OS : Window 11 감사합니다.
커널 코드 실행 중 인터럽트가 발생한 경우에는 thread_info 구조체의 preemption_count 값을 통해 preemptive schedule 가능 여부를 판단하고, 유저 코드 실행 중에 발생한 경우에는 flags 값을 통해 preemptive schedule 가능 여부를 판단하는 것을 이해했는데, 둘이 왜 확인 방법이 다른지 궁금합니다
