Troubleshooting help for net/isboot-kmod

John Nielsen

2023-09-06 00:49:07 UTC

Post by John Nielsen
Since the original author has presumably moved on to better things, I’m 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.
Note that the port uses its own iSCSI implementation and none of the in-tree iSCSI code (e.g. under sys/dev/iscsi).
I’m 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).
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
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 )
So what could be going on? I don’t 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’t know what exactly (or why the need only arises some of the time).
-JN
===== failed boot debug output =====
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’t always work though.

Post by John Nielsen
Trying to mount root from ufs:/dev/gpt/[REDACTED] [rw,noatime]...
Root mount waiting for: CAM (Repeats indefinitely)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de