From owner-freebsd-arm@freebsd.org Tue Jun 9 00:38:28 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4CC5C33F714 for ; Tue, 9 Jun 2020 00:38:28 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49grnv1KJxz41N1 for ; Tue, 9 Jun 2020 00:38:26 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 0590cSYZ045022 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 8 Jun 2020 17:38:28 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 0590cS4r045021; Mon, 8 Jun 2020 17:38:28 -0700 (PDT) (envelope-from fbsd) Date: Mon, 8 Jun 2020 17:38:27 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Confusing USB device conflict Message-ID: <20200609003827.GB44587@www.zefox.net> References: <20200606223853.GA37281@www.zefox.net> <20200608230350.GA44587@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 49grnv1KJxz41N1 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net X-Spamd-Result: default: False [1.62 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.59)[-0.588]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zefox.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.36)[0.357]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.05)[-0.050]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[yahoo.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_WWW(0.50)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 00:38:28 -0000 On Mon, Jun 08, 2020 at 05:07:56PM -0700, Mark Millard wrote: > On 2020-Jun-8, at 16:03, bob prohaska 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: at usbus0 > > uhub2 on uhub1 > > uhub2: 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: 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: 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: 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: 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