• Новости
• Библиотека
• Е-книги
• Авторское
• Форум
• Каталог ссылок
• Каталог ПО
• О сайте
• Карта сайта

Наши партнеры

Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

Purchase	Copyright © 2002 Paul Sheer. Click here for copying permissions.	Home

42. The LINUX Kernel Source, Modules, and Hardware Support

This chapter explains how to configure, patch, and build a kernel from source. The configuration of device drivers and modules is also discussed in detail.

42.1 Kernel Constitution

A kernel installation consists of the kernel boot image, the kernel modules, the System.map file, the kernel headers (needed only for development), and various support daemons (already provided by your distribution). These constitute everything that is called ``Linux'' under LINUX, and are built from about 50 megabytes of C code of around 1.5 million lines.

• The LINUX kernel image is a 400 to 600-KB file that sits in /boot/ (see Chapter 31). If you look in this directory, you might see several kernels. The choice of which to boot is probably available to you at boot time, through lilo.

  The kernel in /boot/ is compressed. That is, it is gzip compressed and is actually about twice the size when unpacked into memory on boot.

• The kernel also has detached parts called modules. These all sit in /lib/modules/<version>/. They are categorized into the subdirectories below this directory. In kernel 2.2 there were about 400, modules totaling about 9 megabytes.

  Modules are actually just shared object files, like the .o files we created in Section 23.1. They are not quite the same as Windows device drivers, in that it is not generally possibly to use a module on a kernel other than the one it was compiled for--hence the name ``module'' is used instead of ``driver.'' Modules are separated out of the kernel image purely to save RAM. Modules are sometimes compiled into the kernel in the same way that our test program was statically linked on page . In this case, they would be absent from /lib/modules/<version>/ and should not really be called modules. In this chapter I show how to create compiled-in or compiled-out versions of modules when rebuilding the kernel.

• Next is the System.map file, also in /boot. It is used by klogd to resolve kernel address references to symbols, so as to write logs about them, and then also by depmod to work out module dependencies (what modules need what other modules to be loaded first).

• Finally, the kernel headers /usr/src/linux/include are used when certain packages are built.

• The ``various support daemons'' should be running already. Since 2.2, these have been reduced to klogd only. The other kernel daemons that appear to be running are generated by the kernel itself.

42.2 Kernel Version Numbers

The kernel is versioned like other packages: linux-major .minor .patch. Development kernels are given odd minor version numbers; stable kernels are given even minor version numbers. At the time of writing, the stable kernel was 2.2.17, and 2.4.0 was soon to be released. By the time you read this, 2.4.0 will be available. This chapter should be entirely applicable to future stable releases of 2.4.

42.3 Modules, insmod Command, and Siblings

A module is usually a device driver pertaining to some device node generated with the mknod command or already existing in the /dev/ directory. For instance, the SCSI driver automatically locks onto device major = 8, minor = 0, 1,..., when it loads; and the Sound module onto device major = 14, minor = 3 ( /dev/dsp), and others. The modules people most often play with are SCSI, Ethernet, and Sound modules. There are also many modules that support extra features instead of hardware.

Modules are loaded with the insmod command, and removed with the rmmod command. This is somewhat like the operation of linking shown in the Makefile on page . To list currently loaded modules, use lsmod. Try (kernel 2.4 paths are different and are given in braces)

5	insmod /lib/modules/<version>/fs/fat.o ( insmod /lib/modules/<version>/kernel/fs/fat/fat.o ) lsmod rmmod fat lsmod

rmmod -a further removes all unused modules.

Modules sometimes need other modules to be present in order to load. If you try to load a module and it gives <module-name>: unresolved symbol <symbol-name> error messages, then it requires something else to be loaded first. The modprobe command loads a module along with other modules that it depends on. Try

insmod /lib/modules/2.2.12-20/fs/vfat.o ( insmod /lib/modules/<version>/kernel/fs/vfat/vfat.o ) modprobe vfat

modprobe, however, requires a table of module dependencies. This table is the file /lib/modules/<version>/modules.dep and is generated automatically by your startup scripts with the command

/sbin/depmod -a

although you can run it manually at any time. The lsmod listing also shows module dependencies in brackets.

5          10          15

Module                  Size  Used by de4x5                  41396   1  (autoclean) parport_probe           3204   0  (autoclean) parport_pc              5832   1  (autoclean) lp                      4648   0  (autoclean) parport                 7320   1  (autoclean) [parport_probe parport_pc lp] slip                    7932   2  (autoclean) slhc                    4504   1  (autoclean) [slip] sb                     33812   0  uart401                 6224   0  [sb] sound                  57464   0  [sb uart401] soundlow                 420   0  [sound] soundcore               2596   6  [sb sound] loop                    7872   2  (autoclean) nls_iso8859-1           2272   1  (autoclean) nls_cp437               3748   1  (autoclean) vfat                    9372   1  (autoclean) fat                    30656   1  (autoclean) [vfat]

42.4 Interrupts, I/O Ports, and DMA Channels

A loaded module that drives hardware will often consume I/O ports, IRQs, and possibly a DMA channel, as explained in Chapter 3. You can get a full list of occupied resources from the /proc/ directory:

5          10          15          20          25          30          35          40          45          50

[root@cericon]# cat /proc/ioports   0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0220-022f : soundblaster 02f8-02ff : serial(auto) 0330-0333 : MPU-401 UART 0376-0376 : ide1 0378-037a : parport0 0388-038b : OPL3/OPL2 03c0-03df : vga+ 03f0-03f5 : floppy 03f6-03f6 : ide0 03f7-03f7 : floppy DIR 03f8-03ff : serial(auto) e400-e47f : DC21140 (eth0) f000-f007 : ide0 f008-f00f : ide1   [root@cericon]# cat /proc/interrupts              CPU0          0:    8409034          XT-PIC  timer   1:     157231          XT-PIC  keyboard   2:          0          XT-PIC  cascade   3:     104347          XT-PIC  serial   5:          2          XT-PIC  soundblaster   6:         82          XT-PIC  floppy   7:          2          XT-PIC  parport0   8:          1          XT-PIC  rtc  11:          8          XT-PIC  DC21140 (eth0)  13:          1          XT-PIC  fpu  14:     237337          XT-PIC  ide0  15:      16919          XT-PIC  ide1 NMI:          0   [root@cericon]# cat /proc/dma    1: SoundBlaster8  2: floppy  4: cascade  5: SoundBlaster16

The above configuration is typical. Note that the second column of the IRQ listing shows the number of interrupts signals received from the device. Moving my mouse a little and listing the IRQs again gives me

3:     104851          XT-PIC  serial

showing that several hundred interrupts were since received. Another useful entry is /proc/devices, which shows what major devices numbers were allocated and are being used. This file is extremely useful for seeing what peripherals are ``alive'' on your system.

42.5 Module Options and Device Configuration

Device modules often need information about their hardware configuration. For instance, ISA device drivers need to know the IRQ and I/O port that the ISA card is physically configured to access. This information is passed to the module as module options that the module uses to initialize itself. Note that most devices will not need options at all. PCI cards mostly autodetect; it is mostly ISA cards that require these options.

42.5.1 Five ways to pass options to a module

1.

If a module is compiled into the kernel, then the module will be initialized at boot time. lilo passes module options to the kernel from the command-line at the LILO: prompt. For instance, at the LILO: prompt, you can type [See Section 4.4]:

linux aha1542=<portbase>[,<buson>,<busoff>[,<dmaspeed>]]

to initialize the Adaptec 1542 SCSI driver. What these options are and exactly what goes in them can be learned from the file /usr/src/linux-<version>/drivers/scsi/aha1542.c. Near the top of the file are comments explaining the meaning of these options.

2.

If you are using LOADLIN.EXE or some other DOS or Windows kernel loader, then it, too, can take similar options. I will not go into these.

3.

/etc/lilo.conf can take the append = option, as discussed on page . This options passes options to the kernel as though you had typed them at the LILO: prompt. The equivalent lilo.conf line is

append = aha1542=<portbase>[,<buson>,<busoff>[,<dmaspeed>]]

This is the most common way of giving kernel boot options.

4.

The insmod and modprobe commands can take options that are passed to the module. These are vastly different from the way you pass options with append =. For instance, you can give options to a compiled-in Ethernet module with the commands

append = ether=9,0x300,0xd0000,0xd4000,eth0 append = ether=0,0,eth1

from within /etc/lilo.conf. But then, using modprobe on the same ``compiled-out'' modules, these options have to be specified like this:

modprobe wd irq=9 io=0x300 mem=0xd0000 mem_end=0xd4000 modprobe de4x5

Note that the 0xd0000,0xd4000 are only applicable to a few Ethernet modules and are usually omitted. Also, the 0's in ether=0,0,eth1 mean to try autodetect. To find out what options a module will take, you can use the modinfo command which shows that the wd driver is one of the few Ethernet drivers where you can set their RAM usage. [This has not been discussed, but cards can sometimes use areas of memory directly.]

5	[root@cericon]# modinfo -p /lib/modules/<version>/net/wd.o ( [root@cericon]# modinfo -p /lib/modules/<version>/kernel/drivers/net/wd.o ) io int array (min = 1, max = 4) irq int array (min = 1, max = 4) mem int array (min = 1, max = 4) mem_end int array (min = 1, max = 4)

5.

The file /etc/modules.conf [Also sometimes called /etc/conf.modules, but now deprecated.] contains default options for modprobe, instead of our giving them on the modprobe command-line. This is the preferred and most common way of giving module options. Our Ethernet example becomes:

alias eth0 wd alias eth1 de4x5 options wd irq=9 io=0x300 mem=0xd0000 mem_end=0xd4000

Having set up an /etc/modules.conf file allows module dynamic loading to take place. This means that the kernel automatically loads the necessary module whenever the device is required (as when ifconfig is first used for Ethernet devices). The kernel merely tries an /sbin/modprobe eth0, and the alias line hints to modprobe to actually run /sbin/modprobe wd. Further, the options line means to run /sbin/modprobe wd irq=9 io=0x300 mem=0xd0000 mem_end=0xd4000. In this way, /etc/modules.conf maps devices to drivers.

42.5.2 Module documentation sources

You might like to see a complete summary of all module options with examples of each of the five ways of passing options. No such summary exists at this point, simply because there is no overall consistency and because people are mostly interested in getting one particular device to work, which will doubtless have peculiarities best discussed in a specialized document. Further, some specialized modules are mostly used in compiled-out form, whereas others are mostly used in compiled-in form.

To get an old or esoteric device working, it is best to read the appropriate HOWTO documents: BootPrompt-HOWTO, Ethernet-HOWTO, and Sound-HOWTO. The device could also be documented in /usr/linux-<version>/Documentation/ or under one of its subdirectories like sound/ and networking/. This is documentation written by the driver authors themselves. Of particular interest is the file /usr/src/linux/Documentation/networking/net-modules.txt, which, although outdated, has a fairly comprehensive list of networking modules and the module options they take. Another source of documentation is the driver C code itself, as in the aha1542.c example above. It may explain the /etc/lilo.conf or /etc/modules.conf options to use but will often be quite cryptic. A driver is often written with only one of compiled-in or compiled-out support in mind (even though it really supports both). Choose whether to compile-in or compiled-out based on what is implied in the documentation or C source.

42.6 Configuring Various Devices

Further examples on getting common devices to work now follow but only a few devices are discussed. See the documentation sources above for more info. We concentrate here on what is normally done.

42.6.1 Sound and pnpdump

Plug-and-Play (PnP) ISA sound cards (like SoundBlaster cards) are possibly the more popular of any cards that people have gotten to work under LINUX. Here, we use the sound card example to show how to get a PnP ISA card working in a few minutes. This is, of course, applicable to cards other than sound.

A utility called isapnp takes one argument, the file /etc/isapnp.conf, and configures all ISA Plug-and-Play devices to the IRQs and I/O ports specified therein. /etc/isapnp.conf is a complicated file but can be generated with the pnpdump utility. pnpdump outputs an example isapnp.conf file to stdout, which contains IRQ and I/O port values allowed by your devices. You must edit these to unused values. Alternatively, you can use pnpdump --config to get a /etc/isapnp.conf file with the correct IRQ, I/O port, and DMA channels automatically guessed from an examination of the /proc/ entries. This comes down to

5

[root@cericon]# pnpdump --config | grep -v '^\(#.*\|\)$' > /etc/isapnp.conf [root@cericon]# isapnp /etc/isapnp.conf   Board 1 has Identity c9 00 00 ab fa 29 00 8c 0e:  CTL0029 Serial No 44026 [checksum c9] CTL0029/44026[0]{Audio       }: Ports 0x220 0x330 0x388; IRQ5 DMA1 DMA5 --- Enabled OK CTL0029/44026[1]{IDE         }: Ports 0x168 0x36E; IRQ10 --- Enabled OK CTL0029/44026[2]{Game        }: Port 0x200; --- Enabled OK

which gets any ISA PnP card configured with just two commands. Note that the /etc/isapnp.gone file can be used to make pnpdump avoid using certain IRQ and I/O ports. Mine contains

IO 0x378,2 IRQ 7

to avoid conflicting with my parallel port. isapnp /etc/isapnp.conf must be run each time at boot and is probably already in your startup scripts.

Now that your ISA card is enabled, you can install the necessary modules. You can read the /etc/isapnp.conf file and also isapnp's output above to reference the I/O ports to the correct module options:

5          10

alias sound-slot-0 sb alias sound-service-0-0 sb alias sound-service-0-1 sb alias sound-service-0-2 sb alias sound-service-0-3 sb alias sound-service-0-4 sb alias synth0 sb post-install sb /sbin/modprobe "-k" "adlib_card" options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330 options adlib_card io=0x388     # FM synthesizer

Now run tail -f /var/log/messages /var/log/syslog, and then at another terminal type:

depmod -a modprobe sb

If you get no kernel or other errors, then the devices are working.

Now we want to set up dynamic loading of the module. Remove all the sound and other modules with rmmod -a (or manually), and then try:

aumix

You should get a kernel log like this:

Sep 24 00:45:19 cericon kernel: Soundblaster audio driver  Copyright (C) by Hannu Savolainen 1993-1996 Sep 24 00:45:19 cericon kernel: SB 4.13 detected OK (240)

Then try:

playmidi <somefile>.mid

You should get a kernel log like this one:

5	Sep 24 00:51:34 cericon kernel: Soundblaster audio driver  Copyright (C) by Hannu Savolainen 1993-1996 Sep 24 00:51:34 cericon kernel: SB 4.13 detected OK (240) Sep 24 00:51:35 cericon kernel: YM3812 and OPL-3 driver  Copyright (C) by Hannu Savolainen, Rob Hooft 1993-1996

If you had to comment out the alias lines, then a kernel message like modprobe: Can't locate module sound-slot-0 would result. This indicates that the kernel is attempting a /sbin/modprobe sound-slot-0: a cue to insert an alias line. Actually, sound-service-0-0, 1, 2, 3, 4 are the /dev/mixer, sequencer, midi, dsp, audio devices, respectively. sound-slot-0 means a card that should supply all of these. The post-install option means to run an additional command after installing the sb module; this takes care of the Adlib sequencer driver. [I was tempted to try removing the post-install line and adding a alias sound-service-0-1 adlib_card. This works, but not if you run aumix before playmidi, **shrug**.]

42.6.2 Parallel port

The parallel port module is much less trouble:

alias parport_lowlevel parport_pc options parport_lowlevel io=0x378 irq=7

Merely make sure that your IRQ and I/O port match those in your CMOS (see Section 3.3), and that they do not conflict with any other devices.

42.6.3 NIC -- Ethernet, PCI, and old ISA

Here I demonstrate non-PnP ISA cards and PCI cards, using Ethernet devices as an example. (NIC stands for Network Interface Card, that is, an Ethernet 10 or 100 Mb card.)

For old ISA cards with jumpers, you will need to check your /proc/ files for unused IRQ and I/O ports and then physically set the jumpers. Now you can do a modprobe as usual, for example:

modinfo -p ne modprobe ne io=0x300 irq=9

Of course, for dynamic loading, your /etc/modules.conf file must have the lines:

alias eth0 ne options ne io=0x300 irq=9

On some occasions you will come across a card that has software configurable jumpers, like PnP, but that can only be configured with a DOS utility. In this case compiling the module into the kernel will cause it to be autoprobed on startup without needing any other configuration.

A worst case scenario is a card whose make is unknown, as well its IRQ and I/O ports. The chip number on the card can sometimes give you a hint ( grep the kernel sources for this number), but not always. To get this card working, compile in support for several modules, one of which the card is likely to be. Experience will help you make better guesses. If one of your guesses is correct, your card will almost certainly be discovered on reboot. You can find its IRQ and I/O port values in /proc/ or you can run dmesg to see the autoprobe message line; the message will begin with eth0: ...   and contain some information about the driver. This information can be used if you decide later to use modules instead of your custom kernel.

As explained, PCI devices almost never require IRQ or I/O ports to be given as options. As long as you have the correct module, a simple

modprobe <module>

will always work. Finding the correct module can still be a problem, however, because suppliers will call a card all sorts of marketable things besides the actual chipset it is compatible with. The utility scanpci (which is actually part of X) checks your PCI slots for PCI devices. Running scanpci might output something like:

5          10

.   .  . pci bus 0x0 cardnum 0x09 function 0x0000: vendor 0x1011 device 0x0009  Digital DC21140 10/100 Mb/s Ethernet   pci bus 0x0 cardnum 0x0b function 0x0000: vendor 0x8086 device 0x1229  Intel 82557/8/9 10/100MBit network controller   pci bus 0x0 cardnum 0x0c function 0x0000: vendor 0x1274 device 0x1371  Ensoniq es1371

Another utility is lspci from the pciutils package, which gives comprehensive information where scanpci sometimes gives none. Then a simple script (kernel 2.4 paths in parentheses again),

5

for i in /lib/modules/<version>/net/* ; do strings $i \                                            | grep -q -i 21140 && echo $i ; done ( for i in /lib/modules/<version>/kernel/drivers/net/* \                          ; do strings $i | grep -q -i 21140 && echo $i ; done ) for i in /lib/modules/<version>/net/* ; do strings $i \                                             | grep -q -i 8255 && echo $i ; done ( for i in /lib/modules/<version>/kernel/drivers/net/* \                           ; do strings $i | grep -q -i 8255 && echo $i ; done )

faithfully outputs three modules de4x5.o, eepro100.o, and tulip.o, of which two are correct. On another system lspci gave

5	.  .  . 00:08.0 Ethernet controller: Macronix, Inc. [MXIC] MX987x5 (rev 20) 00:0a.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10)

and the same for... grep... Accton gave rtl8139.o and tulip.o (the former of which was correct), and for... grep... Macronix (or even 987) gave tulip.o, which hung the machine. I have yet to get that card working, although Eddie across the room claims he got a similar card working fine. Cards are cheap--there are enough working brands so that you don't have to waist your time on difficult ones.

42.6.4 PCI vendor ID and device ID

PCI supports the useful concept that every vendor and device have unique hex IDs. For instance, Intel has chosen to represent themselves by the completely random number 0x8086 as their vendor ID. PCI cards will provide their IDs on request. You will see numerical values listed in the output of lspci, scanpci, and cat /proc/pci, especially if the respective utility cannot look up the vendor name from the ID number. The file /usr/share/pci.ids ( /usr/share/misc/pci.ids on Debian) from the pciutils package contains a complete table of all IDs and their corresponding names. The kudzu package also has a table /usr/share/kudzu/pcitable containing the information we are really looking for: ID to kernel module mappings. This enables you to use the intended scientific method for locating the correct PCI module from the kernel's /proc/pci data. The file format is easy to understand, and as an exercise you should try writing a shell script to do the lookup automatically.

42.6.5 PCI and sound

The scanpci output just above also shows the popular Ensoniq sound card, sometimes built into motherboards. Simply adding the line

alias sound es1371

to your modules.conf file will get this card working. It is relatively easy to find the type of card from the card itself--Ensoniq cards actually have es1371 printed on one of the chips.

42.6.6 Commercial sound drivers

If your card is not listed in /usr/src/<version>/Documentation/sound/, then you might be able to get a driver from Open Sound <http://www.opensound.com>. If you still can't find a driver, complain to the manufacturer by email.

There are a lot of sound (and other) cards whose manufacturers refuse to supply the Free software community with specs. Disclosure of programming information would enable LINUX users to buy their cards; Free software developers would produce a driver at no cost. Actually, manufacturers' reasons are often just pig-headedness.

42.6.7 The ALSA sound project

The ALSA (Advanced Linux Sound Architecture <http://www.alsa-project.org/>) project aims to provide better kernel sound support. If your card is not supported by the standard kernel or you are not getting the most out of the standard kernel drivers, then do check this web site.

42.6.8 Multiple Ethernet cards

If you have more than one Ethernet card, you can easily specify both in your modules.conf file, as shown in Section 42.5 above. Modules compiled into the kernel only probe a single card ( eth0) by default. Adding the line

append = "ether=0,0,eth1 ether=0,0,eth2 ether=0,0,eth3"

will cause eth1, eth2, and eth3 to be probed as well. Further, replacing the 0's with actual values can force certain interfaces to certain physical cards. If all your cards are PCI, however, you will have to get the order of assignment by experimentation.

If you have two of the same card, your kernel may complain when you try to load the same module twice. The -o option to insmod specifies a different internal name for the driver to trick the kernel into thinking that the driver is not really loaded:

alias eth0 3c509 alias eth1 3c509 options eth0 -o 3c509-0 io=0x280 irq=5 options eth1 -o 3c509-1 io=0x300 irq=7

However, with the following two PCI cards that deception was not necessary:

alias eth0 rtl8139 alias eth1 rtl8139

42.6.9 SCSI disks

SCSI (pronounced scuzzy) stands for Small Computer System Interface. SCSI is a ribbon, a specification, and an electronic protocol for communication between devices and computers. Like your IDE ribbons, SCSI ribbons can connect to their own SCSI hard disks. SCSI ribbons have gone through some versions to make SCSI faster, the latest ``Ultra-Wide'' SCSI ribbons are thin, with a dense array of pins. Unlike your IDE, SCSI can also connect tape drives, scanners, and many other types of peripherals. SCSI theoretically allows multiple computers to share the same device, although I have not seen this implemented in practice. Because many UNIX hardware platforms only support SCSI, it has become an integral part of UNIX operating systems.

SCSIs also introduce the concept of LUNs (which stands for Logical Unit Number), Buses, and ID. These are just numbers given to each device in order of the SCSI cards you are using (if more than one), the SCSI cables on those cards, and the SCSI devices on those cables--the SCSI standard was designed to support a great many of these. The kernel assigns each SCSI drive in sequence as it finds them: /dev/sda, /dev/sdb, and so on, so these details are usually irrelevant.

An enormous amount should be said on SCSI, but the bare bones is that for 90% of situations, insmod <pci-scsi-driver> is all you are going to need. You can then immediately begin accessing the device through /dev/sd? for disks, /dev/st? for tapes, /dev/scd? for CD-ROMs, or /dev/sg? for scanners. [Scanner user programs will have docs on what devices they access.] SCSIs often also come with their own BIOS that you can enter on startup (like your CMOS). This will enable you to set certain things. In some cases, where your distribution compiles-out certain modules, you may have to load one of sd_mod.o, st.o, sr_mod.o, or sg.o, respectively. The core scsi_mod.o module may also need loading, and /dev/ devices may need to be created. A safe bet is to run

5	cd /dev ./MAKEDEV -v sd ./MAKEDEV -v st0 st1 st2 st3 ./MAKEDEV -v scd0 scd1 scd2 scd3 ./MAKEDEV -v sg

to ensure that all necessary device files exist in the first place.

It is recommended that you compile into your kernel support for your SCSI card (also called the SCSI Host Adapter) that you have, as well as support for tapes, CD-ROMs, etc. When your system next boots, everything will just autoprobe. An example system with a SCSI disk and tape gives the following at bootup:

5          10          15          20          25          30

(scsi0) <Adaptec AIC-7895 Ultra SCSI host adapter> found at PCI 0/12/0 (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs (scsi0) Cables present (Int-50 YES, Int-68 YES, Ext-68 YES) (scsi0) Illegal cable configuration!!  Only two (scsi0) connectors on the SCSI controller may be in use at a time! (scsi0) Downloading sequencer code... 384 instructions downloaded (scsi1) <Adaptec AIC-7895 Ultra SCSI host adapter> found at PCI 0/12/1 (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs (scsi1) Downloading sequencer code... 384 instructions downloaded scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.28/3.2.4        <Adaptec AIC-7895 Ultra SCSI host adapter> scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.28/3.2.4        <Adaptec AIC-7895 Ultra SCSI host adapter> scsi : 2 hosts. (scsi0:0:0:0) Synchronous at 40.0 Mbyte/sec, offset 8.   Vendor: FUJITSU   Model: MAE3091LP         Rev: 0112   Type:   Direct-Access                      ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 (scsi0:0:3:0) Synchronous at 10.0 Mbyte/sec, offset 15.   Vendor: HP        Model: C1533A            Rev: A708   Type:   Sequential-Access                  ANSI SCSI revision: 02 Detected scsi tape st0 at scsi0, channel 0, id 3, lun 0 scsi : detected 1 SCSI tape 1 SCSI disk total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 17826240 [8704 MB] [8.7 GB]  .  .  . Partition check:  sda: sda1  hda: hda1 hda2 hda3 hda4  hdb: hdb1

You should also check Section 31.5 to find out how to boot SCSI disks when the needed module... is on a file system... inside a SCSI disk... that needs the module.

For actually using a tape drive, see page .

42.6.10 SCSI termination and cooling

This is the most important section to read regarding SCSI. You may be used to IDE ribbons that just plug in and work. SCSI ribbons are not of this variety; they need to be impedance matched and terminated. These are electrical technicians' terms. Basically, it means that you must use high-quality SCSI ribbons and terminate your SCSI device. SCSI ribbons allow many SCSI disks and tapes to be connected to one ribbon. Terminating means setting certain jumpers or switches on the last devices on the ribbon. It may also mean plugging the last cable connector into something else. Your adapter documentation and disk documentation should explain what to do. If you terminate incorrectly, everything may work fine, but you may get disk errors later in the life of the machine. Also note that some newer SCSI devices have automatic termination.

Cooling is another important consideration. When the documentation for a disk drive recommends forced air cooling for that drive, it usually means it. SCSI drives get extremely hot and can burn out in time. Forced air cooling can mean as little as buying a cheap circuit box fan and tying it in a strategic position. You should also use very large cases with several inches of space between drives. Anyone who has opened up an expensive high end server will see the attention paid to air cooling.

42.6.11 CD writers

A system with an ATAPI (IDE CD-Writer and ordinary CD-ROM will display a message at bootup like,

hda: FUJITSU MPE3084AE, ATA DISK drive hdb: CD-ROM 50X L, ATAPI CDROM drive hdd: Hewlett-Packard CD-Writer Plus 9300, ATAPI CDROM drive

Note that these devices should give BIOS messages before LILO: starts to indicate that they are correctly installed.

The /etc/modules.conf lines to get the CD-writer working are:

alias   scd0 sr_mod                  # load sr_mod upon access of /dev/scd0 alias   scsi_hostadapter ide-scsi    # SCSI hostadaptor emulation options ide-cd ignore="hda hdc hdd"  # Our normal IDE CD is on /dev/hdb

The alias scd0 line must be omitted if sr_mod is compiled into the kernel--search your /lib/modules/<version>/ directory. Note that the kernel does not support ATAPI CD-Writers directly. The ide-scsi module emulates a SCSI adapter on behalf of the ATAPI CD-ROM. CD-Writer software expects to speak to /dev/scd?, and the ide-scsi module makes this device appear like a real SCSI CD writer. [Real SCSI CD writers are much more expensive.] There is one caveat: your ordinary IDE CD-ROM driver, ide-cd, will also want to probe your CD writer as if it were a normal CD-ROM. The ignore option makes the ide-cd module overlook any drives that should not be probed--on this system, these would be the hard disk, CD writer, and non-existent secondary master. However, there is no way of giving an ignore option to a compiled-in ide-cd module (which is how many distributions ship), so read on.

An alternative is to compile in support for ide-scsi and completely leave out support for ide-cd. Your normal CD-ROM will work perfectly as a read-only CD-ROM under SCSI emulation. [Even with music CDs.]This means setting the relevant sections of your kernel configuration menu:

5	<*> Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support < >    Include IDE/ATAPI CDROM support <*>    SCSI emulation support   <*> SCSI support <*> SCSI CD-ROM support [*]   Enable vendor-specific extensions (for SCSI CDROM) <*> SCSI generic support

No further configuration is needed, and on bootup, you will find messages like:

5          10

scsi0 : SCSI host adapter emulation for IDE ATAPI devices scsi : 1 host.   Vendor: E-IDE     Model: CD-ROM 50X L      Rev: 12     Type:   CD-ROM                             ANSI SCSI revision: 02 Detected scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0   Vendor: HP        Model: CD-Writer+ 9300   Rev: 1.0b   Type:   CD-ROM                             ANSI SCSI revision: 02 Detected scsi CD-ROM sr1 at scsi0, channel 0, id 1, lun 0 scsi : detected 2 SCSI generics 2 SCSI cdroms total. sr0: scsi3-mmc drive: 4x/50x cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.10 sr1: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray

If you do have a real SCSI writer, compiling in support for your SCSI card will detect it in a similar fashion. Then, for this example, the device on which to mount your CD-ROM is /dev/scd0 and your CD-Writer, /dev/scd1.

For actually recording a CD, the cdrecord command-line program is simple and robust, although there are also many pretty graphical front ends. To locate your CD ID, run

cdrecord -scanbus

which will give a comma-separated numeric sequence. You can then use this sequence as the argument to cdrecord's dev= option. On my machine I type

mkisofs -a -A 'Paul Sheer' -J -L -r -P PaulSheer \          -p www.icon.co.za/~psheer/ -o my_iso /my/directory cdrecord dev=0,1,0 -v speed=10 -isosize -eject my_iso

to create an ISO9660 CD-ROM out of everything below a directory /my/directory. This is most useful for backups. (The -a option should be omitted in newer versions of this command.) Beware not to exceed the speed limit of your CD writer.

42.6.12 Serial devices

You don't need to load any modules to get your mouse and modem to work. Regular serial devices (COM1 through COM4 under DOS/Windows) will autoprobe on boot and are available as /dev/ttyS0 through /dev/ttyS3. A message on boot, like

Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A

will testify to their correct detection.

On the other hand, multiport serial cards can be difficult to configure. These devices are in a category all of their own. Most use a chip called the 16550A UART (Universal Asynchronous Receiver Transmitter), which is similar to that of your built-in serial port. The kernel's generic serial code supports them, and you will not need a separate driver. The UART really is the serial port and comes in the flavors 8250, 16450, 16550, 16550A, 16650, 16650V2, and 16750.

To get these cards working requires the use of the setserial command. It is used to configure the kernel's built-in serial driver. A typical example is an 8-port non-PnP ISA card with jumpers set to unused IRQ 5 and ports 0x180- 0x1BF. Note that unlike most devices, many serial devices can share the same IRQ. [The reason is that serial devices set an I/O port to tell which device is sending the interrupt. The CPU just checks every serial device whenever an interrupt comes in.] The card is configured with this script:

5          10          15

cd /dev/ ./MAKEDEV -v ttyS4 ./MAKEDEV -v ttyS5 ./MAKEDEV -v ttyS6 ./MAKEDEV -v ttyS7 ./MAKEDEV -v ttyS8 ./MAKEDEV -v ttyS9 ./MAKEDEV -v ttyS10 ./MAKEDEV -v ttyS11 /bin/setserial -v /dev/ttyS4 irq 5 port 0x180 uart 16550A skip_test /bin/setserial -v /dev/ttyS5 irq 5 port 0x188 uart 16550A skip_test /bin/setserial -v /dev/ttyS6 irq 5 port 0x190 uart 16550A skip_test /bin/setserial -v /dev/ttyS7 irq 5 port 0x198 uart 16550A skip_test /bin/setserial -v /dev/ttyS8 irq 5 port 0x1A0 uart 16550A skip_test /bin/setserial -v /dev/ttyS9 irq 5 port 0x1A8 uart 16550A skip_test /bin/setserial -v /dev/ttyS10 irq 5 port 0x1B0 uart 16550A skip_test /bin/setserial -v /dev/ttyS11 irq 5 port 0x1B8 uart 16550A skip_test

You should immediately be able to use these devices as regular ports. Note that you would expect to see the interrupt in use under /proc/interrupts. For serial devices this is only true after data actually starts to flow. However, you can check /proc/tty/driver/serial to get more status information. The setserial man page contains more about different UARTs and their compatibility problems. It also explains autoprobing of the UART, IRQ, and I/O ports (although it is better to be sure of your card and never use autoprobing).

Serial devices give innumerable problems. There is a very long Serial-HOWTO that will help you solve most of them; It goes into more technical detail. It will also explain special kernel support for many ``nonstandard'' cards.

42.7 Modem Cards

Elsewhere in this book I refer only to ordinary external modems that connect to your machine's auxiliary serial port. However, internal ISA modem cards are cheaper and include their own internal serial port. This card can be treated as above, like an ISA multiport serial card with only one port: just set the I/O port and IRQ jumpers and then run setserial /dev/ttyS3... .

Beware that a new variety of modem has been invented called the ``win-modem.'' These cards are actually just sound cards. Your operating system has to generate the signals needed to talk the same protocol as a regular modem. Because the CPU has to be very fast to do this, such modems were probably not viable before 1997 or so. http://linmodems.technion.ac.il/, http://www.idir.net/~gromitkc/winmodem.html, and http://www.linmodems.org/ are three resources that cover these modems.

42.8 More on LILO: Options

The BootPrompt-HOWTO contains an exhaustive list of things that can be typed at the boot prompt to do interesting things like NFS root mounts. This document is important to read if only to get an idea of the features that LINUX supports.

42.9 Building the Kernel

Summary:

5          10

cd /usr/src/linux/ make mrproper make menuconfig make dep make clean make bzImage make modules make modules_install cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-<version> cp /usr/src/linux/System.map /boot/System.map-<version>

Finally, edit /etc/lilo.conf and run lilo. Details on each of these steps follow.

42.9.1 Unpacking and patching

The LINUX kernel is available from various places as linux-? .? .? .tar.gz, but primarily from the LINUX kernel's home <ftp://ftp.kernel.org/pub/linux/kernel/>.

The kernel can easily be unpacked with

5	cd /usr/src mv linux linux-OLD tar -xzf linux-2.4.0-test6.tar.gz mv linux linux-2.4.0-test6 ln -s linux-2.4.0-test6 linux cd linux

and possibly patched with (see Section 20.7.3):

5	bzip2 -cd ../patch-2.4.0-test7.bz2 | patch -s -p1 cd .. mv linux-2.4.0-test6 linux-2.4.0-test7 ln -sf linux-2.4.0-test7 linux cd linux make mrproper

Your 2.4.0-test6 kernel source tree is now a 2.4.0-test7 kernel source tree. You will often want to patch the kernel with features that Linus did not include, like security patches or commercial hardware drivers.

Important is that the following include directories point to the correct directories in the kernel source tree:

[root@cericon]# ls -al /usr/include/{linux,asm} /usr/src/linux/include/asm lrwxrwxrwx  1 root  root   24 Sep  4 13:45 /usr/include/asm -> ../src/linux/include/asm lrwxrwxrwx  1 root  root   26 Sep  4 13:44 /usr/include/linux -> ../src/linux/include/linux lrwxrwxrwx  1 root  root    8 Sep  4 13:45 /usr/src/linux/include/asm -> asm-i386

Before continuing, you should read the Changes file (under /usr/src/linux/Documentation/) to find out what is required to build the kernel. If you have a kernel source tree supplied by your distribution, everything will already be up-to-date.

42.9.2 Configuring

(A kernel tree that has suffered from previous builds may need you to run

make mrproper

before anything else. This completely cleans the tree, as though you had just unpacked it.)

There are three kernel configuration interfaces. The old line-for-line y/n interface is painful to use. For a better text mode interface, you can type

make menuconfig

otherwise, under X enter

make xconfig

to get the graphical configurator. For this discussion, I assume that you are using the text-mode interface.

The configure program enables you to specify an enormous number of features. It is advisable to skim through all the sections to get a feel for the different things you can do. Most options are about specifying whether you want a feature [*] compiled into the kernel image, [M] compiled as a module, or [ ] not compiled at all. You can also turn off module support altogether from Loadable module support  -->. The kernel configuration is one LINUX program that offers lots of help--select < Help > on any feature. The raw help file is /usr/src/linux/Documentation/Configure.help (nearly 700 kilobytes) and is worth reading.

When you are satisfied with your selection of options, select < Exit > and select save your new kernel configuration.

The kernel configuration is saved in a file /usr/src/linux/.config. Next time you run make menuconfig, your configuration will default to these settings. The file /usr/src/linux/arch/i386/defconfig contains defaults to use in the absence of a .config file. Note that the command make mrproper removes the .config file.

42.10 Using Packaged Kernel Source

Your distribution will probably have a kernel source package ready to build. This package is better to use than downloading the source yourself because all the default build options will be present; for instance, RedHat 7.0 comes with the file /usr/src/linux-2.2.16/configs/kernel-2.2.16-i586-smp.config, which can be copied over the /usr/src/linux-2.2.16/.config to build a kernel optimized for SMP (Symmetric Multiprocessor Support) with all of RedHat's defaults enabled. It also comes with a custom defconfig file to build kernels identical to those of RedHat. Finally, RedHat would have applied many patches to add features that may be time consuming to do yourself. The same goes for Debian.

You should try to enable or ``compile-in'' features rather than disable anything, since the default RedHat kernel supports almost every kernel feature, and later it may be more convenient to have left it that way. On the other hand, a minimal kernel will compile much faster.

42.11 Building, Installing

Run the following commands to build the kernel; this process may take anything from a few minutes to several hours, depending on what you have enabled. After each command completes, check the last few messages for errors (or check the return code, $?), rather than blindly typing the next commands.

5	make dep && \ make clean && \ make bzImage && \ make modules && \ make modules_install

The command make modules_install would have installed all modules into /lib/modules/<version>. [You may like to clear out this directory at some point and rerun make modules_install, since stale modules cause problems with depmod -a.]

The kernel image itself, /usr/src/linux/arch/i386/boot/bzImage, and /usr/src/linux/System.map are two other files produced by the build. These must be copied to /boot/, possibly creating neat symlinks:

cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-<version> cp /usr/src/linux/System.map /boot/System.map-<version> ln -sf System.map-<version> /boot/System.map ln -sf /boot/vmlinuz-<version> vmlinuz

Finally, your lilo.conf may be edited as described in Chapter 31. Most people now forget to run lilo and find their system unbootable. Do run lilo, making sure that you have left your old kernel in as an option, in case you need to return to it. Also make a boot floppy from your kernel, as shown in Section 31.4.

• Новости
• Библиотека
• Е-книги
• Авторское
• Форум
• Каталог ссылок
• Каталог ПО
• О сайте
• Карта сайта

(C) В.А.Костромин, 1999 - 2024 г.