Date: Mon, 8 Jun 2020 19:19:29 -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: <42BBC517-8237-489E-BABD-B65720286BCB@yahoo.com> In-Reply-To: <20200609003827.GB44587@www.zefox.net> 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> <20200609003827.GB44587@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-Jun-8, at 17:38, bob prohaska <fbsd at www.zefox.net> wrote: > On Mon, Jun 08, 2020 at 05:07:56PM -0700, Mark Millard 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. >>=20 >>> 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 > FWIW, I did check the Pi2 running 12.1 at r360926. The new hub > does not work, even if connected and powered before boot. It > does not prevent boot, but somehow interferes with discovery > of other USB devices. I believe the old hub did work, but that=20 > was long ago. I haven't checked in the last year at least. Unfortunately, the only pre-aarch64 RPi2 that I've access to has its microsd card slot messed up: it forces the card back out. (The RPI2 v1.1 no longer latches the card in place but just ejects it.) As for the aarch64 based RPi2 V1.2, I use the same type of powered USB3-capable hub and USB3 SSD with that RPi2 that I use with the RPi3. I do so in the same way: the USB3 SSD is the root file system for the boot. (I've not done any hot-plugging experiments for this context.) I have done such booting with the USB3 SSD having an armv7 system. (Same media used to boot the OrangePi+ 2ed. The OPi+2e does not need the powered hub, at least when the USB3 SSD is the only external USB connection.) You may want to test the hub with a microsd card reader and microsd card instead of the spinning media and see if that makes a difference. (Unless the hub alone [no media] is enough to mess things up in your context.) =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?42BBC517-8237-489E-BABD-B65720286BCB>