caused by temporary EDT allocations performed by controller drivers in
their interrupt routiens.
Reference count bus entries in the EDT in preparation for support for
dynamic controller arrival and departure.
Have children of the EDT hold references to their parents.
Correct routing of the XPT_IMMED_NOTIFY ccb type for use in
target mode applications.
Fix a few cases where the generation count for EDT data members was
not being updated when a modification occurred.
splcam() problem Noticed by: Tor Egge <tegge@FreeBSD.org>
drive has very poor write performance (1.4MB/sec vs. 12MB/sec) with anything
more than two oustanding transactions.
So, this limits the number of tagged commands to two for that drive.
Thanks to Paul van der Zwan for doing a whole lot of testing to confirm
this.
Reported by: Paul van der Zwan <paulz@trantor.xs4all.nl>
Sync rates like 4.032MHz were getting printed as 4.32MHz.
Also, add a quirk entry for the 18G Quantum Atlas III. Like most other
recent Quantum drives, it bogusly reports queue full. Thanks to Andre
Albsmeier <andre.albsmeier@mchp.siemens.de> for the Atlas III inquiry
information.
Reviewed by: gibbs
its original form. (Originally, it only applied to the CFP 2107.)
Hopefully we can come to some conclusion about which Conner drives are
broken for tagged queueing.
the CFP2107, but it appears (not surprisingly) that the 1 gig and 4 gig
versions of that drive have the same problem with tagged queueing.
Also, fix the problem reported in PR kern/9482. The XPT_DEV_MATCH case in
xptioctl() wasn't putting a proper path in the CCB before it called
xpt_action(). When CAMDEBUG is defined, and CAM_DEBUG_TRACE debugging is
turned on, the CAM_DEBUG statement at the beginning of xpt_action would end
up deferencing a NULL path pointer. That of course caused a panic.
My solution is to just stick the xpt peripheral's path in the CCB.
PR: kern/9482
Reviewed by: gibbs
'Black Hole' device uses this feature to schedule itself against any
target or lun attached to a controller that receives an unwanted request
from an initiator instead of having an instance per potential target/lun
request.
Use the wildcard entries to simplify wildcard async callback storage.
Don't announce devices twice to peripheral drivers. The devices will
be announced as soon as the AC_PATH_REGISTERED event is registered by
the peripheral driver, so no manaul push of this event is required.
Reviewed by: Kenneth Merry <ken@FreeBSD.org>
It keeps returning queue full until we have reduced the number of tagged
openings to the minimum.
So, put in a quirk entry with the same work-around. This quirk entry is
only for the 9G Atlas III, once someone comes up with inquiry information
for the 18G version of that drive, we can quirk it as well.
Submitted by: "Johan Granlund" <johan@granlund.nu>
the quirk that disables tagged queueing for those drives.
Also, silence a warning by disabling xpt_for_all_targets() and
xpt_for_all_periphs(). These two functions are not currently used, but
they should not be removed. They're part of a set of functions that
provide a way to execute a function for every {bus,target,device,periph} in
the system.
If anyone needs to use either function in the future, they can be
un-#ifdefed.
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.
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
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>
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
