Professional Documents
Culture Documents
Table of Contents
Linux PCMCIA HOWTO..................................................................................................................................1 David Hinds, dahinds@users.sourceforge.net. .......................................................................................1 1.General information and hardware requirements.................................................................................1 2.Compilation and installation.................................................................................................................1 3.Resolving installation and configuration problems..............................................................................1 4.Usage and features................................................................................................................................2 5.Advanced topics....................................................................................................................................2 6.Dealing with unsupported cards ............................................................................................................2 7.Debugging tips and programming information .....................................................................................2 1.General information and hardware requirements.................................................................................3 1.1 Introduction........................................................................................................................................3 1.2 Copyright notice and disclaimer........................................................................................................3 1.3 What is the latest version, and where can I get it?.............................................................................3 1.4 What systems are supported?.............................................................................................................4 1.5 What cards are supported?.................................................................................................................5 1.6 When will my favorite (unsupported) card become supported?........................................................5 1.7 Mailing lists and other information sources .......................................................................................5 1.8 Why don't you distribute binaries?....................................................................................................6 1.9 Why is the package so darned big?....................................................................................................6 2.Compilation and installation.................................................................................................................6 2.1 Prerequisites and kernel setup ............................................................................................................6 2.2 Installation.........................................................................................................................................8 2.3 Startup options...................................................................................................................................9 Card readers for desktop systems.............................................................................................11 2.4 System resource settings..................................................................................................................11 PowerBook specific settings.....................................................................................................12 2.5 Notes about specific Linux distributions.........................................................................................12 Debian.......................................................................................................................................12 Red Hat, Caldera, Mandrake .....................................................................................................13 Slackware..................................................................................................................................14 SuSE ..........................................................................................................................................14 3.Resolving installation and configuration problems............................................................................14 3.1 Base PCMCIA kernel modules do not load.....................................................................................15 3.2 Some client driver modules do not load..........................................................................................15 3.3 Interrupt scan failures......................................................................................................................16 3.4 IO port scan failures.........................................................................................................................17 3.5 Memory probe failures .....................................................................................................................18 3.6 Failure to detect card insertions and removals .................................................................................19 3.7 Interrupt delivery problems ..............................................................................................................19 3.8 System resource starvation..............................................................................................................20 3.9 Resource conflict only with two cards inserted...............................................................................20 3.10 Device configuration does not complete ........................................................................................21 4.Usage and features..............................................................................................................................21 4.1 Tools for configuring and monitoring PCMCIA devices................................................................21 The cardmgr configuration daemon ..........................................................................................22 The socket status file, stab........................................................................................................22 The cardctl and cardinfo utilities..............................................................................................22 i
Table of Contents
Inserting and ejecting cards......................................................................................................23 Card Services and Advanced Power Management...................................................................24 Shutting down the PCMCIA system .........................................................................................24 4.2 Overview of the PCMCIA configuration scripts.............................................................................24 4.3 PCMCIA network adapters..............................................................................................................25 Network device parameters......................................................................................................26 Comments about specific cards................................................................................................28 Diagnosing problems with network adapters ............................................................................29 4.4 PCMCIA serial and modem devices................................................................................................30 Serial device parameters...........................................................................................................31 Comments about specific cards................................................................................................31 Diagnosing problems with serial devices.................................................................................31 4.5 PCMCIA parallel port devices.........................................................................................................32 Parallel device parameters........................................................................................................33 Diagnosing problems with parallel port devices .......................................................................33 4.6 PCMCIA SCSI adapters..................................................................................................................34 SCSI device parameters............................................................................................................35 Comments about specific cards................................................................................................36 Diagnosing problems with SCSI adapters................................................................................37 4.7 PCMCIA memory cards..................................................................................................................37 Memory device parameters .......................................................................................................38 Using linear flash memory cards..............................................................................................39 4.8 PCMCIA ATA/IDE card drives .......................................................................................................40 ATA/IDE fixeddisk device parameters..................................................................................40 Diagnosing problems with ATA/IDE adapters .........................................................................41 4.9 Multifunction cards..........................................................................................................................41 5.Advanced topics..................................................................................................................................42 5.1 Resource allocation for PCMCIA devices.......................................................................................42 5.2 PCI interrupt configuration problems and solutions........................................................................42 An overview of PCI interrupt routing issues............................................................................43 CardBus bridge is not detected by the PCI BIOS.....................................................................45 PCI interrupt delivery problems .............................................................................................45 No PCI interrupt assignment; valid routing table.....................................................................46 No PCI interrupt assignment; unknown interrupt router..........................................................46 No PCI interrupt assignment; no routing table.........................................................................46 5.3 How can I have separate device setups for home and work?..........................................................47 5.4 Booting from a PCMCIA device.....................................................................................................48 The pcinitrd helper script..........................................................................................................49 Creating an initrd boot floppy ...................................................................................................50 Installing an initrd image on a nonLinux drive......................................................................50 6.Dealing with unsupported cards ..........................................................................................................52 6.1 Configuring unrecognized cards......................................................................................................52 6.2 Adding support for an NE2000compatible ethernet card..............................................................53 6.3 PCMCIA floppy interface cards......................................................................................................54 7.Debugging tips and programming information ...................................................................................54 7.1 Submitting useful bug reports..........................................................................................................54 7.2 Interpreting kernel trap reports........................................................................................................55 ii
Table of Contents
7.3 Low level PCMCIA debugging aids................................................................................................56 7.4 /proc/bus/pccard...............................................................................................................................57 7.5 Writing Card Services drivers for new cards...................................................................................58 7.6 Guidelines for PCMCIA client driver authors.................................................................................58 7.7 Guidelines for Linux distribution maintainers.................................................................................60
iii
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 ftp://projects.sourceforge.net/pub/pcmciacs/doc. An HTML version is at http://pcmciacs.sourceforge.net.
Linux PCMCIA HOWTO 3.8 System resource starvation 3.9 Resource conflict only with two cards inserted 3.10 Device configuration does not complete
5.Advanced topics
5.1 Resource allocation for PCMCIA devices 5.2 PCI interrupt configuration problems and solutions 5.3 How can I have separate device setups for home and work? 5.4 Booting from a PCMCIA device
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 continually under development. It probably 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.3 What is the latest version, and where can I get it?
The current major release of Card Services is version 3.1, and minor updates or bug fixes are numbered 3.1.1, 3.1.2, and so on. Source code for the latest version is available by FTP at projects.sourceforge.net in the /pub/pcmciacs directory, as pcmciacs3.1.?.tar.gz. There will usually be several versions here. I generally only keep the latest minor release for a given major release. New major releases may contain relatively untested code, so I also keep the latest version of the previous major release as a relatively stable fallback; the current fallback is 3.0.14. It is up to you to decide which version is more appropriate, but the CHANGES file will summarize the most important differences. 1.General information and hardware requirements 3
Linux PCMCIA HOWTO The Linux PCMCIA FTP site is mirrored at sunsite.unc.edu (and all sunsite mirror sites) in /pub/Linux/kernel/pcmcia. If you do not feel up to compiling the drivers from scratch, precompiled drivers are included with current releases of most of the major Linux distributions, including Slackware, Debian, Red Hat, Caldera, SuSE, and Yggdrasil, among others.
Linux PCMCIA HOWTO (Optional) the ``XForms'' X11 user interface toolkit. You need to have a complete linux source tree for your kernel, not just an uptodate 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.us.kernel.org/pub/linux/kernel/v2.2. Development kernels can be found in the corresponding v2.3 or v2.4 subdirectories. 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. 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. There is an unfortunate deficiency in the kernel config process in 1.2.X kernels, in that it is not possible to set configuration options (like SLIP compression) for a loadable module, so it is probably better to just link SLIP into the kernel if you need it. 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.* through 2.1.7 kernels. Older kernels do not support removeable IDE devices; 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 lowlevel drivers for particular host adapters should be disabled, as they will just take up space. If you want to modularize a driver that is needed for a PCMCIA device, you must modify /etc/pcmcia/config to specify what modules need to be loaded for what card types. For example, if the serial driver is modularized, then the serial device definition should be:
This package includes an Xbased 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.
2.2 Installation
Here is a synopsis of the installation process: Unpack pcmciacs3.1.?.tar.gz in /usr/src. Run ``make config'' in the new pcmciacs3.1.? directory. Run ``make all'', then ``make install''. 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 toplevel 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:
Alternate target install directory? If you are compiling the package for installation on another machine, specify an alternate target directory when prompted. This should be an absolute path. All files will be installed relative to this directory. You will then be able to tar this directory tree and copy to your target machine, and unpack relative to its root directory to install everything in the proper places. Newer PCMCIA releases do not ask for this; instead it can be set with the target= command line option to the Configure script. 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 nonroot 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 32bit (CardBus) card support? This option must be selected if you wish to use 32bit CardBus cards. It is not required for CardBus bridge support, if you only plan to use 16bit 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 builtin ``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. 2.2 Installation 8
Linux PCMCIA HOWTO 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 kernelspecific 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 noninteractively, for automatic builds or to quickly reconfigure after a kernel update. Some additional lessfrequentlyused 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 probe utility in the cardmgr/ subdirectory to determine this. There are two major types: the Databook TCIC2 type and the Intel i82365SLcompatible type. In a few cases, the probe command will be unable to determine your controller type automatically. If you have a Halikan NBD 486 system, it has a TCIC2 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 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 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''.
Linux PCMCIA HOWTO 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 two options: ``tcic'' or ``i82365''. Virtually all current controllers are in the ``i82365'' group. 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, lockups 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: 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., DX4100) seem to often benefit from increasing this from 6 (the default) to 12 or 16. The Cirrus PD6729 PCI controller has the fast_pci flag, which should be set if the PCI bus speed is greater than 25 MHz. For Vadem VG468 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. 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 with fast bus clocks, increasing this parameter (i.e., slowing down card accesses) may be beneficial for card recognition problems. This is not a timing issue, but if you have more than one ISAtoPCMCIA controller in your system 2.3 Startup options 10
Linux PCMCIA HOWTO 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 PCItoPCMCIA or PCItoCardBus bridges. Here are some timing settings for specific systems: On the ARM Pentium90 or Midwest Micro Soundbook Plus, use ``freq_bypass=1 cmd_time=8''. On a Midwest Micro Soundbook Elite, use ``cmd_time=12''. On a Gateway Liberty, try ``cmd_time=16''. On a Samsung SENS 810, use ``fast_pci=1''.
Linux PCMCIA HOWTO On the Compaq Presario 1020, exclude port 0x2f80x2ff, irq 3, irq 5. On the Dell Inspiron 7000, exclude irq 3, irq 5. On the Fujitsu C series, exclude port 0x2000x27f. On the HP Omnibook 4000C, exclude port 0x3000x30f. On the IBM ThinkPad 380, and maybe the 385 and 600 series, exclude port 0x2300x233, and irq 5. On IBM ThinkPad 600 and 770 models with internal modems, exclude port 0x2f80x2ff. On the IBM ThinkPad 600E and 770Z, change the high memory window to 0x600000000x60ffffff. On the Micron Millenia Transport, exclude irq 5, irq 9. On the NEC Versa M, exclude irq 9, port 0x2e02ff. On the NEC Versa P/75, exclude irq 5, irq 9. On the NEC Versa S, exclude irq 9, irq 12. On the NEC Versa 6000 series, exclude port 0x2f80x33f, irq 9, irq 10. On the NEC Versa SX, exclude port 0x3000x31f. On the ProStar 9200, Altima Virage, and Acquiline Hurricane DX4100, exclude irq 5, port 0x3300x35f. Maybe use memory 0xd80000xdffff. On the Siemens Nixdorf SIMATIC PG 720C, use memory 0xc00000xcffff, port 0x3000x3bf. On the TI TravelMate 5000, use memory 0xd40000xdffff. On the Toshiba Satellite 4030CDS, exclude irq 9. On the Toshiba T4900 CT, exclude irq 5, port 0x2e00x2e8, port 0x3300x338. On the Toshiba Tecra 8000, exclude irq 3, irq 5, irq 9. On the Twinhead 5100, HP 4000, Sharp PC8700 and PC8900, exclude irq 9 (sound), irq 12. On an MPC 800 Series, exclude irq 5, port 0x3000x30f for the CDROM.
Debian
Debian uses a System V boot script arrangement. The PCMCIA startup script is installed as /etc/init.d/pcmcia, and startup options are specified in /etc/pcmcia.conf. Debian's syslog configuration will place kernel messages in /var/log/messages and cardmgr messages in /var/log/daemon.log.
12
Linux PCMCIA HOWTO Debian distributes the PCMCIA system in two packages: the ``pcmciacs'' package contains cardmgr and other tools, man pages, and configuration scripts; and the ``pcmciamodules'' package contains the kernel driver modules.
if [ f /etc/sysconfig/networkscripts/ifcfg$2 ] ; then start_fn () { . /etc/sysconfig/networkscripts/ifcfg$1 if [ "$ONBOOT" = "yes" ] ; then /sbin/ifup $1 ; fi } stop_fn () { /sbin/ifdown $1 } fi
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 kernelsource RPM (kernelsource*.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.
13
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.
SuSE
SuSE uses a System V init script arrangement, with init scripts stored under /sbin/init.d. The PCMCIA startup script is installed as /sbin/init.d/pcmcia, and startup options are kept in /etc/rc.config. The SuSE startup script is somewhat limited and does not allow PCMCIA startup variables to be overridden from the lilo boot prompt.
Slackware
14
Linux PCMCIA HOWTO 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: 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. Support for multiport serial cards or multifunction cards that include serial or modem devices requires CONFIG_SERIAL_SHARE_IRQ to be enabled. The SCSI client drivers require that CONFIG_SCSI be enabled, along with the appropriate top level driver options (CONFIG_BLK_DEV_SD, CONFIG_BLK_DEV_SR, etc for 2.1 kernels). These may be built as modules. The network client drivers require that CONFIG_INET is enabled. Kernel networking support cannot be compiled as a module. The tokenring client requires that the kernel be compiled with CONFIG_TR enabled. There are two ways to proceed: Rebuild your kernel with the necessary features enabled. 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:
Module paths are specified relative to the toplevel module directory for the current kernel version; if no relative path is given, then the path defaults to the pcmcia subdirectory.
Linux PCMCIA HOWTO 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: The 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 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. 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 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.
Linux PCMCIA HOWTO probe is readonly, but in rare cases, reading from a device may interfere with an important system function, resulting in a lockup. 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.
Linux PCMCIA HOWTO In some cases, the default high memory window is not usable. On some IBM Thinkpad models, a window of 0x600000000x60ffffff will work in place of the default window.
Interrupt starvation often indicates a problem with the interrupt probe (see Interrupt scan failures). In some cases, the probe will seem to work, but only report one or two available interrupts. Check your system log to see if the scan results look sensible. Disabling the probe and selecting interrupts manually should help. If the interrupt probe is not working properly, the socket driver may allocate an interrupt for monitoring card insertions, even when interrupts are too scarce for this to be a good idea. You can switch the controller to polled mode by setting PCIC_OPTS to ``poll_interval=100'. Or, if you have a CardBus controller and an older version of the PCMCIA drivers, try ``pci_csc=1'', which selects a PCI interrupt (if available) for card status changes. IO port starvation is fairly uncommon, but sometimes happens with cards that require large, contiguous, aligned regions of IO port space, or that only recognize a few specific IO port positions. The default IO port ranges in /etc/pcmcia/config.opts are normally sufficient, but may be extended. If this is the problem, try uncommenting the ``include port 0x10000x17ff'' 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 16bit cards. Since CardBus memory windows can be mapped anywhere in the host's PCI address space (rather than just in the 640K1MB ``hole'' in PC systems), it is helpful to specify large memory windows in high memory, such as 0xa00000000xa0ffffff.
Linux PCMCIA HOWTO 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 nonworking card. Exclude these in /etc/pcmcia/config.opts, and restart the cardmgr daemon to reload the resource database.
Module ds
Size 5640
Used by 2
21
[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.
Socket 0: Adaptec APA1460 SlimSCSI 0 scsi aha152x_cs 0 0 scsi aha152x_cs 1 Socket 1: Serial or Modem Card 1 serial serial_cs 0
8 11 5
0 0 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.
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.
23
/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.
Linux PCMCIA HOWTO 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 userspecified 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''. 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.
case "$ADDRESS" in *,0,*,*) # definitions for network card in socket 0 ;; *,1,*,*) # definitions for network card in socket 1 ;; esac
25
Linux PCMCIA HOWTO Alternatively, they could be configured using their hardware addresses, as in:
case "$ADDRESS" in *,*,*,00:80:C8:76:00:B1) # definitions for a DLink card ;; *,*,*,08:00:5A:44:80:01) # definitions for an IBM card esac
IF_PORT Specifies the ethernet transceiver type, for certain 16bit cards that do not autodetect. See ``man ifport'' 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. Network device parameters 26
Linux PCMCIA HOWTO 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 spaceseparated 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. Network device parameters 27
Linux PCMCIA HOWTO 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 cards can 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:
The current (3.0.10 or later) 3c589 driver should quickly autodetect transceiver changes at any time. Earlier releases of the 3c589 driver had a somewhat slow and flaky transceiver autodetection algorithm. For these releases, the appropriate network cable should be connected to the card when the card is configured, or you can force autodetection with:
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. The Farallon EtherWave is actually based on the 3Com 3c589, with a special transceiver. Though the EtherWave uses 10baseTstyle connections, its transceiver requires that the 3c589 be configured in 10base2 mode. 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). 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. 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. 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 Comments about specific cards 28
Linux PCMCIA HOWTO 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. Some Linksys, DLink, and ICCard 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 vendorsupplied utility to select the transceiver, then warm boot Linux. Alternatively, a Linux utility to perform this function is available at ftp://projects.sourceforge.net/pub/pcmciacs/extras/dlport.c. 16bit PCMCIA cards have a maximum performance of 1.52 MB/sec. That means that any 16bit 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. 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/.
In 3.1.15 and later PCMCIA releases, the test_network script in the debugtools subdirectory of the PCMCIA source tree will spot some common problems. 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''. 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. 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. 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, misconfigured cards will usually fail silently. 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. 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. 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. 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.
29
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 builtin 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:
30
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".
In 3.1.15 and later PCMCIA releases, the test_modem script in the debugtools subdirectory of the PCMCIA source tree will spot some common problems. Is your card recognized as a modem? Check the system log and make sure that cardmgr identifies Serial device parameters 31
Linux PCMCIA HOWTO 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. 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 tipoff 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. 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. If the modem seems to work only very, very slowly, this is an almost certain indicator of an interrupt conflict. 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. 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.
32
If you configure your kernel to load the basic Linux parallel port driver as a module, you must edit /etc/pcmcia/config to indicate that the appropriate modules must be loaded. Edit the parallel device entry to read:
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 Parallel device parameters 33
Linux PCMCIA HOWTO 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. 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.
34
Linux PCMCIA HOWTO would say to load the core SCSI module and the toplevel disk driver module before loading the regular PCMCIA driver module. The PCMCIA Configure script will not automatically detect modularized SCSI modules, so you will need use the manual configure option to enable SCSI support. 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 EZDrive, 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.
Linux PCMCIA HOWTO 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 CDROM 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 MSDOS fs on /usr2 DO_FSTAB="y" ; DO_FSCK="y" ; DO_MOUNT="y" FSTYPE="msdos" OPTS="" MOUNTPT="/usr2" ;; *,sr,*,0,6,0) # Options for CDROM at SCSI ID 6 PARTS="" DO_FSTAB="y" ; DO_FSCK="n" ; DO_MOUNT="y" FSTYPE="iso9660" OPTS="ro" MOUNTPT="/cdrom" ;; esac
The Adaptec APA1480 CardBus card needs a large IO port window (256 contiguous ports aligned on a 256port 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. The Adaptec APA460 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 APA460 is not compatible with any existing Linux driver. 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. Comments about specific cards 36
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"
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. If you have compiled SCSI support as modules (CONFIG_SCSI is ``m''), you must modify /etc/pcmcia/config to load the SCSI modules before the appropriate *_cs driver is loaded. If you get ``aborting command due to timeout'' messages when the SCSI bus is probed, you almost certainly have an interrupt conflict. If the host driver reports ``no SCSI devices found'', verify that your kernel was compiled with the appropriate toplevel SCSI drivers for your devices (i.e., disk, tape, CDROM, and/or generic). If a toplevel driver is missing, devices of that type will be ignored.
Linux PCMCIA HOWTO 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.
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
38
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:
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.
39
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.
40
To use an ATA/IDE CDROM 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. 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). The Linux IDE driver may have trouble configuring certain removablemedia drives if no media is present at insertion time. The IBM Portable DriveBay has this problem. 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.
Linux PCMCIA HOWTO 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
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.Advanced topics
42
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 debugtools 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. An overview of PCI interrupt routing issues 43
Linux PCMCIA HOWTO Several PCMCIA module parameters affect PCI interrupt routing:
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.145.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 PCItoCardBus 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 An overview of PCI interrupt routing issues 44
Linux PCMCIA HOWTO socket. And the final line indicates the results of the scan for available interrupts.
Linux PCMCIA HOWTO 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.
Linux PCMCIA HOWTO 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 alreadyconfigured 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 schemespecific 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:
or
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). 5.3 How can I have separate device setups for home and work? 47
Linux PCMCIA HOWTO 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 readonly 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.
Linux PCMCIA HOWTO 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 nonPCMCIA drive, create an initrd image, and then reinstall to the PCMCIA target. The Linux BootdiskHOWTO 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.
To customize the initrd startup sequence, you could mount the image using the ``loopback'' device with a command like:
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.
49
mke2fs /dev/fd0 mount /dev/fd0 /mnt mkdir /mnt/etc /mnt/boot /mnt/dev cp a /dev/fd0 /dev/sda1 /mnt/dev cp [kernelimage] /mnt/vmlinuz cp /boot/boot.b /mnt/boot/boot.b gzip < [initrdimage] > /mnt/initrd
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 alternateroot mode.
50
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 nonLinux target partition and /mnt can be used as a mount point. First, create a subdirectory on the target for the Linux files:
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 readonly 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.
51
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)
card "Megahertz XJ2288 V.34 Fax Modem" version "MEGAHERTZ", "XJ2288", "V.34 PCMCIA MODEM" bind "serial_cs"
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. 6.Dealing with unsupported cards 52
Linux PCMCIA HOWTO After editing /etc/pcmcia/config, you can signal cardmgr to reload the file with:
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.
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 ``hardwire'' the address when the pcnet_cs module is initialized. Edit /etc/pcmcia/config.opts and add a hw_addr= option, like so: 6.2 Adding support for an NE2000compatible ethernet card 53
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.
Linux PCMCIA HOWTO 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 web site, so that they can be seen by others.
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'':
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 7.2 Interpreting kernel trap reports 55
Linux PCMCIA HOWTO 0x0035. Now looking at ``nm 3c574_cs.o | sort'', we see:
d t d d
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/oopstracing.txt is also relevant. Here are a few more kernel debugging hints: 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. To diagnose a silent lockup, try to provoke the problem with X disabled, since kernel messages sent to the text console will not be visible under X. 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. To cause all kernel messages to be sent to the console, for 2.1 kernels, if /proc/sys/kernel/printk exists, do:
echo 8 > /proc/sys/kernel/printk
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. For 2.1 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.
56
Linux PCMCIA HOWTO 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 registerlevel debugging tools in the debug_tools/ subdirectory of the PCMCIA distribution. The dump_tcic and dump_i365 utilities generate register dumps for ISAtoPCMCIA controllers. In 3.1.15 and later releases, dump_i365 is replaced by dump_exca, which is similar but also works for PCItoCardBus bridges. Also new in 3.1.15 for CardBus bridges is the dump_cardbus tool, which interprets the CardBusspecific 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 pre3.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 16bit 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 32bit card, to give direct access to that card's address spaces. See the man pages for more information.
7.4 /proc/bus/pccard
Starting with 2.1.103 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 i82365slcompatible register set. /proc/bus/pccard/*/{pci,cardbus} For CardBus bridges, a dump of the bridge's PCI configuration space, and a dump of the 7.4 /proc/bus/pccard 57
# Sample Makefile for contributed client driver FILES = sample_cs.mk README.sample_cs \ modules/sample_cs.c modules/sample_cs.h \
58
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_cs1.5.tar.gz). A complete distribution could look like:
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/pcmciacs/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.
59
60