Bug 242180 - kern.cam.boot_delay="10000" parameter in /boot/loader.conf stopped working. Catastrophe!
Summary: kern.cam.boot_delay="10000" parameter in /boot/loader.conf stopped working. C...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-bugs mailing list
Keywords: regression
Depends on:
Reported: 2019-11-23 19:13 UTC by Michael
Modified: 2019-11-28 11:37 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael 2019-11-23 19:13:45 UTC
After applying the 4a46b2449c63e010014dc0fb2a3caa5e20b97933 commit, the kern.cam.boot_delay="10000" parameter in /boot/loader.conf stopped working. Catastrophe! Now I have to load mlx4en.ko in firewall rules!
 (in /etc/rc.firewall adding at end "kldload mlx4en")

The main problem is described here:

Please correct the situation.

commit 4a46b2449c63e010014dc0fb2a3caa5e20b97933
   committer mav <mav@FreeBSD.org>
     Fri, 22 Nov 2019 20:39:51 +0200 (18:39 +0000)
  Make CAM use root_mount_hold_token() to delay boot.
Before this change CAM used config_intrhook_establish() for this purpose,
but that approach does not allow to delay it again after releasing once.
USB stack uses root_mount_hold() to delay boot until bus scan is complete.
But once it is, CAM had no time to scan SCSI bus, registered by umass(4),
if it already done other scans and called config_intrhook_disestablish().
The new approach makes it work smooth, assuming the USB device is found
during the initial bus scan.  Devices appearing on USB bus later may still
require setting kern.cam.boot_delay, but hopefully those are minority.
MFC after: 2 weeks
Sponsored by: iXsystems, Inc.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2019-11-23 19:44:20 UTC
Notify committer of r355010 (cited as 4a46b2449c63e010014dc0fb2a3caa5e20b97933).