int. All of its callers pass in cmd as a u_long, so this has
always been a dangerous type demotion. It was spooted by clang/llvm
trying to do a type promotion and sign extension within
cam_periph_ioctl.
Submitted by: rdivacky
vnode interlock to protect the knote fields [1]. The locking assumes
that shared vnode lock is held, thus we get exclusive access to knote
either by exclusive vnode lock protection, or by shared vnode lock +
vnode interlock.
Do not use kl_locked() method to assert either lock ownership or the
fact that curthread does not own the lock. For shared locks, ownership
is not recorded, e.g. VOP_ISLOCKED can return LK_SHARED for the shared
lock not owned by curthread, causing false positives in kqueue subsystem
assertions about knlist lock.
Remove kl_locked method from knlist lock vector, and add two separate
assertion methods kl_assert_locked and kl_assert_unlocked, that are
supposed to use proper asserts. Change knlist_init accordingly.
Add convenience function knlist_init_mtx to reduce number of arguments
for typical knlist initialization.
Submitted by: jhb [1]
Noted by: jhb [2]
Reviewed by: jhb
Tested by: rnoland
The device index number stored in the unit number of sa(4) devices is
only used to print debug messages. Get rid of this index number and use
devtoname() to just print the entire device name.
a serial number, fall through to the next case so that initial negotiation
still happens. Without this, devices were showing up with only 1 available
tag opening, leading to observations of very poor I/O performance.
This should fix problems reported with VMWare Fusion and ESX. Early
generation MPT-SAS controllers with SATA disks might also be affected.
HP CISS controllers are also likely affected, as are many other
pseudo-scsi disk subsystems.
things around so the periph destructors look alike. Based on a patch
by Jaakko Heinonen.
Submitted by: Jaakko Heinonen
Reviewed by: scottl
Approved by: rwatson (mentor)
Sponsored by: FreeBSD Foundation
created by atapicam is being kept opened or mounted. This is probably just
a temporary solution until we invent something better.
Reviewed by: scottl
Approved by: rwatson (mentor)
Sponsored by: FreeBSD Foundation
Reported by: Jaakko Heinonen
This fixes problems with discovering some USB devices that are very slow to
respond during initialisation.
When a USB device is inserted, CAM performs the sequence:
1) INQUIRY
2) INQUIRY (second time with other parameters)
3) TEST UNIT READY
4) READ CAPACITY
Before this change CAM didn't check if TEST UNIT READY was successful and went
on blindly to the next state and sent READ CAPACITY. If the device was still
not ready by then, CAM ended with error message. This patch adds checking for the
status of TEST UNIT READY command and retrying up to 10 times with 0.5 sec
interval.
Submitted by: Grzegorz Bernacki gjb ! semihalf dot com
Reviewed by: scottl
When trying to read scratched or damaged CDs and DVDs, the default
mechanism is sub-optimal. Programs like ddrescue do much better if
you turn off retries entirely, since their algorithms are designed
scan big areas fast, then winnow the areas down. Turning off retries
speeds these programs up by as much as 20x, since the drive is able to
'stream past' many small errors...
The sysctl/tunable kern.cam.cd.retry_count controls this. That
defaults to '4' (for a total of 5 attempts). Setting to 0 turns off
all retry attempts.
Reviewed by: scottl@
does - in DragonFly, it's cam_sim_release() what actually frees the
SIM; cam_sim_free does nothing more than calling cam_sim_release().
Here, we drain in cam_sim_free, waiting for refcount to drop to zero.
We cannot do the same think DragonFly does, because after cam_sim_free
returns, client would destroy the sim->mtx, and CAM would trip over
an initialized mutex.
Reviewed by: scottl
Approved by: rwatson (mentor)
Sponsored by: FreeBSD Foundation
to actually use it would panic on mtx operation, as dead_sim doesn't
have a proper mutex. Even if it had a properly initialized mutex,
it wouldn't have properly locked and owned one.
Reviewed by: scottl
Approved by: rwatson (mentor)
Sponsored by: FreeBSD Foundation
After I removed all the unit2minor()/minor2unit() calls from the kernel
yesterday, I realised calling minor() everywhere is quite confusing.
Character devices now only have the ability to store a unit number, not
a minor number. Remove the confusion by using dev2unit() everywhere.
This commit could also be considered as a bug fix. A lot of drivers call
minor(), while they should actually be calling dev2unit(). In -CURRENT
this isn't a problem, but it turns out we never had any problem reports
related to that issue in the past. I suspect not many people connect
more than 256 pieces of the same hardware.
Reviewed by: kib
When I changed kern_conf.c three months ago I made device unit numbers
equal to (unneeded) device minor numbers. We used to require
bitshifting, because there were eight bits in the middle that were
reserved for a device major number. Not very long after I turned
dev2unit(), minor(), unit2minor() and minor2unit() into macro's.
The unit2minor() and minor2unit() macro's were no-ops.
We'd better not remove these four macro's from the kernel, because there
is a lot of (external) code that may still depend on them. For now it's
harmless to remove all invocations of unit2minor() and minor2unit().
Reviewed by: kib
because the media was removed, the periph would get its refcount dropped
and ultimately freed before getting unlocked. This created a dangling
pointer that was easy to trip over. This fixes a common source of
crashes with removaable media, but problems remain and will get tracked
down.
http://www.t10.org/lists/1spc-lst.htm
Note opcodes for scanner and communication devices are taken from the previous
revision because they are not listed in the files any more.
Also, note newly added ASCs are all marked with 'XXX TBD' and take SS_RDEF action
for now. Some ASCs need SS_TUR for error recovery or SS_FATAL to prevent further
retrials. We should deal with them later.
Reviewed by: scottl, ken
