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>
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>
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
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.
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
- 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.
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.
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.
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
