In most cases, the socket driver (i82365 or tcic) will 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.  With the i82365 and tcic drivers, the irq_list option 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 i82365 and 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 host 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  /etc/rc.d/rc.pcmcia or /etc/sysconfig/pcmcia, depending on your site  setup.  33..77..  IInntteerrrruupptt ddeelliivveerryy pprroobblleemmss  Symptoms:  +o  Cards appear to be configured successfully, but don't work.  +o  Serial and modem cards may respond very sluggishly.  +o  Network cards may report ``interrupt(s) dropped'', and/or transmit     timeouts.  The most simple interrupt delivery problems are due to conflicts with  other system devices.  These can generally be resolved by excluding  problem interrupts in /etc/pcmcia/config.opts.  To test, just exclude  interrupts one by one until either the problem is fixed or you run out  of interrupts.  If no interrupts work, then device conflicts are  probably not the problem.  For CardBus bridges, a variety of other interrupt delivery issues may  come into play.  For a complete discussion, see ``PCI interrupt  delivery problems''.  33..88..  SSyysstteemm rreessoouurrccee ssttaarrvvaattiioonn  Symptoms:  +o  When a card is inserted, it is identified correctly but cannot be     configured (high/low beep pattern).  +o  One of the following messages will appear in the system log:  RequestIO: Resource in use  RequestIRQ: Resource in use  RequestWindow: Resource in use  GetNextTuple: No more items  could not allocate nn IO ports for CardBus socket n  could not allocate nnK memory for CardBus socket n  could not allocate interrupt for CardBus socket n  Interrupt starvation often indicates a problem with the interrupt  probe (see ``Interrupt scan failures'').  In some cases, the probe  will seem to work, but only report one or two available interrupts.  Check your system log to see if the scan results look sensible.  Disabling the probe and selecting interrupts manually should help.  If the interrupt probe is not working properly, the socket driver may  allocate an interrupt for monitoring card insertions, even when  interrupts are too scarce for this to be a good idea.  You can switch  the controller to polled mode by setting PCIC_OPTS to  ``poll_interval=100'.  Or, if you have a CardBus controller and an  older version of the PCMCIA drivers, try ``pci_csc=1'', which selects  a PCI interrupt (if available) for card status changes.  IO port starvation is fairly uncommon, but sometimes happens with  cards that require large, contiguous, aligned regions of IO port  space, or that only recognize a few specific IO port positions.  The  default IO port ranges in /etc/pcmcia/config.opts are normally  sufficient, but may be extended.  If this is the problem, try  uncommenting the ``include port 0x1000-0x17ff'' line in config.opts.  In rare cases, starvation may indicate that the IO port probe failed  (see ``IO port scan failures'').  Memory starvation is also uncommon with the default memory window  settings in config.opts.  CardBus cards may require larger memory  regions than typical 16-bit cards.  Since CardBus memory windows can  be mapped anywhere in the host's PCI address space (rather than just  in the 640K-1MB ``hole'' in PC systems), it is helpful to specify  large memory windows in high memory, such as 0xa0000000-0xa0ffffff.  33..99..  RReessoouurrccee ccoonnfflliicctt oonnllyy wwiitthh ttwwoo ccaarrddss iinnsseerrtteedd  Symptoms:  +o  Two cards each work fine when used separately.  +o  When both cards are inserted, only one works.  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 the  cardmgr daemon to reload the resource database.  33..1100..  DDeevviiccee ccoonnffiigguurraattiioonn ddooeess nnoott ccoommpplleettee  Symptoms:  +o  When a card is inserted, exactly one high beep is heard.  +o  Subsequent card insertions and removals may be ignored.  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  present.  To pinpoint the problem, you can manually run a setup script to see  where it is blocking.  The scripts are in the /etc/pcmcia directory.  They take two parameters: a device name, and an action.  The 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 command  would trace the script:       sh -x /etc/pcmcia/network start eth0  44..  UUssaaggee aanndd ffeeaattuurreess  44..11..  TToooollss ffoorr ccoonnffiigguurriinngg aanndd mmoonniittoorriinngg PPCCMMCCIIAA ddeevviicceess  If the modules are all loaded correctly, the output of the lsmod  command should look like the following, when no cards are inserted:       Module                  Size  Used by       ds                      5640   2       i82365                 15452   2       pcmcia_core            30012   3  [ds i82365]  The system log should also include output from the socket driver  describing the host controller(s) found and the number of sockets  detected.  44..11..11..  TThhee ccaarrddmmggrr ccoonnffiigguurraattiioonn ddaaeemmoonn  The cardmgr daemon is responsible for monitoring PCMCIA sockets,  loading client drivers when needed, and running user-level scripts in  response to card insertions and removals.  It records its actions in  the system log, but also uses beeps to signal card status changes.  The tones of the beeps indicate success or failure of particular  configuration steps.  Two high beeps indicate that a card was  identified and configured successfully.  A high beep followed by a low  beep indicates that a card was identified, but could not be configured  for some reason.  One low beep indicates that a card could not be  identified.  The cardmgr daemon configures cards based on a database of known card  types kept in /etc/pcmcia/config.  This file describes the various  client drivers, then describes how to identify various cards, and  which driver(s) belong with which cards.  The format of this file is  described in the pcmcia(5) man page.  44..11..22..  TThhee ssoocckkeett ssttaattuuss ffiillee,, ssttaabb  Cardmgr records device information for each socket in  /var/lib/pcmcia/stab.  Here is a sample 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       ttyS1   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 (if applicable).  See the  stab man page for more info.  44..11..33..  TThhee ccaarrddccttll aanndd ccaarrddiinnffoo uuttiilliittiieess  The cardctl command can be used to check the status of a socket, or to  see how it is configured.  It can also be used to alter the  configuration status of a card.  Here is an example of the output of  the ``cardctl config'' command:       Socket 0:         not configured       Socket 1:         Vcc = 5.0, Vpp1 = 0.0, Vpp2 = 0.0         Card type is memory and I/O         IRQ 3 is dynamic shared, level mode, enabled         Speaker output is enabled         Function 0:           Config register base = 0x0800             Option = 0x63, status = 0x08           I/O window 1: 0x0280 to 0x02bf, auto sized           I/O window 2: 0x02f8 to 0x02ff, 8 bit  Or ``cardctl ident'', to get card identification information:  Socket 0:    no product info available  Socket 1:    product info: "LINKSYS", "PCMLM336", "A", "0040052D6400"    manfid: 0x0143, 0xc0ab    function: 0 (multifunction)  The ``cardctl suspend'' and ``cardctl resume'' commands can be used to  shut down a card without unloading its associated drivers.  The  ``cardctl reset'' command attempts to reset and reconfigure a card.  ``cardctl insert'' and ``cardctl eject'' mimic the actions performed  when a card is physically inserted or ejected, including loading or  unloading drivers, and configuring or shutting down devices.  If you are running X, the cardinfo utility produces a graphical  display showing the current status of all PCMCIA sockets, similar in  content to ``cardctl config''.  It also provides a graphical interface  to most other cardctl functions.  44..11..44..  IInnsseerrttiinngg aanndd eejjeeccttiinngg ccaarrddss  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.  Some card types cannot be safely hot ejected.  Specifically, ATA/IDE  and SCSI interface cards are not hot-swap-safe.  This is unlikely to  be fixed, because a complete solution would require significant  changes to the Linux block device model.  Also, it is generally not  safe to hot eject CardBus cards of any type.  This is likely to  improve gradually as hot swap bugs in the CardBus drivers are found  and fixed.  For these card types (IDE, SCSI, CardBus), it is  recommended that you always use ``cardctl eject'' before ejecting.  44..11..55..  CCaarrdd SSeerrvviicceess aanndd AAddvvaanncceedd PPoowweerr MMaannaaggeemmeenntt  Card Services can be compiled with support for APM (Advanced Power  Management) if you've configured your kernel with APM support.  The  APM kernel driver is maintained by Stephen Rothwell  (Stephen.Rothwell@canb.auug.org.au).  The apmd daemon is maintained by  Avery Pennarun (apenwarr@worldvisions.ca), with more information  available at <http://www.worldvisions.ca/~apenwarr/apmd/>.  The PCMCIA  modules will automatically be configured for APM if a compatible  version is detected on your system.  Whether or not APM is configured, you can use ``cardctl suspend''  before suspending your laptop, and ``cardctl resume'' after resuming,  to cleanly shut down and restart your PCMCIA cards.  This will not  work with a 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.  Some drivers, notably the PCMCIA SCSI drivers, cannot recover from a  suspend/resume cycle.  When using a PCMCIA SCSI card, always use  ``cardctl eject'' prior to suspending the system.  44..11..66..  SShhuuttttiinng