Copyright (C) 2000-2012 |
Whole document tree 10. Interesting Programs You Should Know About10.1 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.
Introduction If you have a Laptop (PCMCIA) don't use Setserial can also show how the driver is currently set. In addition, it can be made to probe the hardware I0 port addresses to try to determine the UART type and IRQ, but this has severe limitations. See Probing. Note that it can't set the IRQ or the port address in the hardware of PnP serial ports (but the plug-and-play features of the serial driver may do this). It can't read the PnP data stored in configuration registers in the hardware. If you only have one or two built-in serial ports, they will usually
get set up correctly without using setserial. Otherwise, if you add
more serial ports (such as a modem card) you may need to deal with
setserial. Besides the man page for
Setserial does not set either IRQ's nor I/O addresses in the serial port hardware itself. That is done either by jumpers or by plug-and-play. You must tell setserial the identical values that have been set in the hardware. Do not just invent some values that you think would be nice to use and then tell them to setserial. However, if you know the I/O address but don't know the IRQ you may command setserial to attempt to determine the IRQ. You can see a list of possible commands by just typing
you'll see some info about how that device driver is configured for
your ports. Note that where it says "UART: unknown" it
probably means that no uart exists. In other words you probably have
no such serial port and the other info shown about the port is
meaningless and should be ignored. If you really do have such a
serial port, setserial doesn't recognize it and that needs to be
fixed.
If you add -a to the option -g you will see more info although few people need to deal with (or understand) this additional info since the default settings you see usually work fine. In normal cases the hardware is set up the same way as "setserial" reports, but if you are having problems there is a good chance that "setserial" has it wrong. In fact, you can run "setserial" and assign a purely fictitious I/O port address, any IRQ, and whatever uart type you would like to have. Then the next time you type "setserial ..." it will display these bogus values without complaint. They will also be officially registered with the kernel as displayed (at the top of the screen) by the "scanport" command. Of course the serial port driver will not work correctly (if at all) if you attempt to use such a port. Thus when giving parameters to "setserial" anything goes. Well almost. If you assign one port a base address that is already assigned (such as 3e8) it will not accept it. But if you use 3e9 it will accept it. Unfortunately 3e9 is already assigned since it is within the range starting at base address 3e8. Thus the moral of the story is to make sure your data is correct before assigning resources with setserial. While assignments made by setserial are lost when the PC is powered off, a configuration file may restore them (or a previous configuration) when the PC is started up again. In newer versions, what you change by setserial may get automatically saved to a configuration file. In older versions, the configuration file only changes if you edit it manually so the configuration always remains the same from boot to boot. See Configuration Scripts/Files
ProbingPrior to probing with "setserial", one may run the "scanport" command to check all possible ports in one scan. It makes crude guesses as to what is on some ports but doesn't determine the IRQ. But it's a fast first start. It may hang your PC but so far it's worked fine for me. With appropriate options, The purpose of this is to see if there is a uart there, and if so,
what its IRQ is. Use "setserial" mainly as a last resort as there are
faster ways to attempt it such as wvdialconf to detect modems, looking
at very early boot-time messages, or using Besides auto-probing for a uart type, setserial can auto-probe for
IRQ's but this doesn't always work right either. In one case it first
gave the wrong irq but when the command was repeated it found the
correct irq. In versions of setserial >= 2.15, the results of your
last probe test could be automatically saved and put into the
configuration file 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
happens anyway. Probing detects one serial port when actually there
are two. However if they have different IRQs, then the probe for IRQs
may show IRQ = 0. For me it only did this if I first used
Boot-time Configuration When the kernel loads the serial module (or if the "module
equivalent" is built into the kernel) then only To correct possible errors in IRQs (or for other reasons) there may be
a file somewhere that runs Before modifying a configuration file, you can test out a "proposed"
Configuration Scripts/FilesYour objective is to modify (or create) a script file in the /etc tree that runs setserial at boot-time. Most distributions provide such a file (but it may not initially reside in the /etc tree). In addition, setserial 2.15 and higher often have an /etc/serial.conf file that is used by the above script so that you don't need to directly edit the script that runs setserial. In addition just using setserial on the command line (2.15+) may ultimately alter this 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
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 "setserial" at boot time and edit it. If it doesn't exist, you need to create one (or place the commands in a file that runs early at boot-time). If such a file is currently being used it's likely somewhere in the /etc directory-tree. But Redhat <6.0 has supplied it in /usr/doc/setserial/ but you need to move it to the /etc tree before using it. You might use "locate" to try to find such a file. For example, you could type: locate "*serial*". The script If such a file is supplied, it should contain a number of
commented-out examples. By uncommenting some of these and/or
modifying them, you should be able to set things up correctly. Make
sure that you are using a valid path for For versions >= 2.15 (provided your distribution implemented the change, Redhat didn't) it may be more tricky to do since the file that runs setserial on startup, /etc/init.d/setserial or the like was not intended to be edited by the user. See New configuration method using /etc/serial.conf. If you want setserial to automatically determine the uart and the IRQ for ttyS3 you would add something like:
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:
New configuration method using /etc/serial.conf Prior to setserial version 2.15, the way to configure setserial
was to manually edit the shell-script that ran setserial at boot-time.
See
Edit a script (after version 2.15: perhaps not). Starting with version 2.15 (1999) of This was intended so that you don't need to edit any file in order to set up (or change) what setserial does each time that Linux is booted. But there are serious pitfalls because it's not really "setserial" that edits serial.conf. Confusion is compounded because different distributions handle this differently. In addition, you may modify it so that it works differently. What often happens is this: When you shut down your PC the script
that runs "setserial" at boot-time is run again, but this time it only
does what the part for the "stop" case says to do: It uses
"setserial" to find out what the current state of "setserial" is, and
it puts that info into the Now you can perhaps guess what problems might occur. Suppose you don't shut down normally (someone turns the power off, etc.) and the changes don't get saved. Suppose you experiment with "setserial" and forget to run it a final time to restore the original state (or make a mistake in restoring the original state). Then your "experimental" settings are saved. If you manually edit serial.conf, then your editing is destroyed when you shut down because it gets changed back to the state of setserial at shutdown. There is a way to disable the changing of serial.conf at shutdown and that is to remove "###AUTOSAVE###" or the like from first line of serial.conf. In at least one distribution, the removal of "###AUTOSAVE###" from the first line is automatically done after the first time you shutdown just after installation. The serial.conf file should contain some comments to explain this. The file most commonly used to run setserial at boot-time (in conformance with the configuration file) is now /etc/init.d/setserial (Debian) or /etc/init.d/serial (Redhat), or etc., but it should not normally be edited. For 2.15, Redhat 6.0 just had a file /usr/doc/setserial-2.15/rc.serial which you have to move to /etc/init.d/ if you want setserial to run at boot-time. To disable a port, use BUG: As of July 1999 there is a bug/problem since with ###AUTOSAVE### only the setserial parameters displayed by "setserial -Gg /dev/ttyS*" get saved but the other parameters don't get saved. Use the -a flag to "setserial" to see all parameters. This will only affect a small minority of users since the defaults for the parameters not saved are usually OK for most situations. It's been reported as a bug and may be fixed by now. In order to force the current settings set by setserial to be saved to
the configuration file (serial.conf) without shutting down, do what
normally happens when you shutdown: Run the shell-script
In some cases you may wind up with both the old and new configuration methods installed but hopefully only one of them runs at boot-time. Debian labeled obsolete files with "...pre-2.15".
IRQsBy default, both ttyS0 and ttyS2 will share IRQ 4, while ttyS1 and ttyS3 share IRQ 3. But actually sharing serial interrupts (using them in running programs) is not permitted unless you: 1. have kernel 2.2 or better, and 2. you've complied in support for this, and 3. your serial hardware supports it. See
If you only have two serial ports, ttyS0 and ttyS1, you're still OK since IRQ sharing conflicts don't exist for non-existent devices. If you add an internal modem and retain ttyS0 and ttyS1, then you should attempt to find an unused IRQ and set it both on your serial port (or modem card) and then use setserial to assign it to your device driver. If IRQ 5 is not being used for a sound card, this may be one you can use for a modem. To set the IRQ in hardware you may need to use isapnp, a PnP BIOS, or patch Linux to make it PnP. To help you determine which spare IRQ's you might have, type "man setserial" and search for say: "IRQ 11".
Laptops: PCMCIAIf you have a Laptop, read PCMCIA-HOWTO for info on the serial configuration. For serial ports on the motherboard, setserial is used just like it is for a desktop. But for PCMCIA cards (such as a modem) it's a different story. The configuring of the PCMCIA system should automatically run setserial so you shouldn't need to run it. If you do run it (by a script file or by /etc/serial.conf) it might be different and cause trouble. The autosave feature for serial.conf shouldn't save anything for PCMCIA cards (but Debian did until 2.15-7). Of course, it's always OK to use setserial to find out how the driver is configured for PCMCIA cards.
10.2 What is isapnp ?
10.3 What is wvdialconf ?
Next Previous Contents |