Re: Strange USB loop

From: bob prohaska <fbsd_at_www.zefox.net>
Date: Tue, 25 Aug 2020 11:29:16 -0700
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 prohaska
 
Received 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