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 you are running X, the new cardinfo utility produces a slick
graphical display showing the current status of all PCMCIA sockets.
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. 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 cua1 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.
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
three memory device classes (FTL, memory, and pcmem). 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.
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 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 three
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.
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. 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/cua1 or /dev/cua2, depending on the number of
built-in serial ports. The default serial device option script,
/etc/pcmcia/serial.opts, will link the appropriate 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.
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
;;
*,1,*)
# Options for modem in socket 1
;;
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"
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 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. 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
*,sd,*,0,3,0)
# This device has two partitions...
PARTS="1 2"
;;
*,sd,*,0,3,0,1)
# Options for partition 1:
# update /etc/fstab, and mount an ext2 fs on /usr1
DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
FSTYPE="ext2"
OPTS=""
MOUNTPT="/usr1"
;;
*,sd,*,0,3,0,2)
# Options for partition 2:
# update /etc/fstab, and mount an MS-DOS fs on /usr2
DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
FSTYPE="msdos"
OPTS=""
MOUNTPT="/usr2"
;;
*,sr,*,0,6,0)
# Options for CD-ROM at SCSI ID 6
PARTS=""
DO_FSTAB="y" ; DO_FSCK="n" ; DO_MOUNT="y"
FSTYPE="iso9660"
OPTS="ro"
MOUNTPT="/cdrom"
;;
esac
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.
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
FCC ID: IE8T460
Shipped with SCSIworks! driver software
The (supported) Adaptec SlimSCSI can be identified by the following:
Adaptec APA-1460 SlimSCSI
FCC ID: FGT1460
P/N: 900100
Shipped with EZ-SCSI driver software
The default memory card startup script will create block and character
devices for accessing each partition on a memory card. There are two
memory card drivers... pcmem_cs, the older driver, works well for
simple static RAM cards. The newer driver, memory_cs, is mostly
for direct access to flash memory cards. Check the man pages for a
detailed description of how devices are named. Both block and
character devices are created. The block device is used for disk-like
access (creating and mounting filesystems, etc). The character device
is for "raw" reads and writes at arbitrary locations.
To use a flash memory card as an ordinary disk-like block device,
first create a ``flash translation layer'' partition on the device
with the ftl_format command:
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/ftl0
mount -t ext2 /dev/ftl0 /mnt
With the FTL and ``new'' memory drivers, the device address passed to
ftl.opts and memory.opts consists of two fields: the socket
number, and the partition number. Common memory partitions are
numbered before attribute memory partitions. Generally, the only
interesting partition is partition 0 (the main common-memory
partition, where data is stored). Here is an example of a script that
will automatically mount flash memory cards based on which socket they
are inserted into:
case "$ADDRESS" in
*,0,0)
# Mount filesystem, but don't update /etc/fstab
DO_FSTAB="n" ; DO_FSCK="y" ; DO_MOUNT="y"
FSTYPE="ext2" ; OPTS=""
MOUNTPT="/ftl0"
;;
*,1,0)
# Mount filesystem, but don't update /etc/fstab
DO_FSTAB="n" ; DO_FSCK="y" ; DO_MOUNT="y"
FSTYPE="ext2" ; OPTS=""
MOUNTPT="/ftl1"
;;
esac
There are two major formats for flash memory cards: the ``flash translation layer'' 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 complete new filesystem type. Linux cannot currently handle cards formated with FFS.
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. 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.
Here is an example fixed.opts file to mount the first partition
of any ATA/IDE card on /mnt.
case "$ADDRESS" in
*,*,*)
PARTS="1"
;;
*,*,*,1)
DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
FSTYPE="msdos"
OPTS=""
MOUNTPT="/mnt"
;;
esac
If you wish, you can have separate configurations for specific cards
based on their serial numbers. To find out a drive's serial number,
use the ide_info utility. Then, part of fixed.opts might
look like:
case "$ADDRESS" in
*,*,Z4J60542)
# This is my DOS stuff
PARTS="1"
;;
*,*,Z4J60542,1)
DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
FSTYPE="msdos"
OPTS=""
MOUNTPT="/mnt"
;;
esac
cardmgr how to identify a new card? Assuming that your card is supported by an existing driver, all
that needs to be done is to add an entry to
/etc/pcmcia/config to tell cardmgr how to identify the card,
and which driver(s) need to be linked up to this card. Check the man
page for pcmcia for more information about the config file format.
If you insert an unknown card, cardmgr will normally record some
identification information in the system log that can be
used to construct the config entry.
Here is an example of how cardmgr will report an unsupported card in
/usr/adm/messages.
cardmgr[460]: unsupported card in socket 1
cardmgr[460]: version info: "MEGAHERTZ", "XJ2288", "V.34 PCMCIA MODEM"
The corresponding entry in /etc/pcmcia/config would be:
card "Megahertz XJ2288 V.34 Fax Modem"
version "MEGAHERTZ", "XJ2288", "V.34 PCMCIA MODEM"
bind "serial_cs"
You can use ``*'' to match strings that don't need to match exactly, like version numbers. When making new config entries, be careful to copy the strings exactly, preserving case and blank spaces. Also be sure that the config entry has the same number of strings as are reported in the log file.
After editing /etc/pcmcia/config, you can signal cardmgr
to reload the file with:
kill -HUP `cat /var/run/cardmgr.pid`
If you do set up an entry for a new card, please send me a copy so that I can include it in the standard config file.
In theory, it should not really matter which interrupt is allocated to
which device, as long as two devices are not configured to use the
same interrupt. In /etc/pcmcia/config.opts you'll find
a place for excluding interrupts that are used by non-PCMCIA devices.
Note that the interrupt used to monitor card status changes is chosen
by the low-level socket driver module (i82365 or tcic)
before cardmgr parses /etc/pcmcia/config, so it is not
affected by changes to this file. To set this interrupt, use the
irq_mask or cs_irq options when the socket driver is loaded,
in /etc/rc.d/rc.pcmcia.
All the client card drivers have a parameter called irq_mask for
specifying which interrupts they may try to allocate. Each bit of
irq_mask corresponds to one irq line: bit 0 is irq 0, bit 1 is irq 1,
and so on. So, a mask of 0x1200 would correspond to irq 9 and irq 12.
To limit a driver to use only one specific interrupt, its irq_mask
should have only one bit set. These driver options should be set in
your /etc/pcmcia/config file. For example:
device "serial_cs"
module "serial_cs" opts "irq_mask=0x1100"
...
would specify that the serial driver should only use irq 8 or irq 12. Note that Card Services will never allocate an interrupt that is already in use by another device, or an interrupt that is excluded in the config file.
There is no way to directly specify the I/O addresses for a PCMCIA
card to use. The /etc/pcmcia/config.opts file allows you
to specify ranges of ports available for use by all PCMCIA devices.
After modifying /etc/pcmcia/config, you can restart
cardmgr with ``kill -HUP''.
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.
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.
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 (faith@cs.unc.edu), and APM tools can be
obtained from ftp.cs.unc.edu in /pub/users/faith/linux.
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.
Use either the cardctl or cardinfo command.
``cardctl suspend #'' will suspend one socket, and turn off
its power. The corresponding resume command will wake up the
card in its previous state.
This is trivial using PCMCIA ``scheme'' support.
Use two configuration schemes, called ``home'' and ``work''. Here is
an example of a network.opts script with scheme-specific
settings:
case "$ADDRESS" in
work,*,*,*)
# definitions for network card in work scheme
;;
home,*,*,*|default,*,*,*)
# definitions for network card in home scheme
;;
esac
The first part of a PCMCIA device address is always the configuration scheme. In this example, the second ``case'' clause will select for both the ``home'' and ``default'' schemes. So, if the scheme is unset for any reason, it will default to the ``home'' setup.
Now, to choose between the two sets of settings, run either:
cardctl scheme home
or
cardctl scheme work
The cardctl command does the equivalent of shutting down all your
cards and restarting them. The command can be safely executed whether
or not the PCMCIA system is loaded, but the command may fail if you
are using other PCMCIA devices at the time (even if their
configurations are not explicitly dependant on the scheme setting).
To find out the current PCMCIA scheme setting, run:
cardctl scheme