pkg://Linux-HOWTOs.tar.gz:1682658/PCMCIA-HOWTO
downloads
Linux PCMCIA HOWTO
David Hinds, dhinds@hyper.stanford.edu
v1.105, 9 October 1997
This document describes how to install and use PCMCIA Card Services
for Linux, and answers some frequently asked questions. The latest
version of this document can always be found at hyper.stanford.edu in
/pub/pcmcia/doc. An HTML version is at
http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html
1. General information and hardware requirements
1.1. Introduction
Card Services for Linux is a complete PCMCIA support package. It
includes a set of loadable kernel modules that implement a version of
the PCMCIA Card Services applications program interface, a set of
client drivers for specific cards, and a card manager daemon that can
respond to card insertion and removal events, loading and unloading
drivers on demand. It supports ``hot swapping'' of PCMCIA cards, so
cards can be inserted and ejected at any time.
This software is still under development. It probably contains bugs,
and should be used with caution. I'll do my best to fix problems that
are reported to me, but if you don't tell me, I may never know. If
you use this code, I hope you will send me your experiences, good or
bad!
If you have any suggestions for how this document could be improved,
please let me know (dhinds@hyper.stanford.edu).
1.2. Copyright notice and disclaimer
Copyright (c) 1996, 1997 David A. Hinds
This document may be reproduced or distributed in any form without my
prior permission. Modified versions of this document, including
translations into other languages, may be freely distributed, provided
that they are clearly identified as such, and this copyright is
included intact.
This document may be included in commercial distributions without my
prior consent. While it is not required, I would like to be informed
of such usage. If you intend to incorporate this document in a
published work, please contact me to make sure you have the latest
available version.
This document is provided ``as is'', with no explicit or implied
warranties. Use the information in this document at your own risk.
1.3. What is the latest version, and where can I get it?
The current major release of Card Services is version 2.9, and minor
updates or bug fixes are numbered 2.9.1, 2.9.2, and so on.
Source code for the latest version is available from
hyper.stanford.edu in the /pub/pcmcia directory, as pcmcia-
cs-2.9.?.tar.gz. There will usually be several versions here. I
generally only keep the latest minor release for a given major
release. New major releases may contain relatively untested code, so
I also keep the latest version of the previous major release as a
relatively stable fallback; the current fallback is 2.8.23. It is up
to you to decide which version is more appropriate, but the CHANGES
file will summarize the most important differences.
hyper.stanford.edu is mirrored at sunsite.unc.edu in
/pub/Linux/kernel/pcmcia. I'll also try to upload major releases to
tsx-11.mit.edu under /pub/linux/packages/laptops/pcmcia now and then.
If you do not feel up to compiling the PCMCIA drivers from scratch,
pre-compiled drivers are included with current releases of most of the
major Linux distributions, including Slackware, Red Hat, Caldera, and
Yggdrasil, among others.
1.4. What systems are supported?
This code should run on almost any Linux-capable laptop. All common
PCMCIA controllers are supported, including Intel, Cirrus, Vadem,
VLSI, Ricoh, and Databook chips. Custom controllers used in IBM and
Toshiba laptops are also supported. PCMCIA card docks for desktop
systems should work as long as they are the type that plugs directly
into the ISA bus, rather than SCSI-to-PCMCIA or IDE-to-PCMCIA
adapters.
The Motorola 6AHC05GA controller used in some Hyundai laptops is not
supported. The custom PCMCIA controller in the HP Omnibook 600 is
unsupported. PCI to CardBus bridge controllers (from SMC, Ricoh,
Cirrus, and TI) are currently supported only in legacy 16-bit mode,
and this support is still somewhat experimental.
1.5. What PCMCIA cards are supported?
The current release includes drivers for a variety of ethernet cards,
a driver for modem and serial port cards, several SCSI adapter
drivers, a driver for ATA/IDE drive cards, and memory card drivers
that should support most SRAM cards and some flash cards. The
SUPPORTED.CARDS file included with each release of Card Services lists
all cards that are known to work in at least one actual system.
The likelihood that a card not on the supported list will work depends
on the type of card. Essentially all modems should work with the
supplied driver. Some network cards may work if they are OEM versions
of supported cards. Other types of IO cards (frame buffers, sound
cards, etc) will not work until someone writes the appropriate
drivers.
1.6. When will my new card be supported?
Unfortunately, they usually don't pay me to write device drivers, so
if you would like to have a driver for your favorite card, you are
probably going to have to do at least some of the work. Ideally, I'd
like to work towards a model like the Linux kernel, where I would be
responsible mainly for the ``core'' PCMCIA code and other authors
would contribute and maintain drivers for specific cards. The
SUPPORTED.CARDS file mentions some cards for which driver work is
currently in progress. I will try to help where I can, but be warned
that debugging kernel device drivers by email is not particularly
effective.
Manufacturers interested in helping provide Linux support for their
products can contact me about consulting arrangements.
1.7. Mailing lists
I used to maintain a database and mailing list of Linux PCMCIA users.
More recently, I've turned my web page for Linux PCMCIA information
into a ``HyperNews'' site, with a set of message lists for Linux
PCMCIA issues. There are lists for installation and configuration
issues, for different types of cards, and for PCMCIA programming and
debugging. The Linux PCMCIA information page is at
http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html. Users can
request email notification of new responses to particular questions,
or notification for all new messages in a given category. I hope that
this will become a useful repository of information, for questions
that go beyond the scope of the HOWTO.
There is a Linux mailing list devoted to laptop issues, the ``linux-
laptop'' list. For more information, send a message containing the
word ``help'' to majordomo@vger.rutgers.edu. To subscribe, send a
message containing ``subscribe linux-laptop'' to the same address.
This mailing list might be a good forum for discussion of Linux PCMCIA
issues.
The Linux Laptop Home Page at
http://www.cs.utexas.edu/users/kharker/linux-laptop has links to many
sites that have information about configuring specific types of
laptops for Linux (and PCMCIA). There is also a searchable database
of system configuration information.
2. Compilation, installation, and configuration
2.1. Prerequisites and kernel setup
Before starting, you should think about whether you really need to
compile the PCMCIA package yourself. All common Linux distributions
come with pre-compiled PCMCIA driver packages. Generally, you only
need to install the drivers from scratch if you need a new feature of
the current drivers, or if you've updated and/or reconfigured your
kernel in a way that is incompatible with the drivers included with
your Linux distribution. While compiling the PCMCIA package is not
technically difficult, it does require some general Linux familiarity.
The following things should be installed on your system before you
start installing PCMCIA:
· One of the following kernels: 1.2.8 through 1.2.13, 1.3.30, 1.3.37,
1.3.39 through 1.3.99, 1.99.* (i.e., pre-2.0), 2.0.*, or 2.1.*.
· A current set of module utilities.
· (Optional) the ``Forms'' X11 user interface toolkit.
The latest version requires a kernel version 1.2.8 or higher, or a
development kernel 1.3.30 or higher. 1.3.38 is definitely broken, and
1.3.31 to 1.3.36 are untested. It also requires a relatively recent
set of module utilities. There are no kernel patches specifically for
PCMCIA.
You need to have a complete linux source tree for your kernel, not
just an up-to-date kernel image, to compile the PCMCIA package. The
PCMCIA modules contain some references to kernel source files. While
you may want to build a new kernel to remove unnecessary drivers,
installing PCMCIA does not require you to do so.
Current ``stable'' kernel sources and patches are available from
sunsite.unc.edu in /pub/Linux/kernel/v2.0, or from tsx-11.mit.edu in
/pub/linux/sources/system/v2.0. Current module utilities can be found
in the same place, in modules-2.0.0.tgz. Development kernels can be
found in the corresponding v2.1 subdirectories.
In the Linux source tree for 2.0 and 2.1 kernels, the
Documentation/Changes file describes the versions of all sorts of
other system components that are required for that kernel release.
You may want to check through this and verify that your system is up
to date, especially if you have updated your kernel. If you are using
a 2.1 kernel, be sure that you are using the right combination of
shared libraries and module tools. The latest versions of the module
utilities, as well as versions for older kernels, can be found at
<http://www.pi.se/blox/modules>.
When configuring your kernel, if you plan on using a PCMCIA ethernet
card, you should turn on networking support but turn off the normal
Linux network card drivers, including the ``pocket and portable
adapters''. The PCMCIA network card drivers are all implemented as
loadable modules. Any drivers compiled into your kernel will only
waste space.
If you want to use SLIP, PPP, or PLIP, you do need to either configure
your kernel with these enabled, or use the loadable module versions of
these drivers. There is an unfortunate deficiency in the kernel
config process in 1.2.X kernels, in that it is not possible to set
configuration options (like SLIP compression) for a loadable module,
so it is probably better to just link SLIP into the kernel if you need
it.
If you want to use a PCMCIA token ring adapter, your kernel needs to
be configured with ``Token Ring driver support'' (CONFIG_TR) enabled,
though you should leave CONFIG_IBMTR off.
If you want to use a PCMCIA IDE adapter, your kernel should be
configured with CONFIG_BLK_DEV_IDE_PCMCIA enabled, for 1.3.72 through
2.1.7 kernels. Older kernels do not support removeable IDE devices;
newer kernels do not require a special configuration setting.
If you will be using a PCMCIA SCSI adapter, you should enable
CONFIG_SCSI when configuring your kernel. Also, enable any top level
drivers (SCSI disk, tape, cdrom, generic) that you expect to use. All
low-level drivers for particular host adapters should be disabled, as
they will just take up space.
If you want to modularize a driver that is needed for a PCMCIA device,
you must modify /etc/pcmcia/config to specify what modules need to be
loaded for what card types. For example, if the serial driver is
modularized, then you could change the serial device definition to:
device "serial_cs"
class "serial" module "misc/serial", "serial_cs"
This package includes an X-based card status utility called cardinfo.
This utility is based on a freely distributed user interface toolkit
called the Forms Library, which you will need to install before
building cardinfo. A binary distribution is on hyper.stanford.edu in
/pub/pcmcia/extras: there are both a.out and ELF versions of the
library. You will also need to have all the normal X header files and
libraries installed.
2.2. Installation
Here is a synopsis of the installation process:
· Unpack pcmcia-cs-2.9.?.tar.gz in /usr/src.
· Run ``make config'' in the new pcmcia-cs-2.9.? directory.
· Run ``make all'', then ``make install''.
· Customize the PCMCIA startup script and the option files in
/etc/pcmcia for your site.
If you plan to install any contributed client drivers not included in
the core PCMCIA distribution, unpack each of them in the top-level
directory of the PCMCIA source tree. Then follow the normal build
instructions. The extra drivers will be compiled and installed
automatically.
Running ``make config'' prompts for a few configuration options, and
checks out your system to verify that it satisfies all prerequisites
for installing PCMCIA support. In most cases, you'll be able to just
accept all the default configuration options. Be sure to carefully
check the output of this command in case there are problems.
If you are compiling the PCMCIA package for installation on another
machine, specify an alternate target directory when prompted by the
configure script. This should be an absolute path. All the PCMCIA
tools will be installed relative to this directory. You will then be
able to tar this directory tree and copy to your target machine, and
unpack relative to its root directory to install everything in the
proper places.
If you are cross compiling on another machine, you may want to specify
alternate names for the compiler and linker. This may also be helpful
on mixed a.out and ELF systems. The script will also prompt for
additional compiler flags for debugging.
Some of the support utilities (cardctl and cardinfo) can be compiled
either in ``safe'' or ``trusting'' forms. The ``safe'' forms prevent
non-root users from modifying card configurations. The ``trusting''
forms permit ordinary users to issue commands to suspend and resume
cards, reset cards, and change the current configuration scheme. The
configuration script will ask if you want the utilities compiled as
safe or trusting: the default is to be safe.
There are a few kernel configuration options that affect the PCMCIA
tools. The configuration script can deduce these from the running
kernel (the most common case). Alternatively, if you are compiling
for installation on another machine, it can read the configuration
from a kernel source tree, or each option can be set interactively.
Running ``make all'' followed by ``make install'' will build and then
install the kernel modules and utility programs. Kernel modules are
installed under /lib/modules/<version>/pcmcia. The cardmgr and
cardctl programs are installed in /sbin. If cardinfo is built, it is
installed in /usr/bin/X11.
Configuration files will be installed in the /etc/pcmcia directory.
If you are installing over an older version, your old config scripts
will be backed up before being replaced. The saved scripts will be
given extensions like *.~1~, *.~2~, and so on.
If you don't know what kind of PCMCIA controller chip you have, you
can use the probe utility in the cardmgr/ subdirectory to determine
this. There are two major types: the Databook TCIC-2 type and the
Intel i82365SL-compatible type.
A user-level daemon processes card insertion and removal events. This
is called cardmgr. It is similar in function to Barry Jaspan's
pcmciad in earlier PCMCIA releases. Cardmgr reads a configuration
file describing known PCMCIA cards from /etc/pcmcia/config. This file
also specifies what resources can be allocated for use by PCMCIA
devices, and may need to be customized for your system. See the
pcmcia man page for more information about this file.
2.3. Post-installation for systems using BSD init scripts
Some Linux distributions, including Slackware, use a BSD arrangement
for system startup scripts. If /etc/rc.d/rc.M exists, your system is
in this group. The script rc.pcmcia, installed in /etc/rc.d, controls
starting up and shutting down the PCMCIA system. ``make install''
will use the probe command to determine your controller type and
modify rc.pcmcia appropriately. You should add a line to your system
startup file /etc/rc.d/rc.M to invoke the PCMCIA startup script, like:
/etc/rc.d/rc.pcmcia start
It does not really matter where you insert this line, as long as the
PCMCIA drivers are started after syslogd.
2.4. Post-installation for systems using System V init scripts
Red Hat, Caldera, and Debian Linux have a System V-ish arrangement for
system startup files. If you have a directory called /etc/init.d or
/etc/rc.d/init.d, then your system is in this group. The rc.pcmcia
script will be installed as /etc/rc.d/init.d/pcmcia, or
/etc/init.d/pcmcia, as appropriate. There is no need to edit any of
the startup scripts to enable PCMCIA: it will happen automatically.
If the /etc/sysconfig directory exists, then a separate configuration
file, /etc/sysconfig/pcmcia, will be created for startup options. If
you need to change any module options (like the PCIC= or PCIC_OPTS=
settings), edit this config file rather than the actual PCMCIA startup
script. This file will not be overwritten by subsequent installs.
Some previous releases used the /etc/sysconfig/pcmcia-scripts
directory in place of /etc/pcmcia on these platforms. The current
release instead uses /etc/pcmcia for all systems, and will move an
existing /etc/sysconfig/pcmcia-scripts to /etc/pcmcia.
2.5. Site-specific configuration options
Card Services should automatically avoid allocating IO ports and
interrupts already in use by other standard devices. It will also
attempt to detect conflicts with unknown devices, but this is not
completely reliable. In some cases, you may need to explicitly
exclude resources for a device in /etc/pcmcia/config.opts.
Here are some resource settings for specific laptop types.
· On the AMS SoundPro, exclude irq 10.
· On some AMS TravelPro 5300 models, use memory 0xc8000-0xcffff.
· On the BMX 486DX2-66, exclude irq 5, irq 9.
· On the Chicony NB5, use memory 0xda000-0xdffff.
· On the Compaq Presario 1020, exclude port 0x2f8-0x2ff, irq 3, irq
5.
· On the HP Omnibook 4000C, exclude port 0x300-0x30f.
· On the Micron Millenia Transport, exclude irq 5, irq 9.
· On the NEC Versa M, exclude irq 9, port 0x2e0-2ff.
· On the NEC Versa P/75, exclude irq 5, irq 9.
· On the NEC Versa S, exclude irq 9, irq 12.
· On the NEC Versa 6000 series, exclude port 0x300-0x33f, irq 9, irq
10.
· On the ProStar 9200, Altima Virage, and Acquiline Hurricane
DX4-100, exclude irq 5, port 0x330-0x35f. Maybe use memory
0xd8000-0xdffff.
· On the Siemens Nixdorf SIMATIC PG 720C, use memory 0xc0000-0xcffff,
port 0x300-0x3bf.
· On the TI TravelMate 5000, use memory 0xd4000-0xdffff.
· On the Toshiba T4900 CT, exclude irq 5, port 0x2e0-0x2e8, port
0x330-0x338.
· On the Twinhead 5100, HP 4000, Sharp PC-8700 and PC-8900, exclude
irq 9 (sound), irq 12.
· On an MPC 800 Series, exclude irq 5, port 0x300-0x30f for the CD-
ROM.
Some PCMCIA controllers have optional features that may or may not be
implemented in a particular system. It is generally impossible for a
socket driver to detect if these features are implemented. Check the
man page for your driver to see what optional features may be enabled.
In a few cases, the probe command will be unable to determine your
controller type automatically. If you have a Halikan NBD 486 system,
it has a TCIC-2 controller at an unusual location: you'll need to edit
rc.pcmcia to load the tcic module, as well as setting the PCIC_OPTS
parameter to ``tcic_base=0x02c0''.
The low level socket drivers, tcic and i82365, have numerous bus
timing parameters that may need to be adjusted for systems with
particularly fast processors. Symptoms of timing problems include
card recognition problems, lock-ups under heavy loads, high error
rates, or poor device performance. Check the corresponding man pages
for more details, but here is a brief summary:
· Cirrus controllers have numerous configurable timing parameters.
The most important seems to be the cmd_time flag, which determines
the length of PCMCIA bus cycles. Fast 486 systems (i.e., DX4-100)
seem to often benefit from increasing this from 6 (the default) to
12 or 16.
· The Cirrus PD6729 PCI controller has the fast_pci flag, which
should be set if the PCI bus speed is greater than 25 MHz.
· For Vadem VG-468 controllers and Databook TCIC-2 controllers, the
async_clock flag changes the relative clocking of PCMCIA bus and
host bus cycles. Setting this flag adds extra wait states to some
operations. However, I have yet to hear of a laptop that needs
this.
· The pcmcia_core module has the cis_speed parameter for changing the
memory speed used for accessing a card's Card Information Structure
(CIS). On some systems with fast bus clocks, increasing this
parameter (i.e., slowing down card accesses) may be beneficial for
card recognition problems.
· This isn't a timing issue, but if you have more than one PCMCIA
controller in your system or extra sockets in a docking station,
the i82365 module should be loaded with the extra_sockets parameter
set to 1.
All these options should be configured by modifying the top of
/etc/rc.d/rc.pcmcia. For example:
# Should be either i82365 or tcic
PCIC=i82365
# Put socket driver timing parameters here
PCIC_OPTS="cmd_time=12"
# Put pcmcia_core options here
CORE_OPTS="cis_speed=500"
Here are some timing settings for specific systems:
· On the ARM Pentium-90 or Midwest Micro Soundbook Plus, use
``freq_bypass=1 cmd_time=8''.
· On a Midwest Micro Soundbook Elite, use ``cmd_time=12''.
· On a Gateway Liberty, try ``cmd_time=16''.
On some systems using Cirrus controllers, including the NEC Versa M,
the BIOS puts the controller in a special suspended state at system
startup time. On these systems, the probe command will fail to find
any known PCMCIA controller. If this happens, edit
/etc/rc.d/rc.pcmcia by hand as follows:
# Should be either i82365 or tcic
PCIC=i82365
# Put socket driver timing parameters here
PCIC_OPTS="wakeup=1"
2.6. Problems loading kernel modules
The configure script will normally ensure that the PCMCIA modules are
compatible with your kernel. So, module loading problems generally
indicate that the user has interfered with the normal installation
process in some way. Some module loading errors are sent directly to
the Linux console. Other errors are recorded in the system log file,
normally /usr/adm/messages or /var/log/messages. Depending on your
syslogd configuration, some messages may be written to other files,
but they will usually still be under /usr/adm or /var/log. To track
down a problem, be sure to check both locations, to pin down which
module is actually causing trouble.
Some of the PCMCIA modules require kernel services that may or may not
be present, depending on kernel configuration. For instance, the SCSI
card drivers require that the kernel be configured with SCSI support,
and the network drivers require a networking kernel. If a kernel
lacks a necessary feature, insmod may report undefined symbols and
refuse to load a module.
If insmod reports ``wrong version'' errors, it means that the module
was compiled for a different kernel version than your system is
actually running. This might occur if modules compiled on one machine
are copied to another machine with a different configuration, or if
the kernel is reconfigured after PCMCIA is installed.
Another source of module loading errors is when the modules and kernel
were compiled with different settings of CONFIG_MODVERSIONS. If a
module with version checking is loaded against a kernel without
version checking, insmod will complain about undefined symbols.
Finally, relatively recent binutils releases are incompatible with
older versions of the module utilities, and can cause module version
incompatibilities to be reported. The most common symptom is
complaints about ``gcc_compiled'' being undefined. If you get these
errors, upgrade to the latest module utilities, available from
<http://www.pi.se/blox/modules>.
2.7. Problems with the card status change interrupt
In most cases, the socket driver (i82365 or tcic) will automatically
probe and select an appropriate interrupt to signal card status
changes. The automatic interrupt probe doesn't work on some Intel-
compatible controllers, including Cirrus chips and the chips used in
some IBM ThinkPads. If a device is inactive at probe time, its
interrupt may also appear to be available. In these cases, the socket
driver may pick an interrupt that is used by another device.
With the i82365 and tcic drivers, the irq_list option can be used to
limit the interrupts that will be tested. This list limits the set of
interrupts that can be used by PCMCIA cards as well as for monitoring
card status changes. The cs_irq option can also be used to explicitly
set the interrupt to be used for monitoring card status changes.
If you can't find an interrupt number that works, there is also a
polled status mode: both i82365 and tcic will accept a
poll_interval=100 option, to poll for card status changes once per
second. This option should also be used if your system has a shortage
of interrupts available for use by PCMCIA cards. Especially for
systems with more than one PCMCIA controller, there is little point in
dedicating interrupts for monitoring card status changes.
All these options should be set in the PCIC_OPTS= line in either
/etc/rc.d/rc.pcmcia or /etc/sysconfig/pcmcia, depending on your site
setup.
2.8. Card identification problems
By default, the PCMCIA drivers allocate memory windows in the region
0xc0000-0xfffff, after probing this region for conflicts with ROM or
other devices. This memory window is specified in
/etc/pcmcia/config.opts. The probe is done when the drivers first
attempt to configure a new card. The probe procedure is not
foolproof, so it is possible for a conflict to go unrecognized. If an
address region that passes the probe is used by other devices in your
system, cards may not be identified correctly. With chipsets that
support it, conflicts can also result from BIOS shadowing in this
region.
The classic symptom of a memory window configuration problem is that
all cards will be misidentified as memory cards. In unusual cases, a
memory window conflict can interfere with a crucial system service,
resulting in lock-ups or reboots. If you suspect a memory window
problem, first verify that ROM shadowing is disabled in your system's
hardware setup. Finding a good window may require some
experimentation. Some alternative windows to try are 0xd0000-0xdffff,
0xc9000-0xcffff, and 0xd8000-0xdffff.
If you have DOS PCMCIA drivers, you may be able to deduce what memory
region those drivers use. Note that DOS memory addresses are often
specified in ``segment'' form, which leaves off the final hex digit
(so an absolute address of 0xd0000 would be given as 0xd000). Be sure
to add the extra digit back when making changes to
/etc/pcmcia/config.opts.
If adjusting the memory window fails to solve a card identification
problem, then it is likely to be due to a timing problem.
2.9. Why don't you distribute PCMCIA binaries?
For me, distributing binaries is a significant hassle. It is
complicated because some features can only be selected at compile
time, and because the PCMCIA modules are somewhat dependent on having
the ``right'' kernel configuration. So, I would probably need to
distribute precompiled modules along with matching kernels. Beyond
this, the greatest need for precompiled modules is when installing
Linux on a clean system. This typically requires setting up PCMCIA so
that it can be used in the installation process for a particular Linux
distribution. Each Linux distribution has its own procedures, and it
is not feasible for me to provide boot and root disks for even just
the common combinations of drivers and distributions.
PCMCIA is now a part of many of the major Linux distributions,
including Red Hat, Caldera, Slackware, Yggdrasil, Craftworks, and
Nascent Technology.
2.10. Why is the PCMCIA package so darned big?
Well, first of all, it isn't actually that large. All the driver
modules together take up about 200K of disk space. The utility
programs add up to about 70K, and the stuff in /etc/pcmcia is about
30K. When running, the core PCMCIA modules take up 48K of system
memory. The cardmgr daemon will generally be swapped out except when
cards are inserted or removed. The total package size is not much
different from DOS Card Services implementations.
Compared to DOS ``point enablers'', this may still seem like a lot of
overhead, especially for people that don't plan on using many of the
features of PCMCIA, such as power management or hot swapping. Point
enablers can be tiny because they generally support only one or a
small set of cards, and also generally support a restricted set of
PCMCIA controllers. If someone were to write a genuinely ``generic''
modem enabler, it would end up incorporating much of the functionality
of Card Services, to handle cards from different vendors and the full
range of PCMCIA controller variants.
3. Usage and features
3.1. Tools for monitoring PCMCIA devices
The cardmgr daemon normally beeps when a card is inserted, and the
tone of the beeps indicates the status of the newly inserted card.
Two high beeps indicate the card was identified and configured
successfully. A high beep followed by a lower beep indicates that the
card was identified, but could not be configured for some reason. One
low beep indicates that the card could not be identified.
If the modules are all loaded correctly, the output of the lsmod
command should look like the following, with no cards inserted:
Module: #pages: Used by:
ds 2
i82365 3
pcmcia_core 7 [ds i82365]
All the PCMCIA modules and the cardmgr daemon send status messages to
the system log. This will usually be /var/log/messages or
/usr/adm/messages. This file should be the first place to look when
tracking down a problem. When submitting a bug report, always include
the contents of this file. If you are having trouble finding your
system messages, check /etc/syslogd.conf to see how different classes
of messages are handled.
Cardmgr also records some current device information for each socket
in /var/run/stab. Here is a sample /var/run/stab listing:
Socket 0: Adaptec APA-1460 SlimSCSI
0 scsi aha152x_cs 0 sda 8 0
0 scsi aha152x_cs 1 scd0 11 0
Socket 1: Serial or Modem Card
1 serial serial_cs 0 ttyS1 5 65
For the lines describing devices, the first field is the socket, the
second is the device class, the third is the driver name, the fourth
is used to number multiple devices associated with the same driver,
the fifth is the device name, and the final two fields are the major
and minor device numbers for this device (if applicable).
The cardctl command can be used to check the status of a socket, or to
see how it is configured. Here is an example of the output of the
``cardctl config'' command:
Socket 0:
Socket 1:
Vcc = 5.0, Vpp1 = 0.0, Vpp2 = 0.0
Card type is memory and I/O
IRQ 3 is dynamic shared, level mode, enabled
Speaker output is enabled
Function 0:
Config register base = 0x0800
Option = 0x63, status = 0x08
I/O window 1: 0x0280 to 0x02bf, auto sized
I/O window 2: 0x02f8 to 0x02ff, 8 bit
If you are running X, the cardinfo utility produces a graphical
display showing the current status of all PCMCIA sockets, similar in
content to ``cardctl config''.
3.2. Overview of the PCMCIA configuration scripts
Each PCMCIA device has an associated ``class'' that describes how it
should be configured and managed. Classes are associated with device
drivers in /etc/pcmcia/config. There are currently five IO device
classes (network, SCSI, cdrom, fixed disk, and serial) and two memory
device classes (memory and FTL). For each class, there are two
scripts in /etc/pcmcia/config: a main configuration script (i.e.,
/etc/pcmcia/scsi for SCSI devices), and an options script (i.e.,
/etc/pcmcia/scsi.opts). The main script for a device will be invoked
to configure that device when a card is inserted, and to shut down the
device when the card is removed. For cards with several associated
devices, the script will be invoked for each device.
The config scripts start by extracting some information about a device
from /var/run/stab. Each script constructs a ``device address'', that
uniquely describes the device it has been asked to configure, in the
ADDRESS variable. This is passed to the *.opts script, which should
return information about how a device at this address should be
configured. For some devices, the device address is just the socket
number. For others, it includes extra information that may be useful
in deciding how to configure the device. For example, network devices
pass their hardware ethernet address as part of the device address, so
the network.opts script could use this to select from several
different configurations.
The first part of all device addresses is the current PCMCIA
``scheme''. This parameter is used to support multiple sets of device
configurations based on a single external user-specified variable.
One use of schemes would be to have a ``home'' scheme, and a ``work''
scheme, which would include different sets of network configuration
parameters. The current scheme is selected using the cardctl command.
The default if no scheme is set is ``default''.
As a general rule, when configuring Linux for a laptop, PCMCIA devices
should only be configured from the PCMCIA device scripts. Do not try
to configure a PCMCIA device the same way you would configure a
permanently attached device.
3.3. PCMCIA network adapters
Linux ethernet-type network interfaces normally have names like eth0,
eth1, and so on. Token-ring adapters are handled similarly, however
they are named tr0, tr1, and so on. The ifconfig command is used to
view or modify the state of a network interface. A peculiarity of
Linux is that network interfaces do not have corresponding device
files under /dev, so don't be surprised when you can't find them.
When a PCMCIA ethernet card is detected, it will be assigned the first
free interface name, which will probably be eth0. Cardmgr will run
the /etc/pcmcia/network script to configure the interface.
Do not configure your PCMCIA ethernet card in /etc/rc.d/rc.inet1,
since the card may not be present when this script is executed.
Comment out everything except the loopback stuff in rc.inet1. If your
system has an automatic network configuration procedure, you should
generally indicate that you do not have a network card installed.
Instead, edit the /etc/pcmcia/network.opts file to match your local
network setup. The network and network.opts scripts will be executed
only when your ethernet card is actually present.
The device address passed to network.opts consists of four comma-
separated fields: the scheme, the socket number, the device instance,
and the card's hardware ethernet address. The device instance is used
to number devices for cards that have several network interfaces, so
it will usually be 0. If you have several network cards used for
different purposes, one option would be to configure the cards based
on socket position, as in:
case "$ADDRESS" in
*,0,*,*)
# definitions for network card in socket 0
;;
*,1,*,*)
# definitions for network card in socket 1
;;
esac
Alternatively, they could be configured using their hardware
addresses, as in:
case "$ADDRESS" in
*,*,*,00:80:C8:76:00:B1)
# definitions for a D-Link card
;;
*,*,*,08:00:5A:44:80:01)
# definitions for an IBM card
esac
To automatically mount and unmount NFS filesystems, first add all
these filesystems to /etc/fstab, but include noauto in the mount
options. In network.opts, list the filesystem mount points in the
MOUNTS variable. It is especially important to use either cardctl or
cardinfo to shut down a network card when NFS mounts are configured
this way. It is not possible to cleanly unmount NFS filesystems if a
network card is simply ejected without warning.
In addition to the usual network configuration parameters, the
network.opts script can specify extra actions to be taken after an
interface is configured, or before an interface is shut down. If
network.opts defines a shell function called start_fn, it will be
invoked by the network script after the interface is configured, and
the interface name will be passed to the function as its first (and
only) argument. Similarly, if it is defined, stop_fn will be invoked
before shutting down an interface.
3.3.1. Transceiver selection
The transceiver type can be selected in network.opts using the IF_PORT
setting. This can either be a numeric value as in previous PCMCIA
releases, or a keyword identifying the transceiver type. All the
network drivers default to either autodetect the interface if
possible, or 10baseT otherwise. The ifport command can be used to
check or set the current transceiver type. For example:
# ifport eth0 10base2
#
# ifport eth0
eth0 2 (10base2)
Current releases of the 3c589 driver attempt to autodetect the network
connection, but this doesn't seem to be completely functional yet.
For autodetection to work, the network cable should be connected to
the card when the card is configured. Alternatively, once the network
is connected, you can force the driver to check the connection with:
ifconfig eth0 down up
3.3.2. Comments about specific cards
· With IBM CCAE and Socket EA cards, you need to pick the transceiver
type (10base2, 10baseT, AUI) when the network device is configured.
Make sure that the transceiver type reported in the system log
matches your connection.
· The drivers for SMC, Megahertz, Ositech, and 3Com cards should
autodetect the attached network type (10base2 or 10baseT). Setting
the transceiver type when the driver is loaded serves to define the
card's ``first guess''.
· The Farallon EtherWave is actually based on the 3Com 3c589, with a
special transceiver. Though the EtherWave uses 10baseT-style
connections, its transceiver requires that the 3c589 be configured
in 10base2 mode.
· If you have trouble with an IBM CCAE, NE4100, Thomas Conrad, or
Kingston adapter, try increasing the memory access time with the
mem_speed=# option to the pcnet_cs module. An example of how to do
this is given in the standard config.opts file. Try speeds of up
to 1000 (in nanoseconds).
· For the New Media Ethernet adapter, on some systems, it may be
necessary to increase the IO port access time with the io_speed=#
option when the pcmcia_core module is loaded. Edit CORE_OPTS in
the startup script to set this option.
· The multicast support in the New Media Ethernet driver is
incomplete. The latest driver will function with multicast
kernels, but will ignore multicast packets. Promiscuous mode
should work properly.
· The driver used by the IBM and 3Com token ring adapters seems to
behave very badly if the cards are not connected to a ring when
they get initialized. Always connect these cards to the net before
they are powered up. This driver also requires free IO ports in
the range of 0xa20-0xa27. On some systems, the automatic IO port
conflict checker will incorrectly determine that this port range is
unavailable. In that case, the port check can be disabled by
loading the pcmcia_core module with probe_io=0.
· Newer Linksys and D-Link cards have a unique way of selecting the
transceiver type that isn't handled by the Linux drivers. One
workaround is to boot DOS and use the vendor-supplied utility to
select the transceiver, then warm boot Linux. I am looking for
beta testers for a Linux utility to perform this function.
· For WaveLAN wireless network adapters, Jean Tourrilhes
(jt@hplb.hpl.hp.com) has put together a wireless HOWTO at
http://www-uk.hpl.hp.com/people/jt/Linux/Wavelan.html.
3.3.3. Diagnosing problems with network adapters
· Is your card recognized as an ethernet card? Check the system log
and make sure that cardmgr identifies the card correctly and starts
up one of the network drivers. If it doesn't, your card might
still be usable if it is compatible with a supported card. This
will be most easily done if the card claims to be ``NE2000
compatible''.
· Is the card configured properly? If you are using a supported
card, and it was recognized by cardmgr, but still doesn't work,
there might be an interrupt or port conflict with another device.
Find out what resources the card is using (from the system log),
and try excluding these in /etc/pcmcia/config.opts to force the
card to use something different.
· If your card seems to be configured properly, but sometimes locks
up, particularly under high load, you may need to try changing your
socket driver timing parameters. See section ``2.3'' for more
information.
· If you get messages like ``network unreachable'' when you try to
access the network, then you have probably set up
/etc/pcmcia/network.opts incorrectly. On the other hand, mis-
configured cards will usually fail silently.
· To diagnose problems in /etc/pcmcia/network.opts, start by trying
to ping other systems on the same subnet using their IP addresses.
Then try to ping your gateway, and then machines on other subnets.
Ping machines by name only after trying these simpler tests.
· Make sure your problem is really a PCMCIA one. It may help to see
see if the card works under DOS with the vendor's drivers. Double
check your modifications to the /etc/pcmcia/network.opts script.
Make sure your drop cable, ``T'' jack, terminator, etc are working.
3.4. PCMCIA serial and modem devices
Linux serial devices are accessed via the /dev/cua* and /dev/ttyS*
special device files. The ttyS* devices are for incoming connections,
such as directly connected terminals. The cua* devices are for
outgoing connections, such as modems. Each physical serial port has
both a ttyS and a cua device file: it is up to you to pick the
appropriate device for your application. The configuration of a
serial device can be examined and modified with the setserial command.
When a PCMCIA serial or modem card is detected, it will be assigned to
the first available serial device slot. This will usually be
/dev/ttyS1 (cua1) or /dev/ttyS2 (cua2), depending on the number of
built-in serial ports. The ttyS* device is the one reported in
/var/run/stab. The default serial device option script,
/etc/pcmcia/serial.opts, will link the corresponding cua* device file
to /dev/modem as a convenience.
Do not try to use /etc/rc.d/rc.serial to configure a PCMCIA modem.
This script should only be used to configure non-removable devices.
Modify /etc/pcmcia/serial.opts if you want to do anything special to
set up your modem. Also, do not try to change the IO port and
interrupt settings of a PCMCIA serial device using setserial. This
would tell the serial driver to look for the device in a different
place, but would not change how the card hardware is actually
configured. The serial configuration script allows you to specify
other setserial options, as well as whether a line should be added to
/etc/inittab for this port.
The device address passed to serial.opts has three comma-separated
fields: the first is the scheme, the second is the socket number, and
the third is the device instance. The device instance may take
several values for cards that support multiple serial ports, but for
single-port cards, it will always be 0. If you commonly use more than
one PCMCIA modem, you may want to specify different settings based on
socket position, as in:
case "$ADDRESS" in
*,0,*)
# Options for modem in socket 0
LINK=/dev/modem0
;;
*,1,*)
# Options for modem in socket 1
LINK=/dev/modem1
;;
esac
If a PCMCIA modem is already configured when Linux boots, it may be
incorrectly identified as an ordinary built-in serial port. This is
harmless, however, when the PCMCIA drivers take control of the modem,
it will be assigned a different device slot. It is best to either
parse /var/run/stab or use /dev/modem, rather than expecting a PCMCIA
modem to always have the same device assignment.
If you configure your kernel to load the basic Linux serial port
driver as a module, you must edit /etc/pcmcia/config to indicate that
this module must be loaded. Edit the serial device entry to read:
device "serial_cs"
class "serial" module "char/serial", "serial_cs"
3.4.1. Diagnosing problems with serial devices
· Is your card recognized as a modem? Check the system log and make
sure that cardmgr identifies the card correctly and starts up the
serial_cs driver. If it doesn't, you may need to add a new entry
to your /etc/pcmcia/config file so that it will be identified
properly. See section ``3.6'' for details.
· Is the modem configured successfully by serial_cs? Again, check
the system log and look for messages from the serial_cs driver. If
you see ``register_serial() failed'', you may have an I/O port
conflict with another device. Another tip-off of a conflict is if
the device is reported to be an 8250; most modern PCMCIA modems
should be identified as 16550A UART's. If you think you're seeing
a port conflict, edit /etc/pcmcia/config.opts and exclude the port
range that was allocated for the modem.
· Is there an interrupt conflict? If the system log looks good, but
the modem just doesn't seem to work, try using setserial to change
the irq to 0, and see if the modem works. This causes the serial
driver to use a slower polled mode instead of using interrupts. If
this seems to fix the problem, it is likely that some other device
in your system is using the interrupt selected by serial_cs. You
should add a line to /etc/pcmcia/config.opts to exclude this
interrupt.
· If the modem seems to work only very, very slowly, this is an
almost certain indicator of an interrupt conflict.
· Make sure your problem is really a PCMCIA one. It may help to see
if the card works under DOS with the vendor's drivers. Also, don't
test the card with something complex like SLIP or PPP until you are
sure you can make simple connections. If simple things work but
SLIP does not, your problem is most likely with SLIP, not with
PCMCIA.
· If you get kernel messages indicating that the serial_cs module
cannot be loaded, it means that your kernel does not have serial
device support. If you have compiled the serial driver as a
module, you must modify /etc/pcmcia/config to indicate that the
serial module should be loaded before serial_cs.
3.5. PCMCIA SCSI adapters
All the currently supported PCMCIA SCSI cards are work-alikes of one
of the following ISA bus cards: the Qlogic, the Adaptec AHA-152X, or
the Future Domain TMC-16x0. The PCMCIA drivers are built by linking
some PCMCIA-specific code (in qlogic_cs.c, toaster_cs.c, or
fdomain_cs.c) with the normal Linux SCSI driver.
When a new SCSI host adapter is detected, the SCSI drivers will probe
for devices. Check the system log to make sure your devices are
detected properly. New SCSI devices will be assigned to the first
available SCSI device files. The first SCSI disk will be /dev/sda,
the first SCSI tape will be /dev/st0, and the first CD-ROM will be
/dev/scd0.
With 1.3.X and later kernels, the PCMCIA core drivers are able to find
out from the kernel which SCSI devices are connected to a card. They
will be listed in /var/run/stab, and the SCSI configuration script,
/etc/pcmcia/scsi, will be called once for each attached device, to
either configure or shut down that device. The default script does
not take any actions to configure SCSI devices, but will properly
unmount filesystems on SCSI devices when a card is removed.
With 1.2.X kernels, th
