pcmcia-howto

pcmcia source code

  For debugging problems in the device configuration scripts, it may be
  useful to start cardmgr with the ``-v'' option.  With a 3.1.23 or
  later PCMCIA package, this will cause most important script actions to
  be recorded in the system log.

  It is nearly impossible to debug 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 drivers, and then debug the
  problem if it persists.

  33..11..  BBaassee PPCCMMCCIIAA kkeerrnneell mmoodduulleess ddoo nnoott llooaadd

  Symptoms:

  +o  Kernel version mismatch errors are reported when the PCMCIA startup
     script runs.

  +o  After startup, lsmod does not show any PCMCIA modules.

  +o  cardmgr reports ``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,
  and 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 of compatibility.

  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.2.19 kernel will not load against some other 2.2.19 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:

  +o  If you obtained precompiled drivers as part of a Linux
     distribution, verify that you are using an unmodified kernel as
     supplied with that distribution.  If you intend to use precompiled
     modules, you generally must stick with the corresponding kernel.

  +o  If you have reconfigured or upgraded your kernel, you will probably
     need to compile and install the PCMCIA package from scratch.  This
     is easily done if you already have the kernel source tree
     installed.  See ``Compilation and installation'' for detailed
     instructions.

  +o  In some cases, incompatibilities in other system components can
     prevent correct loading of kernel modules.  If you have upgraded
     your own kernel, pay attention to the ``minimal requirements'' for
     module utilities and binutils listed in the Documentation/Changes
     file in the kernel source code tree.

  33..22..  SSoommee cclliieenntt ddrriivveerr mmoodduulleess ddoo nnoott llooaadd

  Symptoms:

  +o  The base modules (pcmcia_core, ds, i82365) load correctly.

  +o  Inserting a card gives a high beep + low beep pattern.

  +o  cardmgr reports version mismatch errors in the system log.

  Some of the driver 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 particular module. Note that insmod error messages do
  not distinguish between version mismatch errors and missing symbol
  errors.

  Specifically:

  +o  The serial client driver serial_cs requires the kernel serial
     driver to be enabled with CONFIG_SERIAL.  This driver may be built
     as a module.

  +o  Support for multiport serial cards or multifunction cards that
     include serial or modem devices requires CONFIG_SERIAL_SHARE_IRQ to
     be enabled.

  +o  The SCSI client drivers require that CONFIG_SCSI be enabled, along
     with the appropriate top level driver options (CONFIG_BLK_DEV_SD,
     CONFIG_BLK_DEV_SR, etc for 2.1 kernels).  These may be built as
     modules.

  +o  The network client drivers require that CONFIG_INET is enabled.
     Kernel networking support cannot be compiled as a module.

  +o  The token-ring client requires that the kernel be compiled with
     CONFIG_TR enabled.

  There are two ways to proceed:

  +o  Rebuild your kernel with the necessary features enabled.

  +o  If the features have been compiled as modules, then modify
     /etc/pcmcia/config to preload these modules.

  The /etc/pcmcia/config file can specify that additional modules need
  to be loaded for a particular client.  For example, for the serial
  driver, one would use:

       device "serial_cs"
         class "serial" module "misc/serial", "serial_cs"

  Module paths are specified relative to the top-level module directory
  for the current kernel version; if no relative path is given, then the
  path defaults to the pcmcia subdirectory.

  33..33..  IISSAA iinntteerrrruupptt ssccaann ffaaiilluurreess

  Symptoms:

  +o  The system locks up when the PCMCIA drivers are loaded, even with
     no cards present.

  +o  The system log shows a successful host controller probe just before
     the lock-up, but does not show interrupt probe results.

  After identifying the host controller type, the socket driver probes
  for free ISA bus 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 host controller, or are
  connected to another device that does not have a driver.

  In the system log, a successful probe might look like:

       Intel PCIC probe:
         TI 1130 CardBus at mem 0x10211000, 2 sockets
         ...
         ISA irqs (scanned) = 5,7,9,10 status change on irq 10

  There are two ways to proceed:

  +o  The ISA interrupt probe can be restricted to a list of interrupts
     using the irq_list parameter for the socket drivers.  For example,
     ``irq_list=5,9,10'' would limit the scan to three interrupts.  All
     16-bit 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.

  +o  The interrupt probe can be disabled entirely by loading the socket
     driver with the ``do_scan=0'' option.  In this case, a default
     interrupt list will be used, which just avoids interrupts already
     allocated for other devices.

  In either case, the probe options can be specified using the PCIC_OPTS
  definition in the PCMCIA startup script, for example:

       PCIC_OPTS="irq_list=5,9,10"

  It should be noted that /proc/interrupts is completely useless when it
  comes to diagnosing interrupt probe problems.  The probe is sensible
  enough to never attempt to use an interrupt that is already in use by
  another Linux driver.  So, the PCMCIA drivers are already using all
  the information in /proc/interrupts.  Depending on system design, an
  inactive device can still occupy an interrupt and cause trouble if it
  is probed for PCMCIA.

  33..44..  IIOO ppoorrtt ssccaann ffaaiilluurreess

  Symptoms:

  +o  The system locks up when cardmgr is first started.  For 3.1.24, the
     lockup happens even with no cards present; for 3.1.25, a card must
     be inserted.

  +o  The system log shows a successful host controller probe, including
     interrupt probe results, but does not show IO probe results.

  +o  In some cases, the IO probe will succeed, but report large numbers
     of random exclusions.

  When cardmgr processes IO port ranges listed in
  /etc/pcmcia/config.opts, the kernel probes these ranges to detect
  latent devices that occupy IO space but are not associated with a
  Linux driver.  The probe is read-only, but in rare cases, reading from
  a device may interfere with an important system function, resulting in
  a lock-up.

  Your system user's guide may include a map of system devices, showing
  their IO and memory ranges.  These can be explicitly excluded in
  config.opts.

  Alternatively, if the probe is unreliable on your system, it can be
  disabled by setting CORE_OPTS to ``probe_io=0''.  In this case, you
  should be very careful to specify only genuinely available ranges of
  ports in config.opts, instead of using the default settings.

  33..55..  MMeemmoorryy pprroobbee ffaaiilluurreess

  Symptoms:

  +o  The core drivers load correctly when no cards are present, with no
     errors in the system log.

  +o  The system freezes and/or reboots as soon as any card is inserted,
     before any beeps are heard.

  Or alternately:

  +o  All card insertions generate a high beep followed by a low beep.

  +o  All cards are identified as ``anonymous memory cards''.

  +o  The system log reports that various memory ranges have been
     excluded.

  The core modules perform a memory scan at the time of first 16-bit
  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
  defined in /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
  config.opts.

  Changing BIOS settings affecting how devices are mapped can sometimes
  be useful.  Try changing settings for BIOS shadowing, or "Plug and
  Play OS support".

  In unusual cases, a memory probe failure can indicate a timing
  register setup problem with the host controller.  See the ``Startup
  options'' section for information about dealing with common timing
  problems.  This really only applies to ISA-to-PCMCIA bus bridges.

  +o  cs: warning: no high memory space available!

  CardBus bridges can allocate memory windows outside of the 640KB-1MB
  ``memory hole'' in the ISA bus architecture.  It is generally a good
  idea to configure CardBus bridges to use high memory windows, because
  these are unlikely to conflict with other devices.  Also, CardBus
  cards may require large memory windows, which may be difficult or
  impossible to fit into low memory.  Card Services will preferentially
  allocate windows in high memory for CardBus bridges, if both low and
  high memory windows are defined in config.opts.  The default
  config.opts includes several candidate high memory windows, one of
  which will work in most cases

  33..66..  FFaaiilluurree ttoo ddeetteecctt ccaarrdd iinnsseerrttiioonnss aanndd rreemmoovvaallss

  Symptoms:

  +o  Cards are detected and configured properly if present at boot time.

  +o  The drivers do not respond to insertion and removal events, either
     by recording events in the system log, or by beeping.