| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Controller)
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
| |
perform various operations on a controller. Specifically, for each mpt(4)
device, create a character device in devfs which accepts ioctl requests for
reading and writing configuration pages and performing RAID actions.
MFC after: 1 week
Reviewed by: scottl
|
|
|
|
| |
Reviewed by: mjacob
|
|
|
|
| |
adapters, apparently.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
abstraction as the RAID and CAM modules, making it nearly impossible
for enough initialization to be done in time for the RAID module to
know whether to attach. On top of this, no reset was being done on
the controller on attach, in violation of the spec. Additionally,
the port enable step was being deferred to the end of the attach
process, long after it should have been done to ensure reliable
operation from the controller. Fix all of these with a few hacks
to force the "attach" and "enable" steps of the core module early
on, and ensure that a reset and port enable also happens early on.
In the future, the driver needs to be refactored to eliminate the
core module abstraction, clean up withe reset/enable steps, and
defer event messages until all of the modules are available to
recieve them.
|
|
|
|
|
|
| |
it's been printing out scary messages about "Unhanded Event Notify Frame"
that are needlessly worrisome to users. Change this warning to only print
out at an elevated debugging level.
|
|
|
|
|
| |
this whole support for systems earlier than 5.0 should probably be removed
but I'll at least FIX it before removing it, so that CVS has it right.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
middle of using it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the mfi(4) LSI MegaSAS RAID card. Looking at the Linux driver for the
mpt(4) it should be 0x0062 and not 0x0060. Tested with an mfi card
of this device id.
Approved by: re (bmah)
Reviewed by: scottl
MFC after: 3 days
|
|
|
|
|
|
|
| |
error recovery.
Approved by: re
Found by: kan
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpt.h:
Add support for reading extended configuration pages.
mpt_cam.c:
Do a top level topology scan on the SAS controller. If any SATA
device are discovered in this scan, send a passthrough FIS to set
the write cache. This is controllable through the following
tunable at boot:
hw.mpt.enable_sata_wc:
-1 = Do not configure, use the controller default
0 = Disable the write cache
1 = Enable the write cache
The default is -1. This tunable is just a hack and may be
deprecated in the future.
Turning on the write cache alleviates the write performance problems with
SATA that many people have observed. It is not recommend for those who
value data reliability! I cannot stress this strongly enough. However,
it is useful in certain circumstances, and it brings the performence in line
with what a generic SATA controller running under the FreeBSD ATA driver
provides (and the ATA driver has had the WC enabled by default for years).
|
| |
|
|
|
|
|
| |
Obtained from: 99% of the work done by Scott Long.
MFC after: 3 days
|
|
|
|
| |
couple of associated error checks.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
MFC after: 3 days
|
| |
|
|
|
|
| |
multi-release support.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
|
|
| |
attachment of new devices that arrive (and we notice them
via async Fibre Channel events). We've always had the
right thing (of sorts) happen when devices go away- this
is the corollary function that makes multipath failover
actually work.
MFC after: 2 weeks
|
| |
|
|
|
|
| |
a problem, but caused annoying messages.
|
|
|
|
| |
Some code to make diffs with RELENG_6 easier.
|
|
|
|
| |
closer to __FreeBSD_version comparison for this.
|
|
|
|
|
| |
non-CAM_NEW_TRAN code) to make diffs to previous FreeBSD
versions more manageable.
|
|
|
|
|
|
| |
PR: 106536
Suggested by: Norikatsu Shigemura
MFC after: 3 days
|
|
|
|
| |
the ENDIAN defines are consistent between mpt.h and mpt.c.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
read wasn't flagging the SYNC mode was enabled. The temp
values for offset and sync period were uint8_t, but were
being assigned and shifted from a uint32_t value.
This didn't show up in testing because a random number
of 1030 cards set a bit that says "honor BIOS negotiation",
which means this whole code path was skipped.
This should clear up at least some of the negotation
issues that have been seen.
|
|
|
|
| |
the number of attached devices is 16 bits wide, not 8 bits wide.
|
|
|
|
|
|
| |
Fix things to use the LSI-Logic Fusion Library mask and shift names for
offset and sync, no matter how awkward they are, in preference to just
plain numbers.
|
| |
|
| |
|
|
|
|
|
| |
pending list and set the state back to free prior to calling mpt_reset
so we don't panic at a later point.
|
|
|
|
| |
commit broke things.
|
|
|
|
|
|
| |
This allows us to play nicely on SANs when we have target mode
enabled in f/w but have neither the scsi_targbh enabled or
scsi_targ with a target enabled.
|
|
|
|
|
|
|
|
| |
different cards (SAS, 4Gb FC), MSI seems to work with
the cards.
This was of some concern because some PCI cards
claim to work with MSI but don't.
|
|
|
|
|
| |
Submitted by: scottl
Reviewed by: mjacob
|
|
|
|
|
|
| |
arches will default to NULL if they have no parent.
Reviewed by: mjacob
|
| |
|
|
|
|
|
| |
devices that support a maximum of 1 message, and we use that 1 message
instead of the INTx rid 0 IRQ with the same interrupt handler, etc.
|
| |
|
| |
|