| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Obtained from: Adaptec, via driver b11669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
now takes a device_t to be the parent of the bus that is being created.
Most SIMs have been updated with a reasonable argument, but a few exceptions
just pass NULL for now. This argument isn't used yet and the newbus
integration likely won't be ready until after 7.0-RELEASE.
|
|
|
|
|
|
|
|
|
|
|
| |
use to synchornize and protect all data objects that are used for that
SIM. Drivers that are not yet MPSAFE register Giant and operate as
usual. RIght now, no drivers are MPSAFE, though a few will be changed
in the coming week as this work settles down.
The driver API has changed, so all CAM drivers will need to be recompiled.
The userland API has not changed, so tools like camcontrol do not need to
be recompiled.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bus_setup_intr()
o add an int return code to all fast handlers
o retire INTR_FAST/IH_FAST
For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current
Reviewed by: many
Approved by: re@
|
|
|
|
|
|
|
| |
Once triggered this would leak away all available commands and starve the rest
of the driver.
Reviewed by: scottl
|
|
|
|
|
| |
Submitted by: Yuxiang Luo
PR: 107943
|
|
|
|
|
|
|
|
|
|
|
| |
would be able to work with aac(4).
This approach is used by some other drivers as well. However, we
need a more generic way to do this in order to avoid having to
special case headers in individual drivers for each platform.
Obtained from: Adaptec (version b11518)
Approved by: scottl
|
|
|
|
|
| |
PR: 106543
MFC after: 3 days
|
|
|
|
| |
Submitted by: Danny Braniss
|
|
|
|
|
|
| |
as the default.
Reviewed by multitudes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the CAM_NEW_TRAN_CODE that has been in the tree for some years now.
This first step consists solely of adding to or correcting
CAM_NEW_TRAN_CODE pieces in the kernel source tree such
that a both a GENERIC (at least on i386) and a LINT build
with CAM_NEW_TRAN_CODE as an option will compile correctly
and run (at least with some the h/w I have).
After a short settle time, the other pieces (making
CAM_NEW_TRAN_CODE the default and updating libcam
and camcontrol) will be brought in.
This will be an incompatible change in that the size of structures
related to XPT_PATH_INQ and XPT_{GET,SET}_TRAN_SETTINGS change
in both size and content. However, basic system operation and
basic system utilities work well enough with this change.
Reviewed by: freebsd-scsi and specific stakeholders
|
|
|
|
|
|
|
|
| |
leak.
Submitted by: Beyond Luo <fedora ercist iscas ac cn>
PR: kern/100046
Reviewed by: scottl
|
|
|
|
|
|
|
|
| |
respective websites.
Reviewed by: scottl
Approved by: rwatson (mentor)
MFC after: 5 days
|
| |
|
|
|
|
|
|
| |
Submitted by: Frank Mayhar
PR: kern/90882
MFC After: 1 day
|
|
|
|
|
|
| |
Nuke whitespace at EOL while I'm here.
Approved by: scottl (MAINTAINER)
|
| |
|
|
|
|
|
|
|
|
| |
aac_alloc_sync_fib(). aac_alloc_sync_fib() will assert that the I/O locks
are held. This fixes a panic on system boot up when the aac(4) device's
bus_generic_attach() routine is called.
Reviewed by: scottl
|
|
|
|
|
|
|
|
| |
do not support the GETINFO immediate command, unlike just about every other
variant of the hardware. Also document some magic values and fix some minor
nearby whitespace.
MFC After: 3 days
|
|
|
|
|
| |
Submitted by: green
PR: 87191
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
risky because the "current time" is supposed to be fed to the card during
initialization, and the current time is supposed to be put into each command
that is sent to the card. Hopefully either the card doesn't actually care
about the timestamps, or it doesn't care about the absolute values so long
and the relative values are consistent. Not an MFC candidate until more
thorough testing can be done.
|
|
|
|
|
| |
MFC after: 3 days
Approved by: scottl
|
|
|
|
| |
driver.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
more verbose about the allocation of RAM on the controller.
Sbumitted by: Jeremy Chadwick
PR: kern/81259
MFC-After: 3 days
|
|
|
|
|
|
| |
and amd64. The optimization is a trivial on recent machines.
Reviewed by: -arch (imp, marcel, dfr)
|
|
|
|
| |
MFC After: 3 days
|
|
|
|
| |
Noticed by: Coverity Prevent analysis tool
|
|
|
|
| |
Submitted by: Coverity Prevent analysis tool
|
| |
|
| |
|
| |
|
|
|
|
|
| |
PERC 3 controllers. This is needed to keep the PM code from powering them
down.
|
| |
|
|
|
|
| |
Submitted by: Ray Gilstrap
|
| |
|
| |
|
|
|
|
| |
providing hardware for testing.
|
|
|
|
|
|
|
|
| |
the firmware status register on the card to see if the firmware is still
running. There is no way to recover from this, but at least it can give
a hint as whether the car has crashed (which happens all too often).
MFC after: 3 days
|
| |
|
|
|
|
|
| |
provides support for the Adaptec 2130S adapter. Thanks to Adaptec for
providing hardware for this.
|
| |
|
| |
|