The Genesys chip is failing when issueing READ_CAP(16) command.
Force a quirk to disable it and use READ_CAP(10) instead.
Also, depending on used firmware, GL3224 can be recognized
either as 'storage device' or 'mass storage class' -
enable both variants in scsi_quirk_table.
Submitted by: Wojciech Macek <wma@semihalf.com>
Konrad Adamczyk <ka@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
Reviewed by: mav
Differential revision: https://reviews.freebsd.org/D10902
The motivation for this is two-fold.
1. Some old WD SATA disks may appear as if they need to be spun up
when they are already spinning. Those disks would respond with
an error to the spin-up request.
2. Even if we really fail to spin up the disk, we still can try to
proceed to the subsequent phases. If we fail later on, then no
difference. Otherwise we get a chance to communicate with the
disk which is better than completely ignoring it, because a user
can try to recover the disk.
Reviewed by: mav
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D10896
This will help application developers simulate end of tape conditions.
To inject an error in sa0:
sysctl kern.cam.sa.0.inject_eom=1
This will return the next read or write request queued with 0 bytes
written. Any subsequent writes or reads will go along as usual.
This will also cause the early warning position flag to get set
for the next position query. So, 'mt status' will show the BPEW
(Beyond Programmable Early Warning) flag on the first query after
an error injection. After that, the position flags will be as they
are in the underlying tape drive.
Also, update the sa(4) man page to describe tape parameters,
which can be set via 'mt param'.
sys/cam/scsi/scsi_sa.c:
In saregister(), create the inject_eom sysctl variable.
In sastart(), check to see whether inject_eom is set. If
so, return the read or write with 0 bytes written to
indicate EOM. Set the set_pews_status flag so that we
fake PEWS status in the next position call for reads, and the
next 3 calls for writes. This allows the user to see the BPEW
flag one time via 'mt status'.
In sagetpos(), check the set_pews_status flag and fake
PEWS status and decrement the counter if it is set.
share/man/man4/sa.4:
Document the inject_eom sysctl variable.
Document all of the parameters currently supported via
'mt param'.
usr.bin/mt/mt.1:
Point the user to the sa(4) man page for more details on
supported parameters.
MFC after: 3 days
Sponsored by: Spectra Logic
sys/cam/scsi/scsi_all.h:
Add the SCSI Solid State Media log page (0x11) structure
definition. This gives the percentage used (in terms of
lifetime flash wear) of an SSD.
MFC after: 3 days
Sponsored by: Spectra Logic
After FreeBSD SVN revision 236814, the pass(4) driver changed from
only doing error recovery when the CAM_PASS_ERR_RECOVER flag was
set on a CCB to sometimes doing error recovery if the passed in
retry count was non-zero.
Error recovery would happen if two conditions were met:
1. The error recovery action was simply a retry. (Which is most
cases.)
2. The retry_count is non-zero. (Which happened a lot because of
cut-and-pasted code.)
This explains a bug I noticed in with camcontrol:
# camcontrol tur da34 -v
Unit is ready
# camcontrol reset da34
Reset of 1:172:0 was successful
At this point, there should be a Unit Attention:
# camcontrol tur da34 -v
Unit is ready
No Unit Attention.
Try it again:
# camcontrol reset da34
Reset of 1:172:0 was successful
Now set the retry_count to 0 for the TUR:
# camcontrol tur da34 -v -C 0
Unit is not ready
(pass42:mps1:0:172:0): TEST UNIT READY. CDB: 00 00 00 00 00 00
(pass42:mps1:0:172:0): CAM status: SCSI Status Error
(pass42:mps1:0:172:0): SCSI status: Check Condition
(pass42:mps1:0:172:0): SCSI sense: UNIT ATTENTION asc:29,2 (SCSI bus reset occurred)
(pass42:mps1:0:172:0): Field Replaceable Unit: 2
There is the unit attention. camcontrol(8) has a default
retry_count of 1, in case someone sets the -E flag without
setting -C.
The CAM_PASS_ERR_RECOVER behavior was only broken with the
CAMIOCOMMAND ioctl, which is the synchronous pass(4) API. It has
worked as intended (error recovery is only done when the flag
is set) in the asynchronous API (CAMIOQUEUE ioctl).
sys/cam/scsi/scsi_pass.c:
In passsendccb(), when calling cam_periph_runccb(), only
specify the error routine when CAM_PASS_ERR_RECOVER is set.
share/man/man4/pass.4:
Document that CAM_PASS_ERR_RECOVER is needed to enable
error recovery.
Reported by: Terry Kennedy <TERRY@glaver.org>
PR: kern/218572
MFC after: 1 week
Sponsored by: Spectra Logic
sys/cam/scsi/scsi_all.c:
In the asc_table, if we get a 0x20,0x02 error ("Access denied -
no access rights"), don't bother retrying. Instead, immediately
fail the command.
This is the error returned by Self Encrypting Drives (SED) when
they are locked.
MFC after: 3 days
Sponsored by: Spectra Logic
using a driver-supplied sbuf for printing device discovery
announcements. This helps ensure that messages to the console
will be properly serialized (through sbuf_putbuf) and not be
truncated and interleaved with other messages. The
infrastructure mirrors the existing xpt_announce_periph()
entry point and is opt-in for now. No content or formatting
changes are visible to the operator other than the new coherency.
While here, eliminate the stack usage of the temporary
announcement buffer in some of the drivers. It's moved to the
softc for now, but future work will eliminate it entirely by
making the code flow more linear. Future work will also address
locking so that the sbufs can be dynamically sized.
The scsi_da, scs_cd, scsi_ses, and ata_da drivers are converted
at this point, other drivers can be converted at a later date.
A tunable+sysctl, kern.cam.announce_nosbuf, exists for testing
purposes but will be removed later.
TODO:
Eliminate all of the code duplication and temporary buffers. The
old printf-based methods will be retired, and xpt_announce_periph()
will just be a wrapper that uses a dynamically sized sbuf. This
requires that the register and deregister paths be made malloc-safe,
which they aren't currently.
Sponsored by: Netflix
According to Warner, multiple TRIM BIOs are collapsed into a single CCB with
NULL bp. It is invalid to biotrack() NULL, and results in a fault. So,
don't do that.
Reported by: asomers@
Sponsored by: Dell EMC Isilon
The goal of this work is to remove the explicit dependency for ctl(4)
on iscsi(4), so end-users without iscsi(4) support in the kernel can
use ctl(4) for its other functions.
This allows those without iscsi(4) support built into the kernel to use
ctl(4) as a test mechanism. As a sidenote, this was possible around the
10.0-RELEASE period, but made impossible for end-users without iscsi(4)
between 10.0-RELEASE and 11.0-RELEASE.
Automatically load cfiscsi(4) from ctladm(8) and ctld(8) for backwards
compatibility with previously releases. The automatic loading feature is
compiled into the beforementioned tools if MK_ISCSI == yes when building
world.
Add a manpage for cfiscsi(4) and refer to it in ctl(4).
Differential Revision: D10099
MFC after: 2 months
Relnotes: yes
Reviewed by: mav, trasz
Sponsored by: Dell EMC Isilon
I think this message is not very useful for end user. Also its formatting
does not match other messages printed at that time. Those who really need
this information can always find it in `camcontrol negotiate daX -v`.
MFC after: 2 weeks
For three years now CAM does not use SIM lock, but still enforces SIM to
use it. Remove this requirement, allowing SIMs to have any locking they
prefer, if they pass no mutex to cam_sim_alloc().
MFC after: 2 weeks
Some SIMs report much less untagged device openings then tagged ones.
Target mode devices are not handled by regular probing routines, and so
there is nothing to increase queue size for them to the SIM's maximum.
To fix that resize the queue explicitly on ctl periph registration.
This radically improves performance of mpt(4) in target mode.
Also fetch and report device queue statistics in `ctladm dumpstructs`,
since regular way of `camcontrol tags` is not usable in target mode.
MFC after: 2 weeks
Queue statistics has nothing to do with presence or absence of INQUIRY
data, etc. Target mode devices are never configured, but have queues.
MFC after: 2 weeks
Some SIMs may not abort them implicitly, that either fail the LUN disable
request or just make us wait for those CCBs forever. With this change
I can successfully disable LUNs on mpt(4). For isp(4), which aborts them
implicitly, this change should be irrelevant.
MFC after: 2 weeks
Report UNMAP granularity as stripesize/-offset if we have no other values
to report there.
Add new quirk DA_Q_STRICT_UNMAP for cases when target is too critical to
misaligned UNMAP request, reporting errors instead of being suboptimal.
Setting this quirk makes da periph to forcefully align all UNMAP requests
to avoid those errors by the cost of some odd ranges not being UNMAP'ed.
This makes UNMAP usable within VMware 6.x VMs, just now 100% efficient.
MFC after: 2 weeks
For now it allows to unload CTL kernel module if there are no target-capable
SIMs in CAM. As next step full teardown of CAM targets can be implemented.
CAM_UNLOCKED is internal flag and cannot correctly be set by userland.
Return EINVAL from CAMIOCOMMAND and CAMIOQUEUE if it is set.
Also fix leaks in some of the error paths for CAMIOQUEUE.
PR: 215356
Reviewed by: ken, mav
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9869
The biggest change is that ctl_remove_initiator() now generates I_T NEXUS
LOSS event, cleaning part of LUs state related to the initiator.
MFC after: 2 weeks
If we asked to send sense data by setting CAM_SEND_SENSE, but SIM didn't
confirm transmission by setting CAM_SENT_SENSE, assume it was not sent.
Queue the I/O back to CTL for later REQUEST SENSE with ctl_queue_sense().
This is needed for error reporting on SPI HBAs like ahc(4)/ahd(4).
MFC after: 2 weeks
This code was disabled due to its high memory usage. But now we need this
functionality for cfumass(4) frontend, since USB MS BBB transport does not
support autosense.
MFC after: 2 weeks
When LUN is disabled, SIM starts returning queued ATIOs/INOTs. But at the
same time there can be some ATIOs/INOTs still carrying real new requests.
If we free those, SIM may leak some resources, forever expecting for any
response from us. So try to be careful, separating ATIOs/INOTs carrying
requests which still must be processed, from ATIOs/INOTs completed with
errors which can be freed.
MFC after: 2 weeks
Before this change XCOPY code could allocate memory in chunks up to 16-32MB
(VMware does XCOPY in 4MB chunks by default), that could be difficult for
VM subsystem to do due to KVA fragmentation, that sometimes created huge
allocation delays, blocking any I/O for respective LU for that time.
This change limits allocations down to TPC_MAX_IO_SIZE, which is 1MB now.
1MB is also not a cookie, but ZFS also can do that for large blocks, so
it should be less dramatic. As drawback this increases CPU overhead, but
it still look acceptable comparing to time consumed by ZFS read/write.
MFC after: 1 week
sys/cam/ctl/ctl.c:
In ctl_datamove(), inside CTL_IO_DELAY, add a lun variable and fill
it in before trying to dereference it.
MFC after: 3 days
Sponsored by: Spectra Logic
Before this change MaxCmdSN was reported as CmdSN + delta, that made it
limit number of requests in transmission from the initiator to target,
that was pretty useless. After this change MaxCmdSN limits number of
requests queued to CTL, i.e. maximal queue depth for the initiator.
The default limit is 256 outstanding requests per initiator at a time.
This code uses existing cs_outstanding_ctl_pdus counter to track queue
depth. It's semantics doen't perfectly match, but close enough to not
add another counter. Just don't set the maxtags below 2.
MFC after: 2 weeks
