pcmcia-howto

pcmcia source code

  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
  ([e-mail]).  The apmd daemon is maintained by
  Avery Pennarun ([e-mail]), 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