f0f47121 imp May 29, 2021, 5:05 a.m.
Part of the nvme recovery process for errors is to reset the
card. Sometimes, this results in failing the entire controller. When nda
is in use, we free the sim, which will sleep until all the I/O has
completed. However, with only one thread, the request fail task never
runs once the reset thread sleeps here. Create two threads to allow I/O
to fail until it's all processed and the reset task can proceed.

This is a temporary kludge until I can work out questions that arose
during the review, not least is what was the race that queueing to a
failure task solved. The original commit is vague and other error paths
in the same context do a direct failure. I'll investigate that more
completely before committing changing that to a direct failure. mav@
raised this issue during the review, but didn't otherwise object.

Multiple threads, though, solve the problem in the mean time until other
such means can be perfected.

Reviewed by:		jhb@
Sponsored by:		Netflix
Differential Revision:	https://reviews.freebsd.org/D30366
e5f5b6a7 jrtc27 May 29, 2021, 3:36 a.m.
GitHub removed Clang 9 from the 20.04 image[1], breaking this build.
Thus, manually add the specific versioned packages we need for the
Ubuntu jobs to ensure they're installed. Note that we don't do the same
for macOS, as Homebrew does not allow multiple llvm@N to co-exist,
giving an error if you attempt to install a second one. In practice we
don't actually use the compiler field here for anything other than the
build name, it's only the cross-bindir that matters, so when it
eventually moves to 12 the name will get confusing but the job will
still work.

MFC after:	immediately

[1] https://github.com/actions/virtual-environments/commit/15a610677be406d250c1f6732b03c8b87e693a0a
9b0f1d64 rew May 29, 2021, 2:59 a.m.
Fix fsck for 32-bit platforms.

This reverts commit f190f9193bc10a8193c87e0a02fa91400e4eb159.
871291c8 rew May 29, 2021, 2:51 a.m.
This reverts commit 84768d114951e88288024f09d4beae0956c3cf21.
5c9e9eb7 mckusick May 29, 2021, 2:41 a.m.
The segfault was being hit in the rerun of Pass 1 in ginode() when
trying to get an inode that needs to be repaired. When the first run
of fsck_ffs finishes it clears the inode cache, but ginode() was
failing to check properly and tried to access the deallocated cache entry.

Reported by:  Peter Holm
Reviewed by:  Chuck Silvers
Tested by:    Peter Holm and Chuck Silvers
MFC after:    3 days
Sponsored by: Netflix
677cb972 jhb May 28, 2021, 11:47 p.m.
If an iSCSI connection is shutdown abruptly (e.g. by a RST from the
peer), pending iSCSI PDUs and page pod work requests can be in the
ulp_pduq when the final CPL is received indicating the death of the

Reported by:	Jithesh Arakkan @ Chelsio
f949967c jhb May 28, 2021, 11:47 p.m.
In 4427ac3675f9, the TOM driver stopped sending work requests to
program iSCSI page pods directly and instead queued them to be written
asynchronously with iSCSI PDUs.  The queue of mbufs to send is
protected by the inp lock.  However, the inp cannot be safely obtained
from the toep since a RST from the remote peer might have cleared
toep->inp asynchronously in an ithread.  To fix, obtain the inp from
the socket as is already done in icl_cxgbei_conn_pdu_queue_cb() and
fail the new transfer setup with ECONNRESET if the connection has been

To avoid passing sockets or inps into the page pod routines, pull the
mbufq out of the two relevant page pod routines such that the routines
queue new work request mbufs to a caller-supplied mbufq.

Reported by:	Jithesh Arakkan @ Chelsio
Fixes:		4427ac3675f91df039d54a23518132e0e0fede86
67360f7b jhb May 28, 2021, 11:45 p.m.
T6 makes several changes relative to T5 for receive of iSCSI PDUs.

First, earlier adapters issue either 2 or 3 messages to the host for
each PDU received: CPL_ISCSI_HDR contains the BHS of the PDU,
CPL_ISCSI_DATA (when DDP is not used for zero-copy receive) contains
the PDU data as buffers on the freelist, and CPL_RX_ISCSI_DDP with
status of the PDU such as result of CRC checks.  In T6, a new
PDUs which are directly placed via DDP only report a single
CPL_RX_ISCSI_CMP message.  Data PDUs received on the free lists are
reported as CPL_ISCSI_DATA followed by CPL_RX_ISCSI_CMP.  Control PDUs
such as R2T are still reported via CPL_ISCSI_HDR and CPL_RX_ISCSI_DDP.

Supporting this requires changing the CPL_ISCSI_DATA handler to
allocate a PDU structure if it is not preceded by a CPL_ISCSI_HDR as
well as support for the new CPL_RX_ISCSI_CMP.

Second, when using DDP for zero-copy receive, T6 will only issue a
CPL_RX_ISCSI_CMP after a burst of PDUs have been received (indicated
by the F flag in the BHS).  In this case, the CPL_RX_ISCSI_CMP can
reflect the completion of multiple PDUs and the BHS and TCP sequence
number included in the message are from the last PDU received in the
burst.  Notably, the message does not include any information about
earlier PDUs received as part of the burst.  Instead, the driver must
track the amount of data already received for a given transfer and use
this to compute the amount of data received in a burst.  In addition,
the iSCSI layer currently has no way to permit receiving a logical PDU
which spans multiple PDUs.  Instead, the driver presents each burst as
a single, "large" PDU to the iSCSI target and initiators.  This is
done by rewriting the buffer offset and data length fields in the BHS
of the final PDU as well as rewriting the DataSN so that the received
PDUs appear to be in order.

To track all this, cxgbei maintains a hash table of 'cxgbei_cmp'
structures indexed by transfer tags for each offloaded iSCSI
connection.  When a SCSI_DATA_IN message is received, the ITT from the
received BHS is used to find the necessary state in the hash table,
whereas SCSI_DATA_OUT replies use the TTT as the key.  The structure
tracks the expected starting offset and DataSN of the next burst as
well as the rewritten DataSN value used for the previously received

Discussed with:	np
Sponsored by:	Chelsio Communications
Differential Revision:	https://reviews.freebsd.org/D30458
55baee8c bdrewery May 28, 2021, 11:29 p.m.
MFC after:	3 days
Sponsored by:	Dell EMC
e20e60be imp May 28, 2021, 10:40 p.m.
Differential Revision:		https://reviews.freebsd.org/D30299

Sponsored by:		Netflix
9fac68fc imp May 28, 2021, 10:40 p.m.
It includes:

1)Newly added TMF feature.
2)Added newly Huawei & Inspur PCI ID's
3)Fixed smartpqi driver hangs in Z-Pool while running on FreeBSD12.1
4)Fixed flooding dmesg in kernel while the controller is offline during in ioctls.
5)Avoided unnecessary host memory allocation for rcb sg buffers.
6)Fixed race conditions while accessing internal rcb structure.
7)Fixed where Logical volumes exposing two different names to the OS it's due to the system memory is overwritten with DMA stale data.
8)Fixed dynamically unloading a smartpqi driver.
9)Added device_shutdown callback instead of deprecated shutdown_final kernel event in smartpqi driver.
10)Fixed where Os is crashed during physical drive hot removal during heavy IO.
11)Fixed OS crash during controller lockup/offline during heavy IO.
12)Fixed coverity issues in smartpqi driver
13)Fixed system crash while creating and deleting logical volume in a continuous loop.
14)Fixed where the volume size is not exposing to OS when it expands.
15)Added HC3 pci id's.

Reviewed by:		Scott Benesh (microsemi), Murthy Bhat (microsemi), imp
Differential Revision:	https://reviews.freebsd.org/D30182

Sponsored by:		Netflix
7ad70d22 jhb May 28, 2021, 10:18 p.m.
While here, trim a spurious local: I missed when added SSL_sendfile.

PR:		255277
Reported by:	yuri
Reviewed by:	jkim
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D30483
91abbc49 mizhka May 28, 2021, 8:35 p.m.
Small patch to set "hw.model" by SoC ChipCommon ID. On BCM4718 it will be BCM4716, because 4716 is core for 4716,4717 & 4718.

Tested on Netgear WNR3500L (BCM4718) and Asus RT-N53 (BCM5357).

Reviewed by: landonf, yamori813@yahoo.co.jp
Sponsored by: Postgres Professional
Differential revision: https://reviews.freebsd.org/D12737
9aa0e5af wulf May 28, 2021, 8:29 p.m.
The second set of USB transfer is requested by hkbd(4) and
should improve HID keyboard handling in kdb and panic contexts.

MFC after:	1 week
Reviewed by:	hselasky
Differential revision:	https://reviews.freebsd.org/D30486
e889a462 wulf May 28, 2021, 8:29 p.m.
Which happens when USB transfer setup is failed.

MFC after:	1 week
PR:		254974
Reviewed by:	hselasky
Differential revision:	https://reviews.freebsd.org/D30485