This package was originally put together by Bruce Perens It is now maintained for Debian by Gordon Russell Note that the standard setup for this package is such that you never have to change any of the configuration files. As standard, all configuration changes made during the on-time of the machine are lost on a shutdown or halt. Only the configuration which existed when the package was first installed is kept. If you are upgrading from a pre 2.15 version of setserial, the old 0setserial file from rc.boot is renamed. to 0setserial.pre-2.15. This will prevent it being run in the future, while still allowing previous modifications to this file to be preserved. The new setserial uses /etc/serial.conf for configuration, which has a new file format to previous versions. In "/etc/serial.conf", if the first line is "###AUTOSAVE###" then the file is automatically rebuilt on every shutdown or halt, storing all serial ports named "/dev/ttyS*" which ARE NOT "unknown port". This may be needed when the default io ports or irq lines are needed by another hardware device in your machine, and there exists in /dev ttyS which are not actually present in your machine (more common than you think). In "/etc/serial.conf", if the first line is "###AUTOSAVE-FULL###" then the file is automatically rebuilt on every shutdown or halt, storing all serial ports named "/dev/ttyS*", EVEN if they ARE "unknown port". Use this one with caution... it breaks things (like pcmcia configurations), and should only be needed by the brave! If the first line is '###AUTOSAVE-ONCE###', then the configuration of the serial ports is taken from the kernel on the next system shutdown, and stored in the /etc/serial.conf file. The first line is then moved to line 2 and a new line added at the beginning of the file. This will allow setserial to get your current port configuration once, and will never store it again over a reboot cycle. To enable the file to store your port setting once more, just delete the first line. To enable it to ALWAYS get your settings stored over reboots, make the first line "###AUTOSAVE###". AUTOSAVE-ONCE should be considered the safe option to choose (and is currently the default). If the first line is anything else, the file is never changed on a shutdown or halt. The idea of AUTOSAVE is to avoid having to edit any configuration files. You configure the ports needed using "setserial" directly, and changes you make are automatically saved on halt or shutdown for use next time. To ensure a change is saves, all that is required is that the port has its UART entry set to something other than "unknown". Setting it to "unknown" will result in the entry being deleted from /etc/serial.conf when the state is saved. However, if you have a bootup problem (like serial.o could not load due to a kernel update), the serial configuration will be lost. Eventually the kernel-detected ports will appear in the serial.conf file, but not other hand-crafted entries. AUTOSAVE-ONCE is propably best, put into the first line whenever you actually want changes to be made. If the serial module is unloaded from the kernel (perhaps because you have not used it for a few minutes and then it is reloaded), all changes you have made to the serial configuration are not reloaded by the serial module. Instead, setserial stores the state on an unload in /var/run/setserial.conf, and reloads the state as stored when the module reloads. If you have in serial.conf AUTOSAVE, it will also save the current state of the ports whenever you reboot. Aparently setserial will not save some ports properly, and under those circumstances you must do everything by hand in the serial.conf file. Remember to delete the AUTOSAVE line completely from the file or all the changes will be lost when the serial module next unloads or the system is shutdown. To delete an entry from /etc/serial.conf (say /dev/ttyS3), do /sbin/setserial /dev/ttyS3 uart unknown /etc/init.d/setserial stop To restore your settings as of the last save, do /etc/init.d/setserial start (Note that this will not delete ports you have created which do not appear in the /etc/serial.conf file) For some reason, pcmcia serial-based ports are controlled using pcmcia-cs, not setserial. Extensive filtering is in setserial to ensure that no status is ever saved (as of 2.15-7) which belongs to a pcmcia device. As of 2.17-4, this was changed so that, rather than filtering such things out, setserial now reports "pcmcia" for the device. However, you should not be using setserial to control or even monitor pcmcia serial ports. This reporting of pcmcia control by setserial is to allow pcmcia-cs to work correctly. If for some reason pcmcia-based serial configuration is appearing in /etc/serial.conf (and a good indication of this is that your pcmcia-based port is changing device names on every reboot until its installation fails) could you please email me the /etc/serial.conf file, the contents of /var/run/stab, and the output of "cardctl config", as I cannot understand why this is still a problem... If you had a version of 2.15 less than -7 in your system, and you have pcmcia problems, read the "pcmcia.repair" file. As an additional route to fixing problems with setserial, I have added to the configuration process an option called KERNEL, which will blank the serial.conf file and write a single comment "#KERNEL" at the beginning. This would seem a sensible option where you only have kernel-detectable serial devices and you are happy with the kernel default values. ---------------------------------- When the serial.o module is loaded (or is hard-coded) the options under which is was compiled should be visible. Often on a standard kernel you get something like: Serial driver version 4.27 with no serial options enabled With no serial options enabled, you only get 4 serial ports in the kernel, no matter how many you try to use in setserial. These are numbered 0 to 3. You cannot use numbers larger than 3 without recompiling the kernel. The number of the port is in itself irrelevent, so do not feel that a particular number is essential to get things to work. Users converting from other distributions may be confused, as port 13 or 14 seem to have been chosen automatically for them by their old distribution, but in reality this could have easily have been port 2. In standard systems, port 0 and 1 are the two motherboard serial devices, and 3 and 4 are unused. ---------------------------------- Gordon.