수안이의 컴퓨터 연구실
드라이버, IRQ, PCI 레이턴시(latency)
Daniel Robbins
President/CEO, Gentoo Technologies, Inc.
2001년 7월
Linux가 명성을 얻는데에는 안정성이 큰 기여를 했다. 하지만, 세상에서 가장 안정적인 OS라도 하드웨어에 결함이 있거나 설정이 잘못되었다면 아무런 소용이 없을 것이다. NVIDIA의 드라이버를 사용하여 Linux에서 NVIDIA TNT 그래픽 카드를 실행했었던 필자(Daniel Robbins)의 경험을 이야기한다. IRQ와 PCI latency 타이머 문제를 진단하고 픽스하는 방법을 설명한다.
불안정성의 원인들
안정성 문제는 불완전한 하드웨어 때문에 발생하는 것만은 아니다. 주로 적절하지 못한 하드웨어 설정이나 미약한 드라이버 때문에 문제가 발생한다.
NVIDIA에는 Linux용 디스플레이 드라이버가 있다. 이러한 드라이버들은 Xfree86 4.0에 포함된 표준 2d-only NVIDIA 드라이버 보다 많은 장점을 가지고 있다. 그 중 하나는 3D 지원이 강화되었다는 점이다. 게다가 Mesa의 강화 버전이라기 보다는 공식적인 OpenGL 1.2 구현이라는 특징이 있다. 이러한 NVIDIA기반의 그래픽 카드를 가지고 있다면 강화된 드라이버를 사용하고 싶을 것이다. 적어도 이론상으로는 그렇다. 그들을 적절하게 작동시키려는 시도를 통해 많은 것을 배웠다.
Linux NVIDIA 드라이버를 설치하고 나서(참고자료), Xfree86를 시작했고 모든 3D 애플리케이션 구동을 시작했다. 지금은 매우 훌륭히 작동한다. 그 이전까지 나는 3D acceleration을 이용하기 위해 Windows NT를 재부팅 해야만 했다. 지금 NT는 신경쓰지 않는다. 3D 애플리케이션을 사용하기위해 재부팅 하는 것은 다소 성가신 일이였지만 Linux를 남겨놓아 머신을 재부팅한다. 하지만 한시간 정도 만지작거리면 Linux 3D aspiration에 치명적인 퇴보를 경험한다. 머신이 잠긴다. 마우스가 멈추고 스크린은 얼어붙었다. 시스템을 재부팅해야 했다.
사실 몇 가지 종류의 안정성 문제가 있었다. 하지만 무엇이 문제를 일으키는지 정확히 몰랐다. 안정적이지 않은 하드웨어 탓인지 카드가 잘못 설정 되어서 그런지 확실하지 않았다. 어쩌면 드라이버와 관련된 문제일지도 모른다. 또는 VIA KT133 기반의 Athlon 마더보드 때문인지도 모른다. 문제가 어떤것이든 간에 빨리 해결하고 싶었다. 이 글에서 나는 하드웨어 안정성 문제를 해결했던 과정을 설명하겠다. 나와 똑 같은 문제를 가지고 있지 않더라도, 문제를 진단하고 픽스하는 과정들은 본질적으로 Linux 하드웨어의 다른 문제 유형에도 적용할 수 있으리라 생각한다.
하드웨어 점검
내 머리속에 떠오른 생각 중 하나는 내가 가지고 있는 하드웨어가 약간 미약하다는 것이였다. 반면 Diamond Viper V550은 Windows NT에서는 아무런 문제가 없었다. 하지만 Linux에서는 칩이 경직되고 열(heat) 과 관련된 lock-up이 생긴다. V550는 극도로 뜨거워졌고 OEM heatsink는 그런대로 적절했다. 나는 V550을 위해 heatsink/fan이 통합된 것을 구입하기 위해 PC Power and Cooling을 참조했다. (참고자료)
그렇게 해서 나는 Video Cool을 구입했다. 비디오 카드에 있던 OEM heatsink를 떼고 TNT 칩을 청소하고 칩의 상단에 Video Cool을 붙였다. 결과는? 비디오 카드는 더 이상 뜨거워지지 않았다. 하지만 lockup은 계속되었다. 이 특별한 경험을 통해서 배운 한 가지 교훈은 시스템이 시작하기에 적당할 정도로 냉각되었다는 것을 확신할 수 있다면 부적절한 냉각으로 인한 컴포넌트의 오작동에 대해서 걱정하지 않아도 된다는 것이다. workstation과 서버를 뜨거워지지 않게 유지하며 실행하기 위해서는 시간과 노력이 필요하다. 열과 관련된 문제들을 연구해본 결과 lockup은 결함있는 하드웨어 때문이 아니라는 것을 알았다. 다른 요소를 찾아보기 시작했다.
새로운 드라이버만이 솔루션인가?
나는 부분적으로는 NVIDIA의 드라이버가 문제의 원인이라고 생각했다. 다행히 신 버전 드라이버가 배포되었다. 그래서 나는 즉시 업그레이드 하였다. 안정성 문제를 해결할 수 있기를 희망했다. 하지만 openprojects.net의 다른 #nvidia channel을 검토한 결과 어떤 누구도 드라이버를 안정적으로 실행시키지 못했다. 내가 나서야 할 때라고 생각했다.
#nvidia와 관련하여 어떤 사람은 V550가 IRQ를 다른 카드와 공유하지 않는 것이 분명하다고 말한다. 표준 XFree86 드라이버와는 다르게 NVIDIA 드라이버는 올바른 작동을 위해 IRQ가 필요하다. 드라이버가 "cat /proc/interrupts"를 입력하고 지켜보았다. V550는 IDE 컨트롤러와 인터럽트를 공유하고 있었다. 문제를 해결했던 방법을 설명하기에 앞서 IRQ에 대해 간단히 설명하겠다.
PC는 IRQ (일반적으로 하드웨어 인터럽트)를 사용하여 비디오 카드와 디스크 컨트롤러와 같은 주변의 디바이스가 실행 준비가 된 데이터를 가지고 있는 CPU에 신호를 주도록 한다. PCI 버스라는 것이 존재하기 전에는 머신의 디바이스 마다 전용의 IRQ를 가지고 있어야만 했다. 여러분이 아직도 ISA 주변장치를 사용하고 있다면 그 사실은 여전히 유효하다. 모든 non-PCI 디바이스들은 전용의 IRQ를 가져야 한다.
IRQ & PCI
하지만 이것은 PCI bus와는 약간 다르다. PCI는 네 개의 IRQ를 할당하여 시스템의 PCI/AGP 카드에 의해 사용될 수 있다. 일반적으로 이러한 IRQ는 다중 디바이스들 사이에서 공유 될 수 있다. (공유를 수행하는 모든 디바이스가 PCI와 AGP 디바이스인지를 확인하라.) IRQ 공유는 중요하다. 다섯개의 PCI와 한 개의 AGP 슬롯을 가지고 있는 머신에 있어 특히 중요하다. IRQ 공유 없이는 시스템에 IRQ를 사용하는 카드를 네 개 이상 가질 수 없다.
하지만 PCI IRQ 공유에도 제한은 있다. 일반적으로 마더보드 BIOS와 Linux 커널이 PCI IRQ 공유를 지원하는 반면 특정 PCI 카드는 IRQ를 다른 디바이스와 공유할 때 작동하지 않을 때가 있다. 간헐적인 시스템 lockup을 경험했다면, 특히 lockup이 특정 하드웨어 디바이스의 사용과 관련이 있다면 모든 PCI 디바이스가 고유의 IRQ를 사용하도록 해야한다. 우선 디바이스들이 IRQ를 공유하고 있는지를 보는 것이 첫 번째 순서이다:
디스크, 사운드, 비디오, SCSI 같은 하드웨어 디바이스를 사용한다. 이것으로 Linux가 이러한 다양한 디바이스에 대한 인터럽트를 핸들할 것임을 알 수 있다.
지금까지 Linux 커널이 핸들했던 모든 인터럽트 리스트와 카운트(count)를 나타내는 "cat /proc/interrupts"는 리스트의 가장 오른쪽 칼럼을 참조하라. 한 행에 두 개 이상의 디바이스 리스트가 있다면 그것들이 특정 IRQ를 공유하고 있는 것이다.
해당 디바이스 중 하나가 non-PCI 디바이스 (ISA 또는 기타 레거시 카드)라면 IRQ 충돌이라는 것을 알 것이다. BIOS나 isapnptools 패키지 또는 physical peripheral 카드에 물리적 점퍼를 가해서 픽스할 수 있다. 디바이스가 마더보드에 내장되었다면 이것이 물리적 PCI 슬롯을 차지하지 않더라도 PCI 디바이스일 가능성이 크다는 것을 주목하라.
해당되는 모든 디바이스들이 PCI 또는 AGP 디바이스라면 하드웨어에 따라서 문제가 생길 수도 있다. 모든 PCI/AGP 디바이스를 고유의 IRQ를 할당하는 방법이 있다:
시스템 BIOS에 들어가서 사용되지 않은 주변기기를 사용 불가 상태로 만든다 (USB, 병렬 포트 등.). 이는 많은 IRQ를 이용할 수 있게 하고 사용되는 하드웨어가 고유의 IRQ를 할당받을 수 있는 기회를 얻게된다.
BIOS의 PnP 섹션으로 들어가 BIOS가 "non-PnP" OS로 설정되었다는 것을 확인한다. 그런 다음 "Reset ESCD data" 옵션을 선택한다. 이것은 BIOS가 여러분이 다음에 재부팅 할 때 모든 하드웨어 디바이스에 IRQ를 재할당 할 수 있도록 한다.
Linux를 부팅하고 cat /proc/interrupts를 사용하고 결과를 본다. 다행스럽게도 모든 디바이스들이 고유의 IRQ를 가지고 있다.
만일 PCI 디바이스가 여전히 IRQ를 공유하고 있다면 여러분이 취할 수 있는 두 가지 옵션이 있다. 어떤 BIOS 셋업 프로그램은 특정 PCI 슬롯에 특정 IRQ를 할당할 수 있다. 만일 여러분이 이러한 드문 BIOS 셋업 프로그램 중 한 개를 가지고 있다면 이 기능을 사용하여 충돌을 줄이는데 사용할 수 있다. 만일 BIOS에 이 옵션이 없다면 또 다른 확실한 방법이 있다. 컴퓨터를 종료하고 파워를 끈다. PC의 전원을 끄는 것이다. 그리고 몇 분 정도 기다린다. 그런다음 시스템 케이스를 열고 PCI 카드를 다른 슬롯으로 옮긴다. 이 옵션은 약간 이상한 방법이지만 아주 훌륭하게 작동할 것이다. 특히 시스템에 몇 개의 여분의 PCI 슬롯이 있다면 더욱 효과적이다. (단, 각 카드에 맞는 정확한 슬롯을 찾는데는 시간이 걸린다).
"PCI 카드 교체하기 트릭"을 통해 내 시스템의 모든 디바이스가 고유의 IRQ를 얻을 수 있었다. 내 IDE 디바이스중 두 개는 여전히 IRQ를 공유하고 있다:
하지만 이것은 정상이다. 왜냐하면 ide2와 ide3 디바이스 Promise FastTrak IDE 카드의 같은 칩으로 통합되었기 때문이다.
거의 모든 디바이스는 고유의 IRQ를 가지고 있기 때문에 나의 accelerated 드라이버를 시도했지만..한 시간이 못되어서 lockup 되었다. 공유된 PCI IRQ 문제게 아니라는 것이 명백해졌다.
끊임없이 발생하는 문제들
몇 시간이 흐른 후에 NVIDIA 드라이버를 완벽하게 실행시킬 수 있는 어떤 방법을 발견했다. 하지만 좀 더 느려졌고 AGP를 사용할 수 없었다. 내가 이러한 상황을 원하지 않은 만큼 현재 버전의 드라이버는 AGP가 XF86Config에 한 라인을 추가함으로서 완전히 꺼질 수 있도록 하였다. AGP를 꺼 놓은 상태에서 비디오의 메모리 대역을 4x로 줄였다. 하지만 매우 느렸던 3D는 다른 어떤 3D acceleration 보다 훨씬 빠르다. AGP를 사용 불가 상태로 만든 후에 마침내 안정적인 시스템을 갖게 되었다. 하지만 이러한 일시적인 솔루션은 다른 문제를 야기시켰다. 3D OpenGL 애니메이션이 지속될 때마다 오디어 플레이백은 고르지 못했다!
다행스럽게도 나는 오디오 문제에 대한 솔루션을 찾을 수 있었다. setpci 유틸리티를 사용하여 PCI 디바이스에 더욱 적절한 PCI bus latency 타이머를 설치했다. 문제 해결 방법을 설명하겠다. 하지만 우선 배경 지식이 필요하다.
PCI 버스는 제한된 대역의 공유 리소스이기 때문에 하나의 PCI가 다른 PCI 카드의 퍼포먼스에 좋지 않은 영향을 끼칠 가능성이 있다. 예를들어 A라는 PCI 카드가 버스를 통해 데이터를 보내는 중에 동시에 B라는 PCI 카드가 데이터 전송을 시도한다면? A가 과연 버스 사용을 허용할까? 아니면 데이터 전송을 그대로 진행할까? 만일 그렇다면 얼마나 오래 진행할까?
PCI latency timer
이러한 질문에 대한 대답은 각각의 PCI 디바이스가 가지고 있는 설정 가능한 PCI bus latency timer와 관련이 있다. 각각의 PCI 디바이스에 맞는 PCI 버스 latency timer 값을 적절히 설정하는 것은 Linux의 역할이다. 대부분 디폴트 세팅이 적당히 되어있다 (최적의 세팅은 아니다). 모든 디바이스는 훌륭히 수행되고 시스템도 적절히 작동한다. PCI 버스 latency timer는 0에서 248 까지 설정할 수 있다. 디바이스가 zero 세팅이 되어있을 경우 다른 디바이스가 전송이 필요하다면 이것은 즉시 버스를 포기한다. 만일 디바이스 세팅이 248로 되어 있다면 멈추기 전까지 오랜 시간동안 버스의 사용을 지속할 것이다. 다른 디바이스는 순서를 기다린다.
모든 디바이스의 PCI 버스 latency timer가 비교적 높게 설정되어 있고 많은 데이터가 버스를 통해 보내질 때 PCI 카드는 일반적으로 버스 제어권을 얻기 전까지 더 오랜시간을 기다린 후에 데이터 전송을 시작할 수 있다. 하지만 버스 제어권을 일단 얻으면 버스가 다른 디바이스로 넘어가기 전까지 이것을 통해서 많은 데이터를 전송할 수 있을 것이다. 왜냐하면 높은 PCI 버스 latency timer 설정은 latency를 늘릴 뿐만 아니라(데이터 전송 지연) 효과적인 대역을 증가시킨다. 각각의 디바이스가 인터럽트 없이 버스를 통해 많은 데이터를 전송하기 때문에 PCI 버스 latency timer 세팅은 좀더 효율적으로 사용되고 PCI 디바이스는 더 많은 데이터를 전송할 수 있는 것이다.
다른 한편으로 PCI 디바이스가 낮은 PCI 버스 레이턴시로 설정되어 있다면 다른 카드가 데이터 전송을 해야 할 때 버스를 기꺼이 포기 할 것이다. 데이터 전송 지연이 훨씬 느려진다. 왜냐하면 어떤 디바이스도 늘어난 시간동안 버스를 붙잡고 있지 않을 것이기 때문이다. 이것의 단점은 낮게 설정된 PCI bus latency timer가 두개 이상의 PCI 디바이스가 동시에 작동할 때 효율적인 PCI 버스 대역을 감소시킨다는 점이다. 많은 데이터 폭주는 자주 발생하지 않으며 버스 제어는 오버헤드를 늘리며 빠르게 변한다.
대부분의 Linux 배포판에는 pci-utils라고 하는 툴이 포함되어 있다. 이것으로 PCI 디바이스의 latency timer 세팅을 보고 변경 할 수 있다. 현재 PCI latency 세팅을 보기 위해서 다음과 같이 해보자:
이 명령어를 타이핑하면 PCI 디바이스에 대한 모든 정보가 매우 자세하게 나온다. 각 디바이스에 대한 PCI 레이턴시 세팅은 세 번째 라인에 나온다. IRQ 세팅 바로 전이다.
PCI latency 접근방법
사운드 문제와 관련된 것은 어떻게 되었는가? 글쎄, 디폴트 PCI latency 설정으로 인해서 사운드 문제를 경험했다. V550이 3D acceleration을 수행할 때 PCI 버스를 억제했다. V550는 AGP 2X 카드이다. 그래서 AGP (안정성을 위해)를 끌 때, 메인 메모리를 75%로 유지하기위해 카드의 대역을 줄인다. V550는 더욱 느려진 PCI 버스를 통해 같은 양의 데이터를 보내려하기 때문에 PCI 버스는 거의 100% utilization에 가까워지고 이것은 사운드 하드웨어에 문제를 일으킨다. 오디오 디바이스는 PCI 레이턴시 문제에 특별히 민감하다. 이유는 오디오 디바이스는 일반적으로 데이터 버퍼가 작고 버퍼를 피하기 위해 제 시간에 오디오 데이터가 전달되어야 하기 때문이다. 현재의 설정으로는 V550는 많은 PCI 대역을 사용하고 있다. 데이터를 사운드 카드로 도달하도록 하기에는 충분하지 못하다. 그래서 나는 오디오 왜곡(distortion)을 경험했던 것이다. 버퍼 언더런(buffer underrun) 때문이다.
두 가지 가능한 솔루션이 있다. 우선 가장 확실한 솔루션은 setpci 명령어를 사용하여 V550의 PCI latency timer를 줄이는 것이다. 이는 PCI 버스를 더욱 빠르게 공유하게 하고 다른 디바이스가 작은 latency로 데이터를 전송할 수 있도록 한다. setpci 명령어를 사용하여 문제 해결을 시도 했고 효과가 있었다. 하지만 이 방법을 사용하지 않기로 했다. 왜냐하면 나는 이미 불구가 된 3D 그래픽 퍼포먼스를 극대화 하고 싶었기 때문이다.
나는 두 번째 방법인 높은 퍼포먼스를 시도하기로 했다. 550 PCI bus latency를 줄이는 대신 나의 모든 디바이스의 PCI latency를 비교적 높은 값인 176으로 늘렸다. (디바이스는 일반적으로 디폴트 레이턴시가 32이다. 디폴트 레이턴시가 200이상인 V550을 제외하고). 그런다음 레이턴시에 민감하게 반응하는 디바이스의 PCI 버스 레이턴시를 최대 248로 설정했다. 이것은 내가 바라던 대로 문제를 해결했다. 사운드 카드는 비교적 많은 데이터를 전송하게 되었다. 버스의 사용을 극대화하고 버퍼 언더런(buffer underrun)을 줄였다. 동시에 나의 다른 디바이스들은 많은 양의 데이터를 전송할 수 있게되었다. 버스를 호깅(hogging)하는 문제가 줄어들고 버스를 효율적으로 사용하였다. 나는 이 솔루션을 특별히 좋아한다. 왜냐하면 나의 개발 머신의 PCI 버스의 대역 효율성을 늘리면서 동시에 오디오 문제도 해결했기 때문이다. 시스템 시작 스크립트를 소개한다. 몇가지 트릭이 사용되었다:
첫 번째 라인에서, -d *:* 옵션은 setpci에게 이 세팅을 모든 PCI 디바이스에 적용하라고 명령한다. latency_timer=b0 옵션은 타이머를 176로 설정한다. 마지막 두개의 라인에 있는 -s 옵션은 PCI 버스/슬롯 기능에 따라 PCI 디바이스를 지정한다. 벤더와 디바이스 ID에 의해서가 아니다. 이것은 lspci를 타이핑 할 때 각각의 디바이스에 대해 나와있는 첫번째 숫자들이다. ff 값은 latency timer를 256으로 설정한다. setpci에 의해 248까지 내려간다. PCI latency timer와 관련된 문제를 경험했다면 lspci와 setpci를 사용하여 시스템에 맞는 최적의 값을 찾아보라. 하드웨어가 이것을 핸들할 수 있다면 가장 큰 latency timer 값이 가장 좋다.
원문 : http://www-903.ibm.com/developerworks/k ··· hw2.html
Daniel Robbins
President/CEO, Gentoo Technologies, Inc.
2001년 7월
Linux가 명성을 얻는데에는 안정성이 큰 기여를 했다. 하지만, 세상에서 가장 안정적인 OS라도 하드웨어에 결함이 있거나 설정이 잘못되었다면 아무런 소용이 없을 것이다. NVIDIA의 드라이버를 사용하여 Linux에서 NVIDIA TNT 그래픽 카드를 실행했었던 필자(Daniel Robbins)의 경험을 이야기한다. IRQ와 PCI latency 타이머 문제를 진단하고 픽스하는 방법을 설명한다.
불안정성의 원인들
안정성 문제는 불완전한 하드웨어 때문에 발생하는 것만은 아니다. 주로 적절하지 못한 하드웨어 설정이나 미약한 드라이버 때문에 문제가 발생한다.
NVIDIA에는 Linux용 디스플레이 드라이버가 있다. 이러한 드라이버들은 Xfree86 4.0에 포함된 표준 2d-only NVIDIA 드라이버 보다 많은 장점을 가지고 있다. 그 중 하나는 3D 지원이 강화되었다는 점이다. 게다가 Mesa의 강화 버전이라기 보다는 공식적인 OpenGL 1.2 구현이라는 특징이 있다. 이러한 NVIDIA기반의 그래픽 카드를 가지고 있다면 강화된 드라이버를 사용하고 싶을 것이다. 적어도 이론상으로는 그렇다. 그들을 적절하게 작동시키려는 시도를 통해 많은 것을 배웠다.
Linux NVIDIA 드라이버를 설치하고 나서(참고자료), Xfree86를 시작했고 모든 3D 애플리케이션 구동을 시작했다. 지금은 매우 훌륭히 작동한다. 그 이전까지 나는 3D acceleration을 이용하기 위해 Windows NT를 재부팅 해야만 했다. 지금 NT는 신경쓰지 않는다. 3D 애플리케이션을 사용하기위해 재부팅 하는 것은 다소 성가신 일이였지만 Linux를 남겨놓아 머신을 재부팅한다. 하지만 한시간 정도 만지작거리면 Linux 3D aspiration에 치명적인 퇴보를 경험한다. 머신이 잠긴다. 마우스가 멈추고 스크린은 얼어붙었다. 시스템을 재부팅해야 했다.
사실 몇 가지 종류의 안정성 문제가 있었다. 하지만 무엇이 문제를 일으키는지 정확히 몰랐다. 안정적이지 않은 하드웨어 탓인지 카드가 잘못 설정 되어서 그런지 확실하지 않았다. 어쩌면 드라이버와 관련된 문제일지도 모른다. 또는 VIA KT133 기반의 Athlon 마더보드 때문인지도 모른다. 문제가 어떤것이든 간에 빨리 해결하고 싶었다. 이 글에서 나는 하드웨어 안정성 문제를 해결했던 과정을 설명하겠다. 나와 똑 같은 문제를 가지고 있지 않더라도, 문제를 진단하고 픽스하는 과정들은 본질적으로 Linux 하드웨어의 다른 문제 유형에도 적용할 수 있으리라 생각한다.
하드웨어 점검
내 머리속에 떠오른 생각 중 하나는 내가 가지고 있는 하드웨어가 약간 미약하다는 것이였다. 반면 Diamond Viper V550은 Windows NT에서는 아무런 문제가 없었다. 하지만 Linux에서는 칩이 경직되고 열(heat) 과 관련된 lock-up이 생긴다. V550는 극도로 뜨거워졌고 OEM heatsink는 그런대로 적절했다. 나는 V550을 위해 heatsink/fan이 통합된 것을 구입하기 위해 PC Power and Cooling을 참조했다. (참고자료)
그렇게 해서 나는 Video Cool을 구입했다. 비디오 카드에 있던 OEM heatsink를 떼고 TNT 칩을 청소하고 칩의 상단에 Video Cool을 붙였다. 결과는? 비디오 카드는 더 이상 뜨거워지지 않았다. 하지만 lockup은 계속되었다. 이 특별한 경험을 통해서 배운 한 가지 교훈은 시스템이 시작하기에 적당할 정도로 냉각되었다는 것을 확신할 수 있다면 부적절한 냉각으로 인한 컴포넌트의 오작동에 대해서 걱정하지 않아도 된다는 것이다. workstation과 서버를 뜨거워지지 않게 유지하며 실행하기 위해서는 시간과 노력이 필요하다. 열과 관련된 문제들을 연구해본 결과 lockup은 결함있는 하드웨어 때문이 아니라는 것을 알았다. 다른 요소를 찾아보기 시작했다.
새로운 드라이버만이 솔루션인가?
나는 부분적으로는 NVIDIA의 드라이버가 문제의 원인이라고 생각했다. 다행히 신 버전 드라이버가 배포되었다. 그래서 나는 즉시 업그레이드 하였다. 안정성 문제를 해결할 수 있기를 희망했다. 하지만 openprojects.net의 다른 #nvidia channel을 검토한 결과 어떤 누구도 드라이버를 안정적으로 실행시키지 못했다. 내가 나서야 할 때라고 생각했다.
#nvidia와 관련하여 어떤 사람은 V550가 IRQ를 다른 카드와 공유하지 않는 것이 분명하다고 말한다. 표준 XFree86 드라이버와는 다르게 NVIDIA 드라이버는 올바른 작동을 위해 IRQ가 필요하다. 드라이버가 "cat /proc/interrupts"를 입력하고 지켜보았다. V550는 IDE 컨트롤러와 인터럽트를 공유하고 있었다. 문제를 해결했던 방법을 설명하기에 앞서 IRQ에 대해 간단히 설명하겠다.
PC는 IRQ (일반적으로 하드웨어 인터럽트)를 사용하여 비디오 카드와 디스크 컨트롤러와 같은 주변의 디바이스가 실행 준비가 된 데이터를 가지고 있는 CPU에 신호를 주도록 한다. PCI 버스라는 것이 존재하기 전에는 머신의 디바이스 마다 전용의 IRQ를 가지고 있어야만 했다. 여러분이 아직도 ISA 주변장치를 사용하고 있다면 그 사실은 여전히 유효하다. 모든 non-PCI 디바이스들은 전용의 IRQ를 가져야 한다.
IRQ & PCI
하지만 이것은 PCI bus와는 약간 다르다. PCI는 네 개의 IRQ를 할당하여 시스템의 PCI/AGP 카드에 의해 사용될 수 있다. 일반적으로 이러한 IRQ는 다중 디바이스들 사이에서 공유 될 수 있다. (공유를 수행하는 모든 디바이스가 PCI와 AGP 디바이스인지를 확인하라.) IRQ 공유는 중요하다. 다섯개의 PCI와 한 개의 AGP 슬롯을 가지고 있는 머신에 있어 특히 중요하다. IRQ 공유 없이는 시스템에 IRQ를 사용하는 카드를 네 개 이상 가질 수 없다.
하지만 PCI IRQ 공유에도 제한은 있다. 일반적으로 마더보드 BIOS와 Linux 커널이 PCI IRQ 공유를 지원하는 반면 특정 PCI 카드는 IRQ를 다른 디바이스와 공유할 때 작동하지 않을 때가 있다. 간헐적인 시스템 lockup을 경험했다면, 특히 lockup이 특정 하드웨어 디바이스의 사용과 관련이 있다면 모든 PCI 디바이스가 고유의 IRQ를 사용하도록 해야한다. 우선 디바이스들이 IRQ를 공유하고 있는지를 보는 것이 첫 번째 순서이다:
디스크, 사운드, 비디오, SCSI 같은 하드웨어 디바이스를 사용한다. 이것으로 Linux가 이러한 다양한 디바이스에 대한 인터럽트를 핸들할 것임을 알 수 있다.
지금까지 Linux 커널이 핸들했던 모든 인터럽트 리스트와 카운트(count)를 나타내는 "cat /proc/interrupts"는 리스트의 가장 오른쪽 칼럼을 참조하라. 한 행에 두 개 이상의 디바이스 리스트가 있다면 그것들이 특정 IRQ를 공유하고 있는 것이다.
해당 디바이스 중 하나가 non-PCI 디바이스 (ISA 또는 기타 레거시 카드)라면 IRQ 충돌이라는 것을 알 것이다. BIOS나 isapnptools 패키지 또는 physical peripheral 카드에 물리적 점퍼를 가해서 픽스할 수 있다. 디바이스가 마더보드에 내장되었다면 이것이 물리적 PCI 슬롯을 차지하지 않더라도 PCI 디바이스일 가능성이 크다는 것을 주목하라.
해당되는 모든 디바이스들이 PCI 또는 AGP 디바이스라면 하드웨어에 따라서 문제가 생길 수도 있다. 모든 PCI/AGP 디바이스를 고유의 IRQ를 할당하는 방법이 있다:
시스템 BIOS에 들어가서 사용되지 않은 주변기기를 사용 불가 상태로 만든다 (USB, 병렬 포트 등.). 이는 많은 IRQ를 이용할 수 있게 하고 사용되는 하드웨어가 고유의 IRQ를 할당받을 수 있는 기회를 얻게된다.
BIOS의 PnP 섹션으로 들어가 BIOS가 "non-PnP" OS로 설정되었다는 것을 확인한다. 그런 다음 "Reset ESCD data" 옵션을 선택한다. 이것은 BIOS가 여러분이 다음에 재부팅 할 때 모든 하드웨어 디바이스에 IRQ를 재할당 할 수 있도록 한다.
Linux를 부팅하고 cat /proc/interrupts를 사용하고 결과를 본다. 다행스럽게도 모든 디바이스들이 고유의 IRQ를 가지고 있다.
만일 PCI 디바이스가 여전히 IRQ를 공유하고 있다면 여러분이 취할 수 있는 두 가지 옵션이 있다. 어떤 BIOS 셋업 프로그램은 특정 PCI 슬롯에 특정 IRQ를 할당할 수 있다. 만일 여러분이 이러한 드문 BIOS 셋업 프로그램 중 한 개를 가지고 있다면 이 기능을 사용하여 충돌을 줄이는데 사용할 수 있다. 만일 BIOS에 이 옵션이 없다면 또 다른 확실한 방법이 있다. 컴퓨터를 종료하고 파워를 끈다. PC의 전원을 끄는 것이다. 그리고 몇 분 정도 기다린다. 그런다음 시스템 케이스를 열고 PCI 카드를 다른 슬롯으로 옮긴다. 이 옵션은 약간 이상한 방법이지만 아주 훌륭하게 작동할 것이다. 특히 시스템에 몇 개의 여분의 PCI 슬롯이 있다면 더욱 효과적이다. (단, 각 카드에 맞는 정확한 슬롯을 찾는데는 시간이 걸린다).
"PCI 카드 교체하기 트릭"을 통해 내 시스템의 모든 디바이스가 고유의 IRQ를 얻을 수 있었다. 내 IDE 디바이스중 두 개는 여전히 IRQ를 공유하고 있다:
하지만 이것은 정상이다. 왜냐하면 ide2와 ide3 디바이스 Promise FastTrak IDE 카드의 같은 칩으로 통합되었기 때문이다.
거의 모든 디바이스는 고유의 IRQ를 가지고 있기 때문에 나의 accelerated 드라이버를 시도했지만..한 시간이 못되어서 lockup 되었다. 공유된 PCI IRQ 문제게 아니라는 것이 명백해졌다.
끊임없이 발생하는 문제들
몇 시간이 흐른 후에 NVIDIA 드라이버를 완벽하게 실행시킬 수 있는 어떤 방법을 발견했다. 하지만 좀 더 느려졌고 AGP를 사용할 수 없었다. 내가 이러한 상황을 원하지 않은 만큼 현재 버전의 드라이버는 AGP가 XF86Config에 한 라인을 추가함으로서 완전히 꺼질 수 있도록 하였다. AGP를 꺼 놓은 상태에서 비디오의 메모리 대역을 4x로 줄였다. 하지만 매우 느렸던 3D는 다른 어떤 3D acceleration 보다 훨씬 빠르다. AGP를 사용 불가 상태로 만든 후에 마침내 안정적인 시스템을 갖게 되었다. 하지만 이러한 일시적인 솔루션은 다른 문제를 야기시켰다. 3D OpenGL 애니메이션이 지속될 때마다 오디어 플레이백은 고르지 못했다!
다행스럽게도 나는 오디오 문제에 대한 솔루션을 찾을 수 있었다. setpci 유틸리티를 사용하여 PCI 디바이스에 더욱 적절한 PCI bus latency 타이머를 설치했다. 문제 해결 방법을 설명하겠다. 하지만 우선 배경 지식이 필요하다.
PCI 버스는 제한된 대역의 공유 리소스이기 때문에 하나의 PCI가 다른 PCI 카드의 퍼포먼스에 좋지 않은 영향을 끼칠 가능성이 있다. 예를들어 A라는 PCI 카드가 버스를 통해 데이터를 보내는 중에 동시에 B라는 PCI 카드가 데이터 전송을 시도한다면? A가 과연 버스 사용을 허용할까? 아니면 데이터 전송을 그대로 진행할까? 만일 그렇다면 얼마나 오래 진행할까?
PCI latency timer
이러한 질문에 대한 대답은 각각의 PCI 디바이스가 가지고 있는 설정 가능한 PCI bus latency timer와 관련이 있다. 각각의 PCI 디바이스에 맞는 PCI 버스 latency timer 값을 적절히 설정하는 것은 Linux의 역할이다. 대부분 디폴트 세팅이 적당히 되어있다 (최적의 세팅은 아니다). 모든 디바이스는 훌륭히 수행되고 시스템도 적절히 작동한다. PCI 버스 latency timer는 0에서 248 까지 설정할 수 있다. 디바이스가 zero 세팅이 되어있을 경우 다른 디바이스가 전송이 필요하다면 이것은 즉시 버스를 포기한다. 만일 디바이스 세팅이 248로 되어 있다면 멈추기 전까지 오랜 시간동안 버스의 사용을 지속할 것이다. 다른 디바이스는 순서를 기다린다.
모든 디바이스의 PCI 버스 latency timer가 비교적 높게 설정되어 있고 많은 데이터가 버스를 통해 보내질 때 PCI 카드는 일반적으로 버스 제어권을 얻기 전까지 더 오랜시간을 기다린 후에 데이터 전송을 시작할 수 있다. 하지만 버스 제어권을 일단 얻으면 버스가 다른 디바이스로 넘어가기 전까지 이것을 통해서 많은 데이터를 전송할 수 있을 것이다. 왜냐하면 높은 PCI 버스 latency timer 설정은 latency를 늘릴 뿐만 아니라(데이터 전송 지연) 효과적인 대역을 증가시킨다. 각각의 디바이스가 인터럽트 없이 버스를 통해 많은 데이터를 전송하기 때문에 PCI 버스 latency timer 세팅은 좀더 효율적으로 사용되고 PCI 디바이스는 더 많은 데이터를 전송할 수 있는 것이다.
다른 한편으로 PCI 디바이스가 낮은 PCI 버스 레이턴시로 설정되어 있다면 다른 카드가 데이터 전송을 해야 할 때 버스를 기꺼이 포기 할 것이다. 데이터 전송 지연이 훨씬 느려진다. 왜냐하면 어떤 디바이스도 늘어난 시간동안 버스를 붙잡고 있지 않을 것이기 때문이다. 이것의 단점은 낮게 설정된 PCI bus latency timer가 두개 이상의 PCI 디바이스가 동시에 작동할 때 효율적인 PCI 버스 대역을 감소시킨다는 점이다. 많은 데이터 폭주는 자주 발생하지 않으며 버스 제어는 오버헤드를 늘리며 빠르게 변한다.
대부분의 Linux 배포판에는 pci-utils라고 하는 툴이 포함되어 있다. 이것으로 PCI 디바이스의 latency timer 세팅을 보고 변경 할 수 있다. 현재 PCI latency 세팅을 보기 위해서 다음과 같이 해보자:
이 명령어를 타이핑하면 PCI 디바이스에 대한 모든 정보가 매우 자세하게 나온다. 각 디바이스에 대한 PCI 레이턴시 세팅은 세 번째 라인에 나온다. IRQ 세팅 바로 전이다.
PCI latency 접근방법
사운드 문제와 관련된 것은 어떻게 되었는가? 글쎄, 디폴트 PCI latency 설정으로 인해서 사운드 문제를 경험했다. V550이 3D acceleration을 수행할 때 PCI 버스를 억제했다. V550는 AGP 2X 카드이다. 그래서 AGP (안정성을 위해)를 끌 때, 메인 메모리를 75%로 유지하기위해 카드의 대역을 줄인다. V550는 더욱 느려진 PCI 버스를 통해 같은 양의 데이터를 보내려하기 때문에 PCI 버스는 거의 100% utilization에 가까워지고 이것은 사운드 하드웨어에 문제를 일으킨다. 오디오 디바이스는 PCI 레이턴시 문제에 특별히 민감하다. 이유는 오디오 디바이스는 일반적으로 데이터 버퍼가 작고 버퍼를 피하기 위해 제 시간에 오디오 데이터가 전달되어야 하기 때문이다. 현재의 설정으로는 V550는 많은 PCI 대역을 사용하고 있다. 데이터를 사운드 카드로 도달하도록 하기에는 충분하지 못하다. 그래서 나는 오디오 왜곡(distortion)을 경험했던 것이다. 버퍼 언더런(buffer underrun) 때문이다.
두 가지 가능한 솔루션이 있다. 우선 가장 확실한 솔루션은 setpci 명령어를 사용하여 V550의 PCI latency timer를 줄이는 것이다. 이는 PCI 버스를 더욱 빠르게 공유하게 하고 다른 디바이스가 작은 latency로 데이터를 전송할 수 있도록 한다. setpci 명령어를 사용하여 문제 해결을 시도 했고 효과가 있었다. 하지만 이 방법을 사용하지 않기로 했다. 왜냐하면 나는 이미 불구가 된 3D 그래픽 퍼포먼스를 극대화 하고 싶었기 때문이다.
나는 두 번째 방법인 높은 퍼포먼스를 시도하기로 했다. 550 PCI bus latency를 줄이는 대신 나의 모든 디바이스의 PCI latency를 비교적 높은 값인 176으로 늘렸다. (디바이스는 일반적으로 디폴트 레이턴시가 32이다. 디폴트 레이턴시가 200이상인 V550을 제외하고). 그런다음 레이턴시에 민감하게 반응하는 디바이스의 PCI 버스 레이턴시를 최대 248로 설정했다. 이것은 내가 바라던 대로 문제를 해결했다. 사운드 카드는 비교적 많은 데이터를 전송하게 되었다. 버스의 사용을 극대화하고 버퍼 언더런(buffer underrun)을 줄였다. 동시에 나의 다른 디바이스들은 많은 양의 데이터를 전송할 수 있게되었다. 버스를 호깅(hogging)하는 문제가 줄어들고 버스를 효율적으로 사용하였다. 나는 이 솔루션을 특별히 좋아한다. 왜냐하면 나의 개발 머신의 PCI 버스의 대역 효율성을 늘리면서 동시에 오디오 문제도 해결했기 때문이다. 시스템 시작 스크립트를 소개한다. 몇가지 트릭이 사용되었다:
첫 번째 라인에서, -d *:* 옵션은 setpci에게 이 세팅을 모든 PCI 디바이스에 적용하라고 명령한다. latency_timer=b0 옵션은 타이머를 176로 설정한다. 마지막 두개의 라인에 있는 -s 옵션은 PCI 버스/슬롯 기능에 따라 PCI 디바이스를 지정한다. 벤더와 디바이스 ID에 의해서가 아니다. 이것은 lspci를 타이핑 할 때 각각의 디바이스에 대해 나와있는 첫번째 숫자들이다. ff 값은 latency timer를 256으로 설정한다. setpci에 의해 248까지 내려간다. PCI latency timer와 관련된 문제를 경험했다면 lspci와 setpci를 사용하여 시스템에 맞는 최적의 값을 찾아보라. 하드웨어가 이것을 핸들할 수 있다면 가장 큰 latency timer 값이 가장 좋다.
원문 : http://www-903.ibm.com/developerworks/k ··· hw2.html
"System" 카테고리의 다른 글
- 리눅스에서의 메모리관리 (0)2007/05/04
- 리눅스 시스템 콜 레퍼런스 (0)2007/05/04
- Linux 하드웨어 안정성 가이드, Part 2 (0)2007/05/04
- Linux 하드웨어 안정성 가이드, Part 1 (0)2007/05/04
- 리눅스 시스템 서비스를 병렬화하여 부팅 속도 향... (0)2007/05/03
Leave your greetings.