[RPi4 4GB] xHCI host controller not responding, assume dead #3404
Comments
|
It might be worth trying different versions of the VL805 firmware. There’s a thread about it here |
|
Thank you. I will give it a try and share the outcome. |
|
Well, on raspbian all went well, but not in hassio. Before shutting down Raspbian I have ensured that the latest vl805 firmware was properly installed (using ´sudo vl805´ and have shown 0137ad). Do you know if the EEPROM bin file deppends on any other optimization on the linux kernel side? or it should fix the USB behaviour by itself? Thanks in advance. |
|
Please, disregard my last post. Took additional actions and all good apparently. 3 hours have passed and all is stable. Many thanks once again! |
|
Just to confirm that everything is still working perfectly. |
|
Hey!! Having exactly the same issue on VL805 FW version: 000137ad Are you still having issues? Can you provide more info about what you did to solve it? |
|
Here some logs: |
|
Hi @hardwareadictos, It worked for about 1 week with VL805 FW 0137ad and then I am facing the same issue again. |
|
I opened an issue for that because I don't know if we have the same issue (I suspect we do): Don't doubt on participating. Thanks for answering 😊 |
|
This could explain some things: c74b1b5 Dont know if that change is already implemented on last kernel... |
|
That patch allows for the possibility of loading VL805 firmware from system RAM rather than EEPROM, which has to be re-enabled after a PCI reset. The VPU firmware is not making use of that facility, so when it comes to your problem that commit is a red herring. |
Im not an expert, that's why i said "could" and not "actually". Was also the only recent commit referencing to xHCI. That issue isnt happening on previous releases. What's you opinion on that? Thanks in advance :) |
|
Perhaps the on-board voltage is a marginal - try adding |
Thank you! Applied. Will test it some days and i will report back. |
|
thank you @pelwell Cheers |
|
24 hours. No issues so far. Next report on Monday, but seems that was the issue... |
|
One week without issues, i consider this issue fixed :) |
|
I also confirm that after 1 week, all is ok. |
|
Agree. It was working before that voltage related changes on kernel. Maybe someone can give more feedback about that. But for the moment all is working as always |
Indeed, I expect a future firmware release will fix this, if the most recent one hasn't already done so. |
|
I am currently running on 0137ad |
|
The VideoCore firmware controls DVFS so the update would be there rather than the XHCI firmware. Might be worth trying rpi-update (assuming you are familiar with rpi-update / risks of using early firmware) |
|
I am having the same issue after updating to the latest release. If I disconnect the [powered] USB3 hub and boot and then connect the hub, I can see the disks for a few minutes (they show in 'blkid' and 'df' and I can also 'ls' the mount points and see my files). They then they disconnect. Looking at dmesg, the same error as others is being produced: I am currently running on 0137ad I have tried over_voltage=1 (in fact I have tried a number of over_voltage numbers or 1,2 and 3) $ cat /proc/cpuinfo | tail -3 $ cat /etc/os-release | head -4 $ uname -a I am an old DEC 10/TOPS-10, VAX/VMS and PDP11/RSX11M+ assembler programmer. Unix is rather new to me. I apologies in advance if I come over as a noob |
|
@DrJohnM61 do you know what firmware/kernel you were on previously? |
IIRC the prior version was the 5th Feb release I tried the force_turbo=1 but does not seem to make any difference. Will try the firmware alternative in the morning (its late now here in London) |
I copied the files that your link pointed to into the /boot directory. Not sure if I was supposed to do anything after that (I am a unix noob). Rebooted and the problem with USB 3 connected hub and devices is still there. I note that the 'name -a' showed no difference in firmware version, so I suspect I am missing a step. Went back to page one of the blog that you direct me to and executed the 'sudo rpi-update 4b2c270' command. Rebooted and then power cycled and the problem has gone away, so clearly (IMHO), this seems to be an issue that has been introduced in a later firmware version. I will note that somewhere between the 4b2c270 version and the latest, I could not boot the RP4 with the connected USB hub/disks and see them but would have to boot without the hub connected and then plug it in after the boot had completed. This change happened after implementing the firmware change that allowed overclocking. I had for some time looked at forums to find a combination of voltage and wait times to try and fix the issue. However, the latest version of the firmware (4.19.102-v7l+ #1295 SMP) just did not allow the external powered USB hub or disks to stably connect (and even if the USB HUB was connected after boot, the USB ports would successively shut down, causing problems with my RAID sets, until the whole HUB disconnected). Here is a snip from the log showing the USB disconnects (post force_turbo setting): Happy to try different firmware if someone can explain how to install it after pulling from a file share. |
Maybe your Power supply isnt giving you enough power then |
|
News? |
|
I have the same Problem! |
|
I'm seeing the same problem. |
|
me ² external hdd enclosure PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" raspbian 64 bit openmediavault 6 device disconnects, share disaspears - need to reset enclosure + pi 1.12.2022, 22:57:05
|
|
@Nazgile94 same problem. Without rebooting not works if i umount and mount again. |
|
duplicate of #5060 |
|
Seems closed but im new one with this problem |
|
I been having this issue and it's now "fixed" by adding the quirks to the cmdline: It's a lot slower, but at least it doesn't hang everyday!!! I was using an external HP SSD and it worked great, but it was veeery slow, so I replaced with an SSD with an external bay and my problems started. I blamed the cheap bay, replaced with a good one. Still the same. Replaced with an external well known SSD (Crucial) and the same!! I've created a "watchdog" on my NAS, I connected my RPi to a Shelly switch, so when the HomeAssistant that's running there doesn't reply for a while, my script turns it off and on again after some seconds. This worked fine, but still had one or two reboots per day. |
|
I take it that this issue is still occuring seeing as I appear to be having it |
Would you mind sharing your solution.....step by step and the "watchdog" script with us. Would be terribly greatful 'ol chap. |
|
Can I quantify / qualify.....is this a hardware, software, firmware / hardware combo or other issue completely???? Anyone? The reason I ask is a) it's not clear from the thread exactly where the problem lies....b) what the actual cause of the problem is (apart from A external USB connected to a Raspberry pi c) most importantly (and selfishly in my case) my Raspberry pi is still within it's 30 day retrurn period SO if it's a hardware issue i'll take the easier softer solution and send the thing back. Thanks |
|
In my case IT helped to give my SSD an external Power supply.
Declan Heerey ***@***.***> schrieb am Di., 28. Mai 2024,
13:51:
… Can I quantify / qualify.....is this a hardware, software, firmware /
hardware combo or other issue completely???? Anyone? The reason I ask is a)
it's not clear from the thread exactly where the problem lies....b) what
the actual cause of the problem is (apart from A external USB connected to
a Raspberry pi c) most importantly (and selfishly in my case) my Raspberry
pi is still within it's 30 day retrurn period SO if it's a hardware issue
i'll take the easier softer solution and send the thing back. Thanks
—
Reply to this email directly, view it on GitHub
<#3404 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACZXRJBIB4Y54CIB6ANZJPDZERVSTAVCNFSM4KGFPQPKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGUYDENJRGMYA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Cool. Thanks. Happy to try this. Easy enough to try and remedy with a spare powered USB hub I have hiding around here somewhere......now where did I leave it??? :o) |
|
I'm having mixed results....as usual with Raspberry Pi's....I didn't enter into this project to tinker but well that's what I always end up doing. Still, learning. Anyway ; Powering the USB SSD via a hub seems to work....BUT agonizingly not if I put any pressure (load) on the mount, filesystem / disk for long - so it probably isn't working at all....I see the following messages in
|
|
This reads more Like you should run a thorough checkt of your hard Drive.
Declan Heerey ***@***.***> schrieb am Di., 28. Mai 2024,
18:00:
… I'm having mixed results....as usual with Raspberry Pi's....I didn't enter
into this project to tinker but well that's what I always end up doing.
Still, learning. Anyway ;
Powering the USB SSD via a hub seems to work....BUT agonizingly not if I
put any pressure (load) on the mount, filesystem / disk for long - so it
probably isn't working at all....I see the following messages in dmesg
[ 561.128679] device offline error, dev sda, sector 0 op 0x1:(WRITE) flags
0x800 phys_seg 0 prio class 2 [ 561.128750] EXT4-fs (sda1): shut down
requested (2) [ 561.128784] Aborting journal on device sda1-8. [
561.128837] device offline error, dev sda, sector 247728128 op 0x1:(WRITE)
flags 0x9800 phys_seg 1 prio class 2 [ 561.128857] device offline error,
dev sda, sector 247728128 op 0x1:(WRITE) flags 0x9800 phys_seg 1 prio class
2 [ 561.128871] Buffer I/O error on dev sda1, logical block 30965760, lost
sync page write [ 561.128902] JBD2: I/O error when updating journal
superblock for sda1-8. [ 561.183827] sd 0:0:0:0: [sda] Synchronizing SCSI
cache
—
Reply to this email directly, view it on GitHub
<#3404 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACZXRJCW4LKZ5OKUSHOBX23ZESS2VAVCNFSM4KGFPQPKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGU3DANZXG42Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Some info ;
` VL805_FW: Using bootloader EEPROM
Official PSU, externally powered hub for SDD. |
Interesting. It was cheap, from Amazon....probably. You get what you pay for. I'll go down the hardware rabbit hole and see where that takes me. Thanks for the response. |
|
Is there any solution after all ? |
No, just the walk-arounds mentioned above they makes the usb not to crash but makes it slower and affects the lifespan of the disks 🤷🏻♂️ i dont think that a realfix (that needs a kernel update) its going to happen anytime, rpi5 has similar issues too |
How is this affecting the lifespan of the disks? I see my system is a lot slower than before and takes much more time to boot. I think even more than the external HP disk I had before that was like 10x times slower than the Crucial! But right now has been running since May 13th (when I rebooted it for an upgrade)! |
Changing the external SSD and USB connector "seems" to be working for me. For now at least. My setup now isn't ideal but it's only for testing atm.....I've reverted back to a second SD card and a adapter connected to a USB hub. I went through a multitude of swapping in and out and this worked so i moved on. |
I also found a table that shows all reliable adapters that work on USB 3.0 with RPi4 and I figure it out that my wasn't actually working and had buy another one. |
|
Alright well, even in 6.6.64-v8+ (custom built kernel from Raspberry Pi's sources with BBRv3 support), latest Raspbian, this is still an issue and it seems that using |
|
Thanks @David112x for confirming that. I've been using I'm waiting for a NVMe hat for my new RPi5 so I can move HASS to it and forget about these issues. Hope not have similar issues (but with another kernel module) 😛 |
Yeah so I tried using newer kernels and I found that: So in most cases these things are fine, but in my case I'm using a 2.5in hard drive which is NOT enterprise grade so having it on 24/7 without suspending at all is a problem because it could cut down it's lifespan, especially considering that the hard drive I use is from 10 years ago, barely having any use, sure, but it's still a good idea to take preventive measures, so I'll have to look into whatever made this a thing and revert it. Hopefully find out if the suspend thing is related to the XHCI controller crashes (and imo the drivers for the controller should be able to handle this instead of having UAS compensate for it) |
|
Update: The HDD does suspend, just doesn't suspend when I use the command |
and others
Describe the bug
After boot-up, an when activating a service that uses USB interface (Network UPS tools, as an example) xHCI interface crashs and the USB devices get disconnected. Recovery only possible after system reboot.
List of USB devices when the system boots up:
After enabling a:
To reproduce
After system boot, start Network UPS tools (UPS connected through USB, having a poll frequency of 30 seconds), and the xHCI interface will crash shortly after, leading to all USB devices being disconnected.
System
Details:
Raspberry Pi 4 Model B Rev 1.1cat /etc/rpi-issue)? HassOS 3.8vcgencmd version)?uname -a)? Linux hassio 4.19.93-v8 var->green.length may be left uninitialized #1 SMP PREEMPT Sun Jan 12 18:33:10 UTC 2020 aarch64 Hassio/OSLogs
dmesg output:
Additional context
This bug report was opened here because HassOS3.8 rus default raspbian Kernel.
This issue was initially reported here:
home-assistant/operating-system#526
USB cable was replaced to ensure that it was not faulty.
If more logs are needed, please let me know
The text was updated successfully, but these errors were encountered: