search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
10.86k stars 4.89k forks source link

ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 #2406

Open mkohns opened 6 years ago

mkohns commented 6 years ago

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 commented 6 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

@spl237 related to the lxpanel issues perhaps?

tinkerdudeno1 commented 3 years ago

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

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 'prevstatus' 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 commented 3 years ago

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 commented 3 years ago

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

ftditest.zip

HuberDe commented 2 years ago

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 commented 2 years ago

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:

antonmeyer commented 1 year ago

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 commented 1 year ago

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

ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
synman commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

dwc_otg.speed=1 Did not work for me

simowilso commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

popy2k14 commented 1 year ago

I have replaced my odroid (arm based) with an Dell wyse 5070 (x86 based) with the same usb devices attached and HA restored.

The issue is gone for me for over two days. Before it happend in a few hours multiple times a day!

So its an arm based kernel issue!

SimpleSimonLA commented 1 year ago

For me, the issue disappeared after I've changed the USB Hub - still one without external power suply.

klack commented 1 year ago

Ah seems like there are multiple reasons for this error. For me I guess it was the Raspberry Pi trying to power 3 printer boards at once.

mertzt89 commented 1 year ago

I've actually solved my problem.. for now... I had put in a room HEPA filter with ionizer and the ionizing function was causing horrendous EMI. Disabled that function, haven't had an issue since.

On Mon, Mar 20, 2023, 4:56 PM Richard Layton @.***> wrote:

Ah seems like there are multiple reasons for this error. For me I guess it was the Raspberry Pi trying to power 3 printer boards at once.

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/2406#issuecomment-1476987008, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVKGRPZTKG3YOGH7FTU2XTW5DG73ANCNFSM4ES4PTKQ . You are receiving this because you commented.Message ID: @.***>

alfredopalhares commented 1 year ago

I have "solved" this issue by switching to CANBus communication with the board.

wpietri commented 1 year ago

I'm also having this problem. My details:

The receiver produces a stream of data at 38400 baud as it is received from passing ships. This works for hours or days at a time, failing such that select returns nothing for the device and sees no issues, even though data is still coming in. An strace of the reading process looks like this:

[pid 467848] 07:02:27 pselect6(5, [3 4], [], [], {tv_sec=9, tv_nsec=999995000}, NULL) = 1 (in [3], left {tv_sec=9, tv_nsec=999978426})
[pid 467848] 07:02:27 read(3, "C", 1)   = 1
[pid 467848] 07:02:27 pselect6(5, [3 4], [], [], {tv_sec=9, tv_nsec=999995000}, NULL) = 1 (in [3], left {tv_sec=9, tv_nsec=999978593})
[pid 467848] 07:02:27 read(3, "\r", 1)  = 1
[pid 467848] 07:02:27 pselect6(5, [3 4], [], [], {tv_sec=9, tv_nsec=999995000}, NULL) = 1 (in [3], left {tv_sec=9, tv_nsec=999978574})
[pid 467848] 07:02:27 read(3, "\n", 1)  = 1
[pid 467848] 07:02:27 write(1, "!AIVDM,1,1,,A,E>kb9O9Rh@@@@@@@@@"..., 67) = 67
[pid 467848] 07:02:27 pselect6(5, [3 4], [], [], {tv_sec=9, tv_nsec=999991000}, NULL) = 0 (Timeout)
[pid 467848] 07:02:37 pselect6(5, [3 4], [], [], {tv_sec=9, tv_nsec=999987000}, NULL) = 0 (Timeout)
[pid 467848] 07:02:47 pselect6(5, [3 4], [], [], {tv_sec=9, tv_nsec=999994000}, NULL) = 0 (Timeout)
[pid 467848] 07:02:57 pselect6(5, [3 4], [], [], {tv_sec=9, tv_nsec=999987000}, NULL) = 0 (Timeout)
[pid 467848] 07:03:07 pselect6(5, [3 4], [], [], {tv_sec=9, tv_nsec=999987000}, NULL) = 0 (Timeout)
[pid 467848] 07:03:17 pselect6(5, [3 4], [], [], {tv_sec=9, tv_nsec=999987000}, NULL) = 0 (Timeout)
[pid 467848] 07:03:27 pselect6(5, [3 4], [], [], {tv_sec=9, tv_nsec=999987000}, NULL) = 0 (Timeout)

The relevant kernel log is:

Apr  2 07:02:29 beacon1 kernel: [1004434.516651] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

The frequency of the problem seems to be increasing over time:

Thu 23 Mar 20:20:54 PDT 2023: same - restarting
Mon 27 Mar 22:33:23 PDT 2023: same - restarting
Tue 28 Mar 08:52:11 PDT 2023: same - restarting
Thu 30 Mar 00:59:14 PDT 2023: same - restarting
Fri 31 Mar 09:56:41 PDT 2023: same - restarting
Fri 31 Mar 13:43:54 PDT 2023: same - restarting
Sat 1 Apr 20:02:04 PDT 2023: same - restarting
Sat 1 Apr 21:57:11 PDT 2023: same - restarting
Sat 1 Apr 23:58:19 PDT 2023: same - restarting
Sun 2 Apr 02:53:27 PDT 2023: same - restarting
Sun 2 Apr 04:57:35 PDT 2023: same - restarting
Sun 2 Apr 07:03:42 PDT 2023: same - restarting
Sun 2 Apr 10:07:53 PDT 2023: same - restarting
Sun 2 Apr 15:11:09 PDT 2023: same - restarting
Sun 2 Apr 17:09:16 PDT 2023: same - restarting
Sun 2 Apr 20:00:24 PDT 2023: same - restarting

The error message sometimes happens without data flow disruption, but every data flow disruption occurs within a couple seconds of a log message like that.

Glad to debug further as requested.

popy2k14 commented 1 year ago

After two weeks of using the Dell wyse 5070 (x86 based) which replaced my odroid (arm based) with the same usb devices attached and HA restored.

The issue is gone!

So its an arm based kernel issue!

klack commented 1 year ago

For me, the issue disappeared after I've changed the USB Hub - still one without external power suply.

This ended up being the real fix for me.

popy2k14 commented 1 year ago

It's rather a workaround! There is a serious bug in the kernel causing this.

bunder2015 commented 1 year ago

I ran into this issue with a pi 4b running the latest 64bit pi OS, connected to a USB hub that is connected a UPS serial monitor and 3 ARM boards' serial consoles. The pi is powered by the official charger, and the USB hub is also powered. It was working fine for a couple weeks and then one of the consoles started hanging up with this urb error. Restarting putty would hang up again after 30 seconds and I wound up rebooting the pi to restore connectivity.

I can try unpowering the hub, as I shouldn't really need to power it for my devices.

Edit: unfortunately my hub doesn't work when unpowered. Perhaps the hub is faulty.

McNugget6750 commented 11 months ago

Confirming the same issue on RPI3

jbeale1 commented 10 months ago

I had the same problem: ch341-uart ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 when communicating with a CH341-UART chip in a knockoff Arduino-UNO-alike board. This was not from a Pi, but on a Linux Fitlet2 box (Linux Mint, 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 running on an Intel J3455) so it is not limited to ARM CPUs. The problem was solved by connecting the CH341 cable direct to the linux box port, instead of through a 4-port unpowered hub (Sabrent brand). So maybe something about the USB 2.0 TT (transaction translator) in the hub?

popy2k14 commented 10 months ago

@jbeale1 Interresting. Never had this issue since i switched to Dell wyse 5070 (x86 based).

ForrestFire0 commented 6 months ago

I have this issue on rpi 4 as well with cp120x and cp340x devices. Seems to be an issue. Given how common these FTDI clones are it seems like this should be a top priority, but it has not been addressed for 5 years!

McNugget6750 commented 6 months ago

Certainly not a solution but I ended up hard-wiring my 3d printer to the hardware serial port of the Raspberry Pi which works without issues. Sad so see that this cannot be resolved. I have noticed, though, that my Ubuntu laptop also experiences occasional disconnects of these chips with the same error message. Maybe it's a mass-produced hardware fault and not a driver issue after all?

klack commented 6 months ago

If you haven't tried an unpowered USB hub, give it a shot. This was even required for my newer PI Zero 2 W.

On Thu, Dec 28, 2023 at 3:19 PM Timo @.***> wrote:

Certainly not a solution but I ended up hard-wiring my 3d printer to the hardware serial port of the Raspberry Pi which works without issues. Sad so see that this cannot be resolved. I have noticed, though, that my Ubuntu laptop also experiences occasional disconnects of these chips with the same error message. Maybe it's a mass-produced hardware fault and not a driver issue after all?

— Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/2406#issuecomment-1871619797, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDEU2YZCF4RFA3MG6PV2NTYLX5A7AVCNFSM4ES4PTK2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBXGE3DCOJXHE3Q . You are receiving this because you commented.Message ID: @.***>

-- -Rich

bunder2015 commented 6 days ago

I recently acquired some Pi 5's and I'm still running into this issue. I haven't tried buying a new usb hub yet though.

McNugget6750 commented 6 days ago

This is not a solution but I ended up connecting my 3D printer directly to the RX/TX pins of the Raspberry Pi and so far it has been absolutely stable. It's heart breaking that this is a common occurrence. I will say though that I have seen this on Ubuntu laptops as well so maybe this is a kernel issue or deeply routed in the drivers and not specifically related to the Raspberry Pi.

popy2k14 commented 5 days ago

Wow, the issue is still not solved!? A year and 3 months on my Dell Wyse (x86) and never had this issue again.