Re: CAM breaks USB [was Re: USB causing boot to hang]

Hi Bob,

On 06.12.2019 23:57, bob prohaska wrote:
> For what it's worth, there does seem to be something amiss with USB.
> 
> An RPI2 at r355446 is having difficulty finding its USB devices 
> on a hands-off reboot. The problem wasn't apparent until this most
> recent upgrade. Here's the console output:
> 
> Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
> Warning: no time-of-day clock registered, system time will not be set accurately
> uhub0: 1 port with 1 removable, self powered
> Setting hostuuid: 95acec23-6e2c-11e7-8cb9-b827eb1a5a4b.
> Setting hostid: 0x6aebd8b6.
> swapon: /dev/da0b: No such file or directory
> Starting file system checks:
> /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/ufs/rootfs: clugen0.2: <vendor 0x0424 product 0x9514> at usbus0

...

> Warning! Some of the devices might not be available; retrying
> Waiting 30s for the root mount holders: usbus0 CAM

...

> The machine seems able to boot hands-off a kernel from r333740, 
> so I don't think it's hardware.
> 
> /boot/loader.conf contains
> bob_at_www:~ % more /boot/loader.conf
> kern.cam.boot_delay="20000"
> vm.pageout_oom_seq="2048"
> bob_at_www:~ % 
> 
> Booting direct to single-user, running fsck and exiting the shell 
> brought  multi-user operation. 

Your situation seem to be different from the first one.  As I
understand, you have root file system on SD card, while some other file
systems and swap on a USB stick.  The problem in your case is that root
mount wait for UFS waits only for root file system to appear, rather
then all of them.  There is an rc.d scripts that should wait for other
devices via calling root_hold_wait function, and you may see in logs
that they try, but I guess something is not right there.

As a workaround for the rc.d problem you may set tunable
vfs.root_mount_always_wait=1 .  After that I guess you may be even able
to remove kern.cam.boot_delay tunable to make boot even faster then
before, while still remain reliable if your USB stick behaves properly.

I think we should either enable vfs.root_mount_always_wait=1 by default,
or really fix the rc.d scripts to properly wait when needed.

> Still, It appears that recognition 
> of an FTDI FT232 usb-serial adapter is impaired as well. It had to 
> be unplugged and replugged after booting to be recognized.

I don't know what is the problem here, but I guess that
vfs.root_mount_always_wait may help here too, if we assume that the
problem is that some app is trying to open the serial adapter before the
USB scan is complete, that previously was workarounded by delay caused
by kern.cam.boot_delay setting.

-- 
Alexander Motin