diff --git a/LDP/howto/linuxdoc/Modem-HOWTO.sgml b/LDP/howto/linuxdoc/Modem-HOWTO.sgml index a0935610..6b80ff67 100644 --- a/LDP/howto/linuxdoc/Modem-HOWTO.sgml +++ b/LDP/howto/linuxdoc/Modem-HOWTO.sgml @@ -3,10 +3,12 @@ Modem-HOWTO David S.Lawyer - v0.12, December 2000 + v0.13, February 2001 Please freely copy and distribute (sell or give away) this document -in any format. Forward any corrections and comments to the document +in any format. Send any corrections and comments to the document maintainer. You may create a derivative work and distribute it provided that you: - Send your derivative work (in the most suitable format such as - sgml) to the LDP (Linux Documentation Project) or the like for - posting on the Internet. If not the LDP, then let the LDP know - where it is available. Except for a translation, send a copy to the - previous maintainer's url as shown in the latest version. + If it's not a translation: Email a copy of your derivative work + to the LDP (Linux Documentation Project) for free distribution on the + Internet in a format LDP accepts. Also email such a copy to the + author(s) and maintainer (could be the same person). License the derivative work in the spirit of this license or use GPL. Include a copyright notice and at least a pointer to the license used. @@ -100,9 +100,8 @@ be a trademark). Such trademarks belong to their respective owners. Credits

Most of the original Serial-HOWTO was written by Greg Hankins. - -He also rewrote many contributions by others in order to maintain + +H e also rewrote many contributions by others in order to maintain continuity in the writing style and flow. He wrote: ``Thanks to everyone who has contributed or commented, the list of people has gotten too long to list (somewhere over one hundred). Special thanks @@ -117,7 +116,8 @@ sites see: . Various formats are available. If you only want to quickly check the date of the latest version look at and compare -it to this version: v2.09 October 2000 . New in this version is: link to Serial Driver homepage, ttySD etc. +it to this version: v2.10 February 2001 . New in this version is: +v2.10 EIA-485, frame errors on networks, gkermit, firewire Related HOWTO's re the Serial Port

Modems, Text-Terminals, some printers, and other peripherals often @@ -180,7 +180,7 @@ you just installed another serial port in your PC. How the Hardware Transfers Bytes

Below is an introduction to the topic, but for a more advance +

Below is an introduction to the topic, but for a more advanced treatment of it see . Transmitting @@ -325,6 +325,7 @@ transmit buffer in the hardware. @@ -361,11 +362,13 @@ convert data from parallel (inside the computer) to serial on the transmit pin (and conversely). Most of the electronics of the serial port is found in a computer chip -(or a section of a chip) known as a UART. For more details on UARTs -see the section . 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. +(or a part of a chip) known as a UART. For more details on UARTs +see the section + + +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. Pins and Wires

Old PC's used 25 pin connectors but only about 9 pins were @@ -532,24 +535,24 @@ be reduced. Flow Control

Flow control means the ability to stop the flow of bytes in a -wire. It also includes provisions to restart the flow without any -loss of bytes. Flow control is needed for modems to allow a jump in -instantaneous flow rates. +

Flow control means the ability to slow done the flow of bytes in a +wire. For serial ports this means the ability to stop and then +restart the flow without any loss of bytes. Flow control is needed +for modems to allow a jump in instantaneous flow rates. Example of Flow Control

For example, consider the case where you connect a 36.6k external modem via a short cable to your serial port. The modem sends and receives bytes over the phone line at 36.6k bits per second (bps). -It's not doing any data compression or error correction. You have set -the serial port speed to 115,200 bits/sec (bps), and you are sending -data from your computer to the phone line. Then the flow from the -your computer to your modem over the short cable is at 115.2k bps. +Assume it's not doing any data compression or error correction. You +have set the serial port speed to 115,200 bits/sec (bps), and you are +sending data from your computer to the phone line. Then the flow from +the your computer to your modem over the short cable is at 115.2k bps. However the flow from your modem out the phone line is only 33.6k bps. Since a faster flow (115.2k) is going into your modem than is coming out of it, the modem is storing the excess flow (115.2k -33.6k = 81.6k -bps) in one of its buffers. This buffer would eventually overrun (run -out of free storage space) unless the 115.2k flow is stopped. +bps) in one of its buffers. This buffer would soon overrun (run out +of free storage space) unless the high 115.2k flow is stopped. But now flow control comes to the rescue. When the modem's buffer is almost full, the modem sends a stop signal to the serial port. The @@ -564,18 +567,40 @@ creates an average flow rate in the short cable (in this case 33.6k) which is significantly less than the "on" flow rate of 115.2k bps. This is "start-stop" flow control. -The above is a simple example of flow control for flow from the -computer to a modem , but there is also flow control which is used for -the opposite direction of flow: from a modem (or other device) to a +In the above simple example it was assumed that the modem did no data +compression. This would be true when the modem is sending a file +which is already compressed and can't be compressed further. Now +let's consider the opposite extreme where the modem is compressing the +data with a high compression ratio. In such a case the modem might +need an input flow rate of say 115.2k bps to provide an output (to the +phone line) of 33.6k bps (compressed data). The compression ratio is +3.43 (115.2/33.6) which is much higher than average. In this case the +modem is able to compress and the 115.2 bps PC-to-modem flow and send +the same data out on the phone line at 33.6bps. There's no need for +flow control here. But such a high compression ratio rarely happens +so that most of the time flow control is needed to slow down the flow +on the 115.2 bps PC-to-modem cable. The flow is stopped and started +so that the average flow is usually well under the "on" flow of 115.2 +bps. + +In the above example the modem was an external modem. But the same +situation exists (as of late 2000) for most internal modems. There is +still a speed limit on the PC-to-modem speed even though this flow +doesn't take place over an external cable. This makes the internal +modems compatible with the external modems. + +In the above example of flow control the flow was from the computer to +a modem. But there is also flow control which is used for the +opposite direction of flow: from a modem (or other device) to a computer. Each direction of flow involve 3 buffers: 1. in the modem -2. in the UART chip (called FIFOs) 3. in main memory managed by the serial -driver. Flow control protects certain buffers from overflowing. The -small UART FIFO buffers are not protected in this way but rely -instead on a fast response to the interrupts they issue. FIFO stand -for "First In, First Out" which is the way it handles bytes. All the -3 buffers use the FIFO rule but only one of them also uses it as a -name. This is the essence of flow control but there are still some -more details. +2. in the UART chip (called FIFOs) 3. in main memory managed by the +serial driver. Flow control protects certain buffers from +overflowing. The small UART FIFO buffers are not protected in this +way but rely instead on a fast response to the interrupts they issue. +FIFO stand for "First In, First Out" which is the way it handles +bytes. All the 3 buffers use the FIFO rule but only one of them also +uses it as a name. This is the essence of flow control but there are +still some more details. @@ -607,19 +632,19 @@ code. Likewise for DC1. Data Flow Path; Buffers -

Although much has been explained about this including flow -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 -there is still another pair of buffers. These are large buffers -(perhaps 8k) 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 memory. The pair consists of both -this transmit buffer and a receive buffer for the opposite direction -of byte-flow. Here's an example diagram for the case of browsing the -Internet with a browser. Transmit data flow is left to right while -receive flow is right to left. +

Much has been explained about this including flow +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. +When an application program sends bytes to the serial port + +they first get stashed in the the transmit serial port buffer in main +memory. The pair consists of both this transmit buffer and a receive +buffer for the opposite direction of byte-flow. Here's an example +diagram for the case of browsing the Internet with a browser. +Transmit data flow is left to right while receive flow is right to +left. application 8k-byte 16-byte 1k-byte tele- @@ -631,7 +656,7 @@ The serial device driver takes out say 16 bytes from this transmit buffer, one byte at a time and puts them into the 16-byte transmit buffer in the serial UART for transmission. Once in that transmit buffer, there is no way to stop them from being transmitted. They are then -transmitted to the moedem or other device connected to the serial port +transmitted to the modem or other device connected to the serial port which also has a fair sized (say 1k) buffer. When the device driver (on orders from flow control) stops the flow of outgoing bytes from the computer, what it actually stops is the flow of outgoing bytes @@ -733,31 +758,29 @@ flow to the hard-disk passed thru my modem and since the overflow happened there, bytes intended for the hard-disk were lost. - Serial Software: Device Driver Module + Serial Driver Module

The device driver for the serial port is the software that operates the serial port. It is now provided as a serial module. -This module will normally get loaded automatically if it's needed. -The kernel 2.2 + will do this. In earlier kernels, you had to have -From kernel 2.2 on, this module will normally get loaded automatically +if it's needed. In earlier kernels, you had to have for more info on +See for more info on + @@ -840,10 +863,10 @@ Thus if someone dials in to you (reaches your multiport serial card from a modem plugged into the card) they will not be able to go above 33.6k in either direction, even if they use a 56k modem. To go above 33.6k for dial-in requires that you have a digital connection to the -telephone line. The serial port is no longer used for this case. -Thus serial multiport cards are now obsolete for use by ISPs or anyone -that needs to allow others to dial-in to them at 56k (over 33.6k). -See Modem-HOWTO: Modem Pools, Digital Modems. +telephone line. The serial port can't be used for this case. Thus +serial multiport cards are now obsolete for use by ISPs or anyone that +needs to allow others to dial-in to them at 56k (over 33.6k). See +Modem-HOWTO: Modem Pools, Digital Modems. Each multiport card has a number of external connecters (DB-25 or RJ45 ) so that one may connect up a number of devices (modems, terminals, @@ -932,9 +955,10 @@ may have some different links. Standard PC Serial Cards -

In olden days PCs used to come with a serial card installed. -Later on the serial function was put on the hard-drive interface card. -Today, one or two serial ports are usually built into the motherboard. +

In olden days PCs came with a serial card installed. Later on the +serial function was put on the hard-drive interface card. Today, one +or two serial ports are usually built into the motherboard. Most of +them (as of 2001) use a 16550 but some use 16650 (32-byte FIFOs). But one may still buy the old PC serial cards if they need 1-4 more serial ports. These are for ttyS0-ttyS3 (COM1 - COM4). They can be used to connect external serial devices (modems, serial mice, etc...). @@ -968,7 +992,7 @@ support for them into the kernel. Arnet Multiport-8 (8 ports) Bell Technologies HUB6 (6 ports) Boca BB-1004 (4 ports), BB-1008 (8 ports), BB-2016 (16 ports; - See the mini-howto) * # + See the Boca mini-howto revised in 2001) * # Boca IOAT66 or? ATIO66 (6 ports, Linux doesn't support its IRQ sharing ?? Uses odd-ball 10-cond RJ45-like connectors) Boca 2by4 (4 serial ports, 2 parallel ports) @@ -1028,11 +1052,11 @@ Serial Driver home page"> 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 may be 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 also have info (ads) on related hardware such as modem pools, -remote access servers, and terminal servers. Where there is no +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 +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 together a better list, let me know. @@ -1217,24 +1241,30 @@ name="http://www.ssc.com/lj/issue14">. Change-log: --> - PCI Bus Support Underway

Some PCI cards (mostly modem cards) need no special support in the -kernel and work fine under Linux once setserial is used to configure -them. Other PCI cards need special support in the kernel but the 2.2 -serial driver has no such support. But kernels 2.3 and 2.4 will -eventually support certain PCI serial cards (and modem cards) by means -of an enhanced serial driver. -The driver will read the id number digitally stored on -the card to determine how (or if) to support the card. + PCI Bus Support Underway

+Although most PCI modems are "winmodems" without a +Linux driver (and will not work under Linux), other PCI serial cards +(usually modem cards) will often work OK under Linux. Some need no +special support in the serial driver and work fine under Linux once +setserial is used to configure them. Other PCI cards need special +support in the kernel. Some of these cards are supported by kernel +2.4 (and in later versions of the 2.3 series). Kernel 2.2 has no such +support. If your modem (or serial port) happens to be supported, then +you shouldn't need to do anything to PnP configure it. The new serial +driver will read the id number digitally stored on the card to +determine how to support the card. It should assign the I/O address +to it, determine it's IRQ, etc. So you don't need to use "setserial" +for it. If you have a PCI modem card you should be looking at Modem-HOWTO and not this Serial-HOWTO. If you just have a PCI serial port card (with no modem -on the card) but it will not work because the driver doesn't support it, you can -help in attempting to create a driver for it. To do this you'll need -to contact the maintainer of the serial driver, Theodore (Ted) Y. -Ts'o. +on the card) but it will not work because the latest serial driver doesn't support +it, you can help in attempting to create a driver for it. To do this +you'll need to contact the maintainer of the serial driver, Theodore +(Ted) Y. Ts'o. You will need to email Ted Ts'o a copy of the output of "lspci -vv" with full information about the model and manufacturer of the PCI modem (or serial port). Then he @@ -1330,17 +1360,19 @@ name="I/O Address & IRQ: Boot-time messages">. Common mistakes made re low-level configuring

Here are some common mistakes people make: -setserial command: They run it (without the "autoconfig" option) - and think it has checked out the hardware (it hasn't). +setserial command: They run it (without the "autoconfig" and + auto_irq options) and think it has checked out the hardware (it + hasn't). setserial messages: They see them displayed on the screen at - boot-time, and erroneously think that the result shows how their - hardware is actually configured. -/proc/interrupts: When their serial device isn't in use they don't - see its interrupt there, and erroneously conclude that their + boot-time (or by giving the setserial command) and erroneously think + that the result always shows how their hardware is actually + configured. +/proc/interrupts: When their serial device isn't in use they + don't see its interrupt there, and erroneously conclude that their serial port can't be found (or doesn't have an interrupt set). -/proc/ioports: People think this shows the hardware - configuration when it only shows about the same data (possibly - erroneous) as setserial. +/proc/ioports and /proc/tty/driver/serial: People think this + shows the actual hardware configuration when it only shows about the + same info (possibly erroneous) as setserial. I/O Address & IRQ: Boot-time messages

The previous section indicated how to attempt to do this by -looking at the start-up messages. If they give you sufficient info -then you may not need to read this section. If they don't then there -are some other ways to look into this. +

If your serial port seems to work OK, then you may type "setserial +-g /dev/ttyS*", look at /proc/tty/driver/serial, or inspect the +start-up messages. If you serial port doesn't work (or is very slow) +then you need to read further. There are really two answers to the question "What is my IO and IRQ?" 1. What the device driver thinks has been set (This is what @@ -1429,24 +1461,22 @@ setserial usually sets and shows). 2. What is actually set in the hardware. They both should be the same. If they're not it spells trouble since the driver has incorrect info on the physical serial port. If the driver has the wrong IO address it will try to send data -to a non-existing serial port --or even worse, to an actual device -that is not a serial port. If it has the wrong IRQ the driver will -not get interrupt service requests from the serial port, resulting in -a very slow or no response. See . If it has the -wrong model of UART there is also apt to be trouble. To determine if -both I0-IRQ pairs are identical you must find out how they are set in -both the driver and the hardware. +to a non-existing serial port --or even worse, to some other device. +If it has the wrong IRQ the driver will not get interrupt service +requests from the serial port, resulting in a very slow or no +response. See . If it has the wrong model of +UART there is also apt to be trouble. To determine if both I0-IRQ +pairs are identical you must find out how they are set in both the +driver and the hardware. What does the device driver think?

This is easy to find out. Just look at the start-up messages or type "setserial -g /dev/ttyS*". If everything works OK then what it tells you is likely also set in the hardware. There are some other ways to find this info by looking at "files" in the /proc directory. -An important reason for understanding these other ways is to warn you -that they only show what the device driver thinks. Some people view -certain "files" in the /proc directory and erroneously think that what -they see is set in the hardware but "it ain't necessarily so". +Be warned that there is no guarantee that the same is set in the +hardware. /proc/ioports will show the IO addresses that the drivers are using. /proc/interrupts shows the IRQs that are used by drivers of @@ -1472,8 +1502,7 @@ use, that interrupt might not be set in the hardware and it implies that the driver is using the wrong interrupt. To view /proc/interrupts to check on a program that you're currently running (such as "minicom") you need to keep the program running while you -view it. To do this, try to jump to a shell without exiting the -program. +view it. What is set in my serial port hardware ?

If you have a true Plug-and-Play set up where either the OS or a -PnP BIOS configures all your devices, then you don't choose your IRQs. -PnP determines what it thinks is best and assigns them. But if you -use the tools in Linux for Plug-and-Play (isapnp and pcitools) then -you have to choose. If you already know what IRQ you want to use you -could skip this section except that you may want to know that IRQ 0 -has a special use (see the following paragraph). +

If you have Plug-and-Play ports then either a PnP BIOS or the +serial driver may configure all your devices for you and then you may +not need to choose any IRQs. PnP determines what it thinks is best +and assigns them. But if you use the tools in Linux for Plug-and-Play +(isapnp and pcitools) or jumpers then you have to choose. If you +already know what IRQ you want to use you could skip this section +except that you may want to know that IRQ 0 has a special use (see the +following paragraph). IRQ 0 is not an IRQ

While IRQ 0 is actually the timer (in hardware) it has a special @@ -1615,22 +1646,23 @@ programs that use interrupts are being run and make sure there are no conflicts. Choosing Addresses --Video card conflict with ttyS3 - +

The IO address of the IBM 8514 video board (and others like it) is allegedly 0x?2e8 where ? is 2, 4, 8, or 9. This may conflict with the IO address of ttyS0 address 0x3f8 @@ -1644,7 +1676,7 @@ Suppose there is an address conflict (as reported by setserial -g does not physically exist (and shows UART: unknown). Such a conflict shouldn't cause problems but it sometimes does in older kernels. To avoid this problem don't permit such address conflicts or delete -/dev/ttyS? if it doesn't physically exist. +/dev/ttySx if it doesn't physically exist. Set IO Address & IRQ in the hardware (mostly for PnP)

Inspecting the connectors may give some clues but is often not +definitive. The serial connectors on the back side of a PC are +usually DB connectors with male pins. 9-pin is the most common but +some are 25-pin (especially older PCs like 486s). There may be one +9-pin (perhaps ttyS0 ??) and one 25-pin (perhaps ttyS1 ??). For two +9-pin ones the top one might be ttyS0. + +If you only have one serial port connector on the back of your PC, +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 PnP configured yet). A report from setserial (at +boot-time or run by you from the command line) should help you +identify the non-modem port. + +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. + + Send bytes to the port +

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 positive 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 +(but the DTR went positive) then you've got the right port but it's +blocked from sending. This may be due to a wrong IRQ, -clocal being +set, etc. The command "stty -F /dev/ttyS1 -a" should show +clocal (and not -clocal). If not, change it to clocal. + +Another test is to jumper the transmit and receive pins (pins 2 and 3 +of either the 25-pin or 9-pin connector) of a test serial port. Then +send something to each port (from the PCs keyboard) and see if it gets +sent back. If it does it's likely the port with the jumper on it. +Then remove the jumper and verify that nothing gets sent back. Note +that if "echo" is set (per stty) then a jumper creates an infinite +loop. Bytes that pass thru the jumper go into the port and come right +back out of the other pin back to the jumper. Then they go back in +and out again and again. Whatever you send to the port repeats itself +forever (until you interrupt it by removing the jumper, etc.). This +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 and perhaps +use a scrap of paper to prevent the mini clips from accidentally +touching the metal of the connector. 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 + for +more info. + + Connect a device to the connector +

Another way to try to identify a serial port is to connect some +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 if connected. + + Missing connectors +

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" label on the motherboard but no ribbon cable +connects to the pins next to this label. To use this port you must +get a ribbon cable/connector. I've seen different wiring arrangements +for such ribbon cables so beware. + Creating Devices In the /dev directory

-If you don't have a device, you will have to create it with the - -linux# mknod -m 666 /dev/cua0 c 5 64 (cua devices are now obsolete) linux# mknod -m 666 /dev/ttyS0 c 4 64 You can use the /dev. @@ -1894,6 +2010,8 @@ for the serial port. What is Setserial ?

This part is in 3 HOWTOs: Modem, Serial, and Text-Terminal. There are some minor differences, depending on which HOWTO it appears in. @@ -1902,11 +2020,12 @@ are some minor differences, depending on which HOWTO it appears in.

Don't ever use = 2.15, the results of your last probe test may be saved -and put into the configuration file /etc/serial.conf which -will be used next time you start Linux. At boot-time when the serial -module loads (or the like), a probe for UARTs is made automatically -and reported on the screen. But the IRQs shown may be wrong. The -second report of the same is the result of a script which usually does -no probing and thus provides no reliable information as to how the -hardware is actually set. It only shows configuration date someone -wrote into the script or data that got saved in /etc/serial.conf. +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 may be saved and put into the configuration file +/etc/serial.conf which will be used next time you start +Linux. At boot-time when the serial module loads (or the like), a +probe for UARTs is made automatically and reported on the screen. But +the IRQs shown may be wrong. The second report of the same is the +result of a script which usually does no probing and thus provides no +reliable information as to how the hardware is actually set. It only +shows configuration data someone wrote into the script or data that +got saved in /etc/serial.conf. It may be that two serial ports both have the same IO address set in the hardware. Of course this is not permitted but it sometimes @@ -2035,16 +2161,26 @@ equivalent" is built into the kernel) then only . Configuration Scripts/Files

Your objective is to modify (or create) a script file in the /etc @@ -2059,11 +2195,11 @@ configuration file. So prior to version 2.15 all you do is edit a script. After 2.15 you may need to either do one of three things: 1. edit a script. 2. edit /etc/serial.conf or 3. run "setserial" on the command line -which will result in /etc/serial.conf automatically being +which may result in /etc/serial.conf automatically being edited. Which one of these you need to do depends on both your particular distribution, and how you have set it up. - Edit a script (after version 2.15: perhaps not) + Edit a script (required prior to version 2.15)

Prior to setserial 2.15 (1999) there was no /etc/serial.conf file to configure setserial. Thus you need to find the file that runs @@ -2081,6 +2217,8 @@ Another file once used was /etc/rc.d/rc.local but it's not a good idea to use this since it may not be run early enough. It's been reported that other processes may try to open the serial port before rc.local runs resulting in serial communication failure. +Today it's most likely in /etc/init.d/ but it isn't normally intended +to be edited. If such a file is supplied, it should contain a number of commented-out examples. By uncommenting some of these and/or @@ -2089,24 +2227,7 @@ sure that you are using a valid path for -/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig - -Do this for every serial port you want to auto configure. Be sure to -give a device name that really does exist on your machine. In some -cases this will not work right due to the hardware so if you know what -the uart and irq actually are, may want to assign them explicitly with -"setserial". For example: - - -/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test - +it right. For versions >= 2.15 (provided your distribution implemented the change, Redhat didn't) it may be more tricky to do since the file that @@ -2114,6 +2235,22 @@ runs setserial on startup, /etc/init.d/setserial or the like was not intended to be edited by the user. See . +If you want setserial to automatically determine the uart and the IRQ +for ttyS3 you would add something like: + + +/sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig + +Do this for every serial port you want to auto configure. Be sure to +give a device name that really does exist on your machine. In some +cases this will not work right due to the hardware. If you know what +the uart and irq actually are, you may want to assign them explicitly +with "setserial". For example: + + +/sbin/setserial /dev/ttyS3 irq 5 uart 16550A skip_test + + New configuration method using /etc/serial.conf

Using = -1.17 and stty >= 2.0) there is an alternate 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 to -understand it. + Using stty at a "foreign" terminal +

Using = 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 to understand it. 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 @@ -2320,15 +2459,15 @@ But it doesn't change any settings for ttyS2. Two interfaces at a terminal

When using a shell (such as bash) with command-line-editing enabled there are two different terminal interfaces (what you see when -you type stty -a). When you type at the command line you have a -temporary "raw" interface (or raw mode) where each character is read -by the command-line-editor as you type it. Once you 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. Note that one never types anything to this -cooked mode but what was typed in raw mode becomes cooked mode as soon -as one hits the <return> key. +you type stty -a). When you type in modern shells at the command line +you have a temporary "raw" interface (or raw mode) where each +character is read by the command-line-editor as you type it. Once you +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. Note that one never gets to type +anything to this cooked mode but what was typed in raw mode becomes +cooked mode as soon as one hits the <return> key. 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 @@ -2345,8 +2484,8 @@ 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 terminal to deal with a terminal that is displaying a command line, -then the view is that of the raw mode. Any changes made will only be -made to the raw mode and will be lost when someone presses +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 using < for redirection) and then hit <return> it's a different story. The <return> @@ -2361,10 +2500,12 @@ work! Of course you can try to type "stty sane ..." at the terminal that is corrupted but you can't see what you typed. All the above not only applies to dumb terminals but to virtual terminals used on a PC Monitor as well as to the terminal windows in X. In other words, it -applies to almost everyone who uses Linux. Luckily, a file that runs -stty at boot-time will likely deal with a terminal (or serial port -with no terminal) that has no shell running on it so there's no -problem. +applies to almost everyone who uses Linux. + +Luckily, when you start up Linux, any file that runs stty at boot-time +will likely deal with a terminal (or serial port with no terminal) +that has no shell running on it so there's no problem for this special +case. Where to put the stty command ?

Should you need to have Can't Set a High Enough Speed - +

You need to find out the highest speed supported by your hardware. -As of late 1998 most hardware only supported speeds up to 115.2k bps. -A few 56k internal modems support 230.4k bps. Recent Linux kernels -support high speeds (over 115.2k) but you might have difficulty using -it because of one or both of the following reasons: +As of late 1998 (and late 2000) most serial ports only supported +speeds up to 115.2k bps. Some 56k internal modems support 230.4k bps +(but it may be hard to find out which ones do). Recent Linux kernels +support high speeds (over 115.2k) but you might have some problems +using it because of one or both of the following reasons: - The application program (or stty) will not accept the high speed. - Setserial has a default speed of 115,200 (but this default is -easy to change) + Older versions of an application program (or stty) may not +accept the high speed. + Setserial may show the wrong speed unless you use the baud_base +option. In any case the high speed will work OK. How speed is set in hardware: the divisor and baud_base

If you are seeing slow throughput and serial port overruns on a system with (E)IDE disk drives, you can get hdparm. This @@ -2530,14 +2675,14 @@ A lock-file is simply a file created to mean that a particular device is in use. They are kept in /var/lock. Formerly they were in /usr/spool/uucp. Linux lock-files are sometimes named Change Owners, Groups, and/or Permissions of Device Files

In order to use a device, you (or the program you run if you have "set user id") needs to have permission to read and write the device @@ -2564,10 +2713,10 @@ this for you. A similar method can be used with the group of the device file. While lock files prevent other process from using the device, changing -device file owners/permissions restricts other users (or the group) from using -it. One case is where the group is permitted to write to the port, -but not to read from it. Writing to the port might just mean a -message sent to a text-terminal while reading means destructive +device file owners/permissions restricts other users (or the group) +from using it. One case is where the group is permitted to write to +the port, but not to read from it. Writing to the port might just +mean a message sent to a text-terminal while reading means destructive reading. The original process that needs to read the data may find data missing if another process has already read that data. Thus a read can do more harm that a write since a read causes loss of data @@ -2592,7 +2741,9 @@ available via FTP, if they didn't come with your distribution. - portable, scriptable, serial and TCP/IP communications including file transfer, character-set translation, and zmodem support -gkermit Tiny GPLed kermit run only from the command line. + Can't connect to another computer + kermit and zmodem -

-To use zmodem with For use of kermit with modems see the Modem-HOWTO. One can run +zmodem within the kermit program. To do this (for ttyS3), add the +following to your define rz !rz < /dev/ttyS3 > /dev/ttyS3 define sz !sz \%0 > /dev/ttyS3 < /dev/ttyS3 @@ -2631,7 +2782,31 @@ just type sz <filename> at the Serial Tips And Miscellany -

Here are some serial tips you might find helpful... + + Serial Module

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. + +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 (revised in 1999 by Vern Hoxie but not at +LDP. Get it from ) + + Serial Console (console on the serial port) +

See the kernel documentation in: Documentation/serial-console.txt. +See also "Serial Console" in Text-Terminal-HOWTO. Line Drivers

For a text terminal, the EIA-232 speeds are fast enough but the @@ -2673,19 +2848,22 @@ if this patch may impair performance of good hardware? Troubleshooting

See Modem-HOWTO for troubleshooting related to modems or getty for -modems. +modems. For a Text-Terminal much of the info here will be of value as +well as the troubleshooting info in Text-Terminal-HOWTO. - Serial Electrical Test Equipment + Serial Electrical Test Equipment

While a multimeter (used as a voltmeter) may be all that you need -for just a few terminals, simple special test equipment has been made -for testing serial port lines. Some are called "breakout ... " where -breakout means to break out conductors from a cable. These gadgets -have a couple of connectors on them and insert into the serial cable. -Some have test points for connecting a voltmeter. Others have LED -lamps which light when certain modem control lines are asserted -(turned on). Still others have jumpers so that you can connect any -wire to any wire. Some have switches. +for just a few serial ports, simple special test equipment has been +made for testing serial port lines. Some are called "breakout ... " +where breakout means to break out conductors from a cable. These +gadgets have a couple of connectors which connect to serial port +connectors (either at the ends of serial cables or at the back of a +PC). Some have test points for connecting a voltmeter. Others have +LED lamps which light when certain modem control lines are asserted +(turned on). The color of the light may indicate the polarity of the +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 1998) a "RS-232 Troubleshooter" or "RS-232 Line Tester" which checks TD, RD, CD, RTS, CTS, DTR, and DSR. A green @@ -2710,7 +2888,8 @@ 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 larger than the pins so that it doesn't damage the contact. Clip -an alligator clip (or the like) to the paper clip to connect up. +an alligator clip (or the like) to the paper clip to connect up. Take +care not to touch two pins at the same time with any metal object. Taste Voltage

As a last resort, if you have no test equipment and are willing to @@ -2733,18 +2912,23 @@ indicate if they are positive (1) or negative (0). See section - (The following subsections are in both the Serial and Modem HOWTOs) My Serial Port is Physically There but Can't be Found

If a device (such as a modem) give evidence of working, then the -serial port that it's on has been found. If it doesn't work at all, then -you need to make sure your serial port can be found. +

If a physical device (such as a modem) doesn't work at all it may +mean that the device is not at the I/O address that setserial +thinks it's at. It could also mean (for a PnP card) that is doesn't +yet have an address. Thus it can't be found. Check the BIOS menus and BIOS messages. For the PCI bus use lspci or scanpci. If it's an ISA bus PnP serial port, try "pnpdump --dumpregs" @@ -2757,7 +2941,7 @@ interrupt. See . Use setserial -g 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 and conflicts may still exist. +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 @@ -2773,8 +2957,8 @@ failing to detect any IRQ. See .

It's likely mis-set/conflicting interrupts. Here are some of the symptoms which will happen the first time you try to use a modem, -terminal, or printer. In some cases you type something but nothing -appears on the screen until many seconds later. Only the last +terminal, or serial printer. In some cases you type something but +nothing appears on the screen until many seconds later. Only the last character typed may show up. It may be just an invisible <return> character so all you notice is that the cursor jumps down one line. In other cases where a lot of data should appear on @@ -2793,19 +2977,19 @@ As a quick check to see if it really is an interrupt problem, set the IRQ to 0 with "setserial". This will tell the driver to use polling instead of interrupts. If this seems to fix the "slow" problem then you had an interrupt problem. You should still try to -solve the problem since polling uses excessive computer resources and -sometimes drastically decreases your thruput. +solve the problem since polling uses excessive computer resources. Checking to find the interrupt conflict may not be easy since Linux supposedly doesn't permit any interrupt conflicts and will send you a error message if it thinks you are attempting to create a conflict. But a -real conflict can be created if "setserial" has incorrect information. -Thus using "setserial" will not reveal the conflict (nor will looking -at /proc/interrupts which bases its info on "setserial"). You still -need to know what "setserial" thinks so that you can pinpoint where -it's wrong and change it when you determine what's really set in the -hardware. +real conflict can be created if "setserial" has told the kernel +incorrect info. The kernel has been lied to and thus doesn't think +there is any conflict. Thus using "setserial" will not reveal the +conflict (nor will looking at /proc/interrupts which bases its info on +"setserial"). You still need to know what "setserial" thinks so that +you can pinpoint where it's wrong and change it when you determine +what's really set in the hardware. What you need to do is to check how the hardware is set by checking jumpers or using PnP software to check how the hardware is actually @@ -2818,14 +3002,16 @@ thinks the hardware is set. modem, terminal, printer) doesn't work as fast as you thought it did. -Another possible reason is that the serial driver thinks you have an -obsolete serial port (UART 8250,16450 or early 16550). See . Use "setserial -g /dev/ttyS*". -If it shows anything less than a 16550A, this is likely your problem. -Then if "setserial" has it wrong, change it. See for more info. Of course if you really do -have an obsolete serial port, lying about it to setserial will only -make things worse. +Another possible reason is that you have an obsolete serial port: UART +8250, 16450 or early 16550 (or the serial driver thinks you do). See + + +Use "setserial -g /dev/ttyS*". +If it shows anything less than a 16550A, this may be your problem. +If you think that "setserial" has it wrong check it out. See for more info. If you +really do have an obsolete serial port, lying about it to setserial +will only make things worse. The Startup Screen Show Wrong IRQs for the Serial Ports.

Check the file permissions on this port with "ls -l /dev/ttyS?"_ @@ -2887,20 +3074,23 @@ Are Lock Files"> using the serial port. There are various ways to try to find out what process is "using" it. One way is to look at the contents of the lockfile (/var/lock/LCK...). It should be the process id. If the -process id is say 261 type "ps 261" to find out what it is. Then if +process id is say 100 type "ps 100" to find out what it is. Then if the process is no longer needed, it may be gracefully killed by "kill -261". If it refuses to be killed use "kill -9 261" to force it to be +100". If it refuses to be killed use "kill -9 100" to force it to be killed, but then the lockfile will not be removed and you'll need to -delete it manually. Of course if there is no such process as 161 then +delete it manually. Of course if there is no such process as 100 then you may just remove the lockfile but in most cases the lockfile should have been automatically removed if it contained a stale process id -(such as 261). +(such as 100). - "/dev/ttyS?: Device or resource busy"

This means that the device you are trying to access (or use) is supposedly busy (in use) or that a resource it needs (such as an IRQ) -is supposedly being used by another device. Sometimes it actually is -"busy" but in other cases it erroneously appears to be "busy". +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". The ``resource busy'' part often means (example for - There may be a real interrupt conflict that is being avoided. + There may be a real resource conflict that is being avoided. Setserial has it wrong and the only reason What you need to do is to find the interrupt setserial thinks - "Input/output error" from setserial or stty +

You may have typed "ttys" instead of "ttyS". You will see this +error message if you try to use the setserial command for any device +that is not a serial port. It also may mean that the serial port is +in use (busy or opened) and thus the attempt to get/set parameters by +setserial or stty failed. It could also mean that there isn't any +serial port at the IO address that setserial thinks your port is at. + + Overrun errors on serial port +

This is an overrun of the hardware FIFO buffer and you can't +increase its size. See @@ -2962,8 +3173,8 @@ troubleshooting: "lspci" shows the actual IRQs, etc. of hardware on the PCI bus. "pnpdump --dumpregs" shows the actual IRQs, etc. of hardware for PnP devices on the ISA bus. - Some "files" in the /proc tree (such as ioports and - interrupts). + Some "files" in the /proc tree (such as ioports, interrupts, + and tty/driver/serial). @@ -2991,11 +3202,11 @@ Since the kernel tries to avoid interrupt conflicts and gives you the interrupt conflicts happen? Easy. "setserial" may have it wrong and erroneously predicts no conflict when there will actually be a real conflict based on what is set in the hardware. When this happens -there will be no "... busy" message but performance will be extremely -slow. Both devices will send identical interrupt signals on the same -wire and the CPU will erroneously think that the interrupts only come -from one device. This will be explained in detail in the following -sections. +there will be no "... busy" message but a conflict will physically +happen. Performance is likely to be extremely slow. Both devices +will send identical interrupt signals on the same wire and the CPU +will erroneously think that the interrupts only come from one device. +This will be explained in detail in the following sections. Linux doesn't complain when you assign two devices the same IRQ provided that neither device is in use. As each device starts up @@ -3034,11 +3245,11 @@ type at<enter> and may see nothing. But then after 10 seconds or so you see the cursor drop down one line. What is going on is that the FIFO is behaving like it can only hold one byte. The "at" you typed caused it to overrun and both letters were lost. But the final -<enter> got thru since you waited for it and you "see" this -invisible character by noting that the cursor jumped down one line. -If you were to type a single letter and then wait about 10 seconds, -you should see it echo back to the screen. This is fine if your -typing speed is less that one word per minute :-) +<enter> eventually got thru and you "see" this invisible +character by noticing that the cursor jumped down one line. If you were +to type a single letter and then wait about 10 seconds, you should see +it echo back to the screen. This is fine if your typing speed is less +that one word per minute :-) Mis-set Interrupts

If you don't understand what an interrupt does see Interrupt Conflicts

When two devices have the same IRQ number it's called sharing interrupts. Under some conditions this sharing works out OK. -Starting with kernel version 2.2, serial ports may, in some cases, -share interrupts with other serial ports. Devices on the PCI bus may -share the same IRQ interrupt with other devices on the PCI bus. In -other cases where there is potential for conflict, there should be no -problem if no two devices with the same IRQ are ever "in use" at the -same time. More precisely, "in use" really means "open" (in +Starting with kernel version 2.2, ISA serial ports may, if the +hardware is designed for this, share interrupts with other serial +ports. Devices on the PCI bus may share the same IRQ interrupt with +other devices on the PCI bus (provided the software supports this). +In other cases where there is potential for conflict, there should be +no problem if no two devices with the same IRQ are ever "in use" at +the same time. More precisely, "in use" really means "open" (in programmer jargon). In cases other than the exceptions mentioned above (unless special software and hardware permit sharing), sharing is not allowed and conflicts arise if sharing is attempted. @@ -3159,13 +3373,8 @@ IRQ then see What Are UARTs? How Do They Affect Performance?

(This section is also in -the Modem-HOWTO) -UARTs ( UARTs ( UART Model Numbers

Here's a list of UARTs. - +Many 486 PCs (old) and all Pentiums (or the like) should have 16550As +(usually called just 16550's) with FIFOs. Some better motherboards +today (2000) even have 16650s. For replacing obsolete UARTs with +newer ones in pre 1990 hardware see the Appendix: Obsolete ... Pinout and Signals

The EIA-232 serial port as implemented on PC is asynchronous which @@ -3618,27 +3830,47 @@ non-EIA-232 listed below are supported by Linux. voltage is only 5 volts. Since this falls within EIA-232 specs it can be connected to a EIA-232 port. Its specs call for somewhat higher speeds than the EIA-232 (but this may be of little help on a -long run where it's the unbalance that causes interference). +long run where it's the unbalance that causes interference). Since +EIA-423 is not much of an improvement over EIA-232, it is not popular +except on old Mac computers. -Apple's Mac computer prior to mid-1998 with its EIA-232/EIA-422 Port -provided twisted-pairs (balanced) for transmit and receive (when used -as a 422). It is (per specs) exactly 100 times as fast as EIA-423 -(which in turn is somewhat faster than EIA-232) The Mac used a small -round "mini-DIN-8" connector. It also provided conventional EIA-232 -but at only at 5 volts (which is still legal EIA-232). To make it -work like at EIA-232 one must use a special cable which (signal) -grounds RxD+ (one side of a balanced pair) and use RxD- as the receive -pin. While TxD- is used as the transmit pin, for some reason TxD+ -should not be grounded. See . However, due to the fact that Macs (and -upgrades for them) cost more than PC's, they are not widely as host -computers for Linux. +EIA-422 is twisted pair (known as "balanced" or "differential) and is +(per specs) exactly 100 times as fast as EIA-423 (which in turn is +somewhat faster than EIA-232). Apple's Mac computer prior to mid-1998 +with its EIA-232/EIA-422 Port uses it. The Mac used a small round +"mini-DIN-8" connector. It also provided conventional EIA-232 but at +only at 5 volts (which is still legal EIA-232). To make it work like +at EIA-232 one must use a special cable which (signal) grounds RxD+ +(one side of a balanced pair) and use RxD- as the receive pin. While +TxD- is used as the transmit pin, for some reason TxD+ should not be +grounded. See . However, due to the fact that +Macs (and upgrades for them) cost more than PC's, they are not widely +as host computers for Linux. EIA-485 -

This is like EIA-422 (balanced). It is half-duplex. It's not -just point-to-point but may be used for a multidrop LAN (up to 32 -nodes). There are no connector specs. +

This is like EIA-422 (balanced = differential). It is +half-duplex. It's not just point-to-point but is like ethernet or +the USB since all devices (nodes) on it share the same "bus". It may +be used for a multidrop LAN (up to 32 nodes or more). Since many +nodes share the same twisted pair the need to use the electrical +tri-state mode where besides the 0 and 1 binary states there is also +an open circuit state to permit other nodes to uses the twisted pair +line. Instead of a transmitter keeping a 1-state voltage on the line +during line idle, the line is open circuited and all nodes just listen +(receive mode). + +The most common architecture is master/slave. The master polls the +slaves to see if they have anything to send. A slave can only +transmit just after it's been polled. + +There is an alternative implementation where two pair of wires are used +for sending data. One pair is only for the Master to send to the Slaves. +Since no one transmits on this line except the master, there is no +need for it to be tri-state. Thus the Master may just be EIA-232 but +the slaves must still be EIA-485. See + for more +details. EIA-530

EIA-530-A (balanced but can also be used unbalanced) at 2Mbits/s @@ -3650,16 +3882,16 @@ been installed. It uses the same 25-pin connector as EIA-232. 50-pin connector and goes up to about 50 Mbits/s but the distance is limited to only several meters. For Linux there are PCI cards supporting HSSI. The companies that sell the cards often provide (or -point you to) a Linux driver. A mini-howto or the like is needed for -this topic. +point you to) a Linux driver. A howto or the like is needed for this +topic. The Universal Serial Bus (USB)

The Universal Serial Bus (USB) is being built into PCI chips. -Newer PC's have them. It is 12 Mbits/s over a twisted pair with a -4-pin connector (2 wires are power supply) but 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. +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 +configuration). Linux supports the bus, although not all devices that +can plug into the bus are supported. It is synchronous and transmits in special packets like a network. Just like a network, it can have several devices attached to it. Each @@ -3669,7 +3901,17 @@ One device can monopolize it if no other device wants to use it. It's not simple to describe in detail. For documentation, see the USB directory in /usr/share/doc/kernel ... -It would be nice to have a HOWTO on the USB. +It would be nice to have a HOWTO on the USB. See also and/or . + + Firewire +

Firewire (IEEE 1394) is something like the USB only faster (800 +Mbps is planned). The protocol on the bus is claimed to be more +efficient than USB's. It uses two twisted pair for data plus two +power conductors (6 conductors in all). A variants uses only 4 +conductors. You may compile firewire support into the Linux kernel. +Like USB, it's also limited to short distances. Synchronization & Synchronous

Beside the asynchronous EIA-232 (and others) there are a number of @@ -3737,8 +3979,12 @@ phone line. Black, Uyless D.: Physical Layer Interfaces & Protocols, IEEE Computer Society Press, Los Alamitos, CA, 1996. Campbell, Joe: The RS-232 Solution, 2nd ed., Sybex, 1982. + Campbell, Joe: C Programmer's Guide to Serial Communications, + 2nd ed., Unknown Publisher, 1993. , (ISBN 0-937175-73-0; O'Reilly) + POSIX Programmer's Guide">, O'Reilly, 1991. + Nelson, Mark: Serial Communications Developer's Guide, 2nd ed., + Hungry Minds, 2000. Putnam, Byron W.: RS-232 Simplified, Prentice Hall, 1987. Seyer, Martin D.: RS-232 Made Easy, 2nd ed., Prentice Hall, 1991. @@ -3776,11 +4022,14 @@ name="Serial Communications"> for communication programs. Monitoring/Diagnostics"> - Linux Documents + Related Linux Documents

-man pages for: setserial(8) stty -libc (or glibc) docs package: "Low Level Terminal Interface" +man pages for: setserial and part of "GNU C Library Reference +manual" (in libc (or glibc) docs package). It covers the detailed +meaning of "stty" commands, etc. Modem-HOWTO: modems on the serial port PPP-HOWTO: help with PPP (using a modem on the serial port) Printing-HOWTO: for setting up a serial printer @@ -3820,13 +4069,28 @@ Monitoring/Diagnostics"> 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). When logging into 'scicom' as "anonymous", - you must use your full e-mail address as the password. For example: - greg.hankins@cc.gatech.edu + 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. + A white paper discussing serial communications and multiport serial boards was available from Cyclades at . -END OF Serial-HOWTO + + Appendix: Obsolete Hardware (prior to 1990) Info + +Replacing obsolete UARTS +

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 +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. + +

END OF Serial-HOWTO diff --git a/LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml b/LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml index 29086118..a501353c 100644 --- a/LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml +++ b/LDP/howto/linuxdoc/Text-Terminal-HOWTO.sgml @@ -2,10 +2,12 @@

Text-Terminal-HOWTO <author> David S. Lawyer <url url="mailto:dave@lafn.org"> -<date> v1.19, January 2001 +<date> v1.20, February 2001 <!-- Change log: +v1.20 Feb. 2001 Revised: Is hardware flow control done by hardware ?, +Bash bugs (with terminals), stuck key, PCTerm could work w/Linux v1.19 Jan. 2001 more on stuck on line 25, more on DEC MMJ cabling, dual signal ground wires, programs use terminfo w/o ncurses v1.18 Dec. 2000 mesg command, respawning error cause, chaos when 2 @@ -122,7 +124,9 @@ be a trademark). Such trademarks belong to their respective owners. 1.11 (1997) by Greg Hankins (with his permission). His "How Do I Set Up A Terminal Connected To My PC?" was incorporated into v1.00 at various places. v1.09 has about 25 changes (and error corrections) -suggested by Alessandro Rubini who reviewed this HOWTO. +suggested by Alessandro Rubini who reviewed this HOWTO. Jeremy Jon +Spykerman told me about using a keyboardless terminal as a console for +a monitorless PC (using ttysnoop). <sect1> Future Plans: You Can Help <p> Please let me know of any errors in facts, opinions, logic, @@ -153,9 +157,9 @@ 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/Text-Terminal-HOWTO.html">. The -version your are currently reading is: v1.19, January 2001 . New in this version: -v1.19 more on stuck on line 25, more on DEC MMJ cabling, dual signal -ground wires, programs use terminfo w/o ncurses +version your are currently reading is: v1.20, February 2001 . New in this version: +v1.20 Feb. 2001 Revised: Is hardware flow control done by hardware ?, +Bash bugs (with terminals), stuck key, PCTerm could work w/Linux <sect1> Related HOWTOs, etc. <label id="related_howtos"> <p> Go to the websites shown above to get these. @@ -306,7 +310,7 @@ mapped images. However, this term is sometimes applied also to text-only terminals since text is a limited form of graphics. <label id="vector_graphics"> -<sect2> Graphics Displays +<sect2> Graphics displays <p> There are two basic types of graphics displays: raster and vector (rarely used). Raster graphics (bit-mapped) puts dots on the screen by horizontal scan lines drawn by an electron beam (or by activating @@ -353,7 +357,7 @@ type is the "network computer" which is supposed to be platform neutral. This implies they should work with both MS Windows and Linux but early models may not be easy to use with Linux. -<sect2> Window Terminals +<sect2> Window terminals <p> These can run under MS Windows NT/2000 using a proprietary protocol. They are true terminals since all the computing work is done by the server running Windows. They are also called "Window-based Terminals" @@ -385,7 +389,7 @@ The above is sometimes called "network computing" since the terminals and servers connect to each other over a network. Network computers may be somewhat different as described below. -<sect2> Network Computers (NCs) +<sect2> Network computers (NCs) <p>These are neither true computers nor true terminals but are something in-between. One type of network computer (NC's) is a computer with a CPU but no hard Disk. The OS it needs to run is sent @@ -403,7 +407,7 @@ Wintel came out with a "NetPC" which, unlike the above, is almost a PC computer. However, it has no removable disks so users can't install their own software or obtain copies of anything. -<sect2> Thin Clients Under Linux +<sect2> Thin clients under Linux <p> Linux provides NFS (Network File System) so that if ordinary computers are connected to each other via a network, then a person on one computer can run programs on another computer. Such a program @@ -459,7 +463,7 @@ standard PC monitor and keyboard both of which plug into a small box which is a "thin" computer. This box provides an interface between the monitor/keyboard and the network. -<sect2> History and the Future +<sect2> History and the future <p> Promoters of NCs and related Window-Terminals projected that they would soon replace millions of PCs. In 1998 about 700,000 thin clients were sold with about 27% of them being NCs. But in 1999 only @@ -801,7 +805,7 @@ messages from the kernel regarding booting and shutdown progress. One may have the messages that normally go to the console, go to the terminal. To get this you must manually patch the kernel, except that for kernel 2.2 (or higher) it is a "make config" option. See <ref -id="term_as_console" name="Make a Terminal the Console">. +id="term_as_console" name="Make a Serial Terminal the Console">. <sect> Terminal Special Files such as /dev/tty <label id="devices_"> @@ -973,7 +977,7 @@ of such codes: escape sequences and control codes (control characters). There are many times more escape sequences than control codes. -<sect2> Control Codes <label id="control_codes"> +<sect2> Control codes <label id="control_codes"> <p> The control codes (or control characters) consist of the first 32 bytes of the ASCII alphabet. They include the following: carriage-return (cursor to far left), line-feed (cursor down one line), @@ -988,7 +992,7 @@ top or bottom of the screen will show up in other locations. The escape sequences to reposition the cursor display on the screen but the cursor doesn't move to where the escape sequence says. -<sect2> Escape Sequences <label id="esc_seq"> +<sect2> Escape sequences <label id="esc_seq"> <p> Since there are not nearly enough control codes to do everything (and for some reason, not all of them are utilized) many escape sequences are used. They consist of the "escape" (ESC) control @@ -1135,30 +1139,32 @@ character. The codes for a byte range from 0 to 255 (00 to FF in hexadecimal). In MS-DOS, character-set tables are called "code-pages". You should examine such a table if you're not familiar with them. They are sometimes included in printer and terminal manuals but also -may be found on the Internet. +are found on the Internet. ASCII is one of the most common character-sets used on text terminals. -It is a 7-bit code but can be made into 8-bit if the first bit (high -order bit) is always set to 0. Other character-sets are usually -available (except on very old terminals where the only choice is +It is a 7-bit code but will usually work OK even if your terminal is set +to 8-bit mode. In 8-bit mode with ASCII, the high order bit is always +set to zero. Other character-sets are usually available and often use +8-bit codes (except on very old terminals where the only choice is ASCII). The first half of most character-sets are the conventional -ASCII characters and the second half (the characters with the -high-order bit set to 1) belong to a wide variety of character-sets. -Character sets are often ISO standards. To get specialized character -sets on a terminal, you may need to download a soft-font for that -character-set into the memory of the terminal. +128 ASCII characters and the second half (with the high-order bit set +to 1) belong to a wide variety of character-sets. Character sets are +often ISO standards. To get specialized character sets on a terminal, +you may need to download a soft-font for that character-set into the +memory of the terminal. Many terminals have a few built-in character +sets (but perhaps not the one you need). -Besides ASCII, there are some other common character-sets, all 8-bit. -CP stands for Code Page character sets invented by IBM: CP-437 (DOS -ECS), CP-850 (Multilingual Latin 1 --not the same as ISO Latin-1), -ISO-8859-1 (Latin-1), ANSI (derived from Latin-1). MS Windows uses -ANSI while the Internet often uses Latin-1. There are several -ISO-8859 character sets in addition to Latin-1. These include Greek -(-7), Arabic (-6), Eastern European (-2), and a replacement for -Latin-1 (-15) called Latin-9. There are many others. For example, -KOI8-R is more commonly used for Russian than IS0-8859-5. Unicode is -a very large character-set where each character is represented by 2 -bytes instead on just one byte. +Here are some common 8-bit character sets. CP stands for Code Page +character sets invented by IBM: CP-437 (DOS ECS), ISO-8859-1 +(Latin-1), CP-850 (Multilingual Latin 1 --not the same as ISO +Latin-1), ANSI (derived from Latin-1). MS Windows uses ANSI while the +Internet often uses Latin-1. There are several ISO-8859- character +sets in addition to Latin-1. These include Greek (-7), Arabic (-6), +Eastern European (-2), and a replacement for Latin-1 (-15) called +Latin-9. There are many others. For example, KOI8-R is more commonly +used for Russian than IS0-8859-5. Unicode is a very large +character-set where each character is represented by 2 bytes instead +on just one byte. More info re character-sets are: <itemize> @@ -1319,7 +1325,7 @@ other non-Latin alphabets) while xcin is for Chinese. There is also has a built-in editor and scroll-bars. It was designed for Plan 9, a Unix-like operating system from AT&T. -<sect2> Real Terminals Better +<sect2> Real terminals better <p> Unless you are using X-Windows with a large display, a real terminal is often nicer to use than emulating one. It usually costs less, has better resolution for text, and has no disk drives to make @@ -1356,8 +1362,8 @@ Many commands exist (see Keyboard-and-Console-HOWTO) to utilize these added features. Real terminals, which use neither scan codes nor VGA cards, unfortunately can't use most of these features. One may recompile Linux to make a terminal receive the messages which normally -go to the console. See <ref id="term_as_console" name="Make a Terminal -the Console">. +go to the console. See <ref id="term_as_console" name="Make a Serial +Terminal the Console">. <sect1> Emulation Software <p> Emulators often don't work quite right so before purchasing @@ -1595,7 +1601,7 @@ the DSR pin is not used. For DTR/DSR flow control at a terminal, the DTR signal is like the signal sent from the RTS pin and the DSR pin is just like the CTS pin. -<sect2> Connecting Up DTR or DTR/DSR Flow Control +<sect2> Connecting up DTR or DTR/DSR Flow Control <p> Some terminals use only DTR flow control. This is only one-way flow control to keep the terminal from being overrun. It doesn't protect the computer from someone typing too fast for the computer to @@ -1613,7 +1619,7 @@ your terminal supports this two-way flow control) you do the above. But you also connect the DSR pin at the terminal to the RTS pin at the computer. Then you are protected if you type too fast. -<sect2> Old RTS/CTS Handshaking Is Different +<sect2> Old RTS/CTS handshaking is different <p> What is confusing is that there is the original use of RTS where it means about the opposite of the previous explanation above. This original meaning is: I Request To Send to you. This request was @@ -1638,34 +1644,34 @@ There may be a dip switch to set the polarity of this signal. <sect1> Is Hardware Flow Control Done by Hardware ? <p> Some think that hardware flow control is done by hardware but -(unless you are using an intelligent serial card with several serial -ports) it's actually done by your operating system software. UART -chips and associated hardware usually know nothing at all about -hardware flow control. When a hardware flow control signal is -received, the signal wire flips polarity and the hardware gives an -electrical interrupt signal to the CPU. However, the hardware has no -idea what this interrupt means. The CPU stops what it was doing and -jumps to a table in main memory that tells the CPU where to go to find -a program which will find out what happened and what to do about it. +only a small part of it is done by hardware. Most of it is actually +done by your operating system software. UART chips and associated +hardware usually know nothing at all about hardware flow control. +When a hardware flow control signal is received (due to the signal +wire flipping polarity) the hardware gives an electrical interrupt +signal to the CPU. However, the hardware has no idea what this +interrupt means. The CPU stops what it was doing and jumps to a table +in main memory that tells the CPU where to go to find a program which +will find out what happened and determine what to do about it. In +this case this program stops the outgoing flow of bytes. -There's another way this could have been implemented since when the -polarity flips the hardware could have been configured to send an -electrical interrupt signal to the CPU. Then the CPU would stop what -it was doing, jump to a service routine of the serial driver, check -registers in the serial hardware to find out what happened, and make a -note not to resume the flow after the service routine is exited. This -might be a little more efficient, but it seems that Linux doesn't -do it this way. I once thought it did. +But even before this program stops the flow, it was already stopped by +the interrupt which interrupted the work of the CPU. This is one +reason why hardware flow control stops the flow faster. It doesn't +need to wait for a program to do it. But if that program didn't +command that the flow be stopped, the flow would resume once +that program exited. So the program is essential to stop the flow +even though it is not the first to actually stop the flow. After the +interrupt happens any bytes (up to 16) which were already in the +serial port's hardware transmit buffer will still get transmitted. So +even with hardware flow control the flow doesn't instantly stop. -Note that with either method the flow of bytes stops nearly instantly. -However, any bytes (up to 16) which were already in the serial port's -hardware transmit buffer will still get transmitted. Using software -flow control requires that each incoming byte be checked to see if -it's an "off" byte. These bytes are delayed by passing thru the -16-byte receive buffer. If the "off" byte was the first byte into -this buffer, there could be a wait while 15 more bytes were received. -Then the 16 bytes would get read and the "off" byte found. This -extra delay doesn't happen with hardware flow control. +Using software flow control requires that each incoming byte be +checked to see if it's an "off" byte. These bytes are delayed by +passing thru the 16-byte receive buffer. If the "off" byte was the +first byte into this buffer, there could be a wait while 15 more bytes +were received. Then the 16 bytes would get read and the "off" byte +found. This extra delay doesn't happen with hardware flow control. <sect1> Obsolete ?? ETX/ACK or ENQ/ACK Flow Control <p> This is also software flow control and requires a device driver @@ -1712,7 +1718,7 @@ id="buy_or_make_cable" name="Buy or Make"> your own cable. Make sure you are connecting to your PC's serial port at the male DB25 or the DB9, and not to your parallel port (female DB25). -<sect2> Null Modem Cable Pin-out (3, 4, or 5 conductor) +<sect2> Null Modem cable pin-out (3, 4, or 5 conductor) <p> These 3 diagrams are for real text-terminals. But you could use them to connect up 2 PCs if you substitute RTS for DTR and CTS for DSR. (Don't use 4-conductors for PC-to-PC). For terminals, if you @@ -1757,15 +1763,17 @@ option to getty (which is equivalent to "stty clocal"). Also if you need hardware flow control it must be enabled at your computer (use a -h flag with agetty) ( equivalent to "stty crtscts" ). -<sect2> Standard Null Modem Cable Pin-out (7 conductor) +<sect2> Standard Null Modem cable pin-out (7 conductor) <label id="null_modem_pinout"> <p> The following 3 diagrams show full "standard" null modem cables. -One that you purchase is apt to be wired this way. They will work -fine for computer-to-computer connections. They also work for real -terminals using software (Xon/Xoff) flow control (or no flow control). -However, they don't work for terminal hardware flow control since most -real terminals support DTR or DTR/DSR flow control (handshaking) but -Linux doesn't. +One that you purchase may be wired this way. Another pinout is for 20 +and 6 to cross over and to have 8 cross over to both 4 and 5. This +will not provide hardware flow control (RTS/CTS) for directly +connected computers. Both of the above will work for terminals using +software (Xon/Xoff) flow control (or no flow control). None of these +cables will work for terminal hardware flow control since most real +terminals support DTR or DTR/DSR flow control (handshaking) but Linux +doesn't yet (2000). <tscreen><verb> PC male DB25 Terminal DB25 @@ -1799,8 +1807,8 @@ RTS Request To Send 7 --> 5 CTS Clear To Send CTS Clear To Send 8 <-- 4 RTS Request To Send (RI Ring Indicator 9 not needed) </verb></tscreen> -(Yes, the pins 2 and 3 <em/really do/ have the opposite meanings in -DB9 connectors than in DB25 connectors!) +(Yes, the pins 2 and 3 really do have opposite meanings for DB9 and +DB25 connectors!) Here's how to null-modem connect two DB9's together (but DTR flow control will not work): @@ -1836,7 +1844,7 @@ of the connector, connect RTS and CTS together, and also connect DSR, DCD and DTR together. This way, when the computer needs a certain handshaking signal to proceed, it will get it (falsely) from itself. -<sect2> Overcoming Length Limitations <label id="length_"> +<sect2> Overcoming length limitations <label id="length_"> <p> A cable longer than a 50 feet or so may not work properly at high speed. Much longer lengths sometimes work OK, especially if the speed is low and/or the cable is a special low-capacitance type and/or the @@ -1868,7 +1876,7 @@ the lowest impedance (due to lower inductance) if it flows back in the same twisted pair. Although I've haven't seen any experimental test results for this method, it should allow longer cable lengths. -<sect2> Hardware Flow Control Cables +<sect2> Hardware Flow Control cables <p> If you expect to use hardware flow control (handshaking) you will likely need to make up your own cable (or order one made). Of course, if the connecters on the ends of a used cable remove, you might rewire @@ -1882,7 +1890,7 @@ id="hdw_flow_control" name="Hardware Flow Control"> for a detailed explanation of it. Older terminals may have no provision for hardware flow control. -<sect2> Cable Tips +<sect2> Cable tips <p> The normal "straight thru" cable will not work unless you are using it as an extension cable in conjunction with either a null modem (crossover) cable or a null modem adapter. Make sure that the @@ -1891,7 +1899,7 @@ hardware. One may use telephone cable which is at least 4-conductor (and possibly twisted pair). Shielded, special low-capacitance cable computer cable is best. -<sect2> A Kludge using Twisted-Pair Cable <label +<sect2> A kludge using twisted-pair cable <label id="twist_pair_kludge"> <p> See also <ref id="length_" name="Overcoming Length Limitations">. Although none of the EIA-232 signals are balanced for twisted pair @@ -1906,7 +1914,7 @@ resistance calculations. This is especially true at higher frequencies since inductive impedance increases with frequency. The rectangular wave of the serial port contains high frequency harmonics. -<sect2> Cable Grounding +<sect2> Cable grounding <p> Pin 1 (of a DB25) should be chassis ground (also earth ground) but on cheap serial ports it may not even be connected to anything. A 9-pin connector doesn't even have a chassis ground. The signal ground @@ -1926,7 +1934,7 @@ Thus with an old terminal and external modem, one may connect to the Internet. If one connects to a host computer on which one has an account, then one may sometimes store ones work (or downloads) there. -<sect2> Dialing Out From a Terminal +<sect2> Dialing out from a terminal <p> Instead of connecting a terminal (or computer emulating a terminal) directly to a host computer using a cable it may be connected to the host via a telephone line (or dedicated private line) @@ -1946,7 +1954,7 @@ number. When the outgoing call is answered by another modem at the other end of the phone line, the the host computer on this modem may run a getty program to enable you to log in. -<sect2> Terminal Gets Dialed Into +<sect2> Terminal gets dialed into <p> It's common for a computer running Linux to get dialed into. The caller gets a login prompt and logs in. At first glance, it may seem strange how a dumb terminal (not connected to any computer) could @@ -2024,7 +2032,7 @@ Sometimes the purpose of the adapter is to interchange wires. Obviously, one may use a special cable (perhaps homemade) as a substitute for an adapter. -<sect2> Sex of Connector/Adapters +<sect2> Sex of connector/adapters <p> Connectors (or one side of adapters) are either male or female. The connectors that have pins are male and the ones that have sockets (sometimes also called pins) are female. For modular connectors, the @@ -2032,7 +2040,7 @@ ones with exposed contacts are plugs while the ones with internal contacts (not easy to see) are jacks. Plugs are male; jacks are female. -<sect2> Types of Adapters +<sect2> Types of adapters <p> There are three basic types of adapters: null modem, gender changers and port adapters. Some adapters perform more than one of these three functions. @@ -2044,7 +2052,7 @@ these three functions. to DB 25, etc.) </itemize> -<sect2> DB Connectors <label id="db_conn"> +<sect2> DB connectors <label id="db_conn"> <p> (For how to install a DB connector on the ends of a cable see <ref id="db_conn_install" name="Installing DB Connectors">.) These come in 9 or 25 pins. The EIA-232 specs. call for 25 pins but since most of @@ -2053,7 +2061,7 @@ sufficient. See <ref id="DB_pin-out" name="DB9-DB25"> for the pin-out. The pins are usually numbered if you look closely enough or use a magnifying glass. -<sect2> RJ Modular Connectors <label id="rj_conn"> +<sect2> RJ modular connectors <label id="rj_conn"> <p> These look like modern telephone connectors but are sometimes not compatible with telephone connectors. See also <ref id="rj_conn_install" name="Installing RJ Connectors">. They may be 6, @@ -2133,7 +2141,7 @@ serial cards and networks. Heres the pin numbers for an 8-conductor: </verb></tscreen> <sect1> Making or Modifying a Cable -<sect2> Buy or Make ? <label id="buy_or_make_cable"> +<sect2> Buy or make ? <label id="buy_or_make_cable"> <p> You may try to buy a short, null modem cable. Just a "modem cable" will not work. Null modem cables are often labeled as serial printer cables (but serial printers are not very popular today and @@ -2161,12 +2169,12 @@ One advantage of making your own cable is that the skills you learn will come in handy if a cable breaks (or goes bad) or if you need to make up another cable in a hurry. -<sect2> Pin Numbers +<sect2> Pin numbers <p> The numbers of the pins should be engraved in the plastic of the connector. Each pin should have a number next to it. You may need a magnifying glass to read them. -<sect2> Installing DB Connectors on Cable Ends <label id="db_conn_install"> +<sect2> Installing DB connectors on cable ends <label id="db_conn_install"> <p> See <ref id="db_conn" name="DB Connectors"> for a brief description of them. Unfortunately, most cables one purchases today have molded connectors on each end and can't be modified. Others have connectors @@ -2219,7 +2227,7 @@ hole or bend the pin:. Don't try soldering unless you know what you're doing or have read about how to do it. -<sect2> Installing RJ Connectors <label id="rj_conn_install"> +<sect2> Installing RJ connectors <label id="rj_conn_install"> <p> These are telephone modular connecters one type of which is used for most ordinary telephones. But there are many different types (see <ref id="rj_conn" name="RJ Modular Connectors">). @@ -2391,7 +2399,7 @@ the "stty" command but it seems to actually set them both the same.) Common speeds are 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, ... The slower speeds (like 600) are for printers and hard-copy terminals. -<sect2> Parity & Should You Use It ? <label id="parity_"> +<sect2> Parity & should you use it ? <label id="parity_"> <p> For a definition see <ref id="parity_def" name="Parity Explained">. Parity-disabled is often the default. To enable parity, you must both enable it and then select either even or odd parity. It probably @@ -2441,11 +2449,14 @@ disabled. <sect2> Bits/Character <label id="ch_size"> -<p> This is the character size (the number of data bits per -character excluding any parity bit). For ASCII it's 7, but it's 8 -for ISO character sets. If you are only going to use ASCII -characters, then select 7-bits since it's faster to transmit 7 bits -than 8. Some older terminals will only display 7-bit characters. +<p> This is the character size (the number of data bits per character +excluding any parity bit). To use international character sets you +need 8 bits. But it's not of much use unless your terminal has the +fonts for them. See <ref id="char_sets" name="Character-Sets"> If you +are only going to use ASCII characters, then select 7-bits since it's +faster to transmit 7 bits than 8. Some very old terminals only +support 7-bit characters. + <sect2> Which Flow Control (Handshaking) ? @@ -2468,7 +2479,7 @@ perhaps with unexpected results. They can't do this with hardware flow control. See <ref id="flow_control" name="Flow Control"> for an explanation of flow control. -<sect2> Port Select <label id="port_select"> +<sect2> Port select <label id="port_select"> <p> Since most terminals have two or more connectors on the back, it is usually possible to assign one of these connecters to connect to the host computer and assign another connector to be the printer port. @@ -2581,7 +2592,7 @@ To exit set-up mode select exit from a menu (or on some older terminals press the set-up key again). <sect1> Communication Options -<p> For the terminal to work at all, speed, parity, bits/character, +<p> For the terminal to work at all, speed, parity, :its/character, and communication mode must be set correctly. Incorrect flow control may cause loss and/or corruption of data seen on the screen. The essential communication options were dealt with (for both the terminal @@ -2852,11 +2863,20 @@ keypad. control character CAN and shifted backspace sometimes sends DEL. <sect2> PC Scan Codes -<p> Newer terminals can emulate a PC keyboard by sending PC scan codes +<p> Many terminals can emulate a PC keyboard by sending PC scancodes (see Keyboard-and-Console-HOWTO) instead of ASCII codes. This would -be used if you were directly connected to a PC running Dos/Windows. -Set {Keycode} to {Scan}. Emulating the Dec "PCTerm" should do this -and more. A serial port under Linux can't cope with such scan codes. +be used if you were directly connected to a PC running Dos. For Wyse +set {Keycode} to {Scan}. Emulating the Dec "PCTerm" should do this +and more. However, hardly any Linux programs that run via the serial +port can accept scancodes. If this is the latest version of this +HOWTO, let me know if any programs do this. I think Foxpro can do it. +You need to define smsc and rmsc in the terminfo, and perhaps pctrm. + +When using scancodes it's best to use hardware flow control since +normal software flow control conflicts with some of the codes (??). +If you do use software flow control, you must use the XPC type of flow +control. It uses 0x65 and 0x67 for on and off characters. It must be +set this way both in the terminal and by stty for the PC. <sect2> Alternate Characters <p> Some keys may have alternative letters on them. When keys is set @@ -3040,14 +3060,14 @@ One does this by editing at the console (or from any working terminal). <p> In order to have a login process run on a serial port when the computer starts up (or switches run levels) a getty command must be put into the /etc/inittab file. Running getty from the command line -may cause problems (see <ref id="stopped_" name="Programs get -Stopped"> to see why ). Getty GETs a TTY (a terminal) going. Each -terminal needs its own getty command. There is also at least one -getty command for the console in every /etc/inittab file. Find this -and put the getty commands for the real terminals next to it. This -file may contain sample getty lines for text terminals that are -commented out so that all you need to do is to uncomment them (remove -the leading #) and change a few arguments. +may cause problems (see <ref id="stopped_" name="If getty run from +command line: Programs get stopped"> to see why ). Getty GETs a TTY +(a terminal) going. Each terminal needs its own getty command. There +is also at least one getty command for the console in every +/etc/inittab file. Find this and put the getty commands for the real +terminals next to it. This file may contain sample getty lines for +text terminals that are commented out so that all you need to do is to +uncomment them (remove the leading #) and change a few arguments. The arguments which are permitted depend on which getty you use:<newline> @@ -3057,12 +3077,12 @@ Two gettys best for directly connected terminals are: files. See <ref id="agetty_" name="Agetty"> <item> <ref id="getty_ps" name="getty (part of getty_ps)"> </enum> -Two gettys best for modems (avoid for terminals) are: +Two gettys best for modems (avoid for directly connected terminals) are: <enum> <item> mgetty: the best one for modems; works for terminals too but inferior <item> uugetty: for modems only; part of the getty_ps package </enum> -Simple gettys to use if you don't use a text-terminal. Most +Simple gettys to use if you don't use a real text-terminal. Most Linux users use one of these at their monitor: <enum> <item> mingetty @@ -3094,7 +3114,8 @@ the minimum number of 3 conductors: transmit, receive, and common signal ground) you should let getty know this by using a "local" flag. The format of this depends on which getty you use. -<sect2> Programs get Stopped <label id="stopped_"> +<sect2> If getty run from command line: Programs get stopped + <label id="stopped_"> <p> You should normally run getty from inside <tt>/etc/inittab</tt> and not from the command line or else some programs running on the terminal may be unexpectedly suspended (stopped). Here's why (skip to @@ -3197,8 +3218,8 @@ DT19200# B19200 CS8 CLOCAL # B19200 SANE -ISTRIP CLOCAL #@S @L login: #DT19200 # 9600 bps Dumb Terminal entry DT9600# B9600 CS8 CLOCAL # B9600 SANE -ISTRIP CLOCAL #@S @L login: #DT9600 </verb></tscreen> -<p> Note that the DT number you use here must be the same as the DT -number that you use in <tt>/etc/inittab</tt>. +<p> Note that the DT38400, DT19200, etc. are just labels and must +be the same that you use in <tt>/etc/inittab</tt>. If you want, you can make <tt/getty/ print interesting things in the login banner. In my examples, I have the system name and the serial @@ -4216,21 +4237,25 @@ its functionality. <sect1> Problems with Editors <p> There may be some problems with using both emacs and vi on some -terminals. +terminals. A few terminals have no escape key (ESC) so you may need +to type Ctrl-[ to get ESC. -<sect2> emacs and ^S, ^Q +<sect2> emacs <p> If software flow control exists, then the ^S command in emacs will -freeze the display. The ^Q command will unfreeze the display. The +freeze the display. The ^Q command will unfreeze the display. One fix is to map this to another key-press by configuring emacs that way. +Some terminals have meta keys although you may need to setup the +terminal to create a meta key. <sect2> vi and Cursor-Keys <label id="vi_k_keys"> -<p> Vi uses the esc-key as a command to exit insert mode. If one hits -an arrow-key (cursor-key) an escape sequence (starting with the ESC -character) is sent to the host. Vi must distinguish between these two -meanings of ESC. A smart vi (such as vim if configured for it) is -able to detect the difference by noting the time between the ESC and -the next key. If it's a short time, then it's likely that a cursor -key was pressed. Use "help cursor-keys" in vim to find out more. +<p> Vi uses the esc-key as a command to exit insert mode. +Unfortunately for most terminals the arrow-keys send an an escape +sequence (starting with the ESC character) to the host. Vi must +distinguish between these two meanings of ESC. A smart vi (such as +vim if configured for it) is able to detect the difference by noting +the time between the ESC and the next key. If it's a short time, then +it's likely that a cursor key was pressed. Use "help cursor-keys" in +vim to find out more. Here's another way to fix this. On VT terminals the left-arrow-key may be either set to send ESC [ D or ESC O D. The other arrow keys @@ -4250,7 +4275,7 @@ enable the function (and related) keys (including the arrow keys). An application enables these keys by sending the "ks" string to the terminal. Whoever wrote the termcap reasoned that if an application wants to enable these keys, then they should be put into "Application -Mode" since this is an "application", but you don't want this. +Key Mode" since this is an "application", but you don't want this. The Linux console has no "ks" string so you can't fall into this trap at the console. For other terminals you may need to edit the termcap @@ -4264,6 +4289,41 @@ O D (so you don't need to edit termcap): See vim help for keys to see what they send but they may be set to send something different when you're in an editor. +<sect1> Bugs in Bash <label id="bash_bug"> +<p> There have been problems with the readline interface to the Bash +shell. Bash 2.01 (1998) had a readline interface which was quite +corrupted if one used a dumb terminal. This was fixed in later +versions. One problem still outstanding is that if certain terminal +keys send bytes with the high order bit set to 1, then Bash seems to +ignore the terminfo entries for them. I've reported this as a bug in +Bash. Other programs such as the vim editor and the lynx browser work +OK with such keys. + +To work around this problem one may define what these keys should do +in Bash by putting such definitions into <tt>/etc/inputrc.</tt> For +example, A Wyse 60 will send D0-D3 when the arrow-keys are hit +provided the terminal is in "application key mode". After modifying +the terminfo to reflect this, they still wouldn't work on the command +line in the Bash shell. So I explicitly defined the arrow-keys in +<tt>/etc/inputrc</tt> like this: + +<tscreen><verb> +# Arrow keys in 8 bit keypad mode: Sends d0-d4. -ap means application. +$if term=wy60-25-ap +set enable-keypad on +"\xd0": backward-char +"\xd1": forward-char +"\xd2": next-history +"\xd3": previous-history +$endif +</verb></tscreen> + +If the terminal is already in "application key mode" there's no need +to "set enable-keypad on". enable-keypad will send the terminal the +escape sequence named smkx in terminfo (which for wyse60 is \E~3 and +makes the arrow keys send D1-D3). Many other application send this +without needing to be told to do so. + <sect1>Color ls Corruption <p> If <tt/ls/ is corrupting your terminal emulation with the color feature, turn it off. <tt/ls --color/, and <tt/ls --colour/ all use @@ -4277,10 +4337,10 @@ have <tt/ls/ do color for the console and do monochrome for terminals. on the terminal (or in some cases displays but doesn't do anything). If what you type is invisible (or does nothing) type ^Q to restart flow (if flow control stopped it). Hanging may also be due to:<newline> -<ref id="sent_bin" name="Sent Terminal Binary"> or -<ref id="abnormal_exit" name="Abnormally Exited a Program"><newline> -If you didn't do any of these two, then your program could by buggy or -you interaction with it fatally illegal. +<ref id="sent_bin" name="Sent terminal binary"> or +<ref id="abnormal_exit" name="Abnormally exited a program"><newline> +If you didn't do any of these two, then the program you're running +could by buggy or you interaction with it fatally illegal. If you want to quit the program you were running and you can't do it by the usual methods (some programs have special keys you must hit to @@ -4308,7 +4368,7 @@ using hardware flow-control is to prevent such freezes. <p> This includes the case of a "frozen display" = "hung terminal" of the previous section. -<sect2> Symptoms and Some Fixes <label id="symptoms_"> +<sect2> Symptoms and some fixes <label id="symptoms_"> <p> When the display doesn't look right, or when what you type doesn't display correctly (if at all), or nothing happens when you type a command, you may have a corrupted terminal interface. In rare cases @@ -4328,12 +4388,12 @@ that the interface got corrupted by something you did. Three mistakes you might have made to corrupt the interface are: <itemize> -<item> <ref id="sent_bin" name="Sent Terminal Binary"> -<item> <ref id="abnormal_exit" name="Abnormally Exited a Program"> +<item> <ref id="sent_bin" name="Sent terminal binary"> +<item> <ref id="abnormal_exit" name="Abnormally exited a program"> <item> <ref id="ctrl_s" name="Typed ctrl-S by mistake"> </itemize> -<sect2> Sent Terminal Binary Characters <label id="sent_bin"> +<sect2> Sent terminal binary characters <label id="sent_bin"> <p> Your terminal will change its characteristics if sent certain escape sequences or control characters. It you inadvertently try to display a binary file, it might by chance contain such sequences which @@ -4365,7 +4425,7 @@ instead of fixing the problem, "reset" only compounds it by disabling communication between the terminal and computer. You will likely need to log in again and hope the getty sets "clocal". If you see a login prompt without asking for it, you're in luck. Otherwise see <ref -id="symptoms_" name="Symptoms and Some Fixes"> for how to get a login +id="symptoms_" name="Symptoms and some fixes"> for how to get a login prompt. You should try out "reset" before you need it and use "setterm -reset" if "reset" logs you out or otherwise doesn't work right. I submitted a bug report in Mar. 2000 so "reset" could be @@ -4375,8 +4435,8 @@ For the case where you see strange "graphic" characters instead of the normal ones, pressing ^O may switch back to the normal letters. The "reset" command also does this but it resets everything else too. -<ref id="symptoms_" name="Symptoms and Some Fixes"> -<sect2> Abnormally Exited a Program <label id="abnormal_exit"> +<ref id="symptoms_" name="Symptoms and some fixes"> +<sect2> Abnormally exited a program <label id="abnormal_exit"> <p> Large application programs (such as editors) often use the stty command (or the like) in their code to temporarily change the stty configuration when you are running the program. This may put the @@ -4472,7 +4532,7 @@ using Shift-PageUp. This is frequently needed since the scrolling is often too fast to stop using ^S. Once you've scrolled backwards Shift-PageDown will scroll forward again. -<sect2> Take Next Character Literally +<sect2> Take next character literally <p> ^V sends the next character typed (usually a control character) directly thru the device driver with no action or interpretation. Echoed back are two ASCII characters such as ^C. @@ -4547,7 +4607,7 @@ command line. Since "echo ..." will execute faster (since it doesn't do any lookups) it's good for using in shell scripts which run at start-up, etc. -<sect2> Saving Changes +<sect2> Saving changes <p> When you turn off the terminal the changes you made will be lost (unless you saved them in non-volatile terminal memory by going into set-up mode and saving it). If you want to use them again without @@ -4556,94 +4616,6 @@ shell function. Then run it when you want to make the changes. One way to make the changes semi-permanent is to put the commands in a file that runs each time you login or start up the computer. -<sect1> Serial Console <label id="term_as_console"> - -<p> This will turn a text-terminal (or emulator PC) into a "serial -console". Many messages from the system are normally only sent to the -console (the PC monitor). Some of the messages sent to the console at -boot-time may also be seen on any terminal after the boot succeeds by -typing the command: dmesg. If the boot failed this will not be of any -use since the terminal can't work without an operating system. It's -possible to modify the Linux kernel so as to make a terminal serve as -the console and receive all the messages from Linux intended for the -console. Unfortunately, the messages from the BIOS (which display on -the monitor when a PC is first started) will not display on this -terminal (but still display on the monitor). - -Some people do this when they run a PC without a monitor or keyboard. -Normally, a PC will not start up without a keyboard and video card but -some BIOSs permit it. If you are lucky enough to have such a BIOS -that supports "console re-direct" you will likely then need to setup -the BIOS using the CMOS menus when you start your PC. - -The method of creating a "serial console" depends on your kernel -version. In any case serial support needs to be compiled into the -kernel and not supplied as a module. - -<sect2> For Kernels 2.2 or higher -<p> The instructions for creating a serial-console are included with -source code documentation in the file: serial-console.txt. Normally, -the device /dev/console is linked to tty0 (the PC console). For a -serial-console you create a new /dev/console by -<tscreen><verb> -mknod -m 622 console c 5 1 -</verb></tscreen> -You must also put statements regarding the serial-console into -/etc/lilo.conf and then run lilo. This is because the equivalent of -"setserial" needs to be run early before the kernel is loaded so that -the serial-console can display the booting. See the above mentioned -documentation and the man page for lilo.conf for more details. - -Here is an example <tt>/etc/lilo.conf</tt> file contents (for ttyS0): -<tscreen><verb> -prompt -timeout=50 -boot = /dev/sda -vga = normal # force sane state -install = /boot/boot.b -message = /boot/message -image = /vmlinuz -root = /dev/sda1 -label = console -serial = 0,9600n8 -append = "console=ttyS0" -</verb></tscreen> - -<sect2> For Kernels before 2.2 -<p> The Linux Journal in April 1997 had an article on patching -the Linux kernel. You add a couple of #defines at the start of -src/linux/drivers/char/console.c: - -<tscreen><verb> -#define CONFIG_SERIAL_ECHO -#define SERIAL_ECHO_PORT 0x2f8 /* Serial port address */ - -The following was not in the Linux Journal article. -In kernel 2.+ (and earlier ??) you need to also set the baud -rate (unless 9600 is OK). Find these 2 lines: - -serial_echo_outb(0x00, UART_DLM); /* 9600 baud */ -serial_echo_outb(0x0c, UART_DLL); - -Change 0x0c in the line above (depending on the baud rate you want): - -115200 baud: 0x01 19200 baud: 0x06 2400 baud: 0x30 - 57600 baud: 0x02 9600 baud: 0x0c 1200 baud: 0x60 - 38400 baud: 0x03 4800 baud: 0x18 -</verb></tscreen> - -If you currently use the console to select which operating system to -boot (using LILO), but would like to do this from a terminal, then you -need to add a line to the /etc/lilo.conf file. See the manual page -for lilo.conf and search for "serial=". - -<sect2> Can I Run Linux without a Monitor (PC Console) ? -<p> Yes, you use a terminal and make it behave like the console per -above. You will likely still need a video card since most BIOSs -require one to get the PC started. Your BIOS may also require a -keyboard to get started or it may have an option where you can set the -BIOS not to require a keyboard. - <sect1> Multiple Sessions <p> The "<tt/screen/" package runs multiple sessions something like virtual terminals on the console: See <ref id="console_dev" name="The @@ -4740,11 +4712,190 @@ be different depending on whether a shell is running on it, whether it's at the "login" prompt, etc. Thus the stty configuration after switching runlevels may vary. +<sect> Special Uses for a Terminal +<sect1>Make a Serial Terminal the Console <label id="term_as_console"> + +<p> This will turn a text-terminal (or emulator PC) into a "serial +console". Many messages from the system are normally only sent to the +console (the PC monitor). Some of the messages sent to the console at +boot-time may also be seen on any terminal after the boot succeeds by +typing the command: dmesg. If the boot failed this will not be of any +use since the terminal can't work without an operating system. It's +possible to modify the Linux kernel so as to make a terminal serve as +the console and receive all the messages from Linux intended for the +console. Unfortunately, the messages from the BIOS (which display on +the monitor when a PC is first started) will not display on this +terminal (but still display on the monitor). + +Some people do this when they run a PC without a monitor or keyboard. +Normally, a PC will not start up without a keyboard and video card but +some BIOSs permit it. If you are lucky enough to have such a BIOS +that supports "console re-direct" you will likely then need to setup +the BIOS using the CMOS menus when you start your PC. + +The method of creating a "serial console" depends on your kernel +version. In any case serial support needs to be compiled into the +kernel and not supplied as a module. + +<sect2> For Kernels 2.2 or higher +<p> The instructions for creating a serial-console are included with +source code documentation in the file: serial-console.txt. Normally, +the device /dev/console is linked to tty0 (the PC console). For a +serial-console you create a new /dev/console by +<tscreen><verb> +mknod -m 622 console c 5 1 +</verb></tscreen> +You must also put statements regarding the serial-console into +/etc/lilo.conf and then run lilo. This is because the equivalent of +"setserial" needs to be run early before the kernel is loaded so that +the serial-console can display the booting. See the above mentioned +documentation and the man page for lilo.conf for more details. + +Here is an example <tt>/etc/lilo.conf</tt> file contents (for ttyS0): +<tscreen><verb> +prompt +timeout=50 +boot = /dev/sda +vga = normal # force sane state +install = /boot/boot.b +message = /boot/message +image = /vmlinuz +root = /dev/sda1 +label = console +serial = 0,9600n8 +append = "console=ttyS0" +</verb></tscreen> + +<sect2> For Kernels before 2.2 +<p> The Linux Journal in April 1997 had an article on patching +the Linux kernel. You add a couple of #defines at the start of +src/linux/drivers/char/console.c: + +<tscreen><verb> +#define CONFIG_SERIAL_ECHO +#define SERIAL_ECHO_PORT 0x2f8 /* Serial port address */ + +The following was not in the Linux Journal article. +In kernel 2.+ (and earlier ??) you need to also set the baud +rate (unless 9600 is OK). Find these 2 lines: + +serial_echo_outb(0x00, UART_DLM); /* 9600 baud */ +serial_echo_outb(0x0c, UART_DLL); + +Change 0x0c in the line above (depending on the baud rate you want): + +115200 baud: 0x01 19200 baud: 0x06 2400 baud: 0x30 + 57600 baud: 0x02 9600 baud: 0x0c 1200 baud: 0x60 + 38400 baud: 0x03 4800 baud: 0x18 +</verb></tscreen> + +If you currently use the console to select which operating system to +boot (using LILO), but would like to do this from a terminal, then you +need to add a line to the /etc/lilo.conf file. See the manual page +for lilo.conf and search for "serial=". + +<sect1> Run Linux without a Monitor +<p> One way to do this is to just use a terminal (serial console) for +the monitor See <ref id="term_as_console" name="Make a Serial Terminal +the Console">. You will likely still need a video card since most +BIOSs require one to get the PC started. Your BIOS may also require a +keyboard to get started or it may have an option where you can set the +BIOS not to require a keyboard. + +If you have a keyboardless terminal, it can also be used as a monitor +by use of the ttysnoop program. As of yet, it doesn't work like a +console since it doesn't get all the initial boot-time messages. See +<ref id="keyboardless_terminal" name="Use a Keyboardless Terminal as +the Monitor"> + +<sect1> Use a Keyboardless Terminal as the Monitor <label +id="keyboardless_terminal"> +<sect2> How it works +<p> While you might think that a terminal without a keyboard is +useless it is possible to use it as the monitor and type on the PC's +own keyboard. This may be done by using the spy program +<tt/ttysnoop/. This program permits a person at one terminal to spy +on (or snoop) what someone else is typing at another terminal (or the +PC console-monitor). + +Now suppose you are typing away at the monitor tty1. Imagine that +someone with a terminal on ttyS2 is spying on you (with ttysnoop) and +has a screen that looks just like your screen. Everything you type +at tty1 also displays on ttyS2. Now move the spy terminal (on ttyS2) +so it is side-by-side with your monitor (on tty1). Everything you +type on the PC keyboard (not the terminal keyboard) will now display +on the two screens in front of you: the monitor and the spy terminal. +Now just look only at the spy terminal as you type. Disconnect both +the monitor and the terminal keyboard since you're not using either. +Thus you are now using a keyboardless terminal as a monitor. What a +simple but clever solution! + +One possible problem (which turns out to be no problem at all) is +that normally, the type of spy terminal should be the same as the type +of terminal being spied upon. Since the monitor is normally declared +as a terminal of type "linux" (which is close to vt100), you might +think that the real terminal should also be (or at least emulate) a +vt100. Not necessarily so! For example, if you have a wyse60 +terminal you simply falsely declare that you have a wyse terminal on +tty1 (tell the getty program for tty1 that it's a wyse60). + +Here's why you can get away with this. Go back the the scenario where +you have both the monitor and the terminal in front of you, both +displaying the same thing (or trying to). If the terminal is a wyse60 +ttysnoop will be sending it the same bytes as are going to the monitor +(via its driver). Unfortunately, some of escape sequence for the +monitor (which an application program thinks is of type "linux") will +not be recognized by the wyse60 and the wyse60 display will be +corrupted. But this can be fixed as follows. + +At the monitor, falsely declare that it is a wyse60. Now when you use +an application program it sends wyse60 escape sequences to both the +monitor and the wyse60 terminal. The situation is now the other way +around. The display on the wyse60 is fine but the display on the +monitor is corrupted since it's getting wyse60 escape sequences. +Since you will not use the monitor (and are about to disconnect it) +the corruption is never a problem (you don't see it). + +A problem remaining is that ttysnoop should start eary in the boot +process so that you get the login prompt on the terminal. If you work +out how to do this (and this is the latest version of the HOWTO), let +me know. + +<sect2> One way to set it up +<p> This is not the ideal setup since ttysnoop runs so late that the +login prompt doesn't appear. This example is for a wyse60 terminal on +ttyS2 and the missing monitor/PC-keyboard on tty1. It uses the agetty +program for getty as supplied by the Debian distribution. Your getty +may require a different format. + +In <tt>/etc/inittab:</tt> +<tscreen><verb> +1:2345:respawn:/sbin/getty 38400 tty1 wyse60 -l /usr/sbin/ttysnoops +</verb></tscreen> +Note that <tt>ttysnoop/ttysnoops</tt> is a client-server combo so the +"s" is not a typo. + +In <tt>/etc/snooptab:</tt> +<tscreen><verb> +# tty snoopdev type execpgm +tty1 /dev/ttyS3 init /usr/local/bin/sterm +</verb></tscreen> +In the above, a script named sterm is used to run the stty program. +You may not need this or may want to use it for another purpose. +Here's the example sterm script in <tt>/usr/local/bin/sterm:</tt> + +<tscreen><verb> +#!/bin/sh +stty rows 24 +/bin/login $@ +</verb></tscreen> + <sect> Trouble-Shooting <label id="trouble_shoot"> <p> If you suspect that the problem is a hardware problem, see the <ref -id="repair_" name="Repair and Diagnose"> section. If the problem -involves the serial port itself see the Serial-HOWTO. +id="repair_" name="Repair and Diagnose"> section. If it's the keyboard +see <ref id="keyboards_" name="Keyboards">. If the problem involves +the serial port itself see the Serial-HOWTO. Here is a list of possible problems: <itemize> @@ -4752,14 +4903,14 @@ Here is a list of possible problems: Suspect the terminal is defective. <item><ref id="display_freezes" name="Display Freezes (hung terminal)"> -<ref id="keys_erratic" name="All Keys Work Erratically; Must Hit a Key - a Few Times"> +<item><ref id="types_garbage" name="Types Garbage"> Characters you + type are "foreign" letters/symbols. <item><ref id="flow_ctrl_ng" name="Missing Text"> Either skips over some text or displays some text OK and hangs. <item><ref id="keys_erratic" name="All Keys Work Erratically; Must Hit a Key a Few Times"> -<item><ref id="stopped_" name="Programs get Stopped"> with - message "Stopped" +<item><ref id="stopped_" name="If getty run from command line: Programs + get stopped"> with message "Stopped" <item><ref id="rapid_respawn" name="Getty Respawning Too Rapidly"> (console error message) <item><ref id="after_login" name="Fails Just After Login"> @@ -4894,6 +5045,18 @@ need to write to your terminal, it's reasonable not to use lockfiles. See Lock-Files in the Serial-HOWTO. <sect1> Getty Respawning Too Rapidly <label id="rapid_respawn"> + +<sect2> No modem control signal +<p> If getty can't open and/or use a port because of the lack of a +positive modem control voltage on one of the pins, then getty might +be killed. Then, per the instructions in inittab, getty respawns and +tries again, only to be killed again, etc., etc. You may see an error +message like: Getty respawning too fast: disabled for 5 minutes. +Instead of "Getty" it may give the label (such as S2) of the line in +/etc/inittab from where from where getty was called. Try using +the "local" option with getty and/or check the modem control settings +and voltages. + <sect2> No serial support <p> Linux provides serial support either by selecting it when compiling the kernel or by loading the serial module. This @@ -4901,21 +5064,13 @@ compiling the kernel or by loading the serial module. This into the kernel nor provided by a serial module. You many use the "lsmod" command to see if the serial module is loaded. -<sect2> No modem control signal -<p> If getty can't open and/or use a port because of the lack of a -positive modem control voltage on one of the pins, then getty might -be killed. Then, per the instructions in inittab, getty respawns and -tries again, only to be killed again, etc., etc. You may see an error -message indicating that due to getty respawning too rapidly it has been -temporarily disabled. Try using the "local" option with getty and/or -check the modem control settings and voltages. - -<sect2> Key Shorted <label id="key_shorted"> -<p> Another possible cause of getty respawning is if a keyboard key is -shorted, giving the same result as if the key was continuously held -down. With auto-repeat enabled, this "types" thousands characters to -the login prompt. Look for a screen filled with all the same -character (in some cases with 2 or more different characters). +<sect2> Key shorted <label id="key_shorted_getty"> +<p> Another possible cause of getty respawning too rapidly is if a +keyboard key is shorted, giving the same result as if the key was +continuously held down. With auto-repeat enabled, this "types" +thousands of characters to the login prompt. Look for a screen filled +with all the same character (in some cases with 2 or more different +characters). <sect1> Fails Just After Login <label id="after_login"> <p> If you can login OK but then you can't use the terminal it may be @@ -4976,15 +5131,16 @@ Try it with a return to see if it fixes it. <sect1> No Login Prompt <label id="no_login_prompt"> <p> If there's no login prompt displayed after hitting the return-key -a few times, first make sure that the terminal is powered on. Is the -computer it's connected to up and running? Use the "top" or "ps" -programs to make sure that a getty (or login) process is running on -the terminal. If getty isn't running, carefully check the format for -calling getty in /etc/inittab. Make sure that it includes the current -runlevel (shown by typing the command "runlevel") and that it is valid -for your flavor of getty. Sometimes killing getty (it will restart -automatically) helps. +a few times then check the following: Use the "top" or "ps" programs +to make sure that a getty (or login) process is actually running on +the terminal. Is the terminal getting power? Is the null modem cable +plugged in to the correct ports on both the terminal and computer? +If getty isn't running, carefully check the format for calling getty +in /etc/inittab. Make sure that it includes the current runlevel +(shown by typing the command "runlevel") and that it is valid for your +flavor of getty. Sometimes killing getty (it will restart +automatically) helps. <sect2> Terminal was working OK <p> Although hardware failures are possible, the problem is likely due @@ -5001,12 +5157,11 @@ mode, etc. At this point two different avenues of approach are (you may pursue more than one at a time). <itemize> -<item> <ref id="consoleD" name="Diagnose Problem from the Console"> -<item> Measure Voltages <ref id="measure_volts" name="Measure - Voltages"> +<item> <ref id="consoleD" name="Diagnose problem from the console"> +<item <ref id="measure_volts" name="Measure voltages"> </itemize> -<sect2> Diagnose Problem from the Console <label id="consoleD"> +<sect2> Diagnose problem from the console <label id="consoleD"> <p> One test is to try to copy a something to the terminal (It might be a good idea to try this near the start of the installation process before setting up getty). You may use the Linux copy command such as:"cp @@ -5018,7 +5173,7 @@ sure the baud rates and the bits/byte are the same. If nothing happens verify that the port is alive with a voltmeter per the next section. -<sect2> Measure Voltages <label id="measure_volts"> +<sect2> Measure voltages <label id="measure_volts"> <p> If you have a voltmeter handy check for a negative voltage (-4v to -15v) at pin 3 (receive data) at the terminal side of the null-modem cable. The positive lead of the meter should be connected to a good @@ -5046,6 +5201,22 @@ you could get a false high AC reading when looking at the idle DC of good device (such as another terminal or an external modem) to the serial port and see if it works OK. +<sect1> Types Garbage <label id="types_garbage"> + +<p> If what you see on the screen is not what you type but looks like +a foreign language, math symbols, line-drawing character, etc. then +it could be that the many of bytes that are echoed to your terminal +have the high order bit set (when it shouldn't be). You are looking +at the character set (or part of a character set) which has high order +bit set. This may happen if you have the baud rate set wrong. Try +stty -F /dev/ttyS? from another terminal to check if the baud rate is +correct. + +Perhaps the wrong character set (font) has been installed. An +erroneous escape sequence sent to the terminal could have switched +character sets. If you are using the mapchan program to change the +keyboard mapping, it could be incorrect. + <sect1> Slow: pauses of several seconds between bursts of characters <p> You likely have mis-set interrupts> See the Serial-HOWTO section starting with "Slow:" @@ -5107,7 +5278,7 @@ select "local" from a menu (or press a certain key). See <ref id="enter_setup" name="Getting Into Set-Up (Configuration) Mode">. <sect1> Serial Electrical Test Equipment -<sect2> Breakout Gadgets, etc. +<sect2> Breakout gadgets, etc. <p> While a multimeter (used as a voltmeter) may be all that you need for just a few terminals, simple special test equipment has been made for testing serial port lines. Some are called "breakout ... " where @@ -5124,7 +5295,7 @@ 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. -<sect2> Measuring Voltages +<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 @@ -5143,7 +5314,7 @@ clip into the desired opening. The paper clip's diameter should be no larger than the pins so that it doesn't damage the contact. Clip an alligator clip (or the like) to the paper clip to connect up. -<sect2> Taste Voltage +<sect2> Taste voltage <p> As a last resort, if you have no test equipment and are willing to risk getting shocked (or even electrocuted) you can always taste the voltage. Before touching one of the test leads with your tongue, test @@ -5384,12 +5555,6 @@ reduces the number of conductors needed (and reduces the number of pins needed on the chip). It's a similar scheme to what is called a "crossbar switch". -<sect2> One Press Types 2 Different Characters <label id="2chars"> -<p> If, due to a defect, conductors 3 and 4 become shorted together -then pressing the 3-B key will also short 4 and B and the chip will -think that both keys 3-B and 4-B have been pressed. This is likely to -type 2 different characters when all you wanted was one character. - <sect2> Modern vs Old Keyboards <p> While the modern keyboard and the old fashioned type look about the same, the mechanics of operation are different. The old ones have @@ -5401,18 +5566,25 @@ printed circuits (including contact points). When you press a key, the two "printed" sheets are pressed together at a certain point, closing the contacts printed on the sheets at that point. -<sect2> Keyboard Doesn't Work At All -<p> If none of the keys work try another keyboard (if you have one) to -verify that the keyboard is the problem. The most likely cause is a -broken wire inside the cord (cable) that connects it to the terminal. -The most likely location of the break is at either end of the cord. -Try wigging the ends of the cord while tapping on a key to see if it -works intermittently. If you find a bad spot, you may carefully cut -into the cord with a knife at the bad spot and splice the broken -conductor. Sometimes just a drop of solder will splice it. Seal up -the cord with electrical tape, glue, or caulk. +<sect2> One Press Types 2 Different Characters <label id="2chars"> +<p> If, due to a defect, conductors 3 and 4 become shorted together +then pressing the 3-B key will also short 4 and B and the chip will +think that both keys 3-B and 4-B have been pressed. This is likely to +type 2 different characters when all you wanted was one character. -<sect2> Typing b Displays bb, etc. (doubled) +<sect2> Keyboard doesn't work at all +<p> If none of the keys work try another keyboard (if you have one) to +verify that the keyboard is the problem. One cause is a broken wire +inside the cord (cable) that connects it to the terminal. The most +likely location of the break is at either end of the cord. Try +wigging the ends of the cord while tapping on a key to see if it works +intermittently. If you find a bad spot, you may carefully cut into +the cord with a knife at the bad spot and splice the broken conductor. +Sometimes just a drop of solder will splice it. Seal up the cord with +electrical tape, glue, or caulk. A keyboard that has gotten wet may +not work at all until it's dry. + +<sect2> Typing b displays bb, etc. (doubled) <p> If all characters appear double there is likely nothing wrong with the keyboard. Instead, your terminal has likely been incorrectly set up for half-duplex (HDX or local echo=on) and every character you type @@ -5421,29 +5593,55 @@ your host computer. If the two characters are not the same, there may be a short circuit inside your keyboard. See <ref id="2chars" name="One Press Types 2 Different Characters"> -<sect2> The Keyboard Types By Itself -<p> If a key is shorted out it is likely to type out a large number of -the same character if auto-repeat is enabled. If more than one key is -shorted out then repeating sequences of a few characters will be -typed. This may cause getty to respawn too fast if it happens at the -login prompt. See <ref id="key_shorted" name="Key Shorted">. The fix -is to clean the contacts per <ref id="clean_keys" name="Cleaning -Keyboard Contacts">. +<sect2> Row upon row of the same character appears +<p> This may happen when auto-repeat is enabled and a key is held +pressed down (or the like). It may be a key that sticks down when +typed or it could be an electrical short that has the same +effect. -<sect2> Liquid Spilled on the Keyboard +<sect3> Key sticks in down position (individual switches) +<p> If it's a stuck key on a keyboard with individual switches, a good +way to fix it is to remove the keycap (if it's removable). See +id="kbd_sw" name="Keyboards with individual switches">. Use a small +amount of cleaner on the push rod. Some keys stick due to stickiness +on the keycap bottom surface (and where it hits on the switch). If +the key sticks in the fully down position this could be the problem. +So clean this this area too. + +Hitting the key a lot to exercise it may help, but the problem is +likely to return. If you suspect the push rod is sticking you might +try to type it while pushing sideways on it with a small screwdriver. +You should push it sideways in one of the four directions and try +different directions. What you are doing by this is attempting to +force out a foreign particle that is rubbing on the side of the key's +push-rod and making it stick. Again, the problem may return later. + +To test the key, push it down very slowly and see if it sticks. Also +push it sideways a little as you're pushing it down. If you hit it +fast or push it straight down, then you may not observe the +stickiness. + +<sect3> Key electrically shorted +<p>If you suspect that a key is shorted out fix it by cleaning the +contacts per <ref id="clean_keys" name="Cleaning Keyboard Contacts">. +If this problem happens at the login prompt see <ref +id="key_shorted_getty" name="Key shorted">. + +<sect2> Liquid spilled on the keyboard <p> If water or watery liquid has been spilled on the keyboard (or if -it was exposed to rain, heavy dew, or dampness) some keys may not work -right. The dampness may cause a key to short out (like it was pressed -down all the time) and you may see the screen fill up with that letter -if auto-repeat is enabled. If it's gotten wet and then partially (or -fully) dried out, certain keys may not work due to deposits on the -contact surfaces. For the modern type of keyboard, one may readily -take apart the plastic sheets inside and dry/clean them. For the old -type one may let it dry out in the sun or oven (low temp.). When it's -dry it may still need contact cleaner on some keys as explained below. +it was exposed to rain, heavy dew, or dampness) some (or all) keys may +not work right. The dampness may cause a key to short out (like it +was pressed down all the time) and you may see the screen fill up with +that letter if auto-repeat is enabled. If it's gotten wet and then +partially (or fully) dried out, certain keys may not work due to +deposits on the contact surfaces. For the modern type of keyboard, +one may readily take apart the plastic sheets inside and dry/clean +them. For the old type one may let it dry out in the sun or oven (low +temp.). When it's dry it may still need contact cleaner on some keys +as explained below. -<sect2> Cleaning Keyboard Contacts <label id="clean_keys"> -<sect3> Keyboards with Membranes +<sect2> Cleaning keyboard contacts <label id="clean_keys"> +<sect3> Keyboards with membranes <p> On some newer keyboards, the plastic sheets (membranes) are easy to remove for inspection and cleaning if needed. You only need to remove several screws to take apart the keyboard and get to the @@ -5453,7 +5651,7 @@ glue to put back (probably not worthwhile to repair). Such a keyboard may sometimes be made to work by flexing, twisting, and/or pounding the assembly containing the plastic sheets. -<sect3> Keyboards with Individual Switches +<sect3> Keyboards with individual switches <label id="kbd_sw"> <p> What follows is for older keyboards that have separate hard plastic switches for each key. Before going to all the work of cleaning electrical contacts first try turning the keyboard @@ -5482,7 +5680,7 @@ liquid get under nearby keys where it may pick up dust and then seep (with the dust) into adjacent key switches. If you make this mistake you may fix one key but damage nearby keys. If this should happen, immediately work (repeatedly press) the affected nearby keys until -they work OK. +they continue to work OK. You might tilt the keyboard so that the cleaner flows better into the contacts. For the CIT101e terminal with an Alps keyboard, this means @@ -5528,7 +5726,7 @@ fly up into the air when taking apart a key switch. <sect1> List of Linux Terminal Commands -<sect2> Sending a Command to the Terminal +<sect2> Sending a command to the terminal <p><itemize> <item> <ref id="setterm_" name="setterm">: long options <item> <ref id="tput" name="tput">: terse options @@ -5537,7 +5735,7 @@ fly up into the air when taking apart a key switch. <item> setterm -reset: sends reset string </itemize> -<sect2> Configuring the Terminal Device Driver +<sect2> Configuring the terminal device driver <p><itemize> <item> <ref id="set_serial" name="Setserial">: <item> <ref id="stty_" name="Stty"> @@ -5586,7 +5784,7 @@ url="http://www.wyse.com/service/support/kbase/wyseterm.asp" <item> comp.terminals is the newsgroup for terminals </itemize> -<sect2> Books Related to Terminals +<sect2> Books related to terminals <p> <itemize> <item> EIA-232 serial port see <ref id="RS232_books" name="EIA-232 (RS-232) Books">. @@ -5596,7 +5794,7 @@ url="http://www.wyse.com/service/support/kbase/wyseterm.asp" name="Termcap Documents"> </itemize> -<sect2> Entire Books on Terminals +<sect2> Entire books on terminals <p> As far as I know, there is no satisfactory book on text terminals Although this HOWTO has been published as a book, I don't suggest that that you buy it if you have access to the online version which I'm @@ -5629,7 +5827,7 @@ used ANSI terminals used today on Unix-like systems. Although it does discuss them a little it doesn't show the various wiring schemes used to connect them to serial ports. -<sect2> Books with Chapters on Terminals +<sect2> Books with chapters on terminals <p> These chapters cover almost nothing about the terminals themselves and their capabilities. Rather, these chapters are mostly about how to set up the computer (and its terminal driver) to work with @@ -5816,7 +6014,7 @@ of the work. Today, the functionality of this chip is usually built into another chip. <sect1> Voltages -<sect2> Voltage for a Bit +<sect2> Voltage for a bit <p> At the EIA-232 serial port, voltages are bipolar (positive or negative with respect to ground) and should be about 12 volts in magnitude (some are 5 or 10 volts). For the transmit and receive @@ -5827,7 +6025,7 @@ normally both true and positive. Although the receive and transmit pins are inverted logic, other pins (modem control lines) are normal logic with a positive voltage being true (or "on" or "asserted") and a negative voltage being false (or "off" or "negated"). Zero voltage -has no meaning (except it usually means that the unit is powered off). +has no meaning (except it usually means that the PC is powered off). A range of voltages is allowed. The specs say the magnitude of a transmitted signal should be between 5 and 15 volts but must never @@ -5844,7 +6042,7 @@ was once the standard) so that if you try to use test equipment designed for testing 3-5 volt computer logic (TTL) on the 12 volts of a serial port, it may damage the test equipment. -<sect2> Voltage Sequence for a Byte <label id="byte_seq"> +<sect2> Voltage sequence for a byte <label id="byte_seq"> <p> The transmit pin (TxD) is held at -12 V (mark) at idle when nothing is being sent. To start a byte it jumps to +12 V (space) for the start bit and remains at +12 V for the duration (period) of the start @@ -6200,10 +6398,16 @@ url="http://www.wyse.com/products/gpt/index.htm" name="Wyse terminals">. <sect2> Wyse 60 <p> Display adjustments (must remove cover): Brightness VR202, Height -VR302, Width VR101 (also affects height). +VR302, Width VR101 (also affects height). If you want to use it in +Native Personality, then the arrow-key codes will conflict with the +codes used in vi (such as ^L). To fix this set "Application key mode" +with ESC ~ 3. This results in the arrow keys sending 0xd1 - 0xd4. +Due to a bug in the readline interface of the Bash shell, you need to +edit /etc/inputrc so that the arrow keys will work in Bash. See <ref +id="bash_bug" name="Bugs in Bash"> <sect2> Wyse 85 -<p> Can emulate VT52/T100/VT200. Press F3 for setup. Scroll thru +<p> Can emulate VT52/VT100/VT200. Press F3 for setup. Scroll thru setup with up/down keys. <sect2> Wyse 99-GT @@ -6281,3 +6485,4 @@ the set-up (confusing menu design). END OF Text-Terminal-HOWTO </article> +