Date: Tue, 5 Sep 2023 18:49:07 -0600 From: John Nielsen <lists@jnielsen.net> To: freebsd-scsi@freebsd.org Subject: Re: Troubleshooting help for net/isboot-kmod Message-ID: <9A50B0C5-B7D3-40BA-AACC-D7504632E895@jnielsen.net> In-Reply-To: <15622762-D8A3-4E98-B932-A7BC7649C57B@jnielsen.net> References: <15622762-D8A3-4E98-B932-A7BC7649C57B@jnielsen.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 5, 2023, at 3:32 PM, John Nielsen <lists@jnielsen.net> wrote: >=20 > Since the original author has presumably moved on to better things, = I=E2=80=99m the maintainer of the net/isboot-kmod port for enabling = booting from iSCSI via an iSCSI Boot Firmware Table. I would not call = myself a kernel developer but I get by in C. >=20 > Note that the port uses its own iSCSI implementation and none of the = in-tree iSCSI code (e.g. under sys/dev/iscsi). >=20 > I=E2=80=99m trying to solve a problem where a system will boot up and = negotiate an iSCSI session correctly, log in to the target, but then = never continue or attach a peripheral after attempting a cam rescan. = (See also https://github.com/jnielsendotnet/isboot/issues/11). I can = reproduce this issue about 30% of the time on my test system as long as = I have isboot's debug messages turned off. With them turned on it is = 100% repeatable (which poses a challenge in directly copying kernel = messages from a successful boot with debug enabled). >=20 > When the problem occurs, isboot completes its cam_attach function, = (handling an XPT_PATH_INQ action along the way), enters its cam_rescan = function, but never exits. See the code here: = https://github.com/jnielsendotnet/isboot/blob/master/src/iscsi.c#L2300 >=20 > I can see from the debug output (below) that it again does = XPT_PATH_INQ (4 times), then gets an XPT_ASYNC followed by an XPT_ABORT = action. Both of those are handled by the fall-through default of setting = ccb_h.status to CAM_REQ_INVALID (see = https://github.com/jnielsendotnet/isboot/blob/master/src/iscsi.c#L2192 ) >=20 > So what could be going on? I don=E2=80=99t have trace output from a = successful boot to compare with, sadly. I feel like perhaps the code = should do something with at least one of the XPT_ASYNC or XPT_ABORT = actions but I don=E2=80=99t know what exactly (or why the need only = arises some of the time). >=20 > -JN >=20 > =3D=3D=3D=3D=3D failed boot debug output =3D=3D=3D=3D=3D > cam attach > isboot action 4 > isboot action 4 done > cam attach end > cam rescan > isboot action 4 > isboot action 4 done > isboot action 4 > isboot action 4 done > isboot action 4 > isboot action 4 done > isboot action 4 > isboot action 4 done > isboot action 15 > isboot action 15 done > isboot action 16 > isboot action 16 done I just saw that these are hex (%x) and not decimal (%d) so the actions = are really 0x15 XPT_GET_TRAN_SETTINGS and 0x16 XPT_SET_TRAN_SETTINGS, = which do appear to be implemented. Still no closer to finding out why it = doesn=E2=80=99t always work though. > Trying to mount root from ufs:/dev/gpt/[REDACTED] [rw,noatime]... > Root mount waiting for: CAM (Repeats indefinitely) >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9A50B0C5-B7D3-40BA-AACC-D7504632E895>