1876 lines
46 KiB
HTML
1876 lines
46 KiB
HTML
<HTML
|
||
><HEAD
|
||
><TITLE
|
||
>Which driver should I use?</TITLE
|
||
><META
|
||
NAME="GENERATOR"
|
||
CONTENT="Modular DocBook HTML Stylesheet Version 1.63
|
||
"><LINK
|
||
REL="HOME"
|
||
TITLE="Token-Ring mini-HOWTO"
|
||
HREF="index.html"><LINK
|
||
REL="PREVIOUS"
|
||
TITLE="Hardware requirements"
|
||
HREF="hardware.html"><LINK
|
||
REL="NEXT"
|
||
TITLE="Known problems"
|
||
HREF="problemns.html"></HEAD
|
||
><BODY
|
||
CLASS="SECT1"
|
||
BGCOLOR="#FFFFFF"
|
||
TEXT="#000000"
|
||
LINK="#0000FF"
|
||
VLINK="#840084"
|
||
ALINK="#0000FF"
|
||
><DIV
|
||
CLASS="NAVHEADER"
|
||
><TABLE
|
||
WIDTH="100%"
|
||
BORDER="0"
|
||
CELLPADDING="0"
|
||
CELLSPACING="0"
|
||
><TR
|
||
><TH
|
||
COLSPAN="3"
|
||
ALIGN="center"
|
||
>Token-Ring mini-HOWTO</TH
|
||
></TR
|
||
><TR
|
||
><TD
|
||
WIDTH="10%"
|
||
ALIGN="left"
|
||
VALIGN="bottom"
|
||
><A
|
||
HREF="hardware.html"
|
||
>Prev</A
|
||
></TD
|
||
><TD
|
||
WIDTH="80%"
|
||
ALIGN="center"
|
||
VALIGN="bottom"
|
||
></TD
|
||
><TD
|
||
WIDTH="10%"
|
||
ALIGN="right"
|
||
VALIGN="bottom"
|
||
><A
|
||
HREF="problemns.html"
|
||
>Next</A
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
><HR
|
||
ALIGN="LEFT"
|
||
WIDTH="100%"></DIV
|
||
><DIV
|
||
CLASS="SECT1"
|
||
><H1
|
||
CLASS="SECT1"
|
||
><A
|
||
NAME="DRIVERS"
|
||
>3. Which driver should I use?</A
|
||
></H1
|
||
><P
|
||
> The realm of Token Ring drivers on Linux has expanded quite a bit in
|
||
last couple of years. It's not just ibmtr anymore! So as a result this
|
||
map will tell you given a card which driver you should try and the
|
||
recommended minimum kernel version (if any).
|
||
</P
|
||
><P
|
||
> 3COM
|
||
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>3C389 PCMCIA -- ibmtr_cs</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>3C619, 3C619B or 3C619C Token Link -- ibmtr</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>3C319 Velocity ISA -- try ibmtr</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>3C359 Velocity XL - PCI -- driver available from
|
||
<A
|
||
HREF="http://www.linuxtr.net"
|
||
TARGET="_top"
|
||
>http://www.linuxtr.net</A
|
||
></P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>3C339 Velocity PCI -- tms380tr </P
|
||
></LI
|
||
></UL
|
||
>
|
||
</P
|
||
><P
|
||
> IBM
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>PCI Token Ring Adaptor -- olympic </P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>PCI Wake on Lan Token Ring Adaptor -- olympic </P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>16/4 Token Ring PCI Adaptor 2, Wake On Lan, and Wake on Lan Special -- olympic</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>High Speed 100/16/4 Token Ring -- olympic</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Turbo 16/4 ISA adapter -- ibmtr</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Token Ring Auto 16/4 ISA adapter -- ibmtr</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Token Ring Auto 16/4 adapter /A -- ibmtr</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Token Ring 16/4 adapter /A -- ibmtr</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Token Ring adapter /A -- ibmtr</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Token Ring adapter II (4 Megabit only) -- ibmtr</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>16/4 ISA Token Ring card (16bit) -- ibmtr</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>16/4 ISA Token Ring card (8bit) -- ibmtr</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>All LANStreamer -- lanstreamer </P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>PCMCIA - Turbo 16/4 -- ibmtr_cs</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>PCMCIA - 16/4 -- ibmtr_cs</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Cardbus - 16/4 - olympic, kernel v.2.4.3 or greater</P
|
||
></LI
|
||
></UL
|
||
>
|
||
</P
|
||
><P
|
||
> Olicom
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>RapidFire 3139, 3140, 3141, and 3540</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>OC 3136</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>OC 3137</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>OC 3118</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>OC 3129</P
|
||
></LI
|
||
></UL
|
||
>
|
||
For these Olicom cards, see their website
|
||
<A
|
||
HREF="http://www.olicom.com"
|
||
TARGET="_top"
|
||
>http://www.olicom.com</A
|
||
> for drivers. You will need a
|
||
2.2.x series kernel.
|
||
</P
|
||
><P
|
||
> Madge
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>51-02 Smart 16/4 PCI</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>20-03 16/4 Cardbus Adapter Mk2</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>51-04 Smart 16/4 PCI Ringnode Mk3</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>51-09 Smart 16/4 Fiber PCI Ringnode</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>51-07 Smart 100/16/4 PCI-HS Ringnode</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>51-05 Smart 100/16/4 PCI Ringnode</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>20-01 Smart 16/4 PCMCIA</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>60-07 Presto PCI 2000</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>60-06 Presto PCI Plus</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>60-05 Presto PCI</P
|
||
></LI
|
||
></UL
|
||
>
|
||
For these Madge cards you'll want to visit their site
|
||
<A
|
||
HREF="http://www.madge.com"
|
||
TARGET="_top"
|
||
>http://www.madge.com</A
|
||
>
|
||
for drivers and get the 2.31 Madge drivers.
|
||
You will need either a 2.0.36 or 2.2.5 as a minimum.
|
||
</P
|
||
><P
|
||
> 2.41 drivers:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>51-05 Smart Mk4 PCI Adapter</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>53-05 Smart Mk4 PCI Adapter (low profile)</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>31-40 Rapidfire 3140V2 16/4 PCI Adapter</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>20-03 Smart 16/4 Cardbus Mk2</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>51-04 Smart 16/4 PCI Ringnode Mk3</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>60-07 Presto PCI 2000</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>60-06 Presto PCI Plus</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>60-05 Presto PCI</P
|
||
></LI
|
||
></UL
|
||
>
|
||
According to the Madge README file the 2.41 driver has been tested on
|
||
uniprocessor and SMP kernel versions: 2.0.36, 2.2.5-15 ,2.2.10,
|
||
2.2.12-20, 2.4.2-2.
|
||
</P
|
||
><P
|
||
> Other Madge cards are reportedly based on the Texas Instruments tms380
|
||
chipset and thus as of the 2.3.26 kernel you can try the tms380tr driver.
|
||
</P
|
||
><P
|
||
> SysKonnect
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>TR4/16(+) SK-4190 ISA</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>TR4/16(+) SK-4590 PCI</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>TR4/16(+) SK-4591 PCI</P
|
||
></LI
|
||
></UL
|
||
>
|
||
In the 2.2.x series of kernels try sktr. In the 2.3.x and greater
|
||
series try the tms380tr driver.
|
||
</P
|
||
><P
|
||
> SMC
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>Tokencard Elite (8115T)</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>Tokencard Elite/A MCA (8115T/A)</P
|
||
></LI
|
||
></UL
|
||
>
|
||
Driver is included as part of the 2.3.38+ kernel.
|
||
</P
|
||
><P
|
||
> Intel
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
>TokenExpress PRO</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
>TokenExpress 16/4</P
|
||
></LI
|
||
></UL
|
||
>
|
||
Support for these cards is currently under development.
|
||
Check <A
|
||
HREF="http://www.linuxtr.net"
|
||
TARGET="_top"
|
||
>http://www.linuxtr.net</A
|
||
> for status.
|
||
</P
|
||
><DIV
|
||
CLASS="SECT2"
|
||
><H2
|
||
CLASS="SECT2"
|
||
><A
|
||
NAME="DRIVERSSPECIFICS"
|
||
>3.1. Drivers/Adapter Specifics</A
|
||
></H2
|
||
><P
|
||
> Here we'll describe the different options and configurations available
|
||
for each of the available drivers.
|
||
</P
|
||
><DIV
|
||
CLASS="SECT3"
|
||
><H3
|
||
CLASS="SECT3"
|
||
><A
|
||
NAME="KP"
|
||
>3.1.1. Kernel Module Aliases and Parameters</A
|
||
></H3
|
||
><P
|
||
> Most drivers accept arguments in the form of module paramters (with the
|
||
exception of the special case of PCMCIA, which is fully described below).
|
||
</P
|
||
><P
|
||
> Kernel modules are specified in the file /etc/conf.modules or /etc/modules.conf
|
||
depending upon which version of modutils you've got.
|
||
</P
|
||
><P
|
||
> You can directly modify this file or use the tools builtin to your specific
|
||
distribution. These distribution specific tools are beyond the scope of this
|
||
document, but you can always directly modify the modules.conf file by hand
|
||
to get things up and running and then figure out how your distribution
|
||
handles these files. For example, Debian has several files in the /etc/modutils
|
||
directory and from these builds the modules.conf file.
|
||
</P
|
||
><P
|
||
> Kernel modules aliases are utilized to associate a particular name with a
|
||
kernel module.
|
||
</P
|
||
><P
|
||
> For token ring, this is used to assign drivers for each of the token ring
|
||
interfaces so that the system scripts know which driver to insert when
|
||
you bring an interface up.
|
||
</P
|
||
><P
|
||
> The format of the alias lines are:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> alias <EM
|
||
>module_name</EM
|
||
> interface
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
Usually, the only line you'll need for the token ring networking would be
|
||
something like:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
>alias olympic tr0</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
This binds the olympic driver to the tr0 interface so when you type
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
>ifconfig tr0 up</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
if the tr0 interface is not already loaded, the system will insert the
|
||
olympic driver, which in turn will find the network card and create
|
||
the tr0 network device.
|
||
</P
|
||
><P
|
||
> Kernel modules parameters are specified in the following format:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> options <EM
|
||
>module_name</EM
|
||
> <EM
|
||
>parameter_1</EM
|
||
>=XXX [<EM
|
||
>parameter2</EM
|
||
>=YYY ...]
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
Where the modules_name is the name of the driver, i.e. olympic, ibmtr, 3c359 and the
|
||
` parameters are those available for each driver. See either the following sections for
|
||
driver specifics or check out the drivers source code.
|
||
</P
|
||
><P
|
||
> For example, if you wanted to set the Olympic driver to 16 mbps operation and with
|
||
a default buffer size of 8192 bytes, you would use the following line:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> options olympic ringspeed=16 pkt_buf_sz=8192
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT3"
|
||
><H3
|
||
CLASS="SECT3"
|
||
><A
|
||
NAME="IBMTR"
|
||
>3.1.2. IBMTR Driver</A
|
||
></H3
|
||
><P
|
||
> IBM Tropic Chipset Based Token Ring Adapters
|
||
</P
|
||
><P
|
||
> This is the original token ring driver in the kernel and supports almost all
|
||
adapters that use the IBM Tropic chipset, including the IBM ISA, ISA/Pnp, and
|
||
a multitude of adapters from other manufacturers.
|
||
</P
|
||
><P
|
||
> The IBM Turbo 16/4 ISA/PnP adapter will, in fact, work fine with the ibmtr driver.
|
||
In older drivers you had to run the card in Auto 16/4 compatability mode.
|
||
The simplest way to set this is to use the LANAID disks
|
||
sent with the card and run the command:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
>LANAIDC /FAST=AUTO16</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
You should then use LANAIDC or LANAID
|
||
to configure the card according to documentation.
|
||
The latest drivers for the Turbo Adapters will recognize these adapters
|
||
and configure them straight out of the box. You may have to either turn
|
||
off isapnp support in the kernel or modify your isapnp.conf file to
|
||
enable the adapter.
|
||
</P
|
||
><P
|
||
> Options:
|
||
</P
|
||
><P
|
||
> Perusal of the ibmtr source code may leave you to believe that the adapter can
|
||
take three parameters, however, in reality the driver doesn't take any. These
|
||
parameters are a hang over from the early stages of the driver and are only
|
||
intended to be used to force the driver to only test restricted <20>ddresses when
|
||
looking for adapters. The information on these options are included here for
|
||
completeness only.
|
||
</P
|
||
><P
|
||
> <P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>io</EM
|
||
>: Specify the I/O ports that the driver will check
|
||
for the presence of any cards. All Tropic based ISA adapters, or adapters
|
||
emulating the ISA cards will be found on either port 0xA20 or 0xA24. If
|
||
you know that your adapter is configured for 0xA24 and/or that probing
|
||
on port 0xA20 will cause problems with your machine, use io to force the
|
||
driver to check a specific port only.
|
||
</P
|
||
><P
|
||
> The Turbo adapters (including the confusingly named latest Auto 16/4
|
||
cards) can have their io regions located anywhere permitted by the PnP
|
||
specification. This location is found using the new turbo detection code
|
||
and no parameters are required.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>irq</EM
|
||
> & <EM
|
||
>mem</EM
|
||
>: The two options were used
|
||
to tell the driver exactly which irq to use and where the shared ram for the
|
||
adapter could be found. These two options are now totally redundant in the driver
|
||
as the interrupt line and the location of the shared ram is obtained directly by
|
||
interrogating the adapter.
|
||
</P
|
||
></LI
|
||
></UL
|
||
>
|
||
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT3"
|
||
><H3
|
||
CLASS="SECT3"
|
||
><A
|
||
NAME="OLYMPIC"
|
||
>3.1.3. Olympic Driver</A
|
||
></H3
|
||
><P
|
||
> IBM PCI Pit/Pit-Phy/Olympic chipset based token ring cards
|
||
</P
|
||
><P
|
||
> Options:
|
||
</P
|
||
><P
|
||
> The driver accepts four options: ringspeed, pkt_buf_sz,
|
||
message_level and network_monitor.
|
||
</P
|
||
><P
|
||
> These options can be specified differently for each card found, i.e if you
|
||
have two olympic adapters in your machine and want to assign a ring speed of 16mbps
|
||
to the first adapter, but a ring speed of 4mbps to the second adapter, your options
|
||
line would read:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> options olympic ringspeed=16,4
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
However, it should be noted that the driver assigns value to each adapter in the
|
||
order they are discovered<65> which is usually the order there are present on the pci
|
||
bus. A little trial and error may be required to be certain which adapter is receiving
|
||
which configuration option.
|
||
</P
|
||
><P
|
||
> <P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>ringspeed</EM
|
||
>: Has one of three settings 0 (default), 4 or 16. 0 will
|
||
make the card autosense the ringspeed and join at the appropriate speed,
|
||
this will be the default option for most people. 4 or 16 allow you to
|
||
explicitly force the card to operate at a certain speed. The card will fail
|
||
if you try to insert it at the wrong speed. (Although some hubs will allow
|
||
this so be *very* careful). The main purpose for explicitly setting the ring
|
||
speed is for when the card is first on the ring. In autosense mode, if the card
|
||
cannot detect any active monitors on the ring it will not open, so you must
|
||
re-init the card at the appropriate speed. Unfortunately at present the only
|
||
way of doing this is rmmod and insmod which is a bit tough if it is compiled
|
||
in the kernel. The driver does support 100 mbps full duplex operation. This
|
||
is automatically detected by the adapter when connected to an appropriate
|
||
switch.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>pkt_buf_sz</EM
|
||
>: This is this initial receive buffer allocation
|
||
size. This will default to 4096 if no value is entered. You may increase
|
||
performance of the driver by setting this to a value larger than the network
|
||
packet size, although the driver now re-sizes buffers based on MTU settings as well.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>message_level</EM
|
||
>: Controls level of messages created by the
|
||
driver. Defaults to 0 which only displays start-up and critical messages.
|
||
Presently any non-zero value will display all soft messages as well. NB This
|
||
does not turn debugging messages on, that must be done by modified the source code.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>network_monitor</EM
|
||
>: Any non-zero value will provide a
|
||
quasi network monitoring mode. All unexpected MAC frames (beaconing etc.)
|
||
will be received by the driver and the source and destination addresses printed.
|
||
Also an entry will be added in /proc/net called olympic_tr%d, where tr%d
|
||
is the registered device name, i.e tr0, tr1, etc. This displays low
|
||
level information about the configuration of the ring and the adapter.
|
||
This feature has been designed for network administrators to assist in
|
||
the diagnosis of network / ring problems. (This used to OLYMPIC_NETWORK_MONITOR,
|
||
but has now changed to allow each adapter to be configured differently and
|
||
to alleviate the necessity to re-compile olympic to turn the option on).
|
||
</P
|
||
></LI
|
||
></UL
|
||
>
|
||
|
||
</P
|
||
><DIV
|
||
CLASS="FORMALPARA"
|
||
><P
|
||
><B
|
||
>Multi-card. </B
|
||
> The driver will detect multiple cards and will work with shared interrupts,
|
||
each card is assigned the next token ring device, i.e. tr0 , tr1, tr2. The
|
||
driver should also happily reside in the system with other drivers. It has
|
||
been tested with ibmtr.c running. I have had multiple cards in the same
|
||
system, all sharing the same interrupt and working perfectly fine together.
|
||
This is also true for the Cardbus Olympic adapters, I have quite happily
|
||
had a Cardbus adapter and regular 16 bit PCMCIA token ring adapter working
|
||
together in the same laptop.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="FORMALPARA"
|
||
><P
|
||
><B
|
||
>Variable MTU size:. </B
|
||
> The driver can handle a MTU size upto either 4500 or 18000 depending upon
|
||
ring speed. The driver also changes the size of the receive buffers as part
|
||
of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
|
||
to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring
|
||
position = 296,000 bytes of memory space, plus of course anything
|
||
necessary for the tx sk_buff's. Remember this is per card, so if you are
|
||
building routers, gateway's etc, you could start to use a lot of memory
|
||
real fast.
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT3"
|
||
><H3
|
||
CLASS="SECT3"
|
||
><A
|
||
NAME="LANSTREAMER"
|
||
>3.1.4. Lanstreamer Driver</A
|
||
></H3
|
||
><P
|
||
> IBM PCI/MCA Lanstreamer chipset based token ring cards
|
||
</P
|
||
><P
|
||
> Options:
|
||
</P
|
||
><P
|
||
> The driver accepts three options: ringspeed, pkt_buf_sz,
|
||
message_level and network_monitor.
|
||
</P
|
||
><P
|
||
> These options can be specified differently for each card found, i.e if you
|
||
have two olympic adapters in your machine and want to assign a ring speed of 16mbps
|
||
to the first adapter, but a ring speed of 4mbps to the second adapter, your options
|
||
line would read:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> options lanstreamer ringspeed=16,4
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
However, it should be noted that the driver assigns value to each adapter in the
|
||
order they are discovered<65> which is usually the order there are present on the pci/mca
|
||
bus. A little trial and error may be required to be certain which adapter is receiving
|
||
which configuration option.
|
||
</P
|
||
><P
|
||
> <P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>ringspeed</EM
|
||
>: Has one of three settings 0 (default), 4 or 16. 0 will
|
||
make the card autosense the ringspeed and join at the appropriate speed,
|
||
this will be the default option for most people. 4 or 16 allow you to
|
||
explicitly force the card to operate at a certain speed. The card will fail
|
||
if you try to insert it at the wrong speed. (Although some hubs will allow
|
||
this so be *very* careful). The main purpose for explicitly setting the ring
|
||
speed is for when the card is first on the ring. In autosense mode, if the card
|
||
cannot detect any active monitors on the ring it will not open, so you must
|
||
re-init the card at the appropriate speed. Unfortunately at present the only
|
||
way of doing this is rmmod and insmod which is a bit tough if it is compiled
|
||
in the kernel.
|
||
switch.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>pkt_buf_sz</EM
|
||
>: This is this initial receive buffer allocation
|
||
size. This will default to 4096 if no value is entered. You may increase
|
||
performance of the driver by setting this to a value larger than the network
|
||
packet size, although the driver now re-sizes buffers based on MTU settings as well.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>message_level</EM
|
||
>: Controls level of messages created by the
|
||
driver. Defaults to 0 which only displays start-up and critical messages.
|
||
Presently any non-zero value will display all soft messages as well. NB This
|
||
does not turn debugging messages on, that must be done by modified the source code.
|
||
</P
|
||
></LI
|
||
></UL
|
||
>
|
||
|
||
</P
|
||
><DIV
|
||
CLASS="FORMALPARA"
|
||
><P
|
||
><B
|
||
>Network Monitor. </B
|
||
> The Lanstreamer driver does support a network monitor mode similar to the olympic
|
||
driver, however it is a compile time option and not a module parameter. To enable
|
||
the network monitor mode, edit lanstreamer.c and change the line:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
>#define STREAMER_NETWORK_MONITOR 0</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
to read:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
>#define STREAMER_NETWORK_MONITOR 1</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
All unexpected MAC frames (beaconing etc.) will be received by the driver and
|
||
the source and destination addresses printed.
|
||
Also an entry will be added in /proc/net called streamer_tr. This displays low
|
||
level information about the configuration of the ring and the adapter.
|
||
This feature has been designed for network administrators to assist in
|
||
the diagnosis of network / ring problems.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="FORMALPARA"
|
||
><P
|
||
><B
|
||
>Multi-card. </B
|
||
> The driver will detect multiple cards and will work with shared interrupts,
|
||
each card is assigned the next token ring device, i.e. tr0 , tr1, tr2. The
|
||
driver should also happily reside in the system with other drivers.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="FORMALPARA"
|
||
><P
|
||
><B
|
||
>Variable MTU size:. </B
|
||
> The driver can handle a MTU size upto either 4500 or 18000 depending upon
|
||
ring speed. The driver also changes the size of the receive buffers as part
|
||
of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
|
||
to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring
|
||
position = 296,000 bytes of memory space, plus of course anything
|
||
necessary for the tx sk_buff's. Remember this is per card, so if you are
|
||
building routers, gateway's etc, you could start to use a lot of memory
|
||
real fast.
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT3"
|
||
><H3
|
||
CLASS="SECT3"
|
||
><A
|
||
NAME="XL-3C359"
|
||
>3.1.5. 3Com 3C359 Driver</A
|
||
></H3
|
||
><P
|
||
> 3COM PCI TOKEN LINK VELOCITY XL TOKEN RING CARDS
|
||
</P
|
||
><P
|
||
> Currently the 3c359 driver in not included in the standard kernel source.
|
||
To utlize the driver, you must download the driver from the
|
||
<A
|
||
HREF="http://www.linuxtr.net"
|
||
TARGET="_top"
|
||
>Linux Token Ring Project</A
|
||
> web
|
||
site and patch your kernel.
|
||
</P
|
||
><P
|
||
> Once you've downloaded the file, you can patch your kernel with the following
|
||
commands:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> cd /usr/src/linux
|
||
patch -p1 < 3c359-2.4.16.patch
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
or, if the patch file is gzipped:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> zcat 3c359-2.4.16.patch | patch -p1
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
Then just run make config|menuconfig|xconfig and select the 3c359 driver from the
|
||
token ring drivers section of the kernel configuration and then compile and install
|
||
the kernel and/or modules as usual.
|
||
</P
|
||
><P
|
||
> Options:
|
||
</P
|
||
><P
|
||
> The driver accepts three options: ringspeed, pkt_buf_sz,
|
||
message_level.
|
||
</P
|
||
><P
|
||
> These options can be specified differently for each card found, i.e if you
|
||
have two olympic adapters in your machine and want to assign a ring speed of 16mbps
|
||
to the first adapter, but a ring speed of 4mbps to the second adapter, your options
|
||
line would read:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> options 3c359 ringspeed=16,4
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
However, it should be noted that the driver assigns value to each adapter in the
|
||
order they are discovered<65> which is usually the order there are present on the pci
|
||
bus. A little trial and error may be required to be certain which adapter is receiving
|
||
which configuration option.
|
||
</P
|
||
><P
|
||
> <P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>ringspeed</EM
|
||
>: Has one of three settings 0 (default), 4 or 16. 0 will
|
||
make the card autosense the ringspeed and join at the appropriate speed,
|
||
this will be the default option for most people. 4 or 16 allow you to
|
||
explicitly force the card to operate at a certain speed. The card will fail
|
||
if you try to insert it at the wrong speed. (Although some hubs will allow
|
||
this so be *very* careful). The main purpose for explicitly setting the ring
|
||
speed is for when the card is first on the ring. In autosense mode, if the card
|
||
cannot detect any active monitors on the ring it will open at the same speed
|
||
as its last opening. This can be harardous if this speed does not match the
|
||
speed you want the ring to operate at.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>pkt_buf_sz</EM
|
||
>: This is this initial receive buffer allocation
|
||
size. This will default to 4096 if no value is entered. You may increase
|
||
performance of the driver by setting this to a value larger than the network
|
||
packet size, although the driver now re-sizes buffers based on MTU settings as well.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> <EM
|
||
>message_level</EM
|
||
>: Controls level of messages created by the
|
||
driver. Defaults to 0 which only displays start-up and critical messages.
|
||
Presently any non-zero value will display all soft messages as well. NB This
|
||
does not turn debugging messages on, that must be done by modified the source code.
|
||
</P
|
||
></LI
|
||
></UL
|
||
>
|
||
|
||
</P
|
||
><DIV
|
||
CLASS="FORMALPARA"
|
||
><P
|
||
><B
|
||
>Multi-card. </B
|
||
> The driver will detect multiple cards and will work with shared interrupts,
|
||
each card is assigned the next token ring device, i.e. tr0 , tr1, tr2. The
|
||
driver should also happily reside in the system with other drivers. It has
|
||
been tested with ibmtr.c running. I have had multiple cards in the same
|
||
system, all sharing the same interrupt and working perfectly fine together.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="FORMALPARA"
|
||
><P
|
||
><B
|
||
>Variable MTU size:. </B
|
||
> The driver can handle a MTU size upto either 4500 or 18000 depending upon
|
||
ring speed. The driver also changes the size of the receive buffers as part
|
||
of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
|
||
to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring
|
||
position = 296,000 bytes of memory space, plus of course anything
|
||
necessary for the tx sk_buff's. Remember this is per card, so if you are
|
||
building routers, gateway's etc, you could start to use a lot of memory
|
||
real fast.
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT3"
|
||
><H3
|
||
CLASS="SECT3"
|
||
><A
|
||
NAME="SYSKONNECT"
|
||
>3.1.6. SysKonnect adapters</A
|
||
></H3
|
||
><P
|
||
> Information for the SysKonnect Token Ring ISA/PCI Adapter is courtesy Jay
|
||
Schulist <TT
|
||
CLASS="EMAIL"
|
||
><<A
|
||
HREF="mailto:jschlst@samba.org"
|
||
>jschlst@samba.org</A
|
||
>></TT
|
||
>
|
||
</P
|
||
><P
|
||
> The Linux SysKonnect Token Ring driver works with the SysKonnect TR4/16(+) ISA,
|
||
SysKonnect TR4/16(+) PCI, SysKonnect TR4/16 PCI, and older revisions of the
|
||
SK NET TR4/16 ISA card.
|
||
</P
|
||
><P
|
||
> Latest information on this driver can be obtained on the Linux-SNA WWW site.
|
||
Please point your browser to: http://www.linux-sna.org
|
||
</P
|
||
><P
|
||
>
|
||
Important information to be noted:
|
||
<P
|
||
></P
|
||
><UL
|
||
><LI
|
||
><P
|
||
> 1. Adapters can be slow to open (~20 secs) and close (~5 secs), please be
|
||
patient.
|
||
</P
|
||
></LI
|
||
><LI
|
||
><P
|
||
> 2. This driver works very well when autoprobing for adapters. Why even
|
||
think about those nasty io/int/dma settings of modprobe when the driver
|
||
will do it all for you!
|
||
</P
|
||
></LI
|
||
></UL
|
||
>
|
||
</P
|
||
><P
|
||
> This driver is rather simple to use. Select Y to Token Ring adapter support
|
||
in the kernel configuration. A choice for SysKonnect Token Ring adapters will
|
||
appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this
|
||
option. I personally recommend compiling the driver as a module (M), but if you
|
||
you would like to compile it staticly answer Y instead.
|
||
</P
|
||
><P
|
||
> This driver supports multiple adapters without the need to load multiple copies
|
||
of the driver. You should be able to load up to 7 adapters without any kernel
|
||
modifications, if you are in need of more please contact the maintainer of this
|
||
driver.
|
||
</P
|
||
><P
|
||
> Load the driver either by lilo/loadlin or as a module. When a module using the
|
||
following command will suffice for most:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> # modprobe sktr
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
|
||
This will produce output similar to the following: (Output is user specific)
|
||
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> sktr.c: v1.01 08/29/97 by Christoph Goos
|
||
tr0: SK NET TR 4/16 PCI found at 0x6100, using IRQ 17.
|
||
tr1: SK NET TR 4/16 PCI found at 0x6200, using IRQ 16.
|
||
tr2: SK NET TR 4/16 ISA found at 0xa20, using IRQ 10 and DMA 5.
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
|
||
|
||
Now just setup the device via ifconfig and set and routes you may have. After
|
||
this you are ready to start sending some tokens.
|
||
</P
|
||
><DIV
|
||
CLASS="FORMALPARA"
|
||
><P
|
||
><B
|
||
>Errata. </B
|
||
> For anyone wondering where to pick up the SysKonnect adapters please browse
|
||
to http://www.syskonnect.com
|
||
</P
|
||
></DIV
|
||
><P
|
||
> Below is the setting for the SK NET TR 4/16 ISA adapters
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> ***************************
|
||
*** C O N T E N T S ***
|
||
***************************
|
||
|
||
1) Location of DIP-Switch W1
|
||
2) Default settings
|
||
3) DIP-Switch W1 description
|
||
|
||
|
||
==============================================================
|
||
CHAPTER 1 LOCATION OF DIP-SWITCH
|
||
==============================================================
|
||
|
||
+------------------------------------------------------------------+
|
||
|+------+ +-----+ +---+ |
|
||
||------| W1 +-----+ +----+ | | |
|
||
||------| | | | | +---+
|
||
||------| +-----------+ +----+ | | | ||
|
||
||------| | | +---+ +---+ +---+
|
||
||------| | TMS380C26 | | | |
|
||
||------| | | +---+ |-+
|
||
|+------+ | | | |
|
||
| +-----------+ | |
|
||
| | |
|
||
| |-+
|
||
| |
|
||
| |
|
||
| |
|
||
| |
|
||
+------------+----------------+--+-----------------------+---------+
|
||
+----------------+ +-----------------------+
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
>
|
||
==============================================================
|
||
CHAPTER 2 DEFAULT SETTINGS
|
||
==============================================================
|
||
|
||
W1 1 2 3 4 5 6 7 8
|
||
+------------------------------+
|
||
| ON X |
|
||
| OFF X X X X X X X |
|
||
+------------------------------+
|
||
|
||
W1.1 = ON Adapter drives address lines SA17..19
|
||
W1.2 - 1.5 = OFF BootROM disabled
|
||
W1.6 - 1.8 = OFF I/O address 0A20h
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> ==============================================================
|
||
CHAPTER 3 DIP SWITCH W1 DESCRIPTION
|
||
==============================================================
|
||
|
||
+---+---+---+---+---+---+---+---+ ON
|
||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|
||
+---+---+---+---+---+---+---+---+ OFF
|
||
|AD | BootROM Addr. | I/O |
|
||
+-+-+-------+-------+-----+-----+
|
||
| | |
|
||
| | +------ 6 7 8
|
||
| | ON ON ON 1900h
|
||
| | ON ON OFF 0900h
|
||
| | ON OFF ON 1980h
|
||
| | ON OFF OFF 0980h
|
||
| | OFF ON ON 1b20h
|
||
| | OFF ON OFF 0b20h
|
||
| | OFF OFF ON 1a20h
|
||
| | OFF OFF OFF 0a20h (+)
|
||
| |
|
||
| |
|
||
| +-------- 2 3 4 5
|
||
| OFF x x x disabled (+)
|
||
| ON ON ON ON C0000
|
||
| ON ON ON OFF C4000
|
||
| ON ON OFF ON C8000
|
||
| ON ON OFF OFF CC000
|
||
| ON OFF ON ON D0000
|
||
| ON OFF ON OFF D4000
|
||
| ON OFF OFF ON D8000
|
||
| ON OFF OFF OFF DC000
|
||
|
|
||
|
|
||
+----- 1
|
||
OFF adapter does NOT drive SA<17..19>
|
||
ON adapter drives SA<17..19> (+)
|
||
|
||
|
||
(+) means default setting
|
||
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT3"
|
||
><H3
|
||
CLASS="SECT3"
|
||
><A
|
||
NAME="PCMCIA"
|
||
>3.1.7. PCMCIA</A
|
||
></H3
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="PCMCIAINTRO"
|
||
>3.1.7.1. Introduction</A
|
||
></H4
|
||
><P
|
||
> PCMCIA Token Ring adapters will work on all versions of the Linux kernel.
|
||
Unfortunately, the road to hell is often paved with melting snowballs ;-)
|
||
and there are a myriad of different combinations that can be used to get the
|
||
adapters to work, all with different options, different requirements and
|
||
different issues. Hopefully with this document you will be able to figure
|
||
out which combinations of ingredients are required and how to get them up and
|
||
running on your machine.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="HISTORY"
|
||
>3.1.7.2. History</A
|
||
></H4
|
||
><P
|
||
> In the 2.0.x and 2.2.x kernels days, pcmcia was only available as an external
|
||
package, created and maintained by David Hinds. When the only stable kernel
|
||
available was 2.0.36, life was pretty easy and with a few simple configuration
|
||
options the adapters would work.
|
||
</P
|
||
><P
|
||
>
|
||
With the advent of 2.2.x, ibmtr.c was completely updated, which broke the pcmcia
|
||
driver (ibmtr_cs.c). The pcmcia driver was updated to work with the new ibmtr driver
|
||
and the 2.2.x kernels. This is where the first level of complication starts. As
|
||
the pcmcia_cs package is stand alone, it has to support the various different
|
||
kernels, so instead of being able to have different versions of drivers in different
|
||
versions of the kernel source, the pcmcia_cs drivers must work with all kernel
|
||
versions. This not only creates some ugliness in the driver itself but also causes
|
||
confusion as to which version of pcmcia_cs works for the latest kernel.
|
||
</P
|
||
><P
|
||
> At this point, everything was working fine, and then come along the 2.3.x develpment
|
||
series of kernels. The 2.3.x kernels provided their own support for pcmcia and the
|
||
ibmtr_cs driver was included in the kernel proper. So now there were two ways of
|
||
getting pcmcia token ring support, either using the kernel drivers themselves or
|
||
using the pcmcia_cs package, not too much of a problem because only developers were
|
||
using the 2.3.x kernels. Of course this all changed when the 2.4 kernel was released
|
||
and a lot more users started using the kernel.
|
||
</P
|
||
><P
|
||
>
|
||
During late 2000, early 2001, significant development work was done on both the
|
||
standard ibmtr driver and the pcmcia driver. Original pcmcia updates including using
|
||
high memory and hot-eject support. These initial updates were only for the 2.2.x kernels,
|
||
and hence only included in the pcmcia_cs package. Later development saw great improvements
|
||
in ibmtr and ibmtr_cs for the 2.4.x kernels. So as of writing, 1/23/02 , there are many
|
||
different combinations of kernel version and driver floating around especially considering
|
||
that different distributions have released different versions of the 2.4 kernels.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="K20"
|
||
>3.1.7.3. 2.0.x kernels</A
|
||
></H4
|
||
><P
|
||
> If you are using one of the 2.0.x kernels, then I salute your perserverance and really you
|
||
should have got the pcmcia drivers configured and working by now ;-)
|
||
</P
|
||
><P
|
||
> You will have to use the pcmcia_cs package and play with the /etc/pcmcia/config.opts, see
|
||
the section below about config.opts fun. Just about any version of pcmcia_cs that's been
|
||
released in the last 2/3 years will work fine.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="K220"
|
||
>3.1.7.4. 2.2.0 - 2.2.6 kernels</A
|
||
></H4
|
||
><P
|
||
> These were the series of kernels where the pcmcia driver didn't work at all. It's probably
|
||
just easiest to upgrade the kernel to a later version.
|
||
</P
|
||
><P
|
||
> If you really do need to get this up and running, then a recent pcmcia_cs is required and
|
||
you should be able to grab the ibmtr.c and ibmtr.h from a 2.2.7 - 2.2.16 kernel and use
|
||
them (note no greater than 2.2.16 !!)
|
||
</P
|
||
><P
|
||
> You have to do the config.opts mangling, see the section on setting all this up.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="K2216"
|
||
>3.1.7.5. 2.2.7 - 2.2.16 kernels</A
|
||
></H4
|
||
><P
|
||
> These kernels are well supported, simply use the pcmcia_cs package and play with the
|
||
config.opts file.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="K2219"
|
||
>3.1.7.6. 2.2.17 - 2.2.19 kernels</A
|
||
></H4
|
||
><P
|
||
> The pcmcia driver was updated for these kernel to eliminate the need for the config.opts
|
||
mangling. You'll need pcmcia_cs at least 3.1.24, although it is probably better just to
|
||
grab the latest version.
|
||
</P
|
||
><P
|
||
>
|
||
Simply compile up pcmcia_cs and you're done. No need to play with config.opts, in fact
|
||
if you've been running a previous version that did have the ibmtr_cs line in config.opts
|
||
it would be a <EM
|
||
>very good</EM
|
||
> idea to remove or comment out the line.
|
||
The new driver allocates the entire 64k for shared ram and it needs to be aligned on a 64k
|
||
boundary, if you've got a previous srambase value not on a 64k boundary, the driver will
|
||
barf and the kernel will panic.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="K24"
|
||
>3.1.7.7. 2.4.0 - 2.4.4 (non Redhat) kernels</A
|
||
></H4
|
||
><P
|
||
> Use the built-in kernel pcmcia driver and play with config.opts.
|
||
</P
|
||
><P
|
||
> If you want to use the latest and greatest version of the driver with the high memory and
|
||
hot-swap support you can download the patch and patch up your kernel. Then the line in
|
||
config.opts can be removed and everything will work fine.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="K244"
|
||
>3.1.7.8. 2.4.4-ac11 > kernels</A
|
||
></H4
|
||
><P
|
||
> These kernels include the new drivers so simply compile up the drivers, ensure that there is
|
||
no configuration line in config.opts and away you go.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="K24RH"
|
||
>3.1.7.9. 2.4.2 mangled, i.e. Redhat 7.1</A
|
||
></H4
|
||
><P
|
||
> When RedHat released 7.1 with the 2.4.2 kernel they modified the kernel (as they always
|
||
do) and included the updated ibmtr/ibmtr_cs driver from the
|
||
<A
|
||
HREF="http://www.linuxtr.net"
|
||
TARGET="_top"
|
||
>web site</A
|
||
>. If you're lucky this
|
||
may work straight out of the box (again no need for the ibmtr_cs line in config.opts), if
|
||
not then it is probably easiest to upgrade to the latest 2.4.x kernels and use the drivers
|
||
there. (The reason being that while I will work out how to get around a distribution
|
||
caused problem, I will not provide support for them, I'll answer questions and give help
|
||
because I'm a nice guy, but I am not going to provide driver updates against distributions.
|
||
Official support is for the drivers in the kernels available from the official kernel mirrors.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="K24CS"
|
||
>3.1.7.10. 2.4.x kernels and pcmcia_cs</A
|
||
></H4
|
||
><P
|
||
> There is no need to use pcmcia_cs with the 2.4 kernels to get the token ring adapters up
|
||
and running, but I appreciate that some of you may need to use pcmcia_cs to get other adapters
|
||
working that are not supported properly in the kernel.
|
||
</P
|
||
><P
|
||
>
|
||
The pcmcia_cs package will not work with the latest drivers, it may work with the 2.4.0-2.4.4
|
||
drivers. I am currently in two minds about providing support with pcmcia_cs for the 2.4 kernels,
|
||
you can ask me directly or check the <A
|
||
HREF="http://www.linuxtr.net"
|
||
TARGET="_top"
|
||
>web site</A
|
||
> every
|
||
now and then so see if anything has changed.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT4"
|
||
><H4
|
||
CLASS="SECT4"
|
||
><A
|
||
NAME="MANGLING"
|
||
>3.1.7.11. Config.opts mangling (or how to send yourself insane)</A
|
||
></H4
|
||
><P
|
||
> This is the hardest part to getting the pcmcia adapters working with the drivers that need the
|
||
ibmtr_cs line in /etc/pcmcia/config.opts. No set of values is guaranteed to work the same on a
|
||
different machine. It really is a case of trial and error but forewarned and forearmed with a
|
||
little bit of knowledge can make the process a whole lot easier.
|
||
</P
|
||
><P
|
||
> <SPAN
|
||
CLASS="QUOTE"
|
||
>"Hey, I don't care, just give me something that works"</SPAN
|
||
>
|
||
</P
|
||
><P
|
||
> OK, try this, it works in most situations, if it doesn't you have to read the rest of the
|
||
section anyway. Just insert the following line in /etc/pcmcia/config.opts
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
>modules "ibmtr_cs" opts "mmiobase=0xd2000 srambase=0xd4000"</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
restart pcmcia and insert the adapter.
|
||
</P
|
||
><P
|
||
> <SPAN
|
||
CLASS="QUOTE"
|
||
>"OK, that didn't work, bring on the pain"</SPAN
|
||
>
|
||
</P
|
||
><P
|
||
> The pcmcia driver need to allocate two areas of memory to operate properly. All areas of memory
|
||
allocated must be aligned on the same boundary as the size of the area being aligned, i.e.
|
||
a block 8K in size must be on an 8K boundary (0xc8000, 0xca000, 0xcc000, 0xce000, 0xd0000, 0xd2000)
|
||
and for a 16K block must be on a 16K boundary (0xc8000, 0xcc000, 0xd0000, 0xd4000). All memory
|
||
areas must be allocated within the ISA address space, 0xC0000-0xDFFFF). Theoretically you should be
|
||
able to use anywhere within this area, although experience has shown that most machines hide
|
||
stuff in the 0xc0000-0xc9fff area. Some machines have even been known to use the 0xd0000-0xd1fff
|
||
area without telling anybody (some thinkpads !!). So you really want to stick with memory
|
||
allocations in the 0xcc000 - 0xdffff range.
|
||
</P
|
||
><P
|
||
> Of course, the two memory areas cannot overlap either ;)
|
||
</P
|
||
><P
|
||
> The first area of memory is an 8K area for the memory mapped input/output (MMIO) and must be
|
||
placed on an 8K boundary. This area of memory is not usually the cause of any problems and can be
|
||
placed pretty much anywhere, recommended values are: 0xcc000, 0xd0000,0xd2000,0xd4000.
|
||
</P
|
||
><P
|
||
>
|
||
The second area of memory can be sized to fit your desires, this is the area of memory where the
|
||
incoming and outgoing packets are stored and received. The driver defaults to a 16K memory size
|
||
and must be placed on a 16K boundary. Good areas are: 0xd0000,0xd4000,0xd8000.
|
||
</P
|
||
><P
|
||
> Once you've decided which areas of memory you are goin to try, you need to add the correct line
|
||
to the /etc/pcmcia/config.opts file. Configuration lines in this file take the format of:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> module "module_name" opts "option1=opt1_value option2=opt2_value ...."
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
In our case module_name is ibmtr_cs. There are three options that be set with the ibmtr_cs driver,
|
||
mmiobase, srambase and sramsize.
|
||
</P
|
||
><P
|
||
> If they are not set they will revert to the defaults in the driver, which in 9 cases out of 10
|
||
won't work for you. sramsize rarely has to be set unless you are looking for that last little bit
|
||
of performance from your adapter.
|
||
</P
|
||
><P
|
||
> So, having decided upon your values, let's say 0xd2000 for the MMIO and 0xd4000 for the shared
|
||
memory you would build a config.opts line like this:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> module "ibmtr_cs" opts "mmiobase=0xd2000 srambase=0xd4000"
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
The pcmcia_cs package must be restarted for these new options to take effect, usually with:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
>/etc/init.d/pcmcia restart or /etc/rc.d/init.d/pcmcia/restart</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
depending upon which run level organization your distribution adheres to.
|
||
</P
|
||
><P
|
||
> Then just plug it in and see if it works. If not you'll just have to go back and change the
|
||
values for mmiobase and srambase until you find a combination that works.
|
||
Or, you can upgrade to a kernel/pcmcia_cs version that support high memory allocation,
|
||
where all this config.opts nonsense is not required and you can just happily plug your adapter
|
||
in and watch it run.
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT3"
|
||
><H3
|
||
CLASS="SECT3"
|
||
><A
|
||
NAME="MADGE"
|
||
>3.1.8. Madge Supplied Drivers</A
|
||
></H3
|
||
><P
|
||
> Madge released 2.31 of their driver in 1999 and 2.41 in late 2001. Both drivers can
|
||
be downloaded from the <A
|
||
HREF="http://www.madge.com"
|
||
TARGET="_top"
|
||
>Madge</A
|
||
> web site and
|
||
the 2.41 driver is also available from the
|
||
<A
|
||
HREF="http:/www.linuxtr.net"
|
||
TARGET="_top"
|
||
>Linux Token Ring Project</A
|
||
> web site.
|
||
</P
|
||
><P
|
||
> Once the drivers have been downloaded, see the README file that comes with the drivers
|
||
for instruction on how to built and install the drivers. The only other issue some
|
||
people find with the drivers is a failure to build the tool chain due to an incorrect
|
||
version of the newt libraries. If you get a compiler error relating to newt.h change
|
||
the madge-source/include/mtok/config.h file so that the #define NEWNEWT line reads:
|
||
<TABLE
|
||
BORDER="1"
|
||
BGCOLOR="#E0E0E0"
|
||
WIDTH="100%"
|
||
><TR
|
||
><TD
|
||
><FONT
|
||
COLOR="#000000"
|
||
><PRE
|
||
CLASS="SCREEN"
|
||
> #define NEWNEWT 1
|
||
</PRE
|
||
></FONT
|
||
></TD
|
||
></TR
|
||
></TABLE
|
||
>
|
||
This will ensure the tools use the correct newt libraries during the build process.
|
||
</P
|
||
><P
|
||
> A patch is available from the <A
|
||
HREF="http://www.linuxtr.net"
|
||
TARGET="_top"
|
||
>Linux Token Ring
|
||
Project</A
|
||
> web site for the 2.31 drivers to enable them to work with the
|
||
2.4.x kernels.
|
||
</P
|
||
></DIV
|
||
><DIV
|
||
CLASS="SECT3"
|
||
><H3
|
||
CLASS="SECT3"
|
||
><A
|
||
NAME="OLICOM"
|
||
>3.1.9. Olicom Drivers</A
|
||
></H3
|
||
><P
|
||
> Back when Olicom were still in business they did produce a Linux driver
|
||
that does actually work. Trying to find the driver these days is a bit tough.
|
||
If the ftp.olicom.com site is still up and running, the driver can be found
|
||
there.
|
||
</P
|
||
><P
|
||
> The driver is a combination of GPL source code and proprietary binary low level
|
||
code. The driver only works with the 2.0.36 and 2.2.x kernels. It should be
|
||
possible to port this driver to the 2.4.x kernels...
|
||
</P
|
||
></DIV
|
||
></DIV
|
||
></DIV
|
||
><DIV
|
||
CLASS="NAVFOOTER"
|
||
><HR
|
||
ALIGN="LEFT"
|
||
WIDTH="100%"><TABLE
|
||
WIDTH="100%"
|
||
BORDER="0"
|
||
CELLPADDING="0"
|
||
CELLSPACING="0"
|
||
><TR
|
||
><TD
|
||
WIDTH="33%"
|
||
ALIGN="left"
|
||
VALIGN="top"
|
||
><A
|
||
HREF="hardware.html"
|
||
>Prev</A
|
||
></TD
|
||
><TD
|
||
WIDTH="34%"
|
||
ALIGN="center"
|
||
VALIGN="top"
|
||
><A
|
||
HREF="index.html"
|
||
>Home</A
|
||
></TD
|
||
><TD
|
||
WIDTH="33%"
|
||
ALIGN="right"
|
||
VALIGN="top"
|
||
><A
|
||
HREF="problemns.html"
|
||
>Next</A
|
||
></TD
|
||
></TR
|
||
><TR
|
||
><TD
|
||
WIDTH="33%"
|
||
ALIGN="left"
|
||
VALIGN="top"
|
||
>Hardware requirements</TD
|
||
><TD
|
||
WIDTH="34%"
|
||
ALIGN="center"
|
||
VALIGN="top"
|
||
> </TD
|
||
><TD
|
||
WIDTH="33%"
|
||
ALIGN="right"
|
||
VALIGN="top"
|
||
>Known problems</TD
|
||
></TR
|
||
></TABLE
|
||
></DIV
|
||
></BODY
|
||
></HTML
|
||
> |