| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
other problem.
- Hold onto splsoftcam() in the peripheral driver open routines until we
have locked the periph. This eliminates a race condition.
- Disallow opening the pass driver when securelevel > 1.
- If a user tries to open the pass driver with O_NONBLOCK set, return
EINVAL instead of ENODEV. (noticed by gibbs)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to a device failed.
In theory, the same steps that happen when we get an AC_LOST_DEVICE async
notification should have been taken when a driver fails to attach. In
practice, that wasn't the case.
This only affected the da, cd and ch drivers, but the fix affects all
peripheral drivers.
There were several possible problems:
- In the da driver, we didn't remove the peripheral's softc from the da
driver's linked list of softcs. Once the peripheral and softc got
removed, we'd get a kernel panic the next time the timeout routine
called dasendorderedtag().
- In the da, cd and possibly ch drivers, we didn't remove the
peripheral's devstat structure from the devstat queue. Once the
peripheral and softc were removed, this could cause a panic if anyone
tried to access device statistics. (one component of the linked list
wouldn't exist anymore)
- In the cd driver, we didn't take the peripheral off the changer run
queue if it was scheduled to run. In practice, it's highly unlikely,
and maybe impossible that the peripheral would have been on the
changer run queue at that stage of the probe process.
The fix is:
- Add a new peripheral callback function (the "oninvalidate" function)
that is called the first time cam_periph_invalidate() is called for a
peripheral.
- Create new foooninvalidate() routines for each peripheral driver. This
routine is always called at splsoftcam(), and contains all the stuff
that used to be in the AC_LOST_DEVICE case of the async callback
handler.
- Move the devstat cleanup call to the destructor/cleanup routines, since
some of the drivers do I/O in their close routines.
- Make sure that when we're flushing the buffer queue, we traverse it at
splbio().
- Add a check for the invalid flag in the pt driver's open routine.
Reviewed by: gibbs
|
| |
|
|
|
| |
Reviewed by: ken
Submitted by: phk
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
block descriptors enabled on mode sense commands.
Basically, we try sending a mode sense with block descriptors disabled (the
previous default), and if it fails, we try sending the mode sense with
block descriptors enabled. If that works, we note that in a runtime quirk
entry, so we don't bother disabling block descriptors again for the device.
This problem was first reported by Chris Jones <cjones@honors.montana.edu>
on one of the NetBSD lists, but I'd imagine that some FreeBSD users would
have run into it eventually as well, since our changer driver is derived
form the NetBSD changer driver.
Also, change some of the probe logic so that we do the right thing in the
case of a failure to attach.
Fix a memory leak in chgetparams().
Add a couple of inline helper functions to scsi_all.h to correctly return
the start of a mode page.
NetBSD PR: kern/6214
Reviewed by: gibbs
|
|
|
da - Direct Access Devices (disks, optical devices, SS disks)
cd - CDROM (or devices that can act like them, WORM, CD-RW, etc)
ch - Medium Changer devices.
sa - Sequential Access Devices (tape drives)
pass - Application pass-thru driver
targ - Target Mode "Processor Target" Emulator
pt - Processor Target Devices (scanners, cpus, etc.)
Submitted by: The CAM Team
|
