controller supports only a single message. I haven't seen such an adapter
out in the wild, though, so this change likely is a NOP.
While at it, further simplify the MSI allocation logic; there's no need
to check the number of available messages on our own as pci_alloc_msi(9)
will just fail if it can't provide us with the single message we want.
- Nuke the unused softc of aacch(4).
MFC after: 1 month
quirk and apply it to these controllers [1]. The same problem was reported
for 2230S, in which case it wasn't actually clear whether the culprit is the
controller or the mainboard, though. In order to be on the safe side, flag
MSIs as being broken with the latter type of controller as well. Given that
these are the only reports of MSI-related breakage with aac(4) so far and
OSes like OpenSolaris unconditionally employ MSIs for all adapters of this
family, however, it doesn't seem warranted to generally disable the use of
MSIs in aac(4).
While it, simplify the MSI allocation logic a bit; there's no need to check
for the presence of the MSI capability on our own as pci_alloc_msi(9) will
just fail when these kind of interrupts are not available.
Reported and tested by: David Boyd [1]
MFC after: 3 days
aac_command_status_table, which is actually unused since r111532.
While at it, make aac_if a pointer to the now const interface tables
instead of copying them over to the softc (this alone already reduces the
size of aac.ko on amd64 by ~1 KiB).
- Remove redundant softc members.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
- Remove redundant bzero(9)'ing of the softc.
- Use pci_enable_busmaster(9) instead of duplicating it.
- Remove redundant checking for PCIM_CMD_MEMEN (resource allocation will
just fail).
- Canonicalize the error messages in case of resource allocation failures.
- Add support for using MSI instead of INTx, controllable via the tunable
hw.aac.enable_msi (defaulting to on).
MFC after: 1 month
corruption. Thanks to scottl@ for the suggestion.
This change will likely be revised after consideration of a general
method to address this type of issue for other drivers.
Sponsored by: Sandvine Incorporated
MFC after: 3 days
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
[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.
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.
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
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.
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
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.
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.
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
- 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
