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 dyo...@pobox.com Urbana, IL (217) 721-9981
