Release Notes: SST Driver for Linux
Supported Linux Releases
This release provides the SST driver and associated software for the following types of Linux systems:
- X86 systems based on Linux 2.2 kernels.
- X86 systems based on Linux 2.4 kernels.
- X86 systems based on Linux 2.6 kernels.
- Itanium (IA64) systems running Linux 2.4 kernels.
- Itanium (IA64) systems running Linux 2.6 kernels.
- X86_64 systems (Intel Xeon, AMD Athelon, etc.) running Linux 2.4 kernels.
- X86_64 systems (Intel Xeon, AMD Athelon, etc.) running Linux 2.6 kernels.
Supported Products
The linux SST driver supports ISA, EISA and PCI versions of the two, four, eight and 16 port boards as well as the expandable 64 and 128 port boards. ISA and EISA are not available on Itanium and x86_64 systems.
Prerequisites
This product is shipped as source and is built on a target system. In order to do the driver build, certain packages must be installed on the target system before installing the driver:
- Linux kernel source (2.2, 2.4, or 2.6). The kernel source must be configured the same as the running kernel. (note: some versions of 2.6 kernels support the kernel build target cloneconfig which can be used to configure the kernel source.
- Curses and the curses libraries. Typically provided by the packages ncurses and ncurses-devel.
- The GNU make utility. Typically provided by the make package.
- The GNU C compiler. Typically provided by the gcc package.
- Perl processor. Typically provided by the perl package.
- RPM utility. Typically provided by the rpm package, but may also require rpm-devel and rpm-build.
Installation
The product is shipped as a source RPM and a set of utilities to assist in the installation.
Installation can be done automatically using the script eqnx-cfg or can be done manually.
Generally, it is recommended that the installation be done automatically using eqnx-cfg. For more information, refer to provided installation notes.
To install with eqnx-cfg:
- Remove existing eqnx product, if one is installed:
(Alternatively, an update of an existing product can be done by using the –U option to eqnx-cfg as mentioned in step #4).
rpm –ev eqnx –or- eqnx-cfg -vr
- Obtain and locate the source RPM product and eqnx-cfg. This may be obtained via ftp, cd-rom or floppy.
- cd to the directory that contains the eqnx source RPM and eqnx-cfg.
- ./eqnx-cfg [-U] [-v] [-o RPM options] [-d directory] [source RPM name]
The options and parameters are all optional.
-U : upgrade option, used to upgrade from a previous eqnx release.
-v : verbose option, provides additional installation information.
-o : other RPM options to be specified to the rpm utility (such as –nodeps for Debian and Slackware installation).
-d : specifies RPM topdir directory.
Source RPM : name of source RPM (otherwise, found in current directory).
Typically, installation can be done by:
./eqnx-cfg -v
- The utility creates a logfile - /var/tmp/eqnx-log. If the installation fails, please read this logfile.
To install manually:
rpm –ivh eqnx-4.12-1.src.rpm
cd to RPM directory (/usr/src/redhat, /usr/src/packages, etc.)
rpm –bb SPECS/eqnx.spec
rpm –ivh RPMS/{arch}/eqnx-4.12-1.{arch}.rpm
(note 1: the archvalue will vary between distributions).
(note 2: an upgrade from an existing eqnx RPM may be done by using the –U option to the rpm utility instead of the -i option. See note 3 below).
- Load the driver and create device files:
/etc/rc.d/init.d/eqnx start
(note 3: if an upgrade was done and the version of the previous product was less than 4.03, then the “restart” command should be used instead of “start”).
- Modify the start-up scripts so that driver is loaded at boot time. This step varies between Linux distribution:
- Redhat, Mandrake, TurboLinux, etc:
chkconfig –add eqnx
/sbin/insserv /etc/rc.d/eqnx
- Suse without insserv, Caldera, etc:
ln –s /etc/rc.d/init.d/eqnx /etc/rc.d/rc{N}.d/S90eqnx (where N=2,3,4,5)
ln –s /etc/rc.d/init.d/eqnx /etc/rc{N}.d/S90eqnx (where N=2,3,4,5)
invoke /etc/rc.d/init.d/eqnx from /etc/rc.d/rc.local
Manual set-up required to invoke /usr/sbin/rc.eqnx at system startup time.
(note: the script /usr/sbin/eqnx-installrc attempts to do this step correctly).
Installation Problems
- The SST software is only distributed as a RPM. On some systems, it may be required to bypass the RPM dependency checks by adding the “—nodeps” option. This is generally required on systems that do not distribute packages using RPM (such as Debian and Slackware). When using, eqnx-cfg, this is specified as follows:
./eqnx-cfg –o –-nodeps …..
- Kernel source must be installed (typically this would be in the kernel-source RPM package). Curses and perhaps curses-development must be installed (typically these would be the ncurses and ncurses-devel RPM packages). The RPM utility must be installed and on some systems, RPM development also.
- The version of the running kernel must match the version of the installed kernel source. For the running kernel, the version can be found by doing ‘uname –a’. The version of the kernel source can be found by looking in the file /usr/src/linux-$VERSION/include/linux/version.h.
Note that right after system installation, the version.h file may not be properly installed and may need to be initialized from the file /usr/include/linux/version.h
- The kernel configuration files must match the configuration of the currently running kernel. Otherwise, there may be build or install problems with the driver. The most critical kernel configuration items are:
CONFIG_SMP (Symmetric multi-processing)
CONFIG_MODVERSIONS (Version information for modules)
- An upgrade operation will fail if the existing driver is in use during the install-upgrade. After freeing the ports, issuing the following command:
/etc/rc.d/init.d/eqnx restart
will unload the old driver and load the new device driver.
- The installation scripts will attempt to locate the appropriate kernel source. This can be bypassed by setting the environment variable KERNELSRC. In addition, 2.6 kernels allow kernel object to be located in a different place from kernel source. This can be specified as KERNELOBJ.
Kernel Rebuild
The driver will be built using the include files for the current kernel. As a result, the correct source must be installed on the system or the build will fail. In addition, the kernel source must be configured to match the current kernel (particularly, CONFIG_SMP and CONFIG_MODVERSIONS).
NOTE: In order to reduce the possibility of installation or operational problems, it is highly recommended that the following procedure be followed:
- Install appropriate kernel source.
- Configure the kernel as required.
- Re-build the entire kernel (and modules).
- Install and re-boot using the new kernel.
- If there are no problems, install the Equinox SST driver.
The actual steps for configuring, building and installing a kernel will vary based on distribution.
Linux 2.6 Kernels
Installing external modules is substantially different when running the linux 2.6 kernel. It is absolutely essential to have a fully configured and built kernel from the kernel source prior to installing the driver. Generally, this kernel must also be running at the point of installation or the driver load will fail.
This driver does not work correctly with the kernel provided with Fedora 2. However, there have been no problems running with the stock 2.6.5 and 2.6.6 kernels (with the Preemptible Kernel feature disabled) on Fedora 2 systems.
In addition, installing the driver may take longer as it may be necessary to build additional modules from the kernel source.
Removal
Product removal can be done in two ways:
this uninstalls the eqnx RPM and also (optionally) removes temporary files from the rpm and build directories (recommended).
this uninstalls the eqnx RPM only.
Validated Distributions Testing was done on linux 2.4 and 2.6 kernels (up to 2.6.11).
Differences between release 4.11 and 4.12:
- Comply with kernel changes in 2.6.18: UTS_RELEASE string moved version.h to utsrelease.h.
- Comply with kernel changes in 2.6.18: tty flag TTY_DRIVER_NO_DEVFS replaced with TTY_DRIVER_DYNAMIC_DEV.
- Comply with kernel changes in 2.6.18: linux/config.h no no longer present.
- Comply with kernel changes in 2.6.20: termios structure has been replaced with ktermios.
- Comply with kernel serial sub-system changes in 2.6.20.
Differences between release 4.11 and 4.11b:
- Changes to comply with 2.6.18 kernel modifications.
Differences between release 4.10 and 4.11:
- Fix kernel panic that would occur while unloading the driver on a multiprocessor system. Problems occur with linux kernel 2.6.9 and later.
- Fix kernel panic that would occur as a result of the driver being unloaded while ports were in use. This would occur when unloading the driver or doing a system shutdown. Problems occur on linux 2.6 systems.
- Changes to comply with tty interface changes with linux kernel 2.6.16.
- Fixed problem with SST device files not being created after a reboot without a clean shutdown.
- Fixed problem with ssmkn being altered by prelink so that it no longer properly creates device files. The result would be no device files created after a reboot.
- Fixed install script on Suse to reload driver on reboot. Now uses isserv.
Differences between release 4.09 and 4.10:
- Added alternative kernel source path - /lib/modules/<kernel version>/build.
- Remove extraneous "lvalue casting" in the driver which is prohibited by later versions of gnu gcc compiler.
- Fix to driver "megamint" routine, which was not correctly doing hangup on DCD drop in 2.6 kernels.
- Fix copyright in eqnx.spec file.
- Changed the package install/build process to:
Determine kernel source and kernel object location if built in seperate locations (2.6 kernels). Otherwise, assumed that kernel object is in the same location as kernel source.
- accept the environment variables KERNELSRC and KERNELOBJ. If KERNELSRC is set, it specifies the location of kernel source, which bypasses the tests done in the scripts and makefiles. If KERNELOBJ is set, it specifies the location of kernel object. If not set, assumed same as kernel source.
- Change so that the RTS signal cannot be explicitly turned off when hardware flow control is enabled.
|