| SUSE LINUX – Administration Guide Chapter 14. PCMCIA / 14.5. Troubleshooting | ||||
|---|---|---|---|---|
 | 14.4. Utilities | 14.6. For More Information |  | |
| SUSE LINUX – Administration Guide Chapter 14. PCMCIA / 14.5. Troubleshooting | ||||
|---|---|---|---|---|
| 14.4. Utilities | 14.6. For More Information | | |
Most PCMCIA-related difficulties with laptops or certain cards can be identified and solved by approaching the problem systematically. First, find out if the problem is caused by the card or by the PCMCIA base system. To do this, boot the computer without inserting any card. If the base system seems to work smoothly, insert the card. All messages are logged in /var/log/messages. While searching for the cause of the problem, monitor this file with tail -f /var/log/messages. In this way, the problem can be narrowed down to one of the following two cases.
If the system hangs at the message PCMCIA: Starting services or other strange things happen when the system is booted, reboot the system and disable PCMCIA by entering NOPCMCIA=yes at the boot prompt. To isolate the error, manually load the three base modules of the PCMCIA system one by one.
To load the PCMCIA modules manually, execute the commands modprobe pcmcia_core, modprobe yenta_socket, and modprobe ds as the user root. In very rare cases, tcic, i82365, or i82092 must be used instead of yenta_socket. The two modules that are loaded first are the critical modules.
If the error occurs while loading pcmcia_core, refer to the manual page of pcmcia_core. The options described in this manual page can first be tested with the command modprobe. For example, consider the testing of free I/O areas. Sometimes, this test can cause problems if it disrupts other hardware components. This can be avoided with the option probe_io=0:
modprobe pcmcia_core probe_io=0
If the selected option is successful, set the variable PCMCIA_CORE_OPTS in the file /etc/sysconfig/pcmcia to the value probe_io=0. Separate multiple options with spaces:
PCMCIA_CORE_OPTS="probe_io=0 setup_delay=10"
Errors that occur while loading the yenta_socket module indicate problems of a more basic nature, such as the resource allocation by ACPI.
The files /etc/pcmcia/config and /etc/pcmcia/config.opts are interpreted by the card manager. The settings they contain are partly used for starting cardmgr and partly for loading the driver modules for PC cards. IRQs, I/O ports, and memory address ranges can be included or excluded in the file /etc/pcmcia/config.opts. In rare cases, access to an incorrect I/O area can result in a system crash. If this is the case, try to limit these areas.
Basically, there are three types of errors: the card is not detected, the driver cannot be loaded, or the interface provided by the driver is misconfigured. It is important to know whether the card is controlled by the card manager or by hotplug. The card manager controls PC cards, and the hotplug controls CardBus cards.
If the system does not react when inserting a card and the manual execution of the command cardctl insert does not help either, the interrupt allocation to PCI devices may be incorrect. If this is the case, other PCI devices such as the network card may also have problems. In this case, the boot parameter pci=noacpi or other PCI or ACPI parameters may be useful.
If the card is not detected, the message unsupported Card in Slot x appears in /var/log/messages. This message merely indicates that the card manager is not able to assign a driver to the card. The file /etc/pcmcia/config or /etc/pcmcia/*.conf is needed for this assignment. This driver database can easily be extended by using existing entries as a template. Enter the command cardctl ident to find out details about the card. More information about this is available in the PCMCIA HOWTO (Section 6) and in the manual page of pcmcia. After editing /etc/pcmcia/config or /etc/pcmcia/*.conf, reload driver assignment with the command rcpcmcia reload.
One reason for this may be that the driver database contains an incorrect assignment. This may happen if, for example, a manufacturer uses a different chip in an outwardly unmodified card model. Some models may only work or work better with drivers other than the preselected drivers. In this case, you need detailed information about the card. If necessary, post your problem on a mailing list or ask the Advanced Support.
For CardBus cards, the entry HOTPLUG_DEBUG=yes must be inserted in the file /etc/sysconfig/hotplug. Subsequently, check the system log for messages indicating whether the driver was loaded (successfully).
A resource conflict is another possible cause. For most PCMCIA cards, it does not matter with which IRQ, I/O port, or memory area they are operated, but there may be exceptions. If this is the case, test only one card at a time and disable other system components, such as the sound card, IrDA, modem, and printer, temporarily. View the resource allocation of the system with the command lsdev as the user root. It is perfectly acceptable if several PCI devices use the same IRQ.
One possible solution is to find a suitable option for the card driver module. Enter modinfo driver to list the options. A manual page is available for most modules. rpm -ql pcmcia | grep man lists all manual pages the pcmcia package contains. To test the options, the card drivers can be unloaded manually.
Once you have found a solution, you can generally permit or prohibit the use of a certain resource in /etc/pcmcia/config.opts. The options for card drivers can also be entered in this file. For example, to use the pcnet_cs module exclusively with IRQ 5, add the following entry:
module pcnet_cs opts irq_list=5
In this case, carefully check the configuration of the interface and the name of the configuration with getcfg to eliminate configuration errors. The variable DEBUG in the file /etc/sysconfig/network/config and the variable HOTPLUG_DEBUG in the file /etc/sysconfig/hotplug should be set to yes. For other cards or if this does not help, you can add the line set -vx in the script executed by the card manager or by hotplug (see /var/log/messages). In this way, every single command of the script is logged in the system log. If you find a critical section in a script, enter and test the respective commands in a terminal.
