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.

[yoyoma2]

This pl2303 issue may have been fixed upstream where the commit description says "incomplete clones of the HXD type chip ... return -EPIPE". The "usb_serial_generic_read_bulk_callback - urb stopped" error message given above in this issue does occur on -EPIPE and @PTamis said above that different hardware implementations have the bug.

I'm not sure I'm looking in the right pl2303 code but it doesn't look like raspberry pi OS (bookworm) has that fix.

It would be great if raspberry pi OS (bookworm) got this pl2303 fix as it seems to be happening to pi users.

[P33M]

That commit fixes an issue where the (fake) chip responds to a command on its control pipe, not the bulk pipe. However, if there's some other bug in handling the command where it also stalls the bulk endpoint then the fix is worth backporting.

[pelwell]

You'll find a backport to rpi-6.12.y in #6689. In about 40 minutes from now you should be able to install a trial build using sudo rpi-update pulls/6689, after first backing up any important data.

[yoyoma2]

That commit fixes an issue where the (fake) chip responds to a command on its control pipe, not the bulk pipe.

I tested the #6689 backport on pi3 twice and it indeed made no difference (no worse either so worth keeping?). During each test, a pair of errors show up and the client application (gpsd) stops receiving data apparently in sync with the second error. My pl2303 came from ebay years ago and wasn't expensive so it is very likely a clone but has worked reliably until moving from jessie to bookworm.

The pi3 has to be stressed a little with kodi to trigger the pl2303 error. A different adapter that doesn't use the pl2303 driver is rock solid on this same pi3 under lots of stress.

kern  :err   : [Thu Feb 27 15:03:38 2025] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
kern  :err   : [Thu Feb 27 15:03:41 2025] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
kern  :err   : [Thu Feb 27 15:16:13 2025] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
kern  :err   : [Thu Feb 27 15:16:19 2025] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

Thanks for the build and if I can provide additional info let me know.

[d-rez]

I personally ended up abandoning USB route and hard-wiring my 3D printer via UART directly to the printer's MCU board's display connector for Klipper to run reliably.
I don't want to have to fall back to 32bit OS if the issue's root cause is unknown after reading tens of threads about this issue.
Plus it just looks neater now without the extra USB cable in the front.

The USB connection would fail with usb_serial_generic_read_bulk_callback - urb stopped: -32 sometimes as often as every hour. Switching power supplies, cables etc did not help.

I am using Creality board so a CH340/CH341 serial chip (ch341-uart driver/module). Even updating kernel to 6.12.y with rpi-update (which should have the backport mentioned by @pelwell above by now) didn't get rid of the issue for me.

This isn't limited to some single chip being fake as it happens across the board (ch340, ftdi_sio, pl2302 all have reports online of this very issue happening across multiple raspberry pi revisions. Rpi3 and up at least is what I could find)

[yoyoma2]

I personally ended up abandoning USB route and hard-wiring my 3D printer via UART directly

I also ended up hard-wiring to the pi's GPIO TXD, RXD pins and got rid of USB completely and that's been rock solid.

I wasn't getting any errors with a CP2102 based adapter but wasn't confident as CP2102 failures are mentioned by @r-hof above. If someone has a CP2102 available it may be worth swapping out the pl2303 for a quick test, YMMV.

[ceisserer]

I also experienced this issue on my PI3 and as described here a few times the usual "suggestions" did not help, not always the power supply or bad connectors are to blame.

In my case switching to the dwc2 driver helped (described here https://forums.raspberrypi.com/viewtopic.php?t=355035), however be prepared to loose performance and features ("The driver for the USB controller dwc2_hsotg does not support scatter-gather which is required by the UAS driver.").

In my case it is rock-solid, I only reboot every 1-2 months because of kernel updates.

The usb-serial converters i use with my pi are:
Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 004: ID 067b:23a3 Prolific Technology, Inc. ATEN Serial Bridge

While it works fine I am a bit concerned using a non-mainstream/niche usb driver stack, which might not get as much testing as dwc_otg enabled by default.