Usb Key Been Disconnected When Drives Spin Down - (SOLVED) New USB Key

[ccsnet]

Hi all... My server is running in the latest RC and seems to be great except I think the usb key is been fully dismounted when the drives spin down by them selves.

 

It does not seem to be an issue if I have backups running or copying data on / off only when the machine is idle.

 

Manually spinning down does not seem to do it but if I leave the server alone for a few hours I find the UX crashed and the flash drive no longer mounted.

 

I have put the key in a usb hub and direct in to a port with no change.

 

I do not think it's the RC as I had the same problem before hand but for the last few weeks the server had been busy reloading my data.

 

Has anyone come across this ?

 

Are there any hidden power settings relating to the usb ports or drives or do I need to disable spining down (I'd prefer not to tbh).

 

Is there a way to see if the drive is included in a spin down group ?

 

I'm going though my logs and when back home I'll post any thing relevant.

 

Thanks in advance

 

Terran

 

Edited March 9, 2019 by ccsnet

[trurl]

2 hours ago, ccsnet said:

UX crashed and the flash drive no longer mounted.

How did you determine it is no longer mounted if the UX is crashed?

 

2 hours ago, ccsnet said:

I have put the key in a usb hub and direct in to a port with no change.

Definitely don't use a hub. Are you using a USB2 port? Have you tried putting flash in PC and letting it checkdisk?

 

That's about all I can offer without diagnostics. If you can't get them from the webUI see the Need Help? sticky pinned near the top of this same subforum for instructions on getting diagnostics from the command line.

 

[ccsnet]

The UX is partly working but certain elements don't. I'll see if I can get a screen shot as it's strange plus I'm not sure but I think the dockers are still running.

 

I'll grab the diags when I'm able to and I've had a remote syslog running to capture any thing as well.

 

Thanks

 

Terran

[Squid]

9 hours ago, ccsnet said:

I think the usb key is been fully dismounted when the drives spin down by them selves.

If anything, that's coincidental

9 hours ago, ccsnet said:

I have put the key in a usb hub and direct in to a port with no change.

A hub is one more point of failure on any system, and shouldn't be used.  BTW, once the flash has been disconnected, no amount of replugging it will get it recognized again as the boot device 

 

9 hours ago, ccsnet said:

Are there any hidden power settings relating to the usb ports

No. 

 

9 hours ago, ccsnet said:

do I need to disable spining down (I'd prefer not to tbh).

Not related

 

[ccsnet]

Hi Squid. Box has been spot on all day how ever I just ran the appdata backup for the first time and it occured again.

 

Diags attached.

 

If it's a faulty usb I can put up with that I just can't tell at the moment.

 

 

tbmaindoma-diagnostics-20190302-2230.zip

[ccsnet]

1 minute ago, ccsnet said:

Hi Squid. Box has been spot on all day how ever I just ran the appdata backup for the first time and it occured again.

 

Diags attached.

 

If it's a faulty usb I can put up with that I just can't tell at the moment.

 

 

tbmaindoma-diagnostics-20190302-2230.zip

 

[ccsnet]

And again... 2 out of the 3 data drives are spun down.

 

I'm thinking a new usb key is required how ever it's disappointing as this was new not long back.

 

I've got the key going direct in to a usb 2 port now.

 

I did try and put a usb 4 port card in in case it was a bus issue but unraid does not want to play.

 

I have also changed to a legacy boot mode.

 

If any one could confirm my findings it would be appreciated.

 

T

 

tbmaindoma-diagnostics-20190303-1718.zip

Edited March 3, 2019 by ccsnet

[ccsnet]

...and its gone again after rebooting 3 hrs ago.

 

I disabled the spin down so I would say that is not linked.

 

Very frustrating though even more so than Windows.

Terran

Edited March 3, 2019 by ccsnet

[cpshoemake]

Replace your USB flash drive. You have numerous write errors at the end of your syslog, just before it hangs. See below excerpt.

Mar  3 15:44:12 tbmaindoma root: cp: error writing '/boot/config': Input/output error
Mar  3 15:44:12 tbmaindoma rsyslogd: file '2' write error: Input/output error [v8.40.0 try https://www.rsyslog.com/e/2027 ]
### [PREVIOUS LINE REPEATED 22 TIMES] ###
Mar  3 15:44:12 tbmaindoma kernel: FAT-fs (sdb1): FAT read failed (blocknr 2792)
### [PREVIOUS LINE REPEATED 103 TIMES] ###
Mar  3 15:44:12 tbmaindoma rsyslogd: file '2' write error: Input/output error [v8.40.0 try https://www.rsyslog.com/e/2027 ]
Mar  3 15:44:12 tbmaindoma kernel: FAT-fs (sdb1): FAT read failed (blocknr 2792)
...

Edited March 3, 2019 by cpshoemake

[ccsnet]

I also got this....

 

Quote

2019-03-03 20:45:27    Kernel.Info    192.168.1.10    Mar  3 20:45:27 tbmaindoma kernel: usb 2-1.6: reset high-speed USB device number 4 using ehci-pci
2019-03-03 20:45:33    Kernel.Error    192.168.1.10    Mar  3 20:45:32 tbmaindoma kernel: usb 2-1.6: device descriptor read/64, error -110
2019-03-03 20:45:48    Kernel.Error    192.168.1.10    Mar  3 20:45:48 tbmaindoma kernel: usb 2-1.6: device descriptor read/64, error -110
2019-03-03 20:45:49    Kernel.Info    192.168.1.10    Mar  3 20:45:48 tbmaindoma kernel: usb 2-1.6: reset high-speed USB device number 4 using ehci-pci
2019-03-03 20:45:49    Kernel.Error    192.168.1.10    Mar  3 20:45:48 tbmaindoma kernel: usb 2-1.6: device descriptor read/64, error -71
2019-03-03 20:45:49    Kernel.Error    192.168.1.10    Mar  3 20:45:49 tbmaindoma kernel: usb 2-1.6: device descriptor read/64, error -71
2019-03-03 20:45:49    Kernel.Info    192.168.1.10    Mar  3 20:45:49 tbmaindoma kernel: usb 2-1.6: reset high-speed USB device number 4 using ehci-pci
2019-03-03 20:45:49    Kernel.Error    192.168.1.10    Mar  3 20:45:49 tbmaindoma kernel: usb 2-1.6: device not accepting address 4, error -71
2019-03-03 20:45:50    Kernel.Info    192.168.1.10    Mar  3 20:45:49 tbmaindoma kernel: usb 2-1.6: reset high-speed USB device number 4 using ehci-pci
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: usb 2-1.6: device not accepting address 4, error -71
2019-03-03 20:45:50    Kernel.Info    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: usb 2-1.6: USB disconnect, device number 4
2019-03-03 20:45:50    Kernel.Info    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
2019-03-03 20:45:50    Kernel.Info    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 19 04 3c 00 00 01 00
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: print_req_error: I/O error, dev sdb, sector 1639484
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): Directory bread(block 1637436) failed
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): Directory bread(block 1637437) failed
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): Directory bread(block 1637438) failed
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): Directory bread(block 1637439) failed
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): unable to read inode block for updating (i_pos 13026307)
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): Directory bread(block 1637436) failed
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): Directory bread(block 1637437) failed
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): Directory bread(block 1637438) failed
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): Directory bread(block 1637439) failed
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): FAT read failed (blocknr 2869)
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): FAT read failed (blocknr 2869)
2019-03-03 20:45:50    Kernel.Error    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: FAT-fs (sdb1): unable to read inode block for updating (i_pos 13026307)
2019-03-03 20:45:50    Kernel.Warning    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: ------------[ cut here ]------------
2019-03-03 20:45:50    Kernel.Warning    192.168.1.10    Mar  3 20:45:50 tbmaindoma kernel: bdi-block not registered

Annoying if so as its not very old this key.

 

Thanks for the feed back so far... 

 

Terran

SyslogCatchAll-2019-03-03.txt

 

EDIT: I've ordered a new key... heres hoping its not another dud

Edited March 3, 2019 by ccsnet

[ccsnet]

Hi all... new key is in and the system feels smoother (placebo affect I guess) how ever the key thing is that its not fallen over since. The good news is that I also got my money back after I shared the logs above so thank you every one who has helped.

 

It does show though that it is possible to get a new USB that actually fails out of the box.

 

Terran