Unexpected USB device disconnect and then connect again #5959
Comments
We can't rule out this being a bug in the out-of-tree driver. |
USB sound DAC, keyboard, mouse, flash disk and RTLSDR dongle:
I'm using 15W Raspberry Pi PSU
SDR++ it uses RTLSDR dongle |
|
Are you saying that you are powering an external drive, a DAC, a keyboard & mouse, SDR dongle and a hub all from our 15W PSU? |
|
The total power consumption is about 5-7W (the current is 1.0-1.2 Amps). |
|
I think you are pushing at the limits of what the Pi can power. If you can continue to see these random disconnection when the SDR dongle and flash drive are connected via a powered hub then I'll be more interested. BTW, I don't make a drive <-> flash distinction - your flash dongle is my flash drive. If I'd said hard drive then you'd have a point. |
|
This issue is not related to power at all and don't related to flash drive. I can approve it 100%. I'm sure that this is software issue. This issue happens when total power consumption of RPI + all devices don't exceeds 1 Amp (5 Watt), while power supply is genuine 15W and can provide much more power with no issue. Undervoltage flag is not raised after this issue. I just caught it again: This time it happens with no flash disk connected: Here is log file, now it has some new records: If you want I can connect lab power supply and attach DMM in CREST mode to detect max and min peak voltage spikes until issue heappens again. But since it is powered with genuine 15W raspberry pi PSU which can provide 3 Amps and actual power consumption is just 1 Amp and there is no undervoltage event flag, this is already clean indication that power is absolutely ok and there is no power issue. I'm sure for 100% that there is no power limit issue and voltage didn't drop below 5.1V Previously exactly the same hardware worked well with no issue for a very long time. The only changes are apt upgrade and replace osmocom rtlsdr driver with self compiled rtl-sdr-blog driver. I suspect it may be related with rtl-sdr-blog driver, I will check it. But this issue happens for all USB devices connected to RPI. I think that running SDR software just increase probability to catch this issue due to many data transfering over USB. |
|
just compared code changes in rtl-sdr-blog and there is nothing suspicious that can raise such issue with all USB devices disconnect. So, the only root of cause for this issue is a bug in the driver for RPI 4B onboard VIA USB hub. Please fix it, because it happens very often. |
|
I installed original oscmocom driver. After some time I caught this error: it happens when SDR app is not worked and RTLSDR didn't used. Two processes was running: VLC in minimized state playing internet radio and my lightweight OpenGL game. So, it can happens even when USB device is not used... |
|
I run sdr-trunk with my RTL-SDR on my pi5 and do not have any disconnects. It will disconnect if I do not have some modules that are recommended to be blacklisted. https://sdr-enthusiasts.gitbook.io/ads-b/setting-up-rtl-sdrs/blacklist-kernel-modules |
|
it continue happens, just got this, I'm not sure, is it possible that this issue happens due to bad support for my USB hub? Previously it worked ok, it starts to happens with some apt update, about month ago or something like that. |
|
I think I'm also having this issue - it just recently with octopi. Redeployed the OS (which upgraded from buster to bullseye) and it still occurs. Seemed to happen after a software update, but can't pinpoint it. |
|
@dangelovich the google rabbit hole gods sent me here... I just started getting this between my rPi running OctoPi and it is tanking my prints with my MK3S: |
|
Having the same issue with an Realtek SDR on a Pi Zero 2: |
|
I also notice that USB disconnect start occurs too often, probably some issue with USB hub driver rolled out with some latest update |
|
Interesting enough this also happens with regular Debian 12, in my case a mini laptop with a USB BT dongle, already installed realtek firmware and tried a bunch of other stuff with no success. |
|
Hi, This is definitely an issue with raspberry-pi hardware or software/drivers. I use:
On Raspberry Pi 4 running Ubuntu 22-24, I've configured ZFS Jan 31 10:03:41 ubuntu kernel: sd 5:0:0:0: [sdf] tag#15 data cmplt err -75 uas-tag 6 inflight: CMD
Jan 31 10:03:41 ubuntu kernel: sd 5:0:0:0: [sdf] tag#15 CDB: Read(10) 28 00 32 2a 93 90 00 04 00 00
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#17 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD IN
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#17 CDB: Read(10) 28 00 32 2a a3 90 00 04 00 00
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#16 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#16 CDB: Read(10) 28 00 32 2a 9f 90 00 04 00 00
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#15 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#15 CDB: Read(10) 28 00 32 2a 93 90 00 04 00 00
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#13 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD IN
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#13 CDB: Read(10) 28 00 32 2a 9b 90 00 04 00 00
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#12 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD IN
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#12 CDB: Read(10) 28 00 32 2a 97 90 00 04 00 00
Jan 31 10:04:12 ubuntu kernel: scsi host5: uas_eh_device_reset_handler start
Jan 31 10:04:12 ubuntu kernel: usb 2-1.4: reset SuperSpeed USB device number 13 using xhci_hcd
Jan 31 10:04:12 ubuntu kernel: usb 2-1.4: device firmware changed
Jan 31 10:04:12 ubuntu kernel: scsi host5: uas_eh_device_reset_handler FAILED err -19
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: Device offlined - not ready after error recovery
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: Device offlined - not ready after error recovery
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: Device offlined - not ready after error recovery
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: Device offlined - not ready after error recovery
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: Device offlined - not ready after error recovery
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#12 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK cmd_age=30s
Jan 31 10:04:12 ubuntu kernel: sd 5:0:0:0: [sdf] tag#12 CDB: Read(10) 28 00 32 2a 97 90 00 04 00 00
Jan 31 10:04:12 ubuntu kernel: I/O error, dev sdf, sector 841652112 op 0x0:(READ) flags 0x4000 phys_seg 128 prio class 0Now, what's the most important: when the SAME setup is connected to Dell Precision 5510 running Ubuntu 24 (same hub, same HDDs, same cables), it runs smoothly: NOT a single disconnect, works during HEAVY loads for DAYS. I even connected another SSD zpool (3x SSD) to the same Hub which means now ALL 7 of 7 PORTS of the HUB are used - and copy from one zpool to another works WITHOUT even a single disconnect - flawlessly. P.S.: I don't know when the USB issue was introduced, but I was running zpool with the above mentioned setup on RPI for almost 3 years (was on Ubuntu 22, only recently upgraded to Ubuntu 24). And the issue was there as long as I remember. It works fine with lightweight workloads, but always disconnects during heavy ones. I was only able to withstand such disconnects due to properly configured watchdog (it rebooted the PI automatically) and because it was used as a cheap cloud server - downtimes was OK for me. Probably related issues:
Update: the problem seems in UAS driver, fallback-ing to the usb-storage driver solves the issue. |
|
Well I might have found a fix to the issue at least in my case. So it seems that USB autosuspend was actually powering down my devices. In my case disabling autosuspend fixed it. this however is only a "temporary" solution because it won't hold on reboots Alternatively you can try to add to grub, or better yet create a udev rule for your device. Disabling autosuspend will increase power consumption so udev rules are probably the best way to go, if this is your issue and this actually solves it. |
|
I think there is a weird issue related to
|
Uh oh!
There was an error while loading. Please reload this page.
It start to happens last week. First I thought this is just random disconnection, but now this error happens for at least 4 times, so there is something wrong...
I'm using rtl-sdr-blog driver for RTLSDR dongle. It works for some long time, but then unexpectedly disconnected and immediately connected again.
I'm using RPI 4B with VIA USB chip, and previously there was issue in VIA chip driver which prevented normal function for xhci_hcd USB device drivers. It was fixed, but it seems that still something going wrong.
Also I notice strange full system halt with no log records and no way to connect through ssh. It already happens two times. And it started to happens after last updates.
It may be related to this issue: raspberrypi/bookworm-feedback#83
Steps to reproduce the behaviour
Device (s)
Raspberry Pi 4 Mod. B
System
Logs
Additional context
No response
The text was updated successfully, but these errors were encountered: