ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

[mkohns]

trafficstars

Scenario:

Hardware: RPI3, 4.14.22-v7+, /boot/.firmware_revision: v634741d4199871ab8bd5446a8e63b7e06c1885af (latest by today) Device: 3D Printer, FTDI Fake Chip: FT232RL, 0403:6001, SerialNumber: A50285BI

Description: The FTDI Chip of the 3D Printer offers /dev/ttyUSB0 for communication. The kernel module ftdi_sio creates a serial device. With a simple

cat /dev/ttyUSB0

the output of the printer can be monitored. The call:

echo "M155 S1" > /dev/ttyUSB0

initates a automated temperature report every second.

Case: This scenario works perfect on i.e desktop pc with ubuntu 17.10, 4.13.0-36-generic but also under 3 different distros I tested the same way. Also under Windows 7/10 (cygwin) the connection is stable.

Under OrangePI (armbian), BananaPi (armbian), RPI1/2/3 (wheezy, jessie, stretch) the connection is unpredictable unstable and dies with

ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

I already cross tested the following options (permutations) with no success:

max_usb_current=1
dwc_otg.microframe_schedule=0
dwc_otg.fiq_fsm_enable=0
dwc_otg.fiq_fix_enable=0 
dwc_otg.fiq_split_enable=0
dwc_otg.nak_holdoff_enable=0
dwc_otg.trans_backoff=3000
dwc_otg.fiq_fsm_mask=0x0 

This issue seems only be handled by

dwc_otg.speed=1

which is no option, as the whole bus (network card included) is limited to USB 1.1

From my point of view, also it is a Fake FTDI Chip, is seems to be an ARM linux kernel issue. On Intel/AMD linux and windows the communication is stable.

What would be the best way to investigate and get this issue solved?

References: https://github.com/raspberrypi/linux/issues/1187 https://github.com/raspberrypi/firmware/issues/88 https://raspberrypi.stackexchange.com/questions/1886/what-kernel-parameters-are-available-for-fixing-usb-problems

Simplification: I simplied the testing scenario to temperatur monitoring. Of course several applications are available for managing 3D Printers in all their complexity. I encountered communications issues with this applications under RPI3.

[JamesH65]

@P33M Not sure there is much to go on here, but any comments?

Seems to be ARM related since desktops don't see the same issue.

[arobbins805]

Was this ever solved?

I am getting a similar issue on Ubuntu 16.04 LTS and 18.04 LTS. I need to repeatedly re-enumerate an FTDI chip. The device is recognized with the Product: FT230X Basic UART.

My syslog has the following lines:

[ +9.835078] ftdi_sio ttyUSB196: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ +0.000090] ftdi_sio ttyUSB196: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ +0.230177] usb 9-4.3.4: USB disconnect, device number 22 [ +0.000137] ftdi_sio ttyUSB196: error from flowcontrol urb

[Feb26 07:06] ftdi_sio ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ +0.000066] ftdi_sio ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ +0.139339] usb 3-4.4.4: USB disconnect, device number 105 [ +0.000141] ftdi_sio ttyUSB1: error from flowcontrol urb

[ +9.969193] ftdi_sio ttyUSB174: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ +0.000114] ftdi_sio ttyUSB174: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ +0.013751] usb 9-4.4.2: USB disconnect, device number 126 [ +0.000137] ftdi_sio ttyUSB174: error from flowcontrol urb

I can provide more detailed info if people are interested in this bug.

[Lukanite]

I think I'm seeing a similar issue. On the Pi Zero W, if I plug in an FTDI cable (TTL-232R-3V3) into the OTG port, when I try to use it, say, with: screen /dev/ttyUSB0 115200 The Pi Zero W immediately slows to a crawl and remains unusably slow until the cable is disconnected (by unplugging it), upon which the kernel log prints:

Mar 27 22:06:17 pizerow kernel: [  207.609776] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Mar 27 22:06:17 pizerow kernel: [  207.609799] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Mar 27 22:06:17 pizerow kernel: [  207.644293] usb 1-1.2: USB disconnect, device number 3
Mar 27 22:06:17 pizerow kernel: [  207.651963] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Mar 27 22:06:17 pizerow kernel: [  207.652106] ftdi_sio 1-1.2:1.0: device disconnected

Oddly enough, if I leave htop open in the background, its update rate slows to <1 update per minute, but when it does, the load figure spike to 4+ but with no process seeming to be responsible.

This is occurring on kernel 4.14.98+ with Raspbian Stretch Lite. My Pi 3B+ on the same kernel and OS (albeit armv7) handles the cable just fine.

[Lukanite]

Hmm, just tried a USB ACM device and it seems to exhibit the same issue, but ONLY if I connect it to the Pi Zero W with a USB hub. If I use an USB OTG adapter to directly connect the device, it's usable and fine.

However, if I try connecting the FTDI cable directly, it just causes the Pi Zero W to reboot. Once it comes back up, though, it's fine.

Maybe it has to do something with hubs?

[arobbins805]

I discovered what was causing this 'error' for me. My program was leaving the /dev/ttyUSBN serial port open. I rebooted and changed my software to close the port after use (Previously, it was left open in one of the error cases). After doing this, I no longer saw the dmesg or syslog errors. Hopefully this helps.

[Lukanite]

Yep, I also see that it only happens if the device is disconnected while the port is open. Sometimes this causes all of the USB ports to stop working, though

[mrx23dot]

I have the same issue, app requires the COM port to be continuously open, I plug it directly into Pi3, without hub. No current changes during run. Any solution?

[JamesH65]

@spl237 related to the lxpanel issues perhaps?

[tinkerdudeno1]

Like many others, I can confirm this issue with the fake ftdi disconnecting. Here's my story:

• Got a brand new Rpi 4
• Installed docker and ran a service which is constantly listening and occasionally sending signals to the ftdi (which is connected to a bus on my heating system).
• It almost instantly disconnects with usb_serial_generic_read_bulk_callback - urb stopped: -32 on dmesg.
• Funny thing is: The exact same image/setup works fine on my old Rpi 3 sitting right next to it. I literally unplugged-replugged with the exakt same docker image on the Pis back and forth and one would work, the other one would go crazy and disconnect. Thought it MUST be their different kernels (Rpi4: 5.4.69-v7l+; Rpi3: 4.19.97-v7+) and found this issue after endless googling.
• Downgrading to usb 1 (with dwc_otg.speed=1 in /boot/cmdline.txt as suggested in #1187) in the Pi 4 did not work for me.

In my desparation, I tried another (fake) ftdi I had flying around and guess what: Everyting is just fine on the Pi 4, no reconnects and no need to downgrade to usb 1. Guess there are different quality fake ftdi out there. So if you -- like me -- don't want to spend 20 euros on a genuine ftdi (which would almost definitey mitigate your problem), trying different ftdi from different batches/sellers might be worth a try.

One more thing: Just connecting the ftdi which just sits there with no data coming through will not cause it to reconnect. It's when you begin pushing data over the chip, it will go crazy and disconnect.

So I'm afraid this issue is very hard to track down. Even with the same setup and a seemingly identical fake ftdi, the behavior is unpredictable.

[otavio]

I confirm the very same issue @tinkerdudeno1; the same issue also works on rpi3 and fails on rpi4. In our case, we are using 5.4.72 kernel on both.

[bangom]

I've hit the same error when using mini USB to UART converter with FT232 chip (https://www.gme.cz/ftdi-prevodnik-s-mini-usb-a-spi) under heavier load:

[  743.655103] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 2463.978860] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 2557.336232] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

RPI: Raspberry Pi 3 Model B Rev 1.2 Kernel: 5.4.75-v7+

The Converter is directly connected to a USB port of the Rasberry.

Downgrading to usb 1 with dwc_otg.speed=1 in /boot/cmdline.txt helped mitigate USB disconnects.

[SamuelGold]

Raspberry Pi 4B, Kernel 5.4.79-v7l+ and the same problem: [ 2911.620320] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 [ 3434.996100] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

[bombasticbob]

I am exhibiting problems like this when doing rapid IO with genuine FTDI ICs on devices that are under development.

They show up as errno=EINVAL after poll or write operation, and appear to be cumulative; that is, closing the application "fixes" it for a while, but the problem shows up more rapidly after i restart the application. The serial is being run at 115k baud to control devices and are rapidly polled. I've used FTDI serial for a lot of things with x86 but not for ARM and so I wasn't expecting problems.

If you look HERE you'll see that the private member 'prev_status' is defined as 'char' (which is unsigned by default for ARM, unless some compiler option has been altered to change that). It's being "math"d with 'status' which is an unsigned char. Normally you would think this is OK but the data types _ were _ declared differently, and I'm not sure whether compiler data type promotion would affect it.

I looked for this type of problem specifically because I've seen weirdness in my own code when porting it to ARM, related to signed vs unsigned char. It's probably benign, but it's the _ kind _ of thing to look for.

Other ARM-related things would have to do with atomics and translation of userland to kernel addressing for various purposes.

Someone familiar with porting drivers from x86 to ARM may know of other things to look for. This was the only thing I spotted that caused me to raise my eyebrow even slightly.

uname: Linux rpi4test 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux (yes it's an RPi 4 but the 3 seems to do it as well)

[Sennevds]

I had/have the same problem. I have a creality Ender 3 V2 3d printer which uses a serial connection over usb to connect to a pi3 b+. It worked perfectly for several weeks until I moved the printer (and the pi) to a build in cabinet. Since the move I got the above errors every hour. I could reconnect but the print has already stopped of course. Now I have moved the pi to a cabinet below the printer and it works perfectly again so it looks like interference creates this problem for me. Not sure if this is completely the same problem(I have the same errors in my dmesg) but I thought maybe this insight couple help identify the problem.

[Stifael]

I experience a similar issue but with a different raspi-setup.

Raspi: Stretch (version 9) Kernel: 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 FTDI: FT4232H Q (https://ftdichip.com/products/usb-com485-plus4/)

I currently experience two problems with this setup, but I am not sure if they depend on each other, and I am also only able to reproduce the latter:

1. Communication problems can occur during normal operation. Even though the hardware setup has not been changed and the system was running for several months, the system can enter a state where communication is no longer possible. Not even rebooting the raspi helps.
2. Hot Plugging the FTDI. It can happen that not only the communication stops, but also that the raspi crashes.

The second problem results in the usb_serial_generic_read_bulk_callback - urb-message. Since I have no clue what causes the first issue, I tried to tackle the second problem first in the hope that the two issues are somewhat dependent on each other. For that, I wrote a very simple cpp-executable that opens 4 ports and writes "hello" to each ttyUSBx port sequentially. When running the executable and test hot-plugging, the raspi can enter a state where it can no longer recover from the communication loss and in the worst case results in a crash.

findings

• writing to just one ttyUSBx port lowers the chances of receiving the usb_serial_generic_read_bulk_callback - urb error message
• setting dwc_otg.speed=1 further improves the stability of the communication
• the same setup but with a Syslogic CompactS runs without issues

ftditest.zip

[HuberDe]

Hi,

just that issue after googling regarding my problem on my pi4. I‘m running zigbee2mqtt on my pi using a zigbee hardware dongle. This worked great for the last year. Since a few days my zigbee2mqtt is crashing several times per day. I did not do any changes on the software nor hardware side. So I assume it could be a aging topic of the hardware?

Denis

[alfredopalhares]

I too am having the same error as above, when using using Klipper on an Ender 5 3D printer

[  111.775735] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[  130.875367] ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

I have tried:

• Adding dwc_otg.speed=1
• Updating the system
• Changed power supply
• Wraping in the USB comunications cable in aluminum foil

[antonmeyer]

similar issue cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

RP4 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux

reading at 9600 baud continously

[dchauran]

Frequent disconnects in OctoPrint with a CH340 (MKS Robin Nano v1.2)

ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

• Rpi 3b+
• Using a very short shielded cable
• No undervoltage issues, power supply is more than adequate
• dwc_otg.speed=1 seemingly has no effect (though it still says a full speed device is connected, but I am unsure if that is relevant or not)

[synman]

I too am having this problem with an ESP32 board with an integrated FTDI controller connecting to my pi4. It happens on both the USB3 and USB2 ports.

Dec 12 17:16:03 octopi-qbp kernel: ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Dec 12 17:16:03 octopi-qbp kernel: ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

On the ESP32 side, the uart keeps the port open and sends and receives without issue.

On the pi side, not so pretty. Once the urb stopped -32 message pops in my syslog the pi loses its receive channel entirely. It is able still able to send data no problem, but the send side is dead.

The only way to recover is to disconnect / reconnect (via software).

Downgrading to usb 1.1 does not solve my issue.

[synman]

Coming back (quickly) to this. I had a breakthrough of sorts.

I failed to mention I also had a CyberPower UPS connected to my pi. For reasons I do not yet understand, after I disconnected the UPS, my problems with the ESP32 board went away.

So now I don't know what to think. I got my ESP32 board working properly, but now I'm SoL when it comes to monitoring my UPS locally.

[klack]

I am also having this issue on 2 out of 3 printers. They are on a Raspberry Pi 4 running in docker.

In the past, I had an undervoltage issue that affected those same 2 printers. Upgrading the power supply solved that issue. But now I have this one.

I am going to try: dwc_otg.speed=1 and Covering the power pin on my usb cable so it does not power the printer

[dchauran]

I updated the kernel on my pi and it's been stable on 32 bit. I tried going to 64 bit and it was far, far worse.

[klack]

dwc_otg.speed=1 Did not work for me

[simowilso]

I am seeing the same issue. Rpi4 Ubuntu 22.04.2 LTS - connected to an Ender 3 v2 3d printer. I don't know what the chip is inside but I presume fake FTDI

[popy2k14]

Exact same issue here with an odroid n2+ , see: https://github.com/Koenkk/zigbee2mqtt/issues/12566#issuecomment-1465295006

Will try the same hardware on an x86 with same HA config and see if the issue is solved -> or in other words: it's an arm kernel issue!?

[klack]

I think I've fixed it for my 3D printers. I covered the 5V pin on my USB B cables with a slice of Kapton tape. This way it will not power the boards. I've got 3 printers working overnight now. Please everyone give it a try, or use a powered USB hub.

[mertzt89]

I've effectively done this by removing the diode that connects 5v USB line to the internal 5v rail on all of my printers.

Even so, I've got many printers experiencing this issue (all of which are ender 3 pros with stock boards). I've got another printer with a duet wifi board and it NEVER experiences this issue even with the same pi.

[synman]

yeah, it's not as simple as removing power or running a powered hub. When I was experiencing this condition, it would crash on a hub as well. for me, it had to do with conflicts occurring between an ESP32 FTDI serial uart and an old CyberPower serial uart and it didn't matter if they were on the same hub / bus / etc.

[mertzt89]

Yeah and for me it is excessively bad today. To me it seems environmental. Perhaps indoor humidity, static, etc. Interestingly, I had ALL of my printers fail simultaneously, even on different pi's. They do share a common AC circuit. I did confirm via dmesg and /proc/uptime that it did indeed show this error.

I'm just trying to document as many observations as possible.