Laptop computers have unique needs. These include Power Management
(APM and ACPI), infrared interfaces (IrDA), and PC cards (PCMCIA).
Occasionally,
such components can also be found in desktop computers. These are essentially
no different than those used in laptops. For this reason, their
use and configuration is summarized in this chapter.
PCMCIA stands for ``Personal Computer Memory Card International Association.'' It is used as a general term for all hardware and software involved.
The essential component is the PCMCIA card. There are two distinct types:
If the PCMCIA service is active, determine the type of the inserted card with the command cardctl ident. A list of supported cards can be found in SUPPORTED.CARDS in /usr/share/doc/packages/pcmcia. The current version of the PCMCIA-HOWTO is also located there.
The second necessary component is the PCMCIA controller or the PC card or CardBus bridge. This establishes the connection between the card and the PCI bus and, in older devices, the connection to the ISA bus as well. These controllers are almost always compatible with the Intel chip i82365. All common models are supported. The type of controller is shown with the command pcic_probe. If this is a PCI device, the command lspci -vt also shows some interesting information.
From kernel 2.4, there are alternative modules in the kernel sources. These form the kernel PCMCIA system. The basic modules were written by Linus Torvalds. They support the more recent CardBus bridges better.
Unfortunately, these two systems are not compatible. There are various sets of card drivers in both systems. For this reason, only one system can be used, depending on the hardware involved. The default in SuSE Linux is the more recent kernel PCMCIA. It is possible to change the system, however. To do this, the variable <PCMCIA_SYSTEM> in the file /etc/sysconfig/pcmcia must be given either the value external or kernel. Then PCMCIA must be restarted with rcpcmcia restart. For temporary changes, use the commands rcpcmcia restart external or rcpcmcia restart kernel. If pcmcia is not running, use the option start instead of restart. Detailed information about this can be found in /usr/share/doc/packages/pcmcia/README.SuSE
The kernel modules for both systems are located in the kernel packages. In addition, the packages pcmcia and hotplug are required. When PCMCIA is started, the modules pcmcia_core, i82365 (external PCMCIA) or yenta_socket (kernel PCMCIA), and ds are loaded. In some very rare cases, the module tcic is required instead of i82365 or yenta_socket. They initialize the existing PCMCIA controller and provide basic functionality.
If a card is inserted, card manager or hotplug determines the type and function of the card then loads the corresponding modules. If this is successful, card manager or hotplug starts certain initialization scripts, depending on the function of the card, which in turn establish a network connection, mount partitions from external SCSI hard drives, or carry out other hardware-specific actions. The scripts for the card manager are located in /etc/pcmcia. The scripts for hotplug can be found in /etc/hotplug.
If the card is removed, card manager or hotplug terminates the various card activities using the same scripts. Finally, those modules that are no longer required are unloaded.
Both the start process of PCMCIA and card events are recorded in the system log (/var/log/messages). Here, it is specified which PCMCIA system is currently used and which daemons have been used by which scripts to set up things. In theory, a PCMCIA card can simply be removed. This works very well for network, modem, or ISDN cards as long as there are no open network connections. It does not work in connection with partitions mounted to an external hard drive or with NFS directories. Here, ensure that these units are synchronized and cleanly unmounted. This is no longer possible, of course, if the card has already been removed. In case of doubt, the command cardctl eject may be of help. This command deactivates all cards still in the laptop. To deactivate one card, also specify the slot number, for example, cardctl eject 0.
Whether PCMCIA or hotplug is started when booting can be specified with the YaST runlevel editor or on the command line using chkconfig. In /etc/sysconfig/pcmcia, there are four variables:
The assignment of drivers to PCMCIA cards for the card manager can be found in the files /etc/pcmcia/config and /etc/pcmcia/*.conf. First, config is read then the *.conf in alphabetical order. The last entry found for a card is decisive. Details on the syntax of these files can be found in pcmcia. The assignment of drivers to PCMCIA cards for hotplug is described in 7).
ISDN modems also exist for PCMCIA cards. These are modem cards or multifunction cards with an additional ISDN connection kit. They are treated like an ordinary modem.
There are also ``soft modems'' for PCMCIA cards. As a rule, these are not supported. If there are some drivers, they must be integrated individually into the system.
External hard drives, CD-ROM drives, and similar devices must be switched on before the PCMCIA card is inserted into the slot. SCSI devices must be actively terminated.
Note
Before a SCSI or IDE card is removed, all partitions on the devices connected
must be unmounted. If you have forgotten to do this, you can only access
these devices again after rebooting the system, even if the rest of the system
continues to run in a stable manner.
You can also install Linux entirely on these external hard drives. However, the boot process is then somewhat more complicated.
A boot disk is required in all cases -- containing the kernel and an initial ramdisk (initrd). More information about this can be found in 11. The initrd contains a virtual file system that includes all required PCMCIA modules and programs. The boot disk and boot disk images are constructed in the same way. With these, you could always boot your external installation. It is, however, tiresome to load the PCMCIA support every time by hand. More advanced users might create their own boot floppy disk, customized to their own particular system. Hints for doing this can be found in the PCMCIA-HOWTO in the section Booting from a PCMCIA Device.
Occasionally, there are problems with certain laptops and certain cards when using PCMCIA. Most difficulties can be solved with little trouble, if you approach the problem systematically.
First, find out if the problem is with the card or with the PCMCIA-based system. For this reason, always start the computer first without the card inserted. Only insert the card when the base system appears to function correctly. All meaningful messages are recorded in /var/log/messages. The file should therefore be viewed, with tail -f /var/log/messages while the necessary tests are made. In this way, the error can be narrowed down to one of the two following cases.
If the system hangs when booting with the message PCMCIA: Starting services or other strange things happen, starting PCMCIA the next time the system is booted can be prevented by entering NOPCMCIA=yes at the boot prompt. To isolate the error further, the base modules of the PCMCIA system used are manually loaded.
These commands are used to do this:
or, in very rare cases,
earth :# modprobe -t <dir> tcic
and
The critical modules are the first two.
If the error occurs when pcmcia_core is loaded, the manual pages for pcmcia_core can help. The options described there can first be tested using modprobe. As an example, switch off the APM support for the PCMCIA module. In a few cases, there could be problems with this. Use the setting do_apm=0 to deactivate power management:
If the chosen option is successful, it can be written to the variable <PCMCIA_CORE_OPTS> in the file /etc/sysconfig/pcmcia:
Checking free IO areas can lead to problems in isolated cases if other hardware components are disturbed by this. Get around this with probe_io=0.
If several options should be used, they must be separated by spaces:
If errors occur when loading the module i82365, refer to i82365.
A problem in this context is a resource conflict -- if an interrupt, IO port, or memory area is occupied twice. Although the module i82365 checks these resources before they are made available to a card, sometimes just this check will lead to problems. Thus, checking the interrupt 12 (PS/2 devices) on some computers leads to the mouse or keyboard hanging. In this case, the parameter irq_list=<List of IRQs> can help. The list should contain all IRQs to use. For example, enter the command modprobe i82365 irq_list=5,7,9,10 or permanently add the list of IRQs to /etc/sysconfig/pcmcia:
In addition, there are /etc/pcmcia/config and /etc/pcmcia/config.opts. These files are evaluated by card manager. The settings made in them are only relevant when loading the driver modules for the PCMCIA cards. In /etc/pcmcia/config.opts, IRQs, IO ports, and memory areas can be included or excluded. The difference from the option irqlist is that the resources excluded in config.opts are not used for a PCMCIA card, but are still checked by the base module i82365.
Here, there are basically three variations: the card is not detected, the driver cannot be loaded, or the interface made available by the driver is set up incorrectly.
Determine whether the card is managed by the card manager or hotplug. For external PCMCIA, card manager always takes control, for kernel PCMCIA, card manager manages PC card cards and hotplug manages CardBUS cards. Here, only card manager is discussed. Hotplug problems are discussed in 7.
Another cause is a resource conflict. For most PCMCIA cards, it is irrelevant with which IRQ, IO port, or memory area they are operated, but there are exceptions. First test only one card and, if necessary, switch off other system components, such as the sound card, IrDA, modem, or printer. The allocation of system resources can be viewed with the command lsdev (it is quite normal that several PCI devices share the same IRQ).
One possible solution would be to use a suitable option for the module i82365 (see PCMCIA_PCIC_OPTS). Many card driver modules also have options. Find these using the command modinfo /lib/modules/<the correct pcmcia directory>/<driver>.o (the complete path is needed to locate the correct driver). There is also a manual page for most modules. rpm -ql pcmcia | grep man lists all manual pages contained in package pcmcia. To test the options, the card drivers can also be unloaded by hand. Again, ensure that the module is using the correct PCMCIA system.
When a solution has been found, the use of a specific resource can, in general, be allowed or forbidden in the file /etc/pcmcia/config.opts. There is even room here for options for card drivers. If the module pcnet_cs should be operated exclusively with IRQ 5, for example, the following entry is required:
One problem that sometimes occurs with 10/100-Mbit network cards is incorrect automatic identification of the transmission method. Use the command ifport or mii_tool to view and modify the transmission method. To have these commands run automatically, the script /etc/pcmcia/network must be individually adjusted.
PCMCIA is already required for installation if you want to install via network or if the CD-ROM is operated via PCMCIA. To do this, start with a boot floppy disk. In addition, one of the module floppy disks is required.
After booting from floppy disk (or after selecting ` Manual Installation' booting from CD), the program linuxrc is started. Select ` Kernel Modules (Hardware Drivers)' ->` Load PCMCIA Module'. Two entry fields appear in which to enter options for the modules pcmcia_core and i82365. Normally, these fields can be left blank. The manual pages for pcmcia_core and i82365 are available as text files on the first CD in the directory docu.
SuSE Linux 8.2 is then installed with the external PCMCIA system. During the installation, system messages are sent to various virtual consoles. Switch to them using
+ function key.
During the installation, there are terminals on which commands can be run. As long as linuxrc is running, use console 9 (a very spartan shell). After YaST starts, there is a bash shell and many standard system tools on console 2.
If the wrong driver module for a PCMCIA card is loaded during installation, the boot floppy disk must be modified manually. This requires a detailed knowledge of Linux, however. When the first part of the installation is finished, the system is partially or completely rebooted. In rare cases, it is possible that the system will hang when the PCMCIA is started. At this point the installation is already at an advanced stage, so Linux can be started without PCMCIA using the boot option NOPCMCIA=yes, at least in text mode. See also 8. It is possible that you can change some settings for the system on console 2 before the first part of the installation is completed, so the reboot will run successfully.
cardctl is an essential tool for obtaining information from PCMCIA and carrying out certain actions. In cardctl, find many details. Enter just cardctl to obtain a list of the valid commands.
There is also a graphical front-end for this program -- cardinfo, shown in Figure 8.1) -- with which the most important things can be controlled. For this to work, the package pcmcia-cardinfo must be installed.
Additional helpful programs from the pcmcia package are ifport, ifuser, probe, and rcpcmcia. These are not always required. To find out about everything contained in the package pcmcia, use the command rpm -ql pcmcia.
If you want to update the kernel, you should use the kernel packages provided by SuSE. If it is necessary to compile your own kernel, the PCMCIA modules must also be recompiled. It is important that the new kernel is already running when these modules are recompiled, because various information is extracted from it. The pcmcia package should already be installed, but not started. In case of doubt, run the command rcpcmcia stop. Install the PCMCIA source package and enter
The new packages will be stored in /usr/src/packages/RPMS. The package pcmcia-modules contains the PCMCIA modules for external PCMCIA. This package must be installed with the command rpm -force, because the module files belong officially to the kernel package.
For more information about specific laptops, visit the Linux Laptop home page at http://linux-laptop.net. Another good source of information is the Moblix home page athttp://tuxmobil.org/. As well as a lot of interesting information, also find a Laptop-Howto and an IrDA-Howto. In addition, there is also the article Laptops and Notebooks (PCMCIA) in the SuSE Support Database at http://sdb.suse.de/en/sdb/html/laptop.html.
There are situations when a modified configuration of the computer system is required. This would mostly be the case for mobile computers that are operated in varying locations. It could, however, also be that a desktop system temporarily uses other hardware components or you simply want to experiment a little. In all these cases, returning to the original system should be made an easy task. It would be even better if this modification of the configuration could be easily reproduced.
Up to the present, there had only been a solution to this problem for PCMCIA hardware. Various configurations could be stored there in certain profiles. SCPM was developed from there, lifting the restriction to PCMCIA. The ``System Configuration Profile Management'' allows to keep an arbitrarily chosen part of the system configuration in customized profiles. It is like making snapshots of the system configuration that can be restored at any time and the framing can be deliberately chosen.
The main application is network configuration on laptops, but different network configurations also often require different settings of other services, such as e-mail or proxies. Then other elements follow, like different printers at home and at the office (even offices), a separate X server configuration for the video beamer at conferences, special power-saving settings for the road, or the differing time zone in the agency abroad. Increasing use of this tool leads to the continuous discovery of new requirements. Feel free to contact us and share your thoughts and ideas about SCPM with us. SCPM is based on a flexible framework in an effort to allow even server-based profile management. Please give your wishes, inspirations, and error descriptions via our web front-end at http://www.suse.de/feedback/.
The following are some terms that are used across the rest of the SCPM documentation and in the YaST module.
A YaST module serves as a graphical front-end to SCPM and is provided an alternative to the command line front-end. Because the functionality of both front-ends is substantially the same and the knowledge of the command line front-end is useful in many cases, only the latter is described here. The operation of the YaST module for SCPM becomes very easy in combination with the help texts provided there. The few differring features of the YaST module are mentioned where appropriate.
The most current documentation is always the info pages for SCPM. Read these with tools like Konqueror (with the command konqueror info:scpm) or emacs. On the console, use info or pinfo. Technical information is provided at /usr/share/doc/package/scpm. Running scpm without any arguments returns a command option summary.
SCPM must be activated before it can be used. By default SCPM handles network and printer settings as well as the XFree86 configuration. If you need to manage special services or configuration files, you have to activate appropriate Resource Groups. In order to list the predefined Resource Groups you may use the list scpm list_groups. If you just want to see the already activated Groups, use scpm list_groups -a. These commands have to be issued as user root on the command line. Activation or deactivation of a group is done with the command scpm activate_group NAME or scpm deactivate_group NAME, where NAME has to be susbtituted by the relevant group name. All the Resource Groups may also be configured with the YaST profile manager.
Activate SCPM with scpm enable. When run for the first time, SCPM is initialized, which takes a few seconds. Deactivate SCPM with scpm disable at any time to prevent the unintentional switching of profiles. A subsequent reactivation simply resumes the initialization.
A profile named default already exists after SCPM is activated. Get a list of all available profiles with scpm list. This so far only existing profile is thus also the active one which can be verified with scpm active. The profile default is a basic configuration from which the other profiles are derived. This is why all settings that should be identicaly in all profiles should be made first. These modifications are then stored in the active profile with scpm reload. The profile default can however be arbitrarily used, renamed or deleted.
There are two possibilities to add a new profile. If the new profile (named work here) should be based on the profile default, create it with scpm copy default work. The command scpm switch work changes into the new profile, which can then be modified. Sometimes the system configuration was modified for special purposes that should be kept in a new profile. The command scpm add work creates a new profile by saving the current system configuration in the profile work and marking it as active. Running scpm reload then saves changes to the profile work.
Rename or delete profiles with the commands scpm rename x y and scpm delete x. For example, to rename work to project use scpm rename work project. Delete project with scpm delete project. Only the active profile cannot be deleted.
The available commands are:
The YaST module only offers an ` Add' button. Pressing it opens a dialog in which to select whether an existing profile should be copied or the current system configuration should be saved. Use ` Edit' for renaming.
The command scpm switch work switches to another profile (the profile work, in this case). You can switch to the active profile to save modified settings of the system configuration. Alternatively, use scpm reload to do this.
When switching profiles, SCPM first checks which resources of the active profile have been modified. It then queries whether the modification of each resource should be added to the active profile or dropped. These questions only concern the profile being left.
SCPM then compares the current system configuration with the profile to which to switch. In the phase, SCPM evaluates which system services need to be stopped or restarted due to mutual dependencies or to reflect the changes in configuration. This is like a partial system reboot that concerns only a small part of the system while the rest continues operating without change.
It is only at this point that
You can enter a description to every profile that is displayed with scpm list. For the active profile it may be set with scpm set description ``text''. Provide the name of the profile for inactive profiles, for instance, scpm set description ``text'' work. It is sometimes desired to perform additional actions which are not (yet) provided by SCPM while switching from one profile to another. Up to four executable programs or scripts can be attached to the profile for this purpose. They are called in various phases of the switching process. These phases are:
Switching from profile work to profile home thus proceeds as follows:
These actions can also be attached with the command set by entering scpm set prestop <filename>, scpm set poststop <filename>, scpm set prestart <filename>, or scpm set poststart <filename>. The call must be made to an executable -- scripts must refer to the correct interpreter and must be executable at least for the superuser.
All additional settings entered with set can be queried with get. The command scpm get poststart, for instance, returns the name of the poststart call or simply nothing if nothing has been attached.
Such settings can be reset by overwriting with "". This means
that the command scpm set prestop removes
the attached prestop program.
All set and get commands can be applied to an arbitrary profile in the same manner as comments are added. For example, scpm get prestop <filename> work or scpm get prestop work.
Caution
These scripts or programs should not be modifiable by
arbitrary users because they are executed with the rights of the
superuser. It is recommended to make scripts only readable to the
superuser because they can contain sensitive information. It
is best to provide these programs with the permissions
-rwx--- root root with the commands chmod 700
variablefilename and chown root.root <filename>.
It is possible to select a profile during the boot process by providing the boot parameter PROFILE=<name-of-the-profile> at the boot prompt. In the boot loader configuration (/boot/grub/menu.lst), the option title reflects the name of the profile. For example:
Systems that still use LILO as the boot loader may use File
22 as an example.
boot = /dev/hda
change-rules
reset
read-only
menu-scheme = Wg:kw:Wg:Wg
prompt
timeout = 80
message = /boot/message
image = /boot/vmlinuz
label = home
root = /dev/hda6
initrd = /boot/initrd
append = "vga=0x317 hde=ide-scsi PROFILE=home"
image = /boot/vmlinuz
label = work
root = /dev/hda6
initrd = /boot/initrd
append = "vga=0x317 hde=ide-scsi PROFILE=work"
image = /boot/vmlinuz
label = road
root = /dev/hda6
initrd = /boot/initrd
append = "vga=0x317 hde=ide-scsi PROFILE=road"
Then you can select the desired profile at the boot prompt.
In most cases, SCPM should function smoothly. There are however some pitfalls, which are described here.
SCPM is currently not able to survive a system update. The difficulty lies in the fact that, with a system update, the data stored in the profiles is not cleanly updated by the automatic mechanisms. SCPM then detects a system update and refuses to work. In this situation, you should get an error message from SCPM that contains your operating system installation changed/is unknown, read man page! In this case, reinitialize SCPM with scpm -f enbale. Your profiles, however, will be lost and you must set them up again.
Sometimes it can also occur that SCPM stops working during a switch procedure. This may be caused by some outside effect, such as a user abort, a power fault, another similar problem, or even an error in SCPM itself. In this case, an error message saying SCPM is locked appears the next time you start SCPM. This is for system safety, because the data stored in its database may differ from the state of the system. To solve this issue, delete the lock file with rm /var/lib/scpm/#LOCK then update your database with scpm -s reload. After this procedure, proceed as usual.
If you want to change the Resource Group Configuration of an already initialized SCPM, there is no real problem doing so. However, you must run scpm rebuild after adding or deleting groups. This adds new resources to all profiles and removes the deleted ones. The deleted ones are then lost to the system, which may cause problems if they are configured specifically in your profiles. The only exception is the current profile, because it is not touched by SCPM. If you reconfigure your system with YaST, you do not need to rebuild manually because YaST does it.
Power management requires correspondingly designed hardware and existing BIOS routines. Most notebooks and many modern desktop computers meet these requirements. The APM (Advanced Power Management) standard has generally been used so far for this. These are basically functions implemented in the BIOS of the computer. This is why power management does not work equally well on all devices. It is currently advisable to use APM on laptops with a functioning implementation of it. This is because there are manufacturers that dropped APM in favor of completely relying on the more recent ACPI (Advanced Configuration and Power Interface) standard. ACPI is, however, based on a more complex concept and requires a good cooperation of hardware manufacturers, BIOS programmers, and operating system experts. The Linux implementation of ACPI is still incomplete and therefore only partially usable. A substantial improvement in this matter can only be expected for the 2.6 kernel.
While many of these functions are of general interest, they become really important in mobile environments. These functions are described below along with the systems on which they can be used.
The complete state of the system is written to random access memory (RAM) and the entire system is subsequently put to sleep. The computer consumes only very little power in this state, allowing battery power to span stretches of time between twelve hours up to several days. The advantage of this state is the ability to resume work at the same point within a few seconds without having to boot and load necessary applications first. It is sufficient with most modern devices to close the lid to suspend and to simply open to resume work. This corresponds to the ACPI state S3.
The computer can last for longer than a winter in this operating state (the term hibernation alludes to this), because the state of the system is completely written to hard disk and the system is subsequently turned off. Resuming from hibernation takes between half a minute and one and a half minutes and the state upon suspension is likewise completely restored. Some manufacturers offer sensible hybrid variations of this mode (for instance, RediSafe in IBM Thinkpads). Hibernation corresponds to the ACPI state S4. Linux also offers a pure software solution, which, however, is not included in SuSE Linux. Information is available at http://falcon.sch.bme.hu/~seasons/linux/swsusp.html.
Apart from monitoring the charge status, it is equally important to take appropriate action when the power reserves run out. This is also handled by the BIOS APM routines in most cases. The apmdacpid or klaptopdaemon can be alternatively used for this.
The computer is completely turned off following a shutdown. This is especially of importance when an automatic shutdown is executed shortly before the battery runs out.
The substantial component for conserving power is the hard disk, which can be spun down for a shorter or longer amount of time depending on the reliability of the whole system. However, the risk of a loss of data rises with the duration of the rest periods. Other components can be deactivated via ACPI (at least theoretically) or permanently in the BIOS setup. The infrared port should, where applicable, be deactivated for as long as its services are not required (see 8).
APM generally only offers the possibility to select from various settings in the BIOS setup. Special tools are available for controlling hardware-specific settings on some devices, such as tpctl and apmiser from the package tpctl for IBM Thinkpads. The processor speed can be controlled with the procspeed application from the package apmd. The processor speed can only be influenced directly with ACPI. Therefore, these possibilities are covered in the ACPI section.
Some of the power saving functions are executed by the APM itself. Standby and suspend can be activated with key combinations or by closing the lid on many laptops. There is, at first, basically no need for contribution to this on part of the operating system. Corresponding packages and a suitable kernel must be installed if it is desired to invoke these functions by command, if it is necessary to execute certain actions before suspension, or to simply check the battery level.
APM support is integrated in the precompiled kernels of SuSE Linux. However, it is only activated if ACPI is not implemented in the kernel and an APM BIOS is detected. The APM support can be activated at the boot prompt with acpi=off. The command cat /proc/apm can be used to check if APM was activated. Everything is in order if a line containing various numbers is returned. Now, the command shutdown -h should shut down the computer.
Spurious behavior can occasionally arise from some incompletely compliant BIOS implementations. Some problems can be circumvented with special boot parameters, which previously were kernel configuration options. All parameters are entered at the boot prompt in the form apm=<parameter>:
The apmd daemon monitors the battery and can invoke certain actions when a standby or a suspend event occurs. It is located in the package apmd. It is not indispensable for operation, yet can be helpful for some problems.
apmd is not started automatically on boot. The settings for the system services, however, can be modified with the YaST runlevel module if necessary. The chkconfig utility can alternatively be used. The service can be called manually with the command rcapmd start.
A few configuration variable are present in /etc/sysconfig/powermanagement. Only a few hints are provided here because the file is commented.
Furthermore, there are additional options, like for adjusting the key repeat rate or the system clock after a suspend or for shutting down the laptop properly when the APM BIOS sends a ``battery critical'' event. The script /usr/sbin/apmd_proxy, which performs the jobs described above, can be adjusted to any requirements for even more specialized actions.
package apmd contains a few additional handy utilities. The utility apm checks and returns the current battery charge level or puts the system into standby (apm -S) or suspend (apm -s) mode. Refer to apm.
The command apmsleep suspends the system for a given time.
tailf can be used instead of tail -f to watch a log file without preventing the hard disk from spinning down.
There are of course also tools for the X Window System. The package apmd also contains the xapm utility for displaying the charge level of the battery. The kbatmon applet displays the charge level of the rechargeable battery to users of the KDE desktop and can also suspend the system. The xosview monitoring utility is likewise interesting as an alternative.
ACPI is the abbreviation for Advanced Configuration and Power Interface. ACPI is designed to enable the operating system to configure and control the individual hardware components. Accordingly, ACPI supersedes both PnP as well as APM. The part of ACPI responsible for initializing the hardware is not covered in this chapter. Additionally, there is little to do for the user in this regard.
The BIOS provides tables containing information about the individual components and methods for the access to the hardware. This information is used by the operating system for tasks such as assigning interrupts or activating or deactivating components as needed. However, as operations performed by the operating system perform operations integrated in the BIOS, the functionality depends on the BIOS implementation. The boot messages are logged to /var/log/boot.msg. Here ACPI reports which tables it was able to find and read.
The ACPI standard defines a variety of system states. The main states are as follows:
Furthermore, the states D0-D3 are available for all hardware components. In these states, the individual components are active, suspended, or off. There are special states for specific operational situations only known to the processor. The C states are introduced by CPU commands and cannot be influenced directly:
In addition, ACPI provides information about the battery, AC adapter, temperature, and fan. It also reports system events such as ``close lid'' or ``low battery''.
Then a number of modules must be loaded for OSPM ( ``Operating System Power Management''). These are loaded by the start script of the ACPI daemon. If any of these modules causes problems, it can be excluded from the loading or unloading process in /etc/sysconfig/powermanagement. The system log (/var/log/messages) contains the messages of the modules. Here, see which components were detected.
In /proc/acpi, you will now find a number of files that provide information on the system state or which can be used to actively change some states. However, many features do not work yet, either because they are still under development or because they are not implemented by the manufacturer.
Caution
To date, neither suspend to RAM or suspend
to disk (hibernation) work with ACPI. Due to kernel-specific reasons,
these features will only be available starting with kernel 2.6 (or
kernel 2.5). If you think you can do it, you can
integrate the sw-susp patch in your kernel.
All files (except dsdt and fadt) can be read with cat. In some of the files, settings can be modified by using echo X > file to specify suitable values for X (all objects in /proc are not real files on the hard disk but an interface for the kernel). Here is a description of the most important files:
The ACPI daemon processes events similarly to the APM daemon. These are currently merely some switching events, like the operation of the power button or the closing of the lid. All events are logged in the system log. The variables ACPI_BUTTON_POWER and ACPI_BUTTON_LID contain instructions for these events. The script /usr/sbin/acpid_proxy can be modified as well as the configuration of the acpid utility in /etc/acpi/ for more control options.
Unlike apmd, little is preconfigured here, as ACPI in Linux is still in a very dynamic development stage. If necessary, configure acpid yourself. If you have any suggestions on preparatory actions, please send an e-mail to http://www.suse.de/feedback.
CPUs for mobile devices have the possibility to adjust the processor frequency to the current system demands. The system interface to this technology is available outside the ACPI subsystem. In /proc/cpufreq, read the current frequency and adjust it in /proc/sys/cpu/0/speed*. More information is available in /usr/src/linux/Documentation/cpufreq/.
To adapt the CPU frequency automatically, use the cpufreqd daemon. This is not started by default. More information about starting system services is available in Section 12. The documentation for cpufreqd is found in /usr/share/doc/packages/cpufreqd/README.SuSE and in the manual page (man cpufreqd). All system settings are configured in /etc/sysconfig/powermanagement.
There are two different types of problems. On one hand, there might be error in the ACPI cord of the kernel that was not detected in time. In this case, a solution will be made available for download. On the other hand, there might be problems in the BIOS of a computer. This happens more often and is more annoying. Unfortunately, deviations from the ACPI specifications are sometimes purposely integrated in the BIOS to circumvent errors of the ACPI implementation in other widespread operating systems. Hardware components that have serious mistakes in the ACPI implementation are recorded in a blacklist to prevent the Linux kernel from using ACPI for these components.
If you encounter a problem, the first thing you should do is update the BIOS. This will solve many problems. If the computer does not boot properly, one of the following boot parameters may be helpful:
Another important step is to take a closer look at the boot messages. To do this, use the command dmesg | grep -2i acpi (or all other messages, since the problem may be due to something else than ACPI) the computer has booted. If an error occurs with the parsing of an ACPI table, at least the most important table -- the DSDT -- can be replaced by integrating an improved table in an individual kernel. This will cause the faulty DSDT of the BIOS to be ignored. However, this is not a simple task and requires some assistance by an expert. Bug-fixed DSDTs are available on the Internet for some computers.
For the kernel configuration, there is a switch that activates ACPI debug messages. If you compiled and installed a kernel with ACPI debugging, experts looking for an error can be supported with detailed information.
If you experience BIOS or hardware problems, it is always advisable to contact the manufacturer of the device. Although the manufacturers may not always be able to provide assistance for Linux, it is still important that they hear the word ``Linux'' as often as possible. The manufacturers will only take it seriously if they realize that an adequate number of their customers utilize Linux. Of course you can also contact the manufacturer to tell him that you use Linux on the hardware without any difficulties.
Additional documentation and help is available in the following sources:
An idling hard disk can be spun down in Linux. The hdparm utility serves the purpose of modifying various settings of a hard disk. The -y option puts the hard disk instantly into standby mode and the -Y option turns it off completely. The command hdparm -S <x> results in the hard disk spinning down after a certain time of inactivity. The <x> variable has a nonlinear scale: 0 turns the mechanism off and the hard disk runs continuously. Values between 1 and 240 are multiplied by five seconds. Values between 241 and 251 correspond to one to eleven times thirty minutes.
One problem is the number of processes in Linux that write to the hard disk, continuously waking it up. It is hence important to understand how Linux handles data that is supposed to be written to the hard disk.
All data is first written into a buffer in random access memory. This buffer is watched by the kernel update daemon kupdated.The buffer is flushed to the hard disk every time the data reaches a certain age or the buffer becomes filled to a certain degree. The size of the buffer is dynamic and depends on the size of the memory and the system load. kupdated is set by default to small time intervals because the preservation of data integrity is a primary goal. It checks the buffer every five seconds and informs the bdflush daemon when data is older than thirty seconds or the buffer is filled by more than thirty percent. The bdflush daemon then writes the data to the hard disk. It also writes independently of kupdated, for instance, when the buffer is full. Operators of a stable system can modify these settings. They must, however, be aware that this is done by risking data corruption.
The settings can be read with cat /proc/sys/vm/bdflush. The first value is the the flushing threshold of the buffer. The sixth value is the maximum age limit for buffered data in hundredths of a second. The fifth value is the checking interval for kupdated and is likewise given in hundredths of a second. For instance, to increase the kupdated interval to one minute, the new values are entered into this file with
The unchanged values are simply copied from the output and the trailing values can be omitted. Thus, entering
changes the flushing threshold of the buffer to sixty percent. The remaining values are described in the file Documentation/filesystems/proc.txt of the kernel sources.
Note
Changes to the settings of the kernel update daemon influence
data intergrity. If in doubt, leave them be.
The settings for the hard disk time-out, the kupdated interval, the buffer threshold, and the maximum age of data can be duplicated in /etc/sysconfig/powermanagement: one set for battery operation and one set for external power supply. The variables are described in the section about apmd and within the file itself. ``Journaling file systems'', like reiserfs or ext3, write their metadata independently of bdflush, which prevents the hard disk from spinning down. At the time of writing, ext3 and jbd respect the fifth value of /proc/sys/vm/bdflush and also write their metadata less often if this value were raised. This is not yet the case for reiserfs. It is best to rely on the ext2 file system in cases of doubt.
It is necessary to observe how any used applications behave. Good text editors, for instance, regularly keep hidden backups of the currently changed file on disk. This will repeatedly wake up the hard disk. Such program features can also be turned off, but this endangers data integrity.
IrDA (``Infrared Data Association'') is an industry standard for wireless communication with infrared light. Many laptops sold nowadays are equipped with an IrDA compatible transceiver that enables communication with other devices, such as printers, modems, LANs, or other laptops. The transfer speed ranges from 2400 bps up to 4 Mbps.
There are two IrDA operation modes. The standard mode SIR accesses the infrared port through a serial interface. This mode works on almost all systems and is sufficient for most requirements. The faster mode FIR requires a special driver for the IrDA chip. There are not, however, such drivers for all chips. The desired mode additionally must be set in the BIOS setup of the computer. This is also where it can be determined which serial interface is used for the SIR mode.
Information about IrDA can be found in the IrDA how-to by Werner Heuser at http://tuxmobil.org/Infrared-HOWTO/Infrared-HOWTO.html and on the web site of the Linux IrDA Project http://irda.sourceforge.net/.
The necessary kernel modules are included in the kernel package. The package irda provides the necessary helper applications for supporting the infrared interface. The documentation can be found at /usr/share/doc/packages/irda/README after the installation of the package.
The IrDA system service is not started automatically by the booting process. Use the YaST runlevel module to change the settings of the system services. The application chkconfig can be used alternatively. IrDA unfortunately consumes noticeably more battery power, because a ``discovery packet'' is sent every few seconds to detect other peripheral devices automatically. This is why IrDA should only be started when needed. The interface can always be activated manually with the command rcirda start or deactivated with the stop parameter. All necessary kernel modules are automatically loaded when the interface is activated.
The file /etc/sysconfig/irda contains only the one variable <IRDA_PORT>. This is where the interface used in SIR mode is set. The script /etc/irda/drivers of the infrared support package sets this variable.
Data can be sent to the device file /dev/irlpt0 for printing. The device file /dev/irlpt0 acts just like the normal /dev/lp0 cabled interface except the printing data is sent wireless with infrared light.
Printers used with the infrared interface are installed just like printers connected to the parallel or serial ports. Make sure the printer is in visible range of the infrared interface and the infrared support is started.
Communication with other hosts and with mobile phones or other similar devices is conducted through the device file /dev/ircomm0. The Siemens S25 and Nokia 6210 mobile phones, for instance, can dial and connect to the Internet with the wvdial application using the infrared interface. A data synchronization with a Palm Pilot is equally possible in this way when the device setting of the corresponding application has been set to /dev/ircomm0.
Only those devices can be accessed without any other adjustments that support the printer or IrCOMM protocols. Devices that support the IROBEX protocol, such as the 3Com Palm Pilot, can be accessed with special applications like irobexpalm and irobexreceive. Refer to the IR-HOWTO on this subject. The protocols supported by the device are stated in brackets behind the name of the device in the output of irdadump. IrLAN protocol support is still a ``work in progress'' -- it is unfortunately not stable yet but will surely also be available for Linux in the near future.
The superuser SuSE @nohyphen root can check with the command irdadump whether the other device has been recognized by the system in case devices do not work at the infrared interface.
Something similar to Output 14 appears regularly when a Canon BJC-80 printer is in visible range of the computer:
Check the configuration of the interface in case there is no output or the other device does not reply. Verify that the correct interface is used. The infrared interface is sometimes located at /dev/ttyS2 or at /dev/ttyS3 and another interrupt than IRQ 3 is used sometimes. These settings can be checked and modified in the BIOS setup menu of almost every laptop.
A simple CCD video camera can also help in determining whether the infrared LED lights up at all. Most video cameras can see infrared light, whereas the human eye cannot.