Frequently Asked Questions about Linux PCMCIA Card Services Version of this document: 1.10, 1994/12/31 18:55:17 If you have a question that is not answered by this document, please contact David Hinds . ======================================================================== Section 1. General information and hardware requirements Question 1.1. What is Card Services for Linux? Question 1.2. Where can I find the latest version? Question 1.3. What systems are supported? Question 1.4. What PCMCIA cards are supported? Question 1.5. When will card X be supported? Section 2. Compilation, installation, and configuration Question 2.1. What prerequisites do I need before installing? Question 2.2. When I try to load the sample drv_hello.o module, I get "___moddi3 undefined". What's wrong? Question 2.3. Why does insmod complain about undefined symbols? Question 2.4. How do I tell if it is working? Question 2.5. Why doesn't my system respond to card insertions? Question 2.6. How do I tell cardmgr how to identify a new card? Question 2.7. What do "could not adjust resource" messages mean? Question 2.8. How do I control which interrupt is used by a device? Question 2.9. Can I install Linux on a laptop over the net? Section 3. Problems with specific cards Question 3.1. Why doesn't my modem work? Question 3.2. Why does my Megahertz modem sometimes fail to work? Question 3.3. How do I select the transceiver type for my 3c589 card? Question 3.4. How do I use my PCMCIA floppy interface? Question 3.5. What's up with support for Xircom cards? Question 3.6. What's up with support for SCSI adapters? Question 3.7. Why do I get lots of errors when I eject my net card? Section 4. Usage and features Question 4.1. How do I unload PCMCIA drivers? Question 4.2. How does Card Services deal with Suspend/Resume? Question 4.3. How do I turn off a PCMCIA card without ejecting it? Section 5. Programming questions and debugging tips Question 5.1. How do I write a Card Services driver for card X? Question 5.2. How can I submit a helpful bug report? Question 5.3. How can I trace a kernel fault in a loadable module? Question 5.4. How can I get documentation for the PCMCIA standard? ======================================================================== Question 1.1. What is Card Services for Linux? Card Services for Linux is a complete PCMCIA support package. It includes a set of loadable kernel modules that implement a version of the PCMCIA Card Services 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 PCMCIA cards, so cards can be inserted and ejected at any time. ======================================================================== Question 1.2. Where can I find the latest version? The latest version is always available from cb-iris.stanford.edu in the /pub/pcmcia directory. There will sometimes be several versions here. In that case, the oldest version should be "stable", and newer versions generally contain more experimental code. It is up to you to decide which version is more appropriate, but the "CHANGES" file will summarize the most important differences. cb-iris.stanford.edu:/pub/pcmcia is mirrored on sunsite.unc.edu as /pub/Linux/kernel/pcmcia. I'll also try to upload the PCMCIA code to tsx-11.mit.edu in /pub/linux/packages/laptops/pcmcia/drivers now and then. ======================================================================== Question 1.3. What systems are supported? To the best of my knowledge, this code should run on any Linux-capable laptop. All common PCMCIA controllers are supported, including Intel, Cirrus, Vadem, VLSI, and Databook chips. Several people also use the package on desktop systems with PCMCIA card adapters. ======================================================================== Question 1.4. What PCMCIA cards are supported? The current release includes drivers for a variety of ethernet cards, a driver for modem and serial port cards, and a simple memory card driver that should support most SRAM cards and read-only access to 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. ======================================================================== Question 1.5. When will card X be supported? Unfortunately, I'm not in the device driver writing business, so if you'd like to have a driver for your favorite card, you're probably going to have to do some work on your own. The "SUPPORTED.CARDS" file mentions some cards for which driver work is currently in progress. I will try to help where I can. ======================================================================== Question 2.1. What prerequisites do I need before installing? For the latest version, you will need to have kernel version 1.1.72 or higher. There are no kernel patches specifically for PCMCIA support. You'll also need to have a relatively recent set of module utilities. If your man page for "insmod" describes the "[symbol=value ...]" syntax, your utilities are current enough. You need to have a complete linux source tree for your kernel, not just an up-to-date kernel image, when you compile the PCMCIA package. The PCMCIA modules contain some references to kernel source files. Current kernel sources and patches are available from tsx-11.mit.edu in /pub/linux/sources/system/v1.1. Current module utilities can be found in the same directory, in the file "modules-1.1.67.tgz". ======================================================================== Question 2.2. When I try to load the sample drv_hello.o module, I get "___moddi3 undefined". What's wrong? Nothing, really. The drv_hello module uses a "modulo" operator that gcc handles by calling a built-in function normally supplied by the libgcc library. Since the module isn't linked against this library, it results in an unresolved reference. Your module utilities are fine. ======================================================================== Question 2.3. Why does insmod complain about undefined symbols? If pcmcia_core.o loads fine, but loading i82365.o or tcic.o fails with undefined symbols like "_check_resource" and "register_ss_entry", your module utilities (insmod, lsmod, etc) are out of date. See Question 2.1 for more information. ======================================================================== Question 2.4. How do I tell if it is working? All the PCMCIA modules and the cardmgr daemon send status messages to the system log. This will usually be /usr/adm/messages. This file should be the first place you look when tracking down a problem. When submitting a bug report, you should always include the contents of this file. ======================================================================== Question 2.5. Why doesn't my system respond to card insertions? The most likely reason is that there is a conflict on the interrupt line being used to signal card status changes. Check /proc/interrupts to see what interrupt is being used by the low level driver (i82365.o or tcic.o). Try unloading the PCMCIA modules and re-loading this driver with a "cs_irq=#" option to select a different value. See the man pages for i82365 and tcic for the lists of choices. If you can't find an interrupt number that works, there is also a polled status mode: turn this on with a "poll_interval=100" option to insmod. ======================================================================== Question 2.6. How do I tell cardmgr how to identify a new card? 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 /usr/adm/messages that can be used to construct the config entry. If you do this, please forward a copy of your new config entry to me so that I can include it in the distributed version. ======================================================================== Question 2.7. What do "could not adjust resource" messages mean? These messages sometimes show up in /usr/adm/messages when you kill and then restart cardmgr. They are harmless. The first time cardmgr runs, it reads resource descriptions from /etc/pcmcia/config and tries to register these resources with Card Services. This only needs to be done once, and cannot be easily undone when cardmgr is shut down. So, the next time cardmgr runs, it tries to register the same resources, and will report a warning. ======================================================================== Question 2.8. How do I control which interrupt is used by a device? The ibmcc_cs, de650_cs, 3c589_cs, and serial_cs drivers each have a parameter called "irq_mask" for specifying which interrupts they may try to allocate. Each bit of irq_mask corresponds to one irq line: bit 0 is irq 0, bit 1 is irq 1, and so on. So, a mask of 0x1100 would correspond to irq 8 and irq 12. To limit a driver to use only one specific interrupt, its irq_mask should have only one bit set. These driver options should be set in your /etc/pcmcia/config file. For example: device "serial_cs" module "serial_cs" opts "irq_mask=0x1100" ... would specify that the serial driver should only use irq 8 or irq 12. Note that 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. ======================================================================== Question 2.9. Can I install Linux on a laptop over the net? I've created a set of 1.44M boot and root disks with PCMCIA support for the Slackware 2.1 distribution. The files are "pcboot14.gz" and "pcroot14.gz" on cb-iris.stanford.edu and sunsite.unc.edu (see Q1.2). The root disk includes cardmgr, the core PCMCIA modules, and all the network drivers. As for how to use these, you should familiarize yourself with the Slackware installation instructions, available from the usual FTP sites. For an NFS install, you will need to manually ifconfig the interface and set up appropriate routes. Please don't pester me with questions about Slackware installation -- I haven't even done it myself yet and it will only frustrate both of us! ======================================================================== Question 3.1. Why doesn't my modem work? That's a broad question, but here's a quick troubleshooting guide. 1. Is your card recognized as a modem? Check /usr/adm/messages 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 question 2.4 for details. 2. Is the modem configured successfully by serial_cs? Again, check /usr/adm/messages 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 -- maybe a second built-in serial port. Another tip-off of a conflict is if the device is reported to be an 8250; most modern PCMCIA modems should be identified as 16550A UART's. If you think you're seeing a port conflict, try un-commenting the resource exclusions for a second built-in serial port in /etc/pcmcia/config. 3. Is there an interrupt conflict? If /usr/adm/messages 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 to exclude this interrupt. ======================================================================== Question 3.2. Why does my Megahertz modem sometimes fail to work? This is an old problem that I still have not been able to track down. For some reason, Megahertz modems sometimes fail to get initialized correctly, and get stuck in an unresponsive state. When this happens, cardmgr will incorrectly identify the modem as an "anonymous memory card" and load the memory card driver. All I can suggest for now is to unplug and re-insert the card until it gets recognized; you might also try sending a HUP signal to cardmgr, which may or may not be able to "jump start" the card. I've also received one report from someone with a newer Megahertz modem that has a 16550-type UART. He says that he wasn't able to get this modem to work under Linux with "cu" until he configured the modem with: echo 'ATS=QV1X4&C1&D2S95=2W1&K3S36=7S95=255' > /dev/modem This initialization string was supplied by Megahertz tech support. ======================================================================== Question 3.3. How do I select the transceiver type for my 3c589 card? It would be nice if the driver could autodetect the difference between a 10baseT and a 10base2 connection, but I don't know how to do that. For now, you need to edit /etc/pcmcia/config and add an "if_ports=#" option to the 3c589_cs module definition. Check the tc589_cs man page for more details, but to select 10base2 (also known as BNC, or thin net, or coax), change: module "3c589_cs" to: module "3c589_cs" opts "if_port=3" ======================================================================== Question 3.4. How do I use my PCMCIA floppy interface? The PCMCIA floppy interface used in the Compaq Aero and a few other laptops is not yet supported by this package. If your laptop can initialize this card before Linux boots, you should be able to use it by telling Card Services to ignore that socket. Note that you will not be able to "hot swap" this card. To configure Card Services to ignore a socket, use the "exclude=#" parameter when you load the i82365 or tcic driver. See the man pages for more details. ======================================================================== Question 3.5. What's up with support for Xircom cards? Xircom does not share technical information about its cards without a non-disclosure agreement. This means that it is not really possible to develop freely distributable drivers for Xircom cards without doing legally dubious things like reverse engineering DOS drivers. Unless their policy changes, it is doubtful that Linux drivers for Xircom products will ever become available. ======================================================================== Question 3.6. What's up with support for SCSI adapters? There is now an "alpha" kernel patch to support loadable SCSI drivers. On tsx-11.mit.edu, get /usr/linux/ALPHA/scsi/kdiff.loadable_scsi.1162. The patch, against kernel version 1.1.62, is quite large (148K). This is scheduled to go into the 1.3.X kernels, after the 1.2 kernel is released. For now, you probably shouldn't bother fooling with it. In the interim, there are "stand-alone" drivers for the QLogic SCSI and Bus Toaster SCSI cards. The Bus Toaster driver includes a "point enabler" for Intel i82365-compatible PCMCIA controllers, but there is no support for Databook controllers. The Qlogic driver is just the ISA card driver. To use the Qlogic driver, you need to configure the card under DOS and then warm boot Linux. This will probably only work for some laptops. For the Bus Toaster card, source files are at: lamont.ldeo.columbia.edu:/pub/Linux/bus_toaster and questions should be addressed to: Gennady Pratusevich The Qlogic driver is included with the Linux kernel as of 1.1.73. Questions should be addressed to: Thomas Zerucha In order for these drivers to coexist with Card Services, you will need to tell Card Services to ignore the socket containing the SCSI card. You will not be able to "hot swap" the card or make use of any other Card Services features. ======================================================================== Question 3.7. Why do I get lots of errors when I eject my net card? The 8390-based cards (i.e., everything except the 3c589) share some code with all the other Linux 8390 drivers, in 8390.o. This module does not "know" about PCMCIA cards. When a card is ejected, it often generates a spurious interrupt. The 8390 driver tries to handle this interrupt, but can only read garbage from the (now absent) card. So, it generates a string of kernel error messages. They seem harmless. If you "ifconfig down" the interface before ejecting, they should go away. If these messages bother you, there is a small kernel patch that will prevent them, in patches/8390.patch. Some systems will actually lock up when you eject a live network card. This same patch should fix these problems as well. ======================================================================== Question 4.1. How do I unload PCMCIA drivers? To unload the entire PCMCIA package, first kill cardmgr. This will shut down all sockets and unload all client drivers. Then, "rmmod" the three core drivers: ds, either i82365 or tcic, and pcmcia_core, in that order. If a device is currently in use, its driver may not be allowed to unload. The driver will shut down when its last device is closed. ======================================================================== Question 4.2. How does Card Services deal with Suspend/Resume? I've started to integrate APM (Advanced Power Management) support into Card Services. This is working with an internal development version of the APM support package, and should be generally available soon, so stay tuned. ======================================================================== Question 4.3. How do I turn off a PCMCIA card without ejecting it? Use the new "cardctl" command. "cardctl suspend #" will suspend one socket, and turn off its power. The corresponding "resume" command will wake up the card in its previous state. ======================================================================== Question 5.1. How do I write a Card Services driver for card X? Start by looking at the sample drivers. For devices that are close relatives of normal ISA devices, you'll 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. I've written a skeleton driver with lots of comments that explains a lot of how a driver communicates with Card Services; you'll find this in modules/skeleton.c. ======================================================================== Question 5.2. How can I submit a helpful bug report? Here are some things that should be included in all bug reports: -- Your system type, and the output of the 'probe' command -- What PCMCIA cards you are using -- Your Linux kernel version, and PCMCIA version -- Any changes you've made to the startup files in /etc/pcmcia -- Contents of /usr/adm/messages, even if you don't see anything that looks interesting. The "make.options" file includes a few choices for building the kernel modules with various kinds of debugging code turned on. This may or may not be useful, depending on your problem. It is probably better to only turn on the really verbose debugging if I ask you to. If your problem involves a kernel fault, the register dump from the fault is only useful if you can track down the fault address, EIP. If it is in the main kernel, you can look up the address in zSystem.map to identify the function at fault. If it is in a loadable module, see Question 5.3. Send bug reports to dhinds@allegro.stanford.edu. I prefer to handle bug reports by email -- please avoid calling me at home or at work. ======================================================================== Question 5.3. How can I trace a kernel fault in a loadable module? Kernel faults in modules are tricky to trace because the address reported by the fault handler has to be converted to an offset in a module. There is a kernel patch in patches/module.patch that makes this a bit easier. With this patch, /proc/modules will report the base address of each loadable module. The EIP address in the fault report can then be tied to a particular module, and subtracting that module's base address gives an offset inside that module. Then, you can invoke gdb on that module, and look up the offset with the "list" command. This will only work if you've compiled that module with "-g" to include debugging information. ======================================================================== Question 5.4. How can I get documentation for the PCMCIA standard? This is a tricky one. There is no proper documentation for the Linux Card Services interface. I based this on a preliminary draft document for the Solaris implementation, which I've heard is being used as the basis for the official 32-bit Unix PCMCIA specification. The genuine PCMCIA standard is only available for a steep price from the PCMCIA association itself. There is a special offer until Dec. 31 where you can get the current 2.1 standard for $125, or order the soon to be released PC Card Standard for $339. In January, this will go up to $399. Personal Computer Memory Card International Association 1030 East Duane Avenue, Suite G Sunnyvale, CA 94086 USA (408) 720-0107, (408) 720-9416 FAX, (408) 720-9388 BBS One alternative is the "PCMCIA Developer's Guide", written by Michael Mori, available from Sycard Technology for $89.95: Sycard Technology 1180-F Miraloma Way Sunnyvale, CA 94086 USA (408) 749-0130, (408) 749-1323 FAX Programming information for various PCMCIA controllers is available from the corresponding chip vendors: Intel Corporation (800) 628-8686 Cirrus Logic (510) 623-8300 Vadem (408) 943-9301 Databook Inc. (716) 889-4204