3817 lines
153 KiB
Plaintext
3817 lines
153 KiB
Plaintext
|
Linux PCMCIA HOWTO
|
|||
|
David Hinds, dahinds@users.sourceforge.net.
|
|||
|
v2.118, 06 December 2003
|
|||
|
|
|||
|
This document describes how to install and use PCMCIA Card Services
|
|||
|
for Linux, and answers some frequently asked questions. The latest
|
|||
|
version of this document can always be found at <http://pcmcia-
|
|||
|
cs.sourceforge.net>.
|
|||
|
______________________________________________________________________
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
|
|||
|
|
|||
|
1. General information and hardware requirements
|
|||
|
|
|||
|
1.1 Introduction
|
|||
|
1.2 Copyright notice and disclaimer
|
|||
|
1.3 What is the latest version, and where can I get it?
|
|||
|
1.4 What systems are supported?
|
|||
|
1.5 What cards are supported?
|
|||
|
1.6 When will my favorite (unsupported) card become supported?
|
|||
|
1.7 Mailing lists and other information sources
|
|||
|
|
|||
|
2. Compilation and installation
|
|||
|
|
|||
|
2.1 Prerequisites and kernel setup
|
|||
|
2.2 Kernel PCMCIA support
|
|||
|
2.3 Installation
|
|||
|
2.4 Startup options
|
|||
|
2.4.1 Card readers for desktop systems
|
|||
|
2.5 System resource settings
|
|||
|
2.5.1 PowerBook specific settings
|
|||
|
2.6 Notes about specific Linux distributions
|
|||
|
2.6.1 Debian
|
|||
|
2.6.2 Red Hat, Caldera, Mandrake
|
|||
|
2.6.3 Slackware
|
|||
|
2.6.4 SuSE
|
|||
|
|
|||
|
3. Resolving installation and configuration problems
|
|||
|
|
|||
|
3.1 Base PCMCIA kernel modules do not load
|
|||
|
3.2 Some client driver modules do not load
|
|||
|
3.3 ISA interrupt scan failures
|
|||
|
3.4 IO port scan failures
|
|||
|
3.5 Memory probe failures
|
|||
|
3.6 Failure to detect card insertions and removals
|
|||
|
3.7 Interrupt delivery problems
|
|||
|
3.8 System resource starvation
|
|||
|
3.9 Resource conflict only with two cards inserted
|
|||
|
3.10 Device configuration does not complete
|
|||
|
|
|||
|
4. Usage and features
|
|||
|
|
|||
|
4.1 Tools for configuring and monitoring PCMCIA devices
|
|||
|
4.1.1 The cardmgr configuration daemon
|
|||
|
4.1.2 The socket status file, stab
|
|||
|
4.1.3 The cardctl and cardinfo utilities
|
|||
|
4.1.4 Inserting and ejecting cards
|
|||
|
4.1.5 Card Services and Advanced Power Management
|
|||
|
4.1.6 Shutting down the PCMCIA system
|
|||
|
4.2 Overview of the PCMCIA configuration scripts
|
|||
|
4.3 PCMCIA network adapters
|
|||
|
4.3.1 Network device parameters
|
|||
|
4.3.2 Comments about specific cards
|
|||
|
4.3.3 Diagnosing problems with network adapters
|
|||
|
4.4 PCMCIA serial and modem devices
|
|||
|
4.4.1 Serial device parameters
|
|||
|
4.4.2 Comments about specific cards
|
|||
|
4.4.3 Diagnosing problems with serial devices
|
|||
|
4.5 PCMCIA parallel port devices
|
|||
|
4.5.1 Parallel device parameters
|
|||
|
4.5.2 Diagnosing problems with parallel port devices
|
|||
|
4.6 PCMCIA SCSI adapters
|
|||
|
4.6.1 SCSI device parameters
|
|||
|
4.6.2 Comments about specific cards
|
|||
|
4.6.3 Diagnosing problems with SCSI adapters
|
|||
|
4.7 PCMCIA memory cards
|
|||
|
4.7.1 Memory device parameters
|
|||
|
4.7.2 Using linear flash memory cards
|
|||
|
4.8 PCMCIA ATA/IDE card drives
|
|||
|
4.8.1 ATA/IDE fixed-disk device parameters
|
|||
|
4.8.2 Diagnosing problems with ATA/IDE adapters
|
|||
|
4.9 Multifunction cards
|
|||
|
|
|||
|
5. Advanced topics
|
|||
|
|
|||
|
5.1 Resource allocation for PCMCIA devices
|
|||
|
5.2 PCI interrupt configuration problems and solutions
|
|||
|
5.2.1 An overview of PCI interrupt routing issues
|
|||
|
5.2.2 CardBus bridge is not detected by the PCI BIOS
|
|||
|
5.2.3 PCI interrupt delivery problems
|
|||
|
5.2.4 No PCI interrupt assignment; valid routing table
|
|||
|
5.2.5 No PCI interrupt assignment; unknown interrupt router
|
|||
|
5.2.6 No PCI interrupt assignment; no routing table
|
|||
|
5.3 How can I have separate device setups for home and work?
|
|||
|
5.4 Booting from a PCMCIA device
|
|||
|
5.4.1 The pcinitrd helper script
|
|||
|
5.4.2 Creating an initrd boot floppy
|
|||
|
5.4.3 Installing an initrd image on a non-Linux drive
|
|||
|
|
|||
|
6. Dealing with unsupported cards
|
|||
|
|
|||
|
6.1 Configuring unrecognized cards
|
|||
|
6.2 Adding support for an NE2000-compatible ethernet card
|
|||
|
6.3 PCMCIA floppy interface cards
|
|||
|
|
|||
|
7. Debugging tips and programming information
|
|||
|
|
|||
|
7.1 Submitting useful problem reports
|
|||
|
7.2 Interpreting kernel trap reports
|
|||
|
7.3 Low level PCMCIA debugging aids
|
|||
|
7.4 /proc/bus/pccard
|
|||
|
7.5 Writing Card Services drivers for new cards
|
|||
|
7.6 Guidelines for PCMCIA client driver authors
|
|||
|
7.7 Guidelines for Linux distribution maintainers
|
|||
|
|
|||
|
|
|||
|
______________________________________________________________________
|
|||
|
|
|||
|
1. General information and hardware requirements
|
|||
|
|
|||
|
1.1. Introduction
|
|||
|
|
|||
|
Card Services for Linux is a complete PCMCIA or ``PC Card'' support
|
|||
|
package. It includes a set of loadable kernel modules that implement
|
|||
|
a version of the Card Services applications program interface, a set
|
|||
|
of client drivers for specific cards, and a card manager daemon that
|
|||
|
can respond to card insertion and removal events, loading and
|
|||
|
unloading drivers on demand. It supports ``hot swapping'' of most
|
|||
|
card types, so cards can be safely inserted and ejected at any time.
|
|||
|
|
|||
|
This software is a work in progress. It contains bugs, and should be
|
|||
|
used with caution. I'll do my best to fix problems that are reported
|
|||
|
to me, but if you don't tell me, I may never know. If you use this
|
|||
|
code, I hope you will send me your experiences, good or bad!
|
|||
|
|
|||
|
If you have any suggestions for how this document could be improved,
|
|||
|
please let me know (dahinds@users.sourceforge.net).
|
|||
|
|
|||
|
|
|||
|
1.2. Copyright notice and disclaimer
|
|||
|
|
|||
|
Copyright (c) 1998-2002 David A. Hinds
|
|||
|
|
|||
|
|
|||
|
This document may be reproduced or distributed in any form without my
|
|||
|
prior permission. Modified versions of this document, including
|
|||
|
translations into other languages, may be freely distributed, provided
|
|||
|
that they are clearly identified as such, and this copyright is
|
|||
|
included intact.
|
|||
|
|
|||
|
This document may be included in commercial distributions without my
|
|||
|
prior consent. While it is not required, I would like to be informed
|
|||
|
of such usage. If you intend to incorporate this document in a
|
|||
|
published work, please contact me to make sure you have the latest
|
|||
|
available version.
|
|||
|
|
|||
|
This document is provided ``AS IS'', with no express or implied
|
|||
|
warranties. Use the information in this document at your own risk.
|
|||
|
|
|||
|
|
|||
|
1.3. What is the latest version, and where can I get it?
|
|||
|
|
|||
|
The current major release of Card Services is version 3.2, and minor
|
|||
|
updates or bug fixes are numbered 3.2.1, 3.2.2, and so on.
|
|||
|
|
|||
|
Source code for the latest version is available on the web at
|
|||
|
<http://pcmcia-cs.sourceforge.net>, as pcmcia-cs-3.2.?.tar.gz. You
|
|||
|
may find more than one release number here. It is up to you to decide
|
|||
|
which version is more appropriate, but the CHANGES file will summarize
|
|||
|
the most important differences.
|
|||
|
|
|||
|
Pre-compiled drivers are included with current releases of essentially
|
|||
|
all major Linux distributions, including Slackware, Debian, Red Hat,
|
|||
|
Caldera, and SuSE, among others. So generally there is no need to
|
|||
|
compile the drivers from scratch.
|
|||
|
|
|||
|
|
|||
|
1.4. What systems are supported?
|
|||
|
|
|||
|
This package should run on almost Intel-based Linux-capable laptop.
|
|||
|
It also runs on some Alpha, PowerPC, ARM, and MIPS platforms. Most
|
|||
|
common socket controllers are supported. Card docks for desktop
|
|||
|
systems should work as long as they use a supported controller, and
|
|||
|
are plugged directly into the ISA or PCI bus, as opposed to SCSI-to-
|
|||
|
PCMCIA or IDE-to-PCMCIA adapters. The following controllers are
|
|||
|
recognized by the supplied socket drivers:
|
|||
|
|
|||
|
|
|||
|
<20> Cirrus Logic (now Basis Communications) PD6710, PD6720, PD6722,
|
|||
|
PD6729, PD6730, PD6832
|
|||
|
|
|||
|
<20> ENE Technology CB1211, CB1225, CB1410, CB1420
|
|||
|
|
|||
|
<20> Intel i82365sl B, C, and DF steps, 82092AA
|
|||
|
|
|||
|
<20> O2Micro OZ6729, OZ6730, OZ6812, OZ6832, OZ6833, OZ6836, OZ6860,
|
|||
|
OZ6922, OZ6933, OZ6912
|
|||
|
|
|||
|
<20> Omega Micro 82C365G, 82C092G
|
|||
|
|
|||
|
<20> Ricoh RF5C296, RF5C396, RL5C465, RL5C466, RL5C475, RL5C476,
|
|||
|
RL5C477, RL5C478
|
|||
|
|
|||
|
<20> SMC 34C90
|
|||
|
|
|||
|
<20> Texas Instruments PCI1031, PCI1130, PCI1131, PCI1210, PCI1211,
|
|||
|
PCI1220, PCI1221, PCI1225, PCI1250A, PCI1251A, PCI1251B, PCI1410,
|
|||
|
PCI1410A, PCI1420, PCI1450, PCI1451A, PCI1510, PCI1520, PCI1620,
|
|||
|
PCI4410, PCI4410A, PCI4450, PCI4451, PCI4510, PCI4520, PCI7410,
|
|||
|
PCI7510, PCI7610
|
|||
|
<20> Toshiba ToPIC95, ToPIC97, ToPIC100 (experimental, incomplete)
|
|||
|
|
|||
|
<20> Vadem VG465, VG468, VG469
|
|||
|
|
|||
|
<20> VLSI Technologies 82C146, VCF94365
|
|||
|
|
|||
|
<20> VIA VT83C469
|
|||
|
|
|||
|
<20> Databook DB86082, DB86082A, DB86084, DB86084A, DB86072, DB86082B
|
|||
|
|
|||
|
Other controllers that are register compatible with the Intel i82365sl
|
|||
|
will generally work, as well.
|
|||
|
|
|||
|
Due to the rapid pace of technological change for laptop hardware, new
|
|||
|
controllers appear frequently, and there may be delays between when a
|
|||
|
new model appears on the market, and when driver support becomes
|
|||
|
available.
|
|||
|
|
|||
|
Support for Toshiba's ToPIC bridges was hindered for a long time by a
|
|||
|
lack of sufficiently detailed technical documentation. While some
|
|||
|
datasheets have been available, a few idiosyncracies of the ToPIC
|
|||
|
chips were not adequately explained. Toshiba has given some direct
|
|||
|
technical help on some of these issues, and I think the major ones
|
|||
|
have been resolved. However, with the introduction of kernel PCMCIA
|
|||
|
support in 2.4.* and later kernels, some new Toshiba bugs may have
|
|||
|
cropped up in the new socket driver code.
|
|||
|
|
|||
|
The Motorola 6AHC05GA controller used in some Hyundai laptops is not
|
|||
|
supported. The custom host controller in the HP Omnibook 600 is also
|
|||
|
unsupported.
|
|||
|
|
|||
|
|
|||
|
1.5. What cards are supported?
|
|||
|
|
|||
|
The current release includes drivers for a variety of ethernet cards,
|
|||
|
a driver for modem and serial port cards, several SCSI adapter
|
|||
|
drivers, a driver for ATA/IDE drive cards, and memory card drivers
|
|||
|
that should support most SRAM cards and some flash cards. The
|
|||
|
SUPPORTED.CARDS file included with each release of Card Services lists
|
|||
|
all cards that are known to work in at least one actual system.
|
|||
|
|
|||
|
The likelihood that a card not on the supported list will work depends
|
|||
|
on the type of card. Essentially all modems should work with the
|
|||
|
supplied driver. Some network cards may work if they are OEM versions
|
|||
|
of supported cards. Other types of IO cards (frame buffers, sound
|
|||
|
cards, etc) will not work until someone writes the appropriate
|
|||
|
drivers.
|
|||
|
|
|||
|
|
|||
|
1.6. When will my favorite (unsupported) card become supported?
|
|||
|
|
|||
|
Unfortunately, they usually don't pay me to write device drivers, so
|
|||
|
if you would like to have a driver for your favorite card, you are
|
|||
|
probably going to have to do at least some of the work. Ideally, I'd
|
|||
|
like to work towards a model like the Linux kernel, where I would be
|
|||
|
responsible mainly for the ``core'' driver code and other authors
|
|||
|
would contribute and maintain client drivers for specific cards. The
|
|||
|
SUPPORTED.CARDS file mentions some cards for which driver work is
|
|||
|
currently in progress. I will try to help where I can, but be warned
|
|||
|
that debugging kernel device drivers by email is not particularly
|
|||
|
effective.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
1.7. Mailing lists and other information sources
|
|||
|
|
|||
|
The Linux PCMCIA information page is at <http://pcmcia-
|
|||
|
cs.sourceforge.net>, and has bug tracking, support and feature
|
|||
|
requests, and a variety of PCMCIA related message forums. Users can
|
|||
|
request email notification of new responses to particular questions,
|
|||
|
or notification for all new messages in a given category. I hope that
|
|||
|
this will become a useful repository of information, for questions
|
|||
|
that go beyond the scope of the HOWTO.
|
|||
|
|
|||
|
The Linux Laptop Page at <http://www.linux-on-laptops.com> has links
|
|||
|
to a vast number of sites that have information about configuring
|
|||
|
specific types of laptops for Linux. There is also a searchable
|
|||
|
database of system configuration information, and pointers to a
|
|||
|
variety of laptop-related mailing lists.
|
|||
|
|
|||
|
|
|||
|
2. Compilation and installation
|
|||
|
|
|||
|
2.1. Prerequisites and kernel setup
|
|||
|
|
|||
|
Before starting, you should think about whether you really need to
|
|||
|
compile the PCMCIA package yourself. All common Linux distributions
|
|||
|
come with pre-compiled driver packages. Generally, you only need to
|
|||
|
install the drivers from scratch if you need a new feature of the
|
|||
|
current drivers, or if you've updated and/or reconfigured your kernel
|
|||
|
in a way that is incompatible with the drivers included with your
|
|||
|
Linux distribution. While compiling the package is not technically
|
|||
|
difficult, it does require some general Linux familiarity.
|
|||
|
|
|||
|
The following things should be installed on your system before you
|
|||
|
begin:
|
|||
|
|
|||
|
<20> A 2.0, 2.2, 2.4, or 2.6 series kernel source tree.
|
|||
|
|
|||
|
<20> An appropriate set of module utilities.
|
|||
|
|
|||
|
<20> (Optional) the ``XForms'' X11 user interface toolkit.
|
|||
|
|
|||
|
You need to have a complete linux source tree for your kernel, not
|
|||
|
just an up-to-date kernel image. The driver modules contain some
|
|||
|
references to kernel source files. While you may want to build a new
|
|||
|
kernel to remove unnecessary drivers, installing PCMCIA does not
|
|||
|
require you to do so.
|
|||
|
|
|||
|
Current ``stable'' kernel sources and patches are available from
|
|||
|
<ftp://ftp.kernel.org/pub/linux/kernel/v2.4>. Current module
|
|||
|
utilities can be found in the same locations.
|
|||
|
|
|||
|
In the Linux kernel source tree, the Documentation/Changes file
|
|||
|
describes the versions of all sorts of other system components that
|
|||
|
are required for that kernel release. You may want to check through
|
|||
|
this and verify that your system is up to date, especially if you have
|
|||
|
updated your kernel. If you are using a development kernel, be sure
|
|||
|
that you are using the right combination of shared libraries and
|
|||
|
module tools.
|
|||
|
|
|||
|
On x86 based systems, if you plan to use 16-bit PC Card devices, you
|
|||
|
should also enable CONFIG_ISA, for recent kernels. These cards behave
|
|||
|
much like ISA devices, and the PCMCIA drivers use CONFIG_ISA to judge
|
|||
|
whether a platform supports ISA bus interrupts.
|
|||
|
|
|||
|
When configuring your kernel, if you plan on using a PCMCIA ethernet
|
|||
|
card, you should turn on networking support but turn off the normal
|
|||
|
Linux network card drivers, including the ``pocket and portable
|
|||
|
adapters''. The PCMCIA network card drivers are all implemented as
|
|||
|
loadable modules. Any drivers compiled into your kernel will only
|
|||
|
waste space.
|
|||
|
|
|||
|
If you want to use SLIP, PPP, or PLIP, you do need to either configure
|
|||
|
your kernel with these enabled, or use the loadable module versions of
|
|||
|
these drivers.
|
|||
|
|
|||
|
In order to use a PCMCIA token ring adapter, your kernel should be
|
|||
|
configured with ``Token Ring driver support'' (CONFIG_TR) enabled,
|
|||
|
though you should leave CONFIG_IBMTR off.
|
|||
|
|
|||
|
If you want to use a PCMCIA IDE adapter, your kernel should be
|
|||
|
configured with CONFIG_BLK_DEV_IDE_PCMCIA enabled, for 2.0.* kernels.
|
|||
|
Newer kernels do not require a special configuration setting.
|
|||
|
|
|||
|
If you will be using a PCMCIA SCSI adapter, then enable CONFIG_SCSI
|
|||
|
when configuring your kernel. Also, enable any top level drivers
|
|||
|
(SCSI disk, tape, cdrom, generic) that you expect to use. All low-
|
|||
|
level drivers for particular host adapters should be disabled, as they
|
|||
|
will just take up space.
|
|||
|
|
|||
|
This package includes an X-based card status utility called cardinfo.
|
|||
|
This utility is based on a freely distributed user interface toolkit
|
|||
|
called the XForms Library. This library is available as a separate
|
|||
|
package with most Linux distributions. If you would like to build
|
|||
|
cardinfo, you should install XForms and all the normal X header files
|
|||
|
and libraries before configuring the PCMCIA package. This tool is
|
|||
|
completely optional.
|
|||
|
|
|||
|
|
|||
|
2.2. Kernel PCMCIA support
|
|||
|
|
|||
|
|
|||
|
PCMCIA driver support is included in the 2.4 and later linux kernel
|
|||
|
trees. While it shares most of the same code with the standalone
|
|||
|
PCMCIA driver package, there are some important differences. The
|
|||
|
kernel PCMCIA support is also still evolving.
|
|||
|
|
|||
|
The kernel PCMCIA code has the same functionality as the driver side
|
|||
|
of the pcmcia-cs package. It does not eliminate the need to install
|
|||
|
the pcmcia-cs package, since it requires the same user tools (cardmgr,
|
|||
|
cardctl, /etc/pcmcia/* files). The drivers in pcmcia-cs can still be
|
|||
|
built for 2.4 kernels, so you have a choice of using either the in-
|
|||
|
kernel PCMCIA drivers, or the drivers included in pcmcia-cs. With 2.5
|
|||
|
and later kernels, the standalone drivers cannot be used.
|
|||
|
|
|||
|
To use the kernel PCMCIA drivers, configure the kernel with
|
|||
|
CONFIG_HOTPLUG, CONFIG_PCMCIA, and usually CONFIG_CARDBUS enabled. On
|
|||
|
x86 based systems, CONFIG_ISA should also be enabled. The drivers can
|
|||
|
either be built into the kernel or built as modules. PCMCIA client
|
|||
|
driver options are listed in their regular driver categories; thus,
|
|||
|
PCMCIA network drivers are in a submenu of network drivers, and PCMCIA
|
|||
|
serial drivers are in a submenu of character drivers.
|
|||
|
|
|||
|
In the standalone pcmcia-cs drivers, the i82365 module supports both
|
|||
|
ISA-to-PCMCIA, PCI-to-PCMCIA, and PCI-to-CardBus bridges. The CardBus
|
|||
|
socket driver in the 2.4 tree is the yenta_socket driver. It is
|
|||
|
selected by the CONFIG_CARDBUS option. In your PCMCIA startup
|
|||
|
options, this driver should be specified in place of the i82365
|
|||
|
driver. The kernel version of the i82365 driver, selected by
|
|||
|
CONFIG_I82365, only supports ISA-to-PCMCIA bridges. PCI-to-PCMCIA
|
|||
|
bridges that are not CardBus capable, like the Cirrus PD6729, are not
|
|||
|
supported at all by the kernel PCMCIA drivers.
|
|||
|
|
|||
|
When compiling the standalone PCMCIA package, the Configure script
|
|||
|
decides whether or not to build any kernel modules by looking at the
|
|||
|
value of the CONFIG_PCMCIA option in your kernel configuration. If
|
|||
|
CONFIG_PCMCIA is enabled, then by default, no driver components are
|
|||
|
built. If CONFIG_PCMCIA is disabled, then all the modules will be
|
|||
|
built and installed. It is safe to compile the user tools (cardmgr,
|
|||
|
cardctl, etc) in a PCMCIA package whose version number differs from
|
|||
|
the PCMCIA version number in the kernel source tree. The kernel
|
|||
|
PCMCIA header files take precedence over the ones included in the
|
|||
|
PCMCIA package, if CONFIG_PCMCIA is enabled.
|
|||
|
|
|||
|
|
|||
|
2.3. Installation
|
|||
|
|
|||
|
Here is a synopsis of the installation process:
|
|||
|
|
|||
|
|
|||
|
<20> Unpack pcmcia-cs-3.2.?.tar.gz in /usr/src.
|
|||
|
|
|||
|
<20> Run ``make config'' in the new pcmcia-cs-3.2.? directory.
|
|||
|
|
|||
|
<20> Run ``make all'', then ``make install''.
|
|||
|
|
|||
|
<20> Customize the startup script and the option files in /etc/pcmcia
|
|||
|
for your site, if needed.
|
|||
|
|
|||
|
If you plan to install any contributed client drivers not included in
|
|||
|
the core PCMCIA distribution, unpack each of them in the top-level
|
|||
|
directory of the PCMCIA source tree. Then follow the normal build
|
|||
|
instructions. The extra drivers will be compiled and installed
|
|||
|
automatically.
|
|||
|
|
|||
|
Running ``make config'' prompts for a few configuration options, and
|
|||
|
checks out your system to verify that it satisfies all prerequisites
|
|||
|
for installing PCMCIA support. In most cases, you'll be able to just
|
|||
|
accept all the default configuration options. Be sure to carefully
|
|||
|
check the output of this command in case there are problems. The
|
|||
|
following options are available:
|
|||
|
|
|||
|
|
|||
|
Linux kernel source directory?
|
|||
|
This is the location of the source tree for the kernel you want
|
|||
|
to use with PCMCIA. Often this is /usr/src/linux, but the
|
|||
|
default location depends on what Linux distribution you're using
|
|||
|
(or on where you've chosen to place your kernel source tree).
|
|||
|
|
|||
|
|
|||
|
Build 'trusting' versions of card utilities?
|
|||
|
Some of the support utilities (cardctl and cardinfo) can be
|
|||
|
compiled either in ``safe'' or ``trusting'' forms. The ``safe''
|
|||
|
forms prevent non-root users from modifying card configurations.
|
|||
|
The ``trusting'' forms permit ordinary users to issue commands
|
|||
|
to suspend and resume cards, reset cards, and change the current
|
|||
|
configuration scheme. The default is to build the safe forms.
|
|||
|
|
|||
|
|
|||
|
Include 32-bit (CardBus) card support?
|
|||
|
This option must be selected if you wish to use 32-bit CardBus
|
|||
|
cards. It is not required for CardBus bridge support, if you
|
|||
|
only plan to use 16-bit PC Cards.
|
|||
|
|
|||
|
|
|||
|
Include PnP BIOS resource checking?
|
|||
|
This builds additional code into the PCMCIA core module to
|
|||
|
communicate with a system's PnP BIOS to obtain resource
|
|||
|
information for built-in ``motherboard'' devices (serial and
|
|||
|
parallel ports, sound, etc), to help avoid resource conflicts.
|
|||
|
If enabled, some extra resource files will be created under
|
|||
|
/proc/bus/pccard, and the lspnp and setpnp tools can be used to
|
|||
|
view and manipulate PnP BIOS devices. However, this setting
|
|||
|
causes problems on some laptops and is not turned on by default.
|
|||
|
|
|||
|
|
|||
|
Module install directory?
|
|||
|
The directory that new kernel modules will be installed into.
|
|||
|
Normally this should be the subdirectory of /lib/modules that
|
|||
|
matches your kernel version.
|
|||
|
|
|||
|
|
|||
|
How to set kernel-specific options?
|
|||
|
There are a few kernel configuration options that affect the
|
|||
|
PCMCIA tools. The configuration script can deduce these from
|
|||
|
the running kernel (the default and most common case).
|
|||
|
Alternatively, if you are compiling for installation on another
|
|||
|
machine, it can read the configuration from a kernel source
|
|||
|
tree, or each option can be set interactively.
|
|||
|
|
|||
|
|
|||
|
The Configure script can also be executed non-interactively, for
|
|||
|
automatic builds or to quickly reconfigure after a kernel update.
|
|||
|
Some additional less-frequently-used options can be only be set from
|
|||
|
the command line. Running ``Configure --help'' lists all available
|
|||
|
options.
|
|||
|
|
|||
|
Running ``make all'' followed by ``make install'' will build and then
|
|||
|
install the kernel modules and utility programs. Kernel modules are
|
|||
|
installed under /lib/modules/<version>/pcmcia. The cardmgr and
|
|||
|
cardctl programs are installed in /sbin. If cardinfo is built, it is
|
|||
|
installed in /usr/bin/X11.
|
|||
|
|
|||
|
Configuration files will be installed in the /etc/pcmcia directory.
|
|||
|
If you are installing over an older version, your old config scripts
|
|||
|
will be backed up before being replaced. The saved scripts will be
|
|||
|
given an *.O extension.
|
|||
|
|
|||
|
If you don't know what kind of host controller your system uses, you
|
|||
|
can use the pcic_probe utility in the cardmgr/ subdirectory to
|
|||
|
determine this. There are several major types: the Databook TCIC-2
|
|||
|
type and the Intel i82365SL-compatible type. With the kernel PCMCIA
|
|||
|
subsystem, Intel compatible controllers are further subdivided into
|
|||
|
ISA-bus 16-bit bridges, and PCI-based CardBus bridges.
|
|||
|
|
|||
|
In a few cases, the pcic_probe command will be unable to determine
|
|||
|
your controller type automatically. If you have a Halikan NBD 486
|
|||
|
system, it has a TCIC-2 controller at an unusual location: you'll need
|
|||
|
to edit rc.pcmcia to load the tcic module, and also set the PCIC_OPTS
|
|||
|
parameter to ``tcic_base=0x02c0''.
|
|||
|
|
|||
|
On some old pre-PCI systems using Cirrus controllers, including the
|
|||
|
NEC Versa M, the BIOS puts the controller in a special suspended state
|
|||
|
at system startup time. On these systems, the pcic_probe command will
|
|||
|
fail to find any known host controller. If this happens, edit
|
|||
|
rc.pcmcia and set PCIC to i82365, and PCIC_OPTS to ``wakeup=1''.
|
|||
|
|
|||
|
|
|||
|
2.4. Startup options
|
|||
|
|
|||
|
The PCMCIA startup script recognizes several groups of startup
|
|||
|
options, set via environment variables. Multiple options should be
|
|||
|
separated by spaces and enclosed in quotes. Placement of startup
|
|||
|
options depends on the Linux distribution used. They may be placed
|
|||
|
directly in the startup script, or they may be kept in a separate
|
|||
|
option file. See the ``Notes about specific Linux distributions'' for
|
|||
|
specifics. The following variables can be set:
|
|||
|
PCMCIA
|
|||
|
This variable specifies whether PCMCIA support should be started
|
|||
|
up, or not. If it is set to anything other than ``yes'', then
|
|||
|
the startup script will be disabled.
|
|||
|
|
|||
|
PCIC
|
|||
|
This identifies the PC Card Interface Controller driver module.
|
|||
|
There are several options: ``tcic'', ``i82365'', and (for the
|
|||
|
kernel PCMCIA subsystem) ``yenta_socket''. Virtually all
|
|||
|
current controllers are in the ``i82365'' group for the
|
|||
|
standalone drivers, and ``yenta_socket'' for the kernel drivers.
|
|||
|
This is the only mandatory option setting.
|
|||
|
|
|||
|
PCIC_OPTS
|
|||
|
This specifies options for the PCIC module. Some host
|
|||
|
controllers have optional features that may or may not be
|
|||
|
implemented in a particular system. In some cases, it is
|
|||
|
impossible for the socket driver to detect if these features are
|
|||
|
implemented. See the corresponding man page for a complete
|
|||
|
description of the available options.
|
|||
|
|
|||
|
CORE_OPTS
|
|||
|
This specifies options for the pcmcia_core module, which
|
|||
|
implements the core PC Card driver services. See ``man
|
|||
|
pcmcia_core'' for more information.
|
|||
|
|
|||
|
CARDMGR_OPTS
|
|||
|
This specifies options to be passed to the cardmgr daemon. See
|
|||
|
``man cardmgr'' for more information.
|
|||
|
|
|||
|
SCHEME
|
|||
|
If set, then the PC Card configuration scheme will be
|
|||
|
initialized to this at driver startup time. See the ``Overview
|
|||
|
of the PCMCIA configuration scripts'' for a discussion of
|
|||
|
schemes.
|
|||
|
|
|||
|
The low level socket drivers, tcic and i82365, have various bus timing
|
|||
|
parameters that may need to be adjusted for certain systems with
|
|||
|
unusual bus clocking. Symptoms of timing problems can include card
|
|||
|
recognition problems, lock-ups under heavy loads, high error rates, or
|
|||
|
poor device performance. Only certain host bridges have adjustable
|
|||
|
timing parameters: check the corresponding man page to see what
|
|||
|
options are available for your controller. Here is a brief summary:
|
|||
|
|
|||
|
|
|||
|
<20> ISA-bus Cirrus controllers have numerous configurable timing
|
|||
|
parameters. The most important seems to be the cmd_time flag,
|
|||
|
which determines the length of PCMCIA bus cycles. Fast 486 systems
|
|||
|
(i.e., DX4-100) seem to often benefit from increasing this from 6
|
|||
|
(the default) to 12 or 16.
|
|||
|
|
|||
|
<20> The Cirrus PD6729 PCI controller has the fast_pci flag, which
|
|||
|
should be set if the PCI bus speed is greater than 25 MHz.
|
|||
|
|
|||
|
<20> For Vadem VG-468 controllers, the async_clock flag changes the
|
|||
|
relative clocking of PCMCIA bus and host bus cycles. Setting this
|
|||
|
flag adds extra wait states to some operations. However, I have
|
|||
|
yet to hear of a laptop that needs this.
|
|||
|
|
|||
|
<20> The pcmcia_core module has the cis_speed parameter for changing the
|
|||
|
memory speed used for accessing a card's Card Information Structure
|
|||
|
(CIS). On some systems, increasing this parameter (i.e., slowing
|
|||
|
down card accesses) may fix card recognition problems.
|
|||
|
|
|||
|
<20> Another pcmcia_core parameter, io_speed, can be used to slow down
|
|||
|
accesses to IO cards. It may help in certain cases with systems
|
|||
|
that have out-of-spec PCMCIA bus timing.
|
|||
|
|
|||
|
<20> This is not a timing issue, but if you have more than one ISA-to-
|
|||
|
PCMCIA controller in your system or extra sockets in a laptop
|
|||
|
docking station, the i82365 module should be loaded with the
|
|||
|
extra_sockets parameter set to 1. This should not be necessary for
|
|||
|
detection of PCI-to-PCMCIA or PCI-to-CardBus bridges.
|
|||
|
|
|||
|
Here are some timing settings for a few old systems:
|
|||
|
|
|||
|
|
|||
|
<20> On the ARM Pentium-90 or Midwest Micro Soundbook Plus, use
|
|||
|
``freq_bypass=1 cmd_time=8''.
|
|||
|
|
|||
|
<20> On a Compaq Presario 1220, try ``setup_time=1''.
|
|||
|
|
|||
|
<20> On a Midwest Micro Soundbook Elite, use ``cmd_time=12''.
|
|||
|
|
|||
|
<20> On a Gateway Liberty, try ``cmd_time=16''.
|
|||
|
|
|||
|
<20> On a Samsung SENS 810, use ``fast_pci=1''.
|
|||
|
|
|||
|
|
|||
|
2.4.1. Card readers for desktop systems
|
|||
|
|
|||
|
While almost all PCMCIA card readers and card docks work fine under
|
|||
|
Linux, some require special startup options because they do not behave
|
|||
|
exactly like laptop PCMCIA bridges. PCI card readers, in particular,
|
|||
|
may handle interrupts differently. Some of the following parameter
|
|||
|
settings are only available for the i82365 module in the standalone
|
|||
|
drivers; the kernel's yenta_socket driver is not configurable.
|
|||
|
|
|||
|
|
|||
|
<20> The Linksys ProConnect PCMRDWR and Antec DataChute ISA card readers
|
|||
|
are ``ISA Plug and Play'' devices. To use these, you must first
|
|||
|
activate them with the Linux isapnp tools. See the man pages for
|
|||
|
pnpdump and isapnp for more information.
|
|||
|
|
|||
|
<20> For Chase CardPORT and Altec ISA card readers using the Cirrus
|
|||
|
PD6722 ISA-to-PCMCIA bridge, the i82365 driver should be loaded
|
|||
|
with a ``has_ring=0'' parameter to prevent irq 15 conflicts.
|
|||
|
|
|||
|
<20> For Elan P-series PCI card readers based on the Cirrus PD6729 PCI-
|
|||
|
to-PCMCIA bridge chip, the i82365 driver requires a ``irq_mode=1''
|
|||
|
parameter.
|
|||
|
|
|||
|
<20> For the Sycard PCChost1200 host adapter, the i82365 driver requires
|
|||
|
a ``p2cclk=1'' parameter.
|
|||
|
|
|||
|
<20> For the Alex Electronics PCICBI host adapter based on the TI 1221
|
|||
|
bridge, the i82365 driver requires ``p2cclk=1 irq_mode=0'' as well
|
|||
|
as PCMCIA driver release 3.1.23 or later.
|
|||
|
|
|||
|
<20> With SCM Microsystems SBP series PCI card readers (which are also
|
|||
|
being distributed with Lucent WaveLAN IEEE cards), and for the
|
|||
|
Synchrotech PCM-CR-PC2IF and PCM-CR-PC2IR, it is necessary to
|
|||
|
specify ``irq_mode=0'' for the i82365 module, to force use of PCI
|
|||
|
interrupts.
|
|||
|
|
|||
|
<20> For the ActionTec PC 750 card reader, and for the Antec Datachute
|
|||
|
PCI card reader, the i82365 driver requires a ``irq_list=0''
|
|||
|
parameter, to indicate that ISA interrupts are unavailable.
|
|||
|
|
|||
|
<20> The PLX Technologies PCI9052 (also sold as the Linksys WDT11) is
|
|||
|
not a general purpose PCMCIA card reader at all: it is a PCI
|
|||
|
interface card for use with certain wireless adapters, that makes
|
|||
|
them look like ordinary PCI devices. These devices are not
|
|||
|
supported.
|
|||
|
|
|||
|
|
|||
|
2.5. System resource settings
|
|||
|
|
|||
|
Card Services should automatically avoid allocating IO ports and
|
|||
|
interrupts already in use by other standard devices. It will also
|
|||
|
attempt to detect conflicts with unknown devices, but this is not
|
|||
|
completely reliable. In some cases, you may need to explicitly
|
|||
|
exclude resources for a device in /etc/pcmcia/config.opts.
|
|||
|
|
|||
|
Here are some resource settings for specific laptop types. View this
|
|||
|
list with suspicion: it may give useful hints for solving problems,
|
|||
|
but it is inevitably out of date and certainly contains mistakes.
|
|||
|
Corrections and additions are welcome.
|
|||
|
|
|||
|
|
|||
|
<20> On the AMS SoundPro, exclude irq 10.
|
|||
|
|
|||
|
<20> On some AMS TravelPro 5300 models, use memory 0xc8000-0xcffff.
|
|||
|
|
|||
|
<20> On the BMX 486DX2-66, exclude irq 5, irq 9.
|
|||
|
|
|||
|
<20> On the Chicony NB5, use memory 0xda000-0xdffff.
|
|||
|
|
|||
|
<20> On the Compaq Presario 900Z, exclude port 0x3b0-0x3bb.
|
|||
|
|
|||
|
<20> On the Compaq Presario 1020, exclude port 0x2f8-0x2ff, irq 3, irq
|
|||
|
5.
|
|||
|
|
|||
|
<20> On the Compaq Presario 2120EA, exclude irq 10.
|
|||
|
|
|||
|
<20> On the Dell Inspiron 7000, exclude irq 3, irq 5.
|
|||
|
|
|||
|
<20> On the Dell Inspiron 8000, exclude port 0x800-0x8ff.
|
|||
|
|
|||
|
<20> On the Fujitsu C series, exclude port 0x200-0x27f.
|
|||
|
|
|||
|
<20> On the HP Omnibook 4000C, exclude port 0x300-0x30f.
|
|||
|
|
|||
|
<20> On the HP Omnibook 4100, exclude port 0x220-0x22f.
|
|||
|
|
|||
|
<20> On the IBM ThinkPad 380, and maybe the 385 and 600 series, exclude
|
|||
|
port 0x230-0x233, and irq 5.
|
|||
|
|
|||
|
<20> On IBM ThinkPad 600 and 770 models with internal modems, exclude
|
|||
|
port 0x2f8-0x2ff.
|
|||
|
|
|||
|
<20> On the IBM ThinkPad 600E and 770Z, change the high memory window to
|
|||
|
0x60000000-0x60ffffff.
|
|||
|
|
|||
|
<20> On the Micron Millenia Transport, exclude irq 5, irq 9.
|
|||
|
|
|||
|
<20> On the NEC Versa M, exclude irq 9, port 0x2e0-2ff.
|
|||
|
|
|||
|
<20> On the NEC Versa P/75, exclude irq 5, irq 9.
|
|||
|
|
|||
|
<20> On the NEC Versa S, exclude irq 9, irq 12.
|
|||
|
|
|||
|
<20> On the NEC Versa 6000 series, exclude port 0x2f8-0x33f, irq 9, irq
|
|||
|
10.
|
|||
|
|
|||
|
<20> On the NEC Versa SX, exclude port 0x300-0x31f.
|
|||
|
|
|||
|
|
|||
|
<20> On the ProStar 9200, Altima Virage, and Acquiline Hurricane
|
|||
|
DX4-100, exclude irq 5, port 0x330-0x35f. Maybe use memory
|
|||
|
0xd8000-0xdffff.
|
|||
|
|
|||
|
<20> On the Siemens Nixdorf SIMATIC PG 720C, use memory 0xc0000-0xcffff,
|
|||
|
port 0x300-0x3bf.
|
|||
|
|
|||
|
<20> On the TI TravelMate 5000, use memory 0xd4000-0xdffff.
|
|||
|
|
|||
|
<20> On the Toshiba Satellite 4030CDS, exclude irq 9.
|
|||
|
|
|||
|
<20> On the Toshiba T4900 CT, exclude irq 5, port 0x2e0-0x2e8, port
|
|||
|
0x330-0x338.
|
|||
|
|
|||
|
<20> On the Toshiba Tecra 8000, exclude irq 3, irq 5, irq 9.
|
|||
|
|
|||
|
<20> On the Twinhead 5100, HP 4000, Sharp PC-8700 and PC-8900, exclude
|
|||
|
irq 9 (sound), irq 12.
|
|||
|
|
|||
|
<20> On an MPC 800 Series, exclude irq 5, port 0x300-0x30f for the CD-
|
|||
|
ROM.
|
|||
|
|
|||
|
|
|||
|
2.5.1. PowerBook specific settings
|
|||
|
|
|||
|
On PowerPC based PowerBook systems, the default system resources in
|
|||
|
/etc/pcmcia/config.opts file are no good at all. Replace all the IO
|
|||
|
port and window definitions with something like:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
include port 0x100-0x4ff, port 0x1000-0x17ff
|
|||
|
include memory 0x80000000-0x80ffffff
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2.6. Notes about specific Linux distributions
|
|||
|
|
|||
|
This section is incomplete. Corrections and additions are welcome.
|
|||
|
|
|||
|
|
|||
|
2.6.1. Debian
|
|||
|
|
|||
|
Debian uses a System V boot script arrangement. The PCMCIA startup
|
|||
|
script is installed as /etc/init.d/pcmcia. New packages use
|
|||
|
/etc/default/pcmcia for startup options; older versions used
|
|||
|
/etc/pcmcia.conf for this purpose. Debian's syslog configuration will
|
|||
|
place kernel messages in /var/log/messages and cardmgr messages in
|
|||
|
/var/log/daemon.log.
|
|||
|
|
|||
|
Debian distributes the PCMCIA system in two packages: the ``pcmcia-
|
|||
|
cs'' package contains cardmgr and other tools, man pages, and
|
|||
|
configuration scripts; and the ``pcmcia-modules'' package contains the
|
|||
|
kernel driver modules.
|
|||
|
|
|||
|
Starting with 3.1.25, a clean PCMCIA install will identify Debian
|
|||
|
systems and create a special network.opts file that, in the absence of
|
|||
|
other network configuration settings, uses Debian's ifup and ifdown
|
|||
|
commands to configure a network card based on settings in
|
|||
|
/etc/network/interfaces.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
2.6.2. Red Hat, Caldera, Mandrake
|
|||
|
|
|||
|
These distributions use a System V boot script organization. The
|
|||
|
PCMCIA startup script is installed as /etc/rc.d/init.d/pcmcia, and
|
|||
|
boot options are kept in /etc/sysconfig/pcmcia. Beware that
|
|||
|
installing the Red Hat package may install a default boot option file
|
|||
|
that has PCMCIA disabled. To enable PCMCIA, the ``PCMCIA'' variable
|
|||
|
should be set to ``yes''. Red Hat's default syslogd configuration
|
|||
|
will record all interesting messages in /var/log/messages.
|
|||
|
|
|||
|
Red Hat's PCMCIA package contains a replacement for the network setup
|
|||
|
script, /etc/pcmcia/network, which meshes with the Red Hat linuxconf
|
|||
|
configuration system. This is convenient for the case where just one
|
|||
|
network adapter is used, with one set of network parameters, but does
|
|||
|
not have the full flexibility of the regular PCMCIA network script.
|
|||
|
Compiling and installing a clean PCMCIA source distribution will
|
|||
|
overwrite the network script, breaking the link to the Red Hat tools.
|
|||
|
If you prefer using the Red Hat tools, either use only Red Hat RPM's,
|
|||
|
or replace /etc/pcmcia/network.opts with the following:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
if [ -f /etc/sysconfig/network-scripts/ifcfg-$2 ] ; then
|
|||
|
start_fn () {
|
|||
|
. /etc/sysconfig/network-scripts/ifcfg-$1
|
|||
|
if [ "$ONBOOT" = "yes" ] ; then /sbin/ifup $1 ; fi
|
|||
|
}
|
|||
|
stop_fn () {
|
|||
|
/sbin/ifdown $1
|
|||
|
}
|
|||
|
fi
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Starting with the 3.1.22 release, the PCMCIA installation script will
|
|||
|
automatically append a variant of this to the default network.opts
|
|||
|
file, so this problem should no longer be an issue.
|
|||
|
|
|||
|
If you do use linuxconf (or netconf) to configure your network
|
|||
|
interface, leave the ``kernel module'', ``I/O port'', and ``irq''
|
|||
|
parameters blank. Setting these parameters may interfere with proper
|
|||
|
operation of the PCMCIA subsystem.
|
|||
|
|
|||
|
At boot time, when the Red Hat network subsystem starts up, it may say
|
|||
|
``Delaying eth0 initialization'' and ``[FAILED]''. This is actually
|
|||
|
not a failure: it means that this network interface will not be
|
|||
|
initialized until after the PCMCIA network device is configured.
|
|||
|
|
|||
|
Red Hat bundles their slightly modified PCMCIA source distribution
|
|||
|
with their kernel sources, rather than as a separate source package.
|
|||
|
When preparing to build a new set of PCMCIA drivers, you will
|
|||
|
generally want to install Red Hat's kernel-source RPM (kernel-
|
|||
|
source-*.i386.rpm), and not the kernel SRPM (kernel-*.src.rpm). The
|
|||
|
SRPM is tailored for building their kernel RPM files, which is not
|
|||
|
exactly what you want. With Red Hat 7.0, the kernel-source RPM also
|
|||
|
includes a mis-configured PCMCIA source tree; if you want to use it,
|
|||
|
delete their PCMCIA config.out file and re-do "make config".
|
|||
|
|
|||
|
|
|||
|
2.6.3. Slackware
|
|||
|
|
|||
|
Slackware uses a BSD boot script arrangement. The PCMCIA startup
|
|||
|
script is installed as /etc/rc.d/rc.pcmcia, and boot options are
|
|||
|
specified in rc.pcmcia itself. The PCMCIA startup script is invoked
|
|||
|
from /etc/rc.d/rc.S.
|
|||
|
2.6.4. SuSE
|
|||
|
|
|||
|
SuSE uses a System V init script arrangement, with init scripts stored
|
|||
|
under /etc/init.d. The PCMCIA startup script is installed as
|
|||
|
/etc/init.d/pcmcia, and startup options are kept in /etc/rc.config.
|
|||
|
Before release 7.0, init scripts were kept under /sbin/init.d. In
|
|||
|
early SuSE releases (pre-5.3), the PCMCIA startup script was somewhat
|
|||
|
limited and did not allow PCMCIA startup variables to be overridden
|
|||
|
from the lilo boot prompt.
|
|||
|
|
|||
|
SuSE 8.0 includes both the standalone PCMCIA modules, and the 2.4
|
|||
|
kernel PCMCIA subsystem modules. A new variable, PCMCIA_SYSTEM, is
|
|||
|
available in /etc/sysconfig/pcmcia to choose between these. It can be
|
|||
|
set to either ``kernel'' or ``external''.
|
|||
|
|
|||
|
To look up current PCMCIA issues in SuSE's support database, go to
|
|||
|
<http://sdb.suse.de/cgi-bin/sdbsearch_en.cgi?stichwort=PCMCIA>.
|
|||
|
|
|||
|
|
|||
|
3. Resolving installation and configuration problems
|
|||
|
|
|||
|
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 client driver or type of card.
|
|||
|
|
|||
|
Before trying to diagnose a problem, you have to know where your
|
|||
|
system log is kept (see ``Notes about specific Linux distributions'').
|
|||
|
You should also be familiar with basic diagnostic tools like dmesg and
|
|||
|
lsmod. Also, be aware that most driver components (including all the
|
|||
|
kernel modules) have their own individual man pages.
|
|||
|
|
|||
|
In 3.1.15 and later releases, the debug-tools subdirectory of the
|
|||
|
PCMCIA source tree has a few scripts to help diagnose some of the most
|
|||
|
common configuration problems. The test_setup script checks your
|
|||
|
PCMCIA installation for completeness. The test_network and test_modem
|
|||
|
scripts will try to diagnose problems with PCMCIA network and modem
|
|||
|
cards. These scripts can be particularly helpful if you are
|
|||
|
unfamiliar with Linux and are not sure how to approach a problem.
|
|||
|
|
|||
|
Try to define your problem as narrowly as possible. If you have
|
|||
|
several cards, try each card in isolation, and in different
|
|||
|
combinations. Try cold Linux boots, versus warm boots from Windows.
|
|||
|
Compare booting with cards inserted, versus inserting cards after
|
|||
|
boot. If you normally use your laptop docked, try it undocked. And
|
|||
|
sometimes, two sockets will behave differently.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
3.1. Base PCMCIA kernel modules do not load
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> Kernel version mismatch errors are reported when the PCMCIA startup
|
|||
|
script runs.
|
|||
|
|
|||
|
<20> After startup, lsmod does not show any PCMCIA modules.
|
|||
|
|
|||
|
<20> 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:
|
|||
|
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
|
|||
|
3.2. Some client driver modules do not load
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> The base modules (pcmcia_core, ds, i82365) load correctly.
|
|||
|
|
|||
|
<20> Inserting a card gives a high beep + low beep pattern.
|
|||
|
|
|||
|
|
|||
|
<20> 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:
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> Support for multiport serial cards or multifunction cards that
|
|||
|
include serial or modem devices requires CONFIG_SERIAL_SHARE_IRQ to
|
|||
|
be enabled.
|
|||
|
|
|||
|
<20> 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.2 and later kernels). These may be
|
|||
|
built as modules.
|
|||
|
|
|||
|
<20> The network client drivers require that CONFIG_INET is enabled.
|
|||
|
Kernel networking support cannot be compiled as a module.
|
|||
|
|
|||
|
<20> The token-ring client requires that the kernel be compiled with
|
|||
|
CONFIG_TR enabled.
|
|||
|
|
|||
|
There are two ways to proceed:
|
|||
|
|
|||
|
<20> Rebuild your kernel with the necessary features enabled.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
|
|||
|
3.3. ISA interrupt scan failures
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> The system locks up when the PCMCIA drivers are loaded, even with
|
|||
|
no cards present.
|
|||
|
|
|||
|
<20> 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:
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
|
|||
|
3.4. IO port scan failures
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
<20> The system log shows a successful host controller probe, including
|
|||
|
interrupt probe results, but does not show IO probe results.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
|
|||
|
3.5. Memory probe failures
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> The core drivers load correctly when no cards are present, with no
|
|||
|
errors in the system log.
|
|||
|
|
|||
|
<20> The system freezes and/or reboots as soon as any card is inserted,
|
|||
|
before any beeps are heard.
|
|||
|
|
|||
|
Or alternately:
|
|||
|
|
|||
|
<20> All card insertions generate a high beep followed by a low beep.
|
|||
|
|
|||
|
<20> All cards are identified as ``anonymous memory cards''.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
|
|||
|
3.6. Failure to detect card insertions and removals
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> Cards are detected and configured properly if present at boot time.
|
|||
|
|
|||
|
<20> The drivers do not respond to insertion and removal events, either
|
|||
|
by recording events in the system log, or by beeping.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
3.7. Interrupt delivery problems
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> Cards appear to be configured successfully, but don't work.
|
|||
|
|
|||
|
<20> Serial and modem cards may respond very sluggishly.
|
|||
|
|
|||
|
<20> 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''.
|
|||
|
|
|||
|
|
|||
|
3.8. System resource starvation
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> When a card is inserted, it is identified correctly but cannot be
|
|||
|
configured (high/low beep pattern).
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
In some cases, kernel misconfiguration can also produce an apparent
|
|||
|
interrupt shortage. On 2.4 and later kernels, if CONFIG_ISA is not
|
|||
|
enabled, then the PCMCIA drivers will assume no ISA bus interrupts are
|
|||
|
available.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
3.9. Resource conflict only with two cards inserted
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> Two cards each work fine when used separately.
|
|||
|
|
|||
|
<20> 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.
|
|||
|
|
|||
|
|
|||
|
3.10. Device configuration does not complete
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> When a card is inserted, exactly one high beep is heard.
|
|||
|
|
|||
|
<20> 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
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4. Usage and features
|
|||
|
|
|||
|
4.1. Tools for configuring and monitoring PCMCIA devices
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
4.1.1. The cardmgr configuration daemon
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
4.1.2. The socket status file, stab
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
In 2.4 and later kernels, hot plut PCI drivers for CardBus cards are
|
|||
|
not managed by cardmgr; they are managed by the hotplug subsystem.
|
|||
|
See <http://linux-hotplug.sourceforge.net> for information about this
|
|||
|
facility. When cardmgr sees a card that is owned by a hot plug PCI
|
|||
|
driver, it will ignore that card. There will be one beep when these
|
|||
|
cards are inserted or ejected, but they will be identified only as a
|
|||
|
``CardBus hotplug device'' in the system log and stab file.
|
|||
|
|
|||
|
|
|||
|
4.1.3. The cardctl and cardinfo utilities
|
|||
|
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
4.1.4. Inserting and ejecting cards
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
4.1.5. Card Services and Advanced Power Management
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
4.1.6. Shutting down the PCMCIA system
|
|||
|
|
|||
|
To unload the entire PCMCIA package, invoke rc.pcmcia with:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
/etc/rc.d/rc.pcmcia stop
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This script will take several seconds to run, to give all client
|
|||
|
drivers time to shut down gracefully. If a device is currently in
|
|||
|
use, the shutdown will be incomplete, and some kernel modules may not
|
|||
|
be unloaded. To avoid this, use ``cardctl eject'' to shut down all
|
|||
|
sockets before invoking rc.pcmcia. The exit status of the cardctl
|
|||
|
command will indicate if any sockets could not be shut down.
|
|||
|
|
|||
|
|
|||
|
4.2. Overview of the PCMCIA configuration scripts
|
|||
|
|
|||
|
The following information applies to cards that are managed by
|
|||
|
cardmgr. In 2.4 and later kernels, if the kernel PCMCIA subsystem is
|
|||
|
active, then CardBus cards are managed by the hotplug subsystem and
|
|||
|
the PCMCIA scripts are not used.
|
|||
|
|
|||
|
Each PCMCIA device has an associated ``class'' that describes how it
|
|||
|
should be configured and managed. Classes are associated with device
|
|||
|
drivers in /etc/pcmcia/config. There are currently five IO device
|
|||
|
classes (network, SCSI, cdrom, fixed disk, and serial) and two memory
|
|||
|
device classes (memory and FTL). For each class, there are two
|
|||
|
scripts in /etc/pcmcia: a main configuration script (i.e.,
|
|||
|
/etc/pcmcia/scsi for SCSI devices), and an options script (i.e.,
|
|||
|
/etc/pcmcia/scsi.opts). The main script for a device will be invoked
|
|||
|
to configure that device when a card is inserted, and to shut down the
|
|||
|
device when the card is removed. For cards with several associated
|
|||
|
devices, the script will be invoked for each device.
|
|||
|
|
|||
|
The config scripts start by extracting some information about a device
|
|||
|
from the stab file. Each script constructs a ``device address'', that
|
|||
|
uniquely describes the device it has been asked to configure, in the
|
|||
|
ADDRESS shell variable. This is passed to the *.opts script, which
|
|||
|
should return information about how a device at this address should be
|
|||
|
configured. For some devices, the device address is just the socket
|
|||
|
number. For others, it includes extra information that may be useful
|
|||
|
in deciding how to configure the device. For example, network devices
|
|||
|
pass their hardware ethernet address as part of the device address, so
|
|||
|
the network.opts script could use this to select from several
|
|||
|
different configurations.
|
|||
|
|
|||
|
The first part of all device addresses is the current PCMCIA
|
|||
|
``scheme''. This parameter is used to support multiple sets of device
|
|||
|
configurations based on a single external user-specified variable.
|
|||
|
One use of schemes would be to have a ``home'' scheme, and a ``work''
|
|||
|
scheme, which would include different sets of network configuration
|
|||
|
parameters. The current scheme is selected using the ``cardctl
|
|||
|
scheme'' command. The default if no scheme is set is ``default''.
|
|||
|
|
|||
|
There are a few additional shell variables that can be used in *.opts
|
|||
|
files in addition to ADDRESS:
|
|||
|
|
|||
|
|
|||
|
SOCKET, CLASS, DRIVER, INSTANCE, DEVICE, MAJOR, MINOR
|
|||
|
These correspond to individual fields from one line in the stab
|
|||
|
file. See its man page for details.
|
|||
|
|
|||
|
PRODID_1, PRODID_2, PRODID_3, PRODID_4, MANFID, FUNCID
|
|||
|
These are equivalent to the output of ``cardctl info'' and give
|
|||
|
more detailed card identification information.
|
|||
|
|
|||
|
As the *.opts files are just shell scripts, it is not required that
|
|||
|
they follow the form of the examples, which just return settings based
|
|||
|
on ADDRESS.
|
|||
|
|
|||
|
As a general rule, when configuring Linux for a laptop, PCMCIA devices
|
|||
|
should only be configured from the PCMCIA device scripts. Do not try
|
|||
|
to configure a PCMCIA device the same way you would configure a
|
|||
|
permanently attached device. However, some Linux distributions
|
|||
|
provide PCMCIA packages that are hooked into those distributions' own
|
|||
|
device configuration tools. In that case, some of the following
|
|||
|
sections may not apply; ideally, this will be documented by the
|
|||
|
distribution maintainers.
|
|||
|
|
|||
|
|
|||
|
4.3. PCMCIA network adapters
|
|||
|
|
|||
|
Linux ethernet-type network interfaces normally have names like eth0,
|
|||
|
eth1, and so on. Token-ring adapters are handled similarly, however
|
|||
|
they are named tr0, tr1, and so on. The ifconfig command is used to
|
|||
|
view or modify the state of a network interface. A peculiarity of
|
|||
|
Linux is that network interfaces do not have corresponding device
|
|||
|
files under /dev, so do not be surprised when you do not find them.
|
|||
|
|
|||
|
When an ethernet card is detected, it will be assigned the first free
|
|||
|
interface name, which will normally be eth0. Cardmgr will run the
|
|||
|
/etc/pcmcia/network script to configure the interface, which normally
|
|||
|
reads network settings from /etc/pcmcia/network.opts. The network and
|
|||
|
network.opts scripts will be executed only when your ethernet card is
|
|||
|
actually present. If your system has an automatic network
|
|||
|
configuration facility, it may or may not be PCMCIA-aware. Consult
|
|||
|
the documentation of your Linux distribution and the ``Notes about
|
|||
|
specific Linux distributions'' to determine if PCMCIA network devices
|
|||
|
should be configured with the automatic tools, or by editing
|
|||
|
network.opts.
|
|||
|
|
|||
|
The device address passed to network.opts consists of four comma-
|
|||
|
separated fields: the scheme, the socket number, the device instance,
|
|||
|
and the card's hardware ethernet address. The device instance is used
|
|||
|
to number devices for cards that have several network interfaces, so
|
|||
|
it will usually be 0. If you have several network cards used for
|
|||
|
different purposes, one option would be to configure the cards based
|
|||
|
on socket position, as in:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
case "$ADDRESS" in
|
|||
|
*,0,*,*)
|
|||
|
# definitions for network card in socket 0
|
|||
|
;;
|
|||
|
*,1,*,*)
|
|||
|
# definitions for network card in socket 1
|
|||
|
;;
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Alternatively, they could be configured using their hardware
|
|||
|
addresses, as in:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
case "$ADDRESS" in
|
|||
|
*,*,*,00:80:C8:76:00:B1)
|
|||
|
# definitions for a D-Link card
|
|||
|
;;
|
|||
|
*,*,*,08:00:5A:44:80:01)
|
|||
|
# definitions for an IBM card
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.3.1. Network device parameters
|
|||
|
|
|||
|
The following parameters can be defined in network.opts:
|
|||
|
|
|||
|
|
|||
|
IF_PORT
|
|||
|
Specifies the ethernet transceiver type, for certain 16-bit
|
|||
|
cards that do not autodetect. See ``man ifport'' and ``man mii-
|
|||
|
tool'' for more information.
|
|||
|
|
|||
|
BOOTP
|
|||
|
A boolean (y/n) value: indicates if the host's IP address and
|
|||
|
routing information should be obtained using the BOOTP protocol,
|
|||
|
with bootpc or pump.
|
|||
|
|
|||
|
DHCP
|
|||
|
A boolean (y/n) value: indicates if the host's IP address and
|
|||
|
routing information should be obtained from a DHCP server. The
|
|||
|
network script first looks for dhcpcd, then dhclient, then pump.
|
|||
|
|
|||
|
DHCP_HOSTNAME
|
|||
|
Specifies a hostname to be passed to dhcpcd or pump, for
|
|||
|
inclusion in DHCP messages.
|
|||
|
IPADDR
|
|||
|
The IP address for this interface.
|
|||
|
|
|||
|
NETMASK, BROADCAST, NETWORK
|
|||
|
Basic network parameters: see the networking HOWTO for more
|
|||
|
information.
|
|||
|
|
|||
|
GATEWAY
|
|||
|
The IP address of a gateway for this host's subnet. Packets
|
|||
|
with destinations outside this subnet will be routed to this
|
|||
|
gateway.
|
|||
|
|
|||
|
DOMAIN
|
|||
|
The local network domain name for this host, to be used in
|
|||
|
creating /etc/resolv.conf.
|
|||
|
|
|||
|
SEARCH
|
|||
|
A search list for host name lookup, to be added to
|
|||
|
/etc/resolv.conf. DOMAIN and SEARCH are mutually exclusive: see
|
|||
|
``man resolver'' for more information.
|
|||
|
|
|||
|
DNS_1, DNS_2, DNS_3
|
|||
|
Host names or IP addresses for nameservers for this interface,
|
|||
|
to be added to /etc/resolv.conf
|
|||
|
|
|||
|
MOUNTS
|
|||
|
A space-separated list of NFS mount points to be mounted for
|
|||
|
this interface.
|
|||
|
|
|||
|
IPX_FRAME, IPX_NETNUM
|
|||
|
For IPX networks: the frame type and network number, passed to
|
|||
|
the ipx_interface command.
|
|||
|
|
|||
|
NO_CHECK, NO_FUSER
|
|||
|
Boolean (y/n) settings for card eject policy. If NO_CHECK is
|
|||
|
set, then ``cardctl eject'' will shut down a device even if
|
|||
|
there are open connections. If NO_FUSER is set, then the script
|
|||
|
will not check for busy NFS mounts or kill processes using those
|
|||
|
mounts.
|
|||
|
|
|||
|
For example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
case "$ADDRESS" in
|
|||
|
*,*,*,*)
|
|||
|
IF_PORT="10base2"
|
|||
|
BOOTP="n"
|
|||
|
IPADDR="10.0.0.1"
|
|||
|
NETMASK="255.255.255.0"
|
|||
|
NETWORK="10.0.0.0"
|
|||
|
BROADCAST="10.0.0.255"
|
|||
|
GATEWAY="10.0.0.1"
|
|||
|
DOMAIN="domain.org"
|
|||
|
DNS_1="dns1.domain.org"
|
|||
|
;;
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
To automatically mount and unmount NFS filesystems, first add all
|
|||
|
these filesystems to /etc/fstab, but include noauto in the mount
|
|||
|
options. In network.opts, list the filesystem mount points in the
|
|||
|
MOUNTS variable. It is especially important to use either cardctl or
|
|||
|
cardinfo to shut down a network card when NFS mounts are active. It
|
|||
|
is not possible to cleanly unmount NFS filesystems if a network card
|
|||
|
is simply ejected without warning.
|
|||
|
|
|||
|
In addition to the usual network configuration parameters, the
|
|||
|
network.opts script can specify extra actions to be taken after an
|
|||
|
interface is configured, or before an interface is shut down. If
|
|||
|
network.opts defines a shell function called start_fn, it will be
|
|||
|
invoked by the network script after the interface is configured, and
|
|||
|
the interface name will be passed to the function as its first (and
|
|||
|
only) argument. Similarly, if it is defined, stop_fn will be invoked
|
|||
|
before shutting down an interface.
|
|||
|
|
|||
|
The transceiver type for some (mostly old) cards must be manually be
|
|||
|
selected using the IF_PORT setting. This can either be a numeric
|
|||
|
value, or a keyword identifying the transceiver type. All the network
|
|||
|
drivers default to either autodetect the interface if possible, or
|
|||
|
10baseT otherwise. The ifport command can be used to check or set the
|
|||
|
current transceiver type. For example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
# ifport eth0 10base2
|
|||
|
#
|
|||
|
# ifport eth0
|
|||
|
eth0 2 (10base2)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Most modern 10/100baseT cards use a ``media independent interface''
|
|||
|
(MII) transceiver that automatically selects line speed and duplex
|
|||
|
setting. The mii-tool command can be used to monitor and control the
|
|||
|
behavior of the MII interface.
|
|||
|
|
|||
|
|
|||
|
4.3.2. Comments about specific cards
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> With IBM CCAE and Socket EA cards, the transceiver type (10base2,
|
|||
|
10baseT, AUI) needs to be set when the network device is
|
|||
|
configured. Make sure that the transceiver type reported in the
|
|||
|
system log matches your connection.
|
|||
|
|
|||
|
<20> The Farallon EtherWave is actually based on the 3Com 3c589, with a
|
|||
|
special transceiver. Though the EtherWave uses 10baseT-style
|
|||
|
connections, its transceiver requires that the 3c589 be configured
|
|||
|
in 10base2 mode.
|
|||
|
|
|||
|
<20> If you have trouble with an IBM CCAE, NE4100, Thomas Conrad, or
|
|||
|
Kingston adapter, try increasing the memory access time with the
|
|||
|
mem_speed=# option to the pcnet_cs module. An example of how to do
|
|||
|
this is given in the standard config.opts file. Try speeds of up
|
|||
|
to 1000 (in nanoseconds).
|
|||
|
|
|||
|
<20> For the New Media Ethernet adapter, on some systems, it may be
|
|||
|
necessary to increase the IO port access time with the io_speed=#
|
|||
|
option when the pcmcia_core module is loaded. Edit CORE_OPTS in
|
|||
|
the startup script to set this option.
|
|||
|
|
|||
|
<20> The multicast support in the New Media Ethernet driver is
|
|||
|
incomplete. The latest driver will function with multicast
|
|||
|
kernels, but will ignore multicast packets. Promiscuous mode
|
|||
|
should work properly.
|
|||
|
|
|||
|
|
|||
|
<20> The driver used by the IBM and 3Com token ring adapters seems to
|
|||
|
behave very badly if the cards are not connected to a ring when
|
|||
|
they get initialized. Always connect these cards to the net before
|
|||
|
they are powered up. If ifconfig reports the hardware address as
|
|||
|
all 0's, this is likely to be due to a memory window configuration
|
|||
|
problem.
|
|||
|
|
|||
|
<20> Some Linksys, D-Link, and IC-Card 10baseT/10base2 cards have a
|
|||
|
unique way of selecting the transceiver type that isn't handled by
|
|||
|
the Linux drivers. One workaround is to boot DOS and use the
|
|||
|
vendor-supplied utility to select the transceiver, then warm boot
|
|||
|
Linux. Alternatively, a Linux utility to perform this function is
|
|||
|
available at <http://pcmcia-
|
|||
|
cs.sourceforge.net/ftp/extras/dlport.c>.
|
|||
|
|
|||
|
<20> 16-bit PCMCIA cards have a maximum performance of 1.5-2 MB/sec.
|
|||
|
That means that any 16-bit 100baseT card (i.e., any card that uses
|
|||
|
the pcnet_cs, 3c574_cs, smc91c92_cs, or xirc2ps_cs driver) will
|
|||
|
never achieve full 100baseT throughput. Only CardBus network
|
|||
|
adapters can fully exploit 100baseT data rates.
|
|||
|
|
|||
|
<20> For WaveLAN wireless network adapters, Jean Tourrilhes
|
|||
|
(jt@hpl.hp.com) has put together a wireless HOWTO at
|
|||
|
<http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/>.
|
|||
|
|
|||
|
|
|||
|
4.3.3. Diagnosing problems with network adapters
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> In 3.1.15 and later PCMCIA releases, the test_network script in the
|
|||
|
debug-tools subdirectory of the PCMCIA source tree will spot some
|
|||
|
common problems.
|
|||
|
|
|||
|
<20> Is your card recognized as an ethernet card? Check the system log
|
|||
|
and make sure that cardmgr identifies the card correctly and starts
|
|||
|
up one of the network drivers. If it doesn't, your card might
|
|||
|
still be usable if it is compatible with a supported card. This
|
|||
|
will be most easily done if the card claims to be ``NE2000
|
|||
|
compatible''.
|
|||
|
|
|||
|
<20> Is the card configured properly? If you are using a supported
|
|||
|
card, and it was recognized by cardmgr, but still doesn't work,
|
|||
|
there might be an interrupt or port conflict with another device.
|
|||
|
Find out what resources the card is using (from the system log),
|
|||
|
and try excluding these in /etc/pcmcia/config.opts to force the
|
|||
|
card to use something different.
|
|||
|
|
|||
|
<20> If your card seems to be configured properly, but sometimes locks
|
|||
|
up, particularly under high load, you may need to try changing your
|
|||
|
socket driver timing parameters. See the ``Startup options''
|
|||
|
section for more information.
|
|||
|
|
|||
|
<20> If you get ``Network is unreachable'' messages when you try to
|
|||
|
access the network, then the routing information specified in
|
|||
|
/etc/pcmcia/network.opts is incorrect. This exact message is an
|
|||
|
absolutely foolproof indication of a routing error. On the other
|
|||
|
hand, mis-configured cards will usually fail silently.
|
|||
|
|
|||
|
<20> If you are trying to use DHCP to configure your network interface,
|
|||
|
try testing things with a static IP address instead, to rule out a
|
|||
|
DHCP configuration problem.
|
|||
|
|
|||
|
<20> To diagnose problems in /etc/pcmcia/network.opts, start by trying
|
|||
|
to ping other systems on the same subnet using their IP addresses.
|
|||
|
Then try to ping your gateway, and then machines on other subnets.
|
|||
|
Ping machines by name only after trying these simpler tests.
|
|||
|
|
|||
|
<20> Make sure your problem is really a PCMCIA one. It may help to see
|
|||
|
see if the card works under DOS with the vendor's drivers. Double
|
|||
|
check your modifications to the /etc/pcmcia/network.opts script.
|
|||
|
Make sure your drop cable, ``T'' jack, terminator, etc are working.
|
|||
|
|
|||
|
<20> Use real network cables. Don't even think about using that old
|
|||
|
phone cord you found in your basement. And this means Category 5
|
|||
|
cable for 100baseT. It really matters.
|
|||
|
|
|||
|
|
|||
|
4.4. PCMCIA serial and modem devices
|
|||
|
|
|||
|
Linux serial devices are accessed via the /dev/ttyS* and /dev/cua*
|
|||
|
special device files. In pre-2.2 kernels, the ttyS* devices were for
|
|||
|
incoming connections, such as directly connected terminals, and the
|
|||
|
cua* devices were for outgoing connections, such as modems. Use of
|
|||
|
cua* devices is deprecated in current kernels, and ttyS* can be used
|
|||
|
for all applications. The configuration of a serial device can be
|
|||
|
examined and modified with the setserial command.
|
|||
|
|
|||
|
When a serial or modem card is detected, it will be assigned to the
|
|||
|
first available serial device slot. This will usually be /dev/ttyS1
|
|||
|
(cua1) or /dev/ttyS2 (cua2), depending on the number of built-in
|
|||
|
serial ports. The ttyS* device is the one reported in stab. The
|
|||
|
default serial device option script, /etc/pcmcia/serial.opts, will
|
|||
|
link the device file to /dev/modem as a convenience. For pre-2.2
|
|||
|
kernels, the link is made to the cua* device.
|
|||
|
|
|||
|
Do not try to use /etc/rc.d/rc.serial to configure a PCMCIA modem.
|
|||
|
This script should only be used to configure non-removable devices.
|
|||
|
Modify /etc/pcmcia/serial.opts if you want to do anything special to
|
|||
|
set up your modem. Also, do not try to change the IO port and
|
|||
|
interrupt settings of a serial device using setserial. This would
|
|||
|
tell the serial driver to look for the device in a different place,
|
|||
|
but would not change how the card's hardware is actually configured.
|
|||
|
The serial configuration script allows you to specify other setserial
|
|||
|
options, as well as whether a line should be added to /etc/inittab for
|
|||
|
this port.
|
|||
|
|
|||
|
The device address passed to serial.opts has three comma-separated
|
|||
|
fields: the first is the scheme, the second is the socket number, and
|
|||
|
the third is the device instance. The device instance may take
|
|||
|
several values for cards that support multiple serial ports, but for
|
|||
|
single-port cards, it will always be 0. If you commonly use more than
|
|||
|
one modem, you may want to specify different settings based on socket
|
|||
|
position, as in:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
case "$ADDRESS" in
|
|||
|
*,0,*)
|
|||
|
# Options for modem in socket 0
|
|||
|
LINK=/dev/modem0
|
|||
|
;;
|
|||
|
*,1,*)
|
|||
|
# Options for modem in socket 1
|
|||
|
LINK=/dev/modem1
|
|||
|
;;
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If a PCMCIA modem is already configured when Linux boots, it may be
|
|||
|
incorrectly identified as an ordinary built-in serial port. This is
|
|||
|
harmless, however, when the PCMCIA drivers take control of the modem,
|
|||
|
it will be assigned a different device slot. It is best to either
|
|||
|
parse stab or use /dev/modem, rather than expecting a PCMCIA modem to
|
|||
|
always have the same device assignment.
|
|||
|
|
|||
|
If you configure your kernel to load the basic Linux serial port
|
|||
|
driver as a module, you must edit /etc/pcmcia/config to indicate that
|
|||
|
this module must be loaded. Edit the serial device entry to read:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
device "serial_cs"
|
|||
|
class "serial" module "misc/serial", "serial_cs"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.4.1. Serial device parameters
|
|||
|
|
|||
|
The following parameters can be defined in serial.opts:
|
|||
|
|
|||
|
LINK
|
|||
|
Specifies a path for a symbolic link to be created to the
|
|||
|
``callout'' device (e.g., /dev/cua* for pre-2.2, or /dev/ttyS*
|
|||
|
for 2.2 kernels).
|
|||
|
|
|||
|
SERIAL_OPTS
|
|||
|
Specifies options to be passed to the setserial command.
|
|||
|
|
|||
|
INITTAB
|
|||
|
If specified, this will be used to construct an inittab entry
|
|||
|
for the device.
|
|||
|
|
|||
|
NO_CHECK, NO_FUSER
|
|||
|
Boolean (y/n) settings for card eject policy. If NO_CHECK is
|
|||
|
true, then ``cardctl eject'' will shut down a device even if it
|
|||
|
is busy. If NO_FUSER is true, then the script will not try to
|
|||
|
kill processes using an ejected device.
|
|||
|
|
|||
|
For example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
case "$ADDRESS" in
|
|||
|
*,*,*)
|
|||
|
LINK="/dev/modem"
|
|||
|
SERIAL_OPTS=""
|
|||
|
INITTAB="/sbin/getty"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.4.2. Comments about specific cards
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> The Uniden Data 2000 Wireless CDPD card has some special dialing
|
|||
|
strings for initiating SLIP and PPP mode. For SLIP, use ``ATDT2'';
|
|||
|
for PPP, "ATDT0".
|
|||
|
|
|||
|
<20> Socket IO revision H serial port cards have a faster-than-normal
|
|||
|
clock rate for the UART. The card's actual baud rate is four times
|
|||
|
faster than the serial driver thinks it is. To work around the
|
|||
|
problem, specify SERIAL_OPTS="baud_base 460800" in
|
|||
|
/etc/pcmcia/serial.opts.
|
|||
|
|
|||
|
|
|||
|
4.4.3. Diagnosing problems with serial devices
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> In 3.1.15 and later PCMCIA releases, the test_modem script in the
|
|||
|
debug-tools subdirectory of the PCMCIA source tree will spot some
|
|||
|
common problems.
|
|||
|
|
|||
|
<20> Is your card recognized as a modem? Check the system log and make
|
|||
|
sure that cardmgr identifies the card correctly and starts up the
|
|||
|
serial_cs driver. If it doesn't, you may need to add a new entry
|
|||
|
to your /etc/pcmcia/config file so that it will be identified
|
|||
|
properly. See the ``Configuring unrecognized cards'' section for
|
|||
|
details.
|
|||
|
|
|||
|
<20> Is the modem configured successfully by serial_cs? Again, check
|
|||
|
the system log and look for messages from the serial_cs driver. If
|
|||
|
you see ``register_serial() failed'', you may have an I/O port
|
|||
|
conflict with another device. Another tip-off of a conflict is if
|
|||
|
the device is reported to be an 8250; most modern modems should be
|
|||
|
identified as 16550A UART's. If you think you're seeing a port
|
|||
|
conflict, edit /etc/pcmcia/config.opts and exclude the port range
|
|||
|
that was allocated for the modem.
|
|||
|
|
|||
|
<20> Is there an interrupt conflict? If the system log looks good, but
|
|||
|
the modem just doesn't seem to work, try using setserial to change
|
|||
|
the irq to 0, and see if the modem works. This causes the serial
|
|||
|
driver to use a slower polled mode instead of using interrupts. If
|
|||
|
this seems to fix the problem, it is likely that some other device
|
|||
|
in your system is using the interrupt selected by serial_cs. You
|
|||
|
should add a line to /etc/pcmcia/config.opts to exclude this
|
|||
|
interrupt.
|
|||
|
|
|||
|
<20> If the modem seems to work only very, very slowly, this is an
|
|||
|
almost certain indicator of an interrupt conflict.
|
|||
|
|
|||
|
<20> Make sure your problem is really a PCMCIA one. It may help to see
|
|||
|
if the card works under DOS with the vendor's drivers. Also, don't
|
|||
|
test the card with something complex like SLIP or PPP until you are
|
|||
|
sure you can make simple connections. If simple things work but
|
|||
|
SLIP does not, your problem is most likely with SLIP, not with
|
|||
|
PCMCIA.
|
|||
|
|
|||
|
<20> If you get kernel messages indicating that the serial_cs module
|
|||
|
cannot be loaded, it means that your kernel does not have serial
|
|||
|
device support. If you have compiled the serial driver as a
|
|||
|
module, you must modify /etc/pcmcia/config to indicate that the
|
|||
|
serial module should be loaded before serial_cs.
|
|||
|
|
|||
|
|
|||
|
4.5. PCMCIA parallel port devices
|
|||
|
|
|||
|
The Linux parallel port driver is layered so that several high-level
|
|||
|
device types can share use of the same low level port driver. Printer
|
|||
|
devices are accessed via the /dev/lp* special device files. The
|
|||
|
configuration of a printer device can be examined and modified with
|
|||
|
the tunelp command.
|
|||
|
|
|||
|
The parport_cs module depends on the parport and parport_pc drivers,
|
|||
|
which may be either compiled into the kernel or compiled as modules.
|
|||
|
The layered driver structure means that any top-level parallel drivers
|
|||
|
(such as the plip driver, the printer driver, etc) must be compiled as
|
|||
|
modules. These drivers only recognize parallel port devices at module
|
|||
|
startup time, so they need to be loaded after any PC Card parallel
|
|||
|
devices are configured.
|
|||
|
|
|||
|
The device address passed to parport.opts has three comma-separated
|
|||
|
fields: the first is the scheme, the second is the socket number, and
|
|||
|
the third is the device instance. The device instance may take
|
|||
|
several values for cards that support multiple parallel ports, but for
|
|||
|
single-port cards, it will always be 0. If you commonly use more than
|
|||
|
one such card, you may want to specify different settings based on
|
|||
|
socket position, as in:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
case "$ADDRESS" in
|
|||
|
*,0,*)
|
|||
|
# Options for card in socket 0
|
|||
|
LINK=/dev/printer0
|
|||
|
;;
|
|||
|
*,1,*)
|
|||
|
# Options for card in socket 1
|
|||
|
LINK=/dev/printer1
|
|||
|
;;
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.5.1. Parallel device parameters
|
|||
|
|
|||
|
The following parameters can be defined in parport.opts:
|
|||
|
|
|||
|
LINK
|
|||
|
Specifies a path for a symbolic link to be created to the
|
|||
|
printer port.
|
|||
|
|
|||
|
LP_OPTS
|
|||
|
Specifies options to be passed to the tunelp command.
|
|||
|
|
|||
|
NO_CHECK, NO_FUSER
|
|||
|
Boolean (y/n) settings for card eject policy. If NO_CHECK is
|
|||
|
true, then ``cardctl eject'' will shut down a device even if it
|
|||
|
is busy. If NO_FUSER is true, then the script will not try to
|
|||
|
kill processes using an ejected device.
|
|||
|
|
|||
|
For example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
case "$ADDRESS" in
|
|||
|
*,*,*,*)
|
|||
|
LINK="/dev/printer"
|
|||
|
LP_OPTS=""
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.5.2. Diagnosing problems with parallel port devices
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> Is there an interrupt conflict? If the system log looks good, but
|
|||
|
the port just doesn't seem to work, try using tunelp to change the
|
|||
|
irq to 0, and see if things improve. This switches the driver to
|
|||
|
polling mode. If this seems to fix the problem, it is likely that
|
|||
|
some other device in your system is using the interrupt selected by
|
|||
|
parport_cs. You should add a line to /etc/pcmcia/config.opts to
|
|||
|
exclude this interrupt.
|
|||
|
|
|||
|
<20> If you get kernel messages indicating that the parport_cs module
|
|||
|
cannot be loaded, it means that your kernel does not have parallel
|
|||
|
device support. If you have compiled the parallel driver as a
|
|||
|
module, you may need to modify /etc/pcmcia/config to indicate that
|
|||
|
the parport and parport_pc modules should be loaded before
|
|||
|
parport_cs.
|
|||
|
|
|||
|
|
|||
|
4.6. PCMCIA SCSI adapters
|
|||
|
|
|||
|
All the currently supported PCMCIA SCSI cards are work-alikes of one
|
|||
|
of the following ISA bus cards: the Qlogic, the Adaptec AHA-152X, or
|
|||
|
the Future Domain TMC-16x0. The PCMCIA drivers are built by linking
|
|||
|
some PCMCIA-specific code (in qlogic_cs.c, aha152x_cs.c, or
|
|||
|
fdomain_cs.c) with the normal Linux SCSI driver, pulled from the Linux
|
|||
|
kernel source tree. The Adaptec APA1480 CardBus driver is based on
|
|||
|
the kernel aic7xxx PCI driver. Due to limitations in the Linux SCSI
|
|||
|
driver model, only one removable card per driver is supported.
|
|||
|
|
|||
|
When a new SCSI host adapter is detected, the SCSI drivers will probe
|
|||
|
for devices. Check the system log to make sure your devices are
|
|||
|
detected properly. New SCSI devices will be assigned to the first
|
|||
|
available SCSI device files. The first SCSI disk will be /dev/sda,
|
|||
|
the first SCSI tape will be /dev/st0, and the first CD-ROM will be
|
|||
|
/dev/scd0.
|
|||
|
|
|||
|
A list of SCSI devices connected to this host adapter will be shown in
|
|||
|
stab, and the SCSI configuration script, /etc/pcmcia/scsi, will be
|
|||
|
called once for each attached device, to either configure or shut down
|
|||
|
that device. The default script does not take any actions to
|
|||
|
configure SCSI devices, but will properly unmount filesystems on SCSI
|
|||
|
devices when a card is removed.
|
|||
|
|
|||
|
The device addresses passed to scsi.opts are complicated, because of
|
|||
|
the variety of things that can be attached to a SCSI adapter.
|
|||
|
Addresses consist of either six or seven comma-separated fields: the
|
|||
|
current scheme, the device type, the socket number, the SCSI channel,
|
|||
|
ID, and logical unit number, and optionally, the partition number.
|
|||
|
The device type will be ``sd'' for disks, ``st'' for tapes, ``sr'' for
|
|||
|
CD-ROM devices, and ``sg'' for generic SCSI devices. For most setups,
|
|||
|
the SCSI channel and logical unit number will be 0. For disk devices
|
|||
|
with several partitions, scsi.opts will first be called for the whole
|
|||
|
device, with a five-field address. The script should set the PARTS
|
|||
|
variable to a list of partitions. Then, scsi.opts will be called for
|
|||
|
each partition, with the longer six-field addresses.
|
|||
|
|
|||
|
If your kernel does not have a top-level driver (disk, tape, etc) for
|
|||
|
a particular SCSI device, then the device will not be configured by
|
|||
|
the PCMCIA drivers. As a side effect, the device's name in stab will
|
|||
|
be something like ``sd#nnnn'' where ``nnnn'' is a four-digit hex
|
|||
|
number. This happens when cardmgr is unable to translate a SCSI
|
|||
|
device ID into a corresponding Linux device name.
|
|||
|
|
|||
|
It is possible to modularize the top-level SCSI drivers so that they
|
|||
|
are loaded on demand. To do so, you need to edit /etc/pcmcia/config
|
|||
|
to tell cardmgr which extra modules need to be loaded when your
|
|||
|
adapter is configured. For example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
device "aha152x_cs"
|
|||
|
class "scsi" module "scsi/scsi_mod", "scsi/sd_mod", "aha152x_cs"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
would say to load the core SCSI module and the top-level disk driver
|
|||
|
module before loading the regular PCMCIA driver module.
|
|||
|
|
|||
|
Always turn on SCSI devices before powering up your laptop, or before
|
|||
|
inserting the adapter card, so that the SCSI bus is properly
|
|||
|
terminated when the adapter is configured. Also be very careful about
|
|||
|
ejecting a SCSI adapter. Be sure that all associated SCSI devices are
|
|||
|
unmounted and closed before ejecting the card. The best way to ensure
|
|||
|
this is to use either cardctl or cardinfo to request card removal
|
|||
|
before physically ejecting the card. For now, all SCSI devices should
|
|||
|
be powered up before plugging in a SCSI adapter, and should stay
|
|||
|
connected until after you unplug the adapter and/or power down your
|
|||
|
laptop.
|
|||
|
|
|||
|
There is a potential complication when using these cards that does not
|
|||
|
arise with ordinary ISA bus adapters. The SCSI bus carries a
|
|||
|
``termination power'' signal that is necessary for proper operation of
|
|||
|
ordinary passive SCSI terminators. PCMCIA SCSI adapters do not supply
|
|||
|
termination power, so if it is required, an external device must
|
|||
|
supply it. Some external SCSI devices may be configured to supply
|
|||
|
termination power. Others, such as the Zip Drive and the Syquest EZ-
|
|||
|
Drive, use active terminators that do not depend on it. In some
|
|||
|
cases, it may be necessary to use a special terminator block such as
|
|||
|
the APS SCSI Sentry 2, which has an external power supply. When
|
|||
|
configuring your SCSI device chain, be aware of whether or not any of
|
|||
|
your devices require or can provide termination power.
|
|||
|
|
|||
|
|
|||
|
4.6.1. SCSI device parameters
|
|||
|
|
|||
|
The following parameters can be defined in scsi.opts:
|
|||
|
|
|||
|
LINK
|
|||
|
Specifies a path for a symbolic link to be created to this
|
|||
|
device.
|
|||
|
|
|||
|
DO_FSTAB
|
|||
|
A boolean (y/n) setting: specifies if an entry should be added
|
|||
|
to /etc/fstab for this device.
|
|||
|
|
|||
|
DO_FSCK
|
|||
|
A boolean (y/n) setting: specifies if the filesystem should be
|
|||
|
checked before being mounted, with ``fsck -Ta''.
|
|||
|
|
|||
|
DO_MOUNT
|
|||
|
A boolean (y/n) setting: specifies if this device should be
|
|||
|
automatically mounted at card insertion time.
|
|||
|
|
|||
|
FSTYPE, OPTS, MOUNTPT
|
|||
|
The filesystem type, mount options, and mount point to be used
|
|||
|
for the fstab entry and/or mounting the device.
|
|||
|
|
|||
|
NO_CHECK, NO_FUSER
|
|||
|
Boolean (y/n) settings for card eject policy. If NO_CHECK is
|
|||
|
true, then ``cardctl eject'' will shut down a device even if it
|
|||
|
is busy. If NO_FUSER is true, then the script will not try to
|
|||
|
kill processes using an ejected device.
|
|||
|
|
|||
|
For example, here is a script for configuring a disk device at SCSI ID
|
|||
|
3, with two partitions, and a CD-ROM at SCSI ID 6:
|
|||
|
case "$ADDRESS" in
|
|||
|
*,sd,*,0,3,0)
|
|||
|
# This device has two partitions...
|
|||
|
PARTS="1 2"
|
|||
|
;;
|
|||
|
*,sd,*,0,3,0,1)
|
|||
|
# Options for partition 1:
|
|||
|
# update /etc/fstab, and mount an ext2 fs on /usr1
|
|||
|
DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
|
|||
|
FSTYPE="ext2"
|
|||
|
OPTS=""
|
|||
|
MOUNTPT="/usr1"
|
|||
|
;;
|
|||
|
*,sd,*,0,3,0,2)
|
|||
|
# Options for partition 2:
|
|||
|
# update /etc/fstab, and mount an MS-DOS fs on /usr2
|
|||
|
DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
|
|||
|
FSTYPE="msdos"
|
|||
|
OPTS=""
|
|||
|
MOUNTPT="/usr2"
|
|||
|
;;
|
|||
|
*,sr,*,0,6,0)
|
|||
|
# Options for CD-ROM at SCSI ID 6
|
|||
|
PARTS=""
|
|||
|
DO_FSTAB="y" ; DO_FSCK="n" ; DO_MOUNT="y"
|
|||
|
FSTYPE="iso9660"
|
|||
|
OPTS="ro"
|
|||
|
MOUNTPT="/cdrom"
|
|||
|
;;
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.6.2. Comments about specific cards
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> The Adaptec APA-1480 CardBus card needs a large IO port window (256
|
|||
|
contiguous ports aligned on a 256-port boundary). It may be
|
|||
|
necessary to expand the IO port regions in /etc/pcmcia/config.opts
|
|||
|
to guarantee that such a large window can be found.
|
|||
|
|
|||
|
<20> The Adaptec APA-460 SlimSCSI adapter is not supported. This card
|
|||
|
was originally sold under the Trantor name, and when Adaptec merged
|
|||
|
with Trantor, they continued to sell the Trantor card with an
|
|||
|
Adaptec label. The APA-460 is not compatible with any existing
|
|||
|
Linux driver.
|
|||
|
|
|||
|
<20> I have had one report of a bad interaction between the New Media
|
|||
|
Bus Toaster and a UMAX Astra 1200s scanner. Due to the complexity
|
|||
|
of the SCSI protocol, when diagnosing problems with SCSI devices,
|
|||
|
it is worth considering that incompatible combinations like this
|
|||
|
may exist and may not be documented.
|
|||
|
|
|||
|
|
|||
|
4.6.3. Diagnosing problems with SCSI adapters
|
|||
|
|
|||
|
|
|||
|
<20> With the aha152x_cs driver (used by Adaptec, New Media, and a few
|
|||
|
others), it seems that SCSI disconnect/reconnect support is a
|
|||
|
frequent source of trouble with tape drives. To disable this
|
|||
|
``feature,'' add the following to /etc/pcmcia/config.opts:
|
|||
|
|
|||
|
|
|||
|
module "aha152x_cs" opts "reconnect=0"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> Also with the aha152x_cs driver, certain devices seem to require a
|
|||
|
longer startup delay, controlled via the reset_delay module
|
|||
|
parameter. The Yamaha 4416S CDR drive is one such device. The
|
|||
|
result is the device is identified successfully, then hangs the
|
|||
|
system. In such cases, try:
|
|||
|
|
|||
|
|
|||
|
module "aha152x_cs" opts "reset_delay=500"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> Another potential source of SCSI device probe problems is probing
|
|||
|
of multiple LUN's. If you see successful detection of a device,
|
|||
|
followed by SCSI bus timeouts when LUN 1 for that device is probed,
|
|||
|
then disable the kernel's CONFIG_SCSI_MULTI_LUN option.
|
|||
|
|
|||
|
<20> If you have compiled SCSI support as modules (CONFIG_SCSI is
|
|||
|
``m''), you may need to modify /etc/pcmcia/config to load the SCSI
|
|||
|
modules before the appropriate *_cs driver is loaded.
|
|||
|
|
|||
|
<20> If you get ``aborting command due to timeout'' messages when the
|
|||
|
SCSI bus is probed, you almost certainly have an interrupt
|
|||
|
conflict.
|
|||
|
|
|||
|
<20> If the host driver reports ``no SCSI devices found'', verify that
|
|||
|
your kernel was compiled with the appropriate top-level SCSI
|
|||
|
drivers for your devices (i.e., disk, tape, CD-ROM, and/or
|
|||
|
generic). If a top-level driver is missing, devices of that type
|
|||
|
will be ignored.
|
|||
|
|
|||
|
|
|||
|
4.7. PCMCIA memory cards
|
|||
|
|
|||
|
The memory_cs driver handles all types of memory cards, as well as
|
|||
|
providing direct access to the PCMCIA memory address space for cards
|
|||
|
that have other functions. When loaded, it creates a combination of
|
|||
|
character and block devices. See the man page for the module for a
|
|||
|
complete description of the device naming scheme. Block devices are
|
|||
|
used for disk-like access (creating and mounting filesystems, etc).
|
|||
|
The character devices are for "raw" unbuffered reads and writes at
|
|||
|
arbitrary locations.
|
|||
|
|
|||
|
The device address passed to memory.opts consists of two fields: the
|
|||
|
scheme, and the socket number. The options are applied to the first
|
|||
|
common memory partition on the corresponding memory card.
|
|||
|
|
|||
|
Some flash memory cards, and most simple static RAM cards, lack a
|
|||
|
``Card Information Structure'' (CIS), which is the system PCMCIA cards
|
|||
|
use to identify themselves. Normally, cardmgr will assume that any
|
|||
|
card that lacks a CIS is a simple memory card, and load the memory_cs
|
|||
|
driver. Thus, a common side effect of a general card identification
|
|||
|
problem is that other types of cards may be misdetected as memory
|
|||
|
cards.
|
|||
|
|
|||
|
There is another issue to consider when handling memory cards that do
|
|||
|
not have CIS information. At startup time, the PCMCIA package tries
|
|||
|
to use the first detected card to determine what memory regions are
|
|||
|
usable for PCMCIA. The memory scan can be fooled if that card is a
|
|||
|
simple memory card. If you plan to use memory cards often, it is best
|
|||
|
to limit the memory windows in /etc/pcmcia/config.opts to known-good
|
|||
|
regions.
|
|||
|
|
|||
|
The memory_cs driver uses a heuristic to guess the capacity of these
|
|||
|
cards. The heuristic does not work for write protected cards, and may
|
|||
|
make mistakes in some other cases as well. If a card is misdetected,
|
|||
|
its size should then be explicitly specified when using commands such
|
|||
|
as dd or mkfs. The memory_cs module also has a parameter for
|
|||
|
overriding the size detection. See the man page.
|
|||
|
|
|||
|
|
|||
|
4.7.1. Memory device parameters
|
|||
|
|
|||
|
|
|||
|
The following parameters can be specified in memory.opts:
|
|||
|
|
|||
|
|
|||
|
DO_FSTAB
|
|||
|
A boolean (y/n) setting: specifies if an entry should be added
|
|||
|
to /etc/fstab for this device.
|
|||
|
|
|||
|
DO_FSCK
|
|||
|
A boolean (y/n) setting: specifies if the filesystem should be
|
|||
|
checked before being mounted, with ``fsck -Ta''.
|
|||
|
|
|||
|
DO_MOUNT
|
|||
|
A boolean (y/n) setting: specifies if this device should be
|
|||
|
automatically mounted at card insertion time.
|
|||
|
|
|||
|
FSTYPE, OPTS, MOUNTPT
|
|||
|
The filesystem type, mount options, and mount point to be used
|
|||
|
for the fstab entry and/or mounting the device.
|
|||
|
|
|||
|
NO_CHECK, NO_FUSER
|
|||
|
Boolean (y/n) settings for card eject policy. If NO_CHECK is
|
|||
|
true, then ``cardctl eject'' will shut down a device even if it
|
|||
|
is busy. If NO_FUSER is true, then the script will not try to
|
|||
|
kill processes using an ejected device.
|
|||
|
|
|||
|
Here is an example of a script that will automatically mount memory
|
|||
|
cards based on which socket they are inserted into:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
case "$ADDRESS" in
|
|||
|
*,0,0)
|
|||
|
# Mount filesystem, but don't update /etc/fstab
|
|||
|
DO_FSTAB="n" ; DO_FSCK="y" ; DO_MOUNT="y"
|
|||
|
FSTYPE="ext2" ; OPTS=""
|
|||
|
MOUNTPT="/mem0"
|
|||
|
;;
|
|||
|
*,1,0)
|
|||
|
# Mount filesystem, but don't update /etc/fstab
|
|||
|
DO_FSTAB="n" ; DO_FSCK="y" ; DO_MOUNT="y"
|
|||
|
FSTYPE="ext2" ; OPTS=""
|
|||
|
MOUNTPT="/mem1"
|
|||
|
;;
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.7.2. Using linear flash memory cards
|
|||
|
|
|||
|
The following information applies only to so-called ``linear flash''
|
|||
|
memory cards. Many flash cards, including all SmartMedia and
|
|||
|
CompactFlash cards, actually include circuitry to emulate an IDE disk
|
|||
|
device. Those cards are thus handled as IDE devices, not memory
|
|||
|
cards.
|
|||
|
|
|||
|
There are two major formats for flash memory cards: the FTL or ``flash
|
|||
|
translation layer'' style, and the Microsoft Flash File System. The
|
|||
|
FTL format is generally more flexible because it allows any ordinary
|
|||
|
high-level filesystem (ext2, ms-dos, etc) to be used on a flash card
|
|||
|
as if it were an ordinary disk device. The FFS is a completely
|
|||
|
different filesystem type. Linux cannot currently handle cards
|
|||
|
formated with FFS.
|
|||
|
|
|||
|
To use a flash memory card as an ordinary disk-like block device,
|
|||
|
first create an FTL partition on the device with the ftl_format
|
|||
|
command. This layer hides the device-specific details of flash memory
|
|||
|
programming and make the card look like a simple block device. For
|
|||
|
example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
ftl_format -i /dev/mem0c0c
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Note that this command accesses the card through the ``raw'' memory
|
|||
|
card interface. Once formatted, the card can be accessed as an
|
|||
|
ordinary block device via the ftl_cs driver. For example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
mke2fs /dev/ftl0c0
|
|||
|
mount -t ext2 /dev/ftl0c0 /mnt
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Device naming for FTL devices is tricky. Minor device numbers have
|
|||
|
three parts: the card number, the region number on that card, and
|
|||
|
optionally, the partition within that region. A region can either be
|
|||
|
treated as a single block device with no partition table (like a
|
|||
|
floppy), or it can be partitioned like a hard disk device. The
|
|||
|
``ftl0c0'' device is card 0, common memory region 0, the entire
|
|||
|
region. The ``ftl0c0p1'' through ``ftl0c0p4'' devices are primary
|
|||
|
partitions 1 through 4 if the region has been partitioned.
|
|||
|
|
|||
|
Configuration options for FTL partitions can be given in ftl.opts,
|
|||
|
which is similar in structure to memory.opts. The device address
|
|||
|
passed to ftl.opts consists of three or four fields: the scheme, the
|
|||
|
socket number, the region number, and optionally, the partition
|
|||
|
number. Most flash cards have just one flash memory region, so the
|
|||
|
region number will generally always be zero.
|
|||
|
|
|||
|
Intel Series 100 flash cards use the first 128K flash block to store
|
|||
|
the cards' configuration information. To prevent accidental erasure
|
|||
|
of this information, ftl_format will automatically detect this and
|
|||
|
skip the first block when creating an FTL partition.
|
|||
|
|
|||
|
|
|||
|
4.8. PCMCIA ATA/IDE card drives
|
|||
|
|
|||
|
ATA/IDE drive support is based on the regular kernel IDE driver. This
|
|||
|
includes SmartMedia and CompactFlash devices: these flash memory cards
|
|||
|
are set up so that they emulate an IDE interface. The PCMCIA-specific
|
|||
|
part of the driver is ide_cs. Be sure to use cardctl or cardinfo to
|
|||
|
shut down an ATA/IDE card before ejecting it, as the driver has not
|
|||
|
been made ``hot-swap-proof''.
|
|||
|
|
|||
|
The device addresses passed to ide.opts consist of either three or
|
|||
|
four fields: the current scheme, the socket number, the drive's serial
|
|||
|
number, and an optional partition number. The ide_info command can be
|
|||
|
used to obtain an IDE device's serial number. As with SCSI devices,
|
|||
|
ide.opts is first called for the entire device. If ide.opts returns a
|
|||
|
list of partitions in the PARTS variable, the script will then be
|
|||
|
called for each partition.
|
|||
|
|
|||
|
|
|||
|
4.8.1. ATA/IDE fixed-disk device parameters
|
|||
|
|
|||
|
|
|||
|
The following parameters can be specified in ide.opts:
|
|||
|
|
|||
|
|
|||
|
DO_FSTAB
|
|||
|
A boolean (y/n) setting: specifies if an entry should be added
|
|||
|
to /etc/fstab for this device.
|
|||
|
|
|||
|
DO_FSCK
|
|||
|
A boolean (y/n) setting: specifies if the filesystem should be
|
|||
|
checked before being mounted, with ``fsck -Ta''.
|
|||
|
|
|||
|
DO_MOUNT
|
|||
|
A boolean (y/n) setting: specifies if this device should be
|
|||
|
automatically mounted at card insertion time.
|
|||
|
|
|||
|
FSTYPE, OPTS, MOUNTPT
|
|||
|
The filesystem type, mount options, and mount point to be used
|
|||
|
for the fstab entry and/or mounting the device.
|
|||
|
|
|||
|
NO_CHECK, NO_FUSER
|
|||
|
Boolean (y/n) settings for card eject policy. If NO_CHECK is
|
|||
|
true, then ``cardctl eject'' will shut down a device even if it
|
|||
|
is busy. If NO_FUSER is true, then the script will not try to
|
|||
|
kill processes using an ejected device.
|
|||
|
|
|||
|
Here is an example ide.opts file to mount the first partition of any
|
|||
|
ATA/IDE card on /mnt.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
case "$ADDRESS" in
|
|||
|
*,*,*,1)
|
|||
|
DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y"
|
|||
|
FSTYPE="msdos"
|
|||
|
OPTS=""
|
|||
|
MOUNTPT="/mnt"
|
|||
|
;;
|
|||
|
*,*,*)
|
|||
|
PARTS="1"
|
|||
|
;;
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
4.8.2. Diagnosing problems with ATA/IDE adapters
|
|||
|
|
|||
|
|
|||
|
<20> An IO port conflict may cause the IDE driver to misdetect the drive
|
|||
|
geometry and report ``INVALID GEOMETRY: 0 PHYSICAL HEADS?''. To
|
|||
|
fix, try excluding the selected IO port range in
|
|||
|
/etc/pcmcia/config.opts.
|
|||
|
|
|||
|
<20> Some IDE drives violate the PCMCIA specification by requiring more
|
|||
|
time to spin up than the maximum allowed card setup time. This may
|
|||
|
result in ``timed out during reset'' messages at card detect time.
|
|||
|
Adjust the unreset_delay and/or unreset_limit parameters for the
|
|||
|
pcmcia_core module to give a drive more time to spin up; see the
|
|||
|
pcmcia_core man page for parameter details. For example:
|
|||
|
|
|||
|
|
|||
|
CORE_OPTS="unreset_delay=400"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> To use an ATA/IDE CD-ROM device, your kernel must be compiled with
|
|||
|
CONFIG_BLK_DEV_IDECD enabled. This will normally be the case for
|
|||
|
standard kernels, however it is something to be aware of if you
|
|||
|
compile a custom kernel.
|
|||
|
|
|||
|
<20> A common error when using IDE drives is try to mount the wrong
|
|||
|
device file. Generally, you want to mount a partition of the
|
|||
|
device, not the entire device (i.e., /dev/hde1, not /dev/hde).
|
|||
|
|
|||
|
<20> The Linux IDE driver may have trouble configuring certain
|
|||
|
removable-media drives if no media is present at insertion time.
|
|||
|
The IBM Portable DriveBay has this problem.
|
|||
|
|
|||
|
<20> Some kernels will report a pair of ``drive_cmd'' errors at
|
|||
|
insertion time. These errors can be ignored: they pop up when a
|
|||
|
removable IDE device does not accept the IDE ``door lock'' command.
|
|||
|
|
|||
|
|
|||
|
4.9. Multifunction cards
|
|||
|
|
|||
|
A single interrupt can be shared by several drivers, such as the
|
|||
|
serial driver and an ethernet driver: in fact, the PCMCIA
|
|||
|
specification requires all card functions to share the same interrupt.
|
|||
|
Normally, all card functions are available without having to swap
|
|||
|
drivers. All Linux kernels support this kind of interrupt sharing.
|
|||
|
|
|||
|
Simultaneous use of two card functions is ``tricky'' and various
|
|||
|
hardware vendors have implemented interrupt sharing in their own
|
|||
|
incompatible (and sometimes proprietary) ways. The drivers for some
|
|||
|
cards (Ositech Jack of Diamonds, 3Com 3c562 and related cards, Linksys
|
|||
|
cards) properly support simultaneous access, but others (older
|
|||
|
Megahertz cards in particular) do not. If you have trouble using a
|
|||
|
card with both functions active, try using each function in isolation.
|
|||
|
That may require explicitly doing an ``ifconfig down'' to shut down a
|
|||
|
network interface and use a modem on the same card.
|
|||
|
|
|||
|
|
|||
|
5. Advanced topics
|
|||
|
|
|||
|
|
|||
|
|
|||
|
5.1. Resource allocation for PCMCIA devices
|
|||
|
|
|||
|
In theory, it should not really matter which interrupt is allocated to
|
|||
|
which device, as long as two devices are not configured to use the
|
|||
|
same interrupt. In /etc/pcmcia/config.opts you'll find a place for
|
|||
|
excluding interrupts that are used by non-PCMCIA devices.
|
|||
|
|
|||
|
Similarly, there is no way to directly specify the I/O addresses for a
|
|||
|
card to use. The /etc/pcmcia/config.opts file allows you to specify
|
|||
|
ranges of ports available for use by any card, or to exclude ranges
|
|||
|
that conflict with other devices.
|
|||
|
|
|||
|
After modifying /etc/pcmcia/config.opts, you can reinitialize cardmgr
|
|||
|
with ``kill -HUP''.
|
|||
|
|
|||
|
The interrupt used to monitor card status changes is chosen by the
|
|||
|
low-level socket driver module (i82365 or tcic) before cardmgr parses
|
|||
|
/etc/pcmcia/config, so it is not affected by changes to this file. To
|
|||
|
set this interrupt, use the cs_irq= option when the socket driver is
|
|||
|
loaded, by setting the PCIC_OPTS variable in /etc/rc.d/rc.pcmcia.
|
|||
|
|
|||
|
All the client card drivers have a parameter called irq_list for
|
|||
|
specifying which interrupts they may try to allocate. These driver
|
|||
|
options should be set in your /etc/pcmcia/config file. For example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
device "serial_cs"
|
|||
|
module "serial_cs" opts "irq_list=8,12"
|
|||
|
...
|
|||
|
|
|||
|
|
|||
|
|
|||
|
would specify that the serial driver should only use irq 8 or irq 12.
|
|||
|
Regardless of irq_list settings, Card Services will never allocate an
|
|||
|
interrupt that is already in use by another device, or an interrupt
|
|||
|
that is excluded in the config file.
|
|||
|
|
|||
|
|
|||
|
5.2. PCI interrupt configuration problems and solutions
|
|||
|
|
|||
|
|
|||
|
Most of the following discussion applies to 2.2 and earlier kernels.
|
|||
|
With 2.4 and later kernels, the PCI subsystem has more complete
|
|||
|
responsibility for PCI interrupt management. The following tips may
|
|||
|
help diagnose a problem, though some workarounds described here may
|
|||
|
not be available.
|
|||
|
|
|||
|
|
|||
|
5.2.1. An overview of PCI interrupt routing issues
|
|||
|
|
|||
|
Each PCI slot has four PCI interrupt pins, INTA through INTD. Single
|
|||
|
function devices will only use the INTA pin; multifunction devices may
|
|||
|
use multiple INT pins. On the processor side, on x86 single processor
|
|||
|
systems, incoming hardware interrupts are directed to interrupt
|
|||
|
requests (irq's) numbered 0..15. The PCI interrupt router, usually
|
|||
|
part of the PCI-to-ISA host bridge, determines how incoming PCI
|
|||
|
interrupts are mapped to CPU irq numbers. Most modern bridge chips
|
|||
|
have several PCI interrupt inputs, known as PIRQ1, PIRQ2, etc, each of
|
|||
|
which can be routed to any CPU irq number. So we might have something
|
|||
|
like:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
PCI slot 1 INTA --> router PIRQ1 --> CPU irq 9
|
|||
|
PCI slot 1 INTB --> router PIRQ2 --> CPU irq 10
|
|||
|
|
|||
|
PCI slot 2 INTA --> router PIRQ2 --> CPU irq 10
|
|||
|
PCI slot 2 INTB --> router PIRQ1 --> CPU irq 9
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Multiple INT pins are often connected to the same PIRQ pin. Usually,
|
|||
|
the connections from INT pins to PIRQ pins are arranged to spread
|
|||
|
installed devices out as much as possible, to give the OS the most
|
|||
|
flexibility for choosing how interrupts are shared. The mapping from
|
|||
|
bridge PIRQ pins to CPU irq numbers can be obtained by reading
|
|||
|
registers in the interrupt router. The mapping from INT pins to the
|
|||
|
router's PIRQ pins, however, depends on how the board designer decided
|
|||
|
to connect things up, and cannot be directly determined by driver
|
|||
|
software.
|
|||
|
|
|||
|
For most PCI devices, the OS does not need to understand the interrupt
|
|||
|
router details. Each PCI device has a configuration register, the PCI
|
|||
|
Interrupt Line Register, that the BIOS initializes with the
|
|||
|
appropriate CPU irq number for that device. Unfortunately, the BIOS
|
|||
|
generally will not configure PCI interrupts for CardBus bridge
|
|||
|
devices.
|
|||
|
|
|||
|
The PCI BIOS's Interrupt Routing Table is a data structure that
|
|||
|
contains information about the mapping from PCI INT pins to the PIRQ
|
|||
|
pins on the PCI interrupt router. The routing information in the
|
|||
|
table is stored in a somewhat unhelpful form, however. For each
|
|||
|
device's INT pins, the table specifies a ``link value''. All
|
|||
|
interrupts with the same link value are wired to the same PIRQ pin;
|
|||
|
however, the meaning of the link values is defined by the chipset
|
|||
|
vendor.
|
|||
|
|
|||
|
Several tools are available for examining PCI interrupt routing
|
|||
|
information:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
lspci, /proc/pci
|
|||
|
These will show you resource information (including interrupt
|
|||
|
assignments, where they are known) for all your PCI devices.
|
|||
|
|
|||
|
|
|||
|
dump_pirq
|
|||
|
This is in the debug-tools directory of the PCMCIA source
|
|||
|
distribution. It dumps the contents of your PCI interrupt
|
|||
|
routing table, if available. It also scans for known interrupt
|
|||
|
routers and dumps their current interrupt steering settings.
|
|||
|
|
|||
|
|
|||
|
Several PCMCIA module parameters affect PCI interrupt routing:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
pcmcia_core module: cb_pci_irq=n
|
|||
|
This option specifies one interrupt number to be used to program
|
|||
|
the PCI interrupt router for all CardBus sockets that do not
|
|||
|
already have an interrupt assignment. It only has any effect on
|
|||
|
systems that have a PCI irq routing table, and a known interrupt
|
|||
|
router.
|
|||
|
|
|||
|
|
|||
|
i82365 module: irq_mode=n
|
|||
|
Most CardBus bridges offer several methods for delivering
|
|||
|
interrupts to the host. The i82365 module by default assumes
|
|||
|
that a bridge can deliver both PCI and ISA interrupts, since
|
|||
|
this is normal for laptops. A setting of ``irq_mode=0'' can be
|
|||
|
used to force a bridge to use only PCI interrupts. See the man
|
|||
|
page for the i82365 module for a description of what other
|
|||
|
values mean for different bridge types.
|
|||
|
|
|||
|
|
|||
|
i82365 module: irq_list=n,n,...
|
|||
|
This parameter lists which ISA interrupt(s) can be used for
|
|||
|
PCMCIA. If no ISA interrupts are available, specify
|
|||
|
``irq_list=0''. Note that ``irq_mode=0'' implies
|
|||
|
``irq_list=0''.
|
|||
|
|
|||
|
|
|||
|
i82365 module: pci_irq_list=n,n,...
|
|||
|
This option specifies a list of PCI interrupt numbers to use for
|
|||
|
CardBus sockets. It differs from cb_pci_irq, because it does
|
|||
|
not actually program the PCI interrupt router; it can be used
|
|||
|
when you know the PCI interrupts are already set up a certain
|
|||
|
way, even if you do not know how the router works.
|
|||
|
|
|||
|
|
|||
|
If you are having problems that you think may be related to PCI
|
|||
|
interrupt configuration, you should first verify that you have a
|
|||
|
reasonably current PCMCIA driver package. Also carefully look at the
|
|||
|
startup messages when the PCMCIA kernel modules are loaded. You
|
|||
|
should see something like:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Linux PCMCIA Card Services 3.1.18
|
|||
|
kernel build: 2.2.14-5.0 #1 Tue May 9 10:44:24 PDT 2000
|
|||
|
options: [pci] [cardbus] [apm] [pnp]
|
|||
|
PCI routing table version 1.0 at 0xfdf30
|
|||
|
Intel PCIC probe:
|
|||
|
TI 1125 rev 02 PCI-to-CardBus at slot 00:07, mem 0x20000000
|
|||
|
host opts [0]: [ring] [serial pci & irq] [pci irq 11] ...
|
|||
|
host opts [0]: [ring] [serial pci & irq] [pci irq 11] ...
|
|||
|
ISA irqs (scanned) = 3,4,7 PCI status changes
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The ``PCI routing table'' message indicates that a valid routing table
|
|||
|
was found. The ``host opts'' lines indicate the interrupt delivery
|
|||
|
mode and whether or not a PCI interrupt could be determined for each
|
|||
|
socket. And the final line indicates the results of the scan for
|
|||
|
available interrupts.
|
|||
|
|
|||
|
|
|||
|
5.2.2. CardBus bridge is not detected by the PCI BIOS
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> Intel PCIC probe: not found.
|
|||
|
|
|||
|
<20> The bridge does not show up in lspci or in /proc/pci.
|
|||
|
|
|||
|
The Lucent/SCM PCI-to-CardBus adapters seem to confuse the PCI BIOS on
|
|||
|
some older systems. Lucent says that this card is only supported on
|
|||
|
systems that have a BIOS that supports the PCI 2.2 specification, or
|
|||
|
are PC99 compliant. Some older systems will not detect the Lucent
|
|||
|
card at all, and if the system can't detect it, the Linux drivers
|
|||
|
cannot use it. The only possible resolutions are a BIOS upgrade, or
|
|||
|
using a different motherboard or CardBus adapter.
|
|||
|
|
|||
|
|
|||
|
5.2.3. PCI interrupt delivery problems
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> Cards seem to be configured correctly, but do not work.
|
|||
|
|
|||
|
|
|||
|
<20> /proc/interrupts shows a count of 0 for interrupts assigned to
|
|||
|
PCMCIA drivers.
|
|||
|
|
|||
|
CardBus bridges usually support two types of interrupts, PCI and ISA.
|
|||
|
Partly for historical reasons, it has become conventional to use PCI
|
|||
|
interrupts for signaling card insertion and removal events, and for
|
|||
|
CardBus card interrupts; and ISA interrupts for 16-bit cards. Since
|
|||
|
version 3.1.9, this is the scheme that the Linux PCMCIA system will
|
|||
|
use by default. Most CardBus bridges support multiple methods for
|
|||
|
delivering interrupts to the host CPU. Methods include ``parallel''
|
|||
|
interrupts, where each supported irq has a dedicated pin on the
|
|||
|
bridge; various serial interrupt protocols, where one or two pins are
|
|||
|
used to communicate with an interrupt controller; and hybrids, where
|
|||
|
PCI interrupts might be signalled using dedicated pins, while ISA
|
|||
|
interrupts are delivered via a serial controller.
|
|||
|
|
|||
|
In general, it is the responsibility of the BIOS to program a bridge
|
|||
|
for the appropriate interrupt delivery method. However, there are
|
|||
|
systems that do this incorrectly, and in some cases, there is no way
|
|||
|
for software to safely detect the correct delivery method. The i82365
|
|||
|
module reports the bridge mode at startup time, and has a parameter,
|
|||
|
irq_mode, that can be used to reconfigure it. Not all bridges support
|
|||
|
this parameter, and the meaning of irq_mode depends on the bridge
|
|||
|
type. See the i82365 man page for a description of what values are
|
|||
|
supported by your bridge. In some cases, a bridge may function
|
|||
|
correctly in more than one interrupt mode.
|
|||
|
|
|||
|
Most PCMCIA card readers that fit in a PCI bus slot only provide PCI
|
|||
|
interrupt routing. The Linux drivers assume that all bridges have ISA
|
|||
|
interrupt capability, since that is generally correct on laptops.
|
|||
|
With a card reader, it will generally be necessary to use the irq_mode
|
|||
|
parameter to specify a ``PCI only'' interrupt delivery mode; the value
|
|||
|
of the parameter depends on the bridge type, so check the i82365 man
|
|||
|
page. A few PCI card readers require an irq_mode that permits ISA
|
|||
|
interrupts, but those interrupts are not actually connected; in that
|
|||
|
case, use ``irq_list=0''.
|
|||
|
|
|||
|
Check the system log and verify that the CardBus bridge has a PCI
|
|||
|
interrupt assignment. If it does not, then resolve that problem
|
|||
|
first, then return here if the symptoms persist. Next, experiment
|
|||
|
with different values for the irq_mode parameter.
|
|||
|
|
|||
|
|
|||
|
5.2.4. No PCI interrupt assignment; valid routing table
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> The Intel PCIC probe reports ``no pci irq'' for each socket.
|
|||
|
|
|||
|
<20> There is a routing table, and the router type is supported.
|
|||
|
|
|||
|
When a routing table is present, the pcmcia_core module will try to
|
|||
|
automatically configure the PCI interrupt router, but only does so
|
|||
|
when it has a safe and unambiguous choice for what PCI interrupt to
|
|||
|
use. If there are several valid choices, then you must use the
|
|||
|
``cb_pci_irq=...'' option to specify which interrupt to assign. Your
|
|||
|
best bet is to pick the most lightly used interrupt that is already
|
|||
|
assigned to another PCI device.
|
|||
|
|
|||
|
Moving the card to another slot sometimes offers a quick solution. If
|
|||
|
that slot shares its interrupt with an already-configured device, then
|
|||
|
the PCMCIA drivers will have no trouble figuring out the assignment.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
5.2.5. No PCI interrupt assignment; unknown interrupt router
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> The Intel PCIC probe reports ``no pci irq'' for each socket.
|
|||
|
|
|||
|
<20> There is a routing table, but the router is an unknown type.
|
|||
|
|
|||
|
Adding support for a new interrupt router is tricky but not a big job.
|
|||
|
First determine, from a datasheet, how your interrupt router steers
|
|||
|
PCI interrupts. Then, see if you can guess the meaning of the link
|
|||
|
values from the output of dump_pirq. Usually this is reasonably
|
|||
|
obvious. Most routers have four PIRQ pins, and the link values might
|
|||
|
be something like 1,2,3,4, or 0x10,0x18,0x20,0x28, or
|
|||
|
0x60,0x61,0x62,0x63. The values are usually chosen so that they can
|
|||
|
be easily converted to the location of the appropriate interrupt
|
|||
|
steering register. Finally, add small functions to
|
|||
|
modules/pci_fixup.c to get/set the interrupt steering information for
|
|||
|
this router, using the other routers as examples.
|
|||
|
|
|||
|
|
|||
|
5.2.6. No PCI interrupt assignment; no routing table
|
|||
|
|
|||
|
|
|||
|
Symptoms:
|
|||
|
|
|||
|
<20> The Intel PCIC probe reports ``no pci irq'' for each socket.
|
|||
|
|
|||
|
<20> No interrupt routing table is found.
|
|||
|
|
|||
|
Without an interrupt routing table, we cannot tell how interrupts from
|
|||
|
the CardBus bridge are directed to CPU irq numbers. All hope is not
|
|||
|
lost: you may be able to guess the PCI interrupt assignment and use
|
|||
|
the ``pci_irq_list=...'' option to pass this information to the i82365
|
|||
|
module. Good guesses might include the interrupt(s) assigned to other
|
|||
|
PCI devices, the interrupt(s) used under Windows, or any other
|
|||
|
interrupts that are unaccounted for.
|
|||
|
|
|||
|
You may also want to experiment with putting the adapter in different
|
|||
|
PCI slots, for each pci_irq_list you try. You are trying to find a
|
|||
|
slot that shares its interrupt with an already-configured device, and
|
|||
|
might need to try several slots to find one.
|
|||
|
|
|||
|
|
|||
|
5.3. How can I have separate device setups for home and work?
|
|||
|
|
|||
|
This is fairly easy using ``scheme'' support. Use two configuration
|
|||
|
schemes, called ``home'' and ``work''. Here is an example of a
|
|||
|
network.opts script with scheme-specific settings:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
case "$ADDRESS" in
|
|||
|
work,*,*,*)
|
|||
|
# definitions for network card in work scheme
|
|||
|
...
|
|||
|
;;
|
|||
|
home,*,*,*|default,*,*,*)
|
|||
|
# definitions for network card in home scheme
|
|||
|
...
|
|||
|
;;
|
|||
|
esac
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The first part of a device address is always the configuration scheme.
|
|||
|
In this example, the second ``case'' clause will select for both the
|
|||
|
``home'' and ``default'' schemes. So, if the scheme is unset for any
|
|||
|
reason, it will default to the ``home'' setup.
|
|||
|
|
|||
|
Now, to select between the two sets of settings, run either:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
cardctl scheme home
|
|||
|
|
|||
|
|
|||
|
|
|||
|
or
|
|||
|
|
|||
|
|
|||
|
|
|||
|
cardctl scheme work
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The cardctl command does the equivalent of shutting down all your
|
|||
|
cards and restarting them. The command can be safely executed whether
|
|||
|
or not the PCMCIA system is loaded, but the command may fail if you
|
|||
|
are using other PCMCIA devices at the time (even if their
|
|||
|
configurations are not explicitly dependant on the scheme setting).
|
|||
|
|
|||
|
To find out the current scheme setting, run:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
cardctl scheme
|
|||
|
|
|||
|
|
|||
|
|
|||
|
By default, the scheme setting is persistent across boots. This can
|
|||
|
have undesirable effects if networking is initialized for the wrong
|
|||
|
environment. Optionally, you can set the initial scheme value with
|
|||
|
the SCHEME startup option (see ``Startup options'' for details). It
|
|||
|
is also possible to set the scheme from the lilo boot prompt. Since
|
|||
|
lilo passes unrecognized options to init as environment variables, a
|
|||
|
value for SCHEME (or any other PCMCIA startup option) at the boot
|
|||
|
prompt will be propagated into the PCMCIA startup script.
|
|||
|
|
|||
|
To save even more keystrokes, schemes can be specified in lilo's
|
|||
|
configuration file. For instance, you could have:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
root = /dev/hda1
|
|||
|
read-only
|
|||
|
image = /boot/vmlinuz
|
|||
|
label = home
|
|||
|
append = "SCHEME=home"
|
|||
|
image = /boot/vmlinuz
|
|||
|
label = work
|
|||
|
append = "SCHEME=work"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Typing ``home'' or ``work'' at the boot prompt would then boot into
|
|||
|
the appropriate scheme.
|
|||
|
5.4. Booting from a PCMCIA device
|
|||
|
|
|||
|
|
|||
|
Having the root filesystem on a PCMCIA device is tricky because the
|
|||
|
Linux PCMCIA system is not designed to be linked into the kernel. Its
|
|||
|
core components, the loadable kernel modules and the user mode cardmgr
|
|||
|
daemon, depend on an already running system. The kernel's ``initrd''
|
|||
|
facility works around this requirement by allowing Linux to boot using
|
|||
|
a temporary ram disk as a minimal root image, load drivers, and then
|
|||
|
re-mount a different root filesystem. The temporary root can
|
|||
|
configure PCMCIA devices and then re-mount a PCMCIA device as root.
|
|||
|
|
|||
|
The initrd image absolutely must reside on a bootable device: this
|
|||
|
generally cannot be put on a PCMCIA device. This is a BIOS
|
|||
|
limitation, not a kernel limitation. It is useful here to distinguish
|
|||
|
between ``boot-able'' devices (i.e., devices that can be booted), and
|
|||
|
``root-able'' devices (i.e., devices that can be mounted as root).
|
|||
|
``Boot-able'' devices are determined by the BIOS, and are generally
|
|||
|
limited to internal floppy and hard disk drives. ``Root-able''
|
|||
|
devices are any block devices that the kernel supports once it has
|
|||
|
been loaded. The initrd facility makes more devices ``root-able'',
|
|||
|
not ``boot-able''.
|
|||
|
|
|||
|
Some Linux distributions will allow installation to a device connected
|
|||
|
to a PCMCIA SCSI adapter, as an unintended side-effect of their
|
|||
|
support for installs from PCMCIA SCSI CD-ROM devices. However, at
|
|||
|
present, no Linux installation tools support configuring an
|
|||
|
appropriate ``initrd'' to boot Linux with a PCMCIA root filesystem.
|
|||
|
Setting up a system with a PCMCIA root thus requires that you use
|
|||
|
another Linux system to create the ``initrd'' image. If another Linux
|
|||
|
system is not available, another option would be to temporarily
|
|||
|
install a minimal Linux setup on a non-PCMCIA drive, create an initrd
|
|||
|
image, and then reinstall to the PCMCIA target.
|
|||
|
|
|||
|
The Linux Bootdisk-HOWTO has some general information about setting up
|
|||
|
boot disks but nothing specific to initrd. The main initrd document
|
|||
|
is included with recent kernel source code distributions, in
|
|||
|
linux/Documentation/initrd.txt. Before beginning, you should read
|
|||
|
this document. A familiarity with lilo is also helpful. Using initrd
|
|||
|
also requires that you have a kernel compiled with CONFIG_BLK_DEV_RAM
|
|||
|
and CONFIG_BLK_DEV_INITRD enabled.
|
|||
|
|
|||
|
This is an advanced configuration technique, and requires a high level
|
|||
|
of familiarity with Linux and the PCMCIA system. Be sure to read all
|
|||
|
the relevant documentation before starting. The following cookbook
|
|||
|
instructions should work, but deviations from the examples will
|
|||
|
quickly put you in uncharted and ``unsupported'' territory, and you
|
|||
|
will be on your own.
|
|||
|
|
|||
|
This method absolutely requires that you use a PCMCIA driver release
|
|||
|
of 2.9.5 or later. Older PCMCIA packages or individual components
|
|||
|
will not work in the initrd context. Do not mix components from
|
|||
|
different releases.
|
|||
|
|
|||
|
|
|||
|
5.4.1. The pcinitrd helper script
|
|||
|
|
|||
|
The pcinitrd script creates a basic initrd image for booting with a
|
|||
|
PCMCIA root partition. The image includes a minimal directory
|
|||
|
heirarchy, a handful of device files, a few binaries, shared
|
|||
|
libraries, and a set of PCMCIA driver modules. When invoking
|
|||
|
pcinitrd, you specify the driver modules that you want to be included
|
|||
|
in the image. The core PCMCIA components, pcmcia_core and ds, are
|
|||
|
automatically included.
|
|||
|
|
|||
|
|
|||
|
As an example, say that your laptop uses an i82365-compatible host
|
|||
|
controller, and you want to boot Linux with the root filesystem on a
|
|||
|
hard drive attached to an Adaptec SlimSCSI adapter. You could create
|
|||
|
an appropriate initrd image with:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
pcinitrd -v initrd pcmcia/i82365.o pcmcia/aha152x_cs.o
|
|||
|
|
|||
|
|
|||
|
|
|||
|
To customize the initrd startup sequence, you could mount the image
|
|||
|
using the ``loopback'' device with a command like:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
mount -o loop -t ext2 initrd /mnt
|
|||
|
|
|||
|
|
|||
|
|
|||
|
and then edit the linuxrc script. The configuration files will be
|
|||
|
installed under /etc in the image, and can also be customized. See
|
|||
|
the man page for pcinitrd for more information.
|
|||
|
|
|||
|
|
|||
|
5.4.2. Creating an initrd boot floppy
|
|||
|
|
|||
|
|
|||
|
After creating an image with pcinitrd, you can create a boot floppy by
|
|||
|
copying the kernel, the compressed initrd image, and a few support
|
|||
|
files for lilo to a clean floppy. In the following example, we assume
|
|||
|
that the desired PCMCIA root device is /dev/sda1:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
mke2fs /dev/fd0
|
|||
|
mount /dev/fd0 /mnt
|
|||
|
mkdir /mnt/etc /mnt/boot /mnt/dev
|
|||
|
cp -a /dev/fd0 /dev/sda1 /mnt/dev
|
|||
|
cp [kernel-image] /mnt/vmlinuz
|
|||
|
cp /boot/boot.b /mnt/boot/boot.b
|
|||
|
gzip < [initrd-image] > /mnt/initrd
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Create /mnt/etc/lilo.conf with the contents:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
boot=/dev/fd0
|
|||
|
compact
|
|||
|
image=/vmlinuz
|
|||
|
label=linux
|
|||
|
initrd=/initrd
|
|||
|
read-only
|
|||
|
root=/dev/sda1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Finally, invoke lilo with:
|
|||
|
|
|||
|
|
|||
|
lilo -r /mnt
|
|||
|
|
|||
|
|
|||
|
|
|||
|
When lilo is invoked with -r, it performs all actions relative to the
|
|||
|
specified alternate root directory. The reason for creating the
|
|||
|
device files under /mnt/dev was that lilo will not be able to use the
|
|||
|
files in /dev when it is running in this alternate-root mode.
|
|||
|
|
|||
|
|
|||
|
5.4.3. Installing an initrd image on a non-Linux drive
|
|||
|
|
|||
|
One common use of the initrd facility would be on systems where the
|
|||
|
internal hard drive is dedicated to another operating system. The
|
|||
|
Linux kernel and initrd image can be placed in a non-Linux partition,
|
|||
|
and lilo or LOADLIN can be set up to boot Linux from these images.
|
|||
|
|
|||
|
Assuming that you have a kernel has been configured for the
|
|||
|
appropriate root device, and an initrd image created on another
|
|||
|
system, the easiest way to get started is to boot Linux using LOADLIN,
|
|||
|
as:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
LOADLIN <kernel> initrd=<initrd-image>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Once you can boot Linux on your target machine, you could then install
|
|||
|
lilo to allow booting Linux directly. For example, say that /dev/hda1
|
|||
|
is the non-Linux target partition and /mnt can be used as a mount
|
|||
|
point. First, create a subdirectory on the target for the Linux
|
|||
|
files:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
mount /dev/hda1 /mnt
|
|||
|
mkdir /mnt/linux
|
|||
|
cp [kernel-image] /mnt/linux/vmlinuz
|
|||
|
cp [initrd-image] /mnt/linux/initrd
|
|||
|
|
|||
|
|
|||
|
|
|||
|
In this example, say that /dev/sda1 is the desired Linux root
|
|||
|
partition, a SCSI hard drive mounted via a PCMCIA SCSI adapter. To
|
|||
|
install lilo, create a lilo.conf file with the contents:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
boot=/dev/hda
|
|||
|
map=/mnt/linux/map
|
|||
|
compact
|
|||
|
image=/mnt/linux/vmlinuz
|
|||
|
label=linux
|
|||
|
root=/dev/sda1
|
|||
|
initrd=/mnt/linux/initrd
|
|||
|
read-only
|
|||
|
other=/dev/hda1
|
|||
|
table=/dev/hda
|
|||
|
label=windows
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The boot= line says to install the boot loader in the master boot
|
|||
|
record of the specified device. The root= line identifies the desired
|
|||
|
root filesystem to be used after loading the initrd image, and may be
|
|||
|
unnecessary if the kernel image is already configured this way. The
|
|||
|
other= section is used to describe the other operating system
|
|||
|
installed on /dev/hda1.
|
|||
|
|
|||
|
To install lilo in this case, use:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
lilo -C lilo.conf
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Note that in this case, the lilo.conf file uses absolute paths that
|
|||
|
include /mnt. I did this in the example because the target filesystem
|
|||
|
may not support the creation of Linux device files for the boot= and
|
|||
|
root= options.
|
|||
|
|
|||
|
|
|||
|
6. Dealing with unsupported cards
|
|||
|
|
|||
|
|
|||
|
|
|||
|
6.1. Configuring unrecognized cards
|
|||
|
|
|||
|
|
|||
|
Assuming that your card is supported by an existing driver, all that
|
|||
|
needs to be done is to add an entry to /etc/pcmcia/config to tell
|
|||
|
cardmgr how to identify the card, and which driver(s) need to be
|
|||
|
linked up to this card. Check the man page for pcmcia for more
|
|||
|
information about the config file format. If you insert an unknown
|
|||
|
card, cardmgr will normally record some identification information in
|
|||
|
the system log that can be used to construct the config entry. This
|
|||
|
information can also be displayed with the ``cardctl ident'' command.
|
|||
|
|
|||
|
Here is an example of how cardmgr will report an unsupported card in
|
|||
|
the system log:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
cardmgr[460]: unsupported card in socket 1
|
|||
|
cardmgr[460]: product info: "MEGAHERTZ", "XJ2288", "V.34 PCMCIA MODEM"
|
|||
|
cardmgr[460]: manfid: 0x0101, 0x1234 function: 2 (serial)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The corresponding entry in /etc/pcmcia/config would be:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
card "Megahertz XJ2288 V.34 Fax Modem"
|
|||
|
version "MEGAHERTZ", "XJ2288", "V.34 PCMCIA MODEM"
|
|||
|
bind "serial_cs"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
or using the more compact product ID codes:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
card "Megahertz XJ2288 V.34 Fax Modem"
|
|||
|
manfid 0x0101, 0x1234
|
|||
|
bind "serial_cs"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
You can use ``*'' to match strings that don't need to match exactly,
|
|||
|
like version numbers. When making new config entries, be careful to
|
|||
|
copy the strings exactly, preserving case and blank spaces. Also be
|
|||
|
sure that the config entry has the same number of strings as are
|
|||
|
reported in the log file.
|
|||
|
|
|||
|
Beware that you can specify just about any driver for a card, but if
|
|||
|
you're just shooting in the dark, there is not much reason to expect
|
|||
|
this to be productive. You may get lucky and find that your card is
|
|||
|
supported by an existing driver. However, the most likely outcome is
|
|||
|
that the driver won't work, and may have unfortunate side effects like
|
|||
|
locking up your system. Unlike most ordinary device drivers, which
|
|||
|
probe for an appropriate card, the probe for a PCMCIA device is done
|
|||
|
by cardmgr, and the driver itself may not do much validation before
|
|||
|
attempting to communicate with the device.
|
|||
|
|
|||
|
After editing /etc/pcmcia/config, you can signal cardmgr to reload the
|
|||
|
file with:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
kill -HUP `cat /var/run/cardmgr.pid`
|
|||
|
|
|||
|
|
|||
|
|
|||
|
If you do set up an entry for a new card, please send me a copy so
|
|||
|
that I can include it in the standard config file.
|
|||
|
|
|||
|
|
|||
|
6.2. Adding support for an NE2000-compatible ethernet card
|
|||
|
|
|||
|
Before you begin: this procedure will only work for simple 16-bit
|
|||
|
ethernet cards. Multifunction cards (i.e., ethernet/modem combo
|
|||
|
cards) have an extra layer of complexity regarding how the two
|
|||
|
functions are integrated, and generally cannot be supported without
|
|||
|
obtaining some configuration information from the card vendor. Using
|
|||
|
the following procedure for a multifunction card will not be
|
|||
|
productive.
|
|||
|
|
|||
|
First, see if the card is already recognized by cardmgr. Some cards
|
|||
|
not listed in SUPPORTED.CARDS are actually OEM versions of cards that
|
|||
|
are supported. If you find a card like this, let me know so I can add
|
|||
|
it to the list.
|
|||
|
|
|||
|
If your card is not recognized, follow the instructions in the
|
|||
|
``Configuring unrecognized cards'' section to create a config entry
|
|||
|
for your card, and bind the card to the pcnet_cs driver. Restart
|
|||
|
cardmgr to use the updated config file.
|
|||
|
|
|||
|
If the pcnet_cs driver says that it is unable to determine your card's
|
|||
|
hardware ethernet address, then edit your new config entry to bind the
|
|||
|
card to the memory card driver, memory_cs. Restart cardmgr to use the
|
|||
|
new updated config file. You will need to know your card's hardware
|
|||
|
ethernet address. This address is a series of six two-digit hex
|
|||
|
numbers, often printed on the card itself. If it is not printed on
|
|||
|
the card, you may be able to use a DOS driver to display the address.
|
|||
|
In any case, once you know it, run:
|
|||
|
|
|||
|
dd if=/dev/mem0a count=20 | od -Ax -t x1
|
|||
|
|
|||
|
|
|||
|
|
|||
|
and search the output for your address. Only the even bytes are
|
|||
|
defined, so ignore the odd bytes in the dump. Record the hex offset
|
|||
|
of the first byte of the address. Now, edit clients/pcnet_cs.c and
|
|||
|
find the hw_info structure. You'll need to create a new entry for
|
|||
|
your card. The first field is the memory offset. The next three
|
|||
|
fields are the first three bytes of the hardware address. The final
|
|||
|
field contains some flags for specific card features; to start, try
|
|||
|
setting it to 0.
|
|||
|
|
|||
|
After editing pcnet_cs.c, compile and install the new module. Edit
|
|||
|
/etc/pcmcia/config again, and change the card binding from memory_cs
|
|||
|
to pcnet_cs. Follow the instructions for reloading the config file,
|
|||
|
and you should be all set. Please send me copies of your new hw_info
|
|||
|
and config entries.
|
|||
|
|
|||
|
If you can't find your card's hardware address in the hex dump, as a
|
|||
|
method of last resort, it is possible to ``hard-wire'' the address
|
|||
|
when the pcnet_cs module is initialized. Edit /etc/pcmcia/config.opts
|
|||
|
and add a hw_addr= option, like so:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
module "pcnet_cs" opts "hw_addr=0x00,0x80,0xc8,0x01,0x02,0x03"
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Substitute your own card's hardware address in the appropriate spot,
|
|||
|
of course. Beware that if you've gotten this far, it is very unlikely
|
|||
|
that your card is genuinely NE2000 compatible. In fact, I'm not sure
|
|||
|
if there are any cards that are not handled by one of the first two
|
|||
|
methods.
|
|||
|
|
|||
|
|
|||
|
6.3. PCMCIA floppy interface cards
|
|||
|
|
|||
|
The PCMCIA floppy interface used in the Compaq Aero and a few other
|
|||
|
laptops is not yet supported by this package. The snag in supporting
|
|||
|
the Aero floppy is that the Aero seems to use a customized PCMCIA
|
|||
|
controller to support DMA to the floppy. Without knowing exactly how
|
|||
|
this is done, there isn't any way to implement support under Linux.
|
|||
|
|
|||
|
If the floppy adapter card is present when an Aero is booted, the Aero
|
|||
|
BIOS will configure the card, and Linux will identify it as a normal
|
|||
|
floppy drive. When the Linux PCMCIA drivers are loaded, they will
|
|||
|
notice that the card is already configured and attached to a Linux
|
|||
|
driver, and this socket will be left alone. So, the drive can be used
|
|||
|
if it is present at boot time, but the card is not hot swappable.
|
|||
|
|
|||
|
|
|||
|
7. Debugging tips and programming information
|
|||
|
|
|||
|
7.1. Submitting useful problem reports
|
|||
|
|
|||
|
The best way to submit reports is to use the online pcmcia-cs forums
|
|||
|
or the bug tracker at SourceForge. That way, other people can see
|
|||
|
current problems (and fixes or workarounds, if available). Here are
|
|||
|
some things that should be included in all bug reports:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> Your system brand and model.
|
|||
|
|
|||
|
<20> All PCMCIA card(s) you are using.
|
|||
|
|
|||
|
<20> Your Linux kernel version (i.e., ``uname -rv''), and PCMCIA driver
|
|||
|
version (i.e., ``cardctl -V'').
|
|||
|
|
|||
|
<20> Output of 'lspci -v'
|
|||
|
|
|||
|
<20> Any changes you have made to the startup files in /etc/pcmcia, or
|
|||
|
to the PCMCIA startup script.
|
|||
|
|
|||
|
<20> All PCMCIA-related messages in your system log file. That includes
|
|||
|
startup messages, and messages generated when your cards are
|
|||
|
configured.
|
|||
|
|
|||
|
All the PCMCIA modules and the cardmgr daemon send status messages to
|
|||
|
the system log. These will usually end up somewhere like
|
|||
|
/var/log/messages or /var/log/daemon.log. These files should be the
|
|||
|
first place to look when tracking down a problem. When submitting a
|
|||
|
bug report, always include the relevant contents of these files. If
|
|||
|
you are having trouble finding your system messages, check
|
|||
|
/etc/syslog.conf to see how different classes of messages are handled.
|
|||
|
|
|||
|
Before submitting a bug report, please check to make sure that you are
|
|||
|
using an up-to-date copy of the driver package. While it is somewhat
|
|||
|
gratifying to read bug reports for things I've already fixed, it isn't
|
|||
|
a particularly constructive use of my time.
|
|||
|
|
|||
|
If you do not have web access, bug reports can be sent to me at
|
|||
|
dahinds@users.sourceforge.net. However, I prefer that bug reports be
|
|||
|
posted to the pcmcia-cs SourceForge site, so that they can be seen by
|
|||
|
others.
|
|||
|
|
|||
|
|
|||
|
7.2. Interpreting kernel trap reports
|
|||
|
|
|||
|
If your problem involves a kernel fault, the register dump from the
|
|||
|
fault is only useful if you can translate the fault address, EIP, to
|
|||
|
something meaningful. Recent versions of klogd attempt to translate
|
|||
|
fault addresses based on the current kernel symbol map, but this may
|
|||
|
not work if the fault is in a module, or if the problem is severe
|
|||
|
enough that klogd cannot finish writing the fault information to the
|
|||
|
system log.
|
|||
|
|
|||
|
If a fault is in the main kernel, the fault address can be looked up
|
|||
|
in the System.map file. This may be installed in /System.map or
|
|||
|
/boot/System.map. If a fault is in a module, the nm command gives the
|
|||
|
same information, however, the fault address has to be adjusted based
|
|||
|
on the module's load address. Let's say that you have the following
|
|||
|
kernel fault:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Unable to handle kernel NULL pointer dereference
|
|||
|
current->tss.cr3 = 014c9000, %cr3 = 014c9000
|
|||
|
*pde = 00000000
|
|||
|
Oops: 0002
|
|||
|
CPU: 0
|
|||
|
EIP: 0010:[<c2026081>]
|
|||
|
EFLAGS: 00010282
|
|||
|
|
|||
|
|
|||
|
|
|||
|
The fault address is 0xc2026081. Looking at System.map, we see that
|
|||
|
this is past the end of the kernel, i.e., is in a kernel module. To
|
|||
|
determine which module, check the output of ``ksyms -m | sort'':
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Address Symbol Defined by
|
|||
|
c200d000 (35k) [pcmcia_core]
|
|||
|
c200d10c register_ss_entry [pcmcia_core]
|
|||
|
c200d230 unregister_ss_entry [pcmcia_core]
|
|||
|
...
|
|||
|
c2026000 (9k) [3c574_cs]
|
|||
|
c202a000 (4k) [serial_cs]
|
|||
|
|
|||
|
|
|||
|
|
|||
|
So, 0xc2026081 is in the 3c574_cs module, and is at an offset of
|
|||
|
0x0081 from the start of the module. We cannot look up this offset in
|
|||
|
3c574_cs.o yet: when the kernel loads a module, it inserts a header at
|
|||
|
the module load address, so the real start of the module is offset
|
|||
|
from the address shown in ksyms. The size of the header varies with
|
|||
|
kernel version: to find out the size for your kernel, check a module
|
|||
|
that exports symbols (like pcmcia_core above), and compare a symbol
|
|||
|
address with nm output for that symbol. In this example,
|
|||
|
register_ss_entry is loaded at an offset of 0xc200d10c - 0xc200d000 =
|
|||
|
0x010c, while ``nm pcmcia_core.o'' shows the offset as 0x00c0, so the
|
|||
|
header size is 0x010c - 0x00c0 = 0x004c bytes.
|
|||
|
|
|||
|
Back to 3c574_cs, our fault offset is 0x0081, and subtracting the
|
|||
|
0x004c header, the real module offset is 0x0035. Now looking at ``nm
|
|||
|
3c574_cs.o | sort'', we see:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
0000002c d if_names
|
|||
|
0000002c t tc574_attach
|
|||
|
00000040 d mii_preamble_required
|
|||
|
00000041 d dev_info
|
|||
|
|
|||
|
|
|||
|
|
|||
|
So, the fault is located in tc574_attach().
|
|||
|
|
|||
|
In this example, the fault did not cause a total system lockup, so
|
|||
|
ksyms could be executed after the fault happened. In other cases, you
|
|||
|
may have to infer the module load addresses indirectly. The same
|
|||
|
sequence of events will normally load modules in the same order and at
|
|||
|
the same addresses. If a fault happens when a certain card is
|
|||
|
inserted, get the ksyms output before inserting the card, or with a
|
|||
|
different card inserted. You can also manually load the card's driver
|
|||
|
modules with insmod and run ksyms before inserting the card.
|
|||
|
|
|||
|
For more background, see ``man insmod'', ``man ksyms'', and ``man
|
|||
|
klogd''. In the kernel source tree, Documentation/oops-tracing.txt is
|
|||
|
also relevant. Here are a few more kernel debugging hints:
|
|||
|
|
|||
|
|
|||
|
<20> Depending on the fault, it may also be useful to translate
|
|||
|
addresses in the ``Call Trace'', using the same procedure as for
|
|||
|
the main fault address.
|
|||
|
|
|||
|
<20> To diagnose a silent lock-up, try to provoke the problem with X
|
|||
|
disabled, since kernel messages sent to the text console will not
|
|||
|
be visible under X.
|
|||
|
<20> If you kill klogd, most kernel messages will be echoed directly on
|
|||
|
the text console, which may be helpful if the problem prevents
|
|||
|
klogd from writing to the system log.
|
|||
|
|
|||
|
<20> To cause all kernel messages to be sent to the console, for 2.2 and
|
|||
|
later kernels, if /proc/sys/kernel/printk exists, do:
|
|||
|
|
|||
|
|
|||
|
echo 8 > /proc/sys/kernel/printk
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<20> The key combination <RightAlt><ScrLk> prints a register dump on the
|
|||
|
text console. This may work even if the system is otherwise
|
|||
|
completely unresponsive, and the EIP address can be interpreted as
|
|||
|
for a kernel fault.
|
|||
|
|
|||
|
<20> For 2.2 and later kernels configured with CONFIG_MAGIC_SYSRQ
|
|||
|
enabled, various emergency functions are available via special
|
|||
|
<Alt><SysRq> key combinations, documented in
|
|||
|
Documentation/sysrq.txt in the kernel source tree.
|
|||
|
|
|||
|
|
|||
|
7.3. Low level PCMCIA debugging aids
|
|||
|
|
|||
|
The PCMCIA modules contain a lot of conditionally-compiled debugging
|
|||
|
code. Most of this code is under control of the PCMCIA_DEBUG
|
|||
|
preprocessor define. If this is undefined, debugging code will not be
|
|||
|
compiled. If set to 0, the code is compiled but inactive. Larger
|
|||
|
numbers specify increasing levels of verbosity. Each module built
|
|||
|
with PCMCIA_DEBUG defined will have an integer parameter, pc_debug,
|
|||
|
that controls the verbosity of its output. This can be adjusted when
|
|||
|
the module is loaded, so output can be controlled on a per-module
|
|||
|
basis without recompiling.
|
|||
|
|
|||
|
Your default configuration for syslogd may discard kernel debugging
|
|||
|
messages. To ensure that they are recorded, edit /etc/syslog.conf to
|
|||
|
ensure that ``kern.debug'' messages are recorded somewhere. See ``man
|
|||
|
syslog.conf'' for details.
|
|||
|
|
|||
|
There are a few register-level debugging tools in the debug_tools/
|
|||
|
subdirectory of the PCMCIA distribution. The dump_tcic and dump_i365
|
|||
|
utilities generate register dumps for ISA-to-PCMCIA controllers. In
|
|||
|
3.1.15 and later releases, dump_i365 is replaced by dump_exca, which
|
|||
|
is similar but also works for PCI-to-CardBus bridges. Also new in
|
|||
|
3.1.15 for CardBus bridges is the dump_cardbus tool, which interprets
|
|||
|
the CardBus-specific registers. These are all most useful if you have
|
|||
|
access to a datasheet for the corresponding controller chip. The
|
|||
|
dump_cis utility (dump_tuples in pre-3.0.2 distributions) lists the
|
|||
|
contents of a card's CIS (Card Information Structure), and decodes
|
|||
|
most of the important bits. And the dump_cisreg utility displays a
|
|||
|
card's local configuration registers.
|
|||
|
|
|||
|
The memory_cs memory card driver is also sometimes useful for
|
|||
|
debugging problems with 16-bit PC Cards. It can be bound to any card,
|
|||
|
and does not interfere with other drivers. It can be used to directly
|
|||
|
access any card's attribute memory or common memory. Similarly for
|
|||
|
CardBus cards, the memory_cb driver can be bound to any 32-bit card,
|
|||
|
to give direct access to that card's address spaces. See the man
|
|||
|
pages for more information.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
7.4. /proc/bus/pccard
|
|||
|
|
|||
|
On 2.2 and later kernels, the PCMCIA package will create a tree of
|
|||
|
status information under /proc/bus/pccard. Much of the information
|
|||
|
can only be interpreted using the data sheets for the PCMCIA host
|
|||
|
controller. Its contents may depend on how the drivers were
|
|||
|
configured, but may include all or some of the following:
|
|||
|
|
|||
|
|
|||
|
/proc/bus/pccard/{irq,ioport,memory}
|
|||
|
If present, these files contain resource allocation information
|
|||
|
to supplement the normal kernel resource tables. Recent
|
|||
|
versions of the PCMCIA system may obtain additional resource
|
|||
|
information from the Plug and Play BIOS if configured to do so.
|
|||
|
|
|||
|
/proc/bus/pccard/drivers
|
|||
|
In recent releases, this lists all currently loaded PCMCIA
|
|||
|
client drivers. Unlike /proc/modules, it also lists drivers
|
|||
|
that may be statically linked into the kernel.
|
|||
|
|
|||
|
/proc/bus/pccard/*/info
|
|||
|
For each socket, describes that socket's host controller and its
|
|||
|
capabilities.
|
|||
|
|
|||
|
/proc/bus/pccard/*/exca
|
|||
|
This contains a dump of a controller's ``ExCA'' Intel i82365sl-
|
|||
|
compatible register set.
|
|||
|
|
|||
|
/proc/bus/pccard/*/{pci,cardbus}
|
|||
|
For CardBus bridges, a dump of the bridge's PCI configuration
|
|||
|
space, and a dump of the bridge's CardBus configuration
|
|||
|
registers.
|
|||
|
|
|||
|
|
|||
|
7.5. Writing Card Services drivers for new cards
|
|||
|
|
|||
|
The Linux PCMCIA Programmer's Guide is the best documentation for the
|
|||
|
client driver interface. The latest version is always available from
|
|||
|
projects.sourceforge.net in /pub/pcmcia-cs/doc, or on the web at
|
|||
|
<http://pcmcia-cs.sourceforge.net>.
|
|||
|
|
|||
|
For devices that are close relatives of normal ISA devices, you will
|
|||
|
probably be able to use parts of existing Linux drivers. In some
|
|||
|
cases, the biggest stumbling block will be modifying an existing
|
|||
|
driver so that it can handle adding and removing devices after boot
|
|||
|
time. Of the current drivers, the memory card driver is the only
|
|||
|
``self-contained'' driver that does not depend on other parts of the
|
|||
|
Linux kernel to do most of the dirty work.
|
|||
|
|
|||
|
In many cases, the largest barrier to supporting a new card type is
|
|||
|
obtaining technical information from the manufacturer. It may be
|
|||
|
difficult to figure out who to ask, or to explain exactly what
|
|||
|
information is needed. However, with a few exceptions, it is very
|
|||
|
difficult if not impossible to implement a driver for a card without
|
|||
|
technical information from the manufacturer.
|
|||
|
|
|||
|
I have written a dummy driver with lots of comments that explains a
|
|||
|
lot of how a driver communicates with Card Services; you will find
|
|||
|
this in the PCMCIA source distribution in clients/dummy_cs.c.
|
|||
|
|
|||
|
|
|||
|
7.6. Guidelines for PCMCIA client driver authors
|
|||
|
|
|||
|
|
|||
|
I have decided that it is not really feasible for me to distribute all
|
|||
|
PCMCIA client drivers as part of the PCMCIA package. Each new driver
|
|||
|
makes the main package incrementally harder to maintain, and including
|
|||
|
a driver inevitably transfers some of the maintenance work from the
|
|||
|
driver author to me. Instead, I will decide on a case by case basis
|
|||
|
whether or not to include contributed drivers, based on user demand as
|
|||
|
well as maintainability. For drivers not included in the core
|
|||
|
package, I suggest that driver authors adopt the following scheme for
|
|||
|
packaging their drivers for distribution.
|
|||
|
|
|||
|
Driver files should be arranged in the same directory scheme used in
|
|||
|
the PCMCIA source distribution, so that the driver can be unpacked on
|
|||
|
top of a complete PCMCIA source tree. A driver should include source
|
|||
|
files (in ./modules/), a man page (in ./man/), and configuration files
|
|||
|
(in ./etc/). The top level directory should also include a README
|
|||
|
file.
|
|||
|
|
|||
|
The top-level directory should include a makefile, set up so that
|
|||
|
``make -f ... all'' and ``make -f ... install'' compile the driver and
|
|||
|
install all appropriate files. If this makefile is given an extension
|
|||
|
of .mk, then it will automatically be invoked by the top-level
|
|||
|
Makefile for the all and install targets. Here is an example of how
|
|||
|
such a makefile could be constructed:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
# Sample Makefile for contributed client driver
|
|||
|
FILES = sample_cs.mk README.sample_cs \
|
|||
|
modules/sample_cs.c modules/sample_cs.h \
|
|||
|
etc/sample.conf etc/sample etc/sample.opts \
|
|||
|
man/sample_cs.4
|
|||
|
all:
|
|||
|
$(MAKE) -C modules MODULES=sample_cs.o
|
|||
|
install:
|
|||
|
$(MAKE) -C modules install-modules MODULES=sample_cs.o
|
|||
|
$(MAKE) -C etc install-clients CLIENTS=sample
|
|||
|
$(MAKE) -C man install-man4 MAN4=sample_cs.4
|
|||
|
dist:
|
|||
|
tar czvf sample_cs.tar.gz $(FILES)
|
|||
|
|
|||
|
|
|||
|
|
|||
|
This makefile uses install targets defined in 2.9.10 and later
|
|||
|
versions of the PCMCIA package. This makefile also includes a
|
|||
|
``dist'' target for the convenience of the driver author. You would
|
|||
|
probably want to add a version number to the final package filename
|
|||
|
(for example, sample_cs-1.5.tar.gz). A complete distribution could
|
|||
|
look like:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
sample_cs.mk
|
|||
|
README.sample_cs
|
|||
|
modules/sample_cs.c
|
|||
|
modules/sample_cs.h
|
|||
|
etc/sample.conf
|
|||
|
etc/sample
|
|||
|
etc/sample.opts
|
|||
|
man/sample_cs.4
|
|||
|
|
|||
|
|
|||
|
|
|||
|
With this arrangement, when the contributed driver is unpacked, it
|
|||
|
becomes essentially part of the PCMCIA source tree. It can make use
|
|||
|
of the PCMCIA header files, as well as the machinery for checking the
|
|||
|
user's system configuration, and automatic dependency checking, just
|
|||
|
like a ``normal'' client driver.
|
|||
|
|
|||
|
In this example, etc/sample and etc/sample.opts would be the new
|
|||
|
driver's configuration scripts (if needed), and etc/sample.conf would
|
|||
|
contain any additions to the PCMCIA card configuration file. Starting
|
|||
|
with the 3.1.6 release, cardmgr will automatically process any *.conf
|
|||
|
files installed in /etc/pcmcia, so installation of contributed drivers
|
|||
|
should no longer require hand editing configuration files.
|
|||
|
|
|||
|
I will accept client drivers prepared according to this specification
|
|||
|
and place them in the /pub/pcmcia-cs/contrib directory on
|
|||
|
projects.sourceforge.net. The README in this directory will describe
|
|||
|
how to unpack a contributed driver.
|
|||
|
|
|||
|
The client driver interface has not changed much over time, and has
|
|||
|
almost always preserved backwards compatibility. A client driver will
|
|||
|
not normally need to be updated for minor revisions in the main
|
|||
|
package. I will try to notify authors of contributed drivers of
|
|||
|
changes that require updates to their drivers.
|
|||
|
|
|||
|
|
|||
|
7.7. Guidelines for Linux distribution maintainers
|
|||
|
|
|||
|
|
|||
|
If your distribution has system configuration tools that you would
|
|||
|
like to be PCMCIA-aware, please use the *.opts files in /etc/pcmcia
|
|||
|
for your ``hooks.'' These files will not be modified if a user
|
|||
|
compiles and installs a new release of the PCMCIA package. If you
|
|||
|
modify the main configuration scripts, then a fresh install will
|
|||
|
silently overwrite your custom scripts and break the connection with
|
|||
|
your configuration tools. Contact me if you are not sure how to write
|
|||
|
an appropriate option script, or if you need additional capabilities.
|
|||
|
|
|||
|
It is helpful for users (and for me) if you can document how your
|
|||
|
distribution deviates from the PCMCIA package as described in this
|
|||
|
document. In particular, please document changes to the startup
|
|||
|
script and configuration scripts. If you send me the appropriate
|
|||
|
information, I will include it in the ``Notes about specific Linux
|
|||
|
distributions''.
|
|||
|
|
|||
|
When building PCMCIA for distribution, consider including contributed
|
|||
|
drivers that are not part of the main PCMCIA package. For reasons of
|
|||
|
maintainability, I am trying to limit the core package size, by only
|
|||
|
adding new drivers if I think they are of particularly broad interest.
|
|||
|
Other drivers will be distributed separately, as described in the
|
|||
|
previous section. The split between integral and separate drivers is
|
|||
|
somewhat arbitrary and partly historical, and should not imply a
|
|||
|
difference in quality.
|
|||
|
|
|||
|
|
|||
|
|