Bug 266990 - FreeBSD can not drive 16950 chip correctly
Summary: FreeBSD can not drive 16950 chip correctly
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 13.1-RELEASE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-12 11:23 UTC by zhigao Lv
Modified: 2024-03-31 13:46 UTC (History)
2 users (show)

See Also:


Attachments
dmesg.boot (22.62 KB, text/plain)
2022-10-12 11:23 UTC, zhigao Lv
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description zhigao Lv 2022-10-12 11:23:54 UTC
Created attachment 237234 [details]
dmesg.boot

I have an industrial control computer, which uses 16950 chips. This chip is used for the serial port of the computer.
I installed FreeBSD version 13.1. When the computer starts, the information detected in the dmesg is as follows:
-------------------- Split line -------------
uart1: <16950 or compatible> at port 0x2f8 irq 3 on isa0
uart1: non-PNP ISA device will be removed from GENERIC in FreeBSD 14.
-------------------- Split line -------------


This is the configuration content of /etc/ttys:
-------------------- Split line -------------
console	none				unknown	off insecure
ttyv0	"/usr/libexec/getty Pc"		xterm	onifexists secure
ttyv1	"/usr/libexec/getty Pc"		xterm	onifexists secure
ttyu1	"/usr/libexec/getty std.115200"	vt100	on secure
-------------------- Split line -------------


This is the configuration content of/boot/loader.conf:
-------------------- Split line -------------
beastie_disable=YES
boot_multicons=YES
comconsole_speed=115200
console=comconsole
-------------------- Split line -------------

Kernel Parameters:
-------------------- Split line -------------
[root@myhost ~]# sysctl kern.console
kern.console: ttyv0,/ttyv0,
[root@myhost ~]# sysctl kern.console=ttyv0,ttyu1
kern.console: ttyv0,/ttyv0,
sysctl: kern.console=ttyv0,ttyu1: Device not configured

[root@myhost ~]# sysctl -a|grep uart
uart1: <16950 or compatible> at port 0x2f8 irq 3 on isa0
uart1: non-PNP ISA device will be removed from GENERIC in FreeBSD 14.
uart1: <16950 or compatible> at port 0x2f8 irq 3 on isa0
uart1: non-PNP ISA device will be removed from GENERIC in FreeBSD 14.
device	uart_ns8250
device	uart
debug.uart_force_poll: 0
debug.uart_poll_freq: 50
irq3: uart1:5 @cpu0(domain0): 3
dev.uart.1.rx_overruns: 0
dev.uart.1.pps_mode: 2
dev.uart.1.%parent: isa0
dev.uart.1.%pnpinfo: 
dev.uart.1.%location: 
dev.uart.1.%driver: uart
dev.uart.1.%desc: 16950 or compatible
dev.uart.%parent: 
-------------------- Split line -------------

Fault phenomenon:
My laptop(MacOS) is connected to this machine through the serial port (RS232), and the console cannot be opened, command line:

-------------------- Split line -------------
screen -S aio /dev/tty.usbserial-1410 115200
-------------------- Split line -------------
Comment 1 zhigao Lv 2022-10-12 13:39:35 UTC
I tested 11.4, 12.3 and 14.0 and found this problem.
Comment 2 zhigao Lv 2022-10-12 14:38:53 UTC
FreeBSD can drive 16550 chip correctly. I tested normal on 11.4, 12.3 and 13.1.
Comment 3 Älven 2023-11-09 19:19:15 UTC
At least some controllers (Moxa) do work:

# dmesg.boot
puc0: <Moxa Technologies, Smartio CP-104EL-A/PCIe> port 0x1000-0x103f,0x1040-0x104f mem 0xba000000-0xba000fff irq 27 at device 0.0 on p
ci7
uart2: <16950 or compatible> at port 1 on puc0
uart3: <16950 or compatible> at port 2 on puc0
uart4: <16950 or compatible> at port 3 on puc0
uart5: <16950 or compatible> at port 4 on puc0

# sysctl -a | grep uart
device	uart_ns8250
device	uart
debug.uart_force_poll: 0
debug.uart_poll_freq: 50
dev.uart.5.rx_overruns: 0
dev.uart.5.pps_mode: 2
dev.uart.5.%parent: puc0
dev.uart.5.%pnpinfo: type=1
dev.uart.5.%location: port=4
dev.uart.5.%driver: uart
dev.uart.5.%desc: 16950 or compatible
dev.uart.4.rx_overruns: 0
dev.uart.4.pps_mode: 2
dev.uart.4.%parent: puc0
dev.uart.4.%pnpinfo: type=1
dev.uart.4.%location: port=3
dev.uart.4.%driver: uart
dev.uart.4.%desc: 16950 or compatible
dev.uart.3.rx_overruns: 0
dev.uart.3.pps_mode: 2
dev.uart.3.%parent: puc0
dev.uart.3.%pnpinfo: type=1
dev.uart.3.%location: port=2
dev.uart.3.%driver: uart
dev.uart.3.%desc: 16950 or compatible
dev.uart.2.rx_overruns: 0
dev.uart.2.pps_mode: 2
dev.uart.2.%parent: puc0
dev.uart.2.%pnpinfo: type=1
dev.uart.2.%location: port=1
dev.uart.2.%driver: uart
dev.uart.2.%desc: 16950 or compatible
dev.uart.%parent:

It has all the corresponding /dev/ttyu* and /dev/ttyv* nodes.
But requires MSI interrupts workaround to actually pass data over serial line:
'hw.puc.msi_disable=1' to loader.conf

See bug #235016, comment #3
Comment 4 Älven 2023-11-14 08:01:48 UTC
In 14.0-RELEASE it still works well, but new message appeared: "ns8250: UART FCR is broken". What does it mean?

# dmesg.boot
puc0: <Moxa Technologies, Smartio CP-104EL-A/PCIe> port 0x1000-0x103f,0x1040-0x104f mem 0xba000000-0xba000fff irq 27 at device 0.0 on p
ci7
ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart2: <16950 or compatible> at port 1 on puc0
ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart3: <16950 or compatible> at port 2 on puc0
ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart4: <16950 or compatible> at port 3 on puc0
ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart5: <16950 or compatible> at port 4 on puc0