MAIWO K308H (VIA VL813 + INITIO INIC-3619)

Maiwo K308H - док-станция и хаб на базе VIA VL813 и Initio INIC-3619. Обзор и эпическая история подключения к компьютеру под управлением Linux Debian 9.

Предисловие

Есть у меня хоум-сервер, который собран в mini ITX корпусе Chieftec IX-01B-OP на базе SoC материнской платы Asus N3050T, а в качестве основного накопителя используется HDD 3.5" Seagate ST2000DM001-1ER1. Хард этот довольно таки горячий и внутри корпуса мог запросто нагреваться до 50°C и выше, поэтому приходилось держать корпус открытым, и не прижимать его к стенке, чтобы обеспечивать хоть какую-то циркуляцию воздуха и охлаждение. Городить вентилляторное охлаждение мне не хотелось, и вот однажды мне пришла в голову идея использовать док-станцию или карман. Плюс к тому, я хотел еще кой-чего изменить в организации севера, и это лишало меня технической возможности использовать SATA-порт. Так что, посмотрев на доступные модели и цены, я решил, что для моих целей идеально подходит устройство под названием Maiwo K308H, которое представляет собой док-станцию для 2.5"/3.5" HDD и хаб на три разъема USB 3.1 Gen 1, 5Gbps, отдельное питание от БП 12V/3A. Цена в Украине - ~$25 (для сравнения: цена на GearBest около $50 с доставкой курьером на дом, а на AliExpress - $37+, но обычной почтой).

Ничего аналогичного по схожей цене в продаже я не нашел, так что можно сказать, что у устрйства просто нет конкурентов, поэтому особо маяться с выбором не пришлось - заказал и купил. Но так как для окончательной модернизации сервера мне нужны были еще кой-какие железяки, то в ожидании посылки с GearBest я решил ограничиться простой проверкой работоспособности.

Первое впечатление

Устройство собрано хорошо, без люфтов и зазоров, качественный пластик. Разъемы выглядят прилично, не болтаются но и не слишком тугие. Кабель USB 3.1 около 80 см, кабель БП около метра. На коробке заявлена совместимость со всеми версиями Windows старше 98SE/Linux/Mac OS.

При подключении док-станции с диском ST2000DM001-1ER1 к рабочему ноуту с Linux Debian система отказалась монтировать диск, ссылаясь на плохую геометрию, хотя на сервере диск проработал без проблем уже около 19000 часов. Ошибка выглядела так:

EXT4-fs (sdc): bad geometry: block count 488378646 exceeds size of device (488378645 blocks)

Проблема решилась просто:

# e2fsck -f /dev/XXX
# resize2fs /dev/XXX

После этого диск нормально смонтировался. Проверил чтение-запись копированием 40Gb - все OK, все порты хаба тоже работают. Вобщем, осталось дождаться остальных железяк.

Первый запуск

И так, посылка с необходимыми запчастями пришла, подключаю все необходимое, подключаю сабж:

usb 2-1: new SuperSpeed USB device number 4 using xhci_hcd
usb 2-1: New USB device found, idVendor=2109, idProduct=0813
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1: Product: USB3.0 Hub
usb 2-1: Manufacturer: VIA Labs, Inc.
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
usb 1-1: new high-speed USB device number 7 using xhci_hcd
usb 1-1: New USB device found, idVendor=2109, idProduct=2813
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1: Product: USB2.0 Hub
usb 1-1: Manufacturer: VIA Labs, Inc.
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected

Подключаю HDD:

usb 2-1.4: new SuperSpeed USB device number 5 using xhci_hcd
usb 2-1.4: New USB device found, idVendor=13fd, idProduct=3940
usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.4: Product: USB3.0 Storage Device
usb 2-1.4: Manufacturer: ST2000DM001-1ER1
usb 2-1.4: SerialNumber: 5A353630324141362020202020202020
usb 2-1.4: UAS is blacklisted for this device, using usb-storage instead
usb-storage 2-1.4:1.0: USB Mass Storage device detected
usb-storage 2-1.4:1.0: Quirks match for vid 13fd pid 3940: 2820020
scsi host1: usb-storage 2-1.4:1.0
scsi 1:0:0:0: Direct-Access ST2000DM 0302 PQ: 0 ANSI: 6
sd 1:0:0:0: [sdb] 3907029167 512-byte logical blocks: (2.00 TB/1.82 TiB)
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 1f 00 10 08
sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 1:0:0:0: [sdb] Attached SCSI disk
EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: (null)

Пытаюсь проверить чтение/запись, копированием директории в 40Gb, но тут начинаются какие-то траблы, копирование прерывается, а в лог валятся сообщения вида:

sd 1:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
sd 1:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 8b 3d c5 48 00 01 00 00
sd 1:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
sd 1:0:0:0: [sda] tag#1 CDB: Read(10) 28 00 8b 3d c4 48 00 01 00 00
scsi host1: uas_eh_bus_reset_handler start
usb 2-3.4: reset SuperSpeed USB device number 3 using xhci_hcd
scsi host1: uas_eh_bus_reset_handler success
sd 1:0:0:0: [sda] tag#0 data cmplt err -71 uas-tag 1 inflight: CMD
sd 1:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 c5 2a 6c f8 00 02 c0 00
sd 1:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
sd 1:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 c5 2a 6c f8 00 02 c0 00
scsi host1: uas_eh_bus_reset_handler start
usb 2-3.4: reset SuperSpeed USB device number 3 using xhci_hcd
scsi host1: uas_eh_bus_reset_handler success
sd 1:0:0:0: [sda] tag#0 data cmplt err -71 uas-tag 1 inflight: CMD
sd 1:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 c5 2a 6c f8 00 02 c0 00
usb 2-3: USB disconnect, device number 2
usb 2-3.4: USB disconnect, device number 3
sd 1:0:0:0: [sda] tag#0 uas_zap_pending 0 uas-tag 1 inflight: CMD
sd 1:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 c5 2a 6c f8 00 02 c0 00
sd 1:0:0:0: [sda] tag#0 FAILED Result^ hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
sd 1:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 c5 2a 6c f8 00 02 c0 00
blk_update_request: I/O error, dev sda, sector 3307891960

Дальнейшая трехнедельная трагикомедия проходила под лозунгом "Не мала баба клопоту - купила порося".

Суть проблемы

Для понимания проблемы нужно было понять, что именно представляет собой устройство изнутри. И так, после разборки выяснил, что девайс построен на базе контроллера VIA VL813-Q7, который обеспечивает работу четырех портов USB 3.1 Gen 1, 5Gbps. На одном из портов висит USB-SATA мост на базе контроллера Initio INIC-3619. Все логично.


С обратной стороны платы были неприлично большие следы флюса, но только в местах пайки разъемов, а остальная пайка была чистая и аккуратная. Похоже, что разъемы паяются отдельно.

После нескольких беcсистемных попыток привести девайс в чувство я решил составить более менее четкий план действий и следовать ему. Сформулировал возможные причины неадекватного поведения устройства:

  • Проблемы с кабелем или БП.
  • Физическая неисправность устройства, брак.
  • Какая-то аппаратно-программная несовместимость хаба и сервера.
  • Что-то еще.
  • Комбинации вышеперечисленных предположений.

Оборудование компьютеров:

Ноутбук:

$ uname -r

Linux hp-8470p 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux

$ lspci | grep USB

00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04)

$ lsusb

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
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 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Сервер, на котором девайс отказывался работать:

$ lsusb

Bus 002 Device 004: ID 13fd:3940 Initio Corporation
Bus 002 Device 003: ID 04c5:2028 Fujitsu, Ltd
Bus 002 Device 002: ID 2109:0813 VIA Labs, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 005: ID 046d:c30e Logitech, Inc. UltraX Keyboard (Y-BL49)
Bus 001 Device 003: ID 2109:2813 VIA Labs, Inc.
Bus 001 Device 002: ID 058f:6387 Alcor Micro Corp. Flash Drive
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ lspci | grep USB

00:14.0 USB controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller (rev 21)

Вот так определяется само устройство Maiwo K308H $ lsusb:

Bus 002 Device 005: ID 13fd:3940 Initio Corporation # появляется только при подключенном HDD
Bus 002 Device 004: ID 2109:0813 VIA Labs, Inc.
Bus 001 Device 002: ID 2109:2813 VIA Labs, Inc.

Брак устройства, кабеля или БП

Устройство было проверено на рабочем ноутбуке с аналогичной ОС. Так же загрузился в Windows 8 PE на обоих компьютерах - никаких проблем, устройство работало как следует. Таким образом вариант неисправности устройства кабеля или БП отпадали. Несмотря на это я все же проверил БП, так как у меня был 100% рабочий аналог, но его замена ни на что не повлияла. Кабеля USB3.1 AM-BM в хозяйстве не нашлось, но так как на другом компьютере все работало, как и на самом сервере, но с загрузкой в Windows 8 PE, то и этот вариант я отбросил как крайне маловероятный.

Во время тестирования произошел интересный случай. Поступила жалоба от супруги, что ее телефон и ноутбук перестали ловить беспроводную сеть. Пришлось параллельно заняться этим вопросом. Я заметил, что у меня на телефоне тоже пропадает связь в тот же самый момент, что и у супруги. После недолгих размышлений и тестов была выявлена интересная остобенность устройства - его кабель создавал помехи, которые глушили WiFi на роутере, который находится рядом с сервером. При чем сама сеть доступна, но возникают проблемы с авторизацией. Как оказалось, ничего особенного в этом нет, USB 3.0 может создавать помехи на частоте 2.4ГГц, на которой работают большинство роутеров. Почитать можно здесь и здесь. Так как кабеля не слишком длинные, а перестановки делать не было желания, то я просто обернул корпус хаба фольгой - помогло. Позже вместо этого попробовал обернуть фольгой разъемы USB кабеля - тоже помогало.

Контроллер Initio INIC-3619 и UAS

На сайте производителя никаких подробных данных об этом контроллере нет, только информация, что это USB 3.0 to SATAII Bridge Controller IC, 8051 CPU. Ни даташита, ни прошивок.

Основываясь на сообщениях в логах и поиску на форумах стало ясно, что существует довольно много устройств класса USB-SATA bridge, которые имеют проблемы в реализации протокола UAS. Для решения проблем такого рода в драйвере usb-storage существует опция quirks, параметры которой задают некоторые ограничения протокола, на тот случай, если он криво реализован производителем устройства. Некоторые из таких устройств и необходимые для их работы параметры уже известны и включены в файл drivers/usb/storage/unusual_devs.h. Список возможных флагов-параметров можно найти поиском по case в файле drivers/usb/storage/usb.c. Онлайн с учетом версии ядра можно посмотреть здесь или здесь. Есть два варианта применения настроек:

  • Вариант 1 - cоздать файл с необходимыми настройками для modprobe:
    $ echo options usb-storage quirks=13fd:3940:u | sudo tee /etc/modprobe.d/usb_storage.conf
    $ sudo update-initramfs -u
    $ sudo reboot
  • Вариант 2 - через параметры командной строки ядра:
    В файле /etc/defaul/grub в GRUB_CMDLINE_LINUX_DEFAULT добавить параметр usbstorage.quirks=13fd:3940:u, затем:
    # update-grub
    # reboot

    В обоих случаях VID:PID устройств можно перечислять через запятую, а флаги комбинировать, например options usb-storage quirks=13fd:3940:brtu,2109:0813:r
    Подробнее об этом можно почитать здесь.

В списке устройств в файле drivers/usb/storage/unusual_devs.h присутствовал и мой INIC-3619, но с другим VID:PID, как у INIC-3609. Так же в Интернете попадались патчи ядра, для устройств использующих этот мост.

Ошибки, которые были в логах, а так же патчи драйвера, предлагаемые для этого устройства, якобы свидетельствовали о проблемах в работе модуля UAS, но, к сожалению, ни одно из предложенных решений и их комбинации мою проблему не решили. Единственное, что я обнаружил, что реализация инетерфейса UAS в INIC-3619 не поддеривает передачу данных S.M.A.R.T., поэтому для нормальной его работы все же стоит запретить модулю uas управлять устройством, передав это право модулю usb-storage. Для этих целей используется флаг u. Но все же непричастность контроллера INIC-3619 к основной проблеме была уже очевидна. Вместе с тем о его непричастности говорило и то, что когда я оставил устройство подключенным на долгое время без диска, оно продолжило перегружаться. Происходило это редко - от одного до 10 раз за ночь. С диском же, в основном, каждые 3-15 минут. А еще оно перегружалось даже тогда, когда я подключал другие диски через раъемы хаба. То есть устройство сбоило под нагрузкой чаще, но и без нее тоже сбоило, просто значительно реже.

VIA VL813

Контроллер не такой уж и новый - 2015 года, но информации по нему в сети не так уж и много. Хотя в общем пользователи Linux довольно негативно отзываются о совместимости чипсетов VIA, но мне удалось найти пару отзывов о вполне успешной работе устройств на VL813 на компьютерах под Debian, правда там ядро было поновее - 4.13. Еще в результате поисков я наткнулся на отзыв о хабе на этом же контроллере. Человек писал, что у него контроллер имел прошивку версии 9000 и хаб работал как USB 2.0. В обсуждении была поднята тема прошивки, но человеку его не удалось прошить. А меня это натолкнуло на мысль.
Мой экземпляр имел прошивку 9011. На station-drivers.com я нашел все доступные прошивки - 9001, 9004, 9011, 9015 и какую-то брендированную - 0380. Все это в каком-то виде есть и на usbdev.ru. Все программы для прошивки, естественно, под Windows, поэтому все операции по прошивке пришлось осществлять в PE среде Windows 8.
С наскока залить прошивку версии 9015 не удалось. Процесс прошивки прерывался. Зато без проблем прошилась 0380 превратившая мое устройство в тыкву Lenovo. Но на работоспособности устройства это никак не сказалось - сменилось только название и PID:VID. Пришлось погружаться еще глубже и изучать даташит на установленную SPI Flash memory FM25F01.

Посмотрел регистры и по аналогии с имеющимися добавил запись в ini прошивальщика. Прошил версию 9015 и поведение устройства стало просто кошмарным. Хаб стал отваливаться каждую минуту, а мост Initio Inic-3619 стал появляться в списке usb-устройств заявлял, что он Storage Device, будто к нему был подключен диск. Даже в Device Manufacturer какой-то мусор умудрялся писать. Последовательно меняя прошивки и раз за разом пробуя на них все предыдущие костыли была найдена самая стабильная - 9001. На ней мне удалось многократно копировать большие объемы по 30-40Gb без сбоев. Но стало появляться сообщение вида

reset superspeed usb device number 2 using xhci_hcd

Погоняв устройство несколько дней стало понятно, что стабильность была только иллюзией. Устройство без всяких видимых причин могло работать табильно много часов, а после перезагрузки компьютера снова начинало сбоить. Причем без каких либо воздействий на него. Прошивки ничего в этом плане тоже не решали...

Возможно кому-то пригодится архив со всем необходимым: драйвера, прошивки, утилита.

Что-то еще

Дальнейшие действия были попытками последовательного перебора всех приходящих на ум всех возможных вариантов, которые соответствовали сообщениям из логов, в момент отключения устройства. А там, в зависимости от версии прошивки, наряду с сообщениями об ошибках UAS было много сообщений и об ошибках возникающих при попытке перевода устройства в различные режимы пониженного потребления энергии (Power Management for USB). Вот некоторые из записей dmesg:

sd 1:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
sd 1:0:0:0: [sda] tag#0 CDB: Read(10) 28 00 8b 3d c5 48 00 01 00 00
sd 1:0:0:0: [sda] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN
sd 1:0:0:0: [sda] tag#1 CDB: Read(10) 28 00 8b 3d c4 48 00 01 00 00
scsi host1: uas_eh_bus_reset_handler start
usb 2-3.4: reset SuperSpeed USB device number 3 using xhci_hcd
scsi host1: uas_eh_bus_reset_handler success
sd 1:0:0:0: [sda] tag#0 data cmplt err -71 uas-tag 1 inflight: CMD
sd 1:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 c5 2a 6c f8 00 02 c0 00
sd 1:0:0:0: [sda] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD
sd 1:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 c5 2a 6c f8 00 02 c0 00
scsi host1: uas_eh_bus_reset_handler start
usb 2-3.4: reset SuperSpeed USB device number 3 using xhci_hcd
scsi host1: uas_eh_bus_reset_handler success
sd 1:0:0:0: [sda] tag#0 data cmplt err -71 uas-tag 1 inflight: CMD
sd 1:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 c5 2a 6c f8 00 02 c0 00
usb 2-3: USB disconnect, device number 2
usb 2-3.4: USB disconnect, device number 3

-

usb 2-3.4: reset SuperSpeed USB device number 3 using xhci_hcd

-

Failed to set U1 timeout to 0x0, error code -71
Failed to set U2 timeout to 0x28, error code -19

-

Failed to set U1 timeout to 0x0, error code -71
Set SEL for devices-initiated U1 failed
Set SEL for devices-initiated U2 failed
usb_reset_and_verify_device Failed to disable LPM

Поэтому я решил, что в устройстве, возможно, криво реализован режим управления энергопотреблением LPM и попробовал его отключить. Для этого пришлось обновить ядро Linux до версии 4.18 (backports). В этой версии ядра реализован механизм установки параметров quirks для модуля usbcore. Модуль скомпилирован в ядро, и управлять его параметрами можно через командную строку в /etc/default/grub. Таким образом у меня повилась возможность полностью отключить LPM.

Все возможные варианты параметров командной строки ядра доступны онлайн.

К сожалению танцы с бубном вокруг Power Management тоже не помогли. Не помогли так же никакие рекомендайии по настройке BIOS, ядра, Power Management, USB autosuspend, настроек HDD и всего прочего. Причем периодически устройство действительно начинало работать вполне стабильно, давая ложные надежды на успех, позволяло копировать большие объемы данных, но вдруг ни с того ни с сего, вновь начинало дисконнектиться.

Невероятно, но факт

Тестирование подошло к терминальной стадии. Напрашивался неутешительный вывод. Даже страшно подумать, но в общем на изучение и проверку всех деталей я затратил примерно 100 часов. Время ушло на чтение доков, даташитов и форумов, чтение исходников, изучение сопутствующих материалов по Linux, перепрошивки контроллера, и тестирование результатов. Да, это крайне много, если посмотреть на цену устройства, но для меня это стало в некоторой степени принципиальным вопросом. Я чувствовал, что здесь кроется что-то совсем простое. Запас моих идей и догадок был израсходован, но для того, чтобы запаковать железяку и закинуть её до лучших времен оставался еще один тест. Нужно было достоверно установить неработоспособность девайса с другим кабелем USB.

Тут стоит пояснить, что весь этот увлекательный квест стартовал примерно за две недели до Нового года, и пока я развлекался, наступило время, когда заниматься покупкой кабеля стало просто некогда - одно дело сидеть и кнопать вечерами и ночами, а другое - искать по магазинам не очень ходовой кабель. Заказывать его в интернет-магазинах было уже бессмысленно, все равно раньше чем через 5-7 дней он бы не пришел. Пару раз во время обсуждения вопроса с женой я высказывал предположение, что проблема может быть в кабеле, но меня смущало то, что устройство абсолютно работоспособно с этим же кабелем на другом компьютере. Вобщем, через пару дней после НГ, я позвонил товарищу, и у него в магазине оказался в наличии совершенно новый кабель нужного мне образца, валяющийся на витрине уже лет 5, как оказалось, в нашей местности хабы и док-станции с интерфейсом USB 3.1 совершенно не востребованы.

И так, наступил момент истины. После подключения устройства через новый кабель все заработало!
Вот так просто, проблема оказалась в бл*дском кабеле за $3. В свое оправдание могу только повторить, что устройство прекрасно работало со штатным кабелем на другом компьютере, да и на целевом компьютере тоже, только под управлением другой ОС. Это отодвинуло предположения о неисправности кабеля в самый низ списка. Еще, конечно, злую шутку сыграло и то, что сообщения, которые валились в лог во время сбоев очень часто попадались на форумах, и успешное решение связанных с ними проблем в большинстве случаев заключалось в соответствующих настройках драверов usbcore и usb-storage. Вот такая вот ложная схожесть симптомов, которая завела меня в дебри углубленного изучения Linux, чтения исходников и даташитов...

Итоги

Ситуация с кабелем конечно попортила мне немного крови и отобрала кучу времени, но если посмотреть на это с философской точки зрения, то именно благодаря этим обстоятельствам я узнал достаточно много нового об устройстве Linux, и получил кое-какой опыт, который в менее обязывающих обстоятельствах вряд ли захотел бы приобретать. Ну и потешил свое ЧСВ осознанием собственного упорства, хоть и слегка туповатого, - не нужно было жлобиться и лениться, а сходу пойти и поискать кабель!

На данный момент устройство бесперебойно отработало уже несколько суток. В док-станцию подключен HDD 3.5", а к хабу для проверки временно подключены: HDD 2.5" в кармане Zalman ZM-VE300, ИБП и клавиатура. Диск в основном находится в остановленном состоянии, просыпается при доступе через Samba-сервер или когда motion пишет с камеры, как собака в наше отсутствие лазит по кровати, и через минуту снова останавливает шпиндель. Никаких пугающих сообщений в логах не появлялось.

С большой долей вероятности можно констатировать, что проблема решена.
Проблемы с Wi-Fi тоже прекратились, наверняка, благодаря нормальному качеству экранирования кабеля.

Кроме отстойного качества кабеля и следов флюса на обратной стороне платы, нареканий к устройству нет - работает, обеспечивает приемлимые скорости чтения/записи и позволяет теперь подключать дополнительные устройства.
Тест скоростей:

При нагрузке температуры микросхем не превышают 55°C - греется только Initio Inic-3619, причем не зависимо от того, подключен ли к док-станции HDD или нет.

P.S.: У меня родилась интересная мысль, что возможно, так же, как кабель USB создавал высокочастотные помехи, мешающие работе беспроводной сети, так же, возможно, и антенна Wi-Fi роутера, которая находится практически в 10-15 сантиметрах от кабеля, могла создавать помехи в работе док-станции из-за того, что кабель был плохо экранирован. Позже обязательно проверю эту версию.

P.P.S.: А еще я буду очень рад, если этот мой неоднозначный опыт поможет кому-то сэкономить время...

Blog Comments powered by Disqus.