| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
products, based on discussion with Adaptec.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[1] Add the support for the NARK controller which seems a variant of
the i960Rx.
[2] Split up memory regions and other resources in 2 different parts
as long as NARK uses them separately (it is not clear to me
why though as long as there are no more informations available
on this controller). Please note that in all the other cases,
the regions overlaps leaving the default behaviour for all the
other controllers.
[3] Implement a clock daemon responsible for maintain updated the
wall clock time of the controller (run any 30 minutes)*.
Submitted by: Adaptec (driver build 15317 [1, 2] and 15727 [3])
Reviewed by: emaste
Tested by: emaste
Sponsored by: Sandvine Incorporated
* Please note that originally, in the Adaptec driver, the clock daemon
is not implemented with callouts as in our in-tree driver.
|
|
|
|
| |
Submitted by: jkim
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Adaptec RAID 2045
Adaptec RAID 2405
Adaptec RAID 2445
Adaptec RAID 2805
Without this change these devices are supported by the driver's family
support, but they then appear as "Adaptec RAID Controller" in boot
messages and the dev.aac.0.%desc sysctl.
|
|
|
|
|
|
|
| |
change in debugging routines.
The fwprintf macro in the AAC_DEBUG case (mapping to printf) isn't from the
Adaptec driver.
|
|
|
|
|
|
| |
share the same interface.
Submitted by: Achim Leubner at Adaptec
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Daniel Kamm.
Adaptec RAID 51245
Adaptec RAID 51645
Adaptec RAID 52445
Adaptec RAID 5405
Sun STK RAID REM
Sun STK RAID EM
SG-XPCIESAS-R-IN
SG-XPCIESAS-R-EX
|
|
|
|
|
|
|
|
|
| |
AOC-USAS-S4i
AOC-USAS-S8i
AOC-USAS-S4iR
AOC-USAS-S8iR
AOC-USAS-S8i-LP
AOC-USAS-S8iR-LP
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adaptec RAID 3085
Adaptec RAID 31205
Adaptec RAID 31605
Adaptec RAID 5085
Adaptec RAID 51205
Adaptec RAID 51605
Adaptec RAID 5445
Adaptec RAID 5805
IBM ServeRAID 8s
ICP RAID ICP5045BL
ICP RAID ICP5085BL
ICP RAID ICP5085SL
ICP RAID ICP5125BR
ICP RAID ICP5125SL
ICP RAID ICP5165BR
ICP RAID ICP5165SL
ICP RAID ICP5445SL
ICP RAID ICP5805BL
ICP RAID ICP5805SL
ICP9067MA SATA RAID
|
|
|
|
|
|
|
|
|
| |
- Adaptec RAID 3405
- Adaptec RAID 3805
Approved by: re (bmah)
Submitted by: John Marra jmarra at nmu dot edu
MFC After: 1 week
|
|
|
|
|
| |
PR: 106543
MFC after: 3 days
|
|
|
|
| |
Submitted by: Danny Braniss
|
|
|
|
|
|
|
|
| |
respective websites.
Reviewed by: scottl
Approved by: rwatson (mentor)
MFC after: 5 days
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the modified interface that they use. Changes include:
- Register a different interrupt handler for the new interface. This one is
INTR_MPSAFE, not INTR_FAST, and directly processes completions and AIFs.
- Add an event registration and callback mechanism for the ioctl and CAM
modules can know when a resource shortage clears. This condition was
previously fatal in CAM due to programming oversights.
- Fix locking to play better with newbus.
- Provide access methods for talking to cards with the NEWCOMM interface.
- Fix up the CAM module to be better suited for dealing with newer firmware
on the PERC Si/Di series that requires talking to plain SCSI via aac.
- Add a whole slew of new PCI Id's.
Thanks to Adaptec for providing an initial version of this work and for
answering countless questions about it. There are still some rough edges in
this, but it works well enough to commit and test for now.
Obtained from: Adaptec, Inc.
|
|
|
|
|
| |
MFC after: 3 days
Approved by: scottl
|
|
|
|
|
|
|
|
| |
channel devices. This should fix Dell 2450/2550/2650 systems that have RAID
enabled. This will likely not fix 2400 systems though as I don't have the
appropriate PCI Id info for them.
MFC After: 3 day
|
|
|
|
|
|
| |
and amd64. The optimization is a trivial on recent machines.
Reviewed by: -arch (imp, marcel, dfr)
|
| |
|
|
|
|
|
| |
PERC 3 controllers. This is needed to keep the PM code from powering them
down.
|
|
|
|
| |
Submitted by: Ray Gilstrap
|
| |
|
|
|
|
| |
providing hardware for testing.
|
|
|
|
|
| |
provides support for the Adaptec 2130S adapter. Thanks to Adaptec for
providing hardware for this.
|
| |
|
| |
|
|
|
|
|
|
|
| |
testing and setting of the INTR_ENTROPY macro as it is not needed in
FreeBSD 5.x.
Submitted by: Alex Vasylenko
|
|
|
|
|
|
| |
only done minimal testing on one of these cards and the firmware folks
have been extremely uncooperative in answering my qeustions about them, so
hopefully they will work ok for everyone.
|
|
|
|
|
| |
Submitted by: Mark Santcroos <marks@ripe.net>
Reviewed by: imp, dfr, bde
|
|
|
|
| |
PR: kern/62276
|
|
|
|
|
|
|
|
|
| |
interrupt handler so that no locks are needed, and schedules the
command completion routine with a taskqueue_fast. This also corrects the
locking in the command thread and removes the need for operation flags.
Simple load tests show that this is now considerably faster than FreeBSD 4.x
in the SMP case when multiple i/o tasks are running.
|
| |
|
| |
|
|
|
|
| |
Also some minor style cleanups.
|
| |
|
|
|
|
| |
in the system. This might also have a small performance gain.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
|
|
|
|
| |
Approved by: re (telecon)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Add data structuress for doing 64-bit scatter/gather
- Move busdma tag creations around so that only the parent is
created in aac_pci.c.
- Retrieve the capabilities word from the firmware before setting
up command structures and tags. This allows the driver to decide
whether to do 64-bit commands, and if work-arounds are needed for
systems with >2GB of RAM.
- Only enable the SCSI passthrough if it's enabled in the capabilities
word in the firmware.
This should fix problems with the 2120S and 2200S cards in systems with more
than 2GB of RAM. Full 64-bit support is forthcoming.
MFC-After: 1 week
|
|
|
|
|
|
|
|
| |
in geom_disk.c.
As a side effect this makes a lot of #include <sys/devicestat.h>
lines not needed and some biofinish() calls can be reduced to
biodone() again.
|
|
|
|
|
| |
longer resembles the 4.x version very much. Garbage collect the legacy
bits.
|
|
|
|
| |
fix to BUS_SPACE_MAXADDR, we were probably bouncing quite a bit =-(
|
|
|
|
|
|
|
| |
that a command completion happened, all further processing is deferred to
a taskqueue. The taskqueue itself runs implicetely under Giant, but we
already used a taskqueue for the biodone() processing, so this at least
saves the contesting of Giant in the interrupt handler.
|
|
|
|
|
|
|
|
| |
blocks now, which should eliminate problems with the driver failing to
attach due to insufficient contiguous RAM. Allow the FIB pool to grow
from the default of 128 to the max of 512 as demand grows. Also pad the
adapter init struct to work around the 2120/2200 DMA bug now that there
is no longer a FIB slab.
|
|
|
|
|
|
|
|
| |
commands from below the first 8K of physical memory. A better fix
is to modify the busdma api to allow either inclusion ranges or
multiple exclusion ranges, but that debate is for another day.
MFC After: 2 days
|
|
|
|
|
|
|
|
| |
upsetting the firmware there.
Thanks to imp@freebsd.org for suffering through testing with this.
Approved by: re
|
|
|
|
|
|
|
|
| |
Don't allow SCSI resets on the 5400S card, it seems to cause problems with
certain backplanes.
Submitted by: lnb@freebsdsystems.com
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ever connect a SCSI Cdrom/Tape/Jukebox/Scanner/Printer/kitty-litter-scooper
to your high-end RAID controller. The interface to the arrays is still
via the block interface; this merely provides a way to circumvent the
RAID functionality and access the SCSI buses directly. Note that for
somewhat obvious reasons, hard drives are not exposed to the da driver
through this interface, though you can still talk to them via the pass
driver. Be the first on your block to low-level format unsuspecting
drives that are part of an array!
To enable this, add the 'aacp' device to your kernel config.
MFC after: 3 days
|