will) get set for the devices that don't actually support
reserve/release (so we don't keep trying it).
Add softc storage and manage storing last I/O and CTL
commands that had errors (for correlative purposes).
In saclose clear the 'MOUNTED' bit if we either rewind or
unload (yes, this shouldn't be necessary since the next open
should catch whether a tape change occurred, but I'm having
some questions about that actually working so this is
safer for the moment). Oh, forgot to mention in previous
commit messages that some of the failures particularly at
close time cause the tape to be ejected (for the sake
of safety)- all this prior to redoing the state machine
(which is in progress) which will try and handle this better.
Complete the addition of the setmark support
(from Martin.Birgmeier@aon.at).
written even it the tape was opened readonly- 2 botches in deferred error
handling for FIXED LENGTH mode which caused panic && hand resp.). Fixed
a memory leak in sa_mount.
2) Fixed an annoying bug when turning of compression to actually reflect
this for future status calls.
3) Implement the MTIOCERRSTAT call where latched control and I/O residuals
and sense data are returned to the application asking for them.
Attempt to determine (at mount time if not done so already) via density code
whether a device should default to fixed mode or not. Attempts to set to
variable that fail will cause fixed to be selected.
Similarly, the '2 filemarks at EOM' quirk is now determined (or attempted to
be determined) via density code. Some as yet not entirely tested code for
coping with 2FM@EOD position is now also in place.
aborted prior to disabling our lun. This requires a second set of
links since we use the ones in the ccb_hdr during normal operations.
Nuke some unused variables.
and out of kernel address space (via the pass(4) and xpt(4) peripheral
drivers) to 64K (DFLTPHYS). Some controllers, like the Adaptec 1542,
don't support more than 64K transactions.
We plan on eventually having the capability of limiting this size based
on min(MAXPHYS, controller max), but since that capability isn't here yet,
limit things to the lowest common denominator.
reporting since this past summer. (I think Daniel O'Conner was the first.)
The problem appears to have been something like this:
- cdda2wav by default passes in a buffer that is close to the 128K MAXPHYS
limit.
- many times, the buffer is not page aligned
- vmapbuf() truncates the address, so that it is page aligned
- that causes the total size of the buffer to be greater than MAXPHYS,
which of course is a bad thing.
Here's a quote from the PR (kern/9067):
==================
In particular, note bp->b_bufsize = 0x0001f950 and bp->b_data = 0xf2219960
(which does not start on a page boundary). vunmapbuf() loops through all
the pages without any difficulty until addr reaches 0xf2239000, and then
the panic occurs. This seems to indicate that we are exceeding MAXPHYS
since we actually started from the middle of a page (the data is being
transfered to a non page aligned location).
To complete the description, note that the system call originates from
ReadCddaMMC12() (in scsi_cmds.c of cdda2wav) with a request to read 55
audio sectors of 2352 bytes (which is calculated to fall under MAXPHYS).
This in turn ends up calling scsi_send() (in scsi-bsd.c) which calls
cam_fill_csio() and cam_send_ccb(). This results in a CAMIOCOMMAND ioctl
with a ccb function code of XPT_SCSI_IO.
==================
The fix is to change the size check in cam_periph_mapmem() so that it is
like the one in minphys(). In particular, it is something like:
if ((buffer_length + (buf_ptr & PAGE_MASK)) > MAXPHYS)
buffer is too big
My fix is based on the one in the PR, but I cleaned up a fair number of
things in cam_periph_mapmem(). The checks for each buffer to be mapped
are now in a separate loop from the actual mapping operation. With the new
arrangement, we don't have to bother with unmapping any previously mapped
buffers if one of the checks fails.
Many thanks to James Liu for tracking this down. I'd appreciate it if some
vm-savvy folks would look this over. I believe this fix is correct, but I
could be wrong.
PR: kern/9067 (also, kern/8112)
Reviewed by: gibbs
Submitted by: "James T. Liu" <jtliu@phlebas.rockefeller.edu>
level so they can be reclaimed before attempting to disable our lun.
Correctly free descriptors. Add periph locking and spl protection
around open and close.
incorporate some notion of which revision the device is. If it's < SCSI2, for
example, READ BLOCK LIMITS is not a MANDATORY command.
At any rate, the initial state is to try and read block limits to get a notion
of the smallest and largest record size as well as the granularity. However,
this doesn't mean that the device should actually *in* fixed block mode should
the max && min be equal... *That* choice is (for now) determined by whether
the device comes up with a blocksize of nonzero. If so, then it's a fixed block
preferred device, otherwise not (this will change again soon).
When actually doing I/O, and you're in fixed length mode, the block count is
*not* the byte count divided by the minimum block size- it's the byte count
divided by the current blocksize (or use shift/mask shortcuts if that worked
out...).
Then when you *change* the blocksize via an ioctl, make sure this actually
propagates to the stored notion of blocksize (and update the shift/mask
shortcuts).
Misc Other:
When doing a mode select, only use the SCSI_SAME_DENSITY (0x7f) code if
the device is >= SCSI2- otherwise just use the saved density code.
Recover from the ripple of ILLEGAL REQUEST not being 'retried' in that
RESERVE/RELEASE is not a mandatory command for < SCSI2 (so ignore it if it
fails).
Allow sync transfers if the controller supports it. Wide will follow
as soon as I get the kinks worked out of wide target transfers in the
aic7xxx driver (currently the only target mode driver in the tree).
to specify that it does not provide initiator services (PIM_NOINITIATOR)
and that the initial bus reset for device probing should be avoided
(PIM_NOBUSRESET).
Modify the XPT layer to honor these flags.
for possible buffer overflow problems. Replaced most sprintf()'s
with snprintf(); for others cases, added terminating NUL bytes where
appropriate, replaced constants like "16" with sizeof(), etc.
These changes include several bug fixes, but most changes are for
maintainability's sake. Any instance where it wasn't "immediately
obvious" that a buffer overflow could not occur was made safer.
Reviewed by: Bruce Evans <bde@zeta.org.au>
Reviewed by: Matthew Dillon <dillon@apollo.backplane.com>
Reviewed by: Mike Spengler <mks@networkcs.com>
not like the 6-byte read and write commands! It returns illegal request,
with the field pointer pointing to byte 9 of a 6 byte CDB.
In any case, the work around is to put in a quirk mechanism that makes sure
that we don't send 6-byte reads or writes to this device. It's rather sad
that this is necessary. You'd think that they would be able to get
something that basic to work right in their firmware...
Reviewed by: gibbs
Reported by: Adam McDougall <bsdx@spawnet.com>
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)
drives. It seems that quite a few (possibly all?) of their drives respond
to inquiries on multiple luns. Hopefully we can detect problems like this
in the probe phase at some point. For now, this is a pretty functional
solution.
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
currently operating in a tagged mode. The SIM driver should determine
if a device is in tag mode by looking at the CAM_TAG_ACTION_VALID flag
in the ccb header. If the flag is set, the tag_action field is either
a SCSI II tag message (simple, ordered, head) or CAM_TAG_ACTION_NONE
to specify that no tagging should be performed.
tested both in the kernel and in userland. Also, fix a couple of printf
warnings that show up when CAMDEBUG is defined.
Reviewed by: imp
Partially submitted by: imp
hung up when you send tags to them too quickly. (CAM is able to recover
from the problem, but this just avoids it altogether.)
Reviewed by: gibbs
Reported by: Bret Ford <bford@uop.cs.uop.edu>
and: Martin Renters <martin@tdc.on.ca>
one error recovery action oustanding for a given peripheral.
This is bad for several reasons. The first problem is that the error
recovery actions would likely be to fix the same problem. (e.g., we
queue 5 CCBs to a disk, and the first one comes back with 0x04,0x02. We
start error recovery, and the second one comes back with the same status.
Then the third one comes back, and so on. Each one causes the drive to get
nailed with a start unit, when we really only need one.)
The other problem is that we only have space to store one CCB while we're
doing error recovery. The subsequent error recovery actions that got
started were over-writing the CCBs from previous error recovery actions,
but we still tried to call the done routine N times for N error recovery
actions. Each call to dadone() was done with the same CCB, though. So on
the second one, we got a "biodone: buffer not busy" panic, since the buffer
in question had already been through biodone().
In any case, this fixes things so that any any given time, there's only one
error recovery action outstanding for any given peripheral driver.
Reviewed by: gibbs
Reported by: Philippe Regnauld <regnauld@deepo.prosa.dk>
[ Philippe wins the "bug finder of the week" award ]
sequence of things:
- spin up a disk
- send an async event to refresh the inquiry data
- run through xpt_scan_lun() to re-probe the device
- eventually finish the probe, but panic in xpt_done() because the
periph pointer wasn't set.
Reviewed by: gibbs
Reported by: Philippe Regnauld <regnauld@deepo.prosa.dk>
1) The vnode pager wasn't properly tracking the file size due to
"size" being page rounded in some cases and not in others.
This sometimes resulted in corrupted files. First noticed by
Terry Lambert.
Fixed by changing the "size" pager_alloc parameter to be a 64bit
byte value (as opposed to a 32bit page index) and changing the
pagers and their callers to deal with this properly.
2) Fixed a bogus type cast in round_page() and trunc_page() that
caused some 64bit offsets and sizes to be scrambled. Removing
the cast required adding casts at a few dozen callers.
There may be problems with other bogus casts in close-by
macros. A quick check seemed to indicate that those were okay,
however.
have the passthrough device configured in their kernel.
This will hopefully reduce the number of people complaining that they can't
get {camcontrol, xmcd, tosha, cdrecord, etc.} to work.
Reviewed by: gibbs
2217's (reported by Matthew Jacob in NetBSD PR kern/6027) and Fujitsu
M2954's (reported by Tom Jackson).
Some of the Fujitsus at least hang when they get a cache sync command.
(Others just return illegal request.)
Also, make error printing in dashutdown() a little more selective. Don't
print any error when the sense key is illegal request. Drives that don't
support the synchronize cache command usually return illegal request.
Also, make sure the scsi status is check condition before going into
scsi_sense_print().
Reviewed by: gibbs
command on drives that don't like it. Right now, there's just a bogus
quirk entry in the table that doesn't do anything, but that should be
changed once we get actual inquiry data for drives that don't like the
synchronize cache command.
Also, add a shutdown hook that runs through all direct access peripherals
and runs a synchronize cache on them if they're still open, and if
synchronize cache isn't disabled via a quirk entry.
Add a synchronize cache call at the end of dadump() (again, conditionalized
on the quirk entry), so we can insure that the disk cache contents get
flushed to physical media after a dump.
Check the new quirk entry in daclose() to decide whether or not to
synchronize the cache for a disk at final close.
Reviewed by: gibbs
tagged queuing support.
Ensure that we report that a device supports tagged queuing even if
the system is waiting a "command count delay" before starting to use
them.
If a user disables disconnects on a device ensure that tagged queuing
is also turned off. We did the right thing during initial configuration,
but could be confused by manual changes.
JAZ drive happy. This shouldn't impact fast drives, and will keep cam
from failing on very slow ones (that are spinning up, say). 20
seconds was almost long enough, but not in all cases.
Suggested by: gibbs
well) Among them:
[ cd driver ]
1. Old labeling code was still there.
2. Error handling for dsopen() was broken (no test for the `error'
returned by dsopen(); bogus test of an `error' that is known to be 0).
3. cdopen() closed the physical device after certain errors although there
may still be open partitions on it.
4. cdclose() closed the physical device although there may still be open
partitions on it.
5. Some printf format fixes was incomplete or missing.
6. cdioctl() truncated unit numbers mod 256.
7. cdioctl() was missing locking.
[ da driver ]
1. daclose() closed the physical device although there may still be open
partitions on it. This was fixed many years ago in sd.c rev.1.57.
2. A minor optimization (the dk_slices != NULL test) in sdopen() became
uglier in daopen(). It is not worth doing. da only regressed compared
with od and my version of sd, since I never committed the change to sd.
daopen() should probably do less if some partition is already open.
This is not addressed by the diffs.
[ ... ]
5. "opt_hw_wdog.h" was not included, so the HW_WDOG code was unreachable.
- Added a getdev CCB call in the cdopen() and daopen() calls so that the
vendor name and device name are available for the disklabel. (suggested
by bde)
- Removed vestigal devfs support in both drivers, since we can't properly
work with devfs yet. (ask bde for details on this)
- Cleaned up the probe code in both drivers in the failure cases. There
were a number of things wrong here. The peripheral driver instances
weren't getting properly cleaned up. Sometimes the wrong probe message
would get printed out (with the failure message appended), so it wasn't
very clear that we failed to attach. SCSI sense information was printed,
even when the error in question wasn't a SCSI error. I put similar fixes
into the changer driver in revision 1.2 of scsi_ch.c.
Reviewed by: gibbs
Submitted by: bde (partially)
print out a one line description/dump of every SCSI CDB sent to a
particular debugging target or targets.
This is a good bit more useful than the other debugging modes, I think.
Change some things in LINT to note the availability of this new option.
Fix an erroneous argument to scsi_cdb_string() in scsi_all.c
Reviewed by: gibbs
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
timeouts in the SA driver (timeouts for space, rewind and erase). Folks
can lengthen the timeouts if their hardware is especially slow, or shorten
them if they want to be notified of errors a little sooner.
Also, get rid of two OD driver options. The od driver has been made
obsolete by the da driver.
Reviewed by: ken, gibbs
Submitted by: Dag-Erling Coidan Smørgrav <des@FreeBSD.ORG>
- Tagged devices were limited to one transaction (oops)
- We revert to untagged with a tag delay if the user changed the
transfer negotiation values (via perhaps camcontrol some day).
- xpt_async did not use the expanded path in some cases which could
cause a panic.
already allowed medium not present type errors (0x3a), but some Philips and
HP WORM drives return 0x04,0x00 when you issue a read capacity without
media in the drive.
enabling transfer negotiations, a BDR, or a bus reset to allow the controller
driver to negotiate without tagged messages getting in the way. Some
devices are confused by attempts to negotiate and tag at the same time.
Some controllers (e.g. BT MultiMaster with certain firmware revs) will
never negotiate if you don't give them an untagged "window" to perform
negotiation in.
Bump the maximum tag count to 255. The system reclaims unused tag space
as the tag count is dropped anyway, so we might as well try the max.
We should probably use a larger type than u_int8_t to hold our tag value
as SCSI over certain mediums allows for higher values.
Reviewed by: Kenneth Merry <ken@FreeBSD.org>
Western Digital Enterprise drives have sorry performance (1.5MB/sec versus
8MB/sec) when doing tagged queueing. Disable tagged queueing for them.
Submitted by: Andrew Gallatin <gallatin@cs.duke.edu>
Some Sony CDROM drives don't like it when we probe more than one LUN.
Verified by: Jean-Marc Zucconi <jmz@FreeBSD.ORG>
Some Sony CD-R's don't like multi-LUN probing either.
Submitted by: Parag Patel <parag@cgt.com>
Clear up trailing NULs in cam_strvis.
cam_xpt.c:
Nuke an experimental quirk entry for the Toshiba 3401. The real
problem with this device turned out to be a bug in the aic7xxx
driver that was fixed months ago.
Add a quirk entry to inhibit multiple lun scanning and serial number
probing of DPT RAID volumes. My DPT controller hangs up solid when
I do either of these things to a RAID 1 volume.
flags on some of the operations in the driver weren't quite right. Also,
clean up scsi_cd.h, change u_char to u_int8_t.
I'm surprised this problem didn't show up sooner. (the code has been in
there almost a year and a half)
PR: 7996
Reviewed by: ken
Submitted (mostly) by: gibbs
a perfect world, we'd notice the UA and do some device validation to ensure
that the device hasn't changed. We may get this before the year ends,
but not before 3.0R. This change gives the adminstrator ample ammunition
to take off a foot or two, but hey this *is* UN*X.
Add quirk entry for a Samsung drive that doesn't like experiencing
the queue full condition.
Bump the timeouts for all probe activities to 60s. We don't know
what the seletion timeout (or equivelent on other mediums) is
for controllers, which can make the transactions at the tail
end of a parallel probe take a while to complete. The DPT
seems to be a card that takes a long time to see a selection timeout.
cam_periph.c:
Don't call a device "gone" after a single selection timeout. We
need to come up with a better policy. Until that time, you'll
have to manually re-scan a bus via camcontrol for the system to
decide that a device is really gone. This should give devices
experiencing temporary insanity to escape death.
wasn't getting sent back for most errors, even if there were retries left
on the command. I'm not sure how I ever let this slip by before...
In any case, we now send back ERESTART if there are retries left for the
command, and send back the default error code when there are no retries
left.
Reviewed by: gibbs
without the DA driver.
The problem was that the CD driver depended on scsi_read_write() and
scsi_start_stop(), which were defined in scsi_da.c.
I moved both functions, and their associated data structures and defines
from scsi_da.* to scsi_all.*. This is technically the "wrong" thing to do
since those commands are really only for direct-access type devices, not
for all SCSI devices. I think, though, that the advantage (allowing people
to compile kernels without the disk driver) outweighs any architectural
purity arguments.
PR: kern/7969
Reviewed by: gibbs
Fix a problem reported by bde: setting SCSI_DELAY to 0 doesn't work. Now,
when the user sets SCSI_DELAY to 0, we re-set it to the minimum allowable
bus settle delay (100ms).
Fix a potential panic in xptfinishconfigfunc() if the CCB passed in is
NULL. Reported by, I think, Nicolas Souchu. Fix a memory leak in the same
function (we created a path, but didn't free it) by allocating the getdev
CCB and path on the stack.
Reviewed by: gibbs
only. Previously, if the device was chmoded 644, someone could open it
with the O_RDONLY flag and issue any ioctl to the device.
Reviewed by: imp, gibbs
