Previous Next Contents

4. Usage and features

4.1 Tools for configuring and monitoring PCMCIA devices

If the modules are all loaded correctly, the output of the lsmod command should look like the following, when no cards are inserted:

Module                  Size  Used by
ds                      5640   2 
i82365                 15452   2 
pcmcia_core            30012   3  [ds i82365]

The system log should also include output from the socket driver describing the host controller(s) found and the number of sockets detected.

The cardmgr configuration daemon

The cardmgr daemon is responsible for monitoring PCMCIA sockets, loading client drivers when needed, and running user-level scripts in response to card insertions and removals. It records its actions in the system log, but also uses beeps to signal card status changes. The tones of the beeps indicate success or failure of particular configuration steps. Two high beeps indicate that a card was identified and configured successfully. A high beep followed by a low beep indicates that a card was identified, but could not be configured for some reason. One low beep indicates that a card could not be identified.

Cardmgr records 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 cardmgr daemon configures cards based on a database of known card types kept in /etc/pcmcia/config. This file describes the various client drivers, then describes how to identify various cards, and which driver(s) belong with which cards. The format of this file is described in the pcmcia(5) man page.

The cardctl and cardinfo utilities

The cardctl command can be used to check the status of a socket, or to see how it is configured. It can also be used to alter the configuration status of a card. 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

The ``cardctl suspend'' and ``cardctl resume'' commands can be used to shut down a card without unloading its associated drivers. The ``cardctl reset'' command attempts to reset and reconfigure a card. ``cardctl insert'' and ``cardctl eject'' mimic the actions performed when a card is physically inserted or ejected, including loading or unloading drivers, and configuring or shutting down devices.

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''. It also provides a graphical interface to most other cardctl functions.

Inserting and ejecting cards

In theory, you can insert and remove PCMCIA cards at any time. However, it is a good idea not to eject a card that is currently being used by an application program. Kernels older than 1.1.77 would often lock up when serial/modem cards were ejected, but this should be fixed now.

Card Services and Advanced Power Management

Card Services can be compiled with support for APM (Advanced Power Management) if you've installed this package on your system. APM is incorporated into 1.3.46 and later kernels. It is currently being maintained by Rick Faith (, and APM tools can be obtained from The PCMCIA modules will automatically be configured for APM if a compatible version is detected on your system.

Without resorting to APM, you can do ``cardctl suspend'' before suspending your laptop, and ``cardctl resume'' after resuming, to properly shut down and restart your PCMCIA cards. This will not work with a PCMCIA modem that is in use, because the serial driver isn't able to save and restore the modem operating parameters.

APM seems to be unstable on some systems. If you experience trouble with APM and PCMCIA on your system, try to narrow down the problem to one package or the other before reporting a bug.

Some drivers, notably the PCMCIA SCSI drivers, cannot recover from a suspend/resume cycle. When using a PCMCIA SCSI card, use ``cardctl eject'' prior to suspending the system.

Shutting down the PCMCIA system

To unload the entire PCMCIA package, invoke rc.pcmcia with:

/etc/rc.d/rc.pcmcia stop

This script will take several seconds to run, to give all client drivers time to shut down gracefully. If a PCMCIA device is currently in use, the shutdown will be incomplete, and some kernel modules may not be unloaded. To avoid this, use ``cardctl eject'' to shut down all sockets before invoking rc.pcmcia. The exit status of the cardctl command will indicate if any sockets could not be shut down.

4.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 shell 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 scheme'' 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. However, some Linux distributions provide PCMCIA packages that are hooked into those distributions' own device configuration tools. In that case, some of the following sections may not apply; ideally, this will be documented in the distribution.

4.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 do not be surprised when you do not 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. 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. If your system has an automatic network configuration procedure, it may or may not be PCMCIA-aware. Consult the documentation of your Linux distribution to determine if PCMCIA network devices should be configured with the automatic tools, or by editing network.opts.

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
    # definitions for network card in socket 0
    # definitions for network card in socket 1

Alternatively, they could be configured using their hardware addresses, as in:

case "$ADDRESS" in
    # definitions for a D-Link card
    # definitions for an IBM card

Network device parameters

The following parameters can be defined in network.opts:


Specifies the ethernet transceiver type, for cards that do not autodetect. See ``man ifport'' for transceiver names.


A boolean (y/n) value: indicates if the host's IP address and routing information should be obtained using the BOOTP protocol.


The IP address for this interface.


Basic network parameters: see the networking HOWTO for more information.


The IP address of a gateway for this host's subnet. Packets with destinations outside this subnet will be routed to this gateway.


The network domain name for this host, to be used in creating /etc/resolv.conf.

DNS_1, DNS_2, DNS_3

Host names or IP addresses for nameservers for this interface, to be added to /etc/resolv.conf


A list of NFS mount points to be mounted for this interface.


For IPX networks: the frame type and network number, passed to the ipx_interface command.

For example:

case "$ADDRESS" in

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.

The transceiver type can be selected 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

Comments about specific cards

Diagnosing problems with network adapters

4.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
    # Options for modem in socket 0
    # Options for modem in socket 1

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 "misc/serial", "serial_cs"

Serial device parameters

The following parameters can be defined in serial.opts:


Specifies a path for a symbolic link to be created to the ``dialout'' or /dev/cua* device.


Specifies options to be passed to the setserial command.


If specified, this will be used to construct an inittab entry for the device.

For example:

case "$ADDRESS" in

Diagnosing problems with serial devices

4.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, the PCMCIA drivers cannot automatically deduce which devices are associated with a particular SCSI adapter. Instead, if you have one normal SCSI device configuration, you may list these devices in /etc/pcmcia/scsi.opts. For example, if you normally have a SCSI disk and a CD-ROM, you would use:

# For 1.2 kernels: list of attached devices
SCSI_DEVICES="sda scd0"

The device addresses passed to scsi.opts are complicated, because of the variety of things that can be attached to a SCSI adapter. Addresses consist of either six or seven comma-separated fields: the current scheme, the device type, the socket number, the SCSI channel, ID, and logical unit number, and optionally, the partition number. The device type will be ``sd'' for disks, ``st'' for tapes, ``sr'' for CD-ROM devices, and ``sg'' for generic SCSI devices. For most setups, the SCSI channel and logical unit number will be 0. For disk devices with several partitions, scsi.opts will first be called for the whole device, with a five-field address. The script should set the PARTS variable to a list of partitions. Then, scsi.opts will be called for each partition, with the longer seven-field addresses.

If your kernel does not have a top-level driver (disk, tape, etc) for a particular SCSI device, then the device will not be configured by the PCMCIA drivers. As a side effect, the device's name in /var/run/stab will be something like ``sd#nnnn'' where ``nnnn'' is a four-digit hex number. This happens when cardmgr is unable to translate a SCSI device ID into a corresponding Linux device name.

It is possible to modularize the top-level SCSI drivers so that they are only loaded when a PCMCIA SCSI adapter is detected. To do so, you need to edit /etc/pcmcia/config to tell cardmgr which extra modules need to be loaded when your adapter is configured. For example:

device "aha152x_cs"
  class "scsi" module "scsi/scsi_mod", "scsi/sd_mod", "aha152x_cs"

would say to load the core SCSI module and the top-level disk driver module before loading the regular PCMCIA driver module. The PCMCIA Configure script will not automatically detect modularized SCSI modules, so you will need use the manual configure option to enable SCSI support.

Always turn on SCSI devices before powering up your laptop, or before inserting the adapter card, so that the SCSI bus is properly terminated when the adapter is configured. Also be very careful about ejecting a SCSI adapter. Be sure that all associated SCSI devices are unmounted and closed before ejecting the card. The best way to ensure this is to use either cardctl or cardinfo to request card removal before physically ejecting the card. For now, all SCSI devices should be powered up before plugging in a SCSI adapter, and should stay connected until after you unplug the adapter and/or power down your laptop.

There is a potential complication when using these cards that does not arise with ordinary ISA bus adapters. The SCSI bus carries a ``termination power'' signal that is necessary for proper operation of ordinary passive SCSI terminators. PCMCIA SCSI adapters do not supply termination power, so if it is required, an external device must supply it. Some external SCSI devices may be configured to supply termination power. Others, such as the Zip Drive and the Syquest EZ-Drive, use active terminators that do not depend on it. In some cases, it may be necessary to use a special terminator block such as the APS SCSI Sentry 2, which has an external power supply. When configuring your SCSI device chain, be aware of whether or not any of your devices require or can provide termination power.

The Adaptec APA-460 SlimSCSI adapter is not supported. This card was originally sold under the Trantor name, and when Adaptec merged with Trantor, they continued to sell the Trantor card with an Adaptec label. The APA-460 is not compatible with any existing Linux driver. I'm not sure how hard it would be to write a driver; I don't think anyone has been able to obtain the technical information from Adaptec.

The (unsupported) Trantor SlimSCSI can be identified by the following:

Trantor / Adaptec APA-460 SlimSCSI
Shipped with SCSIworks! driver software

The (supported) Adaptec SlimSCSI can be identified by the following:

Adaptec APA-1460 SlimSCSI
P/N: 900100
Shipped with EZ-SCSI driver software

SCSI device parameters

The following parameters can be defined in scsi.opts:


A boolean (y/n) setting: specifies if an entry should be added to /etc/fstab for this device.


A boolean (y/n) setting: specifies if the filesystem should be checked before being mounted, with ``fsck -Ta''.


A boolean (y/n) setting: specifies if this device should be automatically mounted at card insertion time.


The filesystem type, mount options, and mount point to be used for the fstab entry and/or mounting the device.

For example, here is a script for configuring a disk device at SCSI ID 3, with two partitions, and a CD-ROM at SCSI ID 6:

case "$ADDRESS" in
    # This device has two partitions...
    PARTS="1 2"
    # Options for partition 1:
    #  update /etc/fstab, and mount an ext2 fs on /usr1
    DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
    # Options for partition 2:
    #  update /etc/fstab, and mount an MS-DOS fs on /usr2
    DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
    # Options for CD-ROM at SCSI ID 6
    DO_FSTAB="y" ; DO_FSCK="n" ; DO_MOUNT="y"

Diagnosing problems with SCSI adapters

4.6 PCMCIA memory cards

The memory_cs driver handles all types of memory cards, as well as providing direct access to the PCMCIA memory address space for cards that have other functions. When loaded, it creates a combination of character and block devices. See the man page for the module for a complete description of the device naming scheme. Block devices are used for disk-like access (creating and mounting filesystems, etc). The character devices are for "raw" unbuffered reads and writes at arbitrary locations.

The device address passed to memory.opts consists of two fields: the scheme, and the socket number. The options are applied to the first common memory partition on the corresponding memory card.

Some older memory cards, and most simple static RAM cards, lack a ``Card Information Structure'' (CIS), which is the scheme PCMCIA cards use to identify themselves. Normally, cardmgr will assume that any card that lacks a CIS is a simple memory card, and load the memory_cs driver. Thus, a common side effect of a general card identification problem is that other types of cards may be misdetected as memory cards.

The memory_cs driver uses a heuristic to guess the capacity of these cards. The heuristic does not work for write protected cards, and may make mistakes in some other cases as well. If a card is misdetected, its size should then be explicitly specified when using commands such as dd or mkfs.

Memory device parameters

The following parameters can be specified in memory.opts:


A boolean (y/n) setting: specifies if an entry should be added to /etc/fstab for this device.


A boolean (y/n) setting: specifies if the filesystem should be checked before being mounted, with ``fsck -Ta''.


A boolean (y/n) setting: specifies if this device should be automatically mounted at card insertion time.


The filesystem type, mount options, and mount point to be used for the fstab entry and/or mounting the device.

Here is an example of a script that will automatically mount memory cards based on which socket they are inserted into:

case "$ADDRESS" in
    # Mount filesystem, but don't update /etc/fstab
    DO_FSTAB="n" ; DO_FSCK="y" ; DO_MOUNT="y"
    FSTYPE="ext2" ; OPTS=""
    # Mount filesystem, but don't update /etc/fstab
    DO_FSTAB="n" ; DO_FSCK="y" ; DO_MOUNT="y"
    FSTYPE="ext2" ; OPTS=""

Using flash memory cards

The device address passed to ftl.opts consists of three or four fields: the scheme, the socket number, the region number, and optionally, the partition number. Most flash cards have just one flash memory region, so the region number will generally always be zero.

To use a flash memory card as an ordinary disk-like block device, first create an FTL, or ``flash translation layer'', partition on the device with the ftl_format command. This layer hides the device-specific details of flash memory programming and make the card look like a simple block device. For example:

ftl_format -i /dev/mem0c0c

Note that this command accesses the card through the ``raw'' memory card interface. Once formatted, the card can be accessed as an ordinary block device via the ftl_cs driver. For example:

mke2fs /dev/ftl0c0
mount -t ext2 /dev/ftl0c0 /mnt

Device naming for FTL devices is tricky. Minor device numbers have three parts: the card number, the region number on that card, and optionally, the partition within that region. A region can either be treated as a single block device with no partition table (like a floppy), or it can be partitioned like a hard disk device. The ``ftl0c0'' device is card 0, common memory region 0, the entire region. The ``ftl0c0p1'' through ``ftl0c0p4'' devices are primary partitions 1 through 4 if the region has been partitioned.

There are two major formats for flash memory cards: the FTL style, and the Microsoft Flash File System. The FTL format is generally more flexible because it allows any ordinary high-level filesystem (ext2, ms-dos, etc) to be used on a flash card as if it were an ordinary disk device. The FFS is a completely different filesystem type. Linux cannot currently handle cards formated with FFS.

4.7 PCMCIA ATA/IDE card drives

ATA/IDE drive support requires a 1.3.72 or higher kernel. The PCMCIA-specific part of the driver is fixed_cs. Be sure to use cardctl or cardinfo to shut down an ATA/IDE card before ejecting it, as the driver has not been made ``hot-swap-proof''.

The device addresses passed to fixed.opts consist of either three or four fields: the current scheme, the socket number, the drive's serial number, and an optional partition number. The ide_info can be used to obtain an IDE device's serial number. As with SCSI devices, fixed.opts is first called for the entire device. If fixed.opts returns a list of partitions in the PARTS variable, the script will then be called for each partition.

ATA/IDE fixed-disk device parameters

The following parameters can be specified in fixed.opts:


A boolean (y/n) setting: specifies if an entry should be added to /etc/fstab for this device.


A boolean (y/n) setting: specifies if the filesystem should be checked before being mounted, with ``fsck -Ta''.


A boolean (y/n) setting: specifies if this device should be automatically mounted at card insertion time.


The filesystem type, mount options, and mount point to be used for the fstab entry and/or mounting the device.

Here is an example fixed.opts file to mount the first partition of any ATA/IDE card on /mnt.

case "$ADDRESS" in
    DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"

Diagnosing problems with ATA/IDE adapters

4.8 Multifunction cards

Starting with the 1.3.73 Linux kernel, a single interrupt can be shared by several drivers, such as the serial driver and an ethernet driver. When using a multifunction card under a newer kernel, all card functions can be used without loading and unloading drivers.

Simultaneous use of two card functions is ``tricky'' and various hardware vendors have implemented interrupt sharing in their own incompatible (and sometimes proprietary) ways. The drivers for some cards (Ositech Jack of Diamonds, 3Com 3c562, Linksys) properly support simultaneous access, but others (Megahertz in particular) do not.

Earlier kernels do not support interrupt sharing between different device drivers, so it is not possible for the PCMCIA drivers to configure this card for simultaneous ethernet and modem access. The ethernet and serial drivers are both loaded automatically. However, the ethernet driver ``owns'' the card interrupt by default. To use the modem, you can unload the ethernet driver and reconfigure the serial port by doing something like:

ifconfig eth0 down
rmmod 3c589_cs
setserial /dev/modem autoconfig auto_irq
setserial /dev/modem

The second setserial should verify that the port has been configured to use the interrupt previously used by the ethernet driver.

Previous Next Contents