From d8199a49bb181848ddfa005cf969dc23ad99cae9 Mon Sep 17 00:00:00 2001 From: gferg <> Date: Mon, 20 Feb 2006 14:00:14 +0000 Subject: [PATCH] updated --- LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml | 2 +- LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml | 2 +- LDP/howto/linuxdoc/Serial-HOWTO.sgml | 872 +++++++++++-------- 3 files changed, 506 insertions(+), 370 deletions(-) diff --git a/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml b/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml index 5fbb8474..77f2a542 100644 --- a/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml +++ b/LDP/howto/docbook/HOWTO-INDEX/howtoChap.sgml @@ -3961,7 +3961,7 @@ Addresses Linux localization issues specific to Serbian users Serial-HOWTO, Serial HOWTO -Updated: Nov 2004. +Updated: Feb 2006. 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 diff --git a/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml b/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml index 6844a0f4..ae604e60 100644 --- a/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml +++ b/LDP/howto/docbook/HOWTO-INDEX/hwSect.sgml @@ -1143,7 +1143,7 @@ writers may need to know. Serial-HOWTO, Serial HOWTO -Updated: Nov 2004. +Updated: Feb 2006. 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 diff --git a/LDP/howto/linuxdoc/Serial-HOWTO.sgml b/LDP/howto/linuxdoc/Serial-HOWTO.sgml index 28bcbf5b..01756468 100644 --- a/LDP/howto/linuxdoc/Serial-HOWTO.sgml +++ b/LDP/howto/linuxdoc/Serial-HOWTO.sgml @@ -1,13 +1,16 @@ -
Serial HOWTO <author>David S.Lawyer <tt><htmlurl url="mailto:dave@lafn.org" name="dave@lafn.org"></tt> original by Greg Hankins -<date> v2.23 November 2004 +<date> v2.24 February 2006 <!-- Change log: +2.24 Feb. 2006: Serial Laplink HOWTO (connecting 2 PCs via the +serial line), Fixed typos found by Charles Brockman. Messages with +"ttyS01" now show it as "ttyS1, etc". +v2.23 Links to Vern's stuff on my website, serlook, use mouse to find port v2.23 Nov. 2004: typo fixed, Quick Help added, Serial ports on motherboard likely ISA or LPC v2.22 Dec. 2003: revised Complex Flow Control Example, more on devfs @@ -71,32 +74,35 @@ v1.0: June 1993: was called Serial FAQ, by Greg Hankins <p> This HOWTO covers basic info on the Serial Port and multiport serial cards. It contains much more information in it than most -people need to know and most people are able to use it without reading -this HOWTO. But if you're having problems or just want to understand -how it works, this is one place to find out about it. +people need to know and most people are able to use the serial port +without reading this HOWTO. But if you're having problems or just +want to understand how it works, this is one place to find out about +it. -This HOWTO is about the original serial port which uses a UART chip -and is sometimes called a "UART serial port" to differentiate it from -the newer Universal Serial Bus. Information specific to modems and -text-terminals is found in Modem-HOWTO and Text-Terminal-HOWTO. Info -on getty (the program that runs the login process or the like) has -been also moved to these HOWTOs since mgetty and uugetty are best for -modems while agetty is best for text-terminals. If you are dealing -with a modem, text terminal, or printer, then you may not need to -consult this HOWTO. But if you are using the serial port for some -other device, using a multiport serial card, trouble-shooting the -serial port itself, or want to understand more technical details of -the serial port, then you may want to use this HOWTO as well as some -of the other HOWTOs. (See <ref id="related_howtos" name="Related -HOWTO's">) This HOWTO lists info on various multiport serial cards -since they may be used for either modems or text-terminals. This -HOWTO addresses Linux running on PCs (ISA and/or PCI buses), although -it might be valid for other architectures. +This HOWTO is about the slow original serial port which uses a UART +chip and is sometimes called a "UART serial port" to differentiate it +from the newer types of serial devices: Universal Serial Bus or +Firewire. Information specific to devices which use serial ports: +modems, text-terminals, infrared devices, and a few printers are found +in Modem-HOWTO, Text-Terminal-HOWTO, Infrared-HOWTO, and +Printing-HOWTO. Info on getty (the program that runs the login +process or the like) has been also moved to other HOWTOs since mgetty +and uugetty are best for modems while agetty is best for +text-terminals. If you are dealing with a modem, text terminal, +infrared device, or printer, then you may not need to consult this +HOWTO. But if you are using the serial port for some other device, +using a multiport serial card, trouble-shooting the serial port +itself, or want to understand more technical details of the serial +port, then you may want to use this HOWTO as well as some of the other +HOWTOs. (See <ref id="related_howtos" name="Related HOWTO's">) This +HOWTO lists info on various multiport serial cards. This HOWTO +addresses Linux running on PCs (ISA and/or PCI buses), although it +might be valid for other architectures. <sect1> Copyright, Disclaimer, & Credits <sect2>Copyright <p> -Copyright (c) 1993-1997 by Greg Hankins, (c) 1998-2003 by David S. +Copyright (c) 1993-1997 by Greg Hankins, (c) 1998-2005 by David S. Lawyer <url url="mailto:dave@lafn.org"> <!-- license.D begin --> @@ -141,7 +147,9 @@ everyone who has contributed or commented, the list of people has gotten too long to list (somewhere over one hundred). Special thanks to Ted Ts'o for answering questions about the serial drivers.'' Approximately half of v2.00 was from Greg Hankins HOWTO and the other -half is by David Lawyer. Ted Ts'o has continued to be helpful. +half were additions by David Lawyer. Ted Ts'o has continued to be +helpful. In Jan. 2006 "Charles Brockman" reviewed it for typos which +resulted in many typos being fixed. <sect1> New Versions of this Serial-HOWTO <p> New versions of the Serial-HOWTO will be available to @@ -150,7 +158,7 @@ sites see: <url url="http://www.tldp.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.tldp.org/HOWTO/Serial-HOWTO.html"> and compare -it to this version: v2.23 November 2004 . +it to this version: v2.24 February 2006 . <sect1>New in Recent Versions <p> For a full revision history going back to the time I started @@ -159,6 +167,9 @@ maintaining this HOWTO, see the source file (in linuxdoc format) at url="http://www.ibiblio.org/pub/linux/docs/HOWTO/other-formats/sgml/Serial-HOWTO.sgml.gz">. <itemize> +<item>v2.24 Feb. 2006: Serial Laplink HOWTO (connecting 2 PCs via the +serial line), Fixed typos found by Charles Brockman. Messages with +"ttyS01" now show it as "ttyS1"<item>, etc. <item>v2.23 Nov. 2004: typo fixed, Quick Help added, Serial ports on motherboard likely ISA or LPC <item>v2.22 Dec. 2003: revised Complex Flow Control Example, more on devfs @@ -201,10 +212,12 @@ what you don't understand, or what could be clearer. You can reach me via email at <tt><url url="mailto:dave@lafn.org"></tt>. <sect1> What is a Serial Port? -<p> The conventional serial port (not the newer USB port, or HSSI -port) is a very old I/O port. Almost all Desktop PC's have them. +<p> The conventional serial port (not the newer USB port, or Firewire +port) is a very old I/O (Input/Output) port. Most Desktop PC's have +them. For laptops, they're not likely to be present on newer models. Macs (Apple Computer) after mid-1998 only have the USB port. However, -it's possible, to put a conventional serial port device on the USB. +it's possible, to put a conventional serial port device on the USB bus +which is on all modern PCs (including laptops and Macs). Each serial port has a "file" associated with it in the /dev directory. It isn't really a file but it seems like one. For @@ -257,7 +270,9 @@ They could be shown in a menu dealing with Resources, Plug-and-Play, Peripherals, Ports, etc. Some old BIOSs setups (before 1995 ?) didn't deal with the serial ports. Make sure the ports you need are not disabled and note how they are configured (like 3F8 IRQ 4). You may -need to change the configuration to prevent conflicts. +need to change the configuration to prevent conflicts. There could be +a shortage of IRQs if the BIOS has reserved some IRQs that it didn't +need to reserve. For serial ports to be found, either the kernel must have been compiled with serial support, or serial support must be provided by a @@ -275,11 +290,11 @@ understand since it's similar. The first explanation given here will be grossly oversimplified. Then more detail will be added in later explanations. When the computer wants to send a byte out the serial port (to the external cable) the CPU sends the byte on the bus inside -the computer to the I/O address of the serial port. The serial port -takes the byte, and sends it out one bit at a time (a serial -bit-stream) on the transmit pin of the serial cable connector. For what a -bit (and byte) look like electrically see <ref id="volt_shape" -name="Voltage Waveshapes">. +the computer to the I/O (Input Output) address of the serial port. +I/O is often written as just IO. The serial port takes the byte, and +sends it out one bit at a time (a serial bit-stream) on the transmit +pin of the serial cable connector. For what a bit (and byte) look +like electrically see <ref id="volt_shape" name="Voltage Waveshapes">. Here's a replay of the above in a little more detail (but still very incomplete). Most of the work at the serial port is done by the UART @@ -416,7 +431,7 @@ Feb. '02 4k buffer -> 8k Feb. '03: UARTs with auto flow control. Rewrite of Flow Control. Mar. '03: Flip buffer (the 4th buffer) Apr. '03: flow control clarity, RTS -> CTS re modems -Nov. '04: Better clarity re Data Flow +Nov. '04: Better clarity re Data Flow, Winmodem support --> @@ -455,9 +470,7 @@ transmit pin (and conversely). Most of the electronics of the serial port is found in a computer chip (or a part of a chip) known as a UART. For more details on UARTs see the section - -<ref id="uart_" name="What Are UARTS?"> -But you may want to finish this section first so that you will +<ref id="uart_" name="What Are UARTS?"> But you may want to finish this section first so that you will hopefully understand how the UART fits into the overall scheme of things. @@ -549,7 +562,7 @@ corresponds to say ttyS1 depends both on what the serial driver thinks (per setserial) and what is set in the hardware. If a mistake has been made, the physical port may not correspond to any name (such as ttyS2) and thus it can't be used. See <ref id="ttySN_" name="Serial -Port Devices /dev/ttyS2, etc."> for more details> +Port Devices /dev/ttyS2, etc."> for more details. <sect1> Interrupts <label id="interrupt_"> <p> @@ -604,7 +617,7 @@ the serial port. That program is called an interrupt service routine happened at the serial port and then deals with the problem such a transferring bytes from (or to) the serial port's hardware buffer. This program can easily find out what has happened since the serial -port has registers at IO addresses known to the the serial driver +port has registers at IO addresses known to the serial driver software. These registers contain status information about the serial port. The software reads these registers and by inspecting the contents, finds out what has happened and takes appropriate action. @@ -957,12 +970,12 @@ See <ref id="set_serial" name="What is Setserial"> for more info on <sect> Is the Serial Port Obsolete? <sect1> Introduction -<p> The answer is yes, but ... The serial port is somewhat obsolete -(and often called a "legacy" device, 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. Linux supports ordinary analog modems -only if they work thru a serial port (although the port may be built -into the modem). +<p> The serial port is somewhat obsolete (and often called a "legacy" +device, but it's still important, especially for Linux. The serial port +has many shortcomings but most new PC's (except for laptops and Macs) +seem to come with them. Some PC's, called "legacy-free" don't have +serial ports. Linux supports ordinary analog modems only if they work +thru a serial port (although the port may be built into the modem). The physical serial port on the back of a PC, must pass data between the computer and an external cable. Thus it has two interfaces: the @@ -993,16 +1006,18 @@ the "Cable Conference", RS-232 failed to utilize it. Since RS-232 was originally designed for connecting a terminal to a low speed modem located nearby, the need for high speed and longer distance transmission was apparently not recognized. The result was that since -the serial port couldn't handle high speeds new types of serial +the serial port couldn't handle high speeds, new types of serial interfaces were devised that could: Ethernet, USB, Firewire, etc. -<sect1> Inefficient Interface to the Computer (in some cases) +<sect1> Inefficient PCI Interface to the Computer (in some cases) -<p> The serial port communicates with the computer via the PCI bus (or -the LPC or ISA bus). The PCI bus is now 32 or 64 bits wide, but the -serial port only sends a byte at a time (8 bits wide) which is a waste -of PCI bus bandwidth. Not so for the LPC bus which has only a 4-bit -wide bus and thus provides an efficient interface. +<p> The serial port communicates with the computer via the PCI bus, +the LPC bus, X-bus, or ISA bus. The PCI bus is now 32 or 64 bits wide, +but the serial port only sends a byte at a time (8 bits wide) which is +a waste of PCI bus bandwidth. Not so for the LPC bus which has only a +4-bit wide bus and thus provides an efficient interface. The ISA bus +is usually 16-bits wide and the efficiency is intermediate as compared +to efficient LPC and inefficient PCI. <sect> Multiport Serial Boards/Cards/Adapters <sect1> Intro to Multiport Serial @@ -1260,7 +1275,7 @@ There are many different brands, each of which often offers many different cards. No attempt is currently being made to list all the cards here (and many listed are obsolete). But all major brands and websites should be shown here so it something is missing let me know. -Go the the webpage shown for more information. These websites often +Go the webpage shown for more information. These websites often also have info (ads) on related hardware such as modem pools, remote access servers (RASs), and terminal servers. Where there is no webpage, the cards are likely obsolete. If you would like to put @@ -1499,7 +1514,7 @@ assigning each port an IO address, IRQ, and name (such as ttyS2). This IO-IRQ pair must be set in both the hardware and told to the serial driver. We might just call this "io-irq" configuring for short. The "setserial" program is sometimes used to tell the driver. PnP -methods, jumpers, etc, are used to set the I0 and IRQ in the hardware. +methods, jumpers, etc, are used to set the IO and IRQ in the hardware. Details will be supplied later. If you need to configure but don't understand certain details it's easy to get into trouble. See <ref id="locate_port" name="Locating the Serial Port: IO address IRQs"> @@ -1536,26 +1551,26 @@ the card inserts into (usually a PCI slot). But if the serial port is built into the motherboard it may not be clear what bus it's on. For old motherboards that have ISA bus slots, it's likely on the ISA bus and may not even be Plug-and-Play. But even if all your slots are -PCI, the serial port is not likely to be PCI. It may still be ISA, or -it might be on a LPC bus (also called a "LPC interface"). LPC is -common on laptop computers. Type "lspci" to see if it shows "LPC". -Unfortunately, the LPC bus has no standard Plug-and-Play method for -low-level configuring devices on it. One way to deal with it is to -hope that the BIOS can configure them. Some Linux developers are -aware of the problem (in late 2004) and Linux may support LPC better -in the future. +PCI, the serial port is likely to be on either the ISA bus or LPC bus +(also called a "LPC interface"). LPC is common on laptop computers. +Type "lspci" to see if it shows "LPC". Unfortunately, the LPC bus has +no standard Plug-and-Play method for low-level configuring devices on +it. One way to deal with it is to hope that the BIOS can configure +them using ACPI. Some Linux developers are aware of the problem (in +late 2004) and Linux may support the LPC bus better in the future. +To see if you have a LCP bus, type "lspci" and look for a LPC bridge. <sect1> IO & IRQ Overview <p> For a serial port to work properly it first must be given both an IO address and an IRQ. For old hardware (of mid 1990s), jumpers on a -card or the a saved BIOS setting does it. For newer hardware the BIOS +card or the saved BIOS setting does it. For newer hardware the BIOS or Linux must set them at boot-time, and the new hardware doesn't -remember how it was set once it's powered Enabling hardware it gives -it both an IRQ and an IO address. Without an IO address, it can't be -used. Without an IRQ it will need to use inefficient polling methods -for which one must set the IRQ to 0 in the serial driver. In olden -days IRQs and IO addresses were set by jumpers or switches on a serial -port card. Today these are set by digital signals sent to the +remember how it was set once it's powered down. Enabling hardware +gives it both an IRQ and an IO address. Without an IO address, it +can't be used. Without an IRQ it will need to use inefficient polling +methods for which one must set the IRQ to 0 in the serial driver. In +olden days IRQs and IO addresses were set by jumpers or switches on a +serial port card. Today these are set by digital signals sent to the hardware by the BIOS or Linux. It all should get configured automatically (provided the BIOS has not been previously set up to disable it) so that you only need to read this if you're having @@ -1610,9 +1625,9 @@ then you need to do it if you: Starting with kernel 2.2 you may be able to use more that 2 serial ports without doing any low-level configuring by sharing interrupts. -All PCI ports should support this but for ISA, it only works for some +All PCI ports should support this but for ISA it only works for some hardware. It may be just as easy to give each port a unique interrupt -if they is available. See <ref id="int_share-2.2" name="Interrupt +if they are available. See <ref id="int_share-2.2" name="Interrupt sharing and Kernels 2.2+"> The low-level configuring (setting the IRQ and IO address) seems to @@ -1667,17 +1682,16 @@ While kernel 2.2 supported PCI in general, it had no support for PCI serial ports (although some people got them working anyway). Starting with kernel 2.4, the serial driver will read the id number digitally stored in the serial hardware to determine how to support it (if it -knows how). It should assign an I/O address to it, determine it's +knows how). It should assign an I/O address to it, determine its IRQ, etc. So you don't need to use "setserial" for it. There is a possible problem if you don't use the device filesystem. -The driver may assign the port to say "<tt/ttyS04" per a boot-time -message (use <tt/dmesg/ to see it). But if you don't have a "file" /dev/ttyS4 -then the port will not work. So you will then need to create it, -using<newline> -<tt>cd /dev</tt> and then <tt>./MAKEDEV ttyS4</tt><newline> -For the device filesystem, the driver should create the device -<tt>tts/1</tt> +The driver may assign the port to say tt/ttyS4 per a boot-time +message (use <tt/dmesg/ to see it). But if you don't have a "file" +/dev/ttyS4 then the port will not work. So you will then need to +create it, using<newline> +<tt>cd /dev; ./MAKEDEV ttyS4</tt><newline> +For the device filesystem, the driver should create the device <tt>tts/1</tt> <!-- <sect2> Requesting that future drivers support your serial port @@ -1786,23 +1800,25 @@ Use Shift-PageUp to scroll back to the messages after they have flashed by. Shift-PageDown will scroll in the opposite direction. The <tt/dmesg/ command (or looking at logs in /var/log) will show only the first of these two messages. Here's an example of the start-up -messages (as of 2004, almost the same as for 1999). Note that ttyS00 -is the same as /dev/ttyS0, etc. +messages (as of 2004, almost the same as for 1999). Note that in +older versions ttyS1 was displayed in these messages as ttyS01, etc. -<tscreen><verb> At first you see what was detected (but the irq is only a wild guess): +<tscreen><verb> Serial driver version 4.27 with no serial options enabled -ttyS00 at 0x03f8 (irq = 4) is a 16550A -ttyS01 at 0x02f8 (irq = 3) is a 16550A -ttyS02 at 0x03e8 (irq = 4) is a 16550A -ttyS04 at port 0xeff0 (irq = 10) is a 16550A +ttyS0 at 0x03f8 (irq = 4) is a 16550A +ttyS1 at 0x02f8 (irq = 3) is a 16550A +ttyS2 at 0x03e8 (irq = 4) is a 16550A +ttyS4 at port 0xeff0 (irq = 10) is a 16550A +</verb></tscreen> Note that ttyS0-ttyS2 were detected by probing the standard addresses while ttyS4 is a PCI port detected by probing the PCI configuration. Later setserial shows you what was saved in a configuration file (which you may edit), but it's not necessarily correct either: +<tscreen><verb> Loading the saved-state of the serial devices... /dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A /dev/ttyS2 at 0x03e8 (irq = 5) is a 16550A @@ -1835,12 +1851,12 @@ The first message is a result of Linux probing the ISA serial port addresses but it doesn't probe for IRQs. If a port shows up here it exists but the IRQ may be wrong. Linux doesn't check IRQs because doing so is not foolproof. It just assumes the IRQs are as shown -because they are the "standard" values. Your may check them manually +because they are the "standard" values. You may check them manually with <tt/setserial/ using the <tt/autoconfig/ and <tt/auto_irq/ options but this isn't guaranteed to be correct either. The data shown by the BIOS messages (which you see at first before -Linux is booted) is what is initially set in the hardware. If your +Linux is booted) are what is initially set in the hardware. If your serial port is Plug-and-Play (PnP) then it's possible that "isapnp" or "setpci" will run and change these settings. Look for messages about this after Linux starts. The last serial port message shown in the @@ -2141,7 +2157,7 @@ possible methods of configuring PnP serial ports: <item> Letting a PnP BIOS automatically configure a PnP serial port See <ref id="bios_conf" name="Using a PnP BIOS to I0-IRQ Configure"> <item> Doing nothing if the serial driver recognized your card OK -<item> Using <tt/isapnp/ for a PnP serial port non-PCI) +<item> Using <tt/isapnp/ for a PnP serial port (non-PCI) <item> Using setpci (pciutils or pcitools) for the PCI bus </itemize> @@ -2156,7 +2172,7 @@ thinking that Windows is not a PnP OS. See Plug-and-Play-HOWTO. Plug-and-Play (PnP) was designed to automate this io-irq configuring, but for Linux it initially made life much more complicated. In modern Linux (2.4 kernels --partially in 2.2 kernels), each device driver has -to do it's own PnP (using supplied software which it may utilize). +to do its own PnP (using supplied software which it may utilize). There is unfortunately no centralized planning for assigning IO addresses and IRQs as there is in MS Windows. But it usually works out OK in Linux anyway. @@ -2245,7 +2261,9 @@ for hardware flow control for port ttyS2: <tscreen><verb> stty crtscts < /dev/ttyS2 +</verb></tscreen> or for stty version >= 1.17: +<tscreen><verb> stty -F /dev/ttyS2 crtscts </verb></tscreen> @@ -2278,7 +2296,7 @@ plugging. With all this confusion, most distributions use neither devfs nor udev. If you use devfs or udev, ttyS1 becomes tts/1, ttyUSB1 becomes -/usb/tts/1, and ttyACM1 is /usb/acm/1. Note that the the number 1 +/usb/tts/1, and ttyACM1 is /usb/acm/1. Note that the number 1 above is just an example. It could be replaced by 0, 2, 3, 4, etc. One may use devfs but have the conventional names linked (via symlinks) to the new names. So they use the new system with the old names but @@ -2301,7 +2319,7 @@ serial/parallel ports and floppy drives. <sect1>Devfs (The Device File System) <p>In kernel 2.4 the devfs was created only to be obsoleted in favor -of udev in kernel 2.6. devfs creased a new system of device naming +of udev in kernel 2.6. devfs created a new system of device naming which was continued with udev. The naming system makes it easier to deal with a huge number of devices. But there's also a popular option to continue using the old names. However, a new device may not have @@ -2327,7 +2345,7 @@ program and the serial module isn't loaded, the kernel is supposed to try to find a driver for it and create a name for it in the /dev directory. -This is works OK if it finds a driver. But suppose there is no driver +This works OK if it finds a driver. But suppose there is no driver found for it. For example, if you try to use "setserial" to configure a port that the driver failed to detect, it claims there is no such port. How does one create a devfs port in this case? @@ -2386,7 +2404,7 @@ directory for files: usb-serial, acm, etc. <p> On some installations, two extra devices will be created, <tt>/dev/modem</tt> for your modem and <tt>/dev/mouse</tt> for a mouse. Both of these are symbolic links to the appropriate serial -device in <tt>/dev</tt> which you specified during the installation +device in <tt>/dev</tt> which you specified during the installation. Except if you have a bus mouse, then <tt>/dev/mouse</tt> will point to the bus mouse device). @@ -2398,7 +2416,8 @@ system doesn't fall into this trap so it's now OK to use such links. <!-- dev_names.D end --> -<sect1> Which Connector on the Back of my PC is ttyS1, etc? +<sect1> Which Connector on the Back of my PC is ttyS1, etc? <label +id="identify_ttyS"> <sect2> Inspect the connectors <p> Inspecting the connectors may give some clues but is often not definitive. The serial connectors on the back side of a PC are @@ -2412,27 +2431,28 @@ this may be easy. If you also have an internal modem, a program like wvdial may be able to tell you what port it's on (unless it's a PnP that hasn't been enabled yet). A report from setserial (at boot-time or run by you from the command line) should help you -identify the non-modem port. +identify the non-modem ports. -If you have two serial connectors it may be more difficult. -First check manuals (if any) for your computer. Look at the -connectors for meaningful labels. You might even want to take off the -PC's cover and see if there are any meaningful labels on the card -where the internal ribbon cables plug in. Labels (if any) are likely -to say something like "serial 1", "serial 2" or A, B. Which com port it -actually is will depend on jumper or PnP settings (sometimes shown in -a CMOS setup menu). But 1 or A are more likely to be ttyS0 with 2 or -B ttyS1. +If you have two serial ports it may be more difficult. You could have +only one serial connector but actually have 2 ports, one of which +isn't used (but it's still there electronically). First check manuals +(if any) for your computer. Look at the connectors for meaningful +labels. You might even want to take off the PC's cover and see if +there are any meaningful labels on the card where the internal ribbon +serial cables plug in. Labels (if any) are likely to say something like +"serial 1", "serial 2" or A, B. Which com port it actually is will +depend on jumper or PnP settings (sometimes shown in a BIOS setup +menu). But 1 or A are more likely to be ttyS0 with 2 or B ttyS1. <sect2> Send bytes to the port <p> Labels are not apt to be definitive so here's another method. If the serial ports have been configured correctly per setserial, then you may send some bytes out a port and try to detect which connector -(if any) it's coming out of. One way to send such a signal is to copy -a long text file to the port using a command like: cp my_file_name -/dev/ttyS1. A voltmeter connected to the DTR pin (see Serial-HOWTO -for Pinout) will display a positive voltage as soon as you give the -copy command. +(if any) they are coming out of. One way to send such a signal is to +copy a long text file to the port using a command like: cp +my_file_name /dev/ttyS1. A voltmeter connected to the DTR pin (see +Serial-HOWTO for Pinout) will display a positive voltage as soon as +you give the copy command. The transmit pin should go from several volts negative to a voltage fluctuating around zero after you start sending the bytes. If it doesn't @@ -2455,17 +2475,17 @@ may be a good way to test it as the repeating test messages halt when the jumper is removed. As a jumper you could use a mini (or micro) jumper cable (sold in some -electronic parts stores) with mini alligator clips. A scrap of paper -may be used to prevent the mini clips from accidentally touching the -metal of the connector. Metal paper clips can sometimes be bent to -use as jumpers. Whatever you use as a jumper take care not to bend or -excessively scratch the pins. To receive something from a port, you -can go to a virtual terminal (Alt-F2 for example) and type something -like "cp /dev/ttyS2 /dev/tty". Then at another virtual terminal you -may send something to ttyS2 (or whatever) by "echo test_message > -/dev/ttyS2". Then go back to the receive virtual terminal and look -for the test_message. See <ref id="ser_elect_test" name="Serial -Electrical Test Equipment"> for more info. +electronic parts stores) with mini alligator clips. A small scrap of +paper may be used to prevent the mini clips from making electrical +contact where it shouldn't. Metal paper clips can sometimes be bent +to use as jumpers. Whatever you use as a jumper take care not to bend +or excessively scratch the pins. To receive something from a port, +you can go to a virtual terminal (for example Alt-F2 and login) and +type something like "cp /dev/ttyS2 /dev/tty". Then at another virtual +terminal you may send something to ttyS2 (or whatever) by "echo +test_message > /dev/ttyS2". Then go back to the receive virtual +terminal and look for the test_message. See <ref id="ser_elect_test" +name="Serial Electrical Test Equipment"> for more info. <sect2> Connect a device to the connector <p> Another way to try to identify a serial port is to connect some @@ -2473,16 +2493,22 @@ physical serial device to it and see if it works. But a problem here is that it might not work because it's not configured right. A serial mouse might get detected at boot-time if connected. +You may put a device, such as a serial mouse (use 1200 baud), on a port +and then use minicom to communicate with that port. Then by clicking +on the mouse, or otherwise sending characters with the device, see if +minicom displays them. It not reconfigure minicom to use the other +serial port, but keep the device connected to the same port. + <sect2> Missing connectors <p> If the software shows that you have more serial ports than you have connectors for (including an internal modem which counts as a serial port) then you may have a serial port that has no connector. -Some motherboards come with a serial port with no cable or serial DB -connector. Someone may build a PC from this and omit the connector. -There may be a "serial" connector and label on the motherboard but no -ribbon cable connects to its pins. To use this port you must get a -ribbon cable and connector. I've seen different wiring arrangements for -such ribbon cables so beware. +Some motherboards come with a serial port with no cable or external +serial DB connector. Someone may build a PC from this and decide not +to use this serial port. There may be a "serial" connector and label +on the motherboard but no ribbon cable connects to its pins. To use +this port you must get a ribbon cable and connector. I've seen +different wiring arrangements for such ribbon cables so beware. <sect1>Creating Devices In the /dev directory <label id="create_dev"> <p> @@ -2502,8 +2528,8 @@ device for <tt>ttyS0</tt> you would just type: linux# MAKEDEV ttyS0 </verb></tscreen> -If the above command doesn't work (and your are the root user), look -for the MAKEDEV script in the the /dev directory and run it. +If the above command doesn't work (and you are the root user), look +for the MAKEDEV script in the /dev directory and run it. This handles the devices creation and should set the correct permissions. For making multiport devices see <ref id="make_multi" name="Making @@ -2519,9 +2545,12 @@ Text-Terminal-HOWTO. control lines and indicate if they are positive (1 or green) or negative (0 or red). <itemize> +<item> <url url="http://serlook.sunsite.dk/" name="serlook"> can snoop + on serial line traffic (via a wiretap) and also send/receive on a + serial line. <item> The "file": /proc/tty/driver/serial lists those that are asserted (positive voltage) -<item> modemstat (Only works correctly on Linux PC consoles. Status +<item> modemstat (Only works correctly on Linux PC consoles.) Status monitored in a tiny window. Color-coded and compact. Must kill it (a process) to quit. <item> statserial (Info displayed on entire screen) @@ -2550,6 +2579,7 @@ June 2001 OK to use setserial with Laptops Nov. 2002 Debian's /var/lib/serial.conf Nov. 2003 Major revision. Plug-and-play dominates May 2004 Old Debian 1999 bug reported by me removed (fixed in 1999) +Feb.2005 Where config files reside /var/lib/setserial/autoserial.conf --> <p> This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There @@ -2561,25 +2591,35 @@ If you have a Laptop (PCMCIA) don't use <tt/setserial/ until you read <ref id="laptops_" name="Laptops: PCMCIA">. <sect2> Introduction -<p><tt/setserial/ is a program which allows you (or a shell script) to -talk to the serial device driver 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><tt/setserial/ 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) doesn't both detect +and set your add-on PCI serial ports. + +<tt/setserial/ 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. <tt/setserial/ 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 -configure the serial port hardware: It can't set the IRQ or port -addresses into the hardware. Furthermore, when it reports the -configuration of the hardware, it's sometimes wrong since it doesn't -actually probe the hardware unless you specifically tell it to. -Actually, it's 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. +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. In olden days, when the IRQ and port address was set by jumpers on the serial card, one would use <tt/setserial/ to tell the driver how these jumpers were set. Today, when plug-and-play methods detect how the -jumper-less serial port is set, <tt/setserial/ is not really needed +jumperless serial port is set, <tt/setserial/ is not really needed anymore unless you're having problems or using old hardware. Furthermore, if the configuration file used by <tt/setserial/ is wrong, then there's trouble. In this case, if you use <tt/setserial/ @@ -2588,18 +2628,18 @@ incorrect information in the configuration file. <tt/setserial/ 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 port's, there's usually better ways to look for -them. +options. For modern ports, there's usually better ways to look for +them by plug-and-play methods. Thus the name <tt/setserial/ 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 <tt/setserial/ tells it even if it conflicts with what the driver +what <tt/setserial/ 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". +any "serial driver". Some distributions (and versions) set things up so that <tt/setserial/ is run at boot-time by an initialization shell script (in the @@ -2618,16 +2658,18 @@ 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, <tt/setserial/ could be telling you what's -in them, or it could be telling you what <tt/setserial/ had previously -(and perhaps erroneously) told the driver. There's no way to know for -sure without doing some other checks. +can read these registers and setserial tells you what the device +driver thinks, it might be correct. Or it could be telling you what +<tt/setserial/ had previously (and perhaps erroneously) told the +driver. There's no way to know for sure without doing some other +checks. -The serial driver (for Linux 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 these, then there's no need to -use <tt/setserial/. The driver doesn't probe for legacy IRQs and may -get these wrong. +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 <tt/setserial/. 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. Besides the man page for <tt/setserial/, check out info in <tt>/usr/doc/setserial.../</tt> or <tt>/usr/share/doc/setserial</tt>. @@ -2679,13 +2721,11 @@ Note that setserial calls an IO address a "port". If you type: <tscreen><verb> setserial -g /dev/ttyS* </verb></tscreen> -you'll see some info about how the device driver is configured for -your ports. Note that where it says <tt>"UART: unknown"</tt> it -probably means that no uart exists. In other words, you probably have -no such serial port and the other info shown about the port is -meaningless and should be ignored. If you really do have such a -serial port, setserial doesn't recognize it and that needs to be -fixed. +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: <tt>"UART: unknown"</tt> just ignore the entire line +since no serial port exists at that address. 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 @@ -2712,8 +2752,14 @@ resources with setserial. 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 <tt/setserial/ runs -it uses the info from the the configuration file. In Debian there are -4 options for use of this configuration file: +it uses the info from the configuration file. + +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: <enum> <item>Don't use this file at all. At each boot, the serial driver @@ -2771,7 +2817,8 @@ 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 -configuration file such as <tt>/etc/serial.conf</tt> or +distribution-specific configuration file such as +<tt>/etc/serial.conf</tt> or <tt>/etc/sysconfig/serial</tt> or <tt>/var/lib/setserial/autoserial.conf</tt> for Debian. This will be used next time you start Linux. @@ -2817,10 +2864,11 @@ things up. It may also depends on the runlevel. Before modifying a configuration file, you can test out a "proposed" <tt/setserial/ command by just typing it on the command line. In some cases the results of this use of <tt/setserial/ will automatically get -saved in /etc/serial.conf (or autoserial.conf) when you shutdown. So -if it worked OK (and solved your problem) then there's no need to -modify any configuration file. See <ref id="config_file" -name="Configuration method using /etc/serial.conf, etc.">. +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 +<ref id="config_file" name="Configuration method using +/etc/serial.conf, etc.">. <sect2> Edit a script (required prior to version 2.15) <label id="old_sets_script"> @@ -2842,9 +2890,9 @@ using it. The script <tt>/etc/rc.d/rc.serial</tt> was commonly used in the past. The Debian distribution used <tt>/etc/rc.boot/0setserial</tt>. Another file once used was <tt>/etc/rc.d/rc.local</tt> but it's may -not have run early enough. It's was reported that other processes 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's most likely was found in +communication failure. Later on it most likely was found in /etc/init.d/ but wasn't normally intended to be edited. If such a file was supplied, it likely contained a number of @@ -2857,12 +2905,12 @@ Testing like this was a lot faster than doing repeated reboots to get it right. For versions >= 2.15 (provided your distribution implemented the -change, Redhat didn't as first) it may be more tricky to do since 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 <ref id="config_file" name="Configuration method using /etc/serial.conf, etc.">. -An example line in such a script was" +An example line in such a script was: <tscreen><verb> /sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test </verb></tscreen> @@ -2883,16 +2931,17 @@ cases it didn't work right due to the hardware. <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 <ref id="old_sets_script" name="Edit a script (before -version 2.15)">. 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 -<tt>/etc/serial.conf</tt> (or +version 2.15)">. 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 <tt>/etc/serial.conf</tt> (or <tt>/var/lib/setserial/autoserial.conf</tt>). 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 don't need to edit any file in order to set up (or +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. What often happens is this: When you shut down your PC the script @@ -2909,19 +2958,23 @@ 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. There's an option to avoid this in Debian known -as "AUTOSAVE-ONCE" which will be discussed later on. +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. -If 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). +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). The file most commonly used to run setserial at boot-time (in conformance with the configuration file) is now /etc/init.d/setserial @@ -2952,7 +3005,7 @@ Debian labeled obsolete files with "...pre-2.15". 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 -complied in support for this, and 3. your serial hardware supports it. +compiled in support for this, and 3. your serial hardware supports it. See <ref id="int_share-2.2" name="Interrupt sharing and Kernels 2.2+"> @@ -2962,9 +3015,9 @@ since IRQ sharing conflicts don't exist for non-existent devices. 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 both on your serial port (or modem card) and then use setserial to +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 may be one you can use for a serial port for a modem. +sound card, this could be used for a modem. <sect2> Laptops: PCMCIA <label id="laptops_"> <p>If you have a Laptop, read PCMCIA-HOWTO for info on the serial @@ -2983,18 +3036,20 @@ the driver is configured for PCMCIA cards. <sect1> Stty <label id="stty_"> <!-- stty.D begin <sect1> Stty <label id="stty_"> -In Serial and Text-Terminal --> +In Serial and Text-Terminal +Feb. 2005: Put redirection info into Obsolete section +--> <sect2> Introduction <p> <tt/stty/ does much of the configuration of the serial port but -since application programs (and the getty program) often handle it, +since application programs (and the getty program) often handle this, you may not need to use it much. It's handy if you're having problems or want to see how the port is set up. Try typing ``stty -a'' at your terminal/console to see how it's now set. Also try typing it without the -a (all) for a short listing which shows how it's set different than normal. Don't try to learn all the setting unless you want to -become a serial guru. Most of the defaults should work OK and some of -the settings are needed only for certain obsolete dumb terminals made -in the 1970's. +become a serial historian since many of the settings are only for slow +antique dumb terminals of the 1970's. Most of the defaults should +work OK. <tt/stty/ is documented in the man pages with a more detailed account in the info pages. Type <tt>"man stty"</tt> or <tt>"info stty"</tt>. @@ -3025,17 +3080,18 @@ that you don't need stty. One may write C programs which change the stty configuration, etc. Looking at some of the documentation for this may help one better understand the use of the stty command (and its many possible -arguments). Serial-Programming-HOWTO is useful. The manual page: -termios contains a description of the C-language structure (of type -termios) which stores the stty configuration in computer memory. Many -of the flag names in this C-structure are almost the same (and do the -same thing) as the arguments to the stty command. +arguments). Serial-Programming-HOWTO may be useful but it's outdated. +The manual page: termios contains a description of the C-language +structure (of type termios) which stores the stty configuration in +computer memory. Many of the flag names in this C-structure are +almost the same (and do the same thing) as the arguments to the stty +command. <sect2> Flow control options <p> To set hardware flow control use "crtscts". For software flow control there are 3 settings: ixon, ixoff, and ixany. -ixany: Mainly for terminals. Hitting any key will restarts the flow +ixany: Mainly for terminals. Hitting any key will restart the flow after a flow-control stop. If you stop scrolling with the "stop scroll" key (or the like) then hitting any key will resume scrolling. It's seldom needed since hitting the "scroll lock" key again will do @@ -3050,64 +3106,24 @@ when its buffers in main memory are nearly full. It protects the device where the port is located from being overrun. For a slow dumb terminal (or other slow device) connected to a fast -PC, it's unlikely the the PC's port will be overrun. So you seldom +PC, it's unlikely the PC's port will be overrun. So you seldom actually need to enable ixoff. But it's often enabled "just in case". <sect2> Using stty at a "foreign" terminal -<p> Using <tt/stty/ to configure the terminal that you are currently -using is easy. Doing it for a different (foreign) terminal or serial -port may be impossible. For example, let's say you are at the PC monitor -(tty1) and want to use <tt/stty/ to deal with the serial port ttyS2. -Prior to about 2000 you needed to use the redirection operator "<". -After 2000 (provided your version of setserial is >= 1.17 and stty >= -2.0) there is a better method using the -F option. This will work -when the old redirection method fails. Even with the latest versions -be warned that if there is a terminal on ttyS2 and a shell is running -on that terminal, then what you see will likely be deceptive and -trying to set it will not work. See <ref id="2_term_interfaces" -name="Two interfaces at a terminal"> to understand it. +<p>How do you use stty to view or set a terminal other than the +terminal you are currently using? It's usually impossible to do it if +the foreign terminal is in use and has a shell running on it. In +other cases for dealing with say ttyS2 while typing at another +terminal (such as tty1) use <tt> stty -F /dev/ttyS2 ...</tt> (or +--file instead of F). If ... is -a it displays all the stty settings +(-a means all). -The new method is ``stty -F /dev/ttyS2 ...'' (or --file instead of F). -If ... is -a it displays all the stty settings. The old redirection -method (which still works in later versions) is to type ``stty ... < -/dev/ttyS2''. If the new method works but the old one hangs, it -implies that the port is hung due to a modem control line not being -asserted. Thus the old method is still useful for troubleshooting. -See the following subsection for details. - -<sect3> Old redirection method -<p> Here's a problem with the old redirection operator (which doesn't -happen if you use the newer -F option instead). Sometimes when trying -to use stty, the command hangs and nothing happens (you don't get a -prompt for a next command even after hitting <return>). This is -likely due to the port being stuck because it's waiting for one of the -modem control lines to be asserted. For example, unless you've set -"clocal" to ignore modem control lines, then if no CD signal is -asserted the port will not open and stty will not work for it (unless -you use the newer -F option). A similar situation seems to exist for -hardware flow control. If the cable for the port doesn't even have a -conductor for the pin that needs to be asserted then there is no easy -way to stop the hang. - -One way to try to get out of the above hang is to use the newer -F -option and set "clocal" and/or "crtscts" as needed. If you don't have -the -F option then you may try to run some program (such as minicom) on -the port that will force it to operate even if the control lines say -not to. Then hopefully this program might set the port so it doesn't -need the control signal in the future in order to open: clocal or --crtscts. To use "minicom" to do this you likely will have to -reconfigure minicom and then exit it and restart it. Instead of all -this bother, it may be simpler to just reboot the PC. - -The old redirection method makes ttyS2 the standard input to stty. -This gives the stty program a link to the "file" ttyS2 so that it may -"read" it. But instead of reading the bytes sent to ttyS2 as one -might expect, it uses the link to find the configuration settings of -the port so that it may read or change them. Some people tried to use -``stty ... > /dev/ttyS2'' to set the terminal. This will not do it. -Instead, it takes the message normal displayed by the stty command for -the terminal you are on (say tty1) and sends this message to ttyS2. -But it doesn't change any settings for ttyS2. +But if the foreign terminal (ttyS2 in this example) has a shell +running on it, then what you see will likely be deceptive and trying +to set it will not work. This problem exists for virtual terminals +also such as dealing with tty3 from tty1, etc. See <ref +id="2_term_interfaces" name="Two interfaces at a terminal"> to +understand it. <sect2> Two interfaces at a terminal <label id="2_term_interfaces"> <p> When using a shell (such as bash) with command-line-editing @@ -3119,29 +3135,30 @@ hit the <return> key, the command-line-editor is exited and the terminal interface is changed to the nominal "cooked" interface (cooked mode) for the terminal. This cooked mode lasts until the next prompt is sent to the terminal (which is only a small fraction of a -second). Note that one never gets to type anything to this cooked -mode but what was typed in raw mode gets executed while in cooked -mode. +second). Note that one never gets to type any command in this cooked +mode but what was typed in raw mode on the command line gets read by +the shell while in cooked mode. When a prompt is sent to the terminal, the terminal goes from "cooked" -to "raw" mode (just like it does when you start an editor since you -are starting the command-line editor). The settings for the "raw" -mode are based only on the basic settings taken from the "cooked" -mode. Raw mode keeps these setting but changes several other settings -in order to change the mode to "raw". It is not at all based on the -settings used in the previous "raw" mode. Thus if one uses stty to -change settings for the raw mode, such settings will be permanently -lost as soon as one hits the <return> key at the terminal that -has supposedly been "set". +to "raw" mode (just like it does when you start an editor such as vim. +The prompt signals starting the command-line editor. The settings for +the "raw" mode are based only on the basic stty settings taken from the +"cooked" mode. Raw mode keeps these setting but changes several other +settings in order to change the mode to "raw". It is not at all based +on the settings used in the previous "raw" mode. Thus if one uses +stty to change settings for the raw mode, such settings will be +permanently lost as soon as one hits the <return> key at the +terminal that has supposedly been "set". Now when one types stty to look at the terminal interface, one may either get a view of the cooked mode or the raw mode. You need to -figure out which one you're looking at. It you use stty from another -(foreign) terminal then you will see the raw mode settings. Any -changes made will only be made to the raw mode and will be lost when -someone presses <return> at the terminal you tried to "set". -But if you type a stty command at your terminal (without the -F option -or redirection) and then hit <return> it's a different story. +figure out which one you're looking at. It you use stty from a +foreign terminal (other than the terminal you are currently typing +at) then you will see the raw mode settings. Any changes made will +only be made to the raw mode and will be lost when someone presses +<return> at the foreign terminal you tried to "set". But if you +type a stty command to view/change the configuration of the terminal +you are using, and then hit <return> it's a different story. The <return> puts the terminal in cooked mode. Your changes are saved and will still be there when the terminal goes back into raw mode (unless of course it's a setting not allowed in raw mode). @@ -3177,6 +3194,53 @@ so that the low level stuff is done first. If you have directories in the /etc tree where every file in them is executed at boot-time (System V Init) then you could create a file named "stty" for this purpose. + +<sect2> Obsolete redirection method +<p>Prior to about 2000 you needed to use the redirection operator "<" +if you wanted to use stty on a foreign terminal. For example to use +stty on ttyS2 sitting at tty1 you would type: stty .... < /dev/ttyS2. +After 2000 (provided your version of setserial is >= 1.17 and stty >= +2.0) a better method was created using the -F option: stty -F +/dev/ttyS2. This will work when the old redirection method fails. + +The old redirection example above makes ttyS2 the standard input to +stty. This gives the stty program a link to the "file" ttyS2 so that +it may "read" it. But instead of reading the bytes sent to ttyS2 as +one might expect, it uses the link to find the configuration settings +of the port so that it may read or change them. In olden days, some +people tried to use ``stty ... > /dev/ttyS2'' to set the terminal. +This didn't work. Instead, it takes the message normal displayed +by the stty command for the terminal you are on (say tty1) and sends +this message to ttyS2. But it doesn't change any settings for ttyS2. + +Here's a problem with the old redirection operator (which doesn't +happen if you use the newer -F option instead). Sometimes when trying +to use stty, the command hangs and nothing happens (you don't get a +prompt for a next command even after hitting <return>). This is +likely due to the port being stuck because it's waiting for one of the +modem control lines to be asserted. For example, unless you've set +"clocal" to ignore modem control lines, then if no CD signal is +asserted the port will not open and stty will not work for it (unless +you use the newer -F option). A similar situation seems to exist for +hardware flow control. If the cable for the port doesn't even have a +conductor for the pin that needs to be asserted then there is no easy +way to stop the hang. + +One way to try to get out of the above hang is to use the newer -F +option and set "clocal" and/or "crtscts" as needed. If you don't have +the -F option then you may try to run some program (such as minicom) on +the port that will force it to operate even if the control lines say +not to. Then hopefully this program might set the port so it doesn't +need the control signal in the future in order to open: clocal or +-crtscts. To use "minicom" to do this you likely will have to +reconfigure minicom and then exit it and restart it. Instead of all +this bother, it may be simpler to just reboot the PC. + +The obsolete redirection method (which still works in later versions) +is to type ``stty ... < /dev/ttyS2''. If the new method using -F +works but the obsolete one hangs, it implies that the port is hung due +to a modem control line not being asserted. Thus the obsolete +redirection method might still useful for troubleshooting. <!-- stty.D end --> @@ -3191,11 +3255,23 @@ 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. -<sect1> What is slattach? -<p> It's "serial line attach". It puts the serial line into a -networking mode. You can thus network two computers together via a -serial line using, for example, the slip protocol. But for the ppp -protocol, you need to start pppd on the serial line. +<sect1> Connecting two PCs together via serial ports +<p>This is where you run a serial cable (crossover type = null-modem +type) between the serial ports of two PCs. Then how do you use this +line? One way is for one PC to run login on the serial line and for +the other PC to run say minicom to emulate a terminal. See +Text-Terminal-HOWTO. There is no network protocol used in this case +and no error detection. + +The other method is to run a network protocol on the line. For +example, to use PPP in combination with TCP/IP see Serial Laplink +HOWTO. Although this HOWTO doesn't mention the old program "slattach" +(serial line attach) it can put the serial line into a networking mode +using the protocol you select. Protocols for slattach include PPP or +SLIP (an older protocol widely used prior to PPP). + +The Debian package, net-tools, contains slattach. SLIP is provided as +a kernel module or can be built into the kernel (2.2, 2.4, or 2.6). <sect> Speed (Flow Rate) <label id="speed_"> @@ -3209,7 +3285,7 @@ uses the serial port. See <ref id="stty_" name="Stty"> section is unique to each HOWTO. Feb. 2003, --> -<sect2> Speeds over 115.2k +<sect2> Speeds over 115.2kbps <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 @@ -3387,14 +3463,14 @@ ahead and use the port anyway (after removing the stale lock-files). Unfortunately, there may be some programs that don't do this and give up by telling you that a device is already in use when it really isn't. -When there were only lockfiles with device names, the following -problem could arise: If the same device has two different -names then two different processes could each use a different name for -the same device. This results in lockfiles with different names that -actually are the same device. Formerly each physical serial port was -known by two different device names: ttyS0 and cua0. To solve this -lockfile alias problem, 3 methods have been used. It may be overkill -since any one of these methods would have fixed the problem. +If the lockfile only uses device names, the following problem could +arise: If the same device has two different names then two different +processes could each use a different name for the same device. This +results in lockfiles with different names that actually are the same +device. Formerly each physical serial port was known by two different +device names: ttyS0 and cua0. To solve this lockfile alias problem, 3 +methods have been used. It may be overkill since any one of these +methods would have fixed the problem. <enum> <item> The lock checking software was made aware of ttyS vs. cua. @@ -3404,9 +3480,11 @@ since any one of these methods would have fixed the problem. </enum> Using alternate names such as /dev/modem for /dev/ttyS2 may cause -problems with older versions. For dumb terminals, lockfiles are not -used since this would not permit someone else to send a message to -your terminal using the write or talk program. +problems if one program opens /dev/ttyS2 while another program opens +/dev/modem. This problem was supposedly fixed around 2000, but is +still present in 2005. For dumb terminals, lockfiles are not used +since this would not permit someone else to send a message to your +terminal using the write or talk program. <sect1>Lock-Files if you use devfs <p> The abandoned device-filesystem (devfs) has the /dev directory with @@ -3414,7 +3492,6 @@ subdirectories. As of late 2001, there were problems with lockfiles. For example, the lockfile mechanism considered dev/usb/tts/0 and /dev/tts/0 to be the same device with name "0". Ditto for all other devices that had the same "leaf" name. - Also, if some applications use the old name for a device and other applications use the devfs name for the same device, then the lockfiles will have different names. But the serial driver should @@ -3503,26 +3580,31 @@ prompt. <sect>Serial Tips And Miscellany -<sect1> Serial Module <label id="ser_module"> +<sect1> Serial Modules <label id="ser_module"> <p> Often the serial driver is provided as a module. Parameters may -be supplied to certain modules in /etc/modules.conf. Since kernel 2.2 -you don't edit this file but use the program update-modules to change -it. The info that is used to update modules.conf is put in -/etc/modutils/. The Debian/GNU Linux has a file here named -/etc/modutils/setserial which runs the serial script in /etc/init.d/ -every time the serial module is loaded or unloaded. When the serial -module is unloaded this script will save the state of the module in -/var/run/setserial.conf. Then if the module loads again this saved -state is restored. When the serial module first loads at boot-time, -there's nothing in /var/run/setserial.conf so the state is obtained -from /etc/serial.conf. So there are two files that save the state. -Other distributions may do something similar. +be supplied to certain modules in /etc/modules.conf or +/etc/modprobe.conf. Since kernel 2.2 you don't edit this file but use +the program update-modules to change it. The info that is used to +update modules.conf is put in /etc/modutils/. + +The Debian/GNU Linux has a file named /etc/modutils/setserial which +runs the serial script in /etc/init.d/ every time the serial module is +loaded or unloaded. When the serial module is unloaded this script +will save the state of the module in /var/run/setserial.conf. Then if +the module loads again this saved state is restored. When the serial +module first loads at boot-time, there's nothing in +/var/run/setserial.conf so the state is obtained from +/etc/serial.conf. So there are two files that save the state. Other +distributions may do something similar. + +The module, parport_serial is for PCI cards that contain both serial +and parallel ports. One may modify the serial driver by editing the source code. Much of the serial driver is found in the file serial.c. For info regarding writing of programs for the serial port see Serial-Programming-HOWTO. It was revised in 1999 by Vern Hoxie but -it's not at LDP and it's not now available. +that revision is not at LDP. <sect1> Serial Console (console on the serial port) <p> See the kernel documentation in: Documentation/serial-console.txt. @@ -3533,7 +3615,7 @@ Text-Terminal-HOWTO. <p> For a text terminal, the EIA-232 speeds are fast enough but the usable cable length is often too short. Balanced technology could fix this. The common method of obtaining balanced communication with -a text terminal is to install 2@ line drivers in the serial line to +a text terminal is to install 2 line drivers in the serial line to convert unbalanced to balanced (and conversely). They are a specialty item and are expensive if purchased new. @@ -3683,45 +3765,59 @@ Jan. '03: LSR safety check error Feb. '03: Interrupts may be shared on PCI Bus June '03: Wvdial: busy message due to lockfile permissions Dec. '03: Scanport can also detect an enabled PnP port +Feb. '04: Cannot open /dev/ttyS? +Feb. '05: Revised "Serial Port Can't be Found", /proc tree +May '05<>Linux Creates an Interrupt Conflict (your PC has an ISA slot) --> <sect1>(The following subsections are in both the Serial and Modem HOWTOs) -<sect1> My Serial Port is Physically There but Can't be Found +<sect1> Serial Port Can't be Found <label id="cant_find_port"> -<p> If a physical device (such as a modem) doesn't work at all it's -often because it's disabled and has no address (PnP hasn't enabled it) -or that it is enabled but is not at the I/O address that setserial -thinks it's at. Thus it can't be found. +<p>There are 3 possibilities: +<enum> +<item>Your port is disabled since both the BIOS and Linux failed to +enable it. It has no IO address. +<item>Your port is enabled and has an IO address but it has no ttyS +device number (like ttyS14) assigned to that address so the modem +can't be used. You may need to use "setserial" to assign a ttyS +number to it. +<item>Your port does have a ttyS number assigned to it (like ttyS14) +but you don't know which physical connector it is (on the back of your +PC). + +See <ref id="identify_ttyS" name="Which Connector on the Back of +my PC is ttyS1, etc?"> + +</enum> First check BIOS messages at boot-time (and possibly the BIOS menu for -the serial port). Then for the PCI bus use lspci. If this shows +the serial port). Then for the PCI bus type lspci -v. If this shows something like "LPC Bridge" then your port is likely on the LPC bus which is not well supported by Linux yet (but the BIOS might find it) ?? If it's an ISA bus PnP serial port, try "pnpdump --dumpregs" and/or see Plug-and-Play-HOWTO. If the port happens to be enabled -then the following two paragraphs may help find it: +then the following two paragraphs may help find the IO port: + +<sect2> Scanning/probing legacy ports +<p>This is mainly for legacy non-PCI ports and ISA ports that are not +Plug-and-Play. Using "scanport" (Debian only ??) will scan all enabled bus ports and may discover an unknown port that could be a serial port (but it -doesn't probe the port). It could hang your PC. You may try probing -with setserial. See <ref id="probing_ss" name="Probing">. +doesn't probe the port). It could hang your PC. If you suspect that +your port may be at a certain address, you may try manually probing +with setserial, but it's a slow tedious task if you have several +addresses to probe. See <ref id="probing_ss" name="Probing">. -If nothing seems to get thru the port it may be accessible but have a -bad interrupt. See <ref id="slow_" name="Extremely Slow: Text appears -on the screen slowly after long delays">. Use <tt>setserial -g</tt> -to see what the serial driver thinks and check for IRQ and I0 address -conflicts. Even if you see no conflicts the driver may have incorrect -information (view it by "setserial") and conflicts may still exist. - -If two ports have the same IO address then probing it will erroneously -indicate only one port. Plug-and-play detection will find both ports -so this should only be a problem if at least one port is not -plug-and-play. All sorts of errors may be reported/observed for -devices illegally "sharing" a port but the fact that there are two -devices on the same a port doesn't seem to get detected (except -hopefully by you). In the above case, if the IRQs are different then -probing for IRQs with setserial might "detect" this situation by -failing to detect any IRQ. See <ref id="probing_ss" name="Probing">. +<sect1>Linux Creates an Interrupt Conflict (your PC has an ISA slot) +<p>If your PC has a BIOS that handles ISA (and likely PCI too) then +if you find a IRQ conflict, it might be due to a shortage of free +IRQs. The BIOS often maintains a list of reserved IRQs, reserved for +legacy ISA cards. If too many are reserved, the BIOS may not be able +to find a free IRQ and will erroneously assign an IRQ to the serial +port that creates a conflict. So check to see if all the reserved +IRQs are really needed and if not, unreserve an IRQ that the serial +port can use. For more details, see Plug-and-Play-HOWTO. <sect1> Extremely Slow: Text appears on the screen slowly after long delays <label id="slow_"> @@ -3787,7 +3883,7 @@ id="set_serial" name="What is Setserial"> for more info. If you really do have an obsolete serial port, lying about it to setserial will only make things worse. -<sect1>The Startup Screen Show Wrong IRQs for the Serial Ports. +<sect1>The Startup Screen Shows Wrong IRQs for the Serial Ports <label id="irqs_shown_wrong"> <p> For non-PnP ports, Linux does not do any IRQ detection on startup. When the serial module loads it only does serial device detection. @@ -3818,6 +3914,19 @@ programs change the permissions when they run but restore them when the program exists normally. But if someone pulls the plug on your PC it's an abnormal exit and correct permissions may not be restored. +<sect1> "Cannot open /dev/ttyS?" +<p>Unless stty is set for clocal, the CD pin may need to be asserted +in order to open a serial port. If the physical port is not connected +to anything, or if it's connected to something that is not powered on +(such an external modem) then there will be no voltage on CD +from that device. Thus the "cannot open" message. Either set clocal +or connect the serial port connector to something and power it on. + +Even if a device is powered on and connected to a port, it may +sometimes prevent opening the port. An example of this is where the +device has negated CD and the CD pin on your PC is negated (negative +voltage). + <sect1> "Operation not supported by device" for ttyS? <p> This means that an operation requested by setserial, stty, etc. couldn't be done because the kernel doesn't support doing it. @@ -3977,8 +4086,10 @@ troubleshooting: name="What is Setserial"> <item> "stty" shows and sets the configuration of a port (except for that handled by "setserial"). - See the section <ref id="stty_" name="Stty"><item> "modemstat" or "statserial" will show the current state of - various modem signal lines (such as DTR, CTS, etc.) + See the section <ref id="stty_" name="Stty"><item> "modemstat" or "statserial" or "watch head +/proc/tty/driver/serial" will show the current state of various modem +signal lines (such as DTR, CTS, etc.). The one in /proc also shows +byte flow and errors. <item> "irqtune" will give serial port interrupts higher priority to improve performance. <item> "hdparm" for hard-disk tuning may help some more. @@ -4091,19 +4202,19 @@ another 16-bytes in its transmit buffer) one might expect that the serial port would not work at all. But it still may work anyway --sort of. Why? Well, besides the -interrupt method of servicing the port there's a slow polling method -that doesn't need interrupts. The way it works is that every so often -the device driver checks the serial port to see if it needs anything -such as if it has some bytes that need fetching from its receive -buffer. If interrupts don't work, the serial driver falls back to -this polling method. But this polling method was not intended to be -used a substitute for interrupts. It's so slow that it's not +interrupt method of servicing the port there's an undocumented slow +polling method that doesn't need interrupts. The way it works is that +every so often the device driver checks the serial port to see if it +needs anything such as if it has some bytes that need fetching from +its receive buffer. If interrupts don't work, the serial driver falls +back to this polling method. But this polling method was not intended +to be used a substitute for interrupts. It's so slow that it's not practical to use and may cause buffer overruns. Its purpose may have been to get things going again if just one interrupt is lost or fails to do the right thing. It's also useful in showing you that interrupts have failed. Don't confuse this slow polling method with -the fast polling method that operates on ports that have their -IRQs set to 0. +the fast polling method that operates on ports that have their IRQs +set to 0. For the 16-byte transmit buffer, 16 bytes will be transmitted and then it will wait until the next polling takes place (several seconds @@ -4119,7 +4230,8 @@ the screen. Thus the AT characters have to pass twice thru the serial port. Normally this happens so fast that AT seems to appear on the screen at the same time you hit the keys on the keyboard. With slow polling delays at the serial port, you don't see what you typed -until many seconds later. +until perhaps 15 seconds later. Even then, you don't often see all +you typed but only the first several characters. What about overruns of the 16-byte receive buffer? This will happen with an external modem since the modem just sends to the serial port @@ -4780,9 +4892,9 @@ topic. <sect1> The Universal Serial Bus (USB) <p> The Universal Serial Bus (USB) is being built into PCI chips. -Newer PC's have them. It is 12 Mbps (with 200 Mbps planned) over a -twisted pair with a 4-pin connector (2 wires are power supply). It -also is limited to short distances of at most 5 meters (depends on +Newer PC's have them. It was originally 12 Mbps but is now 480 Mbps +over a twisted pair with a 4-pin connector (2 wires are power supply). +It also is limited to short distances of at most 5 meters (depends on configuration). Linux supports the bus, although not all devices that can plug into the bus are supported. @@ -4929,12 +5041,11 @@ Notes re books: </enum> <sect1> Serial Software -<p> It's best to use the nearest mirror site, but here's the main -sites:<newline> -<url url="ftp://metalab.unc.edu/pub/Linux/system/serial/" +<p> If it's not available in your Linux distribution try:<newline> +<url url="http://www.ibiblio.org/pub/Linux/system/serial/" name="Serial Software"> for Linux software for the serial ports including getty and port monitors.<newline> -<url url="ftp://metalab.unc.edu/pub/Linux/apps/serialcomm" +<url url="http://www.ibiblio.org/pub/Linux/apps/serialcomm" name="Serial Communications"> for communication programs. <itemize> @@ -4989,31 +5100,56 @@ meaning of "stty" commands, etc. <itemize> <item> <url url="http://serial.sourceforge.net/" name="Linux Serial Driver home page"> Includes info about PCI support. +<!-- <item> <label id="vern_"> Serial Suite by - Vern Hoxie (site is dead in 2004) is a collection of blurbs about the + Vern Hoxie is a collection of blurbs about the care and feeding of the Linux serial port plus some simple programs. - He also has a Serial-Programming-HOWTO (not yet available from the - Linux Documentation Project). Your browser should automatically log - you in but if you do it manually login as "anonymous" and use your - full e-mail address as the password. + Not available. +--> +<item> <label id="vern_"> Serial-Programming-HOWTO (not yet available +from the Linux Documentation Project). It's now on my website: +<url +url="http://www.lafn.org/~dave/linux/Serial-Programming-HOWTO.txt"> +See also: <url +url="http://www.lafn.org/~dave/linux/Serial-Programming-HOWTO-B.txt" +name="Serial-Programming-HOWTO by Peter Baumann"> +<item> <url +url="http://www.lafn.org/~dave/linux/terminalIO.html" name="Terminal +IO by Vern Hoxie"> +<url +url="http://www.lafn.org/~dave/linux/termios.txt" name="Termios man +page revision by Vern Hoxie"> <item> A white paper discussing serial communications and multiport serial boards was available from Cyclades at <tt><htmlurl url="http://www.cyclades.com" name="http://www.cyclades.com"></tt>. + +<item> <url +url="http://www.freebsd.org/doc/en_US.ISO8859-1/articles/serial-uart/" +name="Serial and UART Tutorial (FreeBSD)"> </itemize> -<sect> Appendix: Obsolete Hardware (prior to 1990) Info +<sect> Appendix A: Obsolete Hardware/Software -<sect1>Replacing obsolete UARTS +<sect1>Replacing pre 1990 UARTS <p> Many 486 PCs (old) and all Pentiums (or the like) should have modern 16550As (usually called just 16550's) with FIFOs. If you have -something really old, the chip may unplug so that you may be able to -upgrade by buying a 16550A chip and replacing your existing 16450 -UART. If the functionality has been built into another type of chip, -you are out of luck. If the UART is socketed, then upgrading is easy -(if you can find a replacement). The new and old are pin-to-pin +something really old (pre 1990), the chip may unplug so that you may +be able to upgrade by buying a 16550A chip and replacing your existing +16450 UART. If the functionality has been built into another type of +chip, you are out of luck. If the UART is socketed, then upgrading is +easy (if you can find a replacement). The new and old are pin-to-pin compatible. It may be more feasible to just buy a new serial card on the Internet (few retail stores stock them today) or find a used one. -<p> END OF Serial-HOWTO -</article> +<sect1>Two ports with same IO address +<p>Modern kernels should not allow the opening of ports with the same +IO address. But one may probe for ports that are not open. If two +ports have the same IO address then probing it will erroneously +indicate only one port. Plug-and-play detection will find both ports +so this should only be a problem if at least one port is not +plug-and-play. All sorts of errors may be reported/observed for +devices illegally "sharing" an IO address. See <ref id="probing_ss" +name="Probing">. + +<p> END OF Serial-HOWTO </article>