The mpt driver previously didn't report a 'maxio' size to CAM, and so the
da(4) driver limited I/O sizes to DFLTPHYS (64K) by default. The number
of scatter gather segments allowed, as reported to busdma, was
(128K / PAGE_SIZE) + 1, or 33 on architectures with 4K pages.
Change things around so that we wait until we've determined how many
segments the adapter can support before creating the busdma tag used for
buffers, so we can potentially support more S/G segments and therefore
larger I/O sizes.
Also, fix some things that were broken about the module unload path. It
still gets hung up inside CAM, though.
mpt.c: Move some busdma initialization calls in here, and call
them just after we've gotten the IOCFacts, and know how
many S/G segments this adapter can support.
mpt.h: Get rid of MPT_MAXPHYS, it is no longer used.
Add max_cam_seg_cnt, which is used to report our maximum
I/O size up to CAM.
mpt_cam.c: Use max_cam_seg_cnt to report our maximum I/O size to CAM.
Fix the locking in mpt_cam_detach().
mpt_pci.c: Pull some busdma initialization and teardown out and put
it in mpt.c. We now delay it until we know many scatter
gather segments the adapter can support, and therefore
how to setup our busdma tags.
mpt_raid.c: Make sure we wake up the right wait channel to get the
raid thread to wake up when we're trying to shut it down.
Reviewed by: gibbs, mjacob
MFC after: 2 weeks
Open Firmware device tree in order to match what the PROM built-in
driver uses. This is especially important when netbooting Fujitsu
Siemens PRIMEPOWER250 as in that case the built-in driver isn't used
and the port facts PortSCSIID defaults to 0, conflicting with the
disk at the same address.
- Unify bus reset/probe sequence. Whenever bus attached at boot or later,
CAM will automatically reset and scan it. It allows to remove duplicate
code from many drivers.
- Any bus, attached before CAM completed it's boot-time initialization,
will equally join to the process, delaying boot if needed.
- New kern.cam.boot_delay loader tunable should help controllers that
are still unable to register their buses in time (such as slow USB/
PCCard/ CardBus devices), by adding one more event to wait on boot.
- To allow synchronization between different CAM levels, concept of
requests priorities was extended. Priorities now split between several
"run levels". Device can be freezed at specified level, allowing higher
priority requests to pass. For example, no payload requests allowed,
until PMP driver enable port. ATA XPT negotiate transfer parameters,
periph driver configure caching and so on.
- Frozen requests are no more counted by request allocation scheduler.
It fixes deadlocks, when frozen low priority payload requests occupying
slots, required by higher levels to manage theit execution.
- Two last changes were holding proper ATA reinitialization and error
recovery implementation. Now it is done: SATA controllers and Port
Multipliers now implement automatic hot-plug and should correctly
recover from timeouts and bus resets.
- Improve SCSI error recovery for devices on buses without automatic sense
reporting, such as ATAPI or USB. For example, it allows CAM to wait, while
CD drive loads disk, instead of immediately return error status.
- Decapitalize diagnostic messages and make them more readable and sensible.
- Teach PMP driver to limit maximum speed on fan-out ports.
- Make boot wait for PMP scan completes, and make rescan more reliable.
- Fix pass driver, to return CCB to user level in case of error.
- Increase number of retries in cd driver, as device may return several UAs.
the race where interrupt thread can complete the request for which
timeout has fired and while mpt_timeout has blocked on mpt_lock.
Do a best effort to keep 4.x ang Giant-locked configurartions
compiling still.
Reported by: ups
Reviewed by: scottl
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
thread. Multiple RAID events in quick succession can cause an additional
bus rescan to be scheduled before an earlier scan has completed. In this
case the driver was attempting to use the same CCB storage for two requests.
PR: kern/130330
Reviewed by: Riccardo Torrini riccardo.torrini | esaote com
MFC after: 1 week
specifically SPI controllers now also work in big-endian
machines and some conversions relevant for FC and SAS
controllers as well as support for ILP32 machines which all
were omitted in previous attempts are now also implemented.
The IOCTL-interface is intentionally left (and where needed
actually changed) to be completely little-endian as otherwise
we would have to add conversion code for every possible
configuration page to mpt(4), which didn't seem the right
thing to do, neither did converting only half of the user-
interface to the native byte order.
This change was tested on amd64 (SAS+SPI), i386 (SAS) and
sparc64 (SAS+SPI). Due to lack of the necessary hardware
the target mode code is still left to be made endian-clean.
Reviewed by: scottl
MFC after: 1 month
kthread of the mpt(4) driver that hangs around for the entire lifetime of
the thread. Previously the driver would allocate a new CCB using M_WAITOK
with a lock held each time it updated its state. While here, use the
CAM API for allocating a CCB rather than raw malloc(9).
Reviewed by: scottl
MFC after: 1 week
Previously we reused the space in the request buffer after the request
header to hold config pages during a transaction. This does not work when
reading large pages however. Also, we were already malloc'ing a buffer to
do a copyin/copyout w/o holding locks that was then copied into/out of the
request buffer. Instead, go ahead and use bus dma to alloc a buffer for
each config page request (and RAID actions that have an associated
ActionSGE). This results in fewer data copies and allows for larger sized
requests. For now the maximum size of a request is arbitrarily limited to
16 MB.
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
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.
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.
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
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).
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.
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
