External USB disks go to sleep and never wake up again

K

kamzata

Renowned Member
Proxmox Subscriber
Jan 21, 2011
229
9
83
Italy
I connected 2 external USB drives (1 HDD and 1 SSD NVMe) and both go to sleep and then they never wake up again. This happen even if I'm copying files from the internal disk to them resulting in a failed copy.

I'd like to wake up them when necessary.

Any hints?
 
This is abnormal behavior. There are broadly 2 possibilities:

1. The drives themselves are entering a sleep/shutdown state & for some reason are not "waking up".
2. The USB port/hub itself is powering down & not coming back up.

Things I'd try:

lsusb before & after that sleep state.
hdparm -C /dev/sdX before & after that sleep state (replace /dev/sdX with the correct device).
Use/try a different USB port/hub/cable/adapter.
Checking BIOS settings concerning USB ports/power/sleep etc.
 
gfngfn256 said:
This is abnormal behavior. There are broadly 2 possibilities:

1. The drives themselves are entering a sleep/shutdown state & for some reason are not "waking up".
2. The USB port/hub itself is powering down & not coming back up.

Things I'd try:

lsusb before & after that sleep state.
hdparm -C /dev/sdX before & after that sleep state (replace /dev/sdX with the correct device).
Use/try a different USB port/hub/cable/adapter.
Checking BIOS settings concerning USB ports/power/sleep etc.
Click to expand...

After they went to sleep lsusb doesn't show them but before they are showed:

Code: 
root@proxmox:~$lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0033 Intel Corp. AX211 Bluetooth
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. JMS583Gen 2 to PCIe Gen3x2 Bridge
Bus 004 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

After I rebooted and the disks are awake I run this:
Code: 
root@proxmox:~$hdparm -C /dev/sda

/dev/sda:
 drive state is:  standby
root@proxmox:~$hdparm -C /dev/sdb

/dev/sdb:
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 drive state is:  standby

/dev/sda is the HDD
/dev/sdb is the SSD

I already tried to connect to different ports with different cables. Now I'm going to check the BIOS.
 
Last edited:
gfngfn256 said:
Please show that lsusb output after they sleep.
Click to expand...

When they are awake:
Code: 
root@proxmox:~$lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0033 Intel Corp. AX211 Bluetooth
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. JMS583Gen 2 to PCIe Gen3x2 Bridge
Bus 004 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

When they are asleep:
Code: 
root@proxmox:~$lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 8087:0033 Intel Corp. AX211 Bluetooth
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 
gfngfn256 said:
If you plug in a random plain USB flash drive, does it also fall asleep?
Click to expand...

I didn't try. It takes a while before they go to sleep. Maybe 1 hour.

Furthermore:
Code: 
root@proxmox:~$sg_decode_sense 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid command operation code
 
kamzata said:
Maybe 1 hour.
Click to expand...
OK. I'm now seeing that 1 hour mark - & this along with the fact that you are complaining of it dropping off even in the middle of disk read/write events, tells me that something is throttling that USB bus. JMicron chips of the type you are using for that SSD is probably the culprit. There have been numerous reports of the USB bus/port issues it has caused. Both your SDD & HDD are connected on Bus 4.

Could you try a test of only connecting the USB HDD, which I believe is using ASMedia chip & see if it remains stable even past the 1 hour mark.
 
gfngfn256 said:
OK. I'm now seeing that 1 hour mark - & this along with the fact that you are complaining of it dropping off even in the middle of disk read/write events, tells me that something is throttling that USB bus. JMicron chips of the type you are using for that SSD is probably the culprit. There have been numerous reports of the USB bus/port issues it has caused. Both your SDD & HDD are connected on Bus 4.

Could you try a test of only connecting the USB HDD, which I believe is using ASMedia chip & see if it remains stable even past the 1 hour mark.
Click to expand...
At the moment both are connected and they fall asleep either. I rebooted 1:50 hour ago and now the HDD is already felt asleep while the SSD is still awake. So, it could be 1 hour or even more.

However, yes, the HDD is using ASMedia chip.
 
gfngfn256 said:
OK. I'm now seeing that 1 hour mark - & this along with the fact that you are complaining of it dropping off even in the middle of disk read/write events, tells me that something is throttling that USB bus. JMicron chips of the type you are using for that SSD is probably the culprit. There have been numerous reports of the USB bus/port issues it has caused. Both your SDD & HDD are connected on Bus 4.

Could you try a test of only connecting the USB HDD, which I believe is using ASMedia chip & see if it remains stable even past the 1 hour mark.
Click to expand...
Just changed USB port and left just the HDD connected now.
 
gfngfn256 said:
OK. I'm now seeing that 1 hour mark - & this along with the fact that you are complaining of it dropping off even in the middle of disk read/write events, tells me that something is throttling that USB bus. JMicron chips of the type you are using for that SSD is probably the culprit. There have been numerous reports of the USB bus/port issues it has caused. Both your SDD & HDD are connected on Bus 4.

Could you try a test of only connecting the USB HDD, which I believe is using ASMedia chip & see if it remains stable even past the 1 hour mark.
Click to expand...
After 1 hour is still awake.
 
If this persists & the HDD does not sleep. You can try the reverse & see if the SSD when connected by itself what happens.
There is the possibility it is caused by the overdraw of power on that USB bus.

As far as I remember those JMicron chips either are either plain buggy or draw excessive power or plain overheat (or all of the above!).
You could try separating the 2 devices on different buses if possible, or more likely replacing that SSD (M.2 ?) adaptor with a different one. Depends on your testing.
 
gfngfn256 said:
If this persists & the HDD does not sleep. You can try the reverse & see if the SSD when connected by itself what happens.
There is the possibility it is caused by the overdraw of power on that USB bus.

As far as I remember those JMicron chips either are either plain buggy or draw excessive power or plain overheat (or all of the above!).
You could try separating the 2 devices on different buses if possible, or more likely replacing that SSD (M.2 ?) adaptor with a different one. Depends on your testing.
Click to expand...
That could be a good reason. I will try to split the disks among the buses. Whenever I try to transfer a big file between this SSD (M2 NVMe with Sabrent adaptor) to HDD it fails because one or the other fall asleep. It happens very very often, I'd say 7 times to 10 and then I can just reboot.
 
Last edited:
That Sabrent adaptor is a Thunderbolt only device as far as I can see. This may also be the source of your problems. There have been problems reported with Thunderbolt on recent kernels.

What does pveversion -v show.
 
gfngfn256 said:
That Sabrent adaptor is a Thunderbolt only device as far as I can see. This may also be the source of your problems. There have been problems reported with Thunderbolt on recent kernels.

What does pveversion -v show.
Click to expand...

Sorry, I was wrong. This is the adaptor that I own.

However, the SSD has gone asleep again while the HDD's not 'till now.

Code: 
root@proxmox:~$pveversion -v
proxmox-ve: 8.3.0 (running kernel: 6.8.12-5-pve)
pve-manager: 8.3.2 (running version: 8.3.2/3e76eec21c4a14a7)
proxmox-kernel-helper: 8.1.0
pve-kernel-5.15: 7.4-4
proxmox-kernel-6.8: 6.8.12-5
proxmox-kernel-6.8.12-5-pve-signed: 6.8.12-5
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
proxmox-kernel-6.5.13-6-pve-signed: 6.5.13-6
proxmox-kernel-6.5: 6.5.13-6
pve-kernel-5.15.108-1-pve: 5.15.108-1
pve-kernel-5.15.74-1-pve: 5.15.74-1
ceph-fuse: 16.2.15+ds-0+deb12u1
corosync: 3.1.7-pve3
criu: 3.17.1-2+deb12u1
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.4
libpve-access-control: 8.2.0
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.10
libpve-cluster-perl: 8.0.10
libpve-common-perl: 8.2.9
libpve-guest-common-perl: 5.1.6
libpve-http-server-perl: 5.1.2
libpve-network-perl: 0.10.0
libpve-rs-perl: 0.9.1
libpve-storage-perl: 8.3.3
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.5.0-1
proxmox-backup-client: 3.3.2-1
proxmox-backup-file-restore: 3.3.2-2
proxmox-firewall: 0.6.0
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.3.1
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.3.3
pve-cluster: 8.0.10
pve-container: 5.2.3
pve-docs: 8.3.1
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.2
pve-firewall: 5.1.0
pve-firmware: 3.14-2
pve-ha-manager: 4.0.6
pve-i18n: 3.3.2
pve-qemu-kvm: 9.0.2-4
pve-xtermjs: 5.3.0-3
qemu-server: 8.3.3
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.6-pve1
 
Last edited:
I recommend getting something like "Y" cable with extra usb connector for aux power. Some SSDs/HDD can overwhelm USB port's power, if they are connected to same bus internally.
 
Just one more thing. I see your System is fully updated. On some recent kernels there have been reported USB issues. Has this problem only started recently (6.8 kernels?). If yes - you could try pinning your kernel to that 6.5 one you have on your system & trying again.

Another thing: since your USB port/s appears to crash (not sleeping drives) - you may experience some data corruption on these drives. Make sure you have adequate backups.
 
Last edited:
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom