On Tue, Aug 25, 2020 at 09:41:41AM +0200, Hans Petter Selasky wrote: > > Can you try r364346 ? > The kernel compiled and installed without trouble. After running run bootcmd_usb0 the machine loaded the kernel, but stopped at the loader prompt. The keyboard was connected direct to the Pi, the mouse was disconnected. It isn't obvious why it stopped at the loader prompt. lsdev reports disk devices: disk0: 250085377 X 512 blocks (removable) disk0s1: DOS/Windows disk0s2: FreeBSD disk0s2a: FreeBSD UFS disk0s2b: FreeBSD swap disk1: 1953525169 X 512 blocks disk1s1: DOS/Windows disk1s2: FreeBSD disk1s2a: FreeBSD UFS disk1s2b: FreeBSD swap http: (unknown) net devices: net0: OK Disk0 is the (bootable) microSD, disk1 is the hard drive. Boot -s came up single-user, with / mounted from /dev/da0s2a as desired. Fsck reported the filesystem clean. Exit to multi-user worked. The USB system keyboard (plugged into the Pi) worked. The mouse (plugged into the hub after boot) also worked. A second reboot with the mouse connected via the hub worked without pausing at the loader prompt. Plugging the FTDI FT232 adapter into the hub triggered a round of uhub_reattach_port: giving up port reset - device vanished messages, but this time they stopped when I pulled the FT232. Plugging the FT232 directly into the Pi caused normal recognition. It looks as if the FT232 somehow interferes with disk discovery. A reboot with USB disk & mouse in the hub but keyboard and FT232 in the Pi again resulted in a mountroot failure, along with a few other error messages: uhub2: MTT enabled Root mount waiting for: usbus1 CAM uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 CAM usb_alloc_device: set address 7 failed (USB_ERR_IOERROR, ignored) Root mount waiting for: usbus1 CAM Root mount waiting for: usbus1 CAM usbd_setup_device_desc: getting device descriptor at addr 7 failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=7, set address failed! (USB_ERR_IOERROR, ignored) Root mount waiting for: usbus1 CAM Root mount waiting for: usbus1 CAM usbd_setup_device_desc: getting device descriptor at addr 7 failed, USB_ERR_IOERROR Root mount waiting for: usbus1 CAM usbd_req_re_enumerate: addr=7, port reset failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=7, port reset failed, USB_ERR_IOERROR Root mount waiting for: usbus1 CAM usbd_req_re_enumerate: addr=7, port reset failed, USB_ERR_IOERROR ugen1.7: <Unknown > at usbus1 (disconnected) uhub_reattach_port: could not allocate new device Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Root mount waiting for: CAM Mounting from ufs:/dev/da0s2a failed with error 2; retrying for 3 more seconds Mounting from ufs:/dev/da0s2a failed with error 2. Loader variables: vfs.root.mountfrom=ufs:/dev/da0s2a vfs.root.mountfrom.options=rw With the FT232 unplugged the machine came up normally. With a _different_ FT232 plugged in it also came up normally. Both are thought to be genuine, but they are of different age and produce different recognition messages: The FT232 that causes trouble reports ugen1.4: <FTDI TTL232R-3V3> at usbus1 uftdi0 on uhub1 uftdi0: <TTL232R-3V3> on usbus1 The one that seems to work is newer and reports ugen1.4: <FTDI FT232R USB UART> at usbus1 uftdi0 on uhub1 uftdi0: <FT232R USB UART> on usbus1 On balance I think the new kernel is better-behaved. Beyond that I'm at a loss. If you can suggest other things to try please do. Thanks for all your help, bob prohaskaReceived on Tue Aug 25 2020 - 16:29:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC