Doesn't detect my USB external HDD

[alexandre1985]

I notice that after pluging in my external drive, my HDD didn't start spining. It was a power issue.
So to solve this I did went to: https://forum.pine64.org/showthread.php?tid=5001 and that solved my power issue.
Now my hard drive has power but it doesn't seem to be detected my archlinux. My lsusb and lsblk doesn't seem to have my external USB HDD listed.
What should I do?

UPDATE:
my usb2.0 ports are working. the problem is with my usb3.0 port, it doesn't detect anything

[ShapeShifter499]

Any updates with this? Does this occur if we use ayufan’s kernel?

I'm currently on the Arch Linux ARM kernel build and I have this issue.

[primeroz]

Same issue for me

[hradec]

same here!!

[ShapeShifter499]

@m01 Is there really no workaround for this issue yet?

[s-kostyuk]

I think the valid place for this issue is a repository of upstream kernel - either Rockchip or mainline, depending on which this distribution is based

Also you can visit ayufan repos for details and similar issues: https://github.com/ayufan-rock64/linux-build

[ShapeShifter499]

ayufan mentioned here that a DTS change is needed for the Rock64 to enable USB 3 rockchip-linux/kernel#83

A Arch Linux ARM dev by the name of kmihelich is attempting to get the required DTS changes for the Rock64 into the mainline Linux kernel. They are also adding in a patch in the meantime to the 'linux-aarch64-rc' for Arch Linux ARM. https://archlinuxarm.org/forum/viewtopic.php?p=58866#p58866

[m01]

I always meant to "fix" this by compiling and packaging Ayufan's kernel for Rock64 as an Arch Linux pkg file. However, I've not managed to get around to doing that, sorry.

[s-kostyuk]

What was the issue? Complining itself or packaging / writing PKGBUILD? пт, 27 июл. 2018 г., 21:05 Michiel <[email protected]>:

…

I always meant to "fix" this by compiling and packaging Ayufan's kernel for Rock64 as an Arch Linux pkg file. However, I've not managed to get around to doing that, sorry. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE4qEijfIcriSjZBvHnyqvd_toQvXa9Bks5uK1ZagaJpZM4R9QNK> .

[m01]

Neither - I believe the Arch Linux ARM PKGBUILDs are available from https://github.com/archlinuxarm/PKGBUILDs/tree/master/core/linux-aarch64, so one of those would need to be adapted to compile Ayufan's source. I'm not sure if there's some config stuff that may need to be incorporated from Ayufan's build files. This can then be (cross-)compiled and packaged.
Then there's the issue of how to distribute the files; for simplicity, I would've extended the make/guestfish scripts to include the <kernel>.pkg.xz package in some obvious location (/root or ~) and let the user switch to ayufan's kernel on the rock64 if desired post install. It's technically possible to pre-install the kernel, but not fully straightforward (guestfish normal method doesn't work because of the architecture mismatch between the host and guest kernel, and I briefly explored using a custom (aarch64) kernel together with the binfmt_misc/qemu stuff with guestfish, but I hit some error there as well (I don't remember exactly, it's probably resolvable); or you could go back down other methods that then require root for the build process).
Longer term, the kernels would also need to be hosted in an Arch Linux repo on the web to support auto-updates, or at least in AUR or so to allow updates.

One thing I did try in the early days was to just replace the Arch Linux kernel with Ayufan's already compiled kernel from the debian package, but for some reason that didn't "just work". It's quite possible that I didn't do something right there, or maybe whatever issue I ran into has been fixed now, I'm not sure.

An upstream fix would of course be preferable over all this; one of the reasons I went with the Rock64 was because of the good upstream support.

[ShapeShifter499]

Just got around to updating and installing things. Seems USB 3.0 works great on linux-aarch64-rc package from Arch Linux ARM

Linux 4.18.0-rc6-1-ARCH #1 SMP Sun Jul 22 18:48:40 MDT 2018 aarch64 GNU/Linux

[ShapeShifter499]

@m01 I just got this which crashed all of my hard drives making me have to reboot. Is this a issue with the driver of the USB 3.0 of the Rock64?

[Jul29 18:07] usb 5-1.3: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[Jul29 18:17] usb 5-1.2: reset SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[Jul29 18:32] usb 5-1.2: reset SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[  +0.030627] sd 0:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[  +0.000737] sd 0:0:0:0: [sdb] tag#0 CDB: Read(16) 88 00 00 00 00 00 c8 80 5e 10 00 00 00 f8 00 00
[  +0.000775] print_req_error: I/O error, dev sdb, sector 3363855888
[Jul29 18:37] usb 5-1.2: reset SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[  +0.030621] sd 0:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[  +0.000737] sd 0:0:0:0: [sdb] tag#0 CDB: Read(16) 88 00 00 00 00 00 fd 80 1e 18 00 00 00 e8 00 00
[  +0.000775] print_req_error: I/O error, dev sdb, sector 4253031960
[Jul29 18:45] usb 5-1.2: reset SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[Jul29 18:51] usb 5-1.3: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd
[Jul29 19:50] usb 5-1.2: reset SuperSpeed Gen 1 USB device number 3 using xhci-hcd
[Jul29 19:51] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
[  +0.000722] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead
[  +0.000768] hub 5-1:1.0: hub_ext_port_status failed (err = -22)
[  +0.000033] usb 5-1.4: cmd cmplt err -108
[  +0.000491] usb 5-1-port2: cannot reset (err = -22)
[  +0.000348] usb 5-1.4: cmd cmplt err -108
[  +0.000423] usb 5-1-port2: cannot reset (err = -22)
[  +0.000353] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
[  +0.000420] usb 5-1-port2: cannot reset (err = -22)
[  +0.000518] usb 4-1: USB disconnect, device number 2
[  +0.000410] usb 5-1.2: USB disconnect, device number 3
[  +0.001351] usb 5-1: USB disconnect, device number 2
[  +0.001152] sd 0:0:0:0: [sdb] Synchronizing SCSI cache
[  +0.003028] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command.
[  +0.020067] sd 0:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[  +0.000774] sd 0:0:0:0: [sdb] tag#0 CDB: Read(16) 88 00 00 00 00 01 72 5f 58 00 00 00 01 00 00 00
[  +0.000775] print_req_error: I/O error, dev sdb, sector 6213818368
[  +0.000652] sd 0:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[  +0.000775] sd 0:0:0:0: [sdb] tag#0 CDB: Write(16) 8a 00 00 00 00 01 71 e1 19 00 00 00 01 00 00 00
[  +0.000786] print_req_error: I/O error, dev sdb, sector 6205544704
[  +0.000568] EXT4-fs warning (device dm-1): ext4_end_bio:323: I/O error 10 writing to inode 21307152 (offset 536477696 size 131072 starting block 775692320)
[  +0.000491] EXT4-fs warning (device dm-1): ext4_end_bio:323: I/O error 10 writing to inode 21307152 (offset 144703488 size 131072 starting block 775593248)
[  +0.000728] Buffer I/O error on device dm-1, logical block 775692320
[  +0.000017] Buffer I/O error on device dm-1, logical block 775692321
[  +0.001208] Buffer I/O error on device dm-1, logical block 775593248
[  +0.000550] Buffer I/O error on device dm-1, logical block 775692322
[  +0.000556] Buffer I/O error on device dm-1, logical block 775593249
[  +0.000547] Buffer I/O error on device dm-1, logical block 775692323
[  +0.000551] Buffer I/O error on device dm-1, logical block 775593250
[  +0.000551] Buffer I/O error on device dm-1, logical block 775692324
[  +0.000594] Buffer I/O error on device dm-1, logical block 775593251
[  +0.000551] Buffer I/O error on device dm-1, logical block 775692325

Edit: I also reported it here https://archlinuxarm.org/forum/viewtopic.php?p=58934#p58934

[ShapeShifter499]

I switched back to using the USB 2.0 ports and I noticed some errors about my luks encrypted USB hard drives being misaligned has gone away. There seems to be some issues with the USB 3.0 driver in use here.

[ShapeShifter499]

I reported this to ayufan as mentioned above. Seems like a bunch of people are seeing similar issues.

[ShapeShifter499]

Ok so I now have USB 3.0 working for the most part. I switched to a different USB hub with more power. The ""Anker 10 Port 60W Data Hub with 7 USB 3.0 Ports and 3 PowerIQ Charging Ports" which I brought from Amazon.

@m01 I have created a AUR package that fetches the latest Debian built kernel from Ayufan. For the meantime anyone following should probably use that for the best compatibility with USB 3.0. Ayufan makes some Rock64 specific edits to the https://github.com/rockchip-linux/kernel source. rockchip-linux contains some specific fixes for USB 3.0 that are not in mainline yet.

https://aur.archlinux.org/pkgbase/linux-aarch64-rock64-bin/

[m01]

A USB3 HDD seems to work for me now, plugged into the USB3 port. I'm not using a USB hub, and just tested mounting my disk, writing a file, and reading it.
For reference, here's my setup:

% uname -a
Linux rocknet 5.0.0-2-ARCH #1 SMP Fri Mar 8 17:18:41 MST 2019 aarch64 GNU/Linux
 % lsusb
Bus 005 Device 002: ID 0bc2:ab24 Seagate RSS LLC Backup Plus Portable Drive
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
% pacman -Qi linux-aarch64
Name            : linux-aarch64
Version         : 5.0.0-2
Description     : The Linux Kernel and modul
...
% sudo mount /dev/sda1 /mnt
% echo 'hello world' > /mnt/hi.txt
% cat /mnt/hi.txt
hello world
% rm /mnt/hi.txt
% sudo umount /dev/sda1

EDIT: I also briefly tested a USB to serial adapter, which also worked.

I think the AUR package for Ayufan's kernel is an excellent idea @ShapeShifter499, thanks!

My thanks go out to everyone who contributed to upstreaming the good stuff to make this work 🙂 .

I'll close this ticket.

[ShapeShifter499]

@m01 I've stopped updating the AUR package. I no longer use the Rock64, it just sits collecting dust. I found it too unstable for what I wanted. There is still a thread of people having major issues with the device. ayufan-rock64/linux-build#112

I have been running a different small board computer (SBC) known as the Up-Board. I got one in a 4GB RAM and 64GB Storage configuration with a Intel Atom x5 Z8350. I've been running a few NAS operations on it including a Nexcloud install with a LAMP setup. Arch Linux, Apache, MariaDB, and PHP.

I have not tested the stability of the Rock64 for a around half a year now or so.

If anyone wants to take over the AUR package let me know.

[ShapeShifter499]

@m01 So Linux Kernel version 5.0+ is working better for you?

[m01]

@ShapeShifter499 that's fair enough, thanks for letting me know.

To be honest, I don't really use the Rock64's USB port much. I primarily use it as a headless server, running everything off the eMMC, which seems to work quite well. It's no longer easy for me to test things on the Rock64, as it's a bit more difficult for me to access, and I'd like to keep the services up 🙂. I finally got around to cleaning up a bit, and the original issue described in this thread definitely seemed to be resolved; in the early days not even lsusb worked properly, hence why I thought to close it. In any case, this looks to me like an upstream issue, rather than something specific to the Arch Linux build.

It's a shame to hear that there still seem to be issues with using the Rock64 as a NAS.

If there's something relatively easy you'd like me to test, that can be done with one already formatted USB 3 HDD, then let me know and I'll help if I can.

[m01]

I should add some notes to the README to point at your AUR package (even if it ends up orphaned or taken over by someone else, with a bit of luck anyone in need would be able to update it to suit their needs) and perhaps add a note about potential USB issues, too.

[ShapeShifter499]

@m01 so everything is working for you, but you're not making use of the USB ports? Do you make use of the micro SD card slot at all?

I might find something the Rock64 board I own can be used for that avoids the use of USB now that I do have a seemingly stable NAS solution running.

[m01]

Yep, pretty much. I was using the micro-SD card for some experimentation with OS images, thinking I could switch the OS easily from the serial uboot prompt. I had some issues with it then mounting the wrong partitions during, boot, which I've now realised was probably due to the way the root partition was specified (using LABEL=, which of course would run into difficulties given I left the eMMC attached, which also contained the OS).