This commit is contained in:
gferg 2002-03-20 14:37:13 +00:00
parent 0b8f02f9ba
commit 1e5bdebda2
4 changed files with 265 additions and 199 deletions

View File

@ -1984,7 +1984,7 @@ nfs server attached by a Null-Modem parallel cable. </Para>
Plug-and-Play-HOWTO</ULink>,
<CiteTitle>The Linux Plug-and-Play HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: August 2001</CiteTitle>.
<CiteTitle>Updated: March 2002</CiteTitle>.
How to get your Linux system to support Plug-and-Play. </Para>
</ListItem>
@ -2314,7 +2314,7 @@ Addresses Linux localization issues specific to Serbian users
Serial-HOWTO</ULink>,
<CiteTitle>Serial HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: November 2001</CiteTitle>.
<CiteTitle>Updated: March 2002</CiteTitle>.
Describes serial port features other than those which should be
covered by other HOWTOs. Lists information on multiport serial cards
and contains detailed technical information about the serial port

View File

@ -999,7 +999,7 @@ SCSI-Generic-HOWTO</ULink> for more current information.</emphasis> </Para>
Serial-HOWTO</ULink>,
<CiteTitle>Serial HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: November 2001</CiteTitle>.
<CiteTitle>Updated: March 2002</CiteTitle>.
Describes serial port features other than those which should be
covered by other HOWTOs. Lists information on multiport serial cards
and contains detailed technical information about the serial port
@ -1257,7 +1257,7 @@ How to install and use PCMCIA Card Services for Linux. </Para>
Plug-and-Play-HOWTO</ULink>,
<CiteTitle>The Linux Plug-and-Play HOWTO</CiteTitle>
</Para><Para>
<CiteTitle>Updated: August 2001</CiteTitle>.
<CiteTitle>Updated: March 2002</CiteTitle>.
How to get your Linux system to support Plug-and-Play. </Para>
</ListItem>

View File

@ -3,13 +3,15 @@
<title> Plug-and-Play-HOWTO </title>
<author>David S.Lawyer
<tt><url url="mailto:dave@lafn.org"></tt>
<date> v1.03, August 2001
<date> v1.04, March 2002
<!--
Change log:
Change log:
v1.04 March 2002 finding a device driver, PCI serial ports,
alias example in modules.conf, PnP needed for linmodems
v1.03 August 2001: error messages, boot-prompt parameters
v1.02 July 2001: PCI config regs.
v1.01 April 2001: less shortage today of bus-resouces, clarity in sect. 2,
v1.01 April 2001: less shortage today of bus-resources, clarity in sect. 2,
Windows 2000 OK (even if "not a PnP OS" in CMOS)
v1.00 November 2000: "skip file" workaround for reconfiguring under Windows.
PCI interrupt details: X, W were transposed, rewrote, mentioned MSI,
@ -32,13 +34,13 @@ v0.02 Apr. 1999 /proc/... doesn't show hdw config (except pci)
v0.01 Mar. 1999 serial PnP spec, PCI interrupts, no DMA on PCI,
dumpregs for pnpdump , Bus Mastering DMA, clarity rewrites, pciutils
kernel 2.2 /proc tree, IO range check, Windows may not update ESCD
v0.00 Nov. 1998
v0.00 Nov. 1998
-->
<abstract>
Help with understanding and dealing with the complex Plug-and-Play
(PnP) issue. How to get PnP to work on your PC (if it doesn't already).
It doesn't cover what's called "Universal Plug and Play"
(UPnP). See <ref id="UPnP_" name="Universal Plug and Play (UPnP)"
(UPnP). See <ref id="UPnP_" name="Universal Plug and Play (UPnP)"
</abstract>
<toc>
@ -57,18 +59,18 @@ provided that you:
<enum>
<item> If it's not a translation: Email a copy of your derivative work
(in a format LDP accepts) to the author(s) and maintainer (could be
the same person). If you don't get a response then email the LDP
(Linux Documentation Project): submit@linuxdoc.org.
(in a format LDP accepts) to the author(s) and maintainer (could be
the same person). If you don't get a response then email the LDP
(Linux Documentation Project): submit@linuxdoc.org.
<item>License the derivative work in the spirit of this license or use
GPL. Include a copyright notice and at least a pointer to the
GPL. Include a copyright notice and at least a pointer to the
license used.
<item>Give due credit to previous authors and major contributors.
</enum>
If you're considering making a derived work other than a
translation, it's requested that you discuss your plans with the
current maintainer.
current maintainer.
<sect2>Disclaimer
<p> While I haven't intentionally tried to mislead you, there are
@ -84,12 +86,12 @@ be a trademark). Such trademarks belong to their respective owners.
<sect2> Credits
<p>
<itemize>
<item> Daniel Scott proofread this in March 2000 and found many
<itemize>
<item> Daniel Scott proofread this in March 2000 and found many
typos, etc.
<item> Pete Barrett gave a workaround to prevent Windows from zeroing
PCI IRQs.
</itemize>
</itemize>
<sect1> Future Plans; You Can Help
<p> Please let me know of any errors in facts, opinions, logic,
@ -112,21 +114,23 @@ url="http://linuxdoc.org/mirrors.html">. Various formats are
available. If you only want to quickly check the date of the latest
version look at: <url
url="http://linuxdoc.org/HOWTO/Plug-and-Play-HOWTO.html">. The
version you are now reading is: v1.03, August 2001 .
version you are now reading is: v1.04, March 2002 .
<sect1> New in Recent Versions
<p>
v1.04 March 2002 finding a device driver, PCI serial ports,
alias example in modules.conf, PnP needed for linmodems
v1.03 August 2001: error messages, boot-prompt parameters
v1.02 July 2001: PCI config regs. v1.01 April 2001: less shortage
today of bus-resources, clarity in sect. 2, Windows 2000 OK (even if
"not a PnP OS" in CMOS)
v1.01 April 2001: less shortage today of bus-resources, clarity in sect. 2,
v1.01 April 2001: less shortage today of bus-resources, clarity in sect. 2,
Windows 2000 OK (even if "not a PnP OS" in CMOS)
The version 1.0 (Nov. 2000) was long overdue and recognized that the
kernel is doing more in helping device drivers set up PnP. Kernel 2.4
is significantly improved in this respect. There's still a lot of
improvements needed in both this HOWTO and the way that Linux does
improvement needed in both this HOWTO and the way that Linux does
PnP.
<sect1> General Introduction. Do you need this HOWTO?
@ -135,7 +139,7 @@ devices such as disks, sound cards, ethernet cards, modems, etc. It
also does some low-level configuring of them. To be detected by PnP, the
device must be designed for PnP. Non-PnP devices (or PnP devices which
have been correctly PnP-configured), can often be detected by
non-PnP methods.
non-PnP methods.
While the Linux kernel has no centralized plug-and-play system, it
does provide programs which various device drivers can use to do their
@ -148,12 +152,32 @@ they not discovered or configured correctly by PnP) then you may need
to read some of this HOWTO. You'll learn not only about PnP but also
something about how communication takes place inside the computer.
If you're having problems with a device, first check to see that you
have the right driver for a device, and that the driver is being found
and used. If the driver is a module, type "lsmod" (as the root user)
to see it it's loaded (in use). If it's not a module then it should
be built into the kernel. There should be a file somewhere that tells
what drivers are built into the kernel: (such as: /boot/config-2.4-20
in Debian). Sometimes a device name (such as /dev/eth0) doesn't get a
driver assigned to it unless the assignment is found in the file:
/etc/modules.conf: For example, to assign the "tulip" driver to eth0
you add a line to this file:
<newline> alias eth0 tulip
This HOWTO doesn't cover the problem of finding and installing device
drivers. Perhaps it should. One problem is that a certain brand of a
card (or other physical device) may not say what kind of chips are
used in it. The driver name is often the same as the chip name and
not the brand name. One way to start to check on a driver is to see
if it is discussed in the kernel documentation, in another HOWTO, or
on the Internet. Warning: Such documentation may be out of date.
In this document I mention so many things that can go wrong that one
who believes in Murphy's Law (If something can go wrong it will) may
become quite alarmed. But for PnP for most people: If something can
go wrong it usually doesn't. Remember that sometimes problems which
seem to be PnP related are actually due to defective hardware or to
hardware that doesn't conform to PnP specs.
hardware that doesn't fully conform to PnP specs.
<sect> What PnP Should Do: Allocate "Bus-Resources"
<sect1> What is Plug-and-Play (PnP)?
@ -198,7 +222,7 @@ there are a number of devices such as various kinds of disk-drives, a
video card, a keyboard, network cards, modem cards, sound cards, the
USB bus, serial and parallel ports, etc. There is also a power supply
to provide electric energy, various buses on a motherboard to connect
the devices to the CPU, and a case to put all this into.
the devices to the CPU, and a case to put all this into.
In olden days most all devices had their own plug-in cards (printed
circuit boards). Today, in addition to plug-in cards, many "devices"
@ -212,15 +236,19 @@ control of its "device driver". This is software which is a part of
the operating system (perhaps loaded as a module) and runs on the CPU.
Device drivers are associated with "special files" in the /dev
directory although they are not really files. They have names such as
hda1 (first partition on hard drive a), ttyS0 (the first serial port),
eth1 (the second ethernet card), etc. To make matters more
complicated, the particular device driver selected, say for eth1, will
depend on the type of ethernet card you have. Thus eth1 can't just be
assigned to any ethernet driver. It must be assigned to a certain
driver that will work for the type of ethernet card you have
installed. For modules, some of these assignments might be found in
/etc/modules.conf (called "alias") while others may reside in an
internal kernel table.
hda3 (third partition on hard drive a), ttyS1 (the second serial port),
eth0 (the first ethernet card), etc.
To make matters more complicated, the particular device driver
selected, say for example eth0, will depend on the type of ethernet
card you have. Thus eth0 can't just be assigned to any ethernet
driver. It must be assigned to a certain driver that will work for
the type of ethernet card you have installed. If the driver is a
module, some of these assignments might be found in /etc/modules.conf
(called "alias") while others may reside in an internal kernel table.
For example, if you have an ethernet card that uses the "tulip" chip
put "alias eth0 tulip" into /etc/modules.conf so that when your
computer asks for eth0 it finds the tulip driver.
To control a device, the CPU (under the control of the device driver)
sends commands (and data) to and reads info from the various devices.
@ -238,7 +266,7 @@ device. Also, there is a reverse part of the channel (known as
interrupts) which allows devices to send an urgent "help" request to
their device driver.
<sect1> Addresses
<sect1> Addresses
<p> PCs have 3 address spaces: I/O, main memory (IO memory), and
configuration (except that the old ISA bus lacks a "configuration"
address space). All of these 3 types of addresses share the same bus
@ -257,10 +285,10 @@ range" are also used. Don't confuse these IO ports with "IO memory"
located in main memory. There are two main steps to allocate the I/O
addresses (or other bus-resources such as interrupts):
<enum>
<item> Set the I/O address, etc. on the card (in one of its registers)
<enum>
<item> Set the I/O address, etc. on the card (in one of its registers)
<item> Let its device driver know what this I/O address, etc. is
</enum>
</enum>
The two step process above is something like the two part problem of
finding someone's house number on a street. Someone must install a
@ -279,7 +307,7 @@ to a serial port without realizing that this only tells the driver an
address. It doesn't set the address in the serial port hardware
itself. If the serial port hardware doesn't have the address you told
setserial (or doesn't have any address set in it) then you're in
trouble.
trouble.
An obvious requirement is that before the device driver can use an
address it must be first set on the physical device (such as a card).
@ -311,7 +339,7 @@ is shared between the device and the CPU (running the device driver)
just as IO address space is shared between the device and the CPU.
This shared memory serves as a means of data "transfer" between the
device and main memory. It's IO but it's not done in IO space. Both
the card and the device driver need to know where it is.
the card and the device driver need to know where it is.
ROM is different. It is likely a program (perhaps a device driver)
which will be used with the device. It could be initialization code
@ -319,7 +347,7 @@ so that a device driver is still required. Hopefully, it will work
with Linux and not just MS Windows ?? It may need to be shadowed
which means that it is copied to your main memory chips in order to
run faster. Once it's shadowed it's no longer "read only".
<sect1> IRQs --Overview <label id="interrupt_over">
<sect1> IRQs --Overview <label id="interrupt_over">
<p> After reading this you may read <ref id="interrupt_detail" name=
"Interrupts --Details"> for some more details. The following is
intentionally oversimplified: Besides the address, there is also an
@ -360,7 +388,7 @@ sharing of IRQs is allowed.
<p> DMA channels are only for the ISA bus. DMA stands for "Direct Memory
Access". This is where a device is allowed to take over the main
computer bus from the CPU and transfer bytes directly to main memory.
Normally the CPU would make such a transfer in a two step process:
Normally the CPU would make such a transfer in a two step process:
<enum>
<item>reading from the I/O memory space of the device and putting these
bytes into the CPU itself
@ -368,7 +396,7 @@ bytes into the CPU itself
</enum>
<enum>
<item> With DMA it's usually a one step process of sending the bytes
directly from the device to memory
directly from the device to memory
</enum>
The device must have such capabilities built into its hardware and
thus not all devices can do DMA. While DMA is going on the CPU can't
@ -416,7 +444,7 @@ configuration register data is usually lost when the PC is powered
down (turned off) so that the bus-resource data must be supplied to
each device anew each time the PC is powered on.
<sect1> The Problem
<sect1> The Problem
<p> The architecture of the PC provides only a limited number of
IRQ's, DMA channels, I/O address, and memory regions. If there were
only several devices and they all had standardized bus-resource (such
@ -460,18 +488,20 @@ can initiate communication.
<p> External devices that connect to the serial port via a cable (such
as external modems) can also be called Plug-and-Play. Since only the
serial port itself needs bus-resources (an IRQ and I/O address) there are
no bus-resources to allocate to such plug-in devices. Thus PnP is not
really needed for them. Even so, there is a PnP specification for
such external serial devices.
no bus-resources to allocate to such plug-in devices. In this case,
PnP is used only to identify the modem (read it's model code number).
This could be important if the modem is a software modem (linmodem)
and requires a special driver. There is a special PnP specification
for such external serial devices (something connected to the serial
port).
A PnP operating system will find such an external device and read its
model number, etc. Then it may be able to find a device driver for it
so that you don't have to tell an application program that you have a
certain device on say /dev/ttyS1. Since you should be able to
manually inform your application program (via a configuration file,
etc.) what serial port the device is on (and possibly what model
number it is) you should not really need this "serial port" feature of
PnP. I don't think Linux supports it ??
Linux doesn't support this yet ?? For a hardware modem, the ordinary
serial driver will work OK so there's little need for using the
special serial PnP to find a driver. You still need to tell the
communications program what port (such as /dev/ttyS1) the modem is on.
With PnP you wouldn't need to even do this. With the advent of
software modems that have Linux drivers (linmodems), it would be nice
to have the appropriate driver install itself automatically via PnP.
<sect> The Plug-and-Play (PnP) Solution
<sect1> Introduction to PnP
@ -509,7 +539,7 @@ possible). It then tells each physical device what bus-resources are
assigned to it and the devices set themselves up to use only the
assigned bus-resources. Then the device drivers somehow find out what
bus-resources their devices use and are thus able to communicate
effectively with the devices they control.
effectively with the devices they control.
For example, suppose a card needs one interrupt (IRQ number) and 1 MB
of shared memory. The PnP program reads this request from the card.
@ -597,7 +627,7 @@ device drivers with devices and also a need to configure devices that
are added when the PC is up and running. These needs would be better
satisfied if Linux was a PnP operating system.
<sect1> How Linux Does PnP <label id="how_linux_pnps">
<sect1> How Linux Does PnP <label id="how_linux_pnps">
<p> Linux has had a serious problem dealing with PnP and still has a
problem but it's not as severe as it once was. Linux still is not
really a PnP operating system and seems to mainly rely on and device
@ -642,11 +672,11 @@ use. For the ISA bus see isapnp.txt and possibly (for kernel 2.4)
When the PC starts up you may note from the messages on the screen
that some Linux device drivers often find their hardware devices (and
the bus-resources the BIOS has assigned them). But there are a number
of things that a real PnP operating system could handle better:
of things that a real PnP operating system could handle better:
<itemize>
<item>A Allocate bus-resources when they are in short supply
<item>Deal with more than one driver for a physical device
<item>A Allocate bus-resources when they are in short supply
<item>Deal with more than one driver for a physical device
<item>Find a driver for a detected device (instead of making
drivers do the searching)
<item>Save a lot of work for the programmers of device drivers
@ -743,7 +773,7 @@ fully configured by the BIOS but it can't. But it's reported that
Windows 2000 can cope with this. One might expect that even if
Windows9x didn't realize that the hardware was already configured, it
would set the configuration of the physical devices per it's registry
and then then everything would work OK.
and then then everything would work OK.
But it doesn't seem to happen this way. It seems that Windows9x may
just tell its device drivers what has been stored in the Windows'
@ -758,9 +788,7 @@ One way to try to get the Registry and the ESCD the same is to install
should present Windows with hardware configured by the BIOS. If this
configuration is without conflicts, Windows will hopefully leave it
alone and save it in it's Registry. Then the ESCD and the registry
are in sync. If this works for you (and this is the latest version of
this HOWTO), let me know as I only have one report of this working out
OK.
are in sync.
Another method is to remove devices that are causing problems in
Windows by clicking on "remove" in the Device Manager. Then reboot with
@ -822,8 +850,8 @@ configures it, you hope that the driver can find out what the BIOS did
<item> <ref id="bios_conf" name= "BIOS Configures PnP"> (For the PCI bus
you only need a PCI BIOS, otherwise you need a PnP BIOS)
<item> <ref id="disable_pnp" name="Disable PnP"> by jumpers or
DOS/Windows software (but many cards can't do this)
<item> <ref id="isapnp_" name="Isapnp"> is a program you can always
DOS/Windows software (but many cards can't do this)
<item> <ref id="isapnp_" name="Isapnp"> is a program you can always
use to configure PnP devices on the ISA bus only
<item> <ref id="pciutils_" name="PCI Utilities"> is for configuring the PCI
bus but the device driver should handle it
@ -908,7 +936,7 @@ optional but most PnP-BIOSs have it. The ESCD not only stores the
resource-configuration of PnP devices but also stores configuration
information of non-PnP devices (and marks them as such) so as to avoid
conflicts. The ESCD data is usually saved on a chip and remains
intact when the power is off, but sometimes it's kept on a hard-drive??
intact when the power is off, but sometimes it's kept on a hard-drive??
The ESCD is intended to hold the last used configuration, but if you
use a program such as Linux's isapnp or pci utilities (which doesn't
@ -924,7 +952,7 @@ the Linux OS is loaded) it should configure things this way. If the
BIOS detects a new PnP card which is not in the ESCD, then it must
allocate bus-resources to the card and update the ESCD. It may even
have to change the bus-resources assigned to existing PnP cards and
modify the ESCD accordingly.
modify the ESCD accordingly.
If each device saved its last configuration in its hardware, hardware
configuring wouldn't be needed each time you start your PC. But it
@ -951,7 +979,7 @@ Windows knows about them and what bus-resources they use, then Windows
should put this info into the ESCD.
If PnP devices are configured automatically by Windows without the
user "forcing" it to change settings, then such settings probably will
user "forcing" it to change settings, then such settings probably will
not make it into the ESCD. Of course Windows may well decide on its
own to configure the same as what is set in the ESCD so they could
wind up being the same by coincidence.
@ -983,7 +1011,7 @@ hardware" list: Start --> Programs --> Accessories --> System Tools
--> System Information --> Hardware Resources --> Forced Hardware.
When you "force" a change of bus-resources in Windows, it should put
your change into the ESCD (provided you exit Windows normally).
From the "System Information" window you may also inspect how IRQs and
>From the "System Information" window you may also inspect how IRQs and
IO ports have been allocated under Windows.
Even if Windows shows no conflict of bus-resources, there may be a
@ -1007,7 +1035,7 @@ conflict. Another method is to run ICU under DOS/Windows. Still
another is to install it manually under Windows 9x/2k and then make
sure its configuration is "forced" (see the previous section). If
it's "forced" Windows should update the ESCD when you shut down the
PC.
PC.
<sect1> Disable PnP ? <label id="disable_pnp">
<p> Many devices are PnP only with no option for disabling PnP. But
@ -1037,7 +1065,7 @@ Once configured as non-PnP devices, they can't be configured by PnP
software or a PnP-BIOS (until you move jumpers and/or use the
Dos/Windows configuration software again).
<sect1> Isapnp (part of isapnptools) <label id="isapnp_">
<sect1> Isapnp (part of isapnptools) <label id="isapnp_">
<p> Unfortunately, much of the documentation for isapnp is still
difficult to understand unless you know the basics of PnP. This HOWTO
should help you understand it as well the FAQ that comes with it.
@ -1045,7 +1073,7 @@ should help you understand it as well the FAQ that comes with it.
the Linux program "isapnp" at boot-time will configure such devices to
the resource values specified in /etc/isapnp.conf. Its possible to
create this configuration file automatically but you then must edit it
manually to choose between various options.
manually to choose between various options.
With isapnp there's a danger that a device driver which is built into
the kernel may run too early before isapnp has set the address, etc.
@ -1062,7 +1090,7 @@ the program "pnpdump" to help create the configuration file. It
almost creates a configuration file for you but you must skillfully
edit it a little before using it. It contains some comments to help
you edit it. If you use "isapnp" for configuring and have a PnP BIOS,
you you may want to tell the BIOS (when you set it up) that you don't
you may want to tell the BIOS (when you set it up) that you don't
have a PnP OS since you may want the BIOS to configure the PCI
devices. While the BIOS may also configure the ISA devices, isapnp
will redo it.
@ -1172,7 +1200,7 @@ device resides. It may then try to test various IRQs to see which one
works. It may or may not automatically do this. In other cases the
driver may use PnP methods to find the device and how the bus-resources
have been set, but will not actually set them. It may also look in
some of the files in the /proc directory.
some of the "files" in the /proc directory.
One may need to "manually" tell a driver what bus-resources it should
use. You give such bus-resources as a parameter to the kernel or to a
@ -1183,8 +1211,10 @@ parameters. Once you know what parameters to give to the kernel, one
may put them into lilo.conf file as append="...". Then the lilo
program must be run to get this info into the kernel loader.
If the driver is loaded as a module, you may need to give
bus-resources as parameters to the module. In some versions of Linux
If the driver is loaded as a module, in many cases the module will
find the bus-resources it needs and set them in the device. In other
cases (mostly for older PCs) you may need to give bus-resources as
parameters to the module. In some versions of Linux
/usr/lib/modules_help/descr.gz shows a list of possible module
parameters. Parameters to a module (including ones that automatically
load) may be specified in /etc/modules.conf. There are usually tools
@ -1199,14 +1229,21 @@ kernel documentation tree). Some brief info on a few drivers is
presented in the following sections:
<sect1> Serial Port Driver: setserial
<p> For the standard serial port driver (not for multiport cards) you
use setserial to configure the driver. It is often run from a
start-up file. In newer versions there is a /etc/serial.conf file
that you "edit" by simply using the setserial command in the normal
way and what you set using <tt/setserial/ is saved in the
<tt>serial.conf</tt> configuration file. The <tt>serial.conf</tt>
file should be consulted when the <tt/setserial/ command runs from a
start-up file. Your distribution may or may not set this up for you.
<p> For PCI serial ports (and for newer 2.4 kernels for ISA), the
serial driver detects the type of serial port and PnP configures it.
Unfortunately, there may be some PCI serial ports that are not
supported yet.
For the standard ISA serial port with older versions of the kernel and
serial driver (not for multiport cards) you use setserial to configure
the driver. Using setserial is also a must for non-pnp serial ports.
Setserial is often run from a start-up file. In newer versions there
is a /etc/serial.conf file that you "edit" by simply using the
setserial command in the normal way and what you set using
<tt/setserial/ is saved in the <tt>serial.conf</tt> configuration
file. The <tt>serial.conf</tt> file should be consulted when the
<tt/setserial/ command runs from a start-up file. Your distribution
may or may not set this up for you.
There are two different ways to use <tt/setserial/ depending on the
options you give it. One way is used to manually tell the driver the
@ -1220,7 +1257,7 @@ probe for the existence of a port. See Serial-HOWTO for more details.
For PCI serial, the serial driver may detect certain modems and
configure the bus-resources.
<sect1> Sound Card Drivers
<sect1> Old ISA Sound Card Drivers
<sect2> OSS-Lite
<p> You must give the IO, IRQ, and DMA as parameters to a module
@ -1268,7 +1305,7 @@ information.
But sometimes the driver has been provided incorrect resources by a
script, by incorrect resource parameters given to a module, or perhaps
just hasn't been told what the resources are and tries to use
incorrect default resources. For example, one can uses "setserial"
incorrect default resources. For example, one can uses "setserial"
to tell the driver an incorrect resource configuration and the driver
accepts it without question.
@ -1282,7 +1319,7 @@ time to the shell prompt will show only the Linux kernel messages and
miss some of the most important ones (including ones from the BIOS).
The messages from Linux may sometimes only show what the device driver
thinks the configuration is, perhaps as told it via an incorrect
configuration file.
configuration file.
The BIOS messages will show the actual hardware configuration at that
time, but isapnp, or pci utilities, or device drivers may change it
@ -1292,7 +1329,7 @@ them, try freezing them by hitting the "Pause" key. Press any key to
resume. But once the messages from Linux start to appear, it's too
late to use "Pause" since it will not freeze the messages from Linux.
<sect1> How Are My Device Drivers Configured?
<sect1> How Are My Device Drivers Configured?
<p> There may be a programs you can run from the command line (such as
"setserial" for serial ports) to determine this. The /proc directory
tree is useful. It seems that there are many files buried deep in
@ -1314,13 +1351,13 @@ they came from the device shown. It could be that some other device
which is not currently in use has issued them. A device not in use (per
the kernel) may still issue some interrupts for various reasons.
<sect1> How Are My Hardware Devices Configured?
<sect1> How Are My Hardware Devices Configured?
<p> It's easy to find out what bus-resources have been assigned to
devices on the PCI bus with the "lspci" or "scanpci" commands. For
for kernels &lt 2.2: see <tt>/proc/pci</tt> or <tt>/proc/bus/pci</tt>
for later kernels. Note that IRQs for <tt>/proc/pci</tt> are in
hexadecimal. Don't bother trying to decipher
<tt>/proc/bus/pci/devices</tt> since "lspci" will do that for you.
<tt>/proc/bus/pci/devices</tt> since "lspci" will do that for you.
In most cases for PCI you will only see how the hardware is now
configured and not what resources are required. In some cases you
@ -1358,7 +1395,7 @@ cases both Windows and Linux simply accept what the BIOS has set. But
where Windows and/or Linux do the configuring, they may do it
differently. So don't count on devices being configured the same.
<sect>Error Messages
<sect>Error Messages
<sect1> Unexpected Interrupt
<p> This means that an interrupt happened that no driver expected.
It's unlikely that the hardware issued an interrupt by mistake. It's
@ -1420,7 +1457,7 @@ for serial port is only 8 bytes. The starting address is known as the
"base address". Sometimes just the word "range" is used to mean
"address range".
<sect2> Address space
<sect2> Address space
<p> For ISA, to access both I/O and (main) memory address "spaces"
the same address bus is used (the wires used for the address are
shared). How does the device know whether or not an address which
@ -1430,7 +1467,7 @@ and more. If a certain one of these 4 wires is asserted, it says that
the CPU wants to read from an I/O address, and the main memory ignores
the address on the bus. The other 3 wires serve similar purposes.
Thus read and write wires exist for both main memory and I/O addresses
(4 wires in all).
(4 wires in all).
For the PCI bus it's the same basic idea (also using 4 wires) but it's
done a little differently. Instead of only one or the four wires
@ -1487,7 +1524,7 @@ this problem, each card is assigned a card number (handle) using a
technique called "isolation". See <ref id="isolation_" name="ISA
Isolation"> for the complex details.
Then to configure a certain card, its card number (handle) is sent
Then to configure a certain card, its card number (handle) is sent
out via the write-port address to tell that card that it is to listen
at its address port. All other cards note that this isn't their card
number and thus don't listen. Then the address of a configuration
@ -1562,7 +1599,7 @@ to support it. Note that you can't share the same interrupt between
the PCI and ISA bus. However, illegal sharing will work provided the
devices which are in conflict are not in use at the same time. "In
use" here means that a program is running which "opened" the device in
its C programming code.
its C programming code.
Here are some of the details of the PCI interrupt system. Each PCI
card (and device mounted on the motherboard) has 4 possible
@ -1573,7 +1610,7 @@ interrupt lines for the cards. But the specs permit a fewer number of
interrupt lines so many PCI buses seem to be made with only 4
interrupt lines. This is not too restrictive since interrupts may be
shared. Call these lines (wires or traces) W, X, Y, Z. Suppose we
designate the B interrupt from slot 3 as interrupt 3B.
designate the B interrupt from slot 3 as interrupt 3B.
One simple method of connecting these lines to the interrupts would be
to connect all A interrupts (INTA#) to line W, all B's to X,
@ -1612,7 +1649,7 @@ the CMOS BIOS menu one may allow one to assign IRQs to PCI cards.
Also, a PnP operating system (for example MS Windows) could attempt to
assign these IRQs after first finding out what the BIOS has done. The
assignments are known as a "routing table". If MS Windows makes such
IRQ assignment dynamically (such as a docking event) it's called
IRQ assignment dynamically (such as a docking event) it's called
"IRQ steering". The BIOS may support it's own IRQ steering (which
Linux could use). If you use Linux after Windows without turning off
your PC, the IRQs may be different than what the BIOS set.
@ -1663,7 +1700,7 @@ round) all have the same leading digit (a 1) so we may strip off this
digit and consider only the resulting "stripped serial number" for
future participation in this round. Then go to the start of this
paragraph and repeat until the entire serial number has been examined
for each device (see below for the all-0 case).
for each device (see below for the all-0 case).
Thus it's clear that only cards with the lower serial number get
eliminated during a round. But what happens if all devices in the
@ -1696,3 +1733,5 @@ must be done over again.
END OF Plug-and-Play-HOWTO
</article>
___________________________________
thanks for submitting into linuxdoc

View File

@ -4,9 +4,10 @@
<author>David S.Lawyer
<tt><htmlurl url="mailto:dave@lafn.org" name="dave@lafn.org"></tt>
original by Greg Hankins
<date> v2.15 November 2001
<date> v2.16 March 2002
<!-- Change log:
v2.16 March 2002 fixed a few broken links.
v2.15 November 2001: mention of MIDI ports, problems with lockfiles
for devfs
v2.14 August 2001: major revision of Configuring the Serial Port
@ -39,8 +40,8 @@ v1.11 15 November 1997 by Greg Hankins
some research to determine them)
v1.8.1: 9 Oct. 1995
v1.7: 29 Oct. 1994
v1.0 6 Jan. 1994: first Serial-HOWTO by Greg Hankins
v1.0 June 1993: was called Serial FAQ, by Greg Hankins
v1.0: 6 Jan. 1994: first Serial-HOWTO by Greg Hankins
v1.0: June 1993: was called Serial FAQ, by Greg Hankins
-->
<abstract>
This document describes serial port features other than those which
@ -127,11 +128,12 @@ half is by David Lawyer. Ted Ts'o has continued to be helpful.
<sect1> New Versions of this Serial-HOWTO
<p> New versions of the Serial-HOWTO will be available to
browse and/or download at LDP mirror sites. For a list of mirror
sites see: <url url="http://metalab.unc.edu/LDP/mirrors.html">.
sites see: <url url="http://www.linuxdoc.org/mirrors.html">.
Various formats are available. If you only want to quickly check the
date of the latest version look at <url
url="http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html"> and compare
it to this version: v2.15 November 2001 . New in recent versions:<newline>
it to this version: v2.16 March 2002 . New in recent versions:<newline>
v2.16 March 2002 fixed a few broken links.
v2.15 November 2001: mention of MIDI ports, problems with lockfiles
for devfs
v2.14 August 2001: major revision of Configuring the Serial Port
@ -351,7 +353,8 @@ transmit buffer in the hardware.
Nov. '99: 2 serial drivers concurrently NG
Sept. '00: data flow diagram
Dec. '00 flow control +
July "01 done -> down
July '01 done -> down
Feb. '02 4k buffer -> 8k
-->
@ -662,7 +665,7 @@ code. Likewise for DC1.
control, a pair of 16-byte FIFO buffers (in the UART), and a pair of
larger buffers inside a device connected to the serial port (such as a
modem. But there is still another pair of buffers. These are large
buffers (perhaps 8k) in main memory also known as serial port buffers.
buffers (perhaps 4k) in main memory also known as serial port buffers.
When an application program sends bytes to the serial port
they first get stashed in the the transmit serial port buffer in main
@ -673,7 +676,7 @@ Transmit data flow is left to right while receive flow is right to
left.
<verb>
application 8k-byte 16-byte 1k-byte tele-
application 4k-byte 16-byte 1k-byte tele-
BROWSER ------- MEMORY -------- UART --------- MODEM -------- phone
program buffer buffer buffer line
</verb>
@ -689,7 +692,7 @@ the computer, what it actually stops is the flow of outgoing bytes
from the large transmit buffer in main memory. Even after this has
happened and the flow to the device
connected to the serial port has stopped, an application program
may keep sending bytes to the 8k transmit buffer until it becomes
may keep sending bytes to the 4k transmit buffer until it becomes
fill.
When it gets fill, the application program can't send any more bytes
@ -727,15 +730,15 @@ a long file from the BBS which is being sent simultaneously to both my
text-terminal and a to file on my hard-disk. The bytes are coming in
faster than the terminal can handle them so it sends a "stop" out its
serial port to the first serial port on my PC. The device driver
detects it and stops sending bytes from the 8k serial buffer (in main
detects it and stops sending bytes from the 4k serial buffer (in main
memory) to the terminal. Now minicom still keeps sending out bytes for
the terminal into this 8k buffer.
the terminal into this 4k buffer.
When this 8k transmit buffer (on the first serial port) is full,
When this 4k transmit buffer (on the first serial port) is full,
minicom must stop writing to it. Minicom stops and waits. But this
also causes minicom to stop reading from the 8k receive buffer on the
also causes minicom to stop reading from the 4k receive buffer on the
2nd serial port connected to the modem. Flow from the modem continues
until this 8k buffer too fills up and sends a different "stop" to the
until this 4k buffer too fills up and sends a different "stop" to the
modem. Now the modem's buffer ceases to send to the serial port and
also fills up. The modem (assuming error correction is enabled) sends
a "stop signal" to the other modem at the BBS. This modem stops
@ -748,7 +751,7 @@ Thus a stop signal from a text terminal has halted a programs on a BBS
computer. What a complex sequence of events! Note that the stop
signal passed thru 4 serial ports, 2 modems, and one application
program (minicom). Each serial port has 2 buffers (in one direction
of flow): the 8k one and the hardware 16-byte one. The application
of flow): the 4k one and the hardware 16-byte one. The application
program may have a buffer in its C_code. This adds up to 11 different
buffers the data is passing thru. Note that the small serial hardware
buffers do not participate directly in flow control.
@ -787,7 +790,7 @@ happened there, bytes intended for the hard-disk were lost.
<sect1> Serial Driver Module
<p> The device driver for the serial port is the software that
operates the serial port. It is now provided as a serial module.
From kernel 2.2 on, this module will normally get loaded automatically
>From kernel 2.2 on, this module will normally get loaded automatically
if it's needed. In earlier kernels, you had to have <tt/kerneld/
running in order to do auto-load modules on demand. Otherwise the
serial module needed to be explicitly listed in /etc/modules. Before
@ -814,22 +817,23 @@ See <ref id="set_serial" name="What is Setserial"> for more info on
<sect1> Introduction
<p> The answer is yes, but ... The serial port is somewhat obsolete
but it's still needed, especially for Linux. The serial port has many
shortcomings but almost all new PC's seem to come with them them.
Linux supports ordinary telephone modems only if they work thru a
serial port.
shortcomings but almost all new PC's seem to come with them. Linux
supports ordinary telephone modems only if they work thru a serial
port (although the port may be built into the modem).
The serial port must pass data between the computer and the external
cable. Thus it has two interfaces and both of these interfaces are
slow. First we'll consider the interface via external cable to the
outside world.
cable. Thus it has two interfaces: the serial-port-to cable and the
serial-port-to-computer-bus. Both of these interfaces are slow.
First we'll consider the interface via external cable to the outside
world.
<sect1> EIA-232 Cable Is Low Speed & Short Distance
<p> The conventional EIA-232 serial port is inherently low speed and
is severely limited in distance. Ads often read "high speed" but it
can only work at "high speed" over very short distances such as to a
modem located right next to the computer. Compared to a network card,
even this "high speed" is low speed. All of the serial cable wires
use a common ground return wire so that twisted-pair technology
even this "high speed" is low speed. All of the EIA-232 serial cable
wires use a common ground return wire so that twisted-pair technology
(needed for high speeds) can't be used without additional hardware.
More modern interfaces for serial ports exist but they are not
standard on PC's like the EIA-232 is. See <ref id="non_232"
@ -857,13 +861,13 @@ port). It's actually a range of addresses and the lower address in
this range is the base address. If someone only says (or writes)
"address" it likely really means "base address"
Instead of using I/O, addresses some I/O devices read and write
Instead of using I/O addresses, some I/O devices read and write
directly from/to main memory. This provides more bandwidth since the
conventional serial I/O system only moves a byte at a time. There are
various ways to read/write directly to main memory. One way is called
shared memory I/O (where the shared memory is usually on the same card
as the I/O device). Other methods are DMA (direct memory access) on
the ISA bus and what is about the same as DMA (only much faster):
the ISA bus and what is about the same as DMA (only much faster):
"bus mastering" on the PCI bus. These methods are a lot faster than
those used for the serial port. Thus the conventional serial port
with its interrupt driven (every 14 bytes) interface and single bytes
@ -880,10 +884,11 @@ serial ports. Today they are commonly used for the control of
external devices (including automation for both industry and the
home). They can connect to computer servers for the purpose of
monitoring/controlling the server from a remote location. They were
once mainly used for connecting up many terminals and/or modems to
serial ports. They are still used this way but today most modems are
internal digital modems (often called something else) and they don't
usually use multiport serial cards.
once mainly used for connecting up many dumb terminals and/or modems
to serial ports. Today, use of dumb terminals has declined, and
several modems (or digital modems) can now be built into
an internal card. So multiport serial cards are not as significant as
they once were.
Each multiport card has a number of external connecters (DB-25 or
RJ45) so that one may connect up a number of devices (modems,
@ -997,9 +1002,9 @@ linux# ./MAKEDEV ttyS17
For the names and numbers of other types of serial ports other than
ttyS.. see devices.txt in the kernel documentation. Besides the
listing of various brands of multiports found in this HOWTO there is
<url url="http://members.aa.net/~swear/pedia/serialcards.html"
name="Gary's Encyclopedia - Serial Cards">. It's not as complete, but
may have some different links.
<url url="http://eupedia.org/serialcards.html" name="Gary's
Encyclopedia - Serial Cards">. It's not as complete, but may have
some different links.
<sect1>Standard PC Serial Cards
@ -1018,8 +1023,8 @@ Here's a list of a few popular brands:
<itemize>
<item>Byte Runner (may order directly, shows prices) <url
url="http://www.byterunner.com">
<item> SIIG <url url="http://www.siig.com/io">
<item> Dolphin <url url="http://www.dolphinfast.com/sersol/">
<item> SIIG <url url="http://www.siig.com/products/io/">
<item> Dolphin <url url="http://www.dolphinfast.com/sersol.html">
</itemize>
<p>
Note: due to address conflicts, you may not be able to use COM4 and
@ -1124,37 +1129,37 @@ driver status: for 2.2 kernel. Supported by Chase.
<item>Computone IntelliPort II (ISA, PCI and EISA busses up to 64
ports)<newline>
webpage: <url url="http://www.computone.com"><newline>
driver location:
<url url="ftp://ftp.computone.com/PUB/Products/IntelliPortII/Linux/">,
patch at <url
driver location: old patch at <url
url="http://www.wittsend.com/computone/linux-2.2.10-ctone.patch.gz"><newline>
mailing list: <url url="mailto:majordomo@lazuli.wittsend.com"> with
"subscribe linux-computone" in body<newline>
note: Old ATvantage and Intelliport cards are not supported by Computone
<item> Connecttech<newline>
website: <tt><url url="http://www.connecttech.com/products/products.html"></tt><newline>
website: <tt><url url="http://www.connecttech.com/"></tt><newline>
driver location: <url url="ftp://ftp.connecttech.com/pub/linux/">
<item>Cyclades<newline>
Cyclom-Y (Cirrus Logic CD1400 UARTs; 8 - 32 ports),<newline>
Cyclom-Z (MIPS R3000; 8 - 64 ports)<newline>
website: <tt><url url="http://www.cyclades.com/products.html"></tt><newline>
website: <tt><url
url="http://www.cyclades.com/products/svrbas/zseries.php"></tt><newline>
driver status: supported by Cyclades<newline>
driver location: <tt><htmlurl url="ftp://ftp.cyclades.com/pub/cyclades"
name="ftp://ftp.cyclades.com/pub/cyclades"></tt> and included in Linux
kernel since version 1.1.75: cyclades.o
<item>Decision PCCOM (2-8 ports; ISA and PCI; AKA PC COM)<newline>
<item>Decision PCCOM (2-8 ports; ISA and PCI; aka PC COM)<newline>
ISA:<newline>
contact: <tt><url url="mailto:info@cendio.se"></tt><newline>
driver location: <tt><htmlurl url="ftp://ftp.signum.se/pub/pccom8"
driver location: (dead link) <tt><htmlurl url="ftp://ftp.signum.se/pub/pccom8"
name="ftp://ftp.signum.se/pub/pccom8"></tt><newline>
PCI:<newline>
drivers: <url url="http://www.decision.com.tw"> Click "download"<newline>
drivers: <url url="http://www.decision.com.tw"><newline>
driver status: Support in serial driver 5.03. For an earlier driver,
there exists a patch for kernel 2.2.16 at <url
url="http://www.qualica.com/serial/">
url="http://www.qualica.com/serial/"> and for kernels 2.2.14-2.2.17
at<url url="htp://www.pccompci.com/mains/installing_pci_linux1.html">
<item>Digi PC/Xi (12.5MHz 80186; 4, 8, or 16 ports),<newline>
PC/Xe (12.5/16MHz 80186; 2, 4, or 8 ports),<newline>
@ -1306,7 +1311,7 @@ to view the current status if you're having problems.
See the section <ref id="stty_" name="Stty">
<sect>Locating the Serial Port: IO address, IRQs <label id="locate_port">
<!-- configure.H begin (in MM, SS)
<!-- locate.H begin (in MM, SS)
<sect>Configuring the Serial Port
Change-log:
Aug. 2001: removed mention of patch to convert Linux to a PnP OS;
@ -1986,31 +1991,35 @@ new devfs). The serial port ttySx (x=0,1,2, etc.) has major number 4.
You may see this (and the minor numbers too) by typing: "ls -l ttyS*"
in the /dev directory.
There formerly was an alternate name for each serial port. For
example, ttyS2 would have cua2 as an alternate name. You may still
have the cua devices in your /dev directory but they are now
deprecated. Their drivers behave slightly different than for the ttyS
ones. Device Obsolete">."') See the Modem-HOWTO
section: "cua Device Obsolete">.
There formerly was a "cua" name for each serial port and it behaved
just a little differently. For example, ttyS2 would correspond to
cua2. The cua major number was 5 and minor numbers started at 64.
You may still have the cua devices in your /dev directory but they are
now deprecated. Their drivers behave slightly different than for the
ttyS ones. name="cua Device Obsolete">."') See the Modem-HOWTO section: "cua Device
Obsolete">.
Dos/Windows use the COM name while the <tt/setserial/ program uses
tty00, tty01, etc. Don't confuse these with dev/tty0, dev/tty1, etc.
which are used for the console (your PC monitor) but are not serial
ports. The table below is for the "standard" case (but yours could be
different).
different). The major/minor numbers don't exist with the devfs.
<tscreen><verb>
IO devfs
dos major minor major minor address name
COM1 /dev/ttyS0 4, 64; /dev/cua0 5, 64 3F8 /dev/tts/0
COM2 /dev/ttyS1 4, 65; /dev/cua1 5, 65 2F8 /dev/tts/1
COM3 /dev/ttyS2 4, 66; /dev/cua2 5, 66 3E8 /dev/tts/2
COM4 /dev/ttyS3 4, 67; /dev/cua3 5, 67 2E8 /dev/tts/3
ISA IO devfs usb
dos major minor address devfs devfs usb acm modem
COM1 /dev/ttyS0 4, 64; 3F8 /dev/tts/0 /dev/usb/tts/0 /dev/usb/acm/0
COM2 /dev/ttyS1 4, 65; 2F8 /dev/tts/1 /dev/usb/tts/1 /dev/usb/acm/1
COM3 /dev/ttyS2 4, 66; 3E8 /dev/tts/2 /dev/usb/tts/2 /dev/usb/acm/2
COM4 /dev/ttyS3 4, 67; 2E8 /dev/tts/3 /dev/usb/tts/3 /dev/usb/acm/3
</verb></tscreen>
<sect1> Universal Serial Bus Ports
<p> Although the USB is not covered in this HOWTO, the serial ports on
the USB are: /dev/ttyUSB0 /dev/ttyUSB1, etc.
<sect1> USB (Universal Serial Bus) Ports
<p>The serial ports on the USB are: /dev/ttyUSB0, /dev/ttyUSB1, etc.
The devfs names for these are: /dev/usb/tts/0, /dev/usb/tts/1, etc.
For many modems they are /dev/usb/acm/0, etc. (in devfs notation).
For more info see the usb subdirectory in the kernel documentation
directory for files: acm and usb-serial.
<sect1> Link ttySN to /dev/modem
<p> On some installations, two extra devices will be created,
@ -2764,21 +2773,22 @@ section is unique to each HOWTO.
<p> The top speed of 115.2k has been standard since the mid 1990's.
But by the year 2000, most new serial ports supported higher speeds of
230.4k and 460.8k. Some also support 921.6k. Unfortunately Linux
seldom uses these speeds due to lack of drivers. These ports behave
just like 115.2k ports unless the higher speeds are enabled by special
software. To get these speeds you need to compile the kernel with
special patches but it seems that the 2.4 kernels not yet supported
seldom uses these speeds due to lack of drivers. Thus such ports
behave just like 115.2k ports unless the higher speeds are enabled by
special software. To get these speeds you need to compile the kernel
with special patches but it seems that the 2.4 kernels are not yet
supported
The patch software is fairly simple since it only needs to enable the
higher speeds by dialog with the hardware. But it's not quite as
simple as just putting an enable byte in a hardware register since the
registers weren't designed for this. But unfortunately, there is no
standard way to enable the higher speeds so the driver needs to
standard way to enable the higher speeds so the serial driver needs to
support a variety of hardware.
A patch to support high-speed is called shsmod (Super High Speed
Mode). There are both Windows and Linux versions of this patch. See
<url url="http://www.devdrv.com/shsmod">. For Linux (as of late
<url url="http://www.devdrv.com/shsmod/">. For Linux (as of late
2001), most of the documentation is only in Japanese and the patch is
for the old kernel 2.2.x. There is also a module for the VIA
VT82C686 chip <url url="http://www.kati.fi/viahss/">. Using it may
@ -2790,18 +2800,27 @@ Does shsmod support these ??
<sect2> How speed is set in hardware: the divisor and baud_base <label
id="divisor_">
<p> Here's a list of commonly used divisors and their corresponding
speeds (assuming a maximum speed of 115,200): 1 (115.2k), 2 (57.6k), 3
(38.4k), 6 (19.2k), 12 (9.6k), 24 (4.8k), 48 (2.4k), 96 (1.2k), etc.
The serial driver sets the speed in the hardware by sending the
hardware only a "divisor" (a positive integer). This "divisor"
divides the maximum speed of the hardware resulting in a slower speed
(except a divisor of 1 obviously tells the hardware to run at maximum
speed).
<p> Speed is set by having the serial port's clock change frequency.
But this change happens not by acutally changing the frequency of the
oscillator driving the clock but by "dividing" the clock's frequency.
For example, to divide by two, just ignore every other clock tick.
This cuts the speed in half. Dividing by 3 makes the clock run at 1/3
frequency, etc. So to slow the clock down (meaning set speed), we
just send the clock a divisor. It's sent by the serial driver to a
register in the port. Thus speed is set by a divisor.
If the clock runs at a top speed of 115,000 bps (common), then here
are the divisors for various speeds (assuming a maximum speed of
115,200): 1 (115.2k), 2 (57.6k), 3 (38.4k), 6 (19.2k), 12 (9.6k), 24
(4.8k), 48 (2.4k), 96 (1.2k), etc. The serial driver sets the speed
in the hardware by sending the hardware only a "divisor" (a positive
integer). This "divisor" divides the "maximum speed" of the hardware
resulting in a slower speed (except a divisor of 1 obviously tells the
hardware to run at maximum speed).
There are exceptions to the above since for certain serial port
hardware, speeds above 115.2k are set by using a very high divisor.
Bear that exception in mind as you read the rest of this section.
Keep that exception in mind as you read the rest of this section.
Normally, if you specify a speed of 115.2k (in your communication
program or by stty) then the serial driver sets the port hardware to
divisor 1 which sets the highest speed.
@ -3132,27 +3151,28 @@ signal (positive or negative voltage). Still others have jumpers so
that you can connect any wire to any wire. Some have switches.
Radio Shack sells (in 2001) a "RS-232 Troubleshooter" (formerly called
"RS-232 Line Tester") which checks TD, RD, CD, RTS, CTS, DTR, and DSR.
A green light means on (+12 v) while red means off (-12 v). They also
sell a "RS-232 Serial Jumper Box" which permits connecting the pins
anyway you choose. You will likely need to order them from the catalog
where you may find them by checking the Index under "Tools, D-Sub
Connection Pin ...". The two items mentioned are not "tools" but
they appear on a page with tools.
"RS-232 Line Tester") Cat. #276-1401. It checks TD, RD, CD, RTS,
CTS, DTR, and DSR. A green light means on (+12 v) while red means
off (-12 v). They also sell a "RS-232 Serial Jumper Box" Cat.
#276-1403. This permits connecting the pins anyway you choose. Both
these items are under the heading of "Peripheral hookup helpers".
Unfortunately, they are not listed in the index to the printed
catalog. They are on the same page as the D type connecters so
look in the index under "Wire &amp; Cable, Connectors. Or look
under "Tools, D-Sub Connection Pin ...". A store chain named "Active Component
<sect2> Measuring voltages
<p> Any voltmeter or multimeter, even the cheapest that sells for
about $10, should work fine. Trying to use other methods for
checking voltage is tricky. Don't use a LED unless it has a series
resistor to reduce the voltage across the LED. A 470 ohm resistor is
used for a 20 ma LED (but not all LED's are 20 ma). The LED will
only light for a certain polarity so you may test for + or - voltages.
Does anyone make such a gadget for automotive circuit testing?? Logic
probes may be damaged if you try to use them since the TTL voltages
for which they are designed are only 5 volts. Trying to use a 12 V
incandescent light bulb is not a good idea. It won't show polarity
and due to limited output current of the UART it probably will not
even light up.
about $10, should work fine. Trying to use other methods for checking
voltage is tricky. Don't use a LED unless it has a series resistor to
reduce the voltage across the LED. A 470 ohm resistor is used for a
20 ma LED (but not all LED's are 20 ma). The LED will only light for
a certain polarity so you may test for + or - voltages. Does anyone
make such a gadget for automotive circuit testing?? Logic probes may
be damaged if you try to use them since the TTL voltages for which
they are designed are only 5 volts. Trying to use a 12 V incandescent
light bulb is not a good idea. It won't show polarity and due to
limited output current of the UART it probably will not even light up.
To measure voltage on a female connector you may plug in a bent paper
clip into the desired opening. The paper clip's diameter should be no
@ -3365,7 +3385,7 @@ is supposedly being used by another device (the resource is "busy").
This message is easy to understand if it only means that the device is
busy (in use). But it often means that a resource is in use. What
makes it even more confusing is that in some cases neither the device
not the resources that it needs are actually "busy".
nor the resources that it needs are actually "busy".
The ``resource busy'' part often means (example for <tt/ttyS2/) ``You
can't use <tt/ttyS2/ since another device is using ttyS2's
@ -3394,10 +3414,12 @@ There are two possible cases when you see this message:
What you need to do is to find the interrupt setserial thinks
<tt/ttyS2/ is using. Look at /proc/tty/driver/serial (if you have
it). You should also be able to find it with the "setserial" command
for <tt/ttyS2/. But due to a bug (reported by me in Nov. 2000) you
get the same "... busy" error message when you try this with
"setserial".
it). You should also be able to see it with the "setserial" command
for <tt/ttyS2/.
Bug in old versions: Prior to 2001 there was a bug which wouldn't let
you see it with "setserial". Trying to see it would give the same
"... busy" error message.
To try to resolve this problem reboot or: exit or gracefully kill all
likely conflicting processes. If you reboot: 1. Watch the boot-time
@ -3413,8 +3435,7 @@ correct (the same as set in the hardware). A way to test whether or
not it's a potential interrupt conflict is to set the IRQ to 0
(polling) using "setserial". Then if the busy message goes away, it
was likely a potential interrupt conflict. It's not a good idea to
leave it permanently set at 0 since it will make the CPU work too
hard.
leave it permanently set at 0 since it will put more load on the CPU.
<sect1> "Input/output error" from setserial or stty
<p> You may have typed "ttys" instead of "ttyS". You will see this
@ -3426,7 +3447,10 @@ serial port at the IO address that setserial thinks your port is at.
<sect1> Overrun errors on serial port
<p> This is an overrun of the hardware FIFO buffer and you can't
increase its size. See
increase its size. Bug note (reported in 2002): Due to a bug in some
kernel 2.4 versions, the port number may be missing and you will only
see "ttyS" (no port number). But if devfs notation such as "tts/2" is
being used, there is no bug. See
@ -4423,3 +4447,6 @@ the Internet (few retail stores stock them today) or find a used one.
<p> END OF Serial-HOWTO
</article>
___________________________________
thanks for submitting into linuxdoc