[Bug 278716] ucom(4)/uslcom(4)/uchcom(4) serial driver: communcation problem with FBSD > 13.2-RELENG

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278716

fabrice.bruel@orange.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fabrice.bruel@orange.com

--- Comment #5 from fabrice.bruel@orange.com ---
This appears to be a recurrence of the issue described in PR 278716
(ucom(4)/uslcom(4)/uchcom(4) serial driver: communication problem
with FBSD > 13.2-RELENG), which was closed due to feedback timeout
without a confirmed fix. I'm reporting a fresh, reproducible case on
15.1-RELEASE with additional context.

Environment:
- FreeBSD 15.1-RELEASE-p1, amd64
- USB-serial adapter: CH340 (QinHeng Electronics), driver uchcom(4)
- Device: ZigStar Stick v4 (TI CC2652P2 Zigbee coordinator, Z-Stack
  firmware, ZStack3x0)
- Application: zigbee-herdsman 10.9.2 (Node.js), via Zigbee2MQTT 2.14.1
- Baud rate: 115200, no hardware flow control (rtscts: false)

Symptom:
Serial communication with the attached device works correctly for
an initial period (tens of seconds, dozens of successful
request/response exchanges), then a request silently fails to
receive its expected response, causing the application-level
protocol to time out (6000ms timeout on a synchronous request/
response frame). No corruption is logged at the driver level
(no console/dmesg errors), which suggests a dropped or corrupted
frame that the driver does not report.

The failure is intermittent: restarting the same operation
(reopening the port, restarting the application) succeeds roughly
1 out of 2-3 attempts, consistent with reports in PR 278716 where
esptool.py showed "Invalid head of packet: Possible serial noise
or corruption" on some attempts and not others, with the same
hardware and cabling.

Steps to reproduce:
1. Attach a CH340-based USB-serial device (uchcom0 attaches
   correctly, device enumerates as /dev/cuaU0)
2. Open the port at 115200 baud, 8N1, no flow control
3. Perform a sustained sequence of write/read request-response
   exchanges over ~30-60 seconds (in this case, a Zigbee Z-Stack
   NPI protocol exchange during coordinator startup/backup)
4. Observe that at some point a response is not received within
   the expected window, despite no error being reported by the
   kernel driver

Expected result:
All frames are transmitted and received without loss/corruption,
consistent with behavior on FreeBSD 13.2 and earlier, and with the
same hardware under Linux (where no equivalent failures occur with
the same cabling and device, as also reported in PR 278716).

Actual result:
Intermittent frame loss or corruption causes application-level
timeouts. No corresponding error is visible in dmesg or console at
the time of failure.

Additional notes:
- This is not vendor/product-ID related (uchcom0 correctly
  identifies and attaches the CH340 chipset)
- Removing all other USB devices from the bus does not resolve
  the issue
- This closely tracks the "regression" keyword already applied to
  PR 278716, which spans multiple ucom(4)-based drivers
  (uslcom, uchcom), suggesting the root cause is in the shared
  ucom(4) framework rather than in a specific chipset driver

Requesting this be either reopened as a continuation of PR 278716,
or cross-referenced if a separate tracking bug is preferred, since
that PR was closed on feedback timeout rather than resolution.

-- 
You are receiving this mail because:
You are the assignee for the bug.