History log of /freebsd/sys/cam/scsi/scsi_da.c (Results 101 – 125 of 942)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# fda9adaf 27-Oct-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r339670 through r339812.


# ea657f2c 26-Oct-2018 Warner Losh <imp@FreeBSD.org>

Add statistics for TRIM comands

Add a counter for the LBAs, Ranges and hardware commands so that we
can provide additional color to the statistics we provide to vendors.

Sponsored by: Netflix, Inc


# c6879c6c 23-Oct-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r339015 through r339669.


# 01d4e214 05-Oct-2018 Glen Barber <gjb@FreeBSD.org>

MFH r338661 through r339200.

Sponsored by: The FreeBSD Foundation


# aabac0c1 01-Oct-2018 Kenneth D. Merry <ken@FreeBSD.org>

Fix a da(4) driver memory leak for SCSI SMR devices.

In the probe case for SCSI SMR Host Aware or Most Managed drives, be sure
to free allocated memory.

sys/cam/scsi/scsi_da.c:
In dadone_probezone

Fix a da(4) driver memory leak for SCSI SMR devices.

In the probe case for SCSI SMR Host Aware or Most Managed drives, be sure
to free allocated memory.

sys/cam/scsi/scsi_da.c:
In dadone_probezone(), free the data pointer before returning.

MFC after: 3 days
Sponsored by: Spectra Logic
Approved by: re (kib)

show more ...


# f053ca1f 10-Aug-2018 Conrad Meyer <cem@FreeBSD.org>

Walk back r337554 while discussion continues

The idea was to get the uncontroversial mechanical change out of the way,
then get the meatier functional changes reviewed subsequently. I had not
reali

Walk back r337554 while discussion continues

The idea was to get the uncontroversial mechanical change out of the way,
then get the meatier functional changes reviewed subsequently. I had not
realized that the immediately adjacent issue was addressed in a different
direction in r334506 (see Warner's guidance in D15592).

Discussion continues, trying to determine if there is a secondary issue
still[1] and how best to fix it. With 12-related activities coming up,
while that is ongoing, just take this back for now.

[1]: Shutdown-time eventhandler events fire normally during panic's reboot
path. Driver callbacks that attempt to issue and wait on interrupt-
completed IO may never complete, hanging the system. This is particularly
obnoxious in the shutdown/panic path, as the debugger cannot be entered
anymore and the hang prevents reboot restoring availability.

(There's nothing CAM-specific about this problem -- any shutdown
event-triggered driver could do something like this during panic. But most
NICs, etc. don't try to send spin-down commands at shutdown. ;-))

Discussed with: imp, markj

show more ...


# 2077be2b 09-Aug-2018 Conrad Meyer <cem@FreeBSD.org>

cam(4): Add an xpt-neutral flag indicating a valid panic CCB

No functional change.

Note that this change is careful to set the CCB header xflags after
foo_fill_bar() routines, which generally zero

cam(4): Add an xpt-neutral flag indicating a valid panic CCB

No functional change.

Note that this change is careful to set the CCB header xflags after
foo_fill_bar() routines, which generally zero existing flags. An earlier
version of this patch mistakenly set the flag before the fill routines.

Submitted by: Scott Ferris <sferris AT isilon.com>, jhibbits@
Reviewed by: bdrewery@, markj@, and non-committer FreeBSD contributor Anton Rang
Sponsored by: Dell EMC Isilon

show more ...


Revision tags: release/11.2.0
# e4b58dfe 14-Jun-2018 Kenneth D. Merry <ken@FreeBSD.org>

Fix da(4) locking when probing SMR drives.

Probing host aware and host managed SMR drives got broken in revision
330796.

The added cam_periph_lock() calls were in areas in dadone() where
the periph

Fix da(4) locking when probing SMR drives.

Probing host aware and host managed SMR drives got broken in revision
330796.

The added cam_periph_lock() calls were in areas in dadone() where
the peripheral lock was already held.

Since then, dadone() has been split into separate functions that are
dedicated to each probe state.

The result is that when probing a host aware drive, I ran into a recursive
lock acquisition in dadone_probeatalogdir(). I would have run into the
same problem in dadone_probeataiddir(), and in dadone_probeatasup() and
dadone_probeatazone() in the error paths had the probe continued.

The solution is to take out all of the extra cam_periph_lock() calls. I
also added cam_periph_assert(periph, MA_OWNED) near the top of each of
the dadone_* calls. These make it clear to anyone coming along in the
the future that the lock is held in the probe done functions.

Also add a locking assert in daprobedone(), to make it clear that it must
be called with the periph lock held.

Sponsored by: Spectra Logic
Differential Revision: https://reviews.freebsd.org/D15764

show more ...


# 0eedd213 15-May-2018 Warner Losh <imp@FreeBSD.org>

Hold the reference count until the CCB is released

When a disk disappears and the periph is invalidated, any I/Os that
are pending with the controller can cause a crash when they
complete. Move to h

Hold the reference count until the CCB is released

When a disk disappears and the periph is invalidated, any I/Os that
are pending with the controller can cause a crash when they
complete. Move to holding the softc reference count taken in dastart()
until the I/O is complete rather than only until xpt_action()
returns. (This approach was suggested by Ken Merry.)

Sponsored by: Netflix
Submitted by: Chuck Silvers
Differential Revision: https://reviews.freebsd.org/D15435

show more ...


# 4899b94b 01-May-2018 Scott Long <scottl@FreeBSD.org>

Refactor dadone(). There was no useful code sharing in it; it was just
a 1500 line switch statement. Callers now specify a discrete completion
handler, though they're still welcome to track state v

Refactor dadone(). There was no useful code sharing in it; it was just
a 1500 line switch statement. Callers now specify a discrete completion
handler, though they're still welcome to track state via ccb_state.

Sponsored by: Netflix

show more ...


# eed99e75 01-May-2018 Scott Long <scottl@FreeBSD.org>

cam_periph_runccb() changed several years ago to overwrite the ccb callback
pointer. It's now unhelpful and misleading for callers to continue to set
it, so bring all callers into conformance. Ther

cam_periph_runccb() changed several years ago to overwrite the ccb callback
pointer. It's now unhelpful and misleading for callers to continue to set
it, so bring all callers into conformance. There's no real functional change,
but it makes reading the code a lot less confusing.

Sponsored by: Netflix

show more ...


# c67f3c60 13-Apr-2018 Warner Losh <imp@FreeBSD.org>

Just assert that the lock is held here, rather than taking it out and
dropping it.

Sponsored by: Netflix


# d8d4983e 06-Apr-2018 Alexander Motin <mav@FreeBSD.org>

Do not fail devices just for errors in descriptor format.

MFC after: 1 week
Sponsored by: iXsystems, Inc.


# 6a6c0d58 23-Mar-2018 Warner Losh <imp@FreeBSD.org>

Flag when we have a pending TUR. Don't schedule another one when we
have one pending. Otherwise, we can race and send two, which is
wasteful in close proximity. It can also cause the acaquire/release

Flag when we have a pending TUR. Don't schedule another one when we
have one pending. Otherwise, we can race and send two, which is
wasteful in close proximity. It can also cause the acaquire/release
count for TUR to be > 1, which is undexpected.

PR: 226510
Differential Review: https://reviews.freebsd.org/D14792

show more ...


# df4ee763 21-Mar-2018 Warner Losh <imp@FreeBSD.org>

Revert r331273: "Release the "TUR" reference when clearing the TUR work flag. We mostly"

It exposes other issues, so revert to the pervious state of known issues.


# 7b0eb8db 20-Mar-2018 Warner Losh <imp@FreeBSD.org>

Release the "TUR" reference when clearing the TUR work flag. We mostly
do this right, except when there's no BP and we do a TUR by request.
In that case, we clear the flag, but don't release the refe

Release the "TUR" reference when clearing the TUR work flag. We mostly
do this right, except when there's no BP and we do a TUR by request.
In that case, we clear the flag, but don't release the reference,
leaking the reference on rare occasion.

PR: 226510
Sponsored by: Netflix

show more ...


# 378e38c1 17-Mar-2018 Warner Losh <imp@FreeBSD.org>

Only take out the periph lock when we're modifying the flags of the
softc for an async unit attention. CAM locks, sometimes, the periph
lock and other times does not. We were taking the lock always a

Only take out the periph lock when we're modifying the flags of the
softc for an async unit attention. CAM locks, sometimes, the periph
lock and other times does not. We were taking the lock always and
running into lock recursion issues on a non-recursive lock. Now we
take it selectively. It's not clear why xpt takes the lock selectively
before calling us, though, and that's still under investigation.

Reported by: avg
PR: 226510 (same panic, differnt circumstances)
Sponsored by: Netflix

show more ...


# d38677d2 14-Mar-2018 Warner Losh <imp@FreeBSD.org>

Create a sysctl kern.cam.{,a,n}da.X.invalidate

kern.cam.{,a,n}da.X.invalidate=1 forces *daX to detach by calling
cam_periph_invalidate on the underlying periph. This is for testing
purposes only. In

Create a sysctl kern.cam.{,a,n}da.X.invalidate

kern.cam.{,a,n}da.X.invalidate=1 forces *daX to detach by calling
cam_periph_invalidate on the underlying periph. This is for testing
purposes only. Include only with options CAM_TEST_FAILURE and rename
the former [AN]DA_TEST_FAILURE, and fix nda to compile with it set.
We're using it at work to harden geom and the buffer cache to be
resilient in the face of drive failure. Today, it far too often
results in a panic. While much work was done on SIM initiated removal
for the USB thumnb drive removal work, little has been done for periph
initiated removal. This simulates what *daerror() does for some errors
nicely: we get the same panics with it that we do with failing drives.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D14581

show more ...


# af1823cd 12-Mar-2018 Warner Losh <imp@FreeBSD.org>

Tighten up periph lock to avoid some races

Make sure the periph lock is held around rmw access to softc data,
espeically flags, including work flags in iosched.
Add asserts for the periph lock where

Tighten up periph lock to avoid some races

Make sure the periph lock is held around rmw access to softc data,
espeically flags, including work flags in iosched.
Add asserts for the periph lock where it should be held.

PR: 226510
Sponsored by: Netflix
Differential Review: https://reviews.freebsd.org/D14456

show more ...


# 0028abe6 22-Feb-2018 Warner Losh <imp@FreeBSD.org>

Backout r329818, r329816 and r329815.

These aren't the commits I thought I was testing prior to
commit. Revert until I can sort out what happened and fix it.


# c5fe3ae9 22-Feb-2018 Warner Losh <imp@FreeBSD.org>

Introduce capacity flags for periphs

Introduce flags word to describe the capacities of the peripheral.
First bit will describe if the periph driver allows multiple
outstanding TRIMS to be active in

Introduce capacity flags for periphs

Introduce flags word to describe the capacities of the peripheral.
First bit will describe if the periph driver allows multiple
outstanding TRIMS to be active in a device.

Modify the I/O scheduler so that the nda driver can queue trims
for a while after the first one arrives. We'll queue until we see
a I/O scheduler tick, then we'll schedule as many TRIMs as allowed
by other factors (currently this is slocts in the NVMe controller).
This mariginally helps the read latency issues we see with reads,
but sets the stage for the nda driver to do TRIM collapsing like the
da and ada drivers do today.

Sponsored by: Netflix

show more ...


# 99e7a4ad 06-Feb-2018 Scott Long <scottl@FreeBSD.org>

Return a C errno for cam_periph_acquire().

There's no compelling reason to return a cam_status type for this
function and doing so only creates confusion with normal C
coding practices. It's technic

Return a C errno for cam_periph_acquire().

There's no compelling reason to return a cam_status type for this
function and doing so only creates confusion with normal C
coding practices. It's technically an API change, but the periph API
isn't widely used. No efffective change to operation.

Reviewed by: imp, mav, ken
Sponsored by: Netflix
Differential Revision: D14063

show more ...


# de4f4237 29-Jan-2018 Warner Losh <imp@FreeBSD.org>

Do the book-keeping on release before we release the reference. The
periph was going away on final release, and then returning and we
started dancing in free memory.

Sponsored by: Netflix


# da2f5dfb 27-Jan-2018 Scott Long <scottl@FreeBSD.org>

Finish the incomplete move of CAM_PERIPH_PRINT().

Reported by: kevans


# 15747cac 27-Jan-2018 Scott Long <scottl@FreeBSD.org>

Move CAM_PERIPH_PRINT() to cam_periph.h


12345678910>>...38