RPi 4B, USB attached HDD fails with the message "xhci_hcd 0000:01:00.0: WARN Cannot submit Set TR Deq Ptr" in dmesg #3981
Comments
|
I don't know if it is the same problem but we have old Raspberry Pi 2 that streams from IP camera and stores video to mounted SMB storage. With kernel 4.19, everything runs for weeks without any problem. After update to kernel 5.4, it runs for a while but after several hours the access to the remote storage (even simple "ls /mnt") freezes the Raspberry. Similar backtrace appears in kernel log. I don't have the exact backtrace now, because we downgraded back to kernel 4.19 and everything runs without problem again. |
|
Thanks for the information. I just downgraded to 4.19.118, let's see if this changes something. It might take days until the issue occurs, but I'll keep you updated. |
|
Possibly a duplicate of #3210 |
I still have the test running with the downgraded kernel version. If the issue occurs again I will try |
|
Could it be caused by the automatic hibernation of the hard disk, and the hard disk may enter a low power consumption mode without data collection for a long time? Similar to hard disk hibernation? |
|
I am running Raspbian OS version 2020-08-19 and kernel version as following : and dmesg info: seems it is work property for me, my Raspberry Pi 4B 8GB works fine. lsblk infor: |
As I wrote, I have a script which writes a file each minute, so that the disk does no go to sleep. But still the problem occurred.
What is the uptime of your RPi? Days, weeks, or even months? P.S.: With the downgraded kernel, the problem did no occur until now. |
|
In our case, HDD does not hibernate either. Data is being written to it permanently. It is remote network HDD connected via SMB. |
|
FYI: after downgrading the kernel to 4.19 there were no more problems with the HDD so far. |
|
Same issue here. @githubharald how did you downgraded your pi to 4.x kernel? Thanks |
|
|
|
I believe I'm having this same issue. I'll try downgrading as well. It typically loses access to external HDD after 1-3 days of uptime. I'm writing data to it ~every 10 minutes. I will try the downgrading from 5.4.79 to 4.19 using your command. Current Version Version after running
|
|
@debuti |
|
So far the downgrading solves the problem yes, its been 3 days without issues (while usually in 1-2 days it was failing) |
|
After 5 days without issue it's safe to say this has solved my issue. |
|
would be cool if someone from the RPi team could comment on this. It seems that some bug was introduced in the new kernel. Are all of you with the problem also using a Toshiba ext HDD (at least from the logs AaronFaltesek seems to also have one). |
|
No, i have WD or Seagate (not sure which one fails) |
|
Same issue with 2 WD disks running as raid on the USB3 connectors: This does not seem related to #3210 as mentioned above, I'm running on a 4MB PI headless and there's no OOM in the logs. |
|
I just wanted to reply and state that downgrading to 4.19.118-v7l+ fixed my issue. I was having this same issue for MONTHS where the connection to my external (powered) USB hard drive would just randomly freeze (within a day or 2 of rebooting my Pi). It would still show as mounted, but I couldn't' access it and the drive light would constantly blink. I would have to reboot my Pi 4 B in order for the drive to be accessible again for a day or so. I downgraded to 4.19.118-v7l+ via the command githubharald posted. That was 4 days ago and the drive is still connected.Thank you everyone for this post!! It was driving me nuts. Has anyone tried to contact the Raspberry Pi folks to let them know? I'm assuming they have to know about this, as it's been going on for a number of months now. sudo rpi-update e1050e94821a70b2e4c72b318d6c6c968552e9a2 |
|
I am having the same issues (external USB HDD stop responding randomly, usually after a day uptime) : I will try to downgrade to 4.19 and let you know , I am just curious why I am on version 5.1 and everyone else is on 5.4 (I don't get 5.4 via apt upgrade) |
|
This isn't just raspberrypi, I have this issue on my mythbuntu installation with an external drive. Kernel is 5.4. Trying to figure out how to downgrade to 4.19. I was going to upgrade to 5.10 but it seems that has an issue too. Frustrating! |
|
|
the same issue on my RPI4 Linux rpi4tvhead 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux The USB 3.0 drive is : Bus 002 Device 002: ID 1058:1230 Western Digital Technologies, Inc. My Book (WDBFJK) The same problem was on other HDD i've previously tested. The kernel log as below: [819629.648204] xhci_hcd 0000:01:00.0: WARN Cannot submit Set TR Deq Ptr When I try to downgrade kernel with i get the message : *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom Is it safe to proceed? |
|
Provided you've got about 60MB free in your boot partition you should be fine. It's disappointing that the creator of the distribution didn't make it 1MB larger just to avoid that warning. |
|
How is the WD drive powered? The Pi's USB sockets can't provide enough current for HDDs under load, and even SSDs can be marginal. Which chipset does the USB<->SATA adaptor use ( |
Both HDDs were externally powered. The USB <-> SATA adaptor is ASM1151, but with dedicated WD firmware programmed (as far as I know It locks adapter to particular HDD with specified size and serial number). That's why it's recognized as : Bus 002 Device 002: ID 1058:1230 Western Digital Technologies, Inc. My Book (WDBFJK) Previous HDD I've tested was using the same chip, but with cleared EEPROM, so It wasn't recognized as WD anymore. The same configuration was working great on RPI2. I've switched to RPI4 few months ago, for better wr/rd speeds over USB. And all this time I've struggled with this random USB crashes every 1-3 days. Few days ago I've switched to other HDD and the problem still occures.
I still have ~200MiB free on boot partition. /dev/mmcblk0p6 258094 48784 209310 19% /boot |
|
And which power supply is the Pi 4 using? |
It uses 5V 3A dedicated RPI4 power supply, same as this one: https://kamami.pl/zasilacze/575564-zasilacz-5v3a-usb-c-do-raspberry-pi-4-czarny.html |
|
I tested using an external powered USB hub, but this did not make a difference (see original post). |
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
commit a01ba2a3378be85538e0183ae5367c1bc1d5aaf3 upstream. See raspberrypi/linux#3981 Two read-modify-write cycles on ep->ep_state are not guarded by xhci->lock. Fix these. Fixes: f524946 ("xhci: Clear the host side toggle manually when endpoint is soft reset") Cc: stable@vger.kernel.org Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211008092547.3996295-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
See #3981 An unknown unsafe memory access can result in the ep_state variable in xhci_virt_ep being trampled with a stuck SET_DEQ_PENDING state despite successful completion of a Set TR Deq Pointer command. All URB enqueue/dequeue calls for the endpoint will fail in this state so no transfers are possible until the device is reconnected. As a workaround, clear the flag if we see it set and issue a new Set TR Deq command anyway - this should be harmless, as a prior Set TR Deq command will only have been issued in the Stopped state, and if the endpoint is Running then the controller is required to ignore it and respond with a Context State Error event TRB. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
and others
Describe the bug
Problem description:
I'm having random problems with my external harddisk (HDD) connected to my Raspberry Pi 4B. When accessing the HDD with samba, or by doing a git push, the operation sometimes freezes on my computer or smartphone or smart-tv. When I then have a look at the HDD, I can see the white status LED blinking without stopping. I can ssh the RPi, but when I want to access the HDD (e.g. cd or ls on it), the ssh session also freezes. I also can not reboot using the reboot command. But as soon as I unplug the HDD, everything works fine again. After rebooting things usually work fine for quite some time again. Also keeping the HDD active (writing a file each minute) does not help, but it seems like the problem is not power-supply-related, because there are not more spin-ups needed because the HDD is never in standby mode.
What I tried so far:
At the beginning I directly attached the HDD to the USB3 port. It worked, but sometimes it made “click” noises, which might be caused by too little power. So I connected it to the USB2 port. Worked fine until after 1 month I got the issues described above, that samba was hanging. This happened multiple times, from different client devices. I then plugged a powered USB2 hub in between, and the problems disappeared for 2 month. I though it was solved, but this week I had the issue 2 times, first time when doing a git push, second time when I wanted to backup files from my computer to the samba share. I also added a cron job that writes a timestamp-file each minute to avoid the HDD to go to standby mode. But also with this it happened again after 5-6 days.
Hardware:
Hard disk connected to powered USB 2.0 Hub, Hub connected to RPi USB2 port (now switched to USB3 port)
External hard drive: TOSHIBA MQ01UBD100, 1TB, 3 partitions, all formatted as ext4
Powered USB 2.0 Hub: Belkin 7 port hub (lsusb shows 3 hubs, nut sure which one it is)
The part of the lsusb output showing something hub related:
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
RPi: model 4B, 4GB RAM, Linux raspberrypi 5.4.72-v7l+, apt-get update and upgrade done just a few days ago
Power supply: the “official” one
Connected to network via LAN port
To reproduce
Details about my setup see above. Basically, it seems to be somehow random, so there is no "do action X to cause issue Y".
Expected behaviour
Run 24/7 without at some point having processes hang which access the HDD.
Actual behaviour
Again, see above. Processes (like samba, git, or just some Python script writing to the HDD) accessing HDD hang.
System
Output of raspinfo: raspinfo.txt
Logs
dmesg only showing the OOM errors due to the hanging scripts which should keep the HDD active. Therefore the interesting information in the log seems to be already gone.
Here are some parts of /var/log/messages which might have something to do with the problem:
And some time later, we get OOM errors because of all the processes that should write to the file on the disk but hang:
blkid still shows all three partitions.
umount /dev/sda1: target is busy (also when using -l), or the command hangs (had both situations).
Is there anything else I can check?
Additional context
Also discussed in RPi Forum.
The text was updated successfully, but these errors were encountered: