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