472 lines
26 KiB
HTML
472 lines
26 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
|
|
<TITLE> Modem-HOWTO: Interesting Programs You Should Know About</TITLE>
|
|
<LINK HREF="Modem-HOWTO-11.html" REL=next>
|
|
<LINK HREF="Modem-HOWTO-9.html" REL=previous>
|
|
<LINK HREF="Modem-HOWTO.html#toc10" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="Modem-HOWTO-11.html">Next</A>
|
|
<A HREF="Modem-HOWTO-9.html">Previous</A>
|
|
<A HREF="Modem-HOWTO.html#toc10">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s10">10.</A> <A HREF="Modem-HOWTO.html#toc10">Interesting Programs You Should Know About</A></H2>
|
|
|
|
<H2><A NAME="set_serial"></A> <A NAME="ss10.1">10.1</A> <A HREF="Modem-HOWTO.html#toc10.1">What is setserial ? </A>
|
|
</H2>
|
|
|
|
<P> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There
|
|
are some minor differences, depending on which HOWTO it appears in.</P>
|
|
|
|
<H3>Setserial problems with linmodems, laptops</H3>
|
|
|
|
<P> The setserial program doesn't seem to work if the serial port is for
|
|
a linmodem such as ttySHCF0.
|
|
If you have a Laptop (PCMCIA) don't use <CODE>setserial</CODE> until you
|
|
read
|
|
<A HREF="#laptops_">Laptops: PCMCIA</A>.</P>
|
|
|
|
<H3>Introduction</H3>
|
|
|
|
<P><CODE>setserial</CODE> is a program used for the user to communicate with
|
|
the serial device driver. You normally never need to use it, provided
|
|
that you only use the one or two serial ports that come as standard
|
|
equipment with a PC. Even in other cases, most extra serial ports
|
|
should be auto-detected by modern kernels. Except you'll need to use
|
|
setserial if you have an old ISA serial port set by jumpers on the
|
|
physical hardware or if your kernel (such as 2.2 or older) doesn't
|
|
both detect and set your add-on PCI serial ports.</P>
|
|
<P><CODE>setserial</CODE> allows you (or a shell script) to talk to the serial
|
|
software. But there's also another program, tt/stty/, that also deals
|
|
with the serial port and is used for setting the port speed, etc.</P>
|
|
<P><CODE>setserial</CODE> deals with the lower-level configuring of the serial
|
|
port, such as dealing with IRQs (such as 5), port addresses (such as
|
|
3f8), and the like. A major problem with it is that it can't
|
|
set or configure the serial port hardware: It can't set the IRQ or
|
|
port addresses into the hardware. Furthermore, when it seemingly
|
|
reports the configuration of the hardware, it's sometimes wrong since
|
|
it doesn't actually probe the hardware unless you specifically tell it
|
|
to. Even then, it doesn't do the modern type of bus probing and some
|
|
hardware may never be found by it. Still, what it shows is right most
|
|
all the time but if you're having trouble getting a serial port to
|
|
work, then there's a fair chance it's wrong.</P>
|
|
<P>In olden days, when the IRQ and port address was set by jumpers on the
|
|
serial card, one would use <CODE>setserial</CODE> to tell the driver how these
|
|
jumpers were set. Today, when plug-and-play methods detect how the
|
|
jumperless serial port is set, <CODE>setserial</CODE> is not really needed
|
|
anymore unless you're having problems or using old hardware.
|
|
Furthermore, if the configuration file used by <CODE>setserial</CODE> is
|
|
wrong, then there's trouble. In this case, if you use <CODE>setserial</CODE>
|
|
to try to find out how the port is configured, it may just repeat the
|
|
incorrect information in the configuration file.</P>
|
|
<P><CODE>setserial</CODE> can sometimes be of help to find a serial port. But
|
|
it's only of use if you know the port address and use the right
|
|
options. For modern ports, there's usually better ways to look for
|
|
them by plug-and-play methods.</P>
|
|
<P>Thus the name <CODE>setserial</CODE> is somewhat of a misnomer since it
|
|
doesn't set the I/O address nor IRQ in the hardware, it just "sets"
|
|
them in the driver software. And the driver naively believes that
|
|
what <CODE>setserial</CODE> tells it, even if it conflicts with what the driver
|
|
has found by using plug-and-play methods. Too bad that it fails to
|
|
at least issue a warning message for such a conflict. Since the
|
|
device driver is considered to be part of the kernel, the word
|
|
"kernel" is often used in other documentation with no mention made of
|
|
any "serial driver". </P>
|
|
<P>Some distributions (and versions) set things up so that <CODE>setserial</CODE>
|
|
is run at boot-time by an initialization shell script (in the
|
|
/etc directory tree). But the configuration file which this script
|
|
uses may be either in the /etc tree or the /var tree. In some cases,
|
|
if you want <CODE>setserial</CODE> to run at boot-time, you may have to take
|
|
some action. <CODE>setserial</CODE>will not work without either serial
|
|
support built into the kernel or loaded as a module. The module may
|
|
get loaded automatically if you (or a script) attempt to use
|
|
<CODE>setserial</CODE>.</P>
|
|
<P>While <CODE>setserial</CODE> can be made to probe the hardware I0 port
|
|
addresses to try to determine the UART type and IRQ, this has
|
|
severe limitations. See
|
|
<A HREF="#probing_ss">Probing</A>. It
|
|
can't set the IRQ or the port address in the hardware of PnP or PCI
|
|
serial ports (but the plug-and-play features of the serial driver may
|
|
do this). It also can't directly read the PnP data stored in
|
|
configuration registers in the hardware. But since the device driver
|
|
can read these registers and setserial tells you what the device
|
|
driver thinks, it might be correct. Or it could be telling you what
|
|
<CODE>setserial</CODE> had previously (and perhaps erroneously) told the
|
|
driver. There's no way to know for sure without doing some other
|
|
checks.</P>
|
|
<P>The serial driver (for Linux Kernel 2.4+) looks for a few "standard"
|
|
legacy serial ports, for PnP ports on the ISA bus, and for all
|
|
supported port hardware on the PCI bus. If it finds your ports
|
|
correctly, then there's no need to use <CODE>setserial</CODE>. The driver
|
|
doesn't probe for legacy IRQs and may get these wrong and it may miss
|
|
old ISA serial ports set with jumpers on the card.</P>
|
|
<P>Besides the man page for <CODE>setserial</CODE>, check out info in
|
|
<CODE>/usr/doc/setserial.../</CODE> or <CODE>/usr/share/doc/setserial</CODE>.
|
|
This should tell you how setserial is handled for your distribution of
|
|
Linux. While <CODE>setserial</CODE> behaves the same in all distributions,
|
|
the scripts for running it, how to configure such scripts (including
|
|
automatic configuration), and the names and locations of the script
|
|
files, etc., are all distribution-dependent. </P>
|
|
|
|
<H3>Serial module unload</H3>
|
|
|
|
<P>If a serial module gets unloaded, the changes previously made by
|
|
<CODE>setserial</CODE> will be forgotten by the driver. But while the driver
|
|
forgets it, a script provided by the distribution may save it in a
|
|
file somewhere so that it can the restored if the module is reloaded.</P>
|
|
|
|
|
|
|
|
<H3>Giving the <CODE>setserial</CODE> command</H3>
|
|
|
|
<P>Remember, that <CODE>setserial</CODE> can't set any I/O addresses or IRQs
|
|
in the hardware. That's done either by plug-and-play software (run by
|
|
the driver) or by jumpers for legacy serial ports. Even if you give
|
|
an I/O address or IRQ to the driver via <CODE>setserial</CODE> it will not set
|
|
such values and assumes that they have already been set. If you give
|
|
it wrong values, the serial port will not work right (if at all).</P>
|
|
<P>For legacy ports, if you know the I/O address but don't know the IRQ
|
|
you may command setserial to attempt to determine the IRQ.</P>
|
|
<P>You can see a list of possible commands by just typing <CODE>setserial</CODE>
|
|
with no arguments. This fails to show you the one-letter options such
|
|
as -v for verbose which you should normally use when troubleshooting.
|
|
Note that setserial calls an IO address a "port". If you type:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
setserial -g /dev/ttyS*
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
You'll see some info about how the device driver is configured for
|
|
your ports. In many cases you'll see some ports displayed with what
|
|
appears at first glance to be erroneous IRQs and addresses. But if
|
|
you also see: <CODE>"UART: unknown"</CODE> just ignore the entire line
|
|
since no serial port exists at that address. </P>
|
|
<P>If you add -a to the option -g you will see more info although few
|
|
people need to deal with (or understand) this additional info since
|
|
the default settings you see usually work fine. In normal cases the
|
|
hardware is set up the same way as "setserial" reports. But if you are
|
|
having problems there is a good chance that <CODE>setserial</CODE> has it wrong.
|
|
In fact, you can run "setserial" and assign a purely fictitious I/O
|
|
port address, any IRQ, and whatever uart type you would like to have.
|
|
Then the next time you type "setserial ..." it will display these
|
|
bogus values you've supplied to the driver. They will also be officially
|
|
registered with the kernel as displayed (at the top of the screen) by
|
|
the "scanport" command (Debian). Of course the serial
|
|
port driver will not work correctly (if at all) if you attempt to use
|
|
such a port. Thus, when giving parameters to <CODE>setserial</CODE>, "anything
|
|
goes". Well almost. If you assign one port a base address that is
|
|
already assigned (such as 3e8) it may not accept it. But if you use
|
|
3e9 it will accept it. Unfortunately 3e9 is actually assigned since it
|
|
is within the range starting at base address 3e8. Thus the moral of
|
|
the story is to make sure your data is correct before assigning
|
|
resources with setserial.</P>
|
|
|
|
<H3>Configuration file</H3>
|
|
|
|
<P>While assignments made by setserial are lost when the PC is powered
|
|
off, a configuration file may restore them when the PC is started
|
|
up again. In newer versions, what you change by setserial might get
|
|
automatically saved to a configuration file. When <CODE>setserial</CODE> runs
|
|
it uses the info from the configuration file.</P>
|
|
<P>Where this configuration file resides depends on your distribution.
|
|
Look at the start-up scripts somewhere in the /etc/ tree (such as
|
|
/etc/init.d/ or /etc/rc.d/) and read the startup script for "serial"
|
|
or "setserial" or the like. It should show where the configuration
|
|
file(s) reside. In Debian there are 4 options for use of this
|
|
configuration file:</P>
|
|
<P>
|
|
<OL>
|
|
<LI>Don't use this file at all. At each boot, the serial driver
|
|
alone detects the ports and setserial doesn't ever run. ("kernel" option)</LI>
|
|
<LI>Save what <CODE>setserial</CODE> reports when the system is first
|
|
shutdown and put it in the configuration file. After that, don't ever
|
|
make any changes to the configuration file, even if someone has made
|
|
changes by running the <CODE>setserial</CODE> command on the command line and
|
|
then shuts down the system. ("autosave-once" option)</LI>
|
|
<LI>At every shutdown, save whatever <CODE>setserial</CODE> detects to the
|
|
configuration file. ("autosave" option)</LI>
|
|
<LI>Manually edit the configuration file to set the configuration.
|
|
Don't ever do any automatic saves to it. ("manual" option)</LI>
|
|
</OL>
|
|
</P>
|
|
<P>In olden days (perhaps before 2000), there wasn't any configuration
|
|
file and the configuration was manually set (hard coded) inside the
|
|
shell script that ran <CODE>setserial</CODE>. See
|
|
<A HREF="#old_sets_script">Edit a script (prior to version 2.15)</A>.</P>
|
|
|
|
<H3><A NAME="probing_ss"></A> Probing </H3>
|
|
|
|
<P>You probe for a port with <CODE>setserial</CODE> only when you suspect that
|
|
it has been enabled (by PnP methods, the BIOS, jumpers, etc.).
|
|
Otherwise <CODE>setserial</CODE> probing will never find it since its address
|
|
doesn't exist. A problem is where the software looks for a port at
|
|
specified I/O addresses. Prior to probing with "setserial", one may
|
|
run the "scanport" (Debian) command to check all possible ports in one
|
|
scan. It makes crude guesses as to what is on some ports but doesn't
|
|
determine the IRQ. It's a fast first start. It may hang your PC but
|
|
so far it's worked fine for me. Note that non-Debian distributions
|
|
don't seem to supply "scanport". Is there another scan program?</P>
|
|
<P>With appropriate options, <CODE>setserial</CODE> can probe (at a given I/O
|
|
address) for a serial port but you must guess the I/O address. If you
|
|
ask it to probe for /dev/ttyS2 for example, it will only probe at the
|
|
address it thinks ttyS2 is at (2F8). If you tell setserial that ttyS2
|
|
is at a different address, then it will probe at that address, etc.
|
|
See
|
|
<A HREF="#probing_ss">Probing</A></P>
|
|
<P>The purpose of such probing is to see if there is a uart there, and if
|
|
so, what its IRQ is. Use <CODE>setserial</CODE> mainly as a last resort as
|
|
there are faster ways to attempt it such as wvdialconf to detect
|
|
modems, looking at very early boot-time messages, or using <CODE>pnpdump
|
|
--dumpregs</CODE>, or lspci -vv. But if you want to detect hardware
|
|
with <CODE>setserial</CODE> use for example :<BR> <CODE>setserial
|
|
/dev/ttyS2 -v autoconfig</CODE><BR>
|
|
If the resulting message shows a uart type such as 16550A, then you're
|
|
OK. If instead it shows "<CODE>unknown</CODE>" for the uart type, then there
|
|
is supposedly no serial port at all at that I/O address. Some cheap
|
|
serial ports don't identify themselves correctly so if you see
|
|
"<CODE>unknown</CODE>" you still might have a serial port there.</P>
|
|
<P>Besides auto-probing for a uart type, setserial can auto-probe for
|
|
IRQ's but this doesn't always work right either. In one case it first
|
|
gave the wrong irq but when the command was repeated it found the
|
|
correct irq. In versions of setserial >= 2.15, the results of your
|
|
last probe test could be automatically saved and put into a
|
|
distribution-specific configuration file such as
|
|
<CODE>/etc/serial.conf</CODE> or <CODE>/etc/sysconfig/serial</CODE> or
|
|
<CODE>/var/lib/setserial/autoserial.conf</CODE> for Debian. This will be
|
|
used next time you start Linux. </P>
|
|
<P>It may be that two serial ports both have the same IO address set in
|
|
the hardware. Of course this is not normally permitted for the ISA
|
|
bus but it sometimes happens anyway. Probing detects one serial port
|
|
when actually there are two. However if they have different IRQs,
|
|
then the probe for IRQs may show IRQ = 0. For me, it only did this if
|
|
I first used <CODE>setserial</CODE> to give the IRQ a fictitious value.</P>
|
|
|
|
<H3><A NAME="sets_boot_time"></A> Boot-time Configuration </H3>
|
|
|
|
<P>While <CODE>setserial</CODE> may run via an initialization script,
|
|
something akin to <CODE>setserial</CODE> also runs earlier when the serial
|
|
module is loaded (or when the kernel starts the built-in serial driver
|
|
if it was compiled into the kernel). Thus when you watch the start-up
|
|
messages on the screen it may look like it ran twice, and in fact it
|
|
has. </P>
|
|
<P>If the first message is for a legacy port, the IRQs shown may be wrong
|
|
since it didn't probe for IRQs. If there is a second report of serial
|
|
ports, it may the result of a script such as /etc/init.d/setserial.
|
|
It usually does no probing and thus could be wrong about how the
|
|
hardware is actually set. It only shows configuration data that got
|
|
saved in a configuration files. The old method, prior to setserial
|
|
2.15, was to manually write such data directly into the script.</P>
|
|
<P>When the kernel loads the serial module (or if the "module equivalent"
|
|
is built into the kernel) then all supported PnP ports are detected.
|
|
For legacy (non-PnP) ports, only <CODE>ttyS{0-3}</CODE> are auto-detected
|
|
and the driver is set to use only IRQs 4 and 3 (regardless of what
|
|
IRQs are actually set in the hardware). No probing is done for IRQs
|
|
but it's possible to do this manually. You see this as a boot-time
|
|
message just as if <CODE>setserial</CODE> had been run.</P>
|
|
<P>To correct possible errors in IRQs (or for other
|
|
reasons) there may be a script file somewhere that runs
|
|
<CODE>setserial</CODE>. Unfortunately, if this file has some IRQs wrong, the
|
|
kernel will still have incorrect info about the IRQs. This file is
|
|
usually part of the initialization done at boot-time. Whether it
|
|
runs or not depends on how you (and/or your distribution) have set
|
|
things up. It may also depends on the runlevel. </P>
|
|
<P>Before modifying a configuration file, you can test out a "proposed"
|
|
<CODE>setserial</CODE> command by just typing it on the command line. In some
|
|
cases the results of this use of <CODE>setserial</CODE> will automatically get
|
|
saved somewhere such as /etc/serial.conf (or autoserial.conf or
|
|
serial) when you shutdown. So if it worked OK (and solved your
|
|
problem) then there's no need to modify any configuration file. See
|
|
<A HREF="#config_file">Configuration method using /etc/serial.conf, etc.</A>.</P>
|
|
|
|
<H3><A NAME="old_sets_script"></A> Edit a script (required prior to version 2.15) </H3>
|
|
|
|
<P> This is how it was done prior to <CODE>setserial</CODE> 2.15 (1999)
|
|
The objective was to modify (or create) a script file in the /etc
|
|
tree that runs setserial at boot-time. Most distributions provided
|
|
such a file (but it may not have initially resided in the /etc tree).</P>
|
|
<P>So prior to version 2.15 (1999) it was simpler. All you did was edit
|
|
a script. There was no /etc/serial.conf file (or the like) to
|
|
configure setserial. Thus you needed to find the file that runs
|
|
"setserial" at boot time and edit it. If it didn't exist, you needed
|
|
to create one (or place the commands in a file that ran early at
|
|
boot-time). If such a file was currently being used it's likely
|
|
was somewhere in the /etc directory-tree. But Redhat <6.0 has supplied it
|
|
in /usr/doc/setserial/ but you need to move it to the /etc tree before
|
|
using it.</P>
|
|
<P>The script <CODE>/etc/rc.d/rc.serial</CODE> was commonly used in the past.
|
|
The Debian distribution used <CODE>/etc/rc.boot/0setserial</CODE>.
|
|
Another file once used was <CODE>/etc/rc.d/rc.local</CODE> but it's may
|
|
not have run early enough. It was reported that other processes may
|
|
try to open the serial port before rc.local ran resulting in serial
|
|
communication failure. Later on it most likely was found in
|
|
/etc/init.d/ but wasn't normally intended to be edited.</P>
|
|
<P>If such a file was supplied, it likely contained a number of
|
|
commented-out examples. By uncommenting some of these and/or
|
|
modifying them, you could set things up correctly. It was important
|
|
use a valid path for <CODE>setserial</CODE>, and a valid
|
|
device name. You could do a test by executing this file manually
|
|
(just type its name as the super-user) to see if it works right.
|
|
Testing like this was a lot faster than doing repeated reboots to get
|
|
it right.</P>
|
|
<P>For versions >= 2.15 (provided your distribution implemented the
|
|
change, Redhat didn't at first) it may be more tricky to do since the
|
|
file that runs setserial on startup, /etc/init.d/setserial or the like
|
|
was not intended to be edited by the user. See
|
|
<A HREF="#config_file">Configuration method using /etc/serial.conf, etc.</A>.</P>
|
|
<P>An example line in such a script was:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>or, if you wanted setserial to automatically determine the uart and the
|
|
IRQ for ttyS3 you would have used something like this:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>This was done for every serial port you wanted to auto configure,
|
|
using a device name that really does exist on your machine. In some
|
|
cases it didn't work right due to the hardware. </P>
|
|
|
|
<H3><A NAME="config_file"></A> Configuration method using /etc/serial.conf, etc.</H3>
|
|
|
|
<P> Prior to setserial version 2.15 (1999), the way to configure
|
|
setserial was to manually edit the shell-script that ran setserial at
|
|
boot-time. See
|
|
<A HREF="#old_sets_script">Edit a script (before version 2.15)</A>. This was simple, but the simple and clear method has
|
|
been changed to something that is unnecessarily complex. Today the
|
|
script and configuration file are two different files instead of one.
|
|
This shell-script is not edited but gets its data from a configuration
|
|
file such as <CODE>/etc/serial.conf</CODE> (or
|
|
<CODE>/var/lib/setserial/autoserial.conf</CODE>).</P>
|
|
<P>Furthermore you may not even need to edit serial.conf (or the like)
|
|
because using the "setserial" command on the command line may
|
|
automatically cause serial.conf to be edited appropriately. This was
|
|
done so that you may not need to edit any file in order to set up (or
|
|
change) what setserial does each time that Linux is booted.</P>
|
|
<P>What often happens is this: When you shut down your PC the script
|
|
that ran "setserial" at boot-time is run again, but this time it only
|
|
does what the part for the "stop" case says to do: It uses
|
|
"setserial" to find out what the current state of "setserial" is, and
|
|
it puts that info into the serial configuration file such as
|
|
<CODE>serial.conf</CODE>. Thus when you run "setserial" to change
|
|
the serial.conf file, it doesn't get changed immediately but only when
|
|
and if you shut down normally.</P>
|
|
<P>Now you can perhaps guess what problems might occur. Suppose you
|
|
don't shut down normally (someone turns the power off, etc.) and the
|
|
changes don't get saved. Suppose you experiment with "setserial" and
|
|
forget to run it a final time to restore the original state (or make a
|
|
mistake in restoring the original state). Then your "experimental"
|
|
settings are saved. And worst of all, unless you know which options
|
|
were set in the configuration file, you don't know what will happen.
|
|
One option in Debian (and likely other distributions) is known as
|
|
"AUTOSAVE-ONCE" which saves changes only for the first time you make
|
|
them with the setserial command.</P>
|
|
<P>If the option "###AUTOSAVE###" is set and you manually edit
|
|
serial.conf, then your editing is destroyed when you shut down because
|
|
it gets changed back to the state of setserial at shutdown. There is
|
|
a way to disable the changing of serial.conf at shutdown and that is
|
|
to remove "###AUTOSAVE###" or the like from first line of serial.conf.
|
|
In the Debian distribution, the removal of "###AUTOSAVE###" from the
|
|
first line was once automatically done after the first time you
|
|
shutdown just after installation. To retain this effect the
|
|
"AUTOSAVE-ONCE" option was created which only does a save when time
|
|
the system is shut down for the first time (just after you install or
|
|
update the setserial program).</P>
|
|
<P>The file most commonly used to run setserial at boot-time (in
|
|
conformance with the configuration file) is now /etc/init.d/setserial
|
|
(Debian) or /etc/init.d/serial (Redhat), or etc., but it should not
|
|
normally be edited. For 2.15, Redhat 6.0 just had a file
|
|
/usr/doc/setserial-2.15/rc.serial which you have to move to
|
|
/etc/init.d/ if you want setserial to run at boot-time.</P>
|
|
<P>To disable a port, use <CODE>setserial</CODE> to set it to "uart none". This
|
|
will not be saved. The format of /etc/serial.conf appears to be just
|
|
like that of the parameters placed after "setserial" on the command
|
|
line with one line for each port. If you don't use autosave, you may
|
|
edit /etc/serial.conf manually.</P>
|
|
<P>In order to force the current settings set by setserial to be saved to
|
|
the configuration file (serial.conf) without shutting down, do what
|
|
normally happens when you shutdown: Run the shell-script
|
|
<CODE>/etc/init.d/{set}serial stop</CODE>. The "stop" command will save
|
|
the current configuration but the serial ports still keep working OK.</P>
|
|
<P>In some cases you may wind up with both the old and new configuration
|
|
methods installed but hopefully only one of them runs at boot-time.
|
|
Debian labeled obsolete files with "...pre-2.15".</P>
|
|
|
|
<H3>IRQs</H3>
|
|
|
|
<P> By default, both ttyS0 and ttyS2 will share IRQ 4, while ttyS1 and
|
|
ttyS3 share IRQ 3. But while sharing serial interrupts (using them in
|
|
running programs) is OK for the PCI bus, it's not permitted for the
|
|
ISA bus unless you: 1. have kernel 2.2 or better, and 2. you've
|
|
compiled in support for this, and 3. your serial hardware supports it.
|
|
See</P>
|
|
|
|
<P>
|
|
<A HREF="Modem-HOWTO-6.html#int_share-2.2">Interrupt sharing and Kernels 2.2+</A>
|
|
If you only have two serial ports, ttyS0 and ttyS1, you're still OK
|
|
since IRQ sharing conflicts don't exist for non-existent devices.</P>
|
|
<P>If you add a legacy internal modem (without plug-and-play) and retain
|
|
ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set
|
|
it in your serial port (or modem card) and then use setserial to
|
|
assign it to your device driver. If IRQ 5 is not being used for a
|
|
sound card, this could be used for a modem.</P>
|
|
|
|
<H3><A NAME="laptops_"></A> Laptops: PCMCIA </H3>
|
|
|
|
<P>If you have a Laptop, read PCMCIA-HOWTO for info on the serial
|
|
configuration. For serial ports on the motherboard, setserial is used
|
|
just like it is for a desktop. But for PCMCIA cards (such as a modem)
|
|
it's a different story. The configuring of the PCMCIA system should
|
|
automatically run setserial so you shouldn't need to run it. If you
|
|
do run it (by a script file or by /etc/serial.conf) it might be
|
|
different and cause trouble. The autosave feature for serial.conf
|
|
shouldn't save anything for PCMCIA cards (but Debian did until
|
|
2.15-7). Of course, it's always OK to use setserial to find out how
|
|
the driver is configured for PCMCIA cards.</P>
|
|
|
|
|
|
|
|
<H2><A NAME="ss10.2">10.2</A> <A HREF="Modem-HOWTO.html#toc10.2">What is isapnp ?</A>
|
|
</H2>
|
|
|
|
<P> <CODE>isapnp</CODE> is a program to configure Plug-and-Play (PnP) devices
|
|
on the ISA bus including internal modems. It comes in a package
|
|
called "isapnptools" and includes another program, "pnpdump" which
|
|
finds all your ISA PnP devices and shows you options for configuring
|
|
them in a format which may be added to the PnP configuration file:
|
|
/etc/isapnp.conf. It may also be used with the --dumpregs option to
|
|
show the current IO address and IRQ of the modem's serial port. The
|
|
isapnp command may be put into a startup file so that it runs each
|
|
time you start the computer and thus will configure ISA PnP devices.
|
|
It is able to do this even if your BIOS doesn't support PnP. See
|
|
Plug-and-Play-HOWTO.</P>
|
|
|
|
<H2><A NAME="wvdial_"></A> <A NAME="ss10.3">10.3</A> <A HREF="Modem-HOWTO.html#toc10.3">What is wvdialconf ? </A>
|
|
</H2>
|
|
|
|
<P> <CODE>wvdialconf</CODE> will try to find which serial port (ttyS?) has a
|
|
modem on it. It also creates a configuration program for the wvdial
|
|
program. <CODE>wvdial</CODE> is used for simplified dialing out using the PPP
|
|
protocol to an ISP. It can also look for modems which are not
|
|
currently in use. It will automatically devise a "suitable" init
|
|
string for the modem but sometimes gets it wrong. Since this command
|
|
has no options, it's simple to use but you must give it the name of a
|
|
file to put the init string (and other data) into. For example type:
|
|
wvdialconf my_config_file_name.</P>
|
|
|
|
<HR>
|
|
<A HREF="Modem-HOWTO-11.html">Next</A>
|
|
<A HREF="Modem-HOWTO-9.html">Previous</A>
|
|
<A HREF="Modem-HOWTO.html#toc10">Contents</A>
|
|
</BODY>
|
|
</HTML>
|