On Mon, May 31, 2021 at 12:38:19PM -0500, Alex Villacís Lasso wrote: > (Sorry if this is a double-post. Previous message appears to have > dissapeared or been rejected in transit. ) > > This is a report of the bug report at > https://bugzilla.redhat.com/show_bug.cgi?id=1965527. I was asked to post > the bisection results by Hans de Goede. Here is the bug information for > reference: > > 1. Please describe the problem: > > For my development work, I use several ESP32 boards from Espressif. On > Fedora, these modules are plugged as USB serial devices, managed via > the cp210x module, and show under /dev/ttyUSB0 . > > On Fedora 34, up until kernel-5.11.21-300.fc34.x86_64, this setup > worked correctly. > > Under recently-released kernels kernel-5.12.5-300.fc34.x86_64 and > kernel-5.12.6-300.fc34.x86_64, this setup is now broken. When I plug > the board, the module loads as usual and shows up under /dev/ttyUSB0. > However, *any* attempt to read or write to the port fails. For > example, using miniterm.py from python3-pyserial-3.4-10.fc34.noarch: > > Traceback (most recent call last): > File "/usr/bin/miniterm.py", line 976, in <module> > main() > File "/usr/bin/miniterm.py", line 932, in main > serial_instance.open() > File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line 288, in open > self._update_rts_state() > File "/usr/lib/python3.9/site-packages/serial/serialposix.py", line 627, in _update_rts_state > fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_RTS_str) > BrokenPipeError: [Errno 32] Broken pipe > > At the same time, the following appears in the system logs: > > may 27 16:04:55 karlalex-asus kernel: usb 1-10: new full-speed USB device number 6 using xhci_hcd > may 27 16:04:55 karlalex-asus kernel: usb 1-10: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00 > may 27 16:04:55 karlalex-asus kernel: usb 1-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > may 27 16:04:55 karlalex-asus kernel: usb 1-10: Product: CP2102N USB to UART Bridge Controller > may 27 16:04:55 karlalex-asus kernel: usb 1-10: Manufacturer: Silicon Labs > may 27 16:04:55 karlalex-asus kernel: usb 1-10: SerialNumber: 18c0ecf00d0aea119fe0ae442473482f > may 27 16:04:55 karlalex-asus mtp-probe[3272]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10" > may 27 16:04:55 karlalex-asus mtp-probe[3272]: bus: 1, device: 6 was not an MTP device > may 27 16:04:55 karlalex-asus kernel: usbcore: registered new interface driver cp210x > may 27 16:04:55 karlalex-asus kernel: usbserial: USB Serial support registered for cp210x > may 27 16:04:55 karlalex-asus kernel: cp210x 1-10:1.0: cp210x converter detected > may 27 16:04:55 karlalex-asus kernel: usb 1-10: cp210x converter now attached to ttyUSB0 > may 27 16:04:55 karlalex-asus mtp-probe[3287]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-10" > may 27 16:04:55 karlalex-asus mtp-probe[3287]: bus: 1, device: 6 was not an MTP device > may 27 16:04:56 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32 > may 27 16:04:56 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32 > may 27 16:04:56 karlalex-asus python3[3292]: detected unhandled Python exception in '/usr/bin/miniterm.py' > may 27 16:04:56 karlalex-asus kernel: cp210x ttyUSB0: failed set request 0x7 status: -32 > may 27 16:04:56 karlalex-asus abrt-server[3293]: Deleting problem directory Python3-2021-05-27-16:04:56-3292 (dup of Python3-2021-05-27-14:26:21-17653) > may 27 16:04:56 karlalex-asus abrt-notification[3312]: [🡕] Process 17653 (miniterm.py) of user 1000 encountered an uncaught BrokenPipeError exception > > The messages with "failed set request..." are abnormal. > > Worked around by downgrading the kernel to any 5.11.x version. Tested > with kernel-5.11.21-300.fc34.x86_64 and kernel-5.11.12-300.fc34.x86_64 > Module cp210x from kernel 5.11 works without errors with ESP32 when > compiled under 5.12.x after applying commit > c5d1448fa353242635fa3e1fed6ab4558e0e7d9a (USB: serial: make remove > callback return void) on top of it. This allows bisection without > rebooting. > > > Bisection points me to this: > > f61309d9c96a308465bec9d2e5206da265b075a0 is the first bad commit > commit f61309d9c96a308465bec9d2e5206da265b075a0 > Author: Johan Hovold <johan@xxxxxxxxxx <mailto:johan@xxxxxxxxxx>> > Date: Mon Jan 18 12:13:27 2021 +0100 > > USB: serial: cp210x: set IXOFF thresholds > > At least CP2102 requires the XON/XOFF limits to be initialised in order > for software input flow control (IXOFF) to work. Specifically, XOFF is > never sent if the XOFF limit is left at its default value of zero. > > Set the limits so that input is throttled when the FIFO free level drops > below 128 bytes and restarted when the FIFO fill level drops below 128 > bytes. > > Note that the threshold values have been chosen so that they can be used > also with CP2105 which has the smallest FIFO of the currently supported > device types (288 byte for the SCI port). If needed the limits can be > made device specific later. > > Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx <mailto:gregkh@xxxxxxxxxxxxxxxxxxx>> > Signed-off-by: Johan Hovold <johan@xxxxxxxxxx <mailto:johan@xxxxxxxxxx>> > If I manually revert commit f61309d9c96a308465bec9d2e5206da265b075a0 > from cp210x.c from 5.12.7, it works correctly. Further proof that this > commit introduced the bug. Thanks for the detailed report. I got another report of this issue off-list a few days ago, but I haven't got any replies to my follow-up questions from that reporter yet. I can't seem to reproduce the issue here and the other reporter only saw this for some CP2102N which seems to suggest that there's some interaction with the device configuration at play here too. The symptoms appear to be consistent with the device still having hardware flow control enabled while the driver thinks it is disabled. The IXON/IXOFF limits are set in the same request and this might explain why things get out of sync, for example, if 128/128 limits are rejected by your device in its current configuration. But that's still to be determined. First, can you enable dynamic debugging in the driver through debugfs: echo module cp210x +p > /sys/kernel/debug/dynamic_debug/control or when loading the module: modprobe cp210x dyndbg==p and send me the logs from when connecting the device and running you terminal program. After the terminal program fails, try just to issue a cat /dev/ttyUSB0 press control-C and then include the logs for that too. For completeness, also include the output of stty -F /dev/ttyUSB0 -a after re-connecting the device and before and after running the terminal program. Johan
