KLDPWiki: Linuxdoc Sgml/Ethernet-HOWTO

Linuxdoc Sgml/Ethernet-HOWTO

Linux Ethernet-Howto

by Paul Gortmaker

v2.7, 5 May 1999

맹지찬, jcmaeng@kldp.org

2000년 7월 22일

이 문서는 리눅스에서 사용될수 있는 이더넷 장치들과 그들을 어떻게 설치하는지 에 대해서 기록한 Ethernet-Howto이다. 알아둘 것은 이 하우투가 이더넷 카드의 하드웨어와 로우 레벨 드라이버에 관해서 다루며, ifconfig나 route와 같은 소프트웨어적인 면은 다루지 않는다는 점이다. 그러한 것들은 Network Howto 를 보기 바란다.

1. 소 개

Ethernet-Howto는 여러분이 어떤 카드를 사거나 사지 말아야 하고 또, 어떻게 그 들을 설치하는지, 어떻게 하나이상 작동하게 하는지와 다른 일반적인 문제와 답에 대해 다루고 있다. 이 문서는 현재 지원되는 사용가능한 대부분의 일반적인 이더 넷 카드들에 대한 상세한 정보를 담고 있다.

여기서는 소프트웨어 면에 대해서는 다루지 않으며, 그러한 것은 NET-3 Howto에서 다루고 있다. 또한 여기서는 일반적인 리눅스 외적인 일반적인 이더넷에 관한 질문들에 답하지 않는다는 점에 주의하라. 그런 종류의 질문들은 comp.dcom.lans.ethernetFAQ에 수많은 양의 정보가 있으니 보길 바란다. 이 문서들은 다른 모든 뉴스그룹 FAQ들 처럼 rtmf.mit.edu에서 FTP를 통해 얻을수 있다.

현재 개정판은 배포판 커널을 2.2.7까지 다룬다.

Ethernet-Howto는

Paul Gortmaker, p_gortmaker@yahoo.com

가 작성했다.

초기 ASCII 버전만 있는 Ethernet-Howto에 대한 정보의 원래 자료는

Donald J. Becker, becker@cesdis.gsfc.nasa.gov

에게 있었다. 그는 현재 리눅스에서 사용할수 있는 거의 주요한 이더넷 카드의 드라이버를 만든 사람이다. 그는 또한 오리지날 NFS 서버의 작성자이기도 하다. 고맙습니다, Donald!

1.1 이 문서의 새 버전들

이 문서의 새 버전들은 다음의 장소에서 가져올수 있다.

Ethernet-HOWTO

또>는 FTP를 사용하거나 HTML 이외의 포맷을 얻으려 한다면 다음에서 얻을수 있다.

Sunsite HOWTO Archive

이것>은 `공식' 장소이다 - 즉, 다른 수많은 리눅스 WWW/ftp 미러 사이트에서도 찾 을수 있다. 사용할 수 있는 드라이버들에 대한 새 정보들로 갱신될 것이다. 만일 여러분이 보고있는 것이 6개월 이상된 것이라면 새로 갱신된 문서가 있는지 확인해 보기 바란다.

이 문서는 다양한 포맷으로 이용할 수 있다.(postscript, dvi, ASCII, HTML 등등). 나는 HTML(WWW 브라우저를 통해서)이나 Postscript/dvi 포맷으로 보기를 권한다. 이 두가지는 일반 텍스트 ASCII 포맷이 가지지 못한 상호 참조를 포함하고 있기 때문이다.

1.2 Ethernet-Howto의 사용

이 안내문서의 양이 점점 많아지기 때문에, 전부 다 읽기 위해 여러분의 시간을 낭비하고 싶지 않을 것이다. 그리고 이 문서를 전부 다 읽을 필요도 없다. HTML 이나 Postscript/dvi 판은 여러분에게 필요한 것을 더 빨리 찾을 수 있도록 도와 주는 목차를 포함하고 있다.

여러분이 이 문서를 읽는 것은 무언가가 잘 안되거나 무엇을 해야할지 알지 못할 경우이다. 다음 장( <@@ref>#help도와주세요 - 잘안되요!) 은 리눅스를 처음 접하는 사람들에게 올바른 방향을 제시해 주기 위한 것이다.

일반적으로 같은 문제와 질문들이 여러 사람들에게서 반복해서 제기된다. 여러분의 문제나 질문이 자주 제기되는 질문들 중의 하나일 경우, 이 문서의 FAQ 부분에 그 대답이 있다. ( FAQ 장). 도움을 요청하기 전에 누구든지 이 장을 보기 바란다.

여러분이 이더넷 카드를 가지고 있지 않다면, 그리고 카드를 선택하는 것부터 시 작하고 싶다면. ( 무슨 카드를 사야하나...)

만일 이미 이더넷 카드를 가지고 있지만, 그것이 리눅스에서 사용할 수 있을지 확신할수 없다면, 각각의 제조업체와 그들의 카드에 대한 정보를 담고 있는 장을 읽어보면 된다. ( 특정 업체...)

리눅스 드라이버의 기술적인 면에 좀 관심이 있다면, 그에 관한 부분을 볼 수도 있다. ( 기술 정보)

1.3 도와주세요 - 잘안되요!

자, 당황하지 말라. 이 글은 비록 여러분이 이더넷 하드웨어나 리눅스에 관한 특 별한 배경지식이 없어도, 그 과정을 이끌어 줄 것이다.

우선 여러분이 할 일은 여러분의 카드가 어떤 모델인지 알아내서 리눅스에 그 카 드의 드라이버가 있는지 찾아내는 것이다. 다른 종류의 카드는 호스트에 의해 서 로 다른 방법으로 제어가 된다. 리눅스 드라이버는 리눅스에서 이 카드를 사용할 수 있도록 일정한 형식으로 그 제어 정보를 담고 있다. 만약 여러분이 어떤 매뉴 얼이나 다른 어떤 종류의 카드 모델에 대한 정보도 없다면, 알지 못하는 카드를 찾아낼수 있도록 시도할 수 있다. (참고 부분: 알지 못하는 카드 알아내기).

이제 여러분이 가진 카드가 어떤 것인지 알았으면, 특정 카드 부분 (참고 부분: 특정 업체...) 에서 여러분의 카드에 대한 자세한 내용을 읽어보기 바란다. 여기에는 알파벳 순서로, 카드 제조업체들, 각 모델번호와 그들의 리눅스 드라이 버가 있는지 없는지가 담겨있다. 만일 이 목록에 `지원되지 않음'이라고 나오면 여기서 포기해라. 만일 여러분의 카드를 이 목록에서 찾지 못한다면, 카드 매뉴 얼에 알려진 다른 카드 종류의 `호환'이라고 적혀있지 않은지 확인하라. 예를 들 어 수백의, 하지만 수천은 아닌 수많은 카드들이 오리지날 노벨 NE2000 모델과 호환제품으로 만들어진 것들이다.

여러분의 카드에 대한 리눅스 드라이버가 있다는 것을 확인했다고 가정하고, 이 제 여러분은 그것을 찾아서 사용해야 한다. 여러분의 카드에 대한 리눅스 드라이 버가 있다는 것이 모든 커널에 적재되어 있다는 뜻은 아니기 때문이다. (커널은 부트시에 가장 먼저 적재되는 운영체제 핵심으로, 수많은 종류의 하드웨어에 대한 드라이버와 다른 여러가지를 포함하고 있다.) 여러분이 사용하고 있는 리눅스 배포판을 만든 이에 따라서, 그안에는 단지 약간의 이미 만들어진 커널과 더욱 작게 분리된 모듈로 된 모든 드라이버들이 있거나, 수많은 종류의 드라이버가 안 에 적재된 큰 커널이 들어있을수도 있다.

현재 대부분의 리눅스 배포판들은 다양한 드라이버들을 작은 모듈로 해서 담고 있다. 필요한 모듈들은 부팅 과정중에 늦게 적재되거나, 아니면 특정한 장치에 접근할 필요가 있을 때 적재하게 된다. 여러분은 부팅이 된 후에 커널에 모듈을 적재해야 할 것이다. 여러분의 배포판에 모듈을 설치하고 사용하는 것에 대한 정 보는 이 문서의 모듈 부분을 보기 바란다. ( 이더넷 드라이버를 모듈로 사용하기)

여러분이 커널에 미리 만들어져서 들어있는 커널이나 모듈로된 드라이버를 찾지 못했다면, 여러분은 일반적이지 않은 카드를 가지고 있는 것이고, 그러므로 이제 그 카드의 드라이버를 포함한 여러분 자신만의 커널을 만들어야 할 것이다. 리눅 스를 인스톨했었다면, 사용자 커널을 만드는 일은 그리 어려운 일이 아니다. 여 러분이 커널에 넣고자 하는 것에 대해서, 예 또는 아니오로 확실히 답해주고, 그 대로 만들라고 말해주기만 하면 된다. 이 부분에서는 Kernel-HowTo에서 도움을 받을 수 있을 것이다.

이제 여러분은 드라이버가 커널에 함께 들어있거나 또는 모듈로 적재된 커널로 부팅을 했을 것이다. 사람들이 가진 문제들중 절반가량은 어떤식으로든 적재된 드라이버를 가지지 못하는 것인데, 이제 여러분은 올바른 것을 찾았을 것이다.

만일 아직도 작동하지 않는다면, 여러분은 커널이 카드를 제대로 찾아내는지 확 인해봐야 한다. 이것을 확인하기 위해서는, 시스템이 부팅해서 모든 모듈들이 적 재된 후에 로그인해서 dmesg | more 명령을 쳐보면 된다. 이 명령은 커널의 부팅 과정중에 스크린을 지나가는 부트 메세지들을 다시 보게 해주는 것이다. 카드가 제대로 발견되면, 메세지 가운데 어딘가에서 eth0으로 시작하고, 드라이버의 이름과 카드가 설정되어 있는 하드웨어 인자들(인터럽트 설정, 입출력 포트 주소, 등등)이 있는 것을 볼수 있을 것이다. (알아둘것: 부트시에, 리눅스는 시스템에 있는 모든 PCI카드들의 목록을 보여주는데, 어떤 드라이버가 사용될수 있는 것인지는 신경쓰지 말라 - 드라이버 찾기는 나중에 나오므로 이것을 보고 실수하지 말라!)

여러분이 이와 같은 드라이버 확인 메세지를 보지 못했다면, 드라이버가 여러분 의 카드를 찾지 못해서 제대로 작동하지 않은 것이다. 카드가 발견되지 않을 경 우 어떻게 해야 하는지는 FAQ ( faq FAQ장)을 보기 바란다. 여러분이 NE2000 호환카드를 가지고 있다면, 그것 또한 몇몇 NE2000만의 특정한 팁들로 카드를 찾아내는 방법이 FAQ 장에 잘 나와있다.

여러분의 카드가 발견되었지만, 발견 메세지가 몇몇 에러를 담고 있다면, 자원충 돌처럼, 드라이버가 카드를 제대로 초기화하지 못해서 아직 사용할수 없는 것이 다. 이런 종류의 대부분의 일반적인 메세지도, 그 해결법과 함께, FAQ 장에 나와 있다.

발견 메세지가 제대로 된것 같으면, 드라이버가 보여주는 카드의 자원과 실제 카 드의 물리적인 설정(카드상의 조그마한 검은색 점퍼들이나 카드 제조사가 주는 소프트웨어 유틸리티에 의한것 모두)이 같은지를 확인해라. 이들이 정확히 같아 야만 한다. 예를 들어, 여러분의 카드가 IRQ 15로 되어있는데 드라이버는 부트 메세지에 IRQ 10 으로 보여준다면, 이것은 제대로 작동하지 않는다. FAQ장은 수 많은 카드들의 설정 정보를 제대로 찾지 못하는 드라이버에 관한 대부분의 경우 에 대하여 다루고 있다.

이제, 여러분은 모두 제대로 된 인자들을 가지고 찾아진, 모든것이 제대로 작동 하는 카드를 가지고 있다. 만일 아니라면, 소프트웨어나 하드웨어 설정 에러가 있는 것이다. 소프트웨어 설정 에러는 ifconfig와 route 명령으로 올바른 네트워크 주소를 설정해주지 않아서이다. 이에 관한 내용은 Network HowTo와 `네트워크 관리자 가이드'에 자세하게 기술되어 있다. 두 문서 모두 여러분이 설치했던 CD-ROM에 들어있을 것이다.

하드웨어 설정 에러는 자원의 충돌이나 잘못된 설정 (드라이버가 부트시에 찾아 내지 못하는)이 카드가 제대로 작동하지 못하고 멈추게 하는 것을 말한다. 이것 은 보통 몇가지 다른 면으로 보여질 수 있다. (1) 여러분이 ifconfig 를 사용해 장치를 사용하기 위해 열고자 할때 ``SIOCSFFLAGS: 다시 시도하시오''같은 에러 메세지가 뜬다. (2) 드라이버가 eth0 에러 메세지들( dmesg | more로 볼수 있는)을 내보내거나 데이타를 보내거나 받을려 할때마다 잘되지 않는다. (3) cat /proc/net/dev 라고 치면 eth0의 errs, drop, fifo, frame 또는 carrier 열중 에서 영이아닌 숫자들이 보인다. (4) cat /proc/interrupts 라고 치면 카드의 인터럽트 카운트가 0으로 나온다. 대부분의 일반적인 하드웨어 설정 에러들도 FAQ 장에서 다루고 있다.

자, 아직까지도 제대로 되지 않는다면, 이 문서의 FAQ 장을 읽고, 여러분의 카 드에 관한 특정 업체의 부분을 읽어라. 그리고나서도 안되면, 도움을 요청할수 있는 적절한 뉴스그룹에 게시해보길 바란다. 게시할때 관련있는 모든 정보들, 즉, 카드 상표, 커널 버전, 드라이버 부트 메세지, cat /proc/net/dev 출력결과, 문제에 대한 명확한 설명, 그리고 여러분이 시도했던 방법들의 과정같은 정보를 자세하게 적어야 한다.

여러분은 얼마나 많은 사람들이 ``누구 도와줄 사람 없나요? 이더넷이 되질 않 아요.''같은 쓸모없는 글을 게시하는지 알면 놀랄것이다. 뉴스그룹을 읽는 사람 들은 그러한 게시물들은 무시하려하므로, 자세하고 쓸모있는 정보들이 있는 문 제설명들만이 `리눅스 도사'들의 주목을 받을수 있다.

2. 리눅스에서 쓰려면 무슨 카드를 사야하나?

이 질문에 대한 대답은 전적으로 여러분이 네트워크 연결로 하려는 일과 그것이 얼마나 많은 전송량을 갖는지에 달렸다.

여러분이 단지 잠깐씩 ftp와 WWW 연결을 하려는 단일 사용자라면, 낡은 8 비트 ISA 카드만으로도 만족할수 있을 것이다.

만일 여러분이 서버를 설치하고자 한다면, 주고 받는 네트워크 데이타로 인한 CPU 부하를 최소로 유지하는것이 필요하므로, DEC tulip (21xxx) 칩이나 AMD PCnet-PCI 칩처럼 버스 마스터링 기능이 있는 PCI 카드중에 하나를 고르면 된다.

여러분이 위의 중간정도에 해당된다면, 안정된 드라이버가 있는 저가의 PCI 나 16 비트 ISA 카드중에 하나를 고르면 될 것이다.

2.1 어떤 드라이버가 안정된거지?

16비트 ISA 카드들 중에서는, 다음의 드라이버들이 매우 안정되어서, 여러분이 이 드라이버들을 사용하는 카드를 산다면 어떠한 문제도 발생하지 않을것이다.

SMC-Ultra/EtherEZ, SMC-Elite (WD80x3), 3c509, Lance, NE2000.

여기서 말하는 것이 다른 드라이버들이 불안정하다는 말이 아니다. 단지 위의 것들이 모든 리눅스 드라이버들 중에 가장 오래되고 가장 많이 사용되어서, 가 장 안전한 선택이 된것이다.

주의할 점은 몇몇 값싼 마더보드들은 ISA Lance 카드가 사용하는 버스마스터링 과 문제가 있을 수 있고, 몇몇 저가의 NE2000 호환품들은 부팅할때 발견하기에 어려움이 있을수 있다.

리눅스에서 가장 일반적으로 사용되는 PCI 드라이버는 아마도 3Com Vortex/Boomerang (3c59x/3c9xx), DEC tulip (21xxx), 그리고 Intel EtherExpressPro 100. 수많은 PCI-NE2000 호환카드들도 아주 많이 쓰이지만, PCI-NE2000 호환 카드를 사는 것은 낮은 가격이 현재의 고성능 디자인 카드보 다 중요하지 않다면 별로 권장하지 않는다.

2.2 8 bit 대 16 bit 카드

여러분은 아마도 새 8 bit ISA 이더넷 카드를 사려고 하지 않을 것이다. 그러 나 여러분은 다음 몇년동안 컴퓨터를 바꿀때까지 매우 낮은 가격의 그들을 수 없이 찾아볼수 있을 것이다. 이것은 그들을 ``홍-이더넷'' 시스템의 인기제품 으로 만들것이다. 지금은 PCI 카드들이 일반적이기 때문에, 위의 내용은 지금 의 16 bit ISA 카드들에게도 그렇다.

몇몇 8 비트 카드들은 낮은 가격에 적당한 성능을 보이는데, wd803, 3c503 그 리고 ne1000이 그렇다. 3c501은 낮은 성능을 제공하며, 이러한 12년 이상된 XT시절의 것들은 피해야 한다. (그들을 Alan에게 보내주길, 그는 수집한다..)

8 비트 wd8003 카드(fast ISA 버스 상에서)로 빠른 호스트에서 대략 500에서 800kB/s의 다운로드 속도를 얻을수 있으므로, 8 비트 데이타 패스는 성능에 해를 끼치진 않는다. 그리고 만일 여러분의 실제 전송량의 대부분이 원격 사 이트로 가는 것이라면, 어딘가에 병목현상이 있을 것이다. 그렇다면 여러분 이 신경쓸 속도의 차이는 여러분 로컬 서브넷 상에서 실제 활동하는 동안일 것이다.

2.3 32 Bit (VLB/EISA/PCI) 이더넷 카드들

10Mbs 네트워크는 일반적으로 반드시 32 비트 인터페이스를 필요로 하지 않는 다는 것에 주의하라. 8MHz ISA 버스상의 10Mbps 이더넷 카드가 왜 정말로 병 목지점이 아닌지는 Programmed I/O vs. ...를 보아라. 빠른 버스상에 이더넷 카드가 있어도 그것이 더 빠른 전송을 의미하는 것은 아니고, 일반적으로 다중사용자 시스템에 좋은, CPU 부하의 감소를 의미한다.

물론 지금은 일반적인 100Mbps 네트워크에서는 32 비트 인터페이스가 전체 대 역폭을 사용할수 있도록 해준다. AMD는 32 비트 PCnet-VLB 와 PCnet-PCI 칩들 을 가지고 있다. LANCE / PCnet-ISA 의 32 비트 버전에 관한 정보는 AMD PCnet-32부분을 보라.

DEC 21xxx PCI `tulip' 칩은 파워유저들의 또다른 선택이다.( DEC 21040을 보라) 수많은 제조업체들이 이 칩을 사용해서 카드를 생산하고, 그러한 이름 없는 카드들의 가격은 보통 아주 저렴하다.

3Com의 `Vortex' 와 `Boomeran' PCI 카드또한 다른 선택이며, 그것을 사용하 는 기간에 비교해볼때 가격느 매우 저렴하다. ( 3c590/3c595를 보라)

Intel의 EtherExpress Pro 10/100 PCI 카드 또한 리눅스에서 잘 돌아간다고 알려져 있다. ( EtherExpress를 보라)

수많은 호환품 제조업체들은 RealTek 이나 Winbond 칩 기반의 PCI NE2000 호 환품을 만들기 시작했다. 이 카드들도 v2.0.31 이상의 커널에 있는 리눅스의 ne2000 드라이버가 잘 지원한다. 그러나 카드가 시대가 지난 ne2000 드라이버 인터페이스를 사용하기 때문에, 더 빠른 버스 인터페이스로 인한 것 이외에는 이점이 없다. v2.0.34 (그 이상)에서는 이 카드들을 위해 독립된 PCI특화된 드라이버인 ne2k-pci.c도 사용할수 있는데, 이것은 ISA ne.c 드라이버보다 아주 약간의 성능 향상이 있다.

2.4 사용할수 있는 100Mbs 카드와 드라이버들

현재 지원되는 100Mbs 하드웨어의 목록은 다음과 같다. DEC 21140 칩 기반의 카드들; 3c595/3c90x Vortex 카드들; EtherExpressPro10/100B; PCnet-FAST; SMC 83c170 (epic100) 과 HP 100VG ANY-LAN.

각각에 대한 정보는 이 문서의 특정 업체에 관한 정보를 보기 바란다. 그리고 다음의 곳도 확인해보라.

Linux and 100Mbs Ethernet

Donald's 100VG Page

Dan Kegel's Fast Ethernet Page

2.5 100VG 대 100BaseT

100BaseT가 100VG보다 훨씬 더 많이 알려져 있고, comp.os.linux에 게시한 Donald의 오래된 정보안의 다음 내용은 그 상황을 매우 잘 요약하고 있다.

``사정을 잘 모르는 이들을 위해 말하면, 100Mbs 이더넷 표준은 두가지가 경쟁하 고 있다. 그것은 100VG (100baseVG 와 100VG-AnyLAN) 과 100baseT (100baseTx, 100baseT4 그리고 100baseFx 케이블 타입)이다.

100VG가 먼저 시장에 선보였고, 내가 느끼기에도 그것이 100baseTx보다 더 잘 만들어진것 같다. 나는 그가 이기길 바라지만, 확실히 그렇게 되지 않을 것이다. HP et al. 은 몇가지 안좋은 선택을 했다.

1) 표준을 지연시키고 IBM과 협력하여 토큰 링 프레임을 지원한다. 이것은 토큰 링 샵을 업그레이드함으로써 관리자들이 그들이 적합치 않은 기술에 의존함으로써 아주 값비싼 대가를 치룰 필요가 없었기 때문에 `그 당시에는 좋은 생각같아 보였다' 그러나 네트워크 상에 두가지 프레임 타입이 공존할수 없었기 때문에 아무것도 얻을 수 없었고, 토큰링은 너무 복잡하므로, IBM은 100BaseT를 선택했다.

2) 단지 ISA 와 EISA 카드들만 만들어졌다. (PCI 모델은 최근에야 발표되었다.) ISA 버스는 100mbs에는 너무 느리고, EISA 머신들은 매우 적은 수만 존재한다. 그 당시 에는 VLB가 PCI와 함께 일반적이고, 빠르며, 저렴한 선택이었다. 그러나 "구시대" 지식인은 서버는 더 고가의 EISA 버스를 가지고 있어야 한다고 생각했다.

3) 나에게 데이타북을 보내지 않았다. 그렇다, 이것이 100VG가 추락한 진짜 이유다 :-). 나는 모든 프로그래밍 정보를 요청했지만, 내가 받은것이라고는 AT&T에서 보낸 Regatta 칩셋이 얼마나 훌륭한지에 대해 설명해놓은 몇페이지짜리 그럴듯한 컬러 팜플렛 뿐이었다.

2.6 여러분의 카드가 지원하는 케이블의 종류

만일 여러분이 소규모의 ``개인적인'' 네트워크를 구성하려 한다면, thinnet 즉 thin 이더넷 케이블을 사용하려 할 것이다. 이것은 표준 BNC 커넥터의 형태로 된 것이다. BNC (금속제의 누르고 돌려서 잠그는) 커넥터를 가진 thinnet, 즉 thin 이더넷 케이블링, (RG-58 동축 케이블) 은 기술용어로 10Base2라고 불린다.

대부분의 이더넷카드들은 단지 $10-$20만 더하면 `콤보' 버전을 구할수 있다. 이 카드들은 꼬임선과 thinnet 단자를 내장하고있어서, 여러분이 나중에 마음을 바꾼다해도 괜찮다.

RJ-45 (대형 전화 잭)을 가진 꼬임선 케이블 커넥터는 기술용어로 10BaseT라고 불린다. 이것은 또 UTP (Unshielded Twisted Pair)라고도 불리운다.

예전의 설치물에서만 찾아볼수 있는 구형의 thick 이더넷 (10mm 동축케이블)은 10Base5라고 불린다. 몇몇 카드들에서 찾아볼수 있는 15핀 D형 플러그 (AUI 커넥터)는 thick 이se2 대신에 10BaseT가 사용된다.

10Base2는 100Base계열로의 어떠한 업그레이드도 제공하지 않는다. 더넷과 외부 단자에 연결하기 위해 사용하는 것이다.

다른 형태의 이더넷 케이블에 관해서는 케이블, 동축... 를 보기 바란다.

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()를 호출해서 가공하지 않은 것들도 보낼수 있다. 물론 루트권한을 가지고 있어야만 한다.

4. 성능 팁들

만일 여러분이 낮은 이더넷 출력이나 좀더 빠른 ftp 전송속도를 얻고자한다면, 여기에 몇가지 팁들이 있다.

ttcp.c 프로그램은 전송속도를 측정하는데 좋다. 또다른 일반적인 방법은 ftp> get large_file /dev/null를 치고 전송하는 머신의 버퍼 캐쉬를 보는 것이다. 여기서 large_file는 1MB보다 큰 파일을 말한다. ( `get'은 적어도 두번은 해야 한다. 첫번째 시도때 보내는 머신의 버퍼캐쉬에 적재가 되기 때문이다.) 여러분이 측정할 때 디스크 에서 파일로 접근하는 속도에는 관심이 없으므로 버퍼 캐쉬 안에 파일이 있어야 한다. 또한 이때문에 들어오는 데이타를 /dev/null로 보내는 것이다.

4.1 일반적인 개념들

8 비트 카드조차도 아무런 문제없이 패킷을 back-to-back으로 보낼수 있다. 문제는 카드가 더 이상 패킷이 들어올수 있게 충분한 공간을 빠르게 만들수 없기 때문에 받은 패킷들을 컴퓨터가 받아들이지 못하는데 있다. 만일 컴퓨터가 카드의 메모리내에 이미 받은 패킷들을 빨리 비우지 않으면, 카드는 새 패킷을 받아들일 공간이 없게 된다.

이러한 경우에 카드는 새 패킷을 버리거나, 이전에 받은 패킷의 맨 위에서 덮어쓰게 된다. 어느 것이든 재전송을 야기/요구함으로써 부드러운 전송 흐름을 방해하게 되고, 심각한 성능 저하를 나타낼수 있다!

더 많은 메모리를 내장한 카드들은 더 많은 패킷들을 ``저장''할수 있고, 패킷을 버리지 않고 더 많은 양의 back-to-back 패킷 흐름을 제어할수 있다. 다시말하면, 카드가 패킷들을 버리지 않기위해 버퍼내의 패킷들을 밀어내도록 요청하지 않는다는 뜻이다.

대부분의 8비트 카드들은 8kB의 버퍼를 가지며, 대부분의 16비트 카드들은 16kB의 버퍼를 갖는 다. 대부분의 리눅스 드라이버들은 버퍼로 3kB를 남겨두며(두개의 전송 버퍼), 8비트 카드를 위해서 단지 5kB를 남겨놓는다. 이 공간은 단지 풀 사이즈의 이더넷 패킷 세개(1500 bytes) 정도의 공간일 뿐이다.

4.2 ISA 카드들과 ISA 버스 속도

위에서 언급했다시피, 패킷들이 카드에서 충분히 빠르게 없어지면, 수신 패킷 버퍼 메모리가 작아도 패킷을 버리거나 넘쳐버리는 일을 일어나지 않는다. 카드에서 컴퓨터의 메모리로 패킷을 이동하는 비율은 두 개가 만나는 부분 - 이것이 ISA 버스 속도이다 - 의 데이타 속도에 달려 있다. (만일 CPU가 386sx-16이라도, 이것은 적용된다)

권장하는 ISA 버스 클럭은 약 8MHz이지만, 많은 메인보드와 주변기기들은 더 높은 주파수로 동작할수 있다. ISA 버스 클럭 주파수는 보통 메인보드/CPU 클럭 주파수를 나눈 것을 선택하는 것으로, CMOS 설정에서 정할수 있다. 몇몇 ISA 와 PCI/ISA 메인보드는 이 옵션을 가지고 있지 않아서 출하시 기본값으로만 사용할수 있다.

예를 들어, 8비트 WD8003EP 카드가 꼽힌, 40MHz 486에서 TTCP 프로그램으로 측정한 서로다른 ISA 버스 속도가 아래에 있다.

        ISA Bus Speed (MHz)     Rx TTCP (kB/s)
        -------------------     --------------
        6.7                     740
        13.4                    970
        20.0                    1030
        26.7                    1075

여러분은 어떠한 10Mb/s 이더넷 카드로도, TCP/IP를 사용해서 1075kB/s이상의 결과를 얻지 못할것이다. 그러나, 모든 시스템에서 빠른 ISA 버스 속도가 나올거라고는 기대하지 말라. 대부분의 시스템에서는 13MHz이상의 속도에서 제대로 돌아가지 않는다. (또한, 몇몇 PCI 시스템 에서는 ISA 버스 속도를 8MHz로 고정시켜 놓아서, 사용자들이 속도를 올리지 못하게 하고 있다.)

또한 더욱 빠른 전송 속도를 얻으려면, CPU 점유율을 낮추어서 메모리와 I/O 사이클에 좀더 짧은 지속시간을 갖게 하면된다. (ISA 버스상의 하드 디스크와 비디오 카드도 또한 향상된 ISA 버스 속도 덕분에 성능이 올라가는 것을 경험할수 있다.)

8MHz가 넘는 ISA 버스 속도를 시험하기에 앞서서 여러분의 데이타를 백업해 두었는지 확인하고, 속도를 올린 후에는 모든 ISA 주변기기들이 제대로 작동하는지 시험해보기 바란다.

4.3 TCP 수신 윈도우의 설정

다시한번 말하자면, 적은 양의 RAM을 가진 카드와 느린 데이타 전송로를 가진 카드와 컴퓨터 메모리 사이에는 문제가 발생한다. TCP 수신 윈도우 설정의 기본값은 32kB인데, 이것은 여러분의 컴퓨터상의 데이타를 잘 받아졌는지 아닌지 보기위해 멈추는것 없이 32k의 데이타를 덤프할수 있는것같이 동일 서브넷의 빠른 컴퓨터에서도 할수 있다는 뜻이다.

최신 버전의 route 명령으로 이 윈도우의 크기를 실시간으로 설정할수 있다. 보통 라우터나 게이트웨이들 뒤에 있는 컴퓨터들은 문제가 없도록 `버퍼링을 하기' 때문에, 로컬 네트워크에서 이 윈도우의 크기는 작아져야 한다. 사용예는 다음과 같다.

        route add <whatever> ... window <win_size>

여기서 win_size 는 여러분이 사용하길 원하는 윈도우의 크기이다.(바이트로) 8MHz나 그 이하의 속도로 작동하는 ISA 버스상의 8비트 3c503 카드는 4kB의 윈도우 크기에도 잘 돌아간다. 너무 큰 윈도우는 패킷 손실이나 넘침을 야기시키고, 이더넷 전송량의 급격한 감소를 가져온다. 여러분의 cat /proc/net/dev라고 쳐서 운영체제의 상태를 확인해볼수 있다. 이 명령은 손실되거나 넘친 상태가 발생했는지 보여준다.

4.4 NFS 성능 올리기

몇몇 사람들은 NFS 클라이언트에서 8비트 카드를 사용하면서 8kB (Sun 고유의) NFS 패킷 크기를 이용할때, 기대했던 성능보다 더 나쁜것을 발견했다.

이 경우에 가능한 원인은 8비트와 16비트 카드에 장착된 버퍼 크기의 차이이다. 이더넷 패킷의 최대 크기는 1500 바이트 이다. 8kB의 NFS 패킷은 대략 최대크기의 이더넷 패킷 6개와 같다. 8비트와 16비트 카드가 패킷을 수신할 때는 아무런 문제가 없다. 문제는 머신이 카드의 버퍼에 서 패킷을 제시간에 제거하지 못해서, 버퍼가 넘칠때 일어난다. 사실 전송량당 정량 이상의 ISA 버스 사이클을 가진 8비트 카드들은 어느것에도 도움이 되지 않는다. 여러분이 할수 있는것은 8비트 카드를 가진 경우 NFS 전송 패킷 크기를 2kB(또는 1kB)로 설정하거나, 카드가 버퍼를 더욱 빨리 비우게 하기 위해서 ISA 버스 속도를 올리는 것이다. 나는 8MHz에서 구형 WD8003E 카드가 (다른 시스템 부하 없이) 2kB NFS 크기를 유지할수 있었지만, 4kB는 세가지 사실때문에 성능이 낮아짐으로 유지할수 없었다.

다른 말로 하면, 기본 크기 옵션을 1kB 크기로 사용하고, 여러분이 적어도 16비트 ISA 카드를 가지고 있다면, 여러분은 4kB ( 또는 8kB까지) 증가하는 것을 발견할수 있을 것이다.

5. 특정 판매자/제조업체/모델별 정보

다음의 목록에서는 판매자 이름과 제품명을 알파벳 순서로 수많은 카드들을 나열하고 있다. 각 제품 ID 옆에는 `지원', `부분지원', '지원안됨'을 볼수 있을 것이다.

지원된다는 의미는 그 카드의 드라이버가 존재하고, 많은 사람들이 문제없이 사용하고 있으며 매우 안정적이라는 뜻이다.

부분지원이라는 뜻은 드라이버가 존재하지만 다음의 설명가운데 적어도 한가지 이상 해당된다는 뜻이다. (1) 드라이버 그리고/또는 하드웨어에 버그가 있어서 낮은 성능이나, 접속 실패 또는 크래쉬도 발생할수 있다. (2) 드라이버가 새로운 것이거나 카드가 일반적이지 않아서 드라이버에 대한 사용/테스트가 매우 적어 드라이버 제작자가 피드백을 별로 받지 못했다. 명확하게 (2)인 경우가 (1)인 경우보다 낫고, 그 카드/드라이버에 대한 개별적인 설명에서 어느 것에 해당하는지 확인해야 한다. 두가지 경우 모두, 여러분은 make config시에 ``Prompt for development and/or incomplete code/drivers?''부분에서 `Y'라고 답해야 한다.

지원안된다는 것은 현재 그 카드에 사용할수 있는 드라이버가 존재하지 않는다는 뜻이다. 이것은 구하기 힘들거나 평범하지 않은 하드웨어에 대한 관심이 부족하거나, 아니면 판매자들이 드라이버를 만드는데 필요한 하드웨어 문서를 배포하지 않기 때문이다.

`지원'과 `부분지원'의 차이는 다소 주관적이며, 뉴스 그룹 게시판과 메일링 리스트 메세지들을 통한 사용자 피드백을 조사한것에 기반한 것임을 알아두라. (한사람이 각 커널 버전에서 모든 카드들을 가지고 모든 드라이버를 테스트한다는것은 절대로 불가능하다!!!) 그러므로 카드 리스트에 부분지원이라고 되어있는 것이 여러분의 경우에 완벽하게 동작한다거나(정말 좋군), 또는 지원이라고 적힌 카드가 문제가 발생하는 것을 (그리 좋지 못하군) 발견할수도 있다는 것에 주의하길 바란다.

status 다음에는, 리눅스 커널내에 주어진 드라이버 이름이 나열되어 있다. 이것은 또한 /etc/conf.modules 모듈 설정 화일내의 alias eth0 driver_name 행으로 사용되는 드라이버 모듈의 이름이기도 하다.

5.1 3Com

만일 여러분이 가지고 있는 카드가 무엇인지 잘 모르지만, 아마 3Com 카드일꺼라고 생각하고 있다면, 어셈블리 넘버로부터 무엇인지 알아낼수 있을 것이다. 3Com에는 가장 명확하게 알수 있는 `어셈블리 넘버로 3Com 아답터 알아내기(Identifying 3Com Adapters By Assembly Number)' (ref 24500002)라는 문서가 있다. 3Com 문서를 어떻게 얻는지는 다음을 보라. Technical Information from 3Com

또한 3Com은 다양한 제품들에 대한 FTP 사이트를 가지고 있다. ftp.3Com.com에서 여러분이 원하는 것을 찾을수 있을 것이다.

이문서를 WWW 브라우저로 보고 있는 사람들은, 3Com의 WWW 사이트도 볼수 있다.

3c501

Status: 부분지원, 드라이버 이름: 3c501

이 구석기 시대의 8비트 카드는 사용하려면 너무 머리가 아플정도다. 전염병을 피하는것처럼 피하라. 농담으로라도 이 카드를 구입하지 말라. 이것의 성능은 끔찍하고, 많은 경우에 문제가 발생한다.

For those not yet convinced, the 3c501 can only do one thing at a time -- while you are removing one packet from the single-packet buffer it cannot receive another packet, nor can it receive a packet while loading a transmit packet. This was fine for a network between two 8088-based computers where processing each packet and replying took 10's of msecs, but modern networks send back-to-back packets for almost every transaction.

AutoIRQ works, DMA isn't used, the autoprobe only looks at 0x280 and 0x300, and the debug level is set with the third boot-time argument.

Once again, the use of a 3c501 is strongly discouraged! Even more so with a IP multicast kernel, as you will grind to a halt while listening to all multicast packets. See the comments at the top of the source code for more details.

EtherLink II, 3c503, 3c503/16

Status: Supported, Driver Name: 3c503 (+8390)

The 3c503 does not have ``EEPROM setup'', so a diagnostic/setup program isn't needed before running the card with Linux. The shared memory address of the 3c503 is set using jumpers that are shared with the boot PROM address. This is confusing to people familiar with other ISA cards, where you always leave the jumper set to ``disable'' unless you have a boot PROM.

These cards should be about the same speed as the same bus width WD80x3, but turn out to be actually a bit slower. These shared-memory ethercards also have a programmed I/O mode that doesn't use the 8390 facilities (their engineers found too many bugs!) The Linux 3c503 driver can also work with the 3c503 in programmed-I/O mode, but this is slower and less reliable than shared memory mode. Also, programmed-I/O mode is not as well tested when updating the drivers. You shouldn't use the programmed-I/O mode unless you need it for MS-DOS compatibility.

The 3c503's IRQ line is set in software, with no hints from an EEPROM. Unlike the MS-DOS drivers, the Linux driver has capability to autoIRQ: it uses the first available IRQ line in {5,2/9,3,4}, selected each time the card is ifconfig'ed. (Older driver versions selected the IRQ at boot time.) The ioctl() call in `ifconfig' will return EAGAIN if no IRQ line is available at that time.

Some common problems that people have with the 503 are discussed in Problems with....

If you intend on using this driver as a loadable module you should probably see Using the Ethernet Drivers as Modules for module specific information.

Note that some old diskless 386 workstations have an on board 3c503 (made by 3Com and sold under different names, like `Bull') but the vendor ID is not a 3Com ID and so it won't be detected. More details can be found in the Etherboot package, which you will need anyways to boot these diskless boxes.

Etherlink Plus 3c505

Status: Semi-Supported, Driver Name: 3c505

This is a driver that was written by Craig Southeren geoffw@extro.ucc.su.oz.au. These cards also use the i82586 chip. There are not that many of these cards about. It is included in the standard kernel, but it is classed as an alpha driver. See Alpha Drivers for important information on using alpha-test ethernet drivers with Linux.

There is also the file /usr/src/linux/drivers/net/README.3c505 that you should read if you are going to use one of these cards. It contains various options that you can enable/disable.

Etherlink-16 3c507

Status: Semi-Supported, Driver Name: 3c507

This card uses one of the Intel chips, and the development of the driver is closely related to the development of the Intel Ether Express driver. The driver is included in the standard kernel release, but as an alpha driver. See Alpha Drivers for important information on using alpha-test ethernet drivers with Linux.

Etherlink III, 3c509 / 3c509B

Status: Supported, Driver Name: 3c509

This card is fairly inexpensive and has good performance for an ISA non-bus-master design. The drawbacks are that the original 3c509 requires very low interrupt latency. The 3c509B shouldn't suffer from the same problem, due to having a larger buffer. (See below.) These cards use PIO transfers, similar to a ne2000 card, and so a shared memory card such as a wd8013 will be more efficient in comparison.

The original 3c509 has a small packet buffer (4kB total, 2kB Rx, 2kB Tx), causing the driver to occasionally drop a packet if interrupts are masked for too long. To minimize this problem, you can try unmasking interrupts during IDE disk transfers (see man hdparm) and/or increasing your ISA bus speed so IDE transfers finish sooner.

The newer model 3c509B has 8kB on board, and the buffer can be split 4/4, 5/3 or 6/2 for Rx/Tx. This setting is changed with the DOS configuration utility, and is stored on the EEPROM. This should alleviate the above problem with the original 3c509.

3c509B users should use either the supplied DOS utility to disable the plug and play support, and to set the output media to what they require. The linux driver currently does not support the Autodetect media setting, so you have to select 10Base-T or 10Base-2 or AUI. Note that to turn off PnP entirely, you should do a 3C5X9CFG /PNP:DISABLE and then follow that with a hard reset to ensure that it takes effect.

Some people ask about the ``Server or Workstation'' and ``Highest Modem Speed'' settings presented in the DOS configuration utility. Donald writes ``These are only hints to the drivers, and the Linux driver does not use these parameters: it always optimizes for high throughput rather than low latency (`Server'). Low latency was critically important for old, non-windowed, IPX throughput. To reduce the latency the MS-DOS driver for the 3c509 disables interrupts for some operations, blocking serial port interrupts. Thus the need for the `modem speed' setting. The Linux driver avoids the need to disable interrupts for long periods by operating only on whole packets e.g. by not starting to transmit a packet until it is completely transferred to the card.''

Note that the ISA card detection uses a different method than most cards. Basically, you ask the cards to respond by sending data to an ID_PORT (port 0x100 to 0x1ff on intervals of 0x10). This detection method means that a particular card will always get detected first in a multiple ISA 3c509 configuration. The card with the lowest hardware ethernet address will always end up being eth0. This shouldn't matter to anyone, except for those people who want to assign a 6 byte hardware address to a particular interface. If you have multiple 3c509 cards, it is best to append ether=0,0,ethN commands without the I/O port specified (i.e. use I/O=zero) and allow the probe to sort out which card is first. Using a non-zero I/O value will ensure that it does not detect all your cards, so don't do it.

If this really bothers you, have a look at Donald's latest driver, as you may be able to use a 0x3c509 value in the unused mem address fields to order the detection to suit your needs.

3c515

Status: Supported, Driver Name: 3c515

This is 3Com's ISA 100Mbps offering, codenamed ``CorkScrew''. A relatively new driver from Donald for these cards is included in the v2.2 kernels. For the most up to date information, you should probably look on the Vortex page:

Vortex

3c523

Status: Semi-Supported, Driver Name: 3c523

This MCA bus card uses the i82586, and Chris Beauregard has modified the ni52 driver to work with these cards. The driver for it can be found in the v2.2 kernel source tree.

More details can be found on the MCA-Linux page at http://glycerine.cetmm.uni.edu/mca/

3c527

Status: Not Supported.

Yes, another MCA card. No, not too much interest in it. Better chances with the 3c529 if you are stuck with MCA.

3c529

Status: Supported, Driver Name: 3c509

This card actually uses the same chipset as the 3c509. Donald actually put hooks into the 3c509 driver to check for MCA cards after probing for EISA cards, and before probing for ISA cards, long before MCA support was added to the kernel. The required MCA probe code is included in the driver shipped with v2.2 kernels. More details can be found on the MCA-Linux page at:

http://glycerine.cetmm.uni.edu/mca/

3c562

Status: Supported, Driver Name: 3c589 (distributed separately)

This PCMCIA card is the combination of a 3c589B ethernet card with a modem. The modem appears as a standard modem to the end user. The only difficulty is getting the two separate linux drivers to share one interrupt. There are a couple of new registers and some hardware interrupt sharing support. You need to use a v2.0 or newer kernel that has the support for interrupt sharing.

Thanks again to Cameron for getting a sample unit and documentation sent off to David Hinds. Look for support in David's PCMCIA package release.

See PCMCIA Support for more info on PCMCIA chipsets, socket enablers, etc.

3c575

Status: Unknown.

A driver for this PCMCIA card is under development and hopefully will be included in David's PCMCIA package in the future. Best to check the PCMCIA package to get the current status.

3c579

Status: Supported, Driver Name: 3c509

The EISA version of the 509. The current EISA version uses the same 16 bit wide chip rather than a 32 bit interface, so the performance increase isn't stunning. Make sure the card is configured for EISA addressing mode. Read the above 3c509 section for info on the driver.

3c589 / 3c589B

Status: Semi-Supported, Driver Name: 3c589

Many people have been using this PCMCIA card for quite some time now. Note that support for it is not (at present) included in the default kernel source tree. The "B" in the name means the same here as it does for the 3c509 case.

There are drivers available on Donald's ftp site and in David Hinds PCMCIA package. You will also need a supported PCMCIA controller chipset. See PCMCIA Support for more info on PCMCIA drivers, chipsets, socket enablers, etc.

3c590 / 3c595

Status: Supported, Driver Name: 3c59x

These ``Vortex'' cards are for PCI bus machines, with the '590 being 10Mbps and the '595 being 3Com's 100Mbs offering. Also note that you can run the '595 as a '590 (i.e. in a 10Mbps mode). The driver is included in the v2.0 kernel source, but is also continually being updated. If you have problems with the driver in the v2.0 kernel, you can get an updated driver from the following URL:

Vortex

Note that there are two different 3c590 cards out there, early models that had 32kB of on-board memory, and later models that only have 8kB of memory. Chances are you won't be able to buy a new 3c59x for much longer, as it is being replaced with the 3c90x card. If you are buying a used one off somebody, try and get the 32kB version. The 3c595 cards have 64kB, as you can't get away with only 8kB RAM at 100Mbps!

A thanks to Cameron Spitzer and Terry Murphy of 3Com for sending cards and documentation to Donald so he could write the driver.

Donald has set up a mailing list for Vortex driver support. To join the list, just do:

echo subscribe | /bin/mail linux-vortex-request@cesdis.gsfc.nasa.gov

3c592 / 3c597

Status: Supported, Driver Name: 3c59x

These are the EISA versions of the 3c59x series of cards. The 3c592/3c597 (aka Demon) should work with the vortex driver discussed above.

3c900 / 3c905 / 3c905B

Status: Supported, Driver Name: 3c59x

These cards (aka `Boomerang', aka EtherLink III XL) have been released to take over the place of the 3c590/3c595 cards.

The support for the Cyclone `B' revision was only recently added. To use this card with older v2.0 kernels, you must obtain the updated 3c59x.c driver from Donald's site at:

Vortex-Page

If in doubt about anything then check out the above WWW page. Donald has set up a mailing list for Vortex driver support announcements and etc. To join the list, just do:

echo subscribe | /bin/mail linux-vortex-request@cesdis.gsfc.nasa.gov

3c985

Status: Supported, Driver Name: acenic

This driver, by Jes Sorensen, is available in v2.2 kernels It supports several other Gigabit cards in addition to the 3Com model.

5.2 Accton

Accton MPX

Status: Supported, Driver Name: ne (+8390)

Don't let the name fool you. This is still supposed to be a NE2000 compatible card, and should work with the ne2000 driver.

Accton EN1203, EN1207, EtherDuo-PCI

Status: Supported, Driver Name: de4x5, tulip

This is another implementation of the DEC 21040 PCI chip. The EN1207 card has the 21140, and also has a 10Base-2 connector, which has proved troublesome for some people in terms of selecting that media. Using the card with 10Base-T and 100Base-T media have worked for others though. So as with all purchases, you should try and make sure you can return it if it doesn't work for you.

See DEC 21040 for more information on these cards, and the present driver situation.

Accton EN2209 Parallel Port Adaptor (EtherPocket)

Status: Semi-Supported, Driver Name: ?

A driver for these parallel port adapters is available but not yet part of the 2.0 or 2.1 kernel source. You have to get the driver from:

http://www.unix-ag.uni-siegen.de/~nils/accton_linux.html

Accton EN2212 PCMCIA Card

Status: Semi-Supported, Driver Name: ?

David Hinds has been working on a driver for this card, and you are best to check the latest release of his PCMCIA package to see what the present status is.

5.3 Allied Telesyn/Telesis

AT1500

Status: Supported, Driver Name: lance

These are a series of low-cost ethercards using the 79C960 version of the AMD LANCE. These are bus-master cards, and hence one of the faster ISA bus ethercards available.

DMA selection and chip numbering information can be found in AMD LANCE.

More technical information on AMD LANCE based Ethernet cards can be found in Notes on AMD....

AT1700

Status: Supported, Driver Name: at1700

Note that to access this driver during make config you still have to answer `Y' when asked ``Prompt for development and/or incomplete code/drivers?'' at the first. This is simply due to lack of feedback on the driver stability due to it being a relatively rare card. If you have problems with the driver that ships with the kernel then you may be interested in the alternative driver available at: http://www.cc.hit-u.ac.jp/nagoya/at1700/

The Allied Telesis AT1700 series ethercards are based on the Fujitsu MB86965. This chip uses a programmed I/O interface, and a pair of fixed-size transmit buffers. This allows small groups of packets to be sent back-to-back, with a short pause while switching buffers.

A unique feature is the ability to drive 150ohm STP (Shielded Twisted Pair) cable commonly installed for Token Ring, in addition to 10baseT 100ohm UTP (unshielded twisted pair). A fibre optic version of the card (AT1700FT) exists as well.

The Fujitsu chip used on the AT1700 has a design flaw: it can only be fully reset by doing a power cycle of the machine. Pressing the reset button doesn't reset the bus interface. This wouldn't be so bad, except that it can only be reliably detected when it has been freshly reset. The solution/work-around is to power-cycle the machine if the kernel has a problem detecting the AT1700.

AT2450

Status: Supported, Driver Name: pcnet32

This is the PCI version of the AT1500, and it doesn't suffer from the problems that the Boca 79c970 PCI card does. DMA selection and chip numbering information can be found in AMD LANCE.

More technical information on AMD LANCE based Ethernet cards can be found in Notes on AMD....

AT2500

Status: Semi-Supported, Driver Name: rtl8139

This card uses the RealTek 8139 chip - see the section RealTek 8139.

AT2540FX

Status: Semi-Supported, Driver Name: eepro100

This card uses the i82557 chip, and hence may/should work with the eepro100 driver. If you try this please send in a report so this information can be updated.

5.4 AMD / Advanced Micro Devices

Carl Ching of AMD was kind enough to provide a very detailed description of all the relevant AMD ethernet products which helped clear up this section.

AMD LANCE (7990, 79C960/961/961A, PCnet-ISA)

Status: Supported, Driver Name: lance

There really is no AMD ethernet card. You are probably reading this because the only markings you could find on your card said AMD and the above number. The 7990 is the original `LANCE' chip, but most stuff (including this document) refer to all these similar chips as `LANCE' chips. (...incorrectly, I might add.)

These above numbers refer to chips from AMD that are the heart of many ethernet cards. For example, the Allied Telesis AT1500 (see AT1500) and the NE1500/2100 (see NE1500) use these chips.

The 7990/79c90 have long been replaced by newer versions. The 79C960 (a.k.a. PCnet-ISA) essentially contains the 79c90 core, along with all the other hardware support required, which allows a single-chip ethernet solution. The 79c961 (PCnet-ISA+) is a jumperless Plug and Play version of the '960. The final chip in the ISA series is the 79c961A (PCnet-ISA II), which adds full duplex capabilities. All cards with one of these chips should work with the lance.c driver, with the exception of very old cards that used the original 7990 in a shared memory configuration. These old cards can be spotted by the lack of jumpers for a DMA channel.

One common problem people have is the `busmaster arbitration failure' message. This is printed out when the LANCE driver can't get access to the bus after a reasonable amount of time has elapsed (50us). This usually indicates that the motherboard implementation of bus-mastering DMA is broken, or some other device is hogging the bus, or there is a DMA channel conflict. If your BIOS setup has the `GAT option' (for Guaranteed Access Time) then try toggling/altering that setting to see if it helps.

Also note that the driver only looks at the addresses: 0x300, 0x320, 0x340, 0x360 for a valid card, and any address supplied by an ether= boot argument is silently ignored (this will be fixed) so make sure your card is configured for one of the above I/O addresses for now.

The driver will still work fine, even if more than 16MB of memory is installed, since low-memory `bounce-buffers' are used when needed (i.e. any data from above 16MB is copied into a buffer below 16MB before being given to the card to transmit.)

The DMA channel can be set with the low bits of the otherwise-unused dev->mem_start value (a.k.a. PARAM_1). (see PARAM_1) If unset it is probed for by enabling each free DMA channel in turn and checking if initialization succeeds.

The HP-J2405A board is an exception: with this board it's easy to read the EEPROM-set values for the IRQ, and DMA.

See Notes on AMD... for more info on these chips.

AMD 79C965 (PCnet-32)

Status: Supported, Driver Name: pcnet32

This is the PCnet-32 -- a 32 bit bus-master version of the original LANCE chip for VL-bus and local bus systems. chip. While these chips can be operated with the standard lance.c driver, a 32 bit version (pcnet32.c) is also available that does not have to concern itself with any 16MB limitations associated with the ISA bus.

AMD 79C970/970A (PCnet-PCI)

Status: Supported, Driver Name: pcnet32

This is the PCnet-PCI -- similar to the PCnet-32, but designed for PCI bus based systems. Please see the above PCnet-32 information. This means that you need to build a kernel with PCI BIOS support enabled. The '970A adds full duplex support along with some other features to the original '970 design.

Note that the Boca implementation of the 79C970 fails on fast Pentium machines. This is a hardware problem, as it affects DOS users as well. See the Boca section for more details.

AMD 79C971 (PCnet-FAST)

Status: Supported, Driver Name: pcnet32

This is AMD's 100Mbit chip for PCI systems, which also supports full duplex operation. It was introduced in June 1996.

AMD 79C972 (PCnet-FAST+)

Status: Unknown, Driver Name: pcnet32

This should also work just like the '971 but this has yet to be confirmed.

AMD 79C974 (PCnet-SCSI)

Status: Supported, Driver Name: pcnet32

This is the PCnet-SCSI -- which is basically treated like a '970 from an Ethernet point of view. Also see the above information. Don't ask if the SCSI half of the chip is supported -- this is the Ethernet-HowTo, not the SCSI-HowTo.

5.5 Ansel Communications

AC3200 EISA

Status: Semi-Supported, Driver Name: ac3200

This driver is included in the present kernel as an alpha test driver. It is based on the common NS8390 chip used in the ne2000 and wd80x3 cards. Please see Alpha Drivers in this document for important information regarding alpha drivers.

If you use it, let one of us know how things work out, as feedback has been low, even though the driver has been in the kernel since v1.1.25.

If you intend on using this driver as a loadable module you should probably see Using the Ethernet Drivers as Modules for module specific information.

5.6 Apricot

Apricot Xen-II On Board Ethernet

Status: Semi-Supported, Driver Name: apricot

This on board ethernet uses an i82596 bus-master chip. It can only be at I/O address 0x300. By looking at the driver source, it appears that the IRQ is also hardwired to 10.

Earlier versions of the driver had a tendency to think that anything living at 0x300 was an apricot NIC. Since then the hardware address is checked to avoid these false detections.

5.7 Arcnet

Status: Supported, Driver Name: arcnet (arc-rimi, com90xx, com20020)

With the very low cost and better performance of ethernet, chances are that most places will be giving away their Arcnet hardware for free, resulting in a lot of home systems with Arcnet.

An advantage of Arcnet is that all of the cards have identical interfaces, so one driver will work for everyone. It also has built in error handling so that it supposedly never loses a packet. (Great for UDP traffic!)

Avery Pennarun's arcnet driver has been in the default kernel sources since 1.1.80. The arcnet driver uses `arc0' as its name instead of the usual `eth0' for ethernet devices. Bug reports and success stories can be mailed to:

apenwarr@foxnet.net

There are information files contained in the standard kernel for setting jumpers and general hints.

Supposedly the driver also works with the 100Mbs ARCnet cards as well!

5.8 AT&T

Note that AT&T's StarLAN is an orphaned technology, like SynOptics LattisNet, and can't be used in a standard 10Base-T environment, without a hub that `speaks' both.

AT&T T7231 (LanPACER+)

Status: Not Supported.

These StarLAN cards use an interface similar to the i82586 chip. At one point, Matthijs Melchior (matthijs.n.melchior@att.com) was playing with the 3c507 driver, and almost had something useable working. Haven't heard much since that.

5.9 Boca Research

Yes, they make more than just multi-port serial cards. :-)

Boca BEN (ISA, VLB, PCI)

Status: Supported, Driver Name: lance, pcnet32

These cards are based on AMD's PCnet chips. Perspective buyers should be warned that many users have had endless problems with these VLB/PCI cards. Owners of fast Pentium systems have been especially hit. Note that this is not a driver problem, as it hits DOS/Win/NT users as well. Boca's technical support number is (407) 241-8088, and you can also reach them at 75300.2672@compuserve.com. The older ISA cards don't appear to suffer the same problems.

Donald did a comparitive test with a Boca PCI card and a similar Allied Telsyn PCnet/PCI implementation, which showed that the problem lies in Boca's implementation of the PCnet/PCI chip. These test results can be accessed on Don's www server.

Linux at CESDIS

Boca is offering a `warranty repair' for affected owners, which involves adding one of the missing capacitors, but it appears that this fix doesn't work 100 percent for most people, although it helps some.

If you are still thinking of buying one of these cards, then at least try and get a 7 day unconditional return policy, so that if it doesn't work properly in your system, you can return it.

More general information on the AMD chips can be found in AMD LANCE.

More technical information on AMD LANCE based Ethernet cards can be found in Notes on AMD....

5.10 Cabletron

Donald writes: `Yes, another one of these companies that won't release its programming information. They waited for months before actually confirming that all their information was proprietary, deliberately wasting my time. Avoid their cards like the plague if you can. Also note that some people have phoned Cabletron, and have been told things like `a D. Becker is working on a driver for linux' -- making it sound like I work for them. This is NOT the case.'

Apparently Cabletron has changed their policy with respect to programming information (like Xircom) since Donald made the above comment several years ago -- send e-mail to support@ctron.com if you want to verify this or ask for programming information. However, at this point in time, there is little demand for modified/updated drivers for the older E20xx and E21xx cards.

E10, E10-x, E20, E20-x

Status: Semi-Supported, Driver Name: ne (+8390)

These are NEx000 almost-clones that are reported to work with the standard NEx000 drivers, thanks to a ctron-specific check during the probe. If there are any problems, they are unlikely to be fixed, as the programming information is unavailable.

E2100

Status: Semi-Supported, Driver Name: e2100 (+8390)

Again, there is not much one can do when the programming information is proprietary. The E2100 is a poor design. Whenever it maps its shared memory in during a packet transfer, it maps it into the whole 128K region! That means you can't safely use another interrupt-driven shared memory device in that region, including another E2100. It will work most of the time, but every once in a while it will bite you. (Yes, this problem can be avoided by turning off interrupts while transferring packets, but that will almost certainly lose clock ticks.) Also, if you mis-program the board, or halt the machine at just the wrong moment, even the reset button won't bring it back. You will have to turn it off and leave it off for about 30 seconds.

Media selection is automatic, but you can override this with the low bits of the dev->mem_end parameter. See PARAM_2. Module users can specify an xcvr=N value as an option in the /etc/conf.modules file.

Also, don't confuse the E2100 for a NE2100 clone. The E2100 is a shared memory NatSemi DP8390 design, roughly similar to a brain-damaged WD8013, whereas the NE2100 (and NE1500) use a bus-mastering AMD LANCE design.

There is an E2100 driver included in the standard kernel. However, seeing as programming info isn't available, don't expect bug-fixes. Don't use one unless you are already stuck with the card.

If you intend on using this driver as a loadable module you should probably see Using the Ethernet Drivers as Modules for module specific information.

E22**

Status: Semi-Supported, Driver Name: lance

According to information in a Cabletron Tech Bulletin, these cards use the standard AMD PC-Net chipset (see AMD PC-Net) and should work with the generic lance driver.

5.11 Cogent

Here is where and how to reach them:

        Cogent Data Technologies, Inc.
        175 West Street, P.O. Box 926
        Friday Harbour, WA 98250, USA.

        Cogent Sales
        15375 S.E. 30th Place, Suite 310
        Bellevue, WA 98007, USA.

        Technical Support:
        Phone (360) 378-2929 between 8am and 5pm PST
        Fax (360) 378-2882
        Compuserve GO COGENT
        Bulletin Board Service (360) 378-5405
        Internet: support@cogentdata.com

EM100-ISA/EISA

Status: Semi-Supported, Driver Name: smc9194

These cards use the SMC 91c100 chip and may work with the SMC 91c92 driver, but this has yet to be verified.

Cogent eMASTER+, EM100-PCI, EM400, EM960, EM964

Status: Supported, Driver Name: de4x5, tulip

These are yet another DEC 21040 implementation that should hopefully work fine with the standard 21040 driver.

The EM400 and the EM964 are four port cards using a DEC 21050 bridge and 4 21040 chips.

See DEC 21040 for more information on these cards, and the present driver situation.

5.12 Compaq

Compaq aren't really in the business of making ethernet cards, but a lot of their systems have embedded ethernet controllers on the motherboard.

Compaq Deskpro / Compaq XL (Embedded AMD Chip)

Status: Supported, Driver Name: pcnet32

Machines such as the XL series have an AMD 79c97x PCI chip on the mainboard that can be used with the standard LANCE driver. But before you can use it, you have to do some trickery to get the PCI BIOS to a place where Linux can see it. Frank Maas was kind enough to provide the details:

`` The problem with this Compaq machine however is that the PCI directory is loaded in high memory, at a spot where the Linux kernel can't (won't) reach. Result: the card is never detected nor is it usable (sideline: the mouse won't work either) The workaround (as described thoroughly in http://www-c724.uibk.ac.at/XL/) is to load MS-DOS, launch a little driver Compaq wrote and then load the Linux kernel using LOADLIN. Ok, I'll give you time to say `yuck, yuck', but for now this is the only working solution I know of. The little driver simply moves the PCI directory to a place where it is normally stored (and where Linux can find it).''

More general information on the AMD chips can be found in AMD LANCE.

Compaq Nettelligent/NetFlex (Embedded ThunderLAN Chip)

Status: Supported, Driver Name: tlan

These systems use a Texas Instruments ThunderLAN chip Information on the ThunderLAN driver can be found in ThunderLAN.

5.13 Danpex

Danpex EN9400

Status: Supported, Driver Name: de4x5, tulip

Yet another card based on the DEC 21040 chip, reported to work fine, and at a relatively cheap price.

See DEC 21040 for more information on these cards, and the present driver situation.

5.14 D-Link

DE-100, DE-200, DE-220-T, DE-250

Status: Supported, Driver Name: ne (+8390)

Some of the early D-Link cards didn't have the 0x57 PROM signature, but the ne2000 driver knows about them. For the software configurable cards, you can get the config program from www.dlink.com. The DE2** cards were the most widely reported as having the spurious transfer address mismatch errors with early versions of linux. Note that there are also cards from Digital (DEC) that are also named DE100 and DE200, but the similarity stops there.

DE-520

Status: Supported, Driver Name: pcnet32

This is a PCI card using the PCI version of AMD's LANCE chip. DMA selection and chip numbering information can be found in AMD LANCE.

More technical information on AMD LANCE based Ethernet cards can be found in Notes on AMD....

DE-528

Status: Supported, Driver Name: ne, ne2k-pci (+8390)

Apparently D-Link have also started making PCI NE2000 clones.

DE-530

Status: Supported, Driver Name: de4x5, tulip

This is a generic DEC 21040 PCI chip implementation, and is reported to work with the generic 21040 tulip driver.

See DEC 21040 for more information on these cards, and the present driver situation.

DE-600

Status: Supported, Driver Name: de600

Laptop users and other folk who might want a quick way to put their computer onto the ethernet may want to use this. The driver is included with the default kernel source tree. Bjorn Ekwall bj0rn@blox.se wrote the driver. Expect about 180kb/s transfer speed from this via the parallel port. You should read the README.DLINK file in the kernel source tree.

Note that the device name that you pass to ifconfig is now eth0 and not the previously used dl0.

If your parallel port is not at the standard 0x378 then you will have to recompile. Bjorn writes: ``Since the DE-620 driver tries to sqeeze the last microsecond from the loops, I made the irq and port address constants instead of variables. This makes for a usable speed, but it also means that you can't change these assignements from e.g. lilo; you _have_ to recompile...'' Also note that some laptops implement the on-board parallel port at 0x3bc which is where the parallel ports on monochrome cards were/are.

DE-620

Status: Supported, Driver Name: de620

Same as the DE-600, only with two output formats. Bjorn has written a driver for this model, for kernel versions 1.1 and above. See the above information on the DE-600.

DE-650

Status: Semi-Supported, Driver Name: de650 (?)

Some people have been using this PCMCIA card for some time now with their notebooks. It is a basic 8390 design, much like a NE2000. The LinkSys PCMCIA card and the IC-Card Ethernet are supposedly DE-650 clones as well. Note that at present, this driver is not part of the standard kernel, and so you will have to do some patching.

See PCMCIA Support in this document, and if you can, have a look at:

Don's PCMCIA Stuff

5.15 DFI

DFINET-300 and DFINET-400

Status: Supported, Driver Name: ne (+8390)

These cards are now detected (as of 0.99pl15) thanks to Eberhard Moenkeberg emoenke@gwdg.de who noted that they use `DFI' in the first 3 bytes of the prom, instead of using 0x57 in bytes 14 and 15, which is what all the NE1000 and NE2000 cards use. (The 300 is an 8 bit pseudo NE1000 clone, and the 400 is a pseudo NE2000 clone.)

5.16 Digital / DEC

DEPCA, DE100/1, DE200/1/2, DE210, DE422

Status: Supported, Driver Name: depca

There is documentation included in the source file `depca.c', which includes info on how to use more than one of these cards in a machine. Note that the DE422 is an EISA card. These cards are all based on the AMD LANCE chip. See AMD LANCE for more info. A maximum of two of the ISA cards can be used, because they can only be set for 0x300 and 0x200 base I/O address. If you are intending to do this, please read the notes in the driver source file depca.c in the standard kernel source tree.

This driver will also work on Alpha CPU based machines, and there are various ioctl()s that the user can play with.

Digital EtherWorks 3 (DE203, DE204, DE205)

Status: Supported, Driver Name: ewrk3

These cards use a proprietary chip from DEC, as opposed to the LANCE chip used in the earlier cards like the DE200. These cards support both shared memory or programmed I/O, although you take about a 50%performance hit if you use PIO mode. The shared memory size can be set to 2kB, 32kB or 64kB, but only 2 and 32 have been tested with this driver. David says that the performance is virtually identical between the 2kB and 32kB mode. There is more information (including using the driver as a loadable module) at the top of the driver file ewrk3.c and also in README.ewrk3. Both of these files come with the standard kernel distribution. This driver has Alpha CPU support like depca.c does.

The standard driver has a number of interesting ioctl() calls that can be used to get or clear packet statistics, read/write the EEPROM, change the hardware address, and the like. Hackers can see the source code for more info on that one.

David has also written a configuration utility for this card (along the lines of the DOS program NICSETUP.EXE) along with other tools. These can be found on most Linux FTP sites in the directory /pub/Linux/system/Network/management -- look for the file ewrk3tools-X.XX.tar.gz.

DE425 EISA, DE434, DE435, DE500

Status: Supported, Driver Name: de4x5, tulip

These cards are based on the 21040 chip mentioned below. The DE500 uses the 21140 chip to provide 10/100Mbs ethernet connections. Have a read of the 21040 section below for extra info. There are also some compile-time options available for non-DEC cards using this driver. Have a look at README.de4x5 for details.

All the Digital cards will autoprobe for their media (except, temporarily, the DE500 due to a patent issue).

This driver is also Alpha CPU ready and supports being loaded as a module. Users can access the driver internals through ioctl() calls - see the 'ewrk3' tools and the de4x5.c sources for information about how to do this.

DEC 21040, 21041, 2114x, Tulip

Status: Supported, Driver Name: de4x5, tulip

The DEC 21040 is a bus-mastering single chip ethernet solution from Digital, similar to AMD's PCnet chip. The 21040 is specifically designed for the PCI bus architecture. SMC's new EtherPower PCI card uses this chip.

You have a choice of two drivers for cards based on this chip. There is the DE425 driver discussed above, and the generic 21040 `tulip' driver.

Warning: Even though your card may be based upon this chip, the drivers may not work for you. David C. Davies writes:

``There are no guarantees that either `tulip.c' OR `de4x5.c' will run any DC2114x based card other than those they've been written to support. WHY?? You ask. Because there is a register, the General Purpose Register (CSR12) that (1) in the DC21140A is programmable by each vendor and they all do it differently (2) in the DC21142/3 this is now an SIA control register (a la DC21041). The only small ray of hope is that we can decode the SROM to help set up the driver. However, this is not a guaranteed solution since some vendors (e.g. SMC 9332 card) don't follow the Digital Semiconductor recommended SROM programming format."

In non-technical terms, this means that if you aren't sure that an unknown card with a DC2114x chip will work with the linux driver(s), then make sure you can return the card to the place of purchase before you pay for it.

The updated 21041 chip is also found in place of the 21040 on most of the later SMC EtherPower cards. The 21140 is for supporting 100Base-? and works with the Linux drivers for the 21040 chip. To use David's de4x5 driver with non-DEC cards, have a look at README.de4x5 for details.

Donald has used SMC EtherPower-10/100 cards to develop the `tulip' driver. Note that the driver that is in the standard kernel tree at the moment is not the most up to date version. If you are having trouble with this driver, you should get the newest version from Donald's ftp/WWW site.

Tulip Driver

The above URL also contains a (non-exhaustive) list of various cards/vendors that use the 21040 chip.

Also note that the tulip driver is still considered an alpha driver (see Alpha Drivers) at the moment, and should be treated as such. To use it, you will have to edit arch/i386/config.in and uncomment the line for CONFIG_DEC_ELCP support.

Donald has even set up a mailing list for tulip driver support announcements, etc. To join it just type:

echo subscribe | /bin/mail linux-tulip-request@cesdis.gsfc.nasa.gov

5.17 Farallon

Farallon sells EtherWave adaptors and transceivers. This device allows multiple 10baseT devices to be daisy-chained.

Farallon Etherwave

Status: Supported, Driver Name: 3c509

This is reported to be a 3c509 clone that includes the EtherWave transceiver. People have used these successfully with Linux and the present 3c509 driver. They are too expensive for general use, but are a great option for special cases. Hublet prices start at $125, and Etherwave adds $75-$100 to the price of the board -- worth it if you have pulled one wire too few, but not if you are two network drops short.

5.18 Fujitsu

Unlike many network chip manufacturers, Fujitsu have also made and sold some network cards based upon their chip.

Fujitsu FMV-181/182/183/184

Status: Supported, Driver Name: fmv18x

According to the driver, these cards are a straight forward Fujitsu MB86965 implementation, which would make them very similar to the Allied Telesis AT1700 cards.

5.19 Hewlett Packard

The 272** cards use programmed I/O, similar to the NE*000 boards, but the data transfer port can be `turned off' when you aren't accessing it, avoiding problems with autoprobing drivers.

Thanks to Glenn Talbott for helping clean up the confusion in this section regarding the version numbers of the HP hardware.

27245A

Status: Supported, Driver Name: hp (+8390)

8 Bit 8390 based 10BaseT, not recommended for all the 8 bit reasons. It was re-designed a couple years ago to be highly integrated which caused some changes in initialization timing which only affected testing programs, not LAN drivers. (The new card is not `ready' as soon after switching into and out of loopback mode.)

If you intend on using this driver as a loadable module you should probably see Using the Ethernet Drivers as Modules for module specific information.

HP EtherTwist, PC Lan+ (27247, 27252A)

Status: Supported, Driver Name: hp+ (+8390)

The HP PC Lan+ is different to the standard HP PC Lan card. This driver was added to the list of drivers in the standard kernel during the v1.1.x development cycle. It can be operated in either a PIO mode like a ne2000, or a shared memory mode like a wd8013.

The 47B is a 16 Bit 8390 based 10BaseT w/AUI, and the 52A is a 16 Bit 8390 based ThinLAN w/AUI. These cards have 32K onboard RAM for Tx/Rx packet buffering instead of the usual 16KB, and they both offer LAN connector autosense.

If you intend on using this driver as a loadable module you should probably see Using the Ethernet Drivers as Modules for module specific information.

HP-J2405A

Status: Supported, Driver Name: lance

These are lower priced, and slightly faster than the 27247/27252A, but are missing some features, such as AUI, ThinLAN connectivity, and boot PROM socket. This is a fairly generic LANCE design, but a minor design decision makes it incompatible with a generic `NE2100' driver. Special support for it (including reading the DMA channel from the board) is included thanks to information provided by HP's Glenn Talbott.

More technical information on LANCE based cards can be found in Notes on AMD...

HP-Vectra On Board Ethernet

Status: Supported, Driver Name: lance

The HP-Vectra has an AMD PCnet chip on the motherboard. DMA selection and chip numbering information can be found in AMD LANCE.

More technical information on LANCE based cards can be found in Notes on AMD...

HP 10/100 VG Any Lan Cards (27248B, J2573, J2577, J2585, J970, J973)

Status: Supported, Driver Name: hp100

This driver also supports some of the Compex VG products. Since the driver supports ISA, EISA and PCI cards, it is found under ISA cards when running make config on a kernel source.

HP NetServer 10/100TX PCI (D5013A)

Status: Supported, Driver Name: eepro100

Apparently these are just a rebadged Intel EtherExpress Pro 10/100B card. See the Intel section for more information.

5.20 IBM / International Business Machines

IBM Thinkpad 300

Status: Supported, Driver Name: znet

This is compatible with the Intel based Zenith Z-note. See Z-note for more info.

Supposedly this site has a comprehensive database of useful stuff for newer versions of the Thinkpad. I haven't checked it out myself yet.

Thinkpad-info

For those without a WWW browser handy, try peipa.essex.ac.uk:/pub/tp750/

IBM Credit Card Adaptor for Ethernet

Status: Semi-Supported, Driver Name: ? (distributed separately)

People have been using this PCMCIA card with Linux as well. Similar points apply, those being that you need a supported PCMCIA chipset on your notebook, and that you will have to patch the PCMCIA support into the standard kernel.

See PCMCIA Support in this document, and if you can, have a look at:

Don's PCMCIA Stuff

IBM Token Ring

Status: Semi-Supported, Driver Name: ibmtr

To support token ring requires more than only writing a device driver, it also requires writing the source routing routines for token ring. It is the source routing that would be the most time comsuming to write.

Peter De Schrijver has been spending some time on Token Ring lately. and has worked with IBM ISA and MCA token ring cards.

The present token ring code has been included into the first of the 1.3.x series kernels.

Peter says that it was originally tested on an MCA 16/4 Megabit Token Ring board, but it should work with other Tropic based boards.

5.21 ICL Ethernet Cards

ICL EtherTeam 16i/32

Status: Supported, Driver Name: eth16i

Mika Kuoppala (miku@pupu.elt.icl.fi) wrote this driver, and it was included into early 1.3.4x kernels. It uses the Fujitsu MB86965 chip that is also used on the at1700 cards.

5.22 Intel Ethernet Cards

Note that the naming of the various Intel cards is ambiguous and confusing at best. If in doubt, then check the i8xxxx number on the main chip on the card or for PCI cards, use the PCI information in the /proc directory and then compare that to the numbers listed here.

Ether Express

Status: Supported, Driver Name: eexpress

This card uses the intel i82586. Earlier versions of this driver (in v1.2 kernels) were classed as alpha-test, as it didn't work well for most people. The driver in the v2.0 kernel seems to work much better for those who have tried it, although the driver source still lists it as experimental and more problematic on faster machines.

The comments at the top of the driver source list some of the problems (and fixes!) associated with these cards. The slowdown hack of replacing all the outb with outb_p in the driver has been reported to avoid lockups for at least one user.

Ether Express PRO/10

Status: Supported, Driver Name: eepro

Bao Chau Ha has written a driver for these cards that has been included into early 1.3.x kernels. It may also work with some of the Compaq built-in ethernet systems that are based on the i82595 chip.

Linux Ethernet-Howto

by Paul Gortmaker

맹지찬, jcmaeng@kldp.org

1. 소 개

1.1 이 문서의 새 버전들

1.2 Ethernet-Howto의 사용

1.3 도와주세요 - 잘안되요!

2. 리눅스에서 쓰려면 무슨 카드를 사야하나?

2.1 어떤 드라이버가 안정된거지?

2.2 8 bit 대 16 bit 카드

2.3 32 Bit (VLB/EISA/PCI) 이더넷 카드들

2.4 사용할수 있는 100Mbs 카드와 드라이버들

2.5 100VG 대 100BaseT

2.6 여러분의 카드가 지원하는 케이블의 종류

3. Frequently Asked Questions

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

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

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

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

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

3.6 3Com 카드들의 문제

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

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

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

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

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

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

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

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

기가바이트 이더넷 지원

FDDI 지원

Full Duplex 지원

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

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

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

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

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

SIOCSIFxxx: No such device

SIOCSFFLAGS: Try again

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

엄청난 양의 RX 와 TX 에러들

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

리눅스와 ``trailers''

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

4. 성능 팁들

4.1 일반적인 개념들

4.2 ISA 카드들과 ISA 버스 속도

4.3 TCP 수신 윈도우의 설정

4.4 NFS 성능 올리기

5. 특정 판매자/제조업체/모델별 정보

5.1 3Com

3c501

EtherLink II, 3c503, 3c503/16

Etherlink Plus 3c505

Etherlink-16 3c507

Etherlink III, 3c509 / 3c509B

3c515

3c523

3c527

3c529

3c562

3c575

3c579

3c589 / 3c589B

3c590 / 3c595

3c592 / 3c597

3c900 / 3c905 / 3c905B

3c985

5.2 Accton

Accton MPX

Accton EN1203, EN1207, EtherDuo-PCI

Accton EN2209 Parallel Port Adaptor (EtherPocket)

Accton EN2212 PCMCIA Card

5.3 Allied Telesyn/Telesis

AT1500

AT1700

AT2450

AT2500

AT2540FX

5.4 AMD / Advanced Micro Devices

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

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

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

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

E10, E10-x, E20, E20-x