Date: Mon, 8 Jun 2020 18:35:42 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: Confusing USB device conflict Message-ID: <08B84101-C94B-4793-A560-A9566309AA34@yahoo.com> In-Reply-To: <ED19C188-5363-4420-BC0A-B893D327A20B@yahoo.com> References: <20200606223853.GA37281@www.zefox.net> <DC8818E7-270E-4A3B-882F-8A60A763760A@yahoo.com> <20200608230350.GA44587@www.zefox.net> <ED19C188-5363-4420-BC0A-B893D327A20B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >=20 >> On Sat, Jun 06, 2020 at 06:22:03PM -0700, Mark Millard wrote: >>>=20 >>>=20 >>>=20 >>> 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.) >>>=20 >> [In sum, the new hub can't be hot-swapped. I thought that would >> be possible, but if not there's nothing wrong] >=20 > Interesting. >=20 > 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. >=20 > 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=20 (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 =3D 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=3D0x2<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: >>=20 >> Head as of r361820 behaves differently than the Pi2 running 12.1,=20 >> but it does not seem better: Plugging the new hub and disk into=20 >> a running machine produces: >>=20 >> 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=3D8, 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=3D8, 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 >>=20 >> The smsc0 complaints continued, so I unplugged the hub and disk . >> To my surprise the error messages didn't stop, but they did change: >>=20 >> 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=3D2, 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=3D2, 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=3D2, 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=3D2, 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) >>=20 >> This looked like an endless loop, so I rebooted. >>=20 >> Next, I tried the new 1TB disk with the old hub. worked fine. >>=20 >> 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=3D8, 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=3D8, 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=3D8, 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=3D8, 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 >>=20 >> The error stream stopped, the disk didn't show up in /dev. >> Usbconfig reports=20 >> ugen0.7: <GenesysLogic USB2.0 Hub> at usbus0, cfg=3D0 md=3DHOST = spd=3DHIGH (480Mbps) pwr=3DSAVE (100mA) >> Not sure how that gybes with address 8 in the console messages. >>=20 >> 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. >>=20 >> Likewise, with 12.1 the Pi3 works correctly provided the hub >> is connected before booting. Didn't try the other permutations. >>=20 >> So, if hot-swapping the hub isn't in the cards, things seem >> to work.=20 >>=20 >> The messages from smsc0 are still puzzling. I gather >> it's a network device, which I don't have. =20 >=20 > Yes you do: smsc0 is for the built-in Ethernet on > the RPi3: >=20 > # 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 >=20 > Note that /usr/src/sys/conf/files has: >=20 > dev/usb/net/usb_ethernet.c optional uether | aue | axe | axge | = cdce | \ > cdceem | cue | ipheth | kue | = mos | \ > rue | smsc | udav | ure | = urndis | muge >=20 > # 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 >=20 > Note that /usr/src/sys/arm64/conf/GENERIC has: >=20 > # USB ethernet support > device muge > device smcphy > device smsc >=20 > On a RPi3 (omitted text indicated with ". . ."): >=20 > # devinfo=20 > nexus0 > ofwbus0 > psci0 > simplebus0 > . . . > bcm283x_dwcotg0 > usbus0 > uhub0 > uhub1 > smsc0 > miibus0 > smscphy0 > uhub3 > umass0 > uhub2 > ukbd0 > uhid0 > ums0 > . . . > ofw_clkbus0 > . . . > cryptosoft0 >=20 > (Context: head -r360311 based.) >=20 > 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. >=20 > I expect that if you do a "devinfo" you will > see a similar arrangement for the smsc0 in your > context. >=20 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=3D0x800f model=3D0xc rev=3D0x3 dev.smscphy.0.%location: phyno=3D1 dev.smscphy.0.%driver: smscphy dev.smscphy.0.%desc: SMC LAN8700 10/100 interface dev.smscphy.%parent:=20 dev.miibus.0.%parent: smsc0 dev.smsc.0.%parent: uhub1 dev.smsc.0.%pnpinfo: vendor=3D0x0424 product=3D0xec00 devclass=3D0xff = devsubclass=3D0x00 devproto=3D0x01 sernum=3D"" release=3D0x0200 = mode=3Dhost intclass=3D0xff intsubclass=3D0x00 intprotocol=3D0xff dev.smsc.0.%location: bus=3D0 hubaddr=3D2 port=3D1 devaddr=3D3 = interface=3D0 ugen=3Dugen0.3 dev.smsc.0.%driver: smsc dev.smsc.0.%desc: vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3 dev.smsc.%parent:=20 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. =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?08B84101-C94B-4793-A560-A9566309AA34>