pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

[haiph-dev]

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

1. Plugin Unitek USB to rs232 on Raspberry Pi 4
2. Open ttyUSB0 baud rate=9600, timeout=1s
3. 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

[jglathe]

sounds like #5088. Appears to be fixed in newer kernels.

[r-hof]

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.

[haiph-dev]

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.

[ceisserer]

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.

[PTamis]

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

[r-hof]

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.

[PTamis]

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

[P33M]

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.

[P33M]

-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...

[PTamis]

Hello again and sorry for the delayed answered.
After some days of testing I confirm that the USB 2.0 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P is the correct cable for the CM4 I use.

No disconnects, no errors in dmesg, no problems whatsoever. It works fine all these days.

It seems that this cable has two versions.
One with 1.1 USB and one with 2.0.
The 2.0 is blue while the 1.1 is black. If you use the blue it will work just fine.
I think this might do the job:
https://thepihut.com/products/usb-to-ttl-serial-cable-debug-console-cable-for-raspberry-pi

From rpi-eeprom-update I don't get anything useful since I am using a Yocto image on my CM4.

I hope it helped.

[ceisserer]

in my case what really helped to get rid of the (now seldom) sporadic issues I observed with the new power supply was to switch to dwc2 via "dtoverlay=dwc2" in config.txt

By default the pi uses dwc_OTG, which probably does not cope that well with quirky USB devices.

[PTamis]

I have some more updates on the issue:
As I wrote above I thought that if you buy the USB cables with the blue coating they will work.
I was wrong. I bought these from amazon:
https://www.amazon.de/dp/B0814P6MYS/ref=pe_27091401_487027711_TE_SCE_dp_i1

and they don't work...

So I opened the coating from the working cable I have and the non working ones.

Photo from working cable

Photo from the non working cables:

As you can see the non working is missing some components like Y12000.

I think that the ones from amazon were fakes and they just changed the coating.

Now I searched from where my previous cable has been bought from and bought the exact same one:
https://www.pishop.ca/product/usb-to-ttl-4-pin-wire/
which after search comes from:
https://www.waveshare.com/usb-to-4-pin-wire.htm

So I order that, this time. I am hopping it will work like the previous cable, and I will let you know as soon as they arrive.