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 2
pcmcia_core 6 [ds i82365]
All the PCMCIA modules and the cardmgr daemon send status
messages to the system log. This will usually be
/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 /etc/stab.
Here is a sample /etc/stab listing:
Socket 0: Adaptec APA-1460 SlimSCSI
0 aha152x_cs 0 sda 8 0
Socket 1: Serial or Modem Card
1 serial_cs 0 cua1 5 65
For the lines describing devices, the first field is the socket, the second is the driver name, the third is used to number multiple devices associated with the same driver, the fourth is the device name, and the final two fields are the major and minor device numbers for this device.
Linux ethernet-type network interfaces normally have names like
eth0, eth1, 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.
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 script,
/etc/pcmcia/serial, will link the appropriate device file to
/dev/modem as a convenience.
If you are using more than one PCMCIA modem, use /etc/stab or
cardinfo to find out which device corresponds to each modem.
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.
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 /etc/stab or use /dev/modem, rather than
expecting a PCMCIA modem to always have the same device assignment.
The Qlogic FastSCSI, New Media Bus Toaster, and Adaptec APA-1460
SlimSCSI cards work under Card Services. The PCMCIA driver modules
for these cards are built by linking some PCMCIA-specific code (in
qlogic_cs.c and toaster_cs.c) with a normal Linux SCSI
driver. The Qlogic PCMCIA driver links with the normal QLogic driver.
The Bus Toaster PCMCIA driver, which also supports the Adaptec
SlimSCSI, links with the Adaptec 152x driver.
When a new SCSI host adapter is detected, the SCSI drivers will probe
for devices. Check /usr/adm/messages 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 CDROM 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 /etc/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"
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.
With 1.2.X kernels, the SCSI configuration script is called just once to either configure or shut down a SCSI adapter. In this situation, the SCSI script will not be able to determine when it is safe to eject the adapter. It is up to the user to ensure that all SCSI devices are closed before ejecting the card.
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 a card's first common memory and attribute
memory regions. Check the man pages for all the details, but the
devices you'll probably be using will be /dev/mem0c
(character device) or /dev/mem0b (block device). 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/mem0c
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
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.
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 /usr/adm/messages 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 fail.
Card Services can be compiled with support for APM (Advanced Power Management) if you've installed this package on your system. The current release of Stephen Rothwell's APM support package is version 0.5. Unlike the 0.4 release, 0.5 does not require a special patch to work with PCMCIA. 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.
APM is currently being maintained by Rick Faith ().
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.