맨위로가기

커널 패닉

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

커널 패닉은 운영 체제의 치명적인 오류로, 시스템의 작동을 즉시 중단시킨다. 유닉스 커널에서 처음 도입되었으며, 하드웨어 고장, 소프트웨어 버그, 호환성 문제, 루트 파일 시스템 문제, 또는 init 프로세스 실패 등 다양한 원인으로 발생할 수 있다. 리눅스에서는 키보드 LED가 깜박이며, macOS에서는 재부팅을 안내하는 메시지가 표시된다. 커널 웁스는 커널 패닉보다 덜 치명적인 오류 상태로, 프로세스를 종료한 후 시스템이 계속 실행될 수 있다.

더 읽어볼만한 페이지

  • 죽음의 화면 - 블루스크린
    블루스크린은 윈도우 운영체제에서 발생하는 치명적인 오류로, 컴퓨터 작동을 멈추고 파란색 화면에 오류 메시지를 표시하며, 하드웨어 또는 소프트웨어 문제로 인해 발생하고, 시스템 복원, 안전 모드 부팅 등의 방법으로 대처한다.
  • 죽음의 화면 - 리눅스 커널 웁스
    리눅스 커널 웁스는 커널이 문제를 감지했을 때 출력하는 메시지이며, 버그 디버깅에 사용되고, 시스템 자원 손상 및 커널 패닉으로 이어질 수 있다.
  • 운영 체제 커널 - 커널 (컴퓨팅)
    커널은 운영 체제의 핵심으로, 하드웨어와 소프트웨어 간 상호 작용을 관리하며 시스템 보안, 자원 관리, 하드웨어 추상화, 프로세스 스케줄링, 프로세스 간 통신, 다중 작업 환경 지원 등의 기능을 제공하고, 모놀리식, 마이크로, 혼합형 커널 등으로 구현되며 가상화 및 클라우드 컴퓨팅 환경에서 중요성이 커지고 있다.
  • 운영 체제 커널 - 로더 (컴퓨팅)
    로더는 운영 체제에서 프로그램을 메모리에 적재하고 실행하는 소프트웨어 구성 요소이며, 유닉스와 윈도우 등에서 실행 파일의 유효성 검사, 메모리 매핑, DLL 초기화 등의 작업을 수행한다.
  • 컴퓨터 오류 - 블루스크린
    블루스크린은 윈도우 운영체제에서 발생하는 치명적인 오류로, 컴퓨터 작동을 멈추고 파란색 화면에 오류 메시지를 표시하며, 하드웨어 또는 소프트웨어 문제로 인해 발생하고, 시스템 복원, 안전 모드 부팅 등의 방법으로 대처한다.
  • 컴퓨터 오류 - 글리치
    글리치는 예기치 않은 오작동이나 오류를 뜻하며, 전자 공학, 컴퓨터, 비디오 게임, 텔레비전 방송, 대중문화 등 다양한 분야에서 기능 실패, 오류, 그래픽 및 사운드 문제, 신호 오류 등의 이상 현상을 포괄적으로 지칭하는 용어이다.
커널 패닉
일반 정보
일반적인 문제점커널 자체의 오류 또는 장치 드라이버와 같은 커널 확장으로 인해 발생
결과시스템 중단
데이터 손실
유사 용어 (마이크로소프트 윈도우)중지 오류 또는 블루 스크린
유사 용어 (macOS)회전하는 무지개 휠
원인
일반적인 원인하드웨어 오류
소프트웨어 버그
호환되지 않는 장치 드라이버
메모리 관리 오류
파일 시스템 손상
증상
일반적인 증상오류 메시지 표시
시스템 멈춤
자동 재부팅
문제 해결
일반적인 해결 방법시스템 재시작
장치 드라이버 업데이트
하드웨어 진단
파일 시스템 복구
커널 재컴파일 (고급 사용자)
커널 패닉 (Kernel Panic)
설명커널 패닉은 유닉스 계열 운영 체제에서 시스템이 더 이상 안전하게 작동을 계속할 수 없을 때 발생하는 Fatal system error 상태
발생 조건커널이 복구 불가능한 오류를 감지했을 때 발생하며, 이는 중지 오류와 유사
추가 정보
영향시스템 중단 및 재시작 필요
작업 중인 데이터 손실 가능성
하드웨어 손상 가능성 (드물게)
예방안정적인 하드웨어 사용
최신 드라이버 유지
신뢰할 수 있는 소프트웨어만 설치
정기적인 시스템 점검

2. 역사

유닉스 커널은 오류 감지 메커니즘인 표명(assertion)을 통해 내부 일관성과 런타임 정확성을 관리했다. 기본적인 가정은 하드웨어와 소프트웨어가 올바르게 동작하며 표명이 실패하면 패닉(모든 시스템 활동에 대한 자발적인 중단)을 야기한다는 것이었다. 커널 패닉은 초기 버전의 유닉스에 도입되었으며 유닉스와 그 전작인 멀틱스 간의 디자인 철학에 주된 차이점을 보여주었다. 멀틱스 개발자 톰 반 플렉은 유닉스 개발자 데니스 리치와의 이 변경 사항에 대한 논의를 다음과 같이 회상했다. "내가 멀틱스에서 작성하는 코드의 거의 절반이 오류 복구 코드라고 데니스에게 말했더니, 그는 '우리는 그 모든 것을 뺐습니다. 오류가 발생하면 '패닉'이라는 루틴이 있고, 그 루틴이 호출되면 시스템이 충돌하고 복도에서 '이봐, 재부팅해.'라고 소리칩니다.'라고 말했습니다."[6]

초기 `panic()` 함수는 오류 메시지만 출력하고 시스템을 무한 유휴 루프로 빠지게 했으나, 유닉스 코드베이스가 강화되면서 다양한 형태의 디버깅 정보를 콘솔에 출력하도록 개선되었다.

2. 1. 초기 유닉스

유닉스 커널은 오류 감지 메커니즘인 표명(assertion)을 통해 내부의 일관성과 런타임 정확성을 관리한다. 기본적인 가정은 하드웨어와 소프트웨어가 올바르게 동작하며 표명이 실패하면 패닉(모든 시스템 활동에 대한 자발적인 중단)을 야기한다는 것이다. 커널 패닉은 초기 버전의 유닉스에 도입되었으며 유닉스와 그 전작인 멀틱스 간의 디자인 철학에 주된 차이점을 보여주었다.

원래의 `panic()` 함수는 유닉스 제5판부터 VAX 기반 유닉스 32V까지 근본적인 변화는 없었고 다른 정보 없이 오류 메시지만 출력한 다음 시스템을 무한 유휴 루프로 빠져들게 했다.

유닉스 V6의 `panic()` 함수의 소스 코드는 다음과 같다:[37]

```c

/*

  • 콘솔이 꺼져 있는 경우,
  • panicstr은 마지막 panic 호출에 대한 인수를 포함합니다.
  • /

char *panicstr;

/*

  • 패닉은 해결할 수 없는 치명적인 오류에 호출됩니다.
  • 동기화하고 "panic: mesg"를 인쇄하고
  • 그런 다음 루프합니다.
  • /

panic(s)

char *s;

{

panicstr = s;

update();

printf("panic: %s\n", s);

for(;;)

idle();

}

```

유닉스 코드베이스가 강화되면서 `panic()` 함수는 다양한 형태의 디버깅 정보를 콘솔에 출력하도록 개선되었다.

3. 원인

커널 패닉은 유닉스 계열 운영 체제에서 발생하는 치명적인 오류로, 시스템을 중단시키는 상황을 말한다. 커널 패닉은 다양한 원인으로 발생할 수 있다.

커널 패닉의 주요 원인은 다음과 같다:


  • 하드웨어 오류: 하드웨어 자체의 결함이나 운영 체제와의 호환성 문제로 인해 발생한다.
  • 소프트웨어 버그: 운영 체제 자체의 결함으로 인해 발생한다.


이 외에도 호환성 문제, 루트 파일 시스템 문제, init 프로세스 실패 등이 커널 패닉을 유발할 수 있다. 이러한 원인들로 인해 시스템이 불안정해지면, 커널 패닉은 추가적인 손상을 막고 오류를 진단하기 위해 시스템을 중단시킨다. (하위 섹션에서 이미 다루고 있으므로, 간략하게 언급)

3. 1. 하드웨어 오류

유닉스 커널은 오류 감지 메커니즘인 표명(assertion)을 통해 내부 일관성과 런타임 정확성을 관리한다. 기본 가정은 하드웨어와 소프트웨어가 올바르게 동작하며, 표명은 패닉(모든 시스템 활동의 자발적 중단)을 야기한다는 것이다.

하드웨어 고장 또는 운영 체제의 소프트웨어 버그로 인해 패닉이 발생할 수 있다. 많은 경우 운영 체제는 오류 발생 후에도 계속 작동할 수 있다. 그러나 시스템이 불안정한 상태에 있으면 보안 침해 및 데이터 손상의 위험을 감수하는 대신, 운영 체제는 추가적인 손상을 방지하기 위해 중단되어 오류 진단을 용이하게 하고 자동으로 다시 시작될 수 있다.[8]

소스 코드에서 커널 바이너리 이미지를 다시 컴파일한 후, 결과 커널을 부팅하는 동안 커널이 올바르게 구성, 컴파일 또는 설치되지 않은 경우 커널 패닉이 발생하는 것은 흔한 문제이다.[9] 추가 하드웨어 또는 오작동하는 RAM 또한 OS와의 호환성 문제 또는 누락된 장치 드라이버로 인해 시작 시 치명적인 커널 오류의 원인이 될 수 있다.[10] 커널은 루트 파일 시스템을 찾을 수 없는 경우에도 `panic()` 상태로 들어갈 수 있다.[11]

3. 2. 소프트웨어 버그

유닉스 커널은 오류 감지 메커니즘인 표명(assertion)을 통해 내부 일관성과 런타임 정확성을 관리한다. 기본 가정은 하드웨어와 소프트웨어가 올바르게 동작하며, 표명이 실패하면 패닉(모든 시스템 활동의 자발적 중단)을 유발한다는 것이다. 커널 패닉은 초기 버전의 유닉스에 도입되었으며, 유닉스와 그 전작인 멀틱스 간의 주요 디자인 철학 차이를 보여준다.

원래의 `panic()` 함수는 유닉스 제5판부터 VAX 기반 유닉스 32V까지 근본적으로 변경되지 않았으며, 오류 메시지만 출력하고 시스템을 무한 유휴 루프에 빠뜨렸다.

유닉스 V6의 `panic()` 함수 소스 코드는 다음과 같다:[37]

```c

/*

  • 콘솔이 꺼져 있는 경우,
  • panicstr은 마지막 panic 호출에 대한 인수를 포함한다.
  • /

char *panicstr;

/*

  • 해결할 수 없는 치명적인 오류에 대해 Panic이 호출된다.
  • 동기화하고 "panic: mesg"를 출력한 다음 반복한다.
  • /

panic(s)

char *s;

{

panicstr = s;

update();

printf("panic: %s\n", s);

for(;;)

idle();

}

```

유닉스 코드베이스가 발전하면서 `panic()` 함수는 다양한 디버깅 정보를 콘솔에 출력하도록 개선되었다.

하드웨어 고장 또는 운영 체제의 소프트웨어 버그로 인해 패닉이 발생할 수 있다. 많은 경우 운영 체제는 오류 발생 후에도 계속 작동할 수 있다. 그러나 시스템이 불안정한 상태에 있으면 보안 침해 및 데이터 손상의 위험을 감수하는 대신, 운영 체제는 추가적인 손상을 방지하기 위해 중단되어 오류 진단을 용이하게 하고 자동으로 다시 시작될 수 있다.[8]

소스 코드에서 커널 바이너리 이미지를 다시 컴파일한 후, 결과 커널을 부팅하는 동안 커널이 올바르게 구성, 컴파일 또는 설치되지 않은 경우 커널 패닉이 발생하는 것은 흔한 문제이다.[9] 추가 하드웨어 또는 오작동하는 RAM 또한 OS와의 호환성 문제 또는 누락된 장치 드라이버로 인해 시작 시 치명적인 커널 오류의 원인이 될 수 있다.[10] 커널은 루트 파일 시스템을 찾을 수 없는 경우에도 `panic()` 상태로 들어갈 수 있다.[11] 커널 사용자 공간 초기화의 마지막 단계에서 init의 생성이 실패하면 일반적으로 패닉이 발생한다. init 프로세스가 종료되면 시스템을 사용할 수 없게 되므로 패닉이 발생할 수도 있다.[12]

다음은 `kernel_init()`에서 리눅스 커널 최종 초기화를 구현한 것이다:[13]

```c

static int __ref kernel_init(void *unused)

{

...

/*

  • 이들 중 하나가 성공할 때까지 시도한다.

  • 심각하게 손상된 시스템을 복구하려는 경우 init 대신 Bourne 쉘을 사용할 수 있다.
  • /

if (execute_command) {

if (!run_init_process(execute_command))

return 0;

pr_err("Failed to execute %s. Attempting defaults...\n",

execute_command);

}

if (!run_init_process("/sbin/init") ||

!run_init_process("/etc/init") ||

!run_init_process("/bin/init") ||

!run_init_process("/bin/sh"))

return 0;

panic("No init found. Try passing init= option to kernel. "

"See Linux Documentation/init.txt for guidance.");

}

3. 3. 호환성 문제

소스 코드에서 커널의 바이너리 이미지를 재컴파일한 후, 결과 커널을 부팅할 때 커널이 올바르게 구성, 컴파일 또는 설치되지 않으면 커널 패닉이 발생할 수 있다.[9] 추가된 하드웨어나 램 오작동 또한 OS와의 비호환성 또는 장치 드라이버 결함으로 인해 부팅 시 치명적인 커널 오류를 일으킬 수 있다.[10]

3. 4. 루트 파일 시스템 문제

커널은 루트 파일 시스템을 찾을 수 없는 경우에도 `panic()` 상태로 들어갈 수 있다.[11] 커널 사용자 공간 초기화의 마지막 단계에서 init의 생성이 실패하면 일반적으로 패닉이 발생한다. init 프로세스가 종료되면 시스템을 사용할 수 없게 되므로 패닉이 발생할 수도 있다.[12]

다음은 `kernel_init()`에서 리눅스 커널 최종 초기화를 구현한 것이다:[13]

```c

static int __ref kernel_init(void *unused)

{

...

/*

  • We try each of these until one succeeds.

  • The Bourne shell can be used instead of init if we are
  • trying to recover a really broken machine.
  • /

if (execute_command) {

if (!run_init_process(execute_command))

return 0;

pr_err("Failed to execute %s. Attempting defaults...\n",

execute_command);

}

if (!run_init_process("/sbin/init") ||

!run_init_process("/etc/init") ||

!run_init_process("/bin/init") ||

!run_init_process("/bin/sh"))

return 0;

panic("No init found. Try passing init= option to kernel. "

"See Linux Documentation/init.txt for guidance.");

}

3. 5. init 프로세스 실패

커널 사용자 공간 초기화의 마지막 단계에서 init의 생성이 실패하면 일반적으로 패닉이 발생한다. init 프로세스가 종료되면 시스템을 사용할 수 없게 되므로 패닉이 발생할 수도 있다.[12]

다음은 `kernel_init()`에서 리눅스 커널 최종 초기화를 구현한 것이다:[13]

```c

static int __ref kernel_init(void *unused)

{

...

/*

  • We try each of these until one succeeds.

  • The Bourne shell can be used instead of init if we are
  • trying to recover a really broken machine.
  • /

if (execute_command) {

if (!run_init_process(execute_command))

return 0;

pr_err("Failed to execute %s. Attempting defaults...\n",

execute_command);

}

if (!run_init_process("/sbin/init") ||

!run_init_process("/etc/init") ||

!run_init_process("/bin/init") ||

!run_init_process("/bin/sh"))

return 0;

panic("No init found. Try passing init= option to kernel. "

"See Linux Documentation/init.txt for guidance.");

}

4. 운영 체제별 특징

유닉스 커널은 오류 감지 메커니즘인 표명(assertion)을 통해 내부의 일관성과 런타임 정확성을 관리한다. 기본 가정은 하드웨어와 소프트웨어가 올바르게 동작하며, 만약 그렇지 않을 경우 표명은 패닉(모든 시스템 활동에 대한 자발적인 중단)을 야기한다는 것이다. 커널 패닉은 초기 버전의 유닉스에 도입되었으며, 이는 유닉스와 그 전작인 멀틱스 간의 디자인 철학에 주된 차이점을 보여준다.

원래의 `panic()` 함수는 유닉스 제 5판부터 VAX 기반 유닉스 32V까지 근본적인 변화가 없었고, 오류 메시지만 출력한 다음 시스템을 무한 유휴 루프로 빠져들게 했다. 유닉스 코드베이스가 강화되면서 `panic()` 함수는 다양한 형태의 디버깅 정보를 콘솔에 출력하도록 개선되었다.

유닉스 V6의 `panic()` 함수 소스 코드는 다음과 같다:[37]

```c

/*


  • 콘솔이 꺼져 있는 경우,
  • panicstr은 마지막 panic 호출에 대한 인수를 포함한다.
  • /

char *panicstr;

/*

  • Panic은 해결할 수 없는
  • 치명적인 오류에 대해 호출된다.
  • 동기화하고 "panic: mesg"를 출력한 다음
  • 루프를 반복한다.
  • /

panic(s)

char *s;

{

panicstr = s;

update();

printf("panic: %s\n", s);

for(;;)

idle();

}

4. 1. 리눅스 (Linux)

유닉스 계열 시스템과 마찬가지로 리눅스에서도 커널 패닉이 발생한다. 그러나 심각하지만 치명적이지 않은 오류는 커널 웁스라고 알려진 다른 종류의 오류 상태를 생성할 수 있다.[14] 이 경우 커널은 일반적으로 문제가 있는 프로세스를 종료한 후 계속 실행된다. 웁스는 일부 서브시스템이나 리소스를 사용할 수 없게 만들 수 있으므로, 나중에 완전한 커널 패닉으로 이어질 수 있다.

리눅스에서 커널 패닉이 발생하면 중요한 상태를 시각적으로 나타내기 위해 키보드 LED가 깜박인다.[15]
iKVM 콘솔에서 보이는 커널 패닉

4. 2. macOS

macOS 10.2부터 10.7까지의 버전에서 커널 패닉이 발생하면, 시스템을 재부팅해야 한다는 내용을 다국어로 사용자에게 알리는 메시지가 컴퓨터에 표시된다.[16] 10.2 이전 버전에서는 좀 더 전통적인 유닉스 스타일의 패닉 메시지가 표시되었고, 10.8 이후 버전에서는 컴퓨터가 자동으로 재부팅되며, 메시지는 건너뛸 수 있는 경고로만 표시된다. 메시지의 형식은 버전별로 다르다.[17]

  • 10.0~10.1: 시스템은 화면에 오류에 대한 세부 정보를 텍스트로 표시하고 응답하지 않는다.
  • 10.2: 검은색 투명 커튼이 내려오면서 흰색 배경에 컴퓨터를 다시 시작해야 한다는 메시지가 표시된다. 메시지는 영어, 프랑스어, 독일어, 일본어로 표시된다.
  • 10.3~10.5: 10.2와 유사하지만 오류 메시지의 배경은 짙은 회색이다.
  • 10.6~10.7: 텍스트가 수정되었으며 스페인어 번역이 포함되어 있다.
  • 10.8 이상: 컴퓨터가 즉시 재부팅되기 전에 응답하지 않게 된다. 재시작 후 몇 초 동안 문제가 발생하여 컴퓨터가 재시작되었다는 메시지를 표시한 후 부팅을 계속한다. 이 메시지에는 중국어 번역이 포함되어 있다.


첫 번째 커널 패닉 발생 후 3분 이내에 5번의 새로운 커널 패닉이 발생하면, Mac은 30초 동안 금지 기호를 표시한 후 종료된다. 이를 "반복 커널 패닉"이라고 한다.[18]

10.2 이상의 모든 버전에서, 텍스트는 전원 기호 위에 겹쳐 표시되며 전체 화면이 아니다. 디버깅 정보는 NVRAM에 저장되며 재부팅 시 로그 파일에 기록된다. 10.7에서는 커널 패닉 후 자동으로 재시작하는 기능이 있다. 10.2 이상에서는 대기 기호 외에 오류에 대한 세부 정보를 담은 흰색 텍스트가 표시될 수도 있다.

Mac OS X 10.6 및 10.7 커널 패닉

5. 참고: 커널 웁스 (Linux)

커널 웁스는 리눅스에서 발생하는 오류의 한 종류이지만, 커널 패닉보다는 덜 치명적이다.[14] 이 경우 커널은 일반적으로 문제가 있는 프로세스를 종료한 후 계속 실행된다.[14] 웁스는 일부 서브시스템이나 리소스를 사용할 수 없게 만들 수 있으므로, 나중에 완전한 커널 패닉으로 이어질 수 있다.[14]

리눅스에서 커널 패닉이 발생하면 중요한 상태를 시각적으로 나타내기 위해 키보드 LED가 깜박인다.[15]

참조

[1] 웹사이트 KP - Kernel Panic (Linux) {{!}} AcronymFinder http://www.acronymfi[...] 2016-01-06
[2] 웹사이트 FreeBSD 11.0 - man page for panic (freebsd section 9) - Unix & Linux Commands http://www.unix.com/[...] 2010-10-26
[3] 웹사이트 boot failure-init died - Unix Linux Forums - HP-UX http://www.unix.com/[...] 2013-06-12
[4] 뉴스 Re: PANIC: init died https://groups.googl[...] 1999-09-01
[5] 서적 Reliable computer systems: design and evaluation https://books.google[...] A K Peters, Ltd. 2011-05-06
[6] 웹사이트 Unix and Multics http://www.multician[...] 2005-05-25
[7] 웹사이트 Source code /usr/sys/ken/prf.c
[8] 서적 Tru64 UNIX troubleshooting: diagnosing and correcting system problemsHP Technologies SeriesITPro collection https://books.google[...] Digital Press 2011-05-03
[9] 서적 Linux annoyances for geeks https://books.google[...] O'Reilly Media, Inc. 2011-04-29
[10] 서적 Switching to the Mac: The Missing Manual, Snow Leopard Edition https://books.google[...] O'Reilly Media, Inc. 2011-05-04
[11] 서적 Linux kernel in a nutshell https://books.google[...] O'Reilly Media, Inc. 2011-05-03
[12] 서적 Professional Linux Kernel Architecture https://books.google[...] John Wiley and Sons 2011-05-03
[13] 웹사이트 linux/init/main.c http://lxr.linux.no/[...]
[14] 웹사이트 "Linux Device Drivers, Chapter 4" https://lwn.net/imag[...] 2016-07-21
[15] 서적 Linux Troubleshooting for System Administrators and Power Users https://books.google[...] Prentice Hall 2016-02-05
[16] 웹사이트 OS X: About kernel panics - Apple Support http://support.apple[...]
[17] 웹사이트 A New Screen of Death for Mac OS X http://osxbook.com/b[...] 2011-04-30
[18] 웹사이트 OS X: About kernel panics https://support.appl[...] Apple
[19] 웹사이트 KP - Kernel Panic (Linux) {{!}} AcronymFinder http://www.acronymfi[...] 2016-01-06
[20] 웹사이트 Bug Checks (Blue Screens) https://docs.microso[...] 2020-11-04
[21] 웹사이트 Did You Know Windows 10 Has a Green Screen of Death? https://www.howtogee[...] 2020-06-04
[22] 웹사이트 FreeBSD 11.0 - man page for panic (freebsd section 9) - Unix & Linux Commands http://www.unix.com/[...] 2020-11-16
[23] 웹사이트 boot failure-init died - Unix Linux Forums - HP-UX http://www.unix.com/[...] 2020-11-16
[24] 서적 Reliable computer systems: design and evaluation https://books.google[...] A K Peters, Ltd. 2011-05-06
[25] 웹사이트 Unix and Multics http://www.multician[...] 2020-11-16
[26] 문서 Source code /usr/sys/ken/prf.c from
[27] 서적 Tru64 UNIX troubleshooting: diagnosing and correcting system problemsHP Technologies SeriesITPro collection https://books.google[...] Digital Press 2011-05-03
[28] 서적 Linux annoyances for geeks https://books.google[...] O'Reilly Media, Inc. 2011-04-29
[29] 서적 Switching to the Mac: The Missing Manual, Snow Leopard Edition https://books.google[...] O'Reilly Media, Inc. 2011-05-04
[30] 서적 Linux kernel in a nutshell https://books.google[...] O'Reilly Media, Inc. 2011-05-03
[31] 서적 Professional Linux Kernel Architecture https://books.google[...] John Wiley and Sons 2011-05-03
[32] 문서 linux/init/main.c
[33] 웹사이트 "Linux Device Drivers, Chapter 4" https://lwn.net/imag[...] 2020-11-16
[34] 서적 Linux Troubleshooting for System Administrators and Power Users https://books.google[...] Prentice Hall 2016-02-05
[35] 웹사이트 OS X: About kernel panics - Apple Support http://support.apple[...] 2020-11-16
[36] 웹사이트 A New Screen of Death for Mac OS X http://osxbook.com/b[...] 2020-11-16
[37] 문서 Source code /usr/sys/ken/prf.c from UNIX V6 http://minnie.tuhs.o[...]


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com