From nobody Tue Sep 5 21:32:33 2023 X-Original-To: freebsd-scsi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RgJdQ1NQvz4s9yM for ; Tue, 5 Sep 2023 21:32:58 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from webmail5.jnielsen.net (webmail5.jnielsen.net [IPv6:2607:f170:34:11::b0]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.freebsdsolutions.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RgJdN30gHz3gBS for ; Tue, 5 Sep 2023 21:32:56 +0000 (UTC) (envelope-from lists@jnielsen.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of lists@jnielsen.net designates 2607:f170:34:11::b0 as permitted sender) smtp.mailfrom=lists@jnielsen.net; dmarc=none Received: from smtpclient.apple ([50.207.241.62]) (authenticated bits=0) by webmail5.jnielsen.net (8.17.2/8.17.1) with ESMTPSA id 385LWiKp016624 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 5 Sep 2023 15:32:47 -0600 (MDT) (envelope-from lists@jnielsen.net) X-Authentication-Warning: webmail5.jnielsen.net: Host [50.207.241.62] claimed to be smtpclient.apple From: John Nielsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: SCSI subsystem List-Archive: https://lists.freebsd.org/archives/freebsd-scsi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Troubleshooting help for net/isboot-kmod Message-Id: <15622762-D8A3-4E98-B932-A7BC7649C57B@jnielsen.net> Date: Tue, 5 Sep 2023 15:32:33 -0600 To: freebsd-scsi@freebsd.org X-Mailer: Apple Mail (2.3731.600.7) X-Spamd-Bar: / X-Spamd-Result: default: False [-0.85 / 15.00]; NEURAL_HAM_LONG(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.96)[-0.963]; NEURAL_SPAM_MEDIUM(0.92)[0.916]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-scsi@freebsd.org]; DMARC_NA(0.00)[jnielsen.net]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:6364, ipnet:2607:f170:30::/44, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; BLOCKLISTDE_FAIL(0.00)[50.207.241.62:server fail,2607:f170:34:11::b0:server fail]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-scsi@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4RgJdN30gHz3gBS 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. Note that the port uses its own iSCSI implementation and none of the = in-tree iSCSI code (e.g. under sys/dev/iscsi). 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). 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=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). -JN =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 Trying to mount root from ufs:/dev/gpt/[REDACTED] [rw,noatime]... Root mount waiting for: CAM (Repeats indefinitely)=