| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Found by: clang
MFC after: 1 month
Notes:
svn path=/head/; revision=208997
|
|
|
|
|
|
|
|
|
|
| |
it will figure out the correct target to handle index and be able to find
things like WWPN, etc.
MFC after: 2 weeks
Notes:
svn path=/head/; revision=208895
|
|
|
|
|
|
|
|
|
|
|
|
| |
bug but we might as well be clearer.
Found with: Coverity Prevent(tm)
CID: 3981
MFC after: 2 weeks
Notes:
svn path=/head/; revision=208849
|
|
|
|
|
|
|
|
|
|
| |
Give the NIL inquiry data real values other than just plain 0x7f
in the first byte.
MFC after: 2 weeks
Notes:
svn path=/head/; revision=208809
|
|
|
|
|
|
|
|
|
|
| |
I don't know why- but it occurred to me in looking at the second sleep
is that all I want is a pause- not an actual sleep. So do that instead.
MFC after: 2 weeks
Notes:
svn path=/head/; revision=208808
|
|
|
|
|
|
|
|
|
|
| |
In at least one case, it's amazing that target mode worked at all.
Found by: Coverity.
MFC after: 2 weeks
Notes:
svn path=/head/; revision=208761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whole bus (XPT_SCAN_BUS) and a single lun on that bus (XPT_SCAN_LUN).
It's less resource comsumptive than scanning a whole bus when the
caller knows only one target has changes.
Reviewed by: scsi@
Sponsored by: Panasas
MFC after: 1 month
Notes:
svn path=/head/; revision=208582
|
|
|
|
|
|
|
|
| |
Submitted by: Ken Merry
MFC after: One week
Notes:
svn path=/head/; revision=208548
|
|
|
|
|
|
|
|
| |
X-MFC: 208542
MFC after: One Month
Notes:
svn path=/head/; revision=208543
|
|
|
|
|
|
|
|
| |
Obtained from: Ken Merry
MFC after: One Month
Notes:
svn path=/head/; revision=208542
|
|
|
|
|
|
|
|
|
|
|
| |
X-MFC: 208119
MFC after: 1 week
Sponsored By: Panasas
Pointy Hat to: Me
Noticed by: Rob
Notes:
svn path=/head/; revision=208129
|
|
|
|
|
|
|
|
|
|
| |
the zombie device timeout code and the loop down time code and the fabric
hysteresis code.
MFC after: 1 week
Sponsored By: Panasas
Notes:
svn path=/head/; revision=208119
|
|
|
|
|
|
|
|
|
| |
in order to match what the PROM built-in driver uses.
Approved by: mjacob
Notes:
svn path=/head/; revision=207579
|
|
|
|
|
|
|
| |
MFC after: 1 week
Notes:
svn path=/head/; revision=205712
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on debug output. Add a new platform function requirement to allow
for printing based upon the ITL nexus instead of the isp unit plus
channel, target and lun. This allows some printouts and error messages
from the core code to appear in the same format as the platform's
subsystem (in FreeBSD's case, CAM path).
MFC after: 1 week
Notes:
svn path=/head/; revision=205698
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
seconds. Oops.
Untangle some of the confusion about what role means when it's in the FCPARAM/SDPARAM
or isp_fc/isp_spi structures. This fixed a problem about seeing targets appear if you've
turned off autologin and find them, or rather don't, via camcontrol rescan.
MFC after: 1 month
Notes:
svn path=/head/; revision=205236
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
32 bit handles. The RIO (reduced interrupt operation) and fast posting
for the parallel SCSI cards were all 16 bit handles. Furthermore,
target mode parallel SCSI only can have 16 bit handles.
Use part of a supplied patch to switch over to using 32 bit handles.
Be a bit more conservative here and only do this for parallel SCSI
for the 12160 (Ultra3) cards. There were a lot of marginal Ultra2
cards, and, frankly, few are findable now for testing.
Fix the target handle routine to only do 16 bit handles for parallel
SCSI cards. This is okay because the upper sixteen bits of the new
32 bit handles is a sequence number to help protect against duplicate
completions. This would be very unlikely to happen with parallel
SCSI target mode, and wasn't present before, so we're no worse off
than we used to be.
While we're at it, finally split the async mailbox completion handlers
into FC and parallel SCSI functions. This makes it much cleaner and
easier to figure out what is or isn't a legal async mailbox completion
code for different card classes.
PR: kern/144250
Submitted partially by: Charles D
MFC after: 1 week
Notes:
svn path=/head/; revision=204397
|
|
|
|
|
|
|
| |
MFC after: 1 day
Notes:
svn path=/head/; revision=204384
|
|
|
|
|
|
|
|
|
|
|
|
| |
change and have isp_make_here scan the whole bus which will then scan all
luns.
I think xpt_rescan needs to be fixed, but that's a separable issue.
Suggested by: Alexander
Notes:
svn path=/head/; revision=204246
|
|
|
|
|
|
|
|
|
|
|
| |
specify a wildcard lun here.
This unbreaks disk re-arrival.
MFC after: 2 days
Notes:
svn path=/head/; revision=204231
|
|
|
|
|
|
|
|
|
|
| |
logged in.
PR: kern/144026
MFC after: 1 week
Notes:
svn path=/head/; revision=204050
|
|
|
|
| |
Notes:
svn path=/head/; revision=203478
|
|
|
|
| |
Notes:
svn path=/head/; revision=203463
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
numbers and handle types in rational way. This will better protect from
(unwittingly) dealing with stale handles/commands.
Fix the watchdog timeout code to better protect itself from mistakes.
If we run an abort on a putatively timed out command, the command
may in fact get completed, so check to make sure the command we're
timing it out is still around. If the abort succeeds, btw, the command
should get returned via a different path.
Notes:
svn path=/head/; revision=203444
|
|
|
|
|
|
|
|
|
| |
for years. Bad!
MFC after: 1 week
Notes:
svn path=/head/; revision=202418
|
|
|
|
|
|
|
|
| |
Submitted by: Marc Balmer <marc@msys.ch>
MFC after: 1 week
Notes:
svn path=/head/; revision=201758
|
|
|
|
|
|
|
| |
MFC after: 1 day
Notes:
svn path=/head/; revision=201408
|
|
|
|
|
|
|
|
|
|
| |
If the NAA is type 2, the Node WWN is the Port WWN with the 12 bits
of port (48..60) cleared. This iff a wwn fetched from NVRAM is zero.
MFC after: 1 week
Notes:
svn path=/head/; revision=201325
|
|
|
|
|
|
|
|
|
|
|
|
| |
the loop down counter, as well as other things. This was brought to my
attention with a different fix, more for RELENG_7- this one covers the
multiple channel case.
PR: 140438
MFC after: 1 month
Notes:
svn path=/head/; revision=200089
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the pieces came from Marius- correct settings for channels
and resource management. The one piece missing was that you cannot
for SBus cards replace 32 bit operations with A64 operations- not
supported.
Submitted by: marius
MFC after: 3 days
Notes:
svn path=/head/; revision=198822
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a maximum response length for FCP RSPNS IUs.
Clarify some of the FC option words for setting parameters
and try and disable automatic PRLI when in target mode- this
should correct some cases of N-port topologies with 23XX cards
where we put out an illegal PRLI (in target mode only we're
not supposed to put out a PRLI).
Notes:
svn path=/head/; revision=197373
|
|
|
|
| |
Notes:
svn path=/head/; revision=197372
|
|
|
|
|
|
|
|
|
|
|
|
| |
we at least don't panic.
We don't really support dual role mode (INITIATOR/TARGET) any more. We
should but it's broken and will take a fair amount of effort to fix
and correctly manage both initiator and target roles sharing the port
database. So, for now, disallow it.
Notes:
svn path=/head/; revision=197214
|
|
|
|
|
|
|
|
|
|
| |
otherwise Sun branded FC cards won't configure.
Reviewed by: Ken, Scott
Approved by: re
Notes:
svn path=/head/; revision=196162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
firmware loading bugs.
Target mode support has received some serious attention to make it
more usable and stable.
Some backward compatible additions to CAM have been made that make
target mode async events easier to deal with have also been put
into place.
Further refinement and better support for NP-IV (N-port Virtualization)
is now in place.
Code for release prior to RELENG_7 has been stripped away for code clarity.
Sponsored by: Copan Systems
Reviewed by: scottl, ken, jung-uk kim
Approved by: re
Notes:
svn path=/head/; revision=196008
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modularize it so that new transports can be created.
Add a transport for SATA
Add a periph+protocol layer for ATA
Add a driver for AHCI-compliant hardware.
Add a maxio field to CAM so that drivers can advertise their max
I/O capability. Modify various drivers so that they are insulated
from the value of MAXPHYS.
The new ATA/SATA code supports AHCI-compliant hardware, and will override
the classic ATA driver if it is loaded as a module at boot time or compiled
into the kernel. The stack now support NCQ (tagged queueing) for increased
performance on modern SATA drives. It also supports port multipliers.
ATA drives are accessed via 'ada' device nodes. ATAPI drives are
accessed via 'cd' device nodes. They can all be enumerated and manipulated
via camcontrol, just like SCSI drives. SCSI commands are not translated to
their ATA equivalents; ATA native commands are used throughout the entire
stack, including camcontrol. See the camcontrol manpage for further
details. Testing this code may require that you update your fstab, and
possibly modify your BIOS to enable AHCI functionality, if available.
This code is very experimental at the moment. The userland ABI/API has
changed, so applications will need to be recompiled. It may change
further in the near future. The 'ada' device name may also change as
more infrastructure is completed in this project. The goal is to
eventually put all CAM busses and devices until newbus, allowing for
interesting topology and management options.
Few functional changes will be seen with existing SCSI/SAS/FC drivers,
though the userland ABI has still changed. In the future, transports
specific modules for SAS and FC may appear in order to better support
the topologies and capabilities of these technologies.
The modularization of CAM and the addition of the ATA/SATA modules is
meant to break CAM out of the mold of being specific to SCSI, letting it
grow to be a framework for arbitrary transports and protocols. It also
allows drivers to be written to support discrete hardware without
jeopardizing the stability of non-related hardware. While only an AHCI
driver is provided now, a Silicon Image driver is also in the works.
Drivers for ICH1-4, ICH5-6, PIIX, classic IDE, and any other hardware
is possible and encouraged. Help with new transports is also encouraged.
Submitted by: scottl, mav
Approved by: re
Notes:
svn path=/head/; revision=195534
|
|
|
|
|
|
|
|
|
|
|
|
| |
adapted to MPSAFE cam(4) to a isp(4) specific callout structure.
Thanks to Florian Smeets for providing access to a machine exhibiting
this problem for debugging.
Approved by: mjacob
MFC after: 3 days
Notes:
svn path=/head/; revision=191979
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
controllers. Reading this register, for which there are indications
that it doesn't really exist, returns 0 on at least some 12160
and doing so on Sun Fire V880 causes a data access error exception.
Reported and tested by: Beat Gaetzi
Approved by: mjacob
Obtained from: OpenBSD (modulo setting isp_lvdmode)
Notes:
svn path=/head/; revision=186140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After I removed all the unit2minor()/minor2unit() calls from the kernel
yesterday, I realised calling minor() everywhere is quite confusing.
Character devices now only have the ability to store a unit number, not
a minor number. Remove the confusion by using dev2unit() everywhere.
This commit could also be considered as a bug fix. A lot of drivers call
minor(), while they should actually be calling dev2unit(). In -CURRENT
this isn't a problem, but it turns out we never had any problem reports
related to that issue in the past. I suspect not many people connect
more than 256 pieces of the same hardware.
Reviewed by: kib
Notes:
svn path=/head/; revision=183397
|
|
|
|
| |
Notes:
svn path=/head/; revision=173359
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to kproc_xxx as they actually make whole processes.
Thos makes way for us to add REAL kthread_create() and friends
that actually make theads. it turns out that most of these
calls actually end up being moved back to the thread version
when it's added. but we need to make this cosmetic change first.
I'd LOVE to do this rename in 7.0 so that we can eventually MFC the
new kthread_xxx() calls.
Notes:
svn path=/head/; revision=172836
|
|
|
|
| |
Notes:
svn path=/head/; revision=172568
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both WWNN and WWPN are 64-bit unsigned integers and they are prefixed
with "0x", which requires two more bytes each.
Submitted by: Danny Braniss (danny at cs dot huji dot ac dot il)
via Matthew Jacob (lydianconcepts at gmail dot com)
Approved by: re (bmah)
MFC after: 3 days
Notes:
svn path=/head/; revision=171997
|
|
|
|
|
|
|
|
| |
Approved by: re (kensmith)
MFC after: 3 days
Notes:
svn path=/head/; revision=171936
|
|
|
|
|
|
|
|
| |
Approved by: re (Ken)
MFC after: 3 days
Notes:
svn path=/head/; revision=171337
|
|
|
|
|
|
|
|
| |
Approved by: re (ken)
MFC after: 3 days
Notes:
svn path=/head/; revision=171336
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, we were never correctly checking for a 24XX Status Type 0
response- that cased us to fall through to evaluate status for
commands as if this were a 2100/2200/2300 Status Type 0 response.
This is *close*, but not quite the same. This has been reported
to be apparent with some wierd lun configuration problems with
some arrays. It became glaringly apparent on sparc64 where none
of the correct byte swap things were done.
Fixing this omission then caused a whole universe shifting debug
cycle of endian issues for the 2400. The manual for 24XX f/w turns
out to be wrong about the endianness of a couple of entities. The
lun and cdb fields for the type 7 request are *not* unconditionally
big endian- they happen to be opposite of whatever the endian of
the current machine type is. Same with the sense data for the
24XX type 0 response.
While we're at it investigate and resolve some NVRAM endian
issues.
Approved by: re (ken)
MFC after: 3 days
Notes:
svn path=/head/; revision=171159
|
|
|
|
|
|
|
| |
Approved by: re (ken, implicit)
Notes:
svn path=/head/; revision=171057
|
|
|
|
|
|
|
|
|
|
|
| |
put out a ispreqt2e_t structure onto the request queue- not a ispreqt2_t
structure. I forgot that the 23XX can use a t2 structure.
Approved by: re (ken, implicitly)
MFC after: 3 days
Notes:
svn path=/head/; revision=171051
|
|
|
|
|
|
|
|
|
|
|
|
| |
to put out a ispreqt3e_t structure onto the request queue-
not a ispreqt3_t structure. We weren't. This turns out only
to really matter for big endian machines.
Approved by: re (ken)
MFC after: 3 days
Notes:
svn path=/head/; revision=171028
|