Confusing USB device conflict

Tue Jun 9 01:35:49 UTC 2020

On 2020-Jun-8, at 17:07, Mark Millard <marklmi at yahoo.com> wrote:

> On 2020-Jun-8, at 16:03, bob prohaska <fbsd at www.zefox.net> wrote:
> 
>> On Sat, Jun 06, 2020 at 06:22:03PM -0700, Mark Millard wrote:
>>> 
>>> 
>>> 
>>> Does this happen with FreeBSD head? It looked like there
>>> was a late 2019 check-in that was related to a context
>>> that involved the above types of messages on a RPi*. If
>>> you are lucky, may be there is something someone could
>>> MFC back into 12 that would help. (I do not know the
>>> details or if what I saw really would help if head
>>> works okay.)
>>> 
>> [In sum, the new hub can't be hot-swapped. I thought that would
>> be possible, but if not there's nothing wrong]
> 
> Interesting.
> 
> As I have my root file system for booting on the powered
> hub, I do not ever hot-swap the powered hub. So I'd never
> have noticed such behavior.
> 
> I can probably get access to another one at some point,
> of the same type as is used at boot, and plug it in to
> a separate port while the RPi3 is in operation.

I tried (with the extra hub already powered in each case):

A) Plugging the extra USB3 hub in the operating RPi3.

B) Unplugging the extra hub.

C) Plugging in a USB3 SSD to the extra hub and then
   plugging that hub unto the RPi3.

D) Unplugging the extra USB3 hub from the RPi3 (still having
   the USB3 SSD in place).

E) Plugging in the extra USB3 hub against, this time with
   the USB3 SSD already plugged in.

F) Unplugging the extra hub from the RPi3.

It all worked. The only oddity was during the (A)
action it reported the following against the root
file system's USB SSD:

(da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 01 65 af 00 00 00 40 00 
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain

as if plugging-in interfered with an in-progress I/O
to the root file system.

Other then that the messages looked like
(I replaced serial numbers):

ugen0.9: <GenesysLogic USB2.0 Hub> at usbus0
uhub4 on uhub1
uhub4: <GenesysLogic USB2.0 Hub, class 9/0, rev 2.00/90.20, addr 9> on usbus0
uhub4: MTT enabled
uhub4: 4 ports with 4 removable, self powered

ugen0.9: <GenesysLogic USB2.0 Hub> at usbus0 (disconnected)
uhub4: at uhub1, port 4, addr 9 (disconnected)
uhub4: detached

ugen0.9: <GenesysLogic USB2.0 Hub> at usbus0
uhub4 on uhub1
uhub4: <GenesysLogic USB2.0 Hub, class 9/0, rev 2.00/90.20, addr 9> on usbus0
uhub4: MTT enabled
uhub4: 4 ports with 4 removable, self powered

ugen0.10: <OWC Envoy Pro mini> at usbus0
umass1 on uhub4
umass1: <OWC Envoy Pro mini, class 0/0, rev 2.10/1.00, addr 10> on usbus0
umass1:  SCSI over Bulk-Only; quirks = 0x0100
umass1:1:1: Attached to scbus1
da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
da1: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
da1: Serial Number #
da1: 40.000MB/s transfers
da1: 228936MB (468862128 512 byte sectors)
da1: quirks=0x2<NO_6_BYTE>

ugen0.9: <GenesysLogic USB2.0 Hub> at usbus0 (disconnected)
uhub4: at uhub1, port 4, addr 9 (disconnected)
ugen0.10: <OWC Envoy Pro mini> at usbus0 (disconnected)
umass1: at uhub4, port 3, addr 10 (disconnected)
da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
da1: <OWC Envoy Pro mini 0>  s/n # detached
(da1:umass-sim1:1:0:0): Periph destroyed
umass1: detached
uhub4: detached

I use one of the modern 5.1V 2.5A official power supplies,
in case that matters. I use this type for all the RPI*'s,
except the RPi4. (On RPi4's I use a CanaKit 5.1V 3.5A
power supply.) I've had fewer power problems with these
compared with past power supplies that I used.

This is all based on head -r360311 as a context.

>> Now using a Pi3:
>> 
>> Head as of r361820 behaves differently than the Pi2 running 12.1, 
>> but it does not seem better: Plugging the new hub and disk into 
>> a running machine produces:
>> 
>> ugen0.6: <GenesysLogic USB2.0 Hub> at usbus0
>> uhub2 on uhub1
>> uhub2: <GenesysLogic USB2.0 Hub, class 9/0, rev 2.00/92.24, addr 6> on usbus0
>> uhub2: MTT enabled
>> uhub2: 4 ports with 4 removable, self powered
>> usb_alloc_device: set address 8 failed (USB_ERR_IOERROR, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_IOERROR
>> usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_IOERROR, ignored)
>> smsc0: warning: bulk read error, USB_ERR_IOERROR
>> usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_IOERROR
>> usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_IOERROR, ignored)
>> smsc0: warning: Failed to read register 0x114
>> smsc0: warning: MII is busy
>> smsc0: warning: Failed to read register 0x114
>> smsc0: warning: MII is busy
>> smsc0: warning: Failed to read register 0x114
>> smsc0: warning: MII is busy
>> smsc0: warning: Failed to read register 0x114
>> smsc0: warning: MII is busy
>> usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_TIMEOUT
>> smsc0: warning: Failed to read register 0x114
>> smsc0: warning: MII is busy
>> 
>> The smsc0 complaints continued, so I unplugged the hub and disk .
>> To my surprise the error messages didn't stop, but they did change:
>> 
>> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT
>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT
>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT
>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT
>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT
>> ugen0.2: <Unknown > at usbus0 (disconnected)
>> 
>> This looked like an endless loop, so I rebooted.
>> 
>> Next, I tried the new 1TB disk with the old hub. worked fine.
>> 
>> Then I tried the new hub with the old 80GB disk. The console reported:
>> uhub2: <GenesysLogic USB2.0 Hub, class 9/0, rev 2.00/92.24, addr 7> on usbus0
>> uhub2: MTT enabled
>> uhub2: 4 ports with 4 removable, self powered
>> usb_alloc_device: set address 8 failed (USB_ERR_IOERROR, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_IOERROR
>> usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_STALLED, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
>> usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_STALLED, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
>> usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_STALLED, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
>> usbd_req_re_enumerate: addr=8, set address failed! (USB_ERR_STALLED, ignored)
>> usbd_setup_device_desc: getting device descriptor at addr 8 failed, USB_ERR_STALLED
>> ugen0.8: <Unknown > at usbus0 (disconnected)
>> uhub_reattach_port: could not allocate new device
>> uhub_explore: illegal enable change, port 1
>> 
>> The error stream stopped, the disk didn't show up in /dev.
>> Usbconfig reports 
>> ugen0.7: <GenesysLogic USB2.0 Hub> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA)
>> Not sure how that gybes with address 8 in the console messages.
>> 
>> Finally, I tried leaving the new hub connected with the old disk
>> and rebooting. Came up just fine. Unplugging the old disk and
>> plugging the new disk in its place also works fine.
>> 
>> Likewise, with 12.1 the Pi3 works correctly provided the hub
>> is connected before booting. Didn't try the other permutations.
>> 
>> So, if hot-swapping the hub isn't in the cards, things seem
>> to work. 
>> 
>> The messages from smsc0 are still puzzling. I gather
>> it's a network device, which I don't have.  
> 
> Yes you do: smsc0 is for the built-in Ethernet on
> the RPi3:
> 
> # grep -ri smsc /usr/src/sys/conf/ | more
> /usr/src/sys/conf/NOTES:device          smcphy          # SMSC LAN91C111
> /usr/src/sys/conf/files:dev/mii/smscphy.c               optional miibus | smscphy
> /usr/src/sys/conf/files:dev/usb/net/if_smsc.c           optional smsc
> /usr/src/sys/conf/files:                                         rue | smsc | udav | ure | urndis | muge
> 
> Note that /usr/src/sys/conf/files has:
> 
> dev/usb/net/usb_ethernet.c      optional uether | aue | axe | axge | cdce | \
>                                         cdceem | cue | ipheth | kue | mos | \
>                                         rue | smsc | udav | ure | urndis | muge
> 
> # grep -ri smsc /usr/src/sys/*/conf/ | more
> /usr/src/sys/arm/conf/GENERIC:device            smsc                    # SMSC LAN91C111
> /usr/src/sys/arm/conf/RPI-B:device              smscphy
> /usr/src/sys/arm/conf/RPI-B:device              smsc
> /usr/src/sys/arm/conf/SOCFPGA:device            smsc
> /usr/src/sys/arm/conf/SOCFPGA:device            smscphy
> /usr/src/sys/arm64/conf/NOTES:device    smc             # SMSC LAN91C111
> /usr/src/sys/arm64/conf/NOTES:device            smsc
> /usr/src/sys/arm64/conf/GENERIC:device          smc             # SMSC LAN91C111
> /usr/src/sys/arm64/conf/GENERIC:device          smsc
> 
> Note that /usr/src/sys/arm64/conf/GENERIC has:
> 
> # USB ethernet support
> device          muge
> device          smcphy
> device          smsc
> 
> On a RPi3 (omitted text indicated with ". . ."):
> 
> # devinfo 
> nexus0
> ofwbus0
>   psci0
>   simplebus0
>     . . .
>     bcm283x_dwcotg0
>       usbus0
>         uhub0
>           uhub1
>             smsc0
>               miibus0
>                 smscphy0
>             uhub3
>               umass0
>             uhub2
>               ukbd0
>               uhid0
>               ums0
>     . . .
>   ofw_clkbus0
>   . . .
> cryptosoft0
> 
> (Context: head -r360311 based.)
> 
> So the RPi3's Ethernet is connected to the
> internal uhub1. uhub3 is the external powered
> hub and is connected to the same RPi3 internal
> hub.
> 
> I expect that if you do a "devinfo" you will
> see a similar arrangement for the smsc0 in your
> context.
> 

By the way:

# sysctl -a | grep -i "\<smsc" | more
net.ue.0.%parent: smsc0
hw.usb.smsc.debug: 0
dev.smscphy.0.%parent: miibus0
dev.smscphy.0.%pnpinfo: oui=0x800f model=0xc rev=0x3
dev.smscphy.0.%location: phyno=1
dev.smscphy.0.%driver: smscphy
dev.smscphy.0.%desc: SMC LAN8700 10/100 interface
dev.smscphy.%parent: 
dev.miibus.0.%parent: smsc0
dev.smsc.0.%parent: uhub1
dev.smsc.0.%pnpinfo: vendor=0x0424 product=0xec00 devclass=0xff devsubclass=0x00 devproto=0x01 sernum="" release=0x0200 mode=host intclass=0xff intsubclass=0x00 intprotocol=0xff
dev.smsc.0.%location: bus=0 hubaddr=2 port=1 devaddr=3 interface=0 ugen=ugen0.3
dev.smsc.0.%driver: smsc
dev.smsc.0.%desc: vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3
dev.smsc.%parent: 

Note the:

net.ue.0.%parent: smsc0

I expect that this means that the ue code (driver) handles a
range of USB Ethernet hardware, including smsc based hardware,
but not limited to smsc hardware. ue0's instance ends up as a
child of smsc0 material for the particular type of context.
There is no /dev/ue0 or /dev/smsc0 involved for this type of
arrangement.

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