Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Jun 2020 21:32:54 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        freebsd-arm <freebsd-arm@freebsd.org>
Subject:   Re: Rock64: USB3 SSD and USB3 Ethernet on a common powered USB3 hub: cp over nfs to that SSD via that Ethernet failed
Message-ID:  <B3706E2D-B339-4E86-A0A3-3A5180377ABA@yahoo.com>
In-Reply-To: <3982293D-BFD4-442C-9F04-0FD9593DCEED@yahoo.com>
References:  <3982293D-BFD4-442C-9F04-0FD9593DCEED@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On 2020-Jun-21, at 16:13, Mark Millard <marklmi@yahoo.com> wrote:

> I was experimenting with the external USB3 Ethernet
> in order to avoid the leak on the Rock64 that is
> associated with:
>=20
> vm.uma.mbuf_cluster.limit.max_items
>=20
> when the internal Ethernet is used.
>=20
> I had the external USB3 hub plugged into the Rock64
> USB port and the USB3 SSD and USB3 Ethernet plugged
> into the USB3 hub. I used dhclient ue0 to have the
> external Ethernet bound via DHCP.
>=20
> The dmesg -a after things were messed up by
> the experiment showed:
>=20
> . . .
> ue0: link state changed to UP
> ue0: link state changed to DOWN
> ue0: link state changed to UP
> ue0: link state changed to DOWN
> ue0: link state changed to UP
> ue0: link state changed to DOWN
> xhci0: Resetting controller

That last just looks like something that should
not normally be done on the Rock64 once things
are set up sufficiently for any USB3 device:

# devinfo
nexus0
  ofwbus0
    rk_dwc30
      xhci0
        usbus0
          uhub0
            . . . (e.g., umass0 and axge0) . . .
    cpulist0
. . .

It looks like the reset is guaranteed to disconnect
all USB3 devices, including the root file system
device if it was mounted via USB3. (And that is what
happened.)

At this point the system had booted and already had
served / as an nfs file system (via the axge0) to
the machine that had just initiated a cp to the
served / .

> uhub0: at usbus0, port 1, addr 1 (disconnected)
> ugen0.2: <GenesysLogic USB2.0 Hub> at usbus0 (disconnected)
> uhub4: at uhub0, port 1, addr 1 (disconnected)
> uhub4: detached
> ugen0.3: <GenesysLogic USB3.0 Hub> at usbus0 (disconnected)
> uhub5: at uhub0, port 2, addr 2 (disconnected)
> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 0c 28 cf 00 00 00 40 00=20=

> ugen0.4: <ASIX Elec. Corp. AX88179> at usbus0 (disconnected)
> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
> axge0: at uhub5, port 1, addr 3 (disconnected)
> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
> rgephy2: detached
> miibus1: detached
> axge0: detached
> ugen0.5: <OWC Envoy Pro mini> at usbus0 (disconnected)
> umass0: at uhub5, port 3, addr 4 (disconnected)
> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 0c 28 cf 00 00 00 40 00=20=

> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
> (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 0c 28 cf 00 00 00 40 00=20=

> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an =
error
> (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0: <OWC Envoy Pro mini 0>  s/n # detached
> g_vfs_done():gpt/Rock64root[WRITE(offset=3D166752878592, =
length=3D32768)]error =3D 6
> g_vfs_done():gpt/Rock64root[WRITE(offset=3D166752944128, =
length=3D32768)]error =3D 6
> g_vfs_done():gpt/Rock64root[WRITE(offset=3D166753173504, =
length=3D32768)]error =3D 6
> g_vfs_done():gpt/Rock64root[WRITE(offset=3D167409385472, =
length=3D32768)]error =3D 6
> g_vfs_done():gpt/Rock64root[WRITE(offset=3D104384823296, =
length=3D32768)]error =3D 6
> g_vfs_done():gpt/Rock64root[WRITE(offset=3D104447475712, =
length=3D32768)]error =3D 6
> (da0:umass-sim0:0:0:0): Periph destroyed
> umass0: detached
> Jun 21 15:30:45 Rock64orRPi4 dhclient[1138]: receive_packet failed on =
ue0: Device not configured
> Jun 21 15:30:45 Rock64orRPi4 dhclient[1138]: ioctl(SIOCGIFFLAGS) on =
ue0: Operation not permitted
> Jun 21 15:30:45 Rock64orRPi4 dhclient[1138]: Interface ue0 no longer =
appears valid.
> Jun 21 15:30:45 Rock64orRPi4 dhclient[1138]: No live interfaces to =
poll on - exiting.
> Jun 21 15:30:45 Rock64orRPi4 dhclient[1138]: exiting.
> Jun 21 15:30:45 Rock64orRPi4 dhclient[1138]: connection closed
> Jun 21 15:30:45 Rock64orRPi4 dhclient[1138]: exiting.
> uhub5: detached
> uhub0: detached

Looks like the below is the reattachment activity.

> uhub0 on usbus0
> uhub0: <Synopsys XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on =
usbus0
> uhub0: 2 ports with 2 removable, self powered
> ugen0.2: <GenesysLogic USB2.0 Hub> at usbus0
> uhub4 on uhub0
> uhub4: <GenesysLogic USB2.0 Hub, class 9/0, rev 2.00/90.20, addr 1> on =
usbus0
> uhub4: MTT enabled
> uhub4: 4 ports with 4 removable, self powered
> ugen0.3: <GenesysLogic USB3.0 Hub> at usbus0
> uhub5 on uhub0
> uhub5: <GenesysLogic> on usbus0
> uhub5: 4 ports with 4 removable, self powered
> ugen0.4: <ASIX Elec. Corp. AX88179> at usbus0
> axge0 on uhub5
> axge0: <NetworkInterface> on usbus0
> miibus1: <MII bus> on axge0
> rgephy2: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 3 on =
miibus1
> rgephy2:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, =
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, =
1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
> ue0: <USB Ethernet> on axge0
> ue0: Ethernet address: #
> ue0: link state changed to DOWN
> ugen0.5: <OWC Envoy Pro mini> at usbus0
> umass0 on uhub5
> umass0: <OWC Envoy Pro mini, class 0/0, rev 3.00/1.00, addr 4> on =
usbus0
> umass0:  SCSI over Bulk-Only; quirks =3D 0x0100
> umass0:0:0: Attached to scbus0
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number #
> da0: 400.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=3D0x2<NO_6_BYTE>

Reattachment did/does not provide sufficient context for
continued device use in the running Rock64 system . . .

> Even shutdown then reported "Device not configured".
> There did not appear to be much I can with with
> it other than cut the power and start over.
>=20
>=20
>=20
> On the other machine what I had tried was:
>=20
> # mount -onoatime,soft a.a.a.a:/ /mnt
> # cp -aRx /usr/obj/clang-armv7-installworld-poud.tar =
/mnt/usr/obj/clang-armv7-installworld-poud.tar.alt

It is not clear to me why the Rock64 did a
"xhci0: Resetting controller" in responce to
the above cp. Prior to that, things seemed to
be working normally.

> Based on the failure this machine showed a message:
>=20
> Jun 21 15:31:52 FBSDCA57 kernel: >.n1.1di2n3:g/
>=20
> It eventually reported:
>=20
> cp: /mnt/usr/obj/clang-armv7-installworld-poud.tar.alt: Device not =
configured
>=20
> Later, when I had things booted again and and did the
> dhclient ue0 again, it reported:
>=20
> nfs server a.a.a.a:/: is alive again
>=20
> (The a.a.a.a is a local network address that I've
> textually replaced. This was not remote location
> use.)
>=20
>=20
> I'll note that I've never had problems with the USB3
> SSD being the only USB device on the external USB3
> powered-hub. (But I do not normally use the USB3 hub.)
> I think that is the 1st time that I've also plugged in
> something else to the hub.
>=20

To be clear: both the USB3 SSD and the USB3 Ethernet were
plugged in to the external USB3 Hub before powering on the
Rock64.

=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B3706E2D-B339-4E86-A0A3-3A5180377ABA>