use to synchornize and protect all data objects that are used for that
SIM. Drivers that are not yet MPSAFE register Giant and operate as
usual. RIght now, no drivers are MPSAFE, though a few will be changed
in the coming week as this work settles down.
The driver API has changed, so all CAM drivers will need to be recompiled.
The userland API has not changed, so tools like camcontrol do not need to
be recompiled.
Linux SCSI SG passthrough device API. The intention is to allow for both
running of Linux apps that want to talk to /dev/sg* nodes, and to facilitate
porting of apps from Linux to FreeBSD. As such, both native and linuxolator
entry points and definitions are provided.
Caveats:
- This does not support the procfs and sysfs nodes that the Linux SG
driver provides. Some Linux apps may rely on these for operation,
others may only use them for informational purposes.
- More ioctls need to be implemented.
- Linux uses a naming scheme of "sg[a-z]" for devices, while FreeBSD uses a
scheme of "sg[0-9]". Devfs aliasis (symlinks) are automatically created
to link the two together. However, tools like camcontrol only see the
native names.
- Some operations were originally designed to return byte counts or other
data directly as the syscall return value. The linuxolator doesn't appear
to support this well, so this driver just punts for these cases.
Now that the driver is in place, others are welcome to add missing
functionality. Thanks to Roman Divacky for pushing this work along.
rescan requests. The purpose of this is to allow a SIM
(or other entities) to request a bus rescan and have it
then fielded in a different (process) context from the
caller.
There are probably better ways to accomplish this, but
it's a very small change that helps solve a number of
problems.
Reviewed by: Justin, Ken and Scott.
MFC after: 2 weeks
flash card reader.
Also remove an 'Opened da0 -> <random number>' which is not needed on a daily
basis (available through bootverbose).
Reviewed by: phk, ken
MFC after: 1 week
author can't remember why it was there.
The CTS_SCSI_FLAGS_TAG_ENB remains in place, and makes sense, and is
checked all over the place.
The CTS_SPI_FLAGS_TAG_ENB was probably an attempt to distinguish
protocol and transport tag capabilities. At the very least this can
be confusing and prone to many bugs, so let's just assume that the
transport tag case just flows from the protocol (and vice versa)
for now.
the ORDERED tag. This recoups significant performance gains for many
arrays.
The default is still to send out the ORDERED tag periodically.
Reviewed by: scsi (justin+timeout)
the CAM_NEW_TRAN_CODE that has been in the tree for some years now.
This first step consists solely of adding to or correcting
CAM_NEW_TRAN_CODE pieces in the kernel source tree such
that a both a GENERIC (at least on i386) and a LINT build
with CAM_NEW_TRAN_CODE as an option will compile correctly
and run (at least with some the h/w I have).
After a short settle time, the other pieces (making
CAM_NEW_TRAN_CODE the default and updating libcam
and camcontrol) will be brought in.
This will be an incompatible change in that the size of structures
related to XPT_PATH_INQ and XPT_{GET,SET}_TRAN_SETTINGS change
in both size and content. However, basic system operation and
basic system utilities work well enough with this change.
Reviewed by: freebsd-scsi and specific stakeholders
and CAM_RESRC_UNAVAIL returns. Delay a tunable amount for
either between retries.
This came up because the MPT IOC was returning "IOC out of
resources" for some user and this caused a CAM_RESRC_UNAVAIL
return. Putting a bit of delay between retries helped them
out.
There was some discussion that an async event should be used
to clear CAM_RESRC_UNAVAIL. That's probably a better notion
eventually.
Reviewed by: scsi@freebsd.org (ade, scott)
MFC after: 1 week
REPORT LUNS command to a device.
camcontrol.[c8]: Implement reportluns. This tries to print the LUNs
out in a reasonable format. Only the periph
addressing method has been tested, since very little
hardware that I know of supports the other methods.
scsi_all.[ch]: Revamp the report luns CDB structure and helper
functions. This constitutes a little bit of an API
change, but since the old CDB length was 10 bytes,
and the REPORT LUNS CDB length is actually 12 bytes,
it's clear that no one was using this API in the
first place.
MFC After: 1 week
what to do with it.
This forces us to scan targets sequentially, not in parallel.
The reason we might want to do this is that SPI negotiation
might not work right at the SIM level if we try to do it
in parallel. We *could* fix this for each SIM where this is
broken, but it's a lot harder to do that when we can simply
ask CAM to probe sequentially.
If PIM_SEQSCAN is not set (default), the original behaviour for
probing is unchanged.
LUN probing is still done in parallel for each target in either
case.
While we're at it, clean up some resource leakage for error
cases.
Reviewed by: ken, scott, scsi@
MFC after: 1 week
usage as of SPC2r20. Specifically, handle the BQueue
flag which will indicate that a device supports the
Basic Queueing model (no Head of Queue or Ordered tags).
When this flag is set, SID_CmdQueue is clear. This has
causes FreeBSD to assume that the device did not support
tagged operations.
MFC after: 1 month
This version of scsi_target.c removes all SMP locking until
we have a lock-aware CAM stack. This allows us to use KNOTE
without a panic at least.
It's not yet clear whether target mode is working yet or not.
Discussed with: Scott, Ken, Nate, Justin
return to user space w/o waiting for I/O to complete.
I tried to get several folks who know this code better than me to review it
with no luck. I *do* know that w/o this code, using the SCSI target driver
panics in userret (if it doesn't panic in knote first).
an application to upon a tape (yea, even the non-control device) even if
it cannot establish a mount session. If the open cannot establish a mount
session and O_NONBLOCK was specified, the tape becomes 'open pending mount'.
All I/O operations that would require access to a tape thereafter until
a close attempt to initiate the mount session. If the mount session succeeds,
the tape driver transitions to full open state, else returns an appropriate
I/O error (ENXIO).
At the same time, add a change that remembers whether tape is being opened
read-only. If so, disallow 'write' operations like writing filemarks that
bypass the normal read-only filtering operations that happen in the write(2)
syscall.
Reviewed by: ken, justin, grog
MFC after: 2 weeks
Suggested by: The Bacula Team
operations before returning. Point the bus at a dummy cam_sim
structure so that any CCBs will complete immediately with a
CAM_DEV_NOT_THERE status, and ensure that any xpt_schedule() calls
on the bus's devices will immediately call the peripheral's
periph_start() routine. Also repeat the async messages because
devices that were part of the way through being probed may appear
after the original AC_LOST_DEVICE was sent, and would otherwise
never go away.
These changes make it possible to deregister a bus and free the SIM
at most stages during bus probing without the usual crashes in
camisr(). In particular, plugging in a umass device and then
unplugging it as soon as the first probe messages appeared would
almost always result in a crash. Now the device just goes away with
a few CAM errors and all references to the CAM bus, target and
device are dropped correctly.
CAM_LUN_INVALID or CAM_TID_INVALID. Retries were being triggered
here when a umass device was unplugged, and while the retries
themselves are probably harmless, they complicated finding the real
SIM removal problems.
the underlying drive had been hot-unplugged from the system. Here
is a specific example. Filesystem code had opened /dev/da1s1e.
Subsequently, the drive was hot-unplugged. This (correctly) caused
all of the associated /dev/da1* entries to be deleted. When the
filesystem later realized that the drive was gone it closed the
device, reducing the write-access counts to 0 on the geom providers
for da1s1e, da1s1, and da1. This caused geom to re-taste the
providers, resulting in the devices being created again. When the
drive was hot-plugged back in, it resulted in duplicate /dev entries
for da1s1e, da1s1, and da1.
This fix adds a new disk_gone() function which is called by CAM when a
drive goes away. It orphans all of the providers associated with the
drive, setting an error condition of ENXIO in each one. In addition,
we prevent a re-taste on last close for writing if an error condition
has been set in the provider.
Sponsored by: Isilon Systems
Reviewed by: phk
MFC after: 1 week
tunable (until we get REPORT LUNS in place).
If we're probing luns, and each probe succeeds, we keep going past
lun 7 if we're a SCSI3 or better device (until we fail to probe).
If we're probing luns, and a probe fails, we only keep going if
we're quirked *for* it (CAM_QUIRK_HILUNS), and if we're not quirked
*against* it (CAM_QUIRK_NOHILUNS), or we're a SCSI3 or better device
and the tunable (kern.cam.cam_srch_hi) is set non-zero.
Reviewed by: nate@rootlabs.org, gibbs@scsiguy.com, ken@kdm.com, scottl@samsco.org
MFC after: 1 week
event handler, dev_clone, which accepts a credential argument.
Implementors of the event can ignore it if they're not interested,
and most do. This avoids having multiple event handler types and
fall-back/precedence logic in devfs.
This changes the kernel API for /dev cloning, and may affect third
party packages containg cloning kernel modules.
Requested by: phk
MFC after: 3 days
- Introducing the possibility of using locks different than mutexes
for the knlist locking. In order to do this, we add three arguments to
knlist_init() to specify the functions to use to lock, unlock and
check if the lock is owned. If these arguments are NULL, we assume
mtx_lock, mtx_unlock and mtx_owned, respectively.
- Using the vnode lock for the knlist locking, when doing kqueue operations
on a vnode. This way, we don't have to lock the vnode while holding a
mutex, in filt_vfsread.
Reviewed by: jmg
Approved by: re (scottl), scottl (mentor override)
Pointyhat to: ssouhlal
Will be happy: everyone
module-specific malloc types. These should help us to pinpoint the
possible memory leakage in the future.
- Implementing xpt_alloc_ccb_nowait() and replacing all malloc/free based
CCB memory management with xpt_alloc_ccb[_nowait]/xpt_free_ccb. Hopefully
this would be helpful if someday we move the CCB allocator to use UMA
instead of malloc().
Encouraged by: jeffr, rwatson
Reviewed by: gibbs, scottl
Approved by: re (scottl)
(depends on how many memory you have) observed through "tar -tvf /dev/sa0."
Without this patch, RELENG_5 and HEAD panics with something like:
kmem_malloc(4096): kmem_map too small: 42258432 total allocated
RELENG_4 doesn't panic but spews following errors:
camq_init: - cannot malloc array!
Reviewed by: gibbs, scottl
Approved by: re (scottl)
MFC after: 3 days
period value. I suppose the BT adapter driver should be
fixed, but more importantly we should protect against
dividing by zero.
PR: kern/75603
MFC after: 1 week
succeed if there was no media in the drive.
This was broken in rev 1.72 when the media check was added to cdioctl().
For now, check the ioctl group to decide whether to check for media or not.
(We only need to check for media on CD-specific ioctls.)
Reported by: bland
MFC after: 3 days
disables tag queuing temporarily in order to allow controllers a window
to safely perform transfer negotiation with non-compliant devices. Before
this change, CAM would restore the queue depth to the controller specified
maximum or device quirk level rather than any depth determined by reactions
to QUEUE FULL/BUSY events or an explicit user setting.
During device probe, initialize the flags field for XPT_SCAN_BUS.
The uninitialized value often confused CAM into not bothering to
issue an AC_FOUND_DEVICE async event for new devices. The reason
this bug wasn't reported earlier is that CAM manually announces
devices after the initial system bus scans.
MFC: 3 days
