This section describes some of the most common failure modes for the PCMCIA subsystem. Try to match your symptoms against the examples. This section only describes ``general failures'' that are not specific to a particular card or driver.
It is nearly impossible to debug PCMCIA driver problems encountered when attempting to install Linux via a PCMCIA device. Even if you can identify the problem based on its symptoms, installation disks are difficult to modify, especially without access to a running Linux system. Customization of installation disks is completely dependent on the choice of Linux distribution, and is beyond the scope of this document. In general, the best course of action is to install Linux using some other means, obtain the latest PCMCIA drivers, and then debug the problem if it persists.
lsmoddoes not show any PCMCIA modules.
cardmgrreports ``no pcmcia driver in /proc/devices'' in the system log.
Kernel modules contain version information that is checked against the
current kernel when a module is loaded. The type of checking depends
on the setting of the
CONFIG_MODVERSIONS kernel option. If this
is false, then the kernel version number is compiled into each module,
insmod checks this for a match with the running kernel. If
CONFIG_MODVERSIONS is true, then each symbol exported by the
kernel is given a sort of checksum. These codes are all compared
against the corresponding codes compiled into a module. The intent
was for this to make modules less version-dependent, because the
checksums would only change if a kernel interface changed, and would
generally stay the same across minor kernel updates. In practice, the
checksums have turned out to be even more restrictive, because many
kernel interfaces depend on compile-time kernel option settings.
Also, the checksums turned out to be an excessively pessimistic judge
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.
The practical upshot of this is that kernel modules are closely tied to both the kernel version, and the setting of many kernel configuration options. Generally, a set of modules compiled for one 2.0.31 kernel will not load against some other 2.0.31 kernel unless special care is taken to ensure that the two were built with similar configurations. This makes distribution of precompiled kernel modules a tricky business.
You have several options:
Documentation/Changesfile in the kernel source code tree.
After identifying the PCMCIA controller, the socket driver probes for free interrupts. The probe involves programming the controller for each apparently free interrupt, then generating a ``soft'' interrupt, to see if the interrupt can be detected correctly. In some cases, probing a particular interrupt can interfere with another system device.
The reason for the probe is to identify interrupts which appear to be free (i.e., are not reserved by any other Linux device driver), yet are either not physically wired to the PCMCIA controller, or are connected to another device that does not have a driver.
There are two ways to proceed:
irq_listparameter for the socket drivers. For example, ``
irq_list=5,9,10'' would limit the scan to three interrupts. All PCMCIA devices will be restricted to using these interrupts (assuming they pass the probe). You may need to use trial and error to find out which interrupts can be safely probed.
In either case, the probe options can be specified using the
PCIC_OPTS definition in the PCMCIA startup script, for example:
The core modules perform a memory scan at the time of first card
insertion. This scan can potentially interfere with other memory
mapped devices. Also, pre-3.0.0 driver packages perform a more
aggressive scan than more recent drivers. The memory window is
/etc/pcmcia/config.opts. The default window is
large, so it may help to restrict the scan to a narrower range.
Reasonable ranges to try include 0xd0000-0xdffff, 0xc0000-0xcffff,
0xc8000-0xcffff, or 0xd8000-0xdffff.
If you have DOS or Windows 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 might be given as
0xd000). Be sure to add the extra digit back when making changes to
In most cases, the socket driver (
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.
tcic drivers, the
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
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
depending on your site setup.
This usually indicates a resource conflict with a system device that Linux does not know about. PCMCIA devices are dynamically configured, so, for example, interrupts are allocated as needed, rather than specifically assigned to particular cards or sockets. Given a list of resources that appear to be available, cards are assigned resources in the order they are configured. In this case, the card configured last is being assigned a resource that in fact is not free.
Check the system log to see what resources are used by the non-working
card. Exclude these in
/etc/pcmcia/config.opts, and restart
cardmgr daemon to reload the resource database.
This indicates that the card was identified successfully, however,
cardmgr has been unable to complete the configuration process for
some reason. The most likely reason is that a step in the card setup
script has blocked. A good example would be the network script
blocking if a network card is inserted with no actual network hookup
To pinpoint the problem, you can manually run a setup script to see
where it is blocking. The scripts are in the
directory. They take two parameters: a device name, and an action.
cardmgr daemon records the configuration commands in the
system log. For example, if the system log shows that the command
``./network start eth0'' was the last command executed by
cardmgr, the following commands would trace the script:
cd /etc/pcmcia sh -x ./network start eth0