pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
haiph-dev opened this issue · comments
Describe the bug
I'm using Unitek USB to rs232 on Raspberry Pi 4 (kernel 5.15.32-v7l+ 11 (bullseye)). After about 24 hours, dmesg showing error like below then ttyUSB0 no longer receive data, ttyUSB1 still working as normal
[87173.786494] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Steps to reproduce the behaviour
- Plugin Unitek USB to rs232 on Raspberry Pi 4
- Open ttyUSB0 baud rate=9600, timeout=1s
- After about 24 hours, dmesg showing error pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Device (s)
Raspberry Pi 4 Mod. B
System
$ cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.2
$ cat /etc/rpi-issue
Raspberry Pi reference 2022-04-04
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 226b479f8d32919c9fe36dd5b4c20c02682f8180, stage2
$ vcgencmd version
Mar 24 2022 13:19:26
Copyright (c) 2012 Broadcom
version e5a963efa66a1974127860b42e913d2374139ff5 (clean) (release) (start)
$ uname -a
Linux G-Bike-In-Out 5.15.32-v7l+ #1538 SMP Thu Mar 31 19:39:41 BST 2022 armv7l GNU/Linux
Logs
[87173.786494] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Additional context
No response
sounds like #5088. Appears to be fixed in newer kernels.
sounds like #5088. Appears to be fixed in newer kernels.
Unfortunately, it appears to be neiter the same issue as in #5088 nor has it been fixed in newer kernels. Rather, it seems to be a common problem with USB-to-serial converters of all kinds and has been an issue for a long time, persistent over many kernel versions.
I have a device with CP2102 USB-to-serial converter chip which has the same problem. On a "Raspberry Pi 2 Model B Rev 1.1" running Raspbian Buster, kernel 5.10.103-v7+ #1529, the message appears sporadically, but on a "Raspberry Pi 4 Model B Rev 1.2" running Raspbian Bullseye, kernel 5.15.84-v7l+ #1613, it appears instantly after the first attempt to read from /dev/ttyUSB0 with the same device, rendering it completely unusable on the newer Pi.
sounds like #5088. Appears to be fixed in newer kernels.
Unfortunately, it appears to be neiter the same issue as in #5088 nor has it been fixed in newer kernels. Rather, it seems to be a common problem with USB-to-serial converters of all kinds and has been an issue for a long time, persistent over many kernel versions.
I have a device with CP2102 USB-to-serial converter chip which has the same problem. On a "Raspberry Pi 2 Model B Rev 1.1" running Raspbian Buster, kernel 5.10.103-v7+ #1529, the message appears sporadically, but on a "Raspberry Pi 4 Model B Rev 1.2" running Raspbian Bullseye, kernel 5.15.84-v7l+ #1613, it appears instantly after the first attempt to read from /dev/ttyUSB0 with the same device, rendering it completely unusable on the newer Pi.
Have you ever try RS485 converter with any suggested chip, is it better to use RS485 than RS232. Thank you.
same where - pi 3 running 6.1.0-rpi7-rpi-v8.
for me a profillic usb-serial adapter (built into an m-bus adapter) is causing the same issue:
[ 1403.181929] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
it seems to appear sporadically, could be related to power supply.
I have the exact same issue.
On a CM4 with IO board I have a "Bus 001 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P" device.
I using it to read only some data from another device so I have connected only the two cables receive and ground.
It is working fine for about 2-3 hours and afterwards after message
pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
it stops. If I reboot the CM4 it works again.
I will try today a different power input to test that also, since I have a suspicion over that and let you know.
I forgot to mention I am on kernel 5.15.34-v8 provided from meta-raspberrypi with a custom Yocto distro at kirkstone
In my case, the problem was at least partially caused by a flaky connection between the usb2serial adapter and the RaspberryPi. After reducing the cable length and eliminating a plug connection, the error occurs much less frequently and does not immediately render the adapter useless every time. I can now use it in production on my Pi4 with the original Pi power adapter.
I connected a different more robust power supply but again the same issue. After some hours the receive of data stopped. Then I remembered that I have another cable so I tried also that.
Both cables seems to be exactly the same and lsusb reports the same info:
lsusb
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P
Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P
Doing though an lsusb -v I saw a significant difference
The one is:
bcdUSB 2.00
while the other
bcdUSB 1.10
Now also in dmesg with previous cable when starting and stopping the device I was seeing the follow errors but regardless the device was working:
pl2303_get_line_request - failed: -32
pl2303 ttyUSB1: error sending break = -32
Now with the new cable I do not see those anymore. So I hope I not also see the error which stops the device.
I will keep it running for the whole day and report back.
The correct cable seems to be the one with version 2.0
There was a firmware fix for a known incompatibility with full-speed devices connected to a Pi 4 which may solve the issue you're seeing - the hub MCU would incorrectly schedule split transactions and cause a port babble.
What is the output of sudo rpi-eeprom-update? The minimum VL805 firmware version that includes the fix is 0138c0.
-EPIPE is only returned in response to an endpoint stall condition, which in this setup has only two sources:
- The device itself encountered some sort of internal error - stalls shouldn't happen on a free-flowing bulk pipe that's just giving you UART characters
- The hub TT incorrectly returned a STALL packet in response to some downstream bus condition.
If your firmware and kernel are up to date, and the issue still occurs, then what happens if a hub is added between the Pi 4 and the PL2303?
I note that the CDC_ACM driver has a dedicated recovery mechanism for a bulk endpoint stall, while usb_serial doesn't. Nowhere in the CDC specification is a STALL response specified for the mandatory ACM bulk endpoints...