Date: Thu, 31 Mar 2022 21:24:28 -0600 From: Warner Losh <imp@bsdimp.com> To: George Michaelson <ggm@algebras.org> Cc: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: CAM timeouts on boot (13.0-p8, Dell R730xd, mrsas controller) Message-ID: <CANCZdfryHTfA0gTs6eEkMG9x6WxDo%2BsMijQqJuUbEdaO%2B546pA@mail.gmail.com> In-Reply-To: <CAKr6gn1KEk5T0W6yJniKKSfHYaNdGh=BhS5LUJ=Htg2mWeTR5g@mail.gmail.com> References: <CAKr6gn1KEk5T0W6yJniKKSfHYaNdGh=BhS5LUJ=Htg2mWeTR5g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000002140fe05db8f5145 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 31, 2022 at 9:14 PM George Michaelson <ggm@algebras.org> wrote: > I upgraded 12.2 to 13.0-p8 and hit a delay with SCSI drive > initialisation, it loops for a timeout over the "Waiting for CAM" > message, then proceeds. > OK. > This interferes with the ZFS initialisation and the non-root zpool are > not imported. > It does not. The Waiting for CAM happens before mountroot, and zpool imports are after that. It cannot interfere. IT's just a message that says CAM hasn't finished probing its buses to release mountroot. Something else must be going on. > I intruded a /usr/local/etc/rc.d script PROCEED: var REQUIRE: zfs > which put it right after zfs initialisation, before any daemons, and I > can manually zpool import the tank once the SCSI stuff has settled > down. > > Adding delay to loader.conf CAM initialisation didn't fix this. > > There are references to this in 2018-2020 timeframe, but mostly it's > people on desktops. I am not used to Dell rackmounts going this bad. > A dmesg would help. Generally, CAM probes all buses to completion before it releases the hold on mountroot. Something else is afoot. My spidy sense says the kernel doesn't have all the disk controllers in it, some are loaded by devmatch, which happens late enough to explain the behavior you are seeing. Or maybe there's a USB device which shows up late, since I've seen umass arrive too late to hold off mountroot. If adding delay doesn't help, then that tells me that the disk controller SIM isn't present before mountroot. Warner --0000000000002140fe05db8f5145 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 31, 2022 at 9:14 PM Georg= e Michaelson <<a href=3D"mailto:ggm@algebras.org">ggm@algebras.org</a>&g= t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I upgr= aded 12.2 to 13.0-p8 and hit a delay with SCSI drive<br> initialisation, it loops for a timeout over the "Waiting for CAM"= <br> message, then proceeds.<br></blockquote><div><br></div><div>OK.<br></div><d= iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> This interferes with the ZFS initialisation and the non-root zpool are<br> not imported.<br></blockquote><div><br></div><div>It does not. The Waiting = for CAM happens before mountroot, and zpool imports are after that.</div><d= iv>It cannot interfere. IT's just a message that says CAM hasn't fi= nished probing its buses to</div><div>release mountroot. Something else mus= t be going on.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa= dding-left:1ex"> I intruded a=C2=A0 /usr/local/etc/rc.d script PROCEED: var REQUIRE: zfs<br> which put it right after zfs initialisation, before any daemons, and I<br> can manually zpool import the tank once the SCSI stuff has settled<br> down.<br> <br> Adding delay to loader.conf CAM initialisation didn't fix this.<br> <br> There are references to this in 2018-2020 timeframe, but mostly it's<br= > people on desktops. I am not used to Dell rackmounts going this bad.<br></b= lockquote><div><br></div><div>A dmesg would help. Generally, CAM probes all= buses to completion before it releases</div><div>the hold on mountroot.</d= iv><div>Something else is afoot.</div><div><br></div><div>My spidy sense sa= ys the kernel doesn't have all the disk controllers in it, some are</di= v><div>loaded by devmatch, which happens late enough to explain the behavio= r you are</div><div>seeing. Or maybe there's a USB device which shows u= p late, since I've seen umass</div><div>arrive too late to hold off mou= ntroot. If adding delay doesn't help, then that tells me</div><div>that= the disk controller SIM isn't present before mountroot.<br></div><div>= <br></div><div>Warner<br></div></div></div> --0000000000002140fe05db8f5145--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfryHTfA0gTs6eEkMG9x6WxDo%2BsMijQqJuUbEdaO%2B546pA>