Jim MacKenzie

  • Content Count

  • Joined

  • Last visited

About Jim MacKenzie

  • Rank

Recent Profile Visitors

127 profile views
  1. So then the question is: is the USB 3.0 hardware bad on this device, or is it a driver issue and it can be corrected? I've certainly found USB 3.0 to be a delicate thing compared to USB 2.0. I've had many, many difficulties with 3.0 (all surmounted over time, thankfully, save this one). The only issue I ever had with 2.0 and Linux was a using-the-port-at-1.1-speeds problem; everything still worked. If I can do anything to help give diagnostic information to developers, please let me know, but it sounds like this problem is easily reproducible.
  2. I may be having a similar problem. I am using a NanoPi Neo4 and my root filesystem is on eMMC, but I have a large RAID6 attached by USB, on which I back up my server (this box lives at a family member's home, offsite). The RAID used to live on a SheevaPlug, but I've replaced it with the NanoPi because of performance issues. (Got a good decade out of the Sheeva!) The RAID devices seem to disappear as soon as heavy I/O occurs. It first occurred when I started an rsync from my server. Rebooting the system became impossible without disconnecting the USB hub because the RAID rebuild would cause the same problem to recur immediately. This was all with a four-port hub connected to the USB 3.0 port. I initially thought it was a power issue, so replaced the four-port unpowered hub with a ten-port powered hub (I don't need ten ports, but I had this unit kicking around). This did nothing to cure the problem. What did solve the problem was moving the hub's connection from the USB 3.0 port to the USB 2.0 port. I'm not sure if it's significant, but I notice in /boot/armbianEnv.txt: usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x331a:u,0x0bc2:0x3322:u And my hard disks are in that quirks "blacklist": root@nobby:/boot# lsusb | grep Seagate Bus 005 Device 009: ID 0bc2:3322 Seagate RSS LLC Bus 005 Device 008: ID 0bc2:331a Seagate RSS LLC Bus 005 Device 007: ID 0bc2:3322 Seagate RSS LLC Bus 005 Device 006: ID 0bc2:3322 Seagate RSS LLC Jim
  3. Thanks. I'll check out that thread. Not sure if it's significant, but I notice in /boot/armbianEnv.txt: usbstoragequirks=[snip],0x0bc2:0x331a:u,0x0bc2:0x3322:u And: jim@nobby:~$ lsusb | grep Seagate Bus 005 Device 009: ID 0bc2:3322 Seagate RSS LLC Bus 005 Device 008: ID 0bc2:331a Seagate RSS LLC Bus 005 Device 007: ID 0bc2:3322 Seagate RSS LLC Bus 005 Device 006: ID 0bc2:3322 Seagate RSS LLC I'm not sure what "usbstoragequirks" does, but perhaps it relates to this issue.
  4. I've found a problem with Armbian on the NanoPi Neo 4 with USB 3.0. I have a RAID6 via four USB 3.0 external hard disks (I know, not optimum but it's been working fine for years off an older ARM box using USB 2.0). While the RAID works fine on the USB 2.0 port (established this was true afterward), when connected to the USB 3.0 port, the USB 3.0 hub I'm using disconnects after only a few seconds, disconnecting all the drives (of course). I initially used an unpowered USB 3.0 hub (I forget the manufacturer; I can check). I figured at first, this might be a power issue (even though the external drives are all self-powered). I found a 10-port powered Cable Matters USB 3.0 hub in my basement, and deployed it today, thinking that would solve my issues But it doesn't. Not a thing changes; the same problem recurs. I moved the hub's USB cable to the USB 2.0 port on the NanoPi and that cures the issue. So my RAID is slow, but it works. (And it's faster than it was on my old box, so it's good enough for now.) I'm not sure if this is a known issue, but thought I would report it.
  5. I got it working by moving the USB cable to another machine. Maybe it's some weird USB-port incompatibility with 1.5Mbps. (It used to be plugged into an old ARM box - the box that the new NanoPi is replacing - but is now plugged into a Core 2 Duo desktop, also running Linux.) I still don't get any kernel booting messages (any way to force this to happen?) but I see the u-boot messages, at least, and was able to diagnose my problem and get the NanoPi booted again.
  6. Confirmed, I get garbage at 1500000 bps as well. I also tried 230400, 115200, 57600, 38400, 19200, 9600, 4800, 2400, 1200 and 300, out of desperation. The UART/USB adapter says it's USB 2.0 but lsusb -v shows it's only connected at 1.1 speeds. I doubt this should matter - 1.1 can still handle 1.5Mbps - but thought I should mention it.
  7. I tried that, and I still got garbage. I'll give it another go, though.
  8. Hi, I have deployed a NanoPi Neo 4 and for the most part, I'm happy with it, but am having a peculiar problem. I am using the manufacturer-supplied serial console cable and USB adapter (via screen /dev/ttyUSBx 115200). Once the machine is properly booted, if I hit enter, I get a serial console as normal. However, I get garbage from u-boot (and presumably from the kernel boot messages). It looks just as if I have a speed mismatch. I have tried many other speeds (1500000, 230400, 57600, 38400, 19200, 9600) and none of these seem to work. What am I doing wrong? Or is the state of the box right now that u-boot sends garbage through the serial port? I'm having a bit a problem with the box (it may be power-related) and being able to see the console would be a huge help. Thanks! Jim