From owner-freebsd-arm@freebsd.org Tue Jun 9 01:35:49 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 A6FCB341EA6 for ; Tue, 9 Jun 2020 01:35:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49gt436xb8z48M9 for ; Tue, 9 Jun 2020 01:35:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 5CJDLrAVM1mGhMv2Ic_iVvgxn_Lf7xaAythKc..77RMx1HmX6AUJAesZMyb6njJ p0cft5ekWqsNAx.Se0kQ9z1ika.FM8KIuH91hxhwpqs98WN8zZqlZHOTqIlwnzrFa7QpY5rltAtZ Gx3YQi9r9hhaeI54Yg46OYFjjjD79dSneYA6BJnUrzeZH6GcBHS_0_ZJqcQpq.mV94acIzDDlOlG v3JkBUBpxYSKqUmS7cM3q_vfO6lXCOiimrZJdbRHiuVL.JKALypfOzp4FRYTX5ZulxEksqdbagAP pVR3b3CYa__5TQlciwcSdycYcx8uZjruUwgdkzCu2RsvhvQ5d2fdi.RDqRONXIBm5Yg6tv_vUBwF op8Oc.nbkj0oTGeTHMKpPIswPjlUoN4t_VjjFg3yhAnFuKSilwkOa4tv5JouKjbOuZVlEM.ZXSVr nXheqMDdd9W02lX1YXEVlHC9WPM_IrQVJzNHF1dob1.zEnpsVGQ_u10vcerlST2vCgO7_cS2D34w NmDvSvIzOSViFb2hx5NC03w3GcOaRwii78_CCFrz1j_DnYSsqvtH4eMNbjAahbk98MYhU1UlyXF9 UoWZSzS_.RfprPbYh2Y4PCpefPw5MFzzVbWe7NKmVXZSegA9ivJlYG30m41P8jKeZtLp4AnOVrzh RNjcXoL9lYlucuxy4mlAqUm0j.K6aKLGdQKpleWtfXMvZo2Zg9pt.lw5gVXR0S4J0sTlIUHxhHAy mpyx3lB4emxIMdT9yqGGxyu1DkVQ4HXMX8c.Remcm8eWaYnZ7s8RF2cR6g6RHentCaZkUOKEn34d yKK5aKD7VVKB.jDGh1D6_Smv173mqZhnUMBMUrSKkyIcrlYT1uz35Fjg1zAdPmX_ngZio4w6P2j2 q2Q8Gwo0XO.ssQS9NWp5.Hsd2gSSEF6DMCC7tRxf4lsbCTB7BzRSCebfrhKwH.WpgoFGRHVUHXGu BYFQXmUGbtFv1JWyk5LUolR0uMXaB3IY3OGX9T14g.lh4cMz9REgzY8Q0TQmOmTZ6JTGNw7zYASB fABuel2_it5wngUsC7kthqeaMDf3qOZ7Zr2z1yJfkfBmHfp.jEkiywTjZSddS4wFdzZnBlM5sulU HfC5u0YxfjZ.8d2t4vlGKPHhefvqZr97h3Smm8OgbAtRZXHa11TZm9S0pOlutXZcxiBwf4mbYtb6 RXYEfxUJUOlFHoccnDfMEg1.pXw8KqVhZFmc4jbdp6JXwSp4ZZ9_y_cT839msSdQjmbJCOip7Rfo 8r42L9XqTWQNz9QgWrpEFzQi67v7NNuiMA5fKk2A2z9wcxGIbPnEpnTodpwTdcWovIQbeZqA.cEB ZdEIqpI5j3GPPNpZMU0K2u2OInKbf9UnGd2Z1GTsGZMmSgZPnr8.i_0kKcyVa30MqUy5nZueSFRl 5UOOPrEvnU2Q8oh84e4h6KfHzbUF5Hzg7z4LeAp5A.xjWTU_C38apHQa1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 9 Jun 2020 01:35:45 +0000 Received: by smtp415.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 15f5096a75ddc2b6b285973d8b88e17d; Tue, 09 Jun 2020 01:35:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Confusing USB device conflict From: Mark Millard In-Reply-To: Date: Mon, 8 Jun 2020 18:35:42 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <08B84101-C94B-4793-A560-A9566309AA34@yahoo.com> References: <20200606223853.GA37281@www.zefox.net> <20200608230350.GA44587@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49gt436xb8z48M9 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.15 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.66.147:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-0.97)[-0.973]; NEURAL_HAM_MEDIUM(-1.04)[-1.040]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.66.147:from]; NEURAL_HAM_SHORT(-0.64)[-0.641]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] 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 01:35:49 -0000 On 2020-Jun-8, at 17:07, Mark Millard wrote: > On 2020-Jun-8, at 16:03, bob prohaska 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: at usbus0 uhub4 on uhub1 uhub4: on = usbus0 uhub4: MTT enabled uhub4: 4 ports with 4 removable, self powered ugen0.9: at usbus0 (disconnected) uhub4: at uhub1, port 4, addr 9 (disconnected) uhub4: detached ugen0.9: at usbus0 uhub4 on uhub1 uhub4: on = usbus0 uhub4: MTT enabled uhub4: 4 ports with 4 removable, self powered ugen0.10: at usbus0 umass1 on uhub4 umass1: 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: Fixed Direct Access SPC-4 SCSI device da1: Serial Number # da1: 40.000MB/s transfers da1: 228936MB (468862128 512 byte sectors) da1: quirks=3D0x2 ugen0.9: at usbus0 (disconnected) uhub4: at uhub1, port 4, addr 9 (disconnected) ugen0.10: at usbus0 (disconnected) umass1: at uhub4, port 3, addr 10 (disconnected) da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 da1: 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: 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=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: 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: = 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: 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: 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 "\