Next Previous Contents

3. General Setup and Kernel Module Issues

3.1 Kernel Module Support

All of the drivers listed here are released as kernel modules; therefore, you must be sure to have a kernel which supports modules. In addition, "module version" support should be enabled to aid the use of kernels and modules which are not version matched, as described further below.

If you use a kernel from a reasonably recent Linux distribution, module support is most likely already enabled. If you're compiling the kernel yourself, then you should already be aware of how to enable modules, via the Kernel HOWTO . In any case, you can check to make sure that the following settings exist in your kernel configuration file (which is usually found under /usr/src/linux):

CONFIG_MODULES=y
CONFIG_MODVERSIONS=y

3.2 ISA Plug-n-Play

If you have an ISA Plug-n-Play modem (such as I do on my Thinkpad i1411), you will most likely need to use isapnptools to allocate resources to the modem card. For this, you need to have isapnptools installed and have an entry in the /etc/isapnp.conf file for the modem. You should read the Plug-and-Play-HOWTO , but if you have no other ISA devices you're concerned about, basically all you need to do is:

  1. As root, run pnpdump to generate a prototype isapnp.conf file based on your system's current resource usage.
  2. Look for your modem in this output, and uncomment the lines corresponding to the (otherwise unused) IRQ you wish to use for the modem. For example, my isapnp.conf includes:

    (CONFIGURE ACRd119/1 (LD 0                   
      (INT 0 (IRQ 11 (MODE +E)))                   
      (IO 1 (SIZE 8) (BASE 0x0100) (CHECK))       
      (NAME "ACRd119/1[0]{LT Win Modem        }") 
    # (ACT Y)                                    
    ))                                           
    
    Strangely, for me at least, it is necessary to leave the #(ACT Y) commented out. If it doesn't work for you one way, try it the other.

  3. Copy the file to /etc/isapnp.conf
  4. Reboot. You should see a message along the lines of 'Initializing ISA PNP devices...OK' on booting. If it fails, you have probably selected an IRQ/DMA setting which is already in use; try another of the options given in the pnpdump output.

    (Note that it is probably not necessary to reboot, if you run isapnp with the right flags. However, it's easiest for the beginner to simply reboot at this point.)

3.3 PCI Modems

To access more information on cards with a PCI interface, utilities within the software package pciutils are useful, such as scanpci and lspci.

3.4 Precompiled Modules and Kernel Versions: insmod -f, Fixscripting, and ppp.o

As of the writing of this document, source code is only available for the Ambient Technology driver and the Lucent LT user-space tools listed above; the remainder have been released only as precompiled binary drivers. These modules/binaries transparently function only with the kernel against which they were co-compiled. Since the Linux kernel is a dynamically changing beast, it is very unfortunate that the modem vendors have not yet chosen to release source-code versions of their drivers, which would ensure the ability to modify and recompile these drivers for use with improved Linux kernels. In the meantime, however, some luck has been had in coaxing the binary modules to function under some later kernel versions, as described below.

insmod -f

A kernel module generally may be loaded using the command insmod module_name. If the module was compiled under a different kernel than the current one, insmod will report the version mismatch and fail to load the module. One can pass a flag to force the module to load despite the mismatch as insmod -f module_name. If the kernel interface the module uses did not actually change with the kernel version, forcing the module to load in this way can give you a functioning module. This is the case with, for example, the Lucent LT modem module ltmodem.o which, while compiled under 2.2.12, can be forcibly inserted and run without problems under kernel 2.2.14; however, running it with kernel version > 2.2.15-x requires the replacement of the module ppp.o with one from kernel 2.2.14, as described below.

Fixscripting

Mark Spieth (mark(at)digivation.com.au) has contributed a script (see appendix) which edits a binary module so that the version mismatch warning is eliminated, allowing module insertion to proceed without the forcing flag, i.e. simply insmod module_name. Continuing with the particular example of ltmodem.o, generating an edited module with

    ./fixscript ltmodem.o ltmodem14.o
allows insertion under 2.2.14 without mismatch complaint by
    insmod ltmodem14

Note, however, that this script does not update the module code to fix any actual kernel API discrepancies, but simply masquerades the module as having been compiled under a different version; i.e., this supresses the symptoms of kernel version mismatch, but does not cure any actual diseases which may exist. The "source code" supplied with some PCTel modules (a small C file) performs similar masquerading when compiled and linked with the binary libraries in those packages, but again does not allow for a changed kernel interface.

ppp.o and Later Kernels

Initial attempts to use the Lucent LT modem driver ltmodem.o under kernels later than 2.2.15-x failed. However, Christoph Hebeisen (cth(at)sfu.ca) reported success by using the modem module compiled under 2.2.12 with a PPP module (ppp.o) compiled under 2.2.14 with a kernel version 2.2.16. Willie Green (willjr(at)lcc.net) confirms that this works also with the ESS module. Marvin Stodolsky (stodolsk(at)erols.com) points out that the same fixscript described above can be used to version-masquerade the ppp.o module from 2.2.14 to 2.2.16 as

    ./fixscript ppp.o ppp14to16.o
, thus allowing "soft insertion" of both the ltmodem and ppp modules to obtain a functioning Linmodem under kernel version 2.2.16.

At some point, this chained use of outdated modules will probably reach a breaking point; it would be very surprising, for example, if some complex combination of older modules would allow these binary drivers to work under kernel 2.4 when it is released. The best solution would be, of course, having an open source driver; at the very least, vendor support with binary modules for more recent kernel versions would be useful. The reader is encouraged to do his/her best to support and encourage such developments.


Next Previous Contents