Use an sbuf that drains to printf to avoid duplicating code in the two
versions of each function.
Reviewed by: mav
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D41263
The end of this function finishes the passed in sbuf, calls printf
manually on the contents, and then clears it. The caller then tries
to print the resulting sbuf. This works currently but will not work
for future callers that pass in an external sbuf to be appended to.
Reviewed by: mav
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D41260
If the periph doesn't have a valid protocol, these routines emit
fallback messages. However, the fallback messages duplicated the
periph name and unit number, and in the case of *denounce* included a
spurious newline.
Reviewed by: mav, imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D41177
Other protocol denounce routines use a "short" variant of announce
that does not include a trailing newline.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D41176
Log CAM_DEV_NOT_THERE status CCBs because they get dropped if a drive
disappears and these requests timeout or are cancelled. It's useful to
know the outstanding commands for failure analysis. Log
CAM_NVME_STATUS_ERROR status CCBs to bring in NVMe errors (this will be
more important in future commits that expand the information logged).
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D41168
Since a30ecd42b8 we've logged almost all unexpected errors from
commands. However, some passthru commands were not logged via devctl. To
fix this, pass all requests through passerror (which calls
cam_periph_error), but flag those requests that didn't want error
recovery as SF_NO_RECOVERY, like we do for device probing. By doing this
we get identical behavior to the current code, but log these errors.
We have had hangs on drives that seems to show no error. Vendor analysis
of the drive found an illegal command that happen to hang the drive. In
verifying their analysis, we discovered that the pass through commands
from things like smartctl that encountered errors or timeouts weren't
logged.
Sponsored by: Netflix
Reviewed by: ken, mav
Differential Revision: https://reviews.freebsd.org/D41167
This asc/ascq code 2/0 ("No seek complete") is a fatal error on modern
drives indicating a sensor failure. One of our vendors noticed we
retried 2/0 so many times in their failure analysis and asked why (no
other OS else does). They've indicated that this failures means the
track couldn't be located (something that's not going to change, except
if the environment changes significantly, which won't happen on a
timescale useful to retries).
Sponsored by: Netflix
Just spent a few minutes puzzling out why we do this. Add a comment to
remind my future self (and other intersted folk) why we do the reset
here when we'd set it a few lines above.
Sponsored by: Netflix
Add CAM_NVME_STATUS_ERROR error code. Flag all NVME commands that
completed with an error status as CAM_NVME_STATUS_ERROR (a new value)
instaead of CAM_REQ_CMP_ERR. This indicates to the upper layers of CAM
that the 'cpl' field for nvmeio CCBs is valid and can be examined for
error recovery, if desired.
No functional change. nda will still see these as errors, call
ndaerror() to get the error recovery action, etc. cam_periph_error will
select the same case as before (even w/o the change, though the change
makes it explicit).
Sponsored by: Netflix
Reviewed by: chuck, mav, jhb
Differential Revision: https://reviews.freebsd.org/D41085
The NVME SIM does not generate these status values, so remove them.
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D41084
This is normally caught by default:, but no harm in making it explicit
that we'll retry valid periphs.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D41083
0x18/0x8 is another code to indicate that the data was recovered
successfully, so complete the command w/o an error rather than retry the
operation.
Sponsored by: Netflix
Reviewed by: mav, jhb
Differential Revision: https://reviews.freebsd.org/D41082
SS_START and higher actions (currently only SS_TUR) allocate a recovery
CCB to send a command to the periph. Add a quick comment about that here.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D41081
This routine is specific to CAM and no longer assumes any internal
bus_dma knowledge as it is simple wrapper around bus_dmamap_load_mem.
Fixes: 60381fd1ee memdesc: Retire MEMDESC_CCB.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D41058
Instead, change memdesc_ccb to examine the CCB and return a memdesc of
a more generic type describing the data buffer.
Reviewed by: imp, markj
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D40880
- Read the version from cts.protocol_version.
- Only check xport_specific.nvme for PCI-e info for XPORT_NVME.
Reviewed by: chuck, imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D40618
The default xport ops for a new bus is xport_default, not NULL, so
check for that when determining if a bus failed to find a suitable
transport. In addition, the path needs to be freed with xpt_free_path
instead of a plain free so that the path's reference on the sim is
dropped; otherwise, cam_sim_free in the caller after xpt_bus_register
returns failure will hang forever.
Note that we have to exempt the xpt bus from this check as it uses
xport_default on purpose.
Reviewed by: mav, imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D40617
This updates our table to Sat Mar 25 2023 at 04:30 of the T10
asc-num.txt. I added all the codes that weren't present in the tree,
corrected a couple of the 'alphabet' comments about where the ASC/ASCQ
was defined. I did not, however, make the transition that the
asc-num.txt file made (it deleted W between P and R and added Z after D
so the first few letters shifted a bit). I've not removed the 'W' nor
added the 'Z' at this time. I'm looking for some way to do this
automatically. Try to pick reasonable responses for new entries. When in
doubt, I selected SS_RDEF.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D40718
This isn't needed by all devices and is only used by the da device (in
camcontrol). All the other da specific da scsi opcodes are only in
scsi_da.h.
Sponsored by: Netflix
Reviewed by: mav
Differential Revision: https://reviews.freebsd.org/D40527
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
ccb_h.status has two parts: the actual status and some addition bits to
indicate additional information. It must be masked before comparing
against completion codes. Add new inline function cam_ccb_success to
simplify this to test whether or not the request succeeded. Most of the
code already does this, but a few places don't (the rest likely should
be converted to use cam_ccb_status and/or cam_ccb_success, but that's
for another day). This caused at least one bug in recognizing devices
behind a SATA port multiplexer, though some of these checks were
fine with the special knowledge of the code paths involved.
PR: 270459
Sponsored by: Netflix
MFC After: 1 week (and maybe a EN requst)
Reviewed by: ken, mav
Differential Revision: https://reviews.freebsd.org/D39572
Use them when possible, instead of separated flags.
No functional change intended.
Reviewed by: hselasky, erj
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D39466
- passing I/O commands through nda requires nsid field to be set (it was
unused when going through nvme_ns_ioctl())
- ccb's status can be OR'ed with the flags, use CAM_STATUS_MASK
Reviewed by: imp (cam)
Differential Revision: https://reviews.freebsd.org/D37696
Before this ioctl frontend always replaced tags with sequential ones.
It was done for ctladm, that can not keep track of global tag list.
But in case of virtio-scsi in bhyve we can pass provided tags as-is.
It should be on virtio-scsi initiator to provide us valid tags. It
should allow proper task management, error reporting, etc. In case
of several virtio-scsi devices, they should use different CTL ports
or initiator IDs to avoid conflicts, but this is expected by design.
PR: 267539
SAM-5 specification states maximum size of command identifier (tag),
defined by specific transports, should not be larger than 64 bits.
While most of supported transports use 32 bits or less, it was
reported that virtio-scsi uses 64 bits. Truncation to 32 bits in
bhyve code caused false tag conflict errors reported and possibly
other issues.
This changes CTL ABI and HA protocol, so CTL_HA_VERSION is bumped.
While we make HA protocol incompatible, increase default maximum
number of ports in CTL from 256 to 1024, matching number of LUNs.
There are many reports from people who need many iSCSI targets with
only one LUN each. Increased memory consumption should be less of
a problem these days.
PR: 267539
For CAM, move to the FreeBSD standard copyright rather than the 'put it
at the front' variation. This variaiton has been flagged as potentially
problematic in other contexts. Since this variation wasn't a conscious
decision on our part, use the standard license from src/COPYRIGHT.
Also, remove the -FreeBSD suffix in SPDX-License-Identifier. It's
obsolete at SPDX and even the original text didn't match it.
MFC After: 3 days
Sponsored by: Netflix
The CAM version bump 0x19 -> 0x1a changed the CAMGETPASSTHRU definition,
so applications using the old ioctl are broken. However, that version
change did not affect anything relating to the ioctl implementation for
periphs.
Fixes: 8f9be1eed1 ("cam(4): Improve XPT_DEV_MATCH")
PR: 264709
Tested by: andreas.mahling@googlemail.com
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D36389
It was possible to cause kernel panic by passing too large args_len
or non-NULL result_nvl.
Though since the /dev/cam/ctl device is accessible only by root and
used only by limited number of tools it was not a big problem.
PR: 266115
PR: 266136
Reported by: Robert Morris <rtm@lcs.mit.edu>
MFC after: 1 week
Before this patch CAM periph drivers called both disk_alloc() and
disk_create() same time on periph creation. But then prevented disks
from opening until the periph probe completion with cam_periph_hold().
As result, especially if disk misbehaves during the probe, GEOM event
thread, triggered to taste the disk, got blocked on open attempt,
potentially for a long time, unable to process other events.
This patch moves disk_create() call from periph creation to the end of
the probe. To allow disk_create() calls from non-sleepable CAM contexts
some of its duties requiring memory allocations are moved either back
to disk_alloc() or forward to g_disk_create(), so now disk_alloc() and
disk_add_alias() are the only disk methods that require sleeping. If
disk fails during the probe disk_create() may just be skipped, going
directly to disk_destroy(). Other method calls during that time are
just ignored. Since GEOM may now see the disks after CAM bus scan is
already completed, introduce per-periph boot hold functions. Enclosure
driver already had such mechanism, so just generalize it.
Reviewed by: imp
MFC after: 1 month
Sponsored by: iXsystems, Inc.
Differential Revision: https://reviews.freebsd.org/D35784