NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

ucom(4) and dropped rx bytes



I have a communications device that appears as a USB CDC ACM
peripheral---that is, a "USB modem."  A program that I wrote for macOS,
Linux, and NetBSD exchanges binary messages with the device.  On macOS
and Linux, the program reads intact messages.  On NetBSD 10.0, it reads
messages that are missing bytes.  I wonder if this connects with others'
observations of umodem/ucom behavior and whether or not any workaround
for dropped bytes is known.

On NetBSD 10, the program has no trouble sending and receiving messages
of 10 bytes or fewer.  However, when the device sends lengthier messages
(the problem crops when messages are about ~40 bytes long; it is severe
when messages are ~50 bytes long and longer), NetBSD frequently reads
a message that is missing one or more bytes.  For example, where there
should be a sequence of eight 0xFFs followed by 0x00, there will be
seven 0xFFs followed by 0x00 The missing byte usually is after the 40th.

The program opens the ucom(4) device node, /dev/dtyU0, and configures
it: 115200 bps, 8N1, *no flow control*.  If there was a "real"
RS-232 circuit involved, then I would not be surprised if the device
occasionally overran the host's receive FIFO and bytes were lost in
that way, since there is no flow control.  But the USB bus is faster
than 115200 bps, buffer space is ample, and the host is fast.  Also,
macOS and Linux apparently can keep up.  So I expect drops to occur only
rarely.

I have been able to replicate the drops using both a Rock64 single-board
computer running 10.0_BETA and a NetBSD 10.0 VM running on an M1 Mac
under UTM (QEMU for macOS).

Here are the relevant lines (root to peripheral) of the Rock64 dmesg:

armfdt0 (root)
simplebus0 at armfdt0: Pine64 Rock64
ohci0 at simplebus0: OHCI
ohci0: interrupting on GIC irq 49
ohci0: OHCI version 1.0
usb1 at ohci0: USB revision 1.0
uhub2 at usb1: NetBSD (0000) OHCI root hub (0000), class 9/0, rev
1.00/1.00, addr 1
uhub2: 1 port with 1 removable, self powered
umodem0 at uhub2 port 1 configuration 1 interface 0
umodem0: <redacted>, rev 2.00/1.01, addr 2, iclass 2/2
umodem0: data interface 1, has no CM over data, has break
umodem0: status change notification available
ucom0 at umodem0

and the M1 Mac VM dmesg:

armfdt0 (root)
armfdt0: using EFI runtime services for RTC
simplebus0 at armfdt0: QEMU QEMU Virtual Machine
acpifdt0 at simplebus0
acpifdt0: SMBIOS rev. 3.0.0 @ 0x23f800000
acpi0 at acpifdt0: Intel ACPICA 20221020
acpi0: X/RSDT: OemId <BOCHS ,BXPC    ,00000001>, AslId <    ,01000013>
acpi0: MCFG: segment 0, bus 0-255, address 0x0000004010000000
acpipchb0 at acpi0 (PCI0, PNP0A08-0): PCI Express Host Bridge
pci0 at acpipchb0 bus 0
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
xhci1 at pci0 dev 5 function 0: vendor 1b36 product 000d (rev. 0x01)
xhci1: 64-bit DMA
xhci1: interrupting at irq 84 (MSI-X vec 0)
xhci1: xHCI version 0.0 not known to be supported
usb3 at xhci1: USB revision 2.0
uhub3 at usb3: NetBSD (0x0000) xHCI root hub (0x0000), class 9/0, rev 2.00/1.00, addr 0
uhub3: 4 ports with 4 removable, self powered
umodem0 at uhub3 port 3 configuration 1 interface 0
umodem0: <redacted>, rev 2.00/1.01, addr 1, iclass 2/2
umodem0: data interface 1, has no CM over data, has break
umodem0: status change notification available
ucom0 at umodem0 portno 0

Any ideas?

David

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981


Home | Main Index | Thread Index | Old Index