Date: Mon, 8 Jun 2020 17:38:27 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: Confusing USB device conflict Message-ID: <20200609003827.GB44587@www.zefox.net> 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 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: > > > 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. > > > 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: > Oops. I knew Ethernet shared the USB system, but the device interface is referred to by the name ue0. Never connected the two. > # 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. > Is there a connection to something called ue anywhere? 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 was long ago. I haven't checked in the last year at least. Thanks for reading! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200609003827.GB44587>