Suggestion for a reliable USB 3.1 Hub?

  • My 3.1 USB hub just keeps crashing with high activity. My current one is an "Inland 3.1 SuperSpeed" something or other that uses a Type-C to Type-A cable, it's obviously crappy. It's the 3rd one I've tried, the others were a "Orico" and "Xcellon". I've been through 3 in the last 2 weeks and all 3 are pretty much junk considering they all use external power ("wall warts"/transformers).


    Code
    Aug 17 20:13:54 omv kernel: [774172.008037] scsi host19: uas_eh_device_reset_handler success
    Aug 17 20:14:14 omv kernel: [774192.371038] sd 18:0:0:0: [sdf] tag#19 uas_eh_abort_handler 0 uas-tag 19 inflight: CMD OUT 
    ...
    Aug 17 20:14:14 omv kernel: [774192.374161] sd 18:0:0:0: [sdf] tag#7 uas_eh_abort_handler 0 uas-tag 5 inflight: 
    Aug 17 20:14:14 omv kernel: [774192.374171] sd 18:0:0:0: [sdf] tag#7 CDB: Write(16) 8a 00 00 00 00 00 83 22 10 28 00 00 01 60 00 00
    Aug 17 20:14:14 omv kernel: [774192.387035] scsi host18: uas_eh_device_reset_handler start
    Aug 17 20:14:14 omv kernel: [774192.520600] usb 6-1: reset SuperSpeed Gen 1 USB device number 3 using xhci_hcd
    Aug 17 20:14:14 omv kernel: [774192.549667] scsi host18: uas_eh_device_reset_handler success

    Any suggestions are welcomed.

  • Turns out this is the onboard controller.


    This did *_NOT_* happen with OMV 1.5 (kralizec)

    Your still using omv 1? Wow I've used omv from way back then but I'd maybe recommend updating to omv5 now

    OMV 5 - 64 bit
    Dell T430, 16gb Ram, 5 x 3TB HDD Raid5, 1 x 120GB 2.5" SSD (OS)

  • Good point, no this is on the latest OMV 5.x while copying any file larger than ~100MB. Since almost all files I'm transferring are at least that size, this happens non-stop and the syslog is 400+ pages after just a day.


    I'm not sure which driver was used/selected in OMV 1.5 on Debian 7, but it didn't have this problem.

  • Good point, no this is on the latest OMV 5.x while copying any file larger than ~100MB. Since almost all files I'm transferring are at least that size, this happens non-stop and the syslog is 400+ pages after just a day.


    I'm not sure which driver was used/selected in OMV 1.5 on Debian 7, but it didn't have this problem.

    Are you running the latest kernal I've had an issue with NFS with kernal 5.6.0.0 as have some others but apprently 5.7.0.0 fixes it the other option was downgrading can do this with the omvextras

    OMV 5 - 64 bit
    Dell T430, 16gb Ram, 5 x 3TB HDD Raid5, 1 x 120GB 2.5" SSD (OS)

  • I literally just upgraded because of your heads up :-).


    I'll try it after the current Rsync job is finished. Just 600GB, all large tiff files, 74 hours and counting, ~80% done... this is crazy... horrible. If I remember correctly, this didn't even take a day in the old OMV :-/. I wish I would of kept that old image just to see which driver/version it used.


    What I haven't done yet is to see if it keeps restarting regardless of transferring files, I'm kind of hoping it does.

  • The update didn't help, it's still broken. It wound up taking 88 hours to transfer 600GB with rsync to the USB drive in the OMV box. In contrast, I mounted the RAID1 in the OMV box and rsync'd to a USB drive on my PC and it took 23.5 hours to transfer 1.07TB, of which 600GB of that 1.07TB was identical.


    Again, this problem didn't exist with OMV 1.5.


    Here's what hwinfo lists on the OMV box:

    Strangely, the chipset is different but the driver is the same on PC, where USB is working fine:


    This very well could be a driver bug with that old ATI SBxxx chipset, but which driver was used for it in OMV 1.5?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!