3

I have installed an 8-port PCI based serial card from Sunix in my Ubuntu PC.

A probe through lspci -v shows the following:

03:02.0 Multiport serial controller: SUNIX Co., Ltd. Multiport serial controller
        Subsystem: SUNIX Co., Ltd. Multiport serial controller
        Flags: medium devsel, IRQ 18
        I/O ports at 2100 [size=32]
        I/O ports at 2000 [size=256]
        I/O ports at 2120 [size=16]
        Capabilities: <access denied>
        Kernel driver in use: serial

Also, the following is the output of ls /dev/ttyS*:

/dev/ttyS0   /dev/ttyS11  /dev/ttyS14  /dev/ttyS17  /dev/ttyS2   /dev/ttyS22  /dev/ttyS25  /dev/ttyS28  /dev/ttyS30  /dev/ttyS5  /dev/ttyS8
/dev/ttyS1   /dev/ttyS12  /dev/ttyS15  /dev/ttyS18  /dev/ttyS20  /dev/ttyS23  /dev/ttyS26  /dev/ttyS29  /dev/ttyS31  /dev/ttyS6  /dev/ttyS9
/dev/ttyS10  /dev/ttyS13  /dev/ttyS16  /dev/ttyS19  /dev/ttyS21  /dev/ttyS24  /dev/ttyS27  /dev/ttyS3   /dev/ttyS4   /dev/ttyS7

Now, I was expecting any of the above 8 to be my serial port devices and set to figure out which using the udevadm utility as follows:

udevadm info -a -p $(udevadm info -q path -n /dev/ttyS<0-31>)

And strangely, there are not 8, but just a single port (/dev/ttyS5) which can be accessed. Only 2 among the 32 (0-31, yeah, I actually probed each one of them!) were detected with a SUBSYSTEMS=="pci" attribute; udevadm info -a -p $(udevadm info -q path -n /dev/ttyS4) gives the following output:

looking at device '/devices/pci0000:00/0000:00:16.3/tty/ttyS4':
    KERNEL=="ttyS4"
    SUBSYSTEM=="tty"
    DRIVER==""

looking at parent device '/devices/pci0000:00/0000:00:16.3':
    KERNELS=="0000:00:16.3"
    SUBSYSTEMS=="pci"
    DRIVERS=="serial"
    ATTRS{broken_parity_status}=="0"
    ATTRS{class}=="0x070002"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{d3cold_allowed}=="1"
    ATTRS{device}=="0x1c3d"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{driver_override}=="(null)"
    ATTRS{enable}=="1"
    ATTRS{irq}=="17"
    ATTRS{local_cpulist}=="0-7"
    ATTRS{local_cpus}=="00ff"
    ATTRS{msi_bus}=="1"
    ATTRS{numa_node}=="-1"
    ATTRS{subsystem_device}=="0x047e"
    ATTRS{subsystem_vendor}=="0x1028"
    ATTRS{vendor}=="0x8086"

looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

and udevadm info -a -p $(udevadm info -q path -n /dev/ttyS5) gives the following output:

looking at device '/devices/pci0000:00/0000:00:1e.0/0000:03:02.0/tty/ttyS5':
  KERNEL=="ttyS5"
  SUBSYSTEM=="tty"
  DRIVER==""

looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:03:02.0':
  KERNELS=="0000:03:02.0"
  SUBSYSTEMS=="pci"
  DRIVERS=="serial"
  ATTRS{broken_parity_status}=="0"
  ATTRS{class}=="0x070200"
  ATTRS{consistent_dma_mask_bits}=="32"
  ATTRS{d3cold_allowed}=="1"
  ATTRS{device}=="0x1999"
  ATTRS{dma_mask_bits}=="32"
  ATTRS{driver_override}=="(null)"
  ATTRS{enable}=="1"
  ATTRS{irq}=="18"
  ATTRS{local_cpulist}=="0-7"
  ATTRS{local_cpus}=="00ff"
  ATTRS{msi_bus}=="1"
  ATTRS{numa_node}=="-1"
  ATTRS{subsystem_device}=="0x0008"
  ATTRS{subsystem_vendor}=="0x1fd4"
  ATTRS{vendor}=="0x1fd4"

looking at parent device '/devices/pci0000:00/0000:00:1e.0':
  KERNELS=="0000:00:1e.0"
  SUBSYSTEMS=="pci"
  DRIVERS==""
  ATTRS{broken_parity_status}=="0"
  ATTRS{class}=="0x060401"
  ATTRS{consistent_dma_mask_bits}=="32"
  ATTRS{d3cold_allowed}=="0"
  ATTRS{device}=="0x244e"
  ATTRS{dma_mask_bits}=="32"
  ATTRS{driver_override}=="(null)"
  ATTRS{enable}=="1"
  ATTRS{irq}=="0"
  ATTRS{local_cpulist}=="0-7"
  ATTRS{local_cpus}=="00ff"
  ATTRS{msi_bus}=="1"
  ATTRS{numa_node}=="-1"
  ATTRS{subsystem_device}=="0x047e"
  ATTRS{subsystem_vendor}=="0x1028"
  ATTRS{vendor}=="0x8086"

looking at parent device '/devices/pci0000:00':
  KERNELS=="pci0000:00"
  SUBSYSTEMS==""
  DRIVERS==""

In addition, I checked the output of sudo setserial -g /dev/ttyS[0123456789] too:

/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: 16550A, Port: 0x4140, IRQ: 17
/dev/ttyS5, UART: 16550A, Port: 0x2100, IRQ: 18
/dev/ttyS6, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS7, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS8, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS9, UART: unknown, Port: 0x0000, IRQ: 0

The remaining 22 ports/devices returned a similar result /dev/ttyS31, UART: unknown, Port: 0x0000, IRQ: 0 as well.

The dmesg gives me the following prints (I have taken logs related to the PCI device only):

[    0.147241] pci 0000:03:02.0: [1fd4:1999] type 00 class 0x070200
[    0.147261] pci 0000:03:02.0: reg 0x10: [io  0x2100-0x211f]
[    0.147269] pci 0000:03:02.0: reg 0x14: [io  0x2000-0x20ff]
[    0.147285] pci 0000:03:02.0: reg 0x1c: [io  0x2120-0x212f]
[    0.147326] pci 0000:03:02.0: PME# supported from D3hot
[    0.644260] 0000:03:02.0: ttyS5 at I/O 0x2100 (irq = 18, base_baud = 921600) is a 16550A

Another clue I got (from an answer below) is that ttyS5 is the only one listed under the PCI device /sys/devices/pci0000:00/0000:00:16.3 in my PC (Please note that this particular PCI card was working fine when it was installed in a Windows 7 based PC). The following is the output of find /sys/devices/ -type d -name ttyS*:

/sys/devices/pnp0/00:04/tty/ttyS0
/sys/devices/pci0000:00/0000:00:16.3/tty/ttyS4
/sys/devices/pci0000:00/0000:00:1e.0/0000:03:02.0/tty/ttyS5
/sys/devices/platform/serial8250/tty/ttyS1
/sys/devices/platform/serial8250/tty/ttyS2
/sys/devices/platform/serial8250/tty/ttyS3
/sys/devices/platform/serial8250/tty/ttyS6
/sys/devices/platform/serial8250/tty/ttyS7
/sys/devices/platform/serial8250/tty/ttyS8
/sys/devices/platform/serial8250/tty/ttyS9
/sys/devices/platform/serial8250/tty/ttyS10
/sys/devices/platform/serial8250/tty/ttyS11
/sys/devices/platform/serial8250/tty/ttyS12
/sys/devices/platform/serial8250/tty/ttyS13
/sys/devices/platform/serial8250/tty/ttyS14
/sys/devices/platform/serial8250/tty/ttyS15
/sys/devices/platform/serial8250/tty/ttyS16
/sys/devices/platform/serial8250/tty/ttyS17
/sys/devices/platform/serial8250/tty/ttyS18
/sys/devices/platform/serial8250/tty/ttyS19
/sys/devices/platform/serial8250/tty/ttyS20
/sys/devices/platform/serial8250/tty/ttyS21
/sys/devices/platform/serial8250/tty/ttyS22
/sys/devices/platform/serial8250/tty/ttyS23
/sys/devices/platform/serial8250/tty/ttyS24
/sys/devices/platform/serial8250/tty/ttyS25
/sys/devices/platform/serial8250/tty/ttyS26
/sys/devices/platform/serial8250/tty/ttyS27
/sys/devices/platform/serial8250/tty/ttyS28
/sys/devices/platform/serial8250/tty/ttyS29
/sys/devices/platform/serial8250/tty/ttyS30
/sys/devices/platform/serial8250/tty/ttyS31

I would like to understand and know why only my port labelled 1 on my Sunix is accessible and how/where can I gain access to my remaining 7 ports?

4

After some in-depth research, I got a custom driver from here:

www.sunix.com/en/download.php?pid=970&file=driver&file_link=download/driver/2016/20160706173626_snx_V2.0.4.2.tar.gz

For some reason (that I'm unaware of), the kernel doesn't seem to recognize the other serial ports. So, I got it fixed by doing the following:

Download the driver from the link above. "ncurses.h" is a dependency for the above driver. Install it using apt as:

sudo apt-get install libncurses5-dev

Change to root directory (to install the driver), create a new directory temp and make temp your working directory:

cd /
sudo mkdir temp
cd /temp

Copy the tar file and extract the contents to /temp:

sudo cp ~/Downloads/20160706173626_snx_V2.0.4.2.tar.gz /temp/snx_V2.0.4.2.tar.gz
sudo tar xvf snx_V2.0.4.2.tar.gz

Install the driver using the following steps:

sudo make clean
sudo make install
sudo modprobe snx

Run lsmod | grep snx to verify. New device files should be created with a prefix as ttySNX (instead of ttyS). The same can be checked using ls /dev/ttySNX*, which should be giving the following output:

/dev/ttySNX0  /dev/ttySNX1  /dev/ttySNX2  /dev/ttySNX3  /dev/ttySNX4  /dev/ttySNX5  /dev/ttySNX6  /dev/ttySNX7

So, the bottomline is : Linux may not be able to do magic (which it does more often than not) and make every device work in a plug and play manner, it may need drivers to some specific devices.

1

This looks like a bug in the kernel driver as it shouldn't have created this many devices. You should check the kernel debug messages to see if anything went wrong during the driver init.

  • Would dmesg prints be of any help? – skrowten_hermit Aug 9 '17 at 12:53
  • Yes, look for the serial port driver messages. – L29Ah Aug 9 '17 at 13:13
  • I just updated my post with the same. – skrowten_hermit Aug 9 '17 at 13:32
  • Does dmesg say anything about all the next ttys? – L29Ah Aug 9 '17 at 14:03
  • Nope. All it says is [ 0.602427] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [ 0.623717] 0000:00:16.3: ttyS4 at I/O 0x4140 (irq = 17, base_baud = 115200) is a 16550A [ 0.644260] 0000:03:02.0: ttyS5 at I/O 0x2100 (irq = 18, base_baud = 921600) is a 16550A – skrowten_hermit Aug 10 '17 at 5:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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