Where does another com port come from?

[ogogon]

Colleagues, please tell me how to understand where another com port comes from?

The situation is as follows. There is a server on the motherboard HUANANZHI x99-tf. Socket 2011v3, only PCI-e buses. There is no built-in com port!
However, the com port is needed so that the server can have heart-to-heart talks with the UPS.

At first, I bought a no-name board with two DB9 ports on the chinese chipset WCH CH382L. This board did not work out with the kernel.

After that, I bought an ST-Lab I-360 card on the Oxford Semiconductor OXPCIe952 chipset.

puc0: <Oxford Semiconductor OXPCIe952 UARTs> mem 0xfbc00000-0xfbc03fff,0xfba00000-0xfbbfffff,0xfb800000-0xfb9fffff irq 26 at device 0.0 numa-domain 0 on pci2
puc0: 2 UARTs detected
uart2: <16950 or compatible> at port 1 on puc0
uart3: <16950 or compatible> at port 2 on puc0

To my great surprise, the card is visible in the system as com ports 2 and 3. At the same time, there is also some com port 0. There is no port 1 at all.

root@server:/var/log # ls -alg /dev/ | grep -E '(cuau|ttyu)'
crw-rw----   1 uucp  dialer    0x4e  1 may   01:18 cuau0
crw-rw----   1 uucp  dialer    0x4f  1 may   01:18 cuau0.init
crw-rw----   1 uucp  dialer    0x50  1 may   01:18 cuau0.lock
crw-rw----   1 uucp  dialer    0x33  1 may   01:18 cuau2
crw-rw----   1 uucp  dialer    0x34  1 may   01:18 cuau2.init
crw-rw----   1 uucp  dialer    0x35  1 may   01:18 cuau2.lock
crw-rw----   1 uucp  dialer    0x39  1 may   01:18 cuau3
crw-rw----   1 uucp  dialer    0x3a  1 may   01:18 cuau3.init
crw-rw----   1 uucp  dialer    0x3b  1 may   01:18 cuau3.lock
crw-------   1 root  wheel     0x4b  1 may   01:18 ttyu0
crw-------   1 root  wheel     0x4c  1 may   01:18 ttyu0.init
crw-------   1 root  wheel     0x4d  1 may   01:18 ttyu0.lock
crw-------   1 root  wheel     0x30  1 may   01:18 ttyu2
crw-------   1 root  wheel     0x31  1 may   01:18 ttyu2.init
crw-------   1 root  wheel     0x32  1 may   01:18 ttyu2.lock
crw-------   1 root  wheel     0x36  1 may   01:18 ttyu3
crw-------   1 root  wheel     0x37  1 may   01:18 ttyu3.init
crw-------   1 root  wheel     0x38  1 may   01:18 ttyu3.lock
root@server:/var/log #

I didn't find anything about this in /var/log/messages or dmesg output.

How can I find out where port 0 comes from and why there is no port 1 at all?
I appreciate the answers and advice on the essence of the issue,
Ogogon.

 

[astyle]

COM ports do start numbering at zero.

To demonstrate why COM port 1 is gone:

Imagine that you have 5 devices/boards to connect, A, B, C, D, and E. You kind of have to pay attention to connect them in sequential order, this is key to keeping track of COM ports!. When you connect device A, it will show up as COM port 0, device/board B will show up as COM port 1, device/board C will show up as COM port 2, etc, all the way to device/board E, which will show up as COM port 4.

Now imagine that you disconnected device/board B (which corresponds to COM port 1).

If you re-connect the device/board B, it will show up as COM port 5, not 1. Just the way COM ports work.

If you mess up the order in which you connect the devices, disconnect them all, and reboot. After reboot, connect them in the correct order so that they show up correctly as COM port 0, 1, etc.

The brand of the board/device doesn't matter. The order in which you connect them does. I remember actually keeping notes on which board showed up under which COM number. Yeah, I had to slow down and be very deliberate in plugging stuff in, but that paid off big time.

 

[Andriy]

Most likely unit ID 0 and 1 are "in use" because of the standard device.hints that define them.
It seems that unit 0 even corresponds to some hardware.
Even if the motherboard does not have any com port soldered (either as an external port or an internal header), its chipset (either dedicated or a part of the CPU) or a separate SuperIO chip may still have a UART controller in it.

 

[SirDice]

Even if the motherboard does not have any com port soldered (either as an external port or an internal header), its chipset (either dedicated or a part of the CPU) or a separate SuperIO chip may still have a UART controller in it.

This. Just disable them in the BIOS/UEFI.

 

[astyle]

This. Just disable them in the BIOS/UEFI.

There's plenty of scenarios where that is not really an option. Getting device IDs to line up can be a pain, like I described. However, an investment of up front effort of paying attention and discipline in following the pattern - that does pay off when boards (like server and UPS, as described by OP) need to talk to each other. Later on, with solid foundation like that, it does become easier to introduce some automation and scripting.

 

[kpedersen]

If you don't have the card plugged in, do you still have cuau0? If so, this might be the Intel Management Engine stuff. This is sometimes exposed as UART.

This is the equivalent on Windows: