Linux Ethernet-Howto: Frequently Asked Questions

3. Frequently Asked Questions

이곳에는 이더넷에 연결된 리눅스를 사용하는 것에 대한 자주 물어보는 질문들(FAQ)이 있다. 몇몇 특정 질문들은 `제조업체별'에 정리되어 있다. 여러분이 답변을 원하는 질문들은 이미 다른 누군가가 질문한 것(그리고 답변이 되었다!)이고, 만일 여기서 원하는 답변을 찾지 못할 경우,적어도 아래같이 여러분이 원하는 뉴스 아카이브가 있는 곳을 찾을수 있을 것이다. Dejanews.

3.1 Alpha Drivers -- 구하고 사용하기

내가 듣기로는 내 카드에 사용할 수 있는 갱신되거나 시험버전의 알파 드라이버가 있다 고 하는데 어디서 구할수 있을까?

`새' 드라이버들의 가장 최신버전은 Donald의 ftp 사이트 cesdis.gsfc.nasa.gov 안의 /pub/linux/ 에서 구할수 있다. 여기있는 것들은 자주 바뀌므로, 찾을수 있을 것이다. 또한, WWW 브라우저를 사용해서

Don's Linux Home Page

에 가면 여러분이 찾고자 하는 드라이버를 더욱 쉽게 찾을수 있다. (WWW 브라우저로 찾으면 소스의 탭을 스페이스나 기타등등으로 바꾸어버린다 - ftp를 사용하거나 확실하지 않다면 적어도 다운받을 FTP URL은 알아둬라.)

자, 만일 그것이 정말로 알파 드라이버, 또는 알파 이전의 드라이버라면, 그 이름처럼 다루기 바란다. 다른 말로 하면, 여러분이 그것으로 무엇을 하는지 이해하지 못할지라도 불평하지 말라는 것이다. 만일 여러분이 어떻게 설치하는지 이해할수 없다면, 아마도 시험 해보지 못할 것이다. 또, 그것 때문에 여러분의 머신이 다운되더라도 불평하지 마라. 대신 잘 작성된 버그 리포트를 보내거나, 패치를 보내준다면 더 좋다!

표준 커널 소스 트리에 포함되어 있는 몇몇 `사용가능한' 실험적인/알파 드라이버들에 대해 알아두어야 할 것들이다. make config를 했을때 가장 먼저 물어보는 것은 ``개발중인 또는 완전하지 않은 코드/ 드라이버들에 대해 표시(Prompt for development and/or incomplete code/drivers)''할것인지 아닌지 이다. 알파/실험적인 드라이버들을 포함할 것인지에 관한 질문들을 받으려면 여기에 `Y'라고 답해야 한다.

3.2 머신당 하나이상의 이더넷 카드 사용하기

리눅스에서 두개의 이더넷 카드를 사용하려면 무엇이 필요하나요?

이 질문에 대한 답은 드라이버가 적재가능한 모듈로 사용되고 있는지 커널에 직접 컴파 일되어 들어가 있는 것인지에 따라 달라진다. 지금의 대부분의 리눅스 배포본들은 모듈러 드라이버를 사용한다. 이들은 배포되고 있는 수많은 커널들과 각각의 다른 드라이버들을 만들어 저장한다. 단일 기본 커널이 사용되는 대신에 특정 사용자의 시스템에 필요한 각각 의 드라이버들이 시스템이 부팅될 때 드라이버 모듈 파일들에 충분히 접근할수 있도록 한번 로드된다. (일반적으로 /lib/modules/에 저장된다.)

드라이버를 모듈로: PCI 드라이버들의 경우, 보통 설치된 모든 카드의 브랜드 모델을 자동적으로 찾아낼 것이다. 그러나, ISA 카드들의 경우, 카드를 찾아내는 작업이 안전하지 않기 때문에, 보통 모듈이 어디서 카드를 찾을수 있는지 I/O 주소를 가르쳐 줄 필요가 있다. 이 정보는 /etc/conf.modules에 저장되어 있다.

예를 들어, 사용자가 두개의 ISA NE2000 카드를 가지고 있고, 하나는 0x300에 그리고 다른것은 0x240에 있다. 이들에 대한 /etc/conf.modules의 내용을 보면,

        alias eth0 ne
        alias eth1 ne
        options ne io=0x240,0x300

이것이 하는 것은 이렇다. 이것은 관리자 (혹은 커널)이 modprobe eth0 혹은 modprobe eth1라고 하면, ne.o 드라이버가 eth0나 eth1를 위한 드라이버를 로드할 것이다. 그리고 ne.o 모듈이 적재될때, io=0x240,0x300 라는 옵션을 가지고 로드되어, 드라이버가 어디에서 카드를 찾을지 알려주게 된다. 0x는 중요하다 - DOS 세상에서 일반적으로 사용하던 300h같은 것들은 통하지 않는다. 0x240 와 0x300의 순서를 바꾸는 것은 eth0 와 eth1의 물리적 카드 순서를 바꾸는 것이 된다. 대부분의 ISA 모듈 드라이버들은 이 예와 같이 여러개의 카드를 다루기 위해 콤마로 구분된 여러개의 IO 값을 받을수 있다. 그러나, 3c501.o 모듈과 같은 몇몇 (구형의?) 드라이버들은 모듈을 로드할 때마다 단지 하나의 카드만을 다룰수 있다. 이 경우에 두 장의 카드를 모두 찾기 위해서 여러분은 모듈을 두번 로드할 수 있다. 이 경우에 /etc/conf.modules 화일은 다음과 같다.

        alias eth0 3c501
        alias eth1 3c501
        options eth0 -o 3c501-0 io=0x280 irq=5
        options eth1 -o 3c501-1 io=0x300 irq=7

이 예에서 -o 옵션은 여러분이 같은 이름으로 두 모듈을 로드할 수 없기 때문에 각 모듈 객체마다 유일한 이름을 부여하기 위해서 사용된다. irq= 옵션도 또한 카드의 하드웨어 IRQ 설정을 정해주기 위해서 사용된다. (이 방법은 콤마로 구분된 I/O 값들을 받아들이는 모듈들을 사용할 때에도 쓸수 있다. 그러나 이것은 그것이 정말 필요하지 않을 때에도 모듈이 두번씩 로드되기 때문에 덜 효율적이다.)

마지막 예로, 0x350에 있는 3c509 카드와 0x280에 있는 SMC Elite16 (WD8013) 카드를 가진 유저가 있다. 그 설정은 다음과 같을 것이다.

        alias eth0 wd
        alias eth1 3c503
        options wd io=0x280
        options 3c503 io=0x350

PCI 카드들의 경우, PCI 카드의 I/O 주소는 안전하게 찾아낼수 있기 때문에 여러분은 보통 적절한 드라이버 이름과 같이 ethN 인터페이스와 연관된 alias 줄만이 필요하다.

사용가능한 모듈들은 보통 /lib/modules/`uname -r`/net에 저장되어 있다. 여기서 uname -r 명령은 커널 버전 (예: 2.0.34)을 돌려준다. 여러분은 거기서 여러분의 카드에 맞는 것을 찾을수 있다. 여러분이 conf.modules 화일에 한번 제대로 설정을 했다면, 다음과 같이 해서 시험해 볼수 있다.

        modprobe ethN
        dmesg | tail

`N'은 여러분이 시험해 보고자하는 이더넷 인터페이스의 숫자이다.

커널 안에 컴파일되어 들어있는 드라이버로: 만일 여러분이 커널에 컴파일되어 들어있는 드라이버를 가지고 있다면, 여러개의 이더넷 카드를 사용하기 위한 모든 것이 그 안에 있다. 그러나, 기본적으로 하나의 이더넷 카드만이 자동으로 찾아진다는 것에 주의하라. 이것은 예민한 카드들을 찾을때 발생할수 있는 부팅시의 에러를 피하도록 해준다.

(알아둘것: 2.1.x 후반대의 커널에서는, 부트 검색이 안전과 불안전으로 나누어져 있고, 그래서 모든 안전 (예: PCI와 EISA) 검색은 모든 관련된 카드들을 자동적으로 찾아주게 된 다. (여러개의 이더넷 카드를 가진 시스템에서 적어도 하나의 ISA 카드를 가지고 있는 경우 에는 여전히 다음의 과정중 하나를 해야만 한다.)

두번째 (그리고 새번째, 그리고...) 카드를 자동으로 검색하는데는 두가지 방법이 있다. 가장 쉬운 방법은 보통 LILO를 통해 하는것처럼 부팅시에 커널로 인수를 전달하는 것이다. 두번째 카드를 찾는 것은 부팅시에 ether=0,0,eth1처럼 간단한 인수를 사용하 면 된다. 이 경우에 eth0와 eth1는 부팅시에 찾아지는 순서대로 정해지게 된다. 만일 카드가 eth0는 0x300에, 그리고 eth1는 0x280에 있다면, 다음과 같이 하면 된다.

LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1

ether= 명령은 위에서 보여지는 바와 같이 IRQ + I/O + 이름을 받아들이게 된다. 전체 문법과 특정 카드 인자들, 그리고 LILO 팁들을 보려면 다음을 보면 된다. 이더넷 인수 전달하기...

이 부팅시의 인수들은 영구적이기 때문에 여러분은 매번 다시 쳐넣을 필요가 없다. LILO 설정 옵션중 `append'는 LILO 매뉴얼을 보기 바란다.

두번째 방법은 (권장하지 않는다) Space.c 를 편집해서 I/O 주소 항목의 0xffe0 부분을 영으로 바꿔주는 것이다. 0xffe0 부분은 이 장치에 대해서 검색을 하지 않는다는 것을 말해준다 -- 이것을 영으로 바꾼다는 것은 장치에 대한 자동검색을 할수 있게 하는 것이다.

여기서 알아둘 점은 여러분이 만약 리눅스를 두 네트워크 사이의 게이트웨이로 사용하려고 한다면, 커널을 IP 포워딩 가능으로 해서 재컴파일 해야만 한다는 것이다. 보통 구식 AT/286에 `kbridge'같은 소프트웨어를 사용하는 것이 더 좋은 해결방법이다.

여러분이 이것을 넷 서핑 도중에 보고 있다면, Donald가 그의 WWW 사이트에 갖고 있는 미니 하우투를 볼수도 있을 것이다. 다음을 확인해 보라. Multiple Ethercards.

3.3 `ether=` 명령이 아무것도 하지 않는다. 왜지?

위에서 설명한 것처럼, ether= 명령은 단지 커널안에 컴파일되어 들어있는 드라이버들에 대해서만 작동한다. 요즘 대부분의 배포판들은 모듈 형식으로된 드라이버들을 사용하므로 ether= 명령은 더이상 거의 사용되지 않는다.(몇몇 오래된 문서들은 이 변화를 반영하여 갱신되고 있다.) 만일 여러분이 이더넷 드라이버 모듈에 옵션들을 적용하려 한다면, 반드시 /etc/conf.modules 화일을 고쳐야만 한다.

만일 여러분이 지금 컴파일된 드라이버를 사용하고 있고, 여러분의 LILO 설정화일 에 ether=를 추가했다면, 바뀐 설정 화일로 실행되도록 lilo를 재실행하기 전까지는 효과가 없다는 것을 명심해라.

3.4 3.4 NE1000 / NE2000 카드(그리고 호환제품)들의 문제

Problem: PCI NE2000 호환카드가 v2.0.x로 부팅시 찾질 못한다.

Reason: v2.0.30 이하에서의 ne.c 드라이버는 단지 RealTek 8029 기반 호환카드들의 PCI ID 넘버만을 알고있기 때문이다. 그러므로 PCI NE2000 호환카드로 나온, 다른 PCI ID 넘버를 가진 카드들을 드라이버가 찾아 내지 못하는 것이다.

Solution: 가장 쉬운 해결책은 리눅스 커널버전 v2.0.31 (또는 그 이상)으로 업그레이드하는 것이다. 이들은 다섯가지 다른 NE2000-PCI 칩들에 대한 ID 넘버를 알고 있기 때문에, 부팅시에나 모듈이 적재되는 시간에 자동으로 그들을 찾아낼 것이다. 만일 여러분이 2.0.34 (또는 그 이상)으로 업그레이드 하면, 거기에는 오리지날 ISA/PCI 드라이버보다 약간 더 작고 보다 효율적인 PCI만의 특정 NE2000 드라이버가 있다.

Problem: PCI NE2000 호환 카드가 v2.0.x에서 부팅시나 ne.o 모듈을 적재할때 ne1000 (8비트 카드!) 라고 나오고, 그리고나서는 작동하지 않는다.

Reason: 몇몇 PCI 호환제품들은 바이트 폭의 접근을 구현하지 않는다.(그리고 진짜 100% NE2000 호환 이 아니다). 이 때문에 NE1000 카드로 생각하고 찾아내는 결과가 나타나게 된다.

Solution: 위에서 설명했던 것처럼 v2.0.31 (또는 그 이상)으로 업그레이드 해야만 한다. 그 드라이버(들) 은 현재 이 하드웨어 버그를 검사한다.

Problem: PCI NE2000 카드가 성능 팁 부분에 설명된대로 윈도우 사이즈를 줄일때에도 정말 최악의 성능을 나타낸다.

Reason: 개발해서 판매된지 십년도 더 된 오리지날 8390 칩의 스펙 표를 보면, 최상의 안정성을 위해 각 쓰기 작업하기 전에 칩이 느린 읽기를 요청한다고 알려져 있다. 그 드라이버는 v1.2 커널 때부터 기본적으로 그런 기능을 사용할수 없게 되어 있다. 한 사용자가 말하기로는 그 `잘못 된 기능'을 다시 사용가능하게 하면 값싼 PCI NE2000 호환 카드의 성능에 도움이 된다고 한다.

Solution: 이 문제의 해결책은 단지 한 사람한테서만 나왔기 때문에, 그렇게 희망적이지는 않다. 쓰기 전에 읽기를 다시 가능하게 고치는 것은 linux/drivers/net/안의 드라이버 화일 을 간단하게 편집하면 된다. NE_RW_BUGFIX를 포함하고 있는 줄의 주석을 제거하 고 커널이나 모듈을 적절하게 재컴파일해주면 된다. 만일 이것이 여러분에게 도움이 된다면, 성능의 차이와 카드/칩셋 종류를 기술하여 우리에게 e-mail을 보내주기 바란다. ( ne2k-pci.c 드라이버에 대해서도 동일하게 할 수 있다.)

Problem: ne2k-pci.c 드라이버가 PCI NE2000 카드에서 timeout waiting for Tx RDC와 같은 에러 메세지를 보내고 제대로 작동하지 않는다.

Reason: 여러분의 카드와/또는 카드에서 PCI 버스로의 연결이 이 드라이버에서 사용된 long word I/O optimization을 다룰수 없는 것이다.

Solution: 우선, BIOS/CMOS 설정에서 안정적인 작동을 방해하는 PCI 버스 타이밍에 관련된 어떠한 설정 이라도 확인해 보라. 그렇지 않다면 ISA/PCI ne.c 드라이버를 사용해서 (아니면 ne2k-pci.c에서 #define USE_LONGIO부분을 없애고) 카드를 사용하도록 해야한다.

Probem: ISA Plug and Play NE2000 (RealTek 8019같은)이 잡히지 않는다.

Reason: 원래의 NE2000 사양에는 (그리고 리눅스 NE2000 드라이버도) 플러그 앤 플레이에 대한 지원은 없다.

Solution: PnP를 사용할수 없게 하기 위해서 카드와 함께 따라오는 DOS 설정 디스크를 사용해서, 카드에 특정 I/O 주소와 IRQ를 설정한다. 그리고 /etc/conf.modules에 options ne io=0xNNN와 같은 라인을 추가한다. 여기서 0xNNN는 여러분이 카드에 설정한 16진수 I/O 주소이다. (여기서는 여러분이 모듈 드라이버를 사용한 다고 가정한다. 만일 아니라면 부트시에 ether=0,0xNNN,eth0 인수를 사용한다). 여러분은 또한 BIOS/CMOS 설정에 들어가서 PnP 대신에 Legacy-ISA용 IRQ에 표시해야 한다. 여러분이 만약 몇몇 다른 운영체제와의 호환성을 위해서 PnP를 가능한 상태로 남겨둬야 한다면 isapnptools 패키지를 찾아보라. man isapnp를 쳐서 이것이 여러분의 시스템에 이미 설치되어 있는지 확인해보라. 아니면, 다음의 URL을 찾아보라.

ISA PNP Tools

Problem: NE*000 드라이버가 부트 검색시에 `not found (no reset ack)'라는 메세지를 출력한다.

Reason: 이것은 위의 변화와 관계가 있다. 초기 확인작업 후에 8390은 검색된 I/O 주소에 있게되고 리셋이 이루어진다. 카드가 완전하게 리셋이 될때, 리셋이 끝났다고 알리게 된다. 여러분의 카드가 그렇지 않다면, 드라이버는 현재 어떠한 NE 카드도 없다고 가정하게 된다.

Solution: 드라이버에게 부팅시에 0xbad의 사용하지 않는 mem_end 16진수 값을 사용해 여러분이 안좋은 카드를 가지고 있다는 것을 알려줄수 있다. 여러분은 0xbad의 재정의를 사용할 때 카드에 영이 아닌 I/O 주소를 제공해야만 한다. 예를 들어, 리셋되지 않는 카드가 0x340에 있다면 다음과 같이 쓰면 될것이다.

LILO: linux ether=0,0x340,0,0xbad,eth0

이것은 여러분의 카드가 리셋을 받아들이지 않더라도 카드 탐색을 계속하도록 해준다. 만일 여러분이 드라이버를 모듈로 사용하고 있다면, I/O 주소를 준것처럼 bad=0xbad 옵션을 넣어줄수 있다.

Problem: 처음 네트워크에 접속할 때 NE*000 카드가 머신을 정지시킨다.

Reason: 이 문제는 1.1.57정도의 오래된 커널에서 현재에까지 보고되고 있다. 이것은 몇몇 소프트웨어 로 설정가능한 호환 카드들에서만 나타난다. 그들은 어떤 특별한 방법으로 초기화를 해주어야 한다.

Solution: 몇몇 사람들은 리눅스에서 카드를 작동시키기위해 웜부팅 (즉, loadlin 이나 `세손가락인사 - ctrl+alt+del:역자주')하기 전에 제공되는 DOS 소프트웨어 설정 프로그램이나 DOS 드라이버 를 실행할때에 나타난다고 보고했다. 이것은 이 카드들이 현재 리눅스 드라이버들이 하는 것 과는 약간 다르게, 특정한 방식으로 초기화되어야 한다는 것을 나타낸다.

Problem: 0x360에서 NE*000 이더넷 카드가 잡히질 않는다.

Reason: NE2000 카드는 0x20의 I/O 폭을 갖는데, 이때문에 패러렐 포트의 주소인 0x378를 침범하게 된다. 그자리에는 두번째 플로피 콘트롤러(만일 있다면)가 0x370에 그리고 두번째 IDE 콘트롤러가 0x376--0x377가 있을수 있다. 만일 그 포트(들)가 이미 다른 드라이버에 의해 등록이 되어 있다면, 커널은 탐색을 하지 않을 것이다.

Solution: 여러분의 카드 주소를 0x280, 0x340, 0x320같은 주소로 옮기거나 패러렐 프린터 지원 없이 컴파일하라.

Problem: 뭔가를 프린트하기만 하면 네트워크가 `죽어버린다' (NE2000)

Reason: 위와 같은 문제이지만, I/O영역을 확인하지 않는 더 오래된 커널을 사용중이다. 위에서 처럼 해결하면 되고, 여러분이 쓰는 것보다 새 커널을 구하라.

Problem: NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found. (invalid signature yy zz)

Reason: 우선 먼저, 0xNNN 주소에 NE1000 또는 NE2000 카드가 있습니까? 그리고 만일 있다면, 하드웨 어 주소가 제대로된 것처럼 나오는가? 그렇다면, 여러분은 형편없는 NE*000 호환카드를 갖고 있는 것이다. 모든 NE*000 호환제품들은 카드의 SA PROM의 14 와 15 번째 바이트에 0x57값을 가지고 있다. 여러분이 가진것은 그렇지 않다 -- 대신 `yy zz'를 가지 고 있다.

Solution: 여기에는 두가지 방법이 있다. 가장 쉬운 방법은 위의 `no reset ack' 문제에서 설명한 것처럼 0xbad mem_end 값을 사용하는 것이다. 이렇게 하면 서명 확인을 하지않고 지 나갈 것이고, 영이 아닌 I/O 주소값도 주어질 것이다. 이 방법은 커널을 재컴파일할 필요가 없다.

두번째 방법은(해커들에게 해당되겠지만) 드라이버를 바꾸고, 여러분의 커널(또는 모듈)을 재컴파일하는 것이다. 그 드라이버(/usr/src/linux/drivers/net/ne.c)는 약 42번 라인정도에 "Hall of Shame(부끄러움의 전당)" 목록이 있다. 이 목록은 잘못된 호환품들을 찾아내는데 사용된다. 예를 들어, DFI 카드들은 14와 15 바이트에 0x57를 사용하는 대신, PROM의 처음 3바이트에 `DFI'를 사용한다.

Problem: 머신이 부팅중에 `8390...' 이나 `WD....' 메세지 바로 다음에서 멈춰버린다.

Solution: 여러분의 NE2000 주소를 0x340 같은 것으로 바꾸어라. 아니면, ``ether='' 인수와 함께 ``reserve=''인수를 사용함으로써 다른 장치 드라이버의 검색에서 카드를 보호할수 있다.

Reason: 여러분의 NE2000 호환제품은 충분히 좋은 호환품이 아니다. 작동하는 NE2000은 어떠한 드라이버의 자동검색에도 걸린다. NE2000을 다른 자동검색에서 벗어나도록 덜 쓰이는 주소로 바꾸면, 여러분의 머신은 부팅될 것이다.

Problem: 부팅시에 SCSI 탐색도중 멈춰버린다.

Reason: 이것도 위의 문제와 같으므로, 이더넷 카드의 주소를 바꾸거나, 아니면 reserve/ether 부팅 인수들을 사용하면된다.

Problem: 부팅시에 사운드 카드를 찾는도중에 머신이 멈추어 버린다.

Reason: 아니다, 그것이 실제로는 조용한 SCSI 탐색도중이므로, 위의 문제와 같다.

Problem: NE2000 이 부팅시에 찾아지지 않는다 - 부트 메세지가 전혀 없다.

Solution: 그것이 찾아지지 않는데는 수많은 원인이 있을수 있기 때문에 `마법의 해결책'은 없다. 다음의 내용들은 여러분이 가능한 문제들을 해결하는데 도움을 줄 것이다.

1) 여러분이 필요로 하는 장치 드라이버들만 가지고 새 커널을 만든다. 여러분이 정말로 새 커널로 부팅하고 있는 것인지 확인하라. lilo를 실행하는 것을 까먹지 않았는지 등등..으로 인해 이전의 것으로 부팅될수 있다. (부팅시에 나오는 만든 시간/날짜를 자세히 보라.) 우리는 이전에 모든것을 다 했다.System.map 화일안의 ne_probe와 같은 이름들을 확인해서, 새 커널에 정말로 그 드라이버가 포함되어 있는지 확인하라.

2) 부트 메세지들을 주의해서 살펴보라. 그곳에 `NE*000 probe at 0xNNN: not found (어쩌구 저쩌구)' 같은 ne2k 검색에 관한 어떠한 언급이 있는지, 아니면 조용하게 실패하는지 말이다. 거기에는 큰 차이가 있다. 로그인한 뒤에 부트 메세지를 다시보려면 dmesg|more를 사용하거나, 부팅된 후 로그인 프롬프트가 나온뒤에 Shift-PgUp을 눌러서 화면을 위로 스크롤해 가며 보면된다.

3) 부팅한 후에, cat /proc/ioports를 치고 카드가 필요로하는 입출력공간 전부가 비어있는지 확인하라. 여러분의 카드가 0x300에 있다면 ne2k 드라이버는 0x300-0x31f 를 요구할 것이다. 만일 어떤 다른 장치 드라이버가 그 범위내에 한 포트라도 등록했다면, 그 주소의 검색은 되지 않고 다음 검색 주소로 넘어가 계속하게 될 것이다. 일반적인 경우에 lp 드라이버가 0x378를 갖거나 두번째 IDE 채널이 0x376를 가지므로 ne 드라이버가 0x360-0x380를 검색하지 못하게 한다.

4) cat /proc/interrupts에 대해서도 위와 같이 해보라. 여러분의 이더넷 카드가 설정되어 있는 인터럽트에 혹시 다른 장치가 등록되어 있는지 확인하라. 이 경우에는, 검색은 이루어지지만, 이더넷 드라이버는 원하는 IRQ 라인을 얻을수 없다며 부팅시해 크게 불평할 것이다.

5) 만일 여러분이 아직도 드라이버의 말없는 실패에 당황해하고 있다면, 드라이버를 편집해서 검색을 위한 몇줄의 printk()를 추가하라. 예를 들어, ne2k에서는 linux/drivers/net/ne.c를 다음과 같이 몇몇줄에 추가/삭제(`+' 나 `-' 로 표기) 할수 있다.

    int reg0 = inb_p(ioaddr);

+    printk("NE2k probe - now checking %x\n",ioaddr);
-    if (reg0 == 0xFF)
+    if (reg0 == 0xFF) {
+       printk("NE2k probe - got 0xFF (vacant I/O port)\n");
        return ENODEV;
+    }

그렇게 하고나면 각각의 포트 주소에 대한 확인 메세지를 출력하게 되고, 여러분은 여러분의 카드 주소가 검색되는지 안되는지 볼수 있을 것이다.

6) 여러분은 또한 Don의 ftp 사이트(하우투내에 잘 설명되어 있다)에서 ne2k 점검 도구를 가져와서 여러분이 리눅스로 부팅한 후에 카드를 찾을수 있는지 없는지 볼수 있다. `-p 0xNNN' 옵션을 사용해서 카드를 찾을 곳이 어디인지 말해줄수 있다. (기본적으로 0x300가 설정되어 있지만 부팅시의 검색과는 달리 다른 주소에 대한 검색은 이루어 지지 않는다.) 카드를 찾았을 경우에 대한 결과 출력은 다음과 같다:

Checking the ethercard at 0x300.
  Register 0x0d (0x30d) is 00
  Passed initial NE2000 probe, value 00.
8390 registers: 0a 00 00 00 63 00 00 00 01 00 30 01 00 00 00 00
SA PROM  0: 00 00 00 00 c0 c0 b0 b0 05 05 65 65 05 05 20 20
SA PROM 0x10: 00 00 07 07 0d 0d 01 01 14 14 02 02 57 57 57 57

        NE2000 found at 0x300, using start page 0x40 and end page 0x80.

여러분의 리지스터 값과 PROM 값들은 아마 서로 다를 것이다. 알아둘 것은 16비트 카드의 경우 모든 PROM 값들은 두배이며, 이더넷 주소 (00:00:c0:b0:05:65)는 처음 행에, 그리고 두개의 0x57 사인은 PROM의 마지막에 나타난다.

0x300에 설치된 카드가 없을때의 결과 출력은 다음과 같다:

Checking the ethercard at 0x300.
  Register 0x0d (0x30d) is ff
  Failed initial NE2000 probe, value ff.
8390 registers: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
SA PROM        0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
SA PROM 0x10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

 Invalid signature found, wordlength 2.

0xff 값들은 비어있는 I/O 포트를 읽을때 반환되는 값이다. 만일 검색된 영역 안에 어떤 다른 하드웨어가 있다면, 0xff 아닌 값들을 보게 될 것이다.

7) 제공되는 DOS 드라이버나 설정 프로그램을 실행하고 난 후에 DOS 부트 플로피에서 (loadlin으로) 리눅스로 웜부팅을 해보라. 이것은 카드를 초기화하는 좀 다른(즉 비표준적인) "마법"이다.

8) Russ Nelson의 ne2000.com 패킷 드라이버로 여러분의 카드를 볼수 있는지 해보라 -- 만일 아니면, 상황은 별로 좋지 않다. 예는 다음과 같다.

A:> ne2000 0x60 10 0x300

인수들은 소프트웨어 인터럽트 벡터, 하드웨어 IRQ, 그리고 I/O 주소이다. 여러분은 어떠한 msdos 아카이브에서나 pktdrv11.zip을 얻을수 있다 -- 현재 버전은 아마 11이상일꺼다.

3.5 SMC Ultra/EtherEZ 와 WD80*3 카드들의 문제

Problem: 다음과 같은 메세지가 나타난다:

        eth0: bogus packet size: 65531, status=0xff, nxpg=0xff

Reason: 이것은 공유 메모리 문제이다.

Solution: 이문제의 가장 일반적인 원인은 ISA 메모리 장치들안에 매핑이 설정되지 않은 PCI 머신들 때문이다. 그러므로 받은 패킷들의 데이타를 가지고 있는 카드의 RAM 대신에 PC의 RAM(모두 0xff 값)을 끝까지 읽는다.

쉽게 고칠수 있는 다른 전통적인 문제들은 보드 충돌, 캐쉬를 가지거나 그 영역에 대해 `shadow ROM'을 가능할게 하는것, 아니면 여러분의 ISA 버스가 8Mhz보다 빨르게 작동하는 경우이다. 이들도 또한 이더넷 카드상의 메모리 실패 숫자가 많은데, 만일 여러분의 카드중에 그러한 것이 있다면 점검 프로그램을 실행해보라.

Problem: SMC EtherEZ 가 비공유 메모리 (PIO) 모드에서 작동하지 않는다.

Reason: Ultra 드라이버의 오래된 버전들은 카드가 공유 메모리 모드에서만 작동하도록 되어 있다.

Solution: 커널 버전 2.0 이상에 포함된 드라이버는 programmed I/O모드에서의 작동도 지원한다. v2.0 이나 그 이상으로 업그레이드하라.

Problem: 구형 wd8003 과/또는 점퍼설정이 가능한 wd8013가 항상 IRQ를 잘못 얻는다.

Reason: 구형 wd8003 카드들과 점퍼설정이 가능한 wd8013 호환제품들은 드라이버가 IRQ 설정을 읽어들일 EEPROM을 가지고 있지 않다. 드라이버가 IRQ를 읽어들일수 없으면, 그다음에는 자동으로 IRQ를 찾는다. 그리고 만일 자동 IRQ가 영을 반환하면, 드라이버는 8비트 카드에게는 IRQ 5를, 16비트 카드에게는 IRQ 10을 할당한다.

Solution: 자동 IRQ 검색 코드를 피하려면, 여러분의 모듈 설정 화일에(또는 커널내의 드라이버일 경우 부팅시에 인수를 이용해서) 여러분의 카드 점퍼가 설정되어 있는 IRQ가 무엇인지 적어서 커널에 알려야 한다.

Problem: SMC Ultra 카드가 wd8013로 잡히는데, IRQ와 공유 메모리 주소가 잘못되게 잡힌다.

Reason: Ultra 카드는 wd8013과 매우 비슷해 보여서, 만일 Ultra 드라이버가 커널내에 존재하지 않으면, wd 드라이버는 ultra를 wd8013으로 잘못 인식하게 된다. ultra의 검색은 wd의 검색보다 먼저하게된다. 그래서 이런일은 보통 일어나지 않는다. ultra는 wd8013과 달리 IRQ와 메모리 주소를 EEPROM에 저장하므로, 가짜 값들이 보고된다.

Solution: 여러분에게 필요한 드라이버들만을 커널내에 담아 재컴파일을 한다. 만일 여러분이 한 머신에 wd 와 ultra 카드를 모두 가지고 있고, 모듈을 사용한다면 ultra 모듈을 먼저 로드하라.

3.6 3Com 카드들의 문제

Problem: 3c503이 IRQ N을 고르는데, 다른 장치들도 IRQ N을 필요로한다. (eg. CD ROM 드라이버, 모뎀, 등등.) 커널안에 컴파일하지 않고 이것을 고칠수는 없을까?

Solution: 3c503 드라이버는 {5, 9/2, 3, 4}의 순서대로 비어있는 IRQ를 탐색한다. 그리고 사용하고 있지 않은것을 고른다.드라이버는 카드가 ifconfig되어지고 있을때 고르게 된다.

만일 여러분이 모듈 드라이버를 사용하고 있다면, 여러분은 IRQ 값을 포함해서 많은 것들을 설정하기위해 모듈 인자들을 사용할수 있다.

아래에서는 IRQ9를 선택하고, 주소는 0x300,<무시된 값>, 그리고 if_port #1(외부 단자:external transceiver)로 정하고 있다.

io=0x300 irq=9 xcvr=1

또한, 만일 드라이버가 커널내에 컴파일되어 있으면, 부팅시에 LILO에 인자들을 넘겨줌으로해서 같은 값을 설정할수 있다.

LILO: linux ether=9,0x300,0,1,eth0

다음에서는 IRQ3을 선택하고, 기반 주소를 탐색하며, <무시된 값>, 그리고 기본 if_port #0 (내부 단자:internal transceiver)로 정한다.

LILO: linux ether=3,0,0,0,eth0

Problem: 3c503: 설정된 인터럽트 X 가 잘못된 것이므로, 자동 IRQ를 사용할 것임.

Reason: 3c503 카드는 단지 IRQ{5, 2/9, 3, 4}중에 하나만 사용한다. (이들은 카드에 연결되어있는 선일뿐이다.) 만일 여러분이 위에 설정된 값이 아닌 IRQ 값을 넘겨주면, 여러분은 위와같은 메세지를 받게될 것이다. 보통, 3c503에는 특정 인터럽트 값을 정해줄 필요가 없다. 3c503은 ifconfg시에 자동IRQ를 사용해서, {5, 2/9, 3, 4}중의 하나를 IRQ값으로 갖게 된다.

Solution: 위에 나열된 올바른 IRQ값들중에 하나를 사용하거나, IRQ 행을 전혀 사용하지 말고 자동IRQ를 쓸수있게 하라.

Problem: 제공되는 3c503 드라이버들은 AUI (thicknet) 포트를 사용하지 않는다. 어떻게 기본 thinnet 포트를 통해 사용할수 있을까?

Solution: 3c503 AUI 포트는 커널내장 드라이버의 경우에는 부팅시에, 모듈의 경우는 모듈 삽입시에 선택할수 있다. 그 선택은 현재 사용되지 않는 dev->rmem_start 변수의 낮은 비트에 오버로드되어진다. 그러므로 커널에 내장된 드라이버에 사용하기 위한 부트시의 인자는 다음과 같다.

LILO: linux ether=0,0,0,1,eth0

모듈로 적재할때 AUI 포트를 정해주려면, 단지 xcvr=1를 여러분의 I/O 와 IRQ 값과 함께 모듈 옵션 행에 추가하면 된다. To specify the AUI port when loading as a module, just append xcvr=1 to the module options line along with your I/O and IRQ values.

3.7 어떤 카드에도 특화되지 않은 FAQ들.

리눅스와 ISA Plug and Play 이더넷 카드들

최선의 결과를 얻기 위해서는(그리고 악영향을 최소한으로) 여러분의 카드에 딸려오는 (보통 DOS)프로그램을 사용해서 PnP 메카니즘을 사용하지 못하게 하고, I/O 주소와 IRQ를 정하면 된다. 여러분이 사용하는 I/O 주소가 부트시에 드라이버에 의해 탐색되는지 확인하고, 만일 모듈을 사용한다면 /etc/conf.modules안에 io=에 주소를 적어준다. 여러분은 또한 BIOS/CMOS 설정에 들어가서 IRQ를 PnP 대신에 Legacy-ISA로 설정해야 한다(여러분의 컴퓨터가 이 옵션을 가지고 있다면 말이다).

여러분은 보통 DOS기반의 설정 프로그램을 실행하기 위해 DOS를 설치할 필요는 없다. 제공되는 플로피 디스크에서 바로 실행하기 위해 DOS 부팅 디스크를 사용해도 되고, 공짜인 OpenDOS 와 FreeDOS를 다운받아 쓸수도 있다.

만일 여러분이 다른 운영체제와의 호환을 위해 PnP가 필요하다면 부팅때마다 리눅스가 카드를 설정하도록 하기 위해서 isapnptools 패키지를 사용해야 한다. 이 경우에도 여전히 드라이버가 탐색할수 있도록 카드의 I/O 주소를 정해주거나 io= 옵션을 주고 확인해야 한다.

이더넷 카드가 부팅시에 잡히지 않는다.

이 경우의 일반적인 원인은 사람들이 그들의 특정 카드에 대한 드라이버를 내장하지 않은 커널을 사용하기 때문이다. 모듈식 커널의 경우에는, 모듈의 적재 요청이 없다거나, 아니면 모듈 옵션으로 특정한 I/O 주소를 정해주지 않았기 때문이다.

만일 여러분이 대부분의 리눅스 배포판에서 설치하는 것처럼 모듈 기반의 커널을 사용하고 있다면, 그 배포판이 제공하는 설정 유틸리티를 사용해서 카드의 모듈을 선택하길 바란다. ISA 카드들의 경우에는, 만일 설정 유틸리티가 옵션에 관해 물어본다면, I/O 주소를 정해서 옵션으로(예를 들어 io=0x340) 추가하면 된다. 만일 설정 유틸리티가 없다면, 여러분은 올바른 모듈 이름(그리고 옵션들)을 /etc/conf.modules에 추가해야 한다 -- 더 자세한 내용은 man modprobe를 보기 바란다.

만일 여러분이 배포판에서 제공되는 미리 컴파일된 커널을 사용하고 있다면, 여러분이 설치한 커널의 문서를 보고, 여러분의 특정 카드에 대한 지원이 들어있는지를 확인하라. 만약 들어있지 않다면, 여러분의 카드에 대한 지원이 있는 커널을 구하거나, 여러분 자신의 것을 만들면 된다.

만일 여러분이 자신에게 필요한 드라이버들만을 가지고 자신의 커널을 만들수 있다면, 커널의 크기도 줄고 (응용 프로그램들을 위해 여러분의 중요한 RAM을 절약!) 민감한 하드웨어를 망가트릴수도 있는 수많은 장치에 대한 탐색을 줄일수 있다. 커널을 만드는 것은 들리는 것처럼 그리 복잡하지 않다. 여러분이 필요한 드라이버가 무엇인지에 대한 질문에 네 또는 아니오로 대답만 해주면, 나머지는 알아서 한다.

그 다음 주된 원인은 여러분의 카드가 필요로하는 I/O 공간의 일부분을 다른 장치가 사용하고 있는 경우이다. 대부분의 카드들은 16 또는 32 바이트의 I/O 공간을 필요로한다. 만일 여러분의 카드가 0x300 에 32 바이트의 공간으로 설정되어 있다면, 드라이버는 0x300-0x31f를 요구하게 된다. 만일 어떤 다른 장치 드라이버가 그 범위내에 어디라도 등록이 되어 있으면, 그 주소에 대한 탐색은 이루어지지 않으며, 드라이버는 아무말없이 다음 탐색 주소로 넘어가서 탐색을 계속하게 된다. 그러므로, 부팅 후에, cat /proc/ioports를 쳐서 카드가 필요로 하는 I/O 주소 공간 모두가 비어있는지를 확인해 보아야 한다.

또다른 문제는 여러분의 카드가 점퍼로 설정된 I/O 주소가 기본적으로 탐색이 되지 않는 것이다. 각 드라이버의 탐색하는 주소 목록은 드라이버 소스내의 주석문 다음에서 쉽게 발견할 수 있다. 비록 여러분의 카드가 설정된 I/O 주소가 목록에 없더라도, 부팅시에(커널에 내장된 드라이버의 경우) ether=명령을 통해 주소를 넘겨줄수 있다. 이 명령은 다음 장소에 설명 되어 있다. 이더넷 인수들 넘겨주기... 모듈 드라이버들의 경우에는 /etc/conf.modules내에 io= 옵션을 사용해서 기본적으로 탐색되지 않는 주소를 정해줄수 있다.

`ifconfig`가 카드에 대해 잘못된 I/O 주소를 보여준다.

그렇지 않다. 여러분이 그 내용을 잘못 해석한 것일뿐이다. 이것은 버그가 아니다. 그리고 보여주는 숫자들은 올바른 것이다. 이러한 현상은 처음 정해진 I/O 포트와 상충되는 자리에 실제 8390칩을 가진 몇몇 8390 기반의 카드들(wd80x3, smc-ultra, 등등)한테서 일어난다. 이것은 dev->base_addr에 있는 값으로, ifconfig로 볼수 있다. 만일 여러분이 여러분의 카드가 사용하는 포트의 전체 범위를 보려면, cat /proc/ioports를 해보면, 여러분이 기대했던 숫자들을 볼수 있을 것이다.

PCI 머신은 카드를 찾아내지만 드라이버는 탐색에 실패한다.

몇몇 PCI BIOS들은 전원을 켰을때 모든 PCI 카드들을 사용할수 있게 하지는 않는데, 특히 BIOS 의 옵션이 `PNP OS'가 사용가능하게 되어있다면 그렇다. 이 잘못된 부분은 아직도 여전히 몇몇 리얼모드 드라이버들을 사용하고 있는 현재의 윈도우 계열을 지원하기 위한 것이다. 이 옵션을 disable로 하거나, 사용할수 없게 설정된 카드를 사용할수 있게하는 코드를 가진 새로운 드라 이버로 업그레이드하면 된다.

PCI 머신내의 공유 메모리 ISA 카드들이 작동하지 않는다 (`0xffff`)

이것은 보통 수많은 0xffff 값들을 읽어들이기 때문에 일어난다. PCI 머신내에서는 공유 메모리 카드들은 만일 여러분이 PCI ROM BIOS/CMOS SETUP 설정을 제대로 하지 않는다면 작동하지 않는다. 여러분은 여러분의 카드가 사용하려고 하는 메모리 영역에 대해서 ISA 버스에서 공유 메모리 접근을 허용하도록 설정해야 한다. 만일 여러분이 어떻게 설정해야 하는지 이해하지 못하겠다면, 여러분을 도와주는 사람이나 지역의 고수들에게 물어보라. AMI BIOS의 경우에는, 보통 "Plug and Play"부분이 있고 그안에 ``ISA Shared Memory Size" 와 ``ISA Shared Memory Base" 설정이 있다. wd8013 이나 SMC Ultra와 같은 카드들의 경우에는 기본적으로 `Disabled'라고 되어있는 것을 16kB로 크기를 바꾸어주고, 여러분 카드의 공유 메모리 주소를 바꾸어주면 된다.

카드가 데이타를 보내는것 같은데 아무것도 받지를 못한다.

cat /proc/interrupts 해보라. 여러분의 카드가 생성한 실행중인 인터럽트 이벤트의 총숫자가 목록에 있을 것이다. 만일 그것이 여러분이 카드를 사용하려고 할때에도 0이거나 더이상 증가하지 않는다면 컴퓨터내에 물리적으로 인터럽트가 충돌하는 다른 장치가 있는 것이다(다른 장치의 드라이버가 설치/사용 가능한가는 아닌가는 신경쓸 필요도 없다). 두 장치중에 하나의 IRQ를 비어있는 것으로 바꾸어라.

비동기 전송 모드 (ATM) 지원

Werner Almesberger 는 리눅스에서의 ATM 지원을 작업하고 있다. 그는 Efficient Networks ENI155p 보드( Efficient Networks) 와 Zeitnet ZN1221 보드 ( Zeitnet) 를 사용해서 작업중이다.

Werner 는 ENI155p용 드라이버가 좀더 안정적이고, ZN1221용 드라이버는 현재 완료되지 않았다고 말한다.

최신의/갱신된 자료는 다음의 URL을 확인해보기 바란다.

리눅스 ATM 지원

기가바이트 이더넷 지원

리눅스에 기가바이트 이더넷에 대한 지원이 있나?

있다, 현재 적어도 두개가 있다. Packet Engines G-NIC PCI 기가비트 이더넷 아답터용 드라이버는 v2.0과 v2.2 커널에서 사용할수 있다. 더 자세한 내용과 지원, 그리고 드라이버 업데이트는 다음을 보라.

http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html

v2.2 커널에서 사용할수 있는 acenic.c 드라이버는 Alteon AceNIC 기가비트 이더넷 카드와 3Com 3c985 같은 다른 Tigon 기반 카드들에서 사용할수 있다. 그 드라이버는 NetGear GA620 에서도 작동해야 하지만, 이것은 아직 확인되지 않았다.

FDDI 지원

리눅스에 FDDI 지원이 있나?

있다. Larry Stefani은 Digital's DEFEA (FDDI EISA)와 DEFPA (FDDI PCI) 카드들로 v2.0용 드라이버를 만들었다. 이것은 v2.0.24 커널에 포함되어 있다. 현재 다른 카드들에 대한 지원은 없다.

Full Duplex 지원

Full Duplex 가 20MBps를 내는가? 리눅스가 그것을 지원하는가?

Cameron Spitzer는 full duplex 10Base-T 카드들에 대하여 다음과 같이 썼다: ``만일 여러분이 full duplex 스위치 허브에 연결한다면, 여러분의 시스템은 충분히 빠르겠지만 아주 월등히는 아니다. 이것은 양방향 연결이 계속되도록 할 뿐이다. full duplex 10BASE-2 나 10BASE-5 같은 것(thin 과 thick coax)은 없다. Full Duplex는 아답터의 충돌 검출을 사용할수 없게 만듦으로 써 작동한다. 이것이 동축 케이블로 할수없는 이유이다; LAN은 그길로는 가지 않을 것이다. 10BASE-T (RJ45 단자)는 보내고 받기위해 분리된 선들을 사용한다. 그래서 동시에 양방향으로 가는 것이 가능하다. 스위칭 허브는 충돌 문제를 살핀다. 전송률은 10Mbps이다.

그러므로 여러분이 볼수 있는 것과 같이, 여전히 단지 10Mbps로 보내고 받을수 있고, 두배의 성능 향상은 기대하지 않는것이 좋다. 그것이 지원되는지 안되는지틑 카드와 사용가능한 드라이 버에 달려있다. 몇몇 카드들은 자동처리를 하기도 하고, 몇몇은 드라이버 지원을 필요로하며, 또 어떤것들은 카드의 EEPROM 설정에서 사용자들이 옵션을 설정해줄 필요가 있다. 단지 심각한/ 걱정많은(serious/heavy) 사용자들만이 두 모드간의 차이에 신경쓸 뿐이다.

SMP 머신상의 리눅스를 위한 이더넷 카드들

만일 여러분이 여분의 돈을 다중 프로세서(MP) 컴퓨터에 쓰려고 한다면, 그만큼 좋은 이더넷 카드를 사야한다. v2.0 커널에서는 정말 이야기의 대상이 되지도 않았지만, v2.2에서는 되고 있다. 대부분의 똑똑하지 못한 구형의 카드들(예를 들어 ISA 버스 PIO 와 공유 메모리 디자인) 은 MP 머신상에서 사용에 대해 조금도 고려하지않고 만들어졌다. 결론적으로 말하자면, 똑똑한 현대적 디자인의 카드를 사고 MP 작업을 다룰수 있게 작성된 (또는 갱신된) 드라이버가 있는지 확인하라. (핵심은 `현대적 디자인'이다 - PCI NE2000은 현대적인 버스상의 적어도 10년이상된 구 디자인이다.) 드라이버 소스내의 spin_lock 를 찾으면, 이는 그 드라이버가 MP 작업을 다룰수 있게 작성된 것이라는 것을 알려주는 것이다. 왜 여러분이 MP를 사용하기 위해서 좋은 카드를 사야 하는지에 대해서는 (그리고 그렇지 않을 경우에는 어떠한 일이 일어나 는지) 다음을 보기 바란다.

커널 v2.0 에서는, `커널내에'(즉, 커널 데이타를 바꾸고, 또는 장치 드라이버들을 실행하는데) 언제나 단지 하나의 프로세서만이 허용되었다. 그러므로 카드의 관점에서는 (그리고 연관된 드 라이버에서도) 단일 프로세서 (UP) 작업과는 작동이 계속된다는 것 말고는 아무런 차이가 없었 다. (이것이 동작하는 리눅스의 MP버전을 구하는 가장 손쉬운 방법이다 - 일정 시간에 단지 하 나의 프로세서만이 전체 커널에 큰 락을 걸도록 하는 것이다. 이 방법은 여러분도 알다시피 동 시에 같은 것을 두 프로세서가 변경하지 못하게 하는 것이다

특정 시간에 커널내에 하나의 프로세서만이 허용되는 상황하에서, 여러분은 실행되는 프로그램 이 자신을 포함하고 의도적인 계산을 할 경우에만 MP 성능을 얻을수 있다. 만일 프로그램이 디스크나 네트워크를 통하여 데이타를 읽고 쓰는 일 같은 입/출력(I/O)을 많이 한다면, 커널내 에 실행중인 하나의 프로세서가 장치 드라이버들의 입출력 요청을 실행하기 위해 시도하는 동안에 다른 모든 프로세서들은 그들의 입출력 요청이 끝나기만을 기다려야 한다. 커널이 병목 이 되어 단지 하나의 프로세서만이 실행중에 있게 되므로, single-lock 인, 입출력이 많은 MP 머신의 성능은 급속도로 단일 프로세서 머신에 가깝게 떨어지게 된다.

이것은 생각했던 것보다 확실히 떨어지기 때문에 (특히, 파일/WWW 서버, 라우터, 등등) v2.2 커널에서는 더 좋은 grained locking을 가지게 되었다 - 이것은 동시에 하나이상의 프로세서가 커널내에 존재할수 있다는 것을 뜻한다. 전체 커널에 대한 하나의 big lock 대신에, 하나 이상 의 프로세서가 동시에 데이타를 복제하는 것을 방지하기 위해서 다수의 작은 락들이 존재하게 되었다. - 즉 하나의 프로세서가 네트워크 카드의 드라이버를 실행하는 동안에, 다른 프로세서 는 동시에 디스크 드라이브에 대한 드라이버를 실행할수 있다.

Okay, with that all in mind here are the snags: The finer locking means that you can have one processor trying to send data out through an ethernet driver while another processor tries to access the same driver/card to do something else (such as get the card statistics for cat /proc/net/dev). Oops - your card stats just got sent out over the wire, while you got data for your stats instead. Yes, the card got confused by being asked to do two (or more!) things at once, and chances are it crashed your machine in the process.

그래서, UP에서 작동하는 드라이버들은 더이상 충분치 않다 - 이들은 설정 데이타의 받고, 전송하고, 복사하는 세가지 작업들을 카드가 안정된 작동을 할정도로 직렬화된 카드의 접근제어 락들을 갱신해야만 한다. The scary part here is that a driver not yet updated with locks for stable MP operation will probably appear to be working in a MP machine under light network load, but will crash the machine or at least exhibit strange behaviour when two (or more!) processors try to do more than one of these three tasks at the same time.

The updated MP aware ethernet driver will (at a minimum) require a lock around the driver that limits access at the entry points from the kernel into the driver to `one at a time please'. With this in place, things will be serialized so that the underlying hardware should be treated just as if it was being used in a UP machine, and so it should be stable. The downside is that the one lock around the whole ethernet driver has the same negative performance implications that having one big lock around the whole kernel had (but on a smaller scale) - i.e. you can only have one processor dealing with the card at a time. [Technical Note: The performance impact may also include increased interrupt latencies if the locks that need to be added are of the irqsave type and they are held for a long time.]

Possible improvements on this situation can be made in two ways. You can try to minimize the time between when the lock is taken and when it is released, and/or you can implement finer grained locking within the driver (e.g. a lock around the whole driver would be overkill if a lock or two protecting against simultaneous access to a couple of sensitive registers/settings on the card would suffice).

However, for older non-intelligent cards that were never designed with MP use in mind, neither of these improvements may be feasible. Worse yet is that the non-intelligent cards typically require the processor to move the data between the card and the computer memory, so in a worst case scenario the lock will be held the whole time that it takes to move each 1.5kB data packet over an ISA bus.

The more modern intelligent cards typically move network data directly to and from the computer memory without any help from a processor. This is a big win, since the lock is then only held for the short time it takes the processor to tell the card where in memory to get/store the next network data packet. More modern card designs are less apt to require a single big lock around the whole driver as well.

Alpha/AXP PCI 보드들 상의 리눅스를 위한 이더넷 카드들

v2.0에서는, 단지 3c509, depca, de4x5, pcnet32, 그리고 모든 8390 드라이버들(wd, smc-ultra, ne, 3c503, 등등.)만이 DEC Alpha CPU 기반 시스템들상에서 작동할수 있을 정도로 `아키텍처 독립적'으로 만들어졌다. Donald의 WWW 페이지에서도 아키텍처 독립적으로 만들어진 다른 업데이트된 PCI 드라이버들을 찾을수 있을 것이다.

드라이버를 아키텍처 독립적으로 바꾸는 것은 복잡하지 않다. 여러분은 단지 다음을 따라 하면 된다.

-multiply all jiffies related values by HZ/100 to account for the different HZ value that the Alpha uses. (i.e timeout=2; becomes timeout=2*HZ/100;)

-replace any I/O memory (640k to 1MB) pointer dereferences with the appropriate readb() writeb() readl() writel() calls, as shown in this example.

-       int *mem_base = (int *)dev->mem_start;
-       mem_base[0] = 0xba5eba5e;
+       unsigned long mem_base = dev->mem_start;
+       writel(0xba5eba5e, mem_base);

-replace all memcpy() calls that have I/O memory as source or target destinations with the appropriate one of memcpy_fromio() or memcpy_toio().

Details on handling memory accesses in an architecture independent fashion are documented in the file linux/Documentation/IO-mapping.txt that comes with recent kernels.

SUN/Sparc 하드웨어 상의 리눅스를 위한 이더넷

스팍 상의 모든 최신의 정보는 다음의 사이트에서 볼수 있다.

Linux Sparc

알아둬야 할 것은 몇몇 스팍 이더넷 하드웨어는 호스트 컴퓨터로부터 MAC 주소를 가져오므로, 여러분은 여러개의 인터페이스를 모두 같은 동일한 MAC 주소로 해줄수 있다. 만일 여러분이 동일한 네트워크 상에 하나 이상의 인터페이스를 놓아야 한다면, ifconfig에 유일한 MAC 주소를 할당하기 위해 hw 옵션을 사용하라.

PCI 드라이버들을 스팍 플랫폼에 포팅하는데의 문제는 위에서 언급한 AXP 플랫폼의 경우와 같다. 또한 여기에는 스팍이 빅 엔디안을, 그리고 AXP와 ix86이 리틀 엔디안이기 때문에, 이 엔디안에 관한 문제도 있다.

다른 하드웨어상의 리눅스를 위한 이더넷

여기에는 리눅스가 실행될수 있는, Atari/Amiga (m68k) 같은 몇몇 다른 하드웨어 플랫폼이 있다. Sparc의 경우에는 각 리눅스 포트의 홈 사이트에 가는것이 그 플랫폼에서 현재 지원되는 것을 볼수 있는 가장 좋은 방법이다. (그런 사이트들이라면 링크를 환영합니다 - 여기로 보내주 세요!)

허브없이 10 또는 100 BaseT 연결하기

허브없이 10/100BaseT (RJ45) 기반 시스템들을 함께 연결할수 있는가?

여러분은 2 머신은 쉽게 이을수 있지만, 그 이상은 별도의 장비들/기즈모들(영화 '그렘린'에 나오는 동물이름인것 같네요:역자주)이 필요하다. 다음을 보라. Twisted Pair -- 이 글은 어떻게 해야 하는지에 대해 설명하고 있다. 그리고 몇개의 선과 장비들을 교차해가며 함께 허브에 물릴수는 없다. 허브에서 복제됨 없이 충돌 신호를 보정하는것은 불가능하다.

SIOCSIFxxx: No such device

나는 부팅시에 `SIOCSIFxxx: No such device' 메세지를 받았다. `SIOCADDRT: Network is unreachable'이라는 메세지에 이어서 말이다. 뭐가 잘못된건가?

여러분의 이더넷 장치가 부트/모듈 삽입시에 탐색되지 않고, ifconfig와 route를 실행하면, 작동시킬 장치가 없다고 한다. dmesg | more를 사용해서 부트 메세지를 살펴보고 이더넷카드 탐색에 대한 어떤 메세지가 없는지 보라.

SIOCSFFLAGS: Try again

`ifconfig'를 실행하자 `SIOCSFFLAGS: Try again' 이라는 메세지를 받았다 -- 헛?

여러분의 이더넷 카드가 사용하려고 하는 IRQ를 어떤 다른 장치가 가져서, 이더넷 카드가 그 IRQ를 사용하지 못하는 것이다. 몇몇 장치들은 그들이 IRQ가 필요할때 잡았다가 다시 작업이 끝나면 풀어주므로, 이것을 할당하기 위해 리부팅할 필요가 없다. 예를들면 몇몇 사운드 카드, 시리얼 포트, 플로피 디스크 드라이버, 등등이 있다. 여러분은 cat /proc/interrupts 라고 쳐서 어느 인터럽트가 현재 사용중인가를 볼수 있다. 대부분의 리눅스 이더넷 카드 드라이버들은 `ifconfig'를 통해 사용하려고 열렸을 경우에만 IRQ를 차지한다. 만일 여러분이 필요한 IRQ 라인을 다른 장치가 `놓고 가게'할수 있다면, 여러분은 ifconfig로 `다시 시도할'수 있을 것이다.

`ifconfig'를 사용해서 00:00:00:00:00:00 값의 HW-addr로 UNSPEC 연결

아무런 인수없이 ifconfig를 하면, LINK가 UNSPEC (10Mbs 이더넷 대신)이고 내 하드웨어 주소는 모두 영이다.

이것은 사람들이 그들의 커널 버전보다 높은 새 버전의 `ifconfig' 프로그램을 실행하기 때문에 일어난다. 이 새버전의 ifconfig는 구형 커널과 함께 사용될 때 이러한 속성들을 보고하지 못한다. 여러분은 커널도 업그레이드 하거나, ifconfig를 `다운그레이드'하거나, 아니면 간단히 무시할수 있다. 커널은 여러분의 하드웨어 주소를 알고 있으므로, ifconfig가 그것을 읽지 못한다고 해서 정말로 무슨 일이 일어나는 것은 아니다.

만일 여러분이 사용하는 ifconfig 프로그램이 여러분이 사용하고 있는 커널보다 아주 많이 구형일 경우에는 엉뚱한 정보를 얻어낼수도 있다.

엄청난 양의 RX 와 TX 에러들

아무런 인수들없이 ifconfig를 실행하면, 보내고 받은 패킷 모두에 엄청난 양의 에러숫자가 있는것을 본다. 모두 제대로 작동하는 것 같은데 -- 무엇이 잘못된 것인가?

다시 잘 보라. 이것은 RX packets big number PAUSE errors 0 PAUSE dropped 0 PAUSE overrun 0 이다. TX 열의 경우도 마찬가지다. 그러므로 여러분이 본 큰 숫자들은 여러분의 머신이 주고 받은 패킷의 총 숫자이다. 아직도 혼란스럽다면, 대신에 cat /proc/net/dev라고 쳐보라.

`/dev/` 내의 이더넷 카드들을 위한 내용물들

나는 /dev/eth0가 /dev/xxx에 링크되어 있다. 이것이 옳은 것인가?

여러분이 들은것과는 달리, /dev/* 내의 파일들은 사용되지 않는다. 여러분은 /dev/wd0, /dev/ne0와 같은 어떠한 비슷한 내용들도 지울수 있다.

리눅스와 ``trailers''

`ifconfig'`를 내 이더넷 카드에 사용할때 트레일러를 사용할수 없게 할수는 없나?

여러분은 여러분이 원하지 않더라도, 트레일러를 사용할수 없게 할수 없다. `트레일러'는 네트워킹 레이어에서의 데이타 복사를 피하기 위해 만들어진 것이다. 이 아이디어는 `H' 크기의 작은 고정 크기 헤더를 사용하기 위한 것으로, 패킷의 끝에 다양한 크기의 헤더 정보를 넣고, 페이지가 시작하기 전에 모든 패킷의 `H' 바이트를 할당한다. 이것은 좋은 생각이지만, 실제로는 잘 동작하지 않는것으로 드러났다. 만일 누군가가 `-트레일러'의 사용을 제안한다면, 이것은 수염소의 피의 희생과 같은 것임을 알아두라. 이것은 문제를 해결하는데 아무런 도움도 주지 못하나, 만일 그 스스로 문제가 고쳐진다면 그 누군가는 깊은 마법같은 지식을 알릴수 있을 것이다.

저수준 이더넷 장치에 접근하기

리눅스에서 TCP/IP나 그러한 것들을 통하지 않고 저수준 이더넷 장치에 접근하려면 어떻게 해야 하나?

        int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));

이것은 여러분이 모든 프로토콜 타입을 받는 소켓을 제공한다. recvfrom()를 호출하면 sa_family내의 장치 타입과 sa_data 배열내의 장치이름으로 sockaddr를 채울 것이다. 나는 누가 리눅스용 SOCK_PACKET을 처음 개발했는지 모르지만 정말 대단한 것이다. 여러분은 sendto()를 호출해서 가공하지 않은 것들도 보낼수 있다. 물론 루트권한을 가지고 있어야만 한다.

다음 이전 차례