Date: Wed, 3 Oct 2018 10:35:37 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Emmanuel Vadot <manu@bidouilliste.com> Cc: Trevor Roydhouse <trev@sentry.org>, freebsd-arm@freebsd.org, Mark Millard <marklmi@yahoo.com>, bob prohaska <fbsd@www.zefox.net> Subject: Re: Timeout poll on interrupt endpoint for RPI3 with keyboard and mouse Message-ID: <20181003173537.GB84788@www.zefox.net> In-Reply-To: <20181003011930.GA84788@www.zefox.net> References: <20180929185213.GA58381@www.zefox.net> <20180930111208.5df04f5b7fb336cdfcf2fd74@bidouilliste.com> <20180930130930.GB58381@www.zefox.net> <20180930132928.GC58381@www.zefox.net> <20180930155055.2c35693431e8dfff4eb7d7bd@bidouilliste.com> <20180930145702.GD58381@www.zefox.net> <ace02a4a-3a79-6d3f-69ee-82d6c3477388@sentry.org> <20181001022415.GA63212@www.zefox.net> <20181002203135.245edff2acfcbd8441d67cc3@bidouilliste.com> <20181003011930.GA84788@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 02, 2018 at 06:19:30PM -0700, bob prohaska wrote: > > As a final test, I unplugged the PL2303 USB-serial adapter which > had been in place throughout (I'd forgotten about it). On reboot > the video console emitted sporadic non-latin characters and > didn't progress past loader, far as I can tell. > > Output on the Pi3's serial console turned to complete gobbldygook, > mostly unprintable with a few latin characters sprinkled in. > I'd forgotten that the PL2303's connector shell provided local ground for the serial console signals. The intention was to eliminate ground loops in the chain of serial connections. Using the ground pin next to the Pi3's UART pins restored normal serial console operation. Repeating the boot test with _only_ Dell keyboard/hub and mouse (no other USB devices and no monitor) connected repeated the former problem with ALPHA8: Type '?' for a list of commands, 'help' for more detailed help. OK ;21;150tTimeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint Timeout poll on interrupt endpoint It looks like the system got to the loader and is stuck there. If I type "boot" just right (quickly, and perhaps at the right time) on the serial console the machine comes up to multi-user. If I unplug the mouse from the keyboard's hub and power-cycle the pattern repeats as with the mouse connected. The caps lock light on the USB keyboard does not seem active, evidently the keyboard isn't recognized at this point. With the Dell keyboard/hub connected the machine hasn't (this morning) booted past the loader. That's different from last night, likely attributable to the lack of grounding on the serial console signals. With a laptop-sized Mac-compatible keyboard (no hub) the machine comes up multi-user without error messages, recognizing the keyboard with ukbd0 on uhub1 ukbd0: <vendor 0x04d9 USB Keyboard, class 0/0, rev 1.10/1.01, addr 4> on usbus0 kbd1 at ukbd0 Using a full size genuine Apple Mac keyboard with internal hub the machine boots without issue, reporting ugen0.4: <Mitsumi Electric Hub in Apple Extended USB Keyboard> at usbus0 uhub2 on uhub1 uhub2: <Mitsumi Electric Hub in Apple Extended USB Keyboard, class 9/0, rev 1.10/4.20, addr 4> on usbus0 uhub2: 3 ports with 2 removable, bus powered ugen0.5: <Mitsumi Electric Apple Extended USB Keyboard> at usbus0 ukbd0 on uhub2 ukbd0: <Mitsumi Electric Apple Extended USB Keyboard, class 0/0, rev 1.10/4.20, addr 5> on usbus0 kbd1 at ukbd0 Connecting an Amazon Essentials USB3.0 powered hub and power cycling reported no errors. Connecting the laptop-sized Mac-compatible keyboard (which worked on its own) to the hub and power cycling caused the console to report ue0: <USB Ethernet> on smsc0 ue0: Ethernet address: b8:27:eb:ba:68:d5 ugen0.4: <VIA Labs, Inc. USB2.0 Hub> at usbus0 uhub2 on uhub1 uhub2: <VIA Labs, Inc. USB2.0 Hub, class 9/0, rev 2.10/90.70, addr 4> on usbus0 uhub2: 4 ports with 4 removable, self powered usb_alloc_device: set address 5 failed (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored) Release APs...done It looks like hubs mixed with keyboards sometimes spell trouble, sometimes not. Apologies for the length, thanks for reading. bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181003173537.GB84788>