Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So, I have a board with 6 hardware serial ports: the first 2 on the ETX bus and the last 4 on the ISA bus. The following configuration is how it is supposed to be:

/dev/ttyS0 port 0x03F8 irq 4
/dev/ttyS1 port 0x02F8 irq 3
/dev/ttyS2 port 0x0100 irq 5
/dev/ttyS3 port 0x0108 irq 5
/dev/ttyS4 port 0x0110 irq 5
/dev/ttyS5 port 0x0118 irq 5

On startup, I run:

# dmesg | egrep -i 'serial|ttys'
Serial: 8250/16550 driver, 6 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:07: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A

# cat /proc/tty/driver/serial
Serinfo:1.0 driver revision:
0: uart:16550A port: 000003F8 irq:4 tx:0 rx:0
1: uart:16550A port: 000002F8 irq:3 tx:0 rx:0
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
4: uart:unknown port:00000000 irq:0
5: uart:unknown port:00000000 irq:0

So, I'm trying to use setserial to configure ports ttyS2-ttyS5 with the correct values:

# setserial /dev/ttyS2 irq 5 port 0x100 uart 16550A
# setserial /dev/ttyS3 irq 5 port 0x108 uart 16550A
# setserial /dev/ttyS4 irq 5 port 0x110 uart 16550A
Cannot set serial info: Invalid argument
# setserial /dev/ttyS5 irq 5 port 0x118 uart 16550A
Cannot set serial info: Invalid argument

Even taking out the uart option from the last command:

# setserial /dev/ttyS4 irq 5
Cannot set serial info: Invalid argument

What do I need to do to get ttyS4 and ttyS5 configured through setserial?

share|improve this question
Do you actually have 6 serials devices? Do you have a usbtoserial driver loaded? Can you provide some info on your hardware and drivers? – forcefsck Mar 18 '11 at 14:55
Edited my original post with additional info. – Ryan Mar 18 '11 at 15:00
Maybe you only see ports S2-S5. dmesg|egrep -i 'serial|ttys' output? – forcefsck Mar 18 '11 at 15:10
Updated my original post with the output from dmesg as well as some more information – Ryan Mar 18 '11 at 16:07
are you sure that the UART controller for other 4 ports is also 16550A ? – rajaganesh87 Apr 14 '11 at 13:24

A couple of things strike me about what I see in your /proc and dmesg output:

  • You shouldn't try to share an IRQ between devices. It may work, but the intention with ISA is that each device on the bus that needs an interrupt line to work gets its own IRQ. If your serial port cards don't give you enough IRQ options, you may simply not be able to use them all together in that PC.

  • The I/O addresses you are using for the second pair of serial ports are nonstandard. ttyS2 is normally at 0x3E8 and ttyS3 is normally at 0x2E8. I would move those if you have that option with the serial card. (There are no standard I/O addresses or IRQs for ttyS4 and up.)

Aside from all that, if I needed 6 serial ports on a Linux box, I wouldn't try to use plain old serial port adapter cards. I would use something like a Digi AccelePort. They still offer one that will work in your ISA slots, the Xe model. If you need cheap, you should be able to find one floating around on the used market; they were very popular back in the day.

share|improve this answer
Updated my original post with the output from cat as well as some more information – Ryan Mar 18 '11 at 16:07
I'm using an embedded board. By ISA bus I didn't mean a physical ISA card but rather a quad serial controller hardwired on the board. I don't understand why S2 and S3 need to use nonstandard addresses but that was what I was told from a tech to use for those COMs. – Ryan Mar 18 '11 at 17:10
In that case, I would ask on electronics.stackexchange.com whether anyone has run Linux on that particular board and gotten it to see all 6 serial ports. I doubt your problem is actually Linux here, but rather the hardware. If so, your question is not on topic. – Warren Young Mar 18 '11 at 17:28

Try adding 8250.nr_uarts=6 or nr_uarts=6 in your kernel boot parameters.

Edit: Some info that might help (hopefully).

share|improve this answer
Well, I already had CONFIG_SERIAL_8250_RUNTIME_UARTS set to 6 in my kernel config, but I tried both of these (separately) as a boot parameter and it had no effect to what I'm seeing. – Ryan Mar 18 '11 at 16:46
There is also CONFIG_SERIAL_8250_NR_UARTS, but according to documentation this should be overridden by 8250.nr_uarts parameter. v0v – forcefsck Mar 18 '11 at 17:07
Actually according to the help in 2.6.37 kernel config, CONFIG_SERIAL_8250_RUNTIME_UARTS corresponds to the number of serial ports the kernel will register at boot time and can be overridden by the boot time parameter "8250.nr_uarts". CONFIG_SERIAL_8250_NR_UARTS is the number of serial ports I want the 8250 driver to support (maximum). In my kernel config CONFIG_SERIAL_8250_NR_UARTS=32 and CONFIG_SERIAL_8250_RUNTIME_UARTS=6 – Ryan Mar 18 '11 at 17:19

Try to use the baud_rate 115200 parameter for setserial

share|improve this answer

I know this question was posted in March 2011, but I encountered the same problem on Debian recently, but have found the relatively obscure cause/solution.

As I'm sure you know, increasing the number of /dev/ttySX serial devices beyond the default of four (/dev/ttyS0 through ttyS3) is easiest done with a boot flag in grub (as changing the default requires recompiling the kernel)

After booting these new ttyS devices are empty (Port, IRQ, UART etc values are all set to zero).

After experimenting here, it turns out the reason is you're trying to configure a port with a zero base baud. Unfortunately, it starts off as zero.

However, when you try to change a port without specifying the base baud, it is possible for the port to become "usable" and unless we enforce the "must not have zero base baud" rule we have the possibility to oops the kernel via a divide by zero.


What you must do is specify the base_baud value before you do anything else. If I recall correctly, base_baud 115200 worked for me.

share|improve this answer

In addition to base_baud as mentioned in my other answer on this question, it may also be the order of arguments: (I didn't have time to experiment with different orders to see what exactly fixed it, as base_baud definitely worked)

I ran into a similar set of issues trying to get new serial ports installed into an embedded x86 application. The issue for me turned out to be that the setserial program converts its command line arguments, in order, into corresponding ioctl() operations to set the various device parameters. Basically, setserial applied a strategy of: 1)read the current setting for the specific /dev/ttySx 2)modify the values as specifid by each command line arg, with each individual command line argument or flag turning into an ioctl

So, specifying the uart type (or autoconfigure) before you specify the port or irq won't work correctly for ports greater the /dev/ttyS3, because the port value for /dev/ttyS3 isn't initialized to anything. This causes the ioctl() operation to return with errno set to EINVAL (invalid argument). I suspect the chain of ioctl()'s that ^fourport flag followed by low_latency flag turn into something that doesn't make sense to the driver. https://bugzilla.kernel.org/show_bug.cgi?id=8458

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.