Jump to content

Recommended Posts

Posted

After a major failure of my file server I bought a pair of seagate desktop USB3 drives to use for temporary storage while I sort out the mess. I plugged them into an XU4 and started transferring several 100GBs of data only to have it lock up solid. dmesg indicates a number of uas restarts, the last of which doesn't complete. I had the same thing on another SBC (one of the orange PIs I think, although I can't remember which model) and I also found references to the same problem on x86 boxes, so I think the problem is fairly generic.

 

Apparently it can be worked around by adding a conf file to to /etc/modprobe.d, but I haven't got that to work yet (time has been in short supply). Hanging the drives off SBCs running an older kernel or connecting to the USB2 port on the xu4 gets things running smoothly (if slowly).

 

Posted
21 minutes ago, James Kingdon said:

Apparently it can be worked around by adding a conf file to to /etc/modprobe.d, but I haven't got that to work yet

 

The proper way to deal with those crappy external Seagate drives is to either create an usbstoragequirks entry in /boot/armbianEnv.txt or let Armbian do this for you (with next gen Armbian images -- new boot script required -- we try to auto-detect these drives and UAS blacklist them automagically but this requires the drive to be connected at boot and at least another reboot in between)

Posted
Just now, James Kingdon said:

Do you happen to know if the same problem affects the Odroid HC1 when connecting via it's sata port (I assume that uses a USB3 converter on the pcb)?

 

No problems with HC1 since the JMS578 there doesn't show the Seagate behaviour (problem with Seagate disk enclosures is that while they use an ASM1153 bridge chip that is known to work well with UAS their modified firmware screws things up and UAS to work properly would either need some quirks or has to be completely disabled. Unfortunately every new Seagate disk enclosure seems to use same ASM1153 with same branded/broken firmware but uses a new product ID so upstream blacklisting these devices most probably will never work. Check which are the most 'popular' devices in drivers/usb/storage/unusual_uas.h ;) )

 

JMS578 on the HC1 has a different problem but JMicron is currently working on a fix... I'm in contact with them and they said once they tested a new fully SAT compliant firmware internally they'll send it to me to test...

Posted

Ok, so that's bad news and good news. Bad news about the aggressive spin down, and good news that JMicron is at least listening to you and working on it. It's a shame I didn't read your message before ordering two HC1s today, but then it sounds like my other choice (rock64 plus it's sata adapter) has the same problem.

 

Let's hope that JMicron come through with that fix!

Posted
6 hours ago, James Kingdon said:

Bad news about the aggressive spin down, and good news that JMicron is at least listening to you and working on it

 

Well, problem has been reported by Hardkernel to them but most probably with wrong description ('We need more than 3 minutes' instead of 'make the bridge behaving SAT compliant everywhere'), TL Lim forwarded JMicron a link I provided and established then a direct contact in parallel. When they got back it seemed they already considered this a bug and not a feature (which could be a valid alternative given drive enclosure manufacturers might prefer sending disks to sleep as soon as possible)

 

You can follow progress here BTW: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?page=4

 

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines