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.