From owner-freebsd-arm@freebsd.org Tue Jun 9 05:45:41 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 3C7C7349951 for ; Tue, 9 Jun 2020 05:45:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (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 49gzcN2lz8z4fmv for ; Tue, 9 Jun 2020 05:45:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Y8pJxM8VM1kumsRdbc5jGiFs_e3zKe0m17DZLaiJs0APhcJiLANesy5LGgz7jGG r7AiN_s5xskcip4WvYfGPK707M4LP.aS_yS7EX1iXZz8JTTkaZNRVGW4WxKJPRfh1uD197IRqZxg SERtqdmIkWMr2ZKjBJvuFifaKm5n2OG7WsbbVmgrXjWEmkSDXXgpokY8yhrdCUXrwYsxvVgskhOU G6iTQdnFpj3Gf5f2dX9EwaRA_UH6rpokJZpxBw8oL9ZpF_UOd98VaDvmX.NugZWHzD9ad1RBUsmo cxaYsl4QfFGQ40t4Jtv.nI7STPynXRWvu2k8bFylSNf7anlaSjVd0ttgqISGvYxrKDaPyByp86Ow afqNgBQlLCpSGeFx.T7Ggquh4WH3uWzsSAHBaUiqqIjsBc_ptDVKhtE9PyIfHsc7DaAeHc9DmIkG 5cnF3cgCn1XzAUffSCy_dIAI_poSSB7Hq_JV5fA7JEtuOlA0abQiRrxDWcC5J.vC2CS3dP_APn_Q fuQO5HM4jox5dz6Ybbjgmspi20SOC6mv5wMGsDCvwyw60HHakfjoZWhHo89WfZbFcaBwndgMX2jR 8pAQ5WiD.BnIN6eHwTaXgDNr6eAeEXwbzZ0qkPaF1hhGIaag8A59Y9XbzRLm86_1uOWU7ioeumt5 fI27zGpkJ_XtKY7AxjMfoa3IDmyPufxjBL9GV5mEJH2kjIG8TYVV90kFGVsJBqJb_5LZBBiRg8e0 z77LWEJvUOKoT7i3JIZ_T7MH9i8WU4qYptiNASoukWrpKE6qGdl669tvbEt2Mfs0EkO9h9jdo_4. ouwsxuoOijgKQrjICEFvJblmYm1ARokRf5TMZiL.KsIntOKpRBC1xA2Z8xIyiL8cBLElKrvI7OB6 TrHRGcYw1KNoosTzITD4.CF9p8yXLUVsD5o4gGClrK.KBpJQ_K_xbcl.y4YdruBxUVxBM2F0EOjJ k.N6beU5mKfikbAIH1mmvOgeJYfhxGG3hZcPqUysqiTTlyy8scgOc_i8kNjZDSchFNgB62UhT16k SqIzSjQDlhVKVPQ8APWqbtPEPAC0XYFCXmQCO84BWI9lAlMGbaLU0T9qwKi6PqDSGohW9Wfmb8wf NHBTt9Ouhi2GdCxzALVzeV0dQqwW.MREIbrFfjv.C.5IzJ5VfQB1e2_EkK31GqiAmUL1I5R.1dC7 euX1MS2qSYFyLCEnBGk5zYoY2_GYanJtql1.EcUhrEYZjIC0hFdixeeMRLqb6Av4KlHRNJbpuitT 1u8aNsH5U3sCLN2IflzajYh1mJVsrN2FEGkqKksr4iLT83qhSeBLEgFQ1ssWGojgySwE5hQV_2rf pr5NVmFST8jWjAWJc6Gh_12GIu94kEC3P3VfLEBCgaVH.1mX3LYDy6fJxZyHxijE1k_zshimJhjD IPCtzxoUk8vfjfk56CDa4Dv_Hs9CGAxbakiUdox4Xo7JtMSZm4PDoMN7M Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 9 Jun 2020 05:45:38 +0000 Received: by smtp416.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 97204fb8a47830628060215efb03a9c9; Tue, 09 Jun 2020 05:45:36 +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: <42BBC517-8237-489E-BABD-B65720286BCB@yahoo.com> Date: Mon, 8 Jun 2020 22:45:35 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9DE60D49-7C14-45AE-8B0F-D4DB1ACC51AF@yahoo.com> References: <20200606223853.GA37281@www.zefox.net> <20200608230350.GA44587@www.zefox.net> <20200609003827.GB44587@www.zefox.net> <42BBC517-8237-489E-BABD-B65720286BCB@yahoo.com> To: bob prohaska X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49gzcN2lz8z4fmv X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.26 / 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.68.82: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.041]; 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.68.82:from]; NEURAL_HAM_SHORT(-0.75)[-0.746]; 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 05:45:41 -0000 On 2020-Jun-8, at 19:19, Mark Millard wrote: > On 2020-Jun-8, at 17:38, bob prohaska wrote: >=20 >> On Mon, Jun 08, 2020 at 05:07:56PM -0700, 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. >>>=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: 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 >> 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. >=20 > 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.) By holding the microsd card in place, I tried the armv7 RPi2 V1.1. It had no trouble using the powered USB3 hub and USB3 SSD on that hub to boot, with the USB3 SSD providing the root file system. (Head -r360311 based context, the same media used for the OPi+2e.) There was no problem with it finding and using its Ethernet. I did not try any hot-plugging experiments with this configuration. One point is that I use ssh and a serial console generally, so I do not normally have a keyboard or mouse or anything but the powered hub(s) externally plugged in to a RPi* USB port (and an Ethernet cable plugged into the built-in Ethernet). I also generally do not have a video connection (HDMI or other). > 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.) >=20 > 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)