안녕하세요, 항상 도움 받고 있습니다. Q&A는 아니고 강의 진행 간 강의 중복 업로드가 확인되어 해당 내용 전달 드립니다. "42. 워크 핸들러에 전달되는 매개 인자 디버깅"의 강의가 "52. ftrace 분석: 워크큐 와치독" 강의로 잘못 업로드된 것 같으니, 확인 부탁드립니다. 감사합니다.
안녕하세요. 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 감사합니다.
17분 2초 쯤 printf("%s\n", inbuf); 의 출력 결과가 hello, world #1 이고 나머지 데이터가 안 찍힌 이유로 개행이 없다고 설명해 주셨는데 이 부분이 조금 애매한 것 같습니다. inbuf 에는 아래와 같이 hello, world #1\0hello, world #2\0hello, world #3 입력한 데이터가 다 들어있고 널문자까지 있습니다. 그걸 printf("%s\n" ...) 출력하다 보니 버퍼 중간의 null 을 만나서 문자열 끝으로 인식해서 출력이 종료된고 write 함수로 MSGSIZE 대신 null 문자를 제외한 사이즈 MSGSIZE - 1 로 출력하면 printf 가 msg1, msg2, mg3을 다 찍네요 null 이 없어서 이상한 문자가 출력되지만요...
안녕하세요 저는 Windows x86 x64 환경에서만 리버싱을 하다 ARM 아키텍처와 리눅스에 대해서도 한번 공부를 해보고 싶은 평범한 직장인입니다. 우선 좋은 강의를 제공해주셔서 정말 감사드립니다. 제가 궁금한 점은 우선 개발자님께서 제공해주시는 커리큘럼이 총 3개가 존재하는데 시스템 소프트웨어 개발자를 위한 Arm - basic course 시스템 소프트웨어 개발자를 위한 Arm - advanced course 시스템 소프트웨어 개발자를 위한 Linux kernel - basic course 우선 제가 궁금한 점은 Linux kernel 강의가 ARMV8 아키텍처 위에서 진행되는 강의다 보니 먼저 ARM basic 과 ARM advanced 코스를 공부한 후 Linux kernel 강의를 들어야 하는지 아니면 같이 공부를 해도 수강하는데 문제가 없는지 궁금합니다. 그리고 추가적으로 궁금한 점은 개발자님께서 출간하신 Linux kernel 책 2권의 내용은 아직 강의로 제공되지 않는 것 같은데 ARM 강의와 마찬가지로 Linux kernel advanced 로 후반부의 내용을 강의로 제공하실 계획이 있으신지 궁금합니다. 감사합니다!
커널 코드 실행 중 인터럽트가 발생한 경우에는 thread_info 구조체의 preemption_count 값을 통해 preemptive schedule 가능 여부를 판단하고, 유저 코드 실행 중에 발생한 경우에는 flags 값을 통해 preemptive schedule 가능 여부를 판단하는 것을 이해했는데, 둘이 왜 확인 방법이 다른지 궁금합니다