Commit Graph

69 Commits

Author SHA1 Message Date
Alexander Kabaev
363b8ed74f Use callout_init_mtx on FreeBSD versions recent enough. This closes
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
2009-10-20 02:35:12 +00:00
Xin LI
c4f739ec0c Use MPT_MAX_LUNS as maximium number of LUNs, not 7, for SAS and FC cases.
This matches Linux driver behavior.

Discussed with:	scottl
Approved by:	re (kensmith)
MFC after:	1 month
2009-07-02 00:43:10 +00:00
Xin LI
1635f0499e Change explicit maximium numbers to the defined macro MPT_MAX_LUNS.
Approved by:	re (kensmith)
2009-07-02 00:41:37 +00:00
Marius Strobl
23f7f783f8 - Remove unused variables. [1]
- Remove redundant zeroing of tmf_req which Coverity Prevent(tm) complains
  about. [2]

Submitted by:	Christoph Mallon [1]
Found with:     Coverity Prevent(tm) [2]
CID:            2496 [2]
MFC after:	2 weeks
2009-06-24 20:52:59 +00:00
Marius Strobl
7ee3780799 Make the whole initiator mode part of mpt(4) endian-clean,
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
2009-01-07 21:52:47 +00:00
Jung-uk Kim
a41aabe249 Restore multi-release tradition of the driver.
Reviewed by:	mjacob
2008-05-02 17:02:35 +00:00
Julian Elischer
3745c395ec Rename the kthread_xxx (e.g. kthread_create()) calls
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.
2007-10-20 23:23:23 +00:00
Scott Long
42f31cf9d0 For some blasted reason the SATA WC change frees a structure right in the
middle of using it.
2007-10-12 16:54:51 +00:00
Scott Long
9adc3a2dfb Move callout initialization to the proper spot. This prevents panics during
error recovery.

Approved by: re
Found by: kan
2007-08-14 19:17:35 +00:00
Scott Long
d38f7b62af Fix some debugging code that crept in accidentally. 2007-06-18 18:28:43 +00:00
Scott Long
b50569b71d Prepare for future integration between CAM and newbus. xpt_bus_register
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.
2007-06-17 05:55:54 +00:00
Scott Long
a54876ea20 Free the portinfo object on unload. 2007-06-04 04:35:04 +00:00
Scott Long
1d558d6a15 mpt.c:
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).
2007-06-03 23:13:05 +00:00
Matt Jacob
d0a68c2747 Make this driver MP safe and still be a multi-release driver.
Obtained from:	99% of the work done by Scott Long.
MFC after:	3 days
2007-05-05 20:18:24 +00:00
Scott Long
8008a935a7 Revert a driver API change to xpt_alloc_ccb that isn't necessary. Fix a
couple of associated error checks.
2007-04-18 04:58:53 +00:00
Scott Long
2b83592fdc Remove Giant from CAM. Drivers (SIMs) now register a mutex that CAM will
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.
2007-04-15 08:49:19 +00:00
Matt Jacob
7b88fb86e3 Hide bus reset announcements within bootverbose.
MFC after:	3 days
2007-04-07 18:15:52 +00:00
Matt Jacob
fa80feee0e feedback from RELENG_5 port 2007-03-11 01:59:44 +00:00
Matt Jacob
ffcf6651a0 Use the new xpt_rescan function to truly now have dynamic
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
2007-02-23 05:51:57 +00:00
Matt Jacob
325bba15cc Whoops- #ifdef problem caused uninitialized transport. Not horribly
a problem, but caused annoying messages.
2007-01-25 18:02:23 +00:00
Matt Jacob
a2baed9764 (commented out) multipath fault injection code.
Some code to make diffs with RELENG_6 easier.
2007-01-05 22:49:05 +00:00
Matt Jacob
05b2985d8e Another (minor) CAM_NEW_TRAN backport thingie, plus a slightly
closer to __FreeBSD_version comparison for this.
2007-01-05 17:51:33 +00:00
Matt Jacob
c3b65db84f Make some slight reorganization (bringing back in some
non-CAM_NEW_TRAN code) to make diffs to previous FreeBSD
versions more manageable.
2006-12-16 07:39:55 +00:00
Matt Jacob
5bac03f95c Make mpt_pci depend on pci and mpt_cam depend on CAM.
PR:		106536
Suggested by:	Norikatsu Shigemura
MFC after:	3 days
2006-12-10 01:13:56 +00:00
Matt Jacob
0e0521a153 MFP4: principally to reapply tagged command support to FC and SAS cards. 2006-12-07 22:02:28 +00:00
Matt Jacob
a841a81629 use xpt_print function 2006-12-05 07:47:22 +00:00
Matt Jacob
c5da377e0e Fix a massive couple of botches here: the NVRAM settings
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.
2006-12-03 07:59:12 +00:00
Matt Jacob
a54067cc0e Fix a debug message which didn't quite get it right about data direction.
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.
2006-12-03 00:28:11 +00:00
Matt Jacob
21167708e8 If a TMF request fails to start, make sure that we pull it off the
pending list and set the state back to free prior to calling mpt_reset
so we don't panic at a later point.
2006-11-19 23:13:12 +00:00
Matt Jacob
52c008534d *smack* - forgot to do i386 compile, so last
commit broke things.
2006-11-17 00:19:55 +00:00
Matt Jacob
757cabc30b Finally fix local command responses to set residual correctly.
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.
2006-11-16 23:47:16 +00:00
John Birrell
3f970273b1 Add big endian support.
Submitted by:	scottl
Reviewed by:	mjacob
2006-11-15 21:46:36 +00:00
Matt Jacob
162eef1f09 Fix some negotiation issues (like not being able to negotiate async) 2006-11-02 23:19:00 +00:00
Matt Jacob
bd3fd815a7 2nd and final commit that moves us to CAM_NEW_TRAN_CODE
as the default.

Reviewed by multitudes.
2006-11-02 00:54:38 +00:00
Matt Jacob
fa9ed86506 The first of 3 major steps to move the CAM layer forward to using
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
2006-10-31 05:53:29 +00:00
Matt Jacob
4542a3798e Connect up a QUEUE FULL event with CAM and adjust openings.
Unfortunately, the QUEUE FULL event only tells you Bus && Target.
It doesn't tell you lun. In order for the XPT_REL_SIMQ action to
work, we have to have a real lun. But which one? For now, just
iterate over MPT_MAX_LUNS.

Practically speaking, this is only going to be happening for lower
quality SAS or SATA drives behind the SAS controller, which means
only lun 0, so it's not so bad.

Helpful Reminder Nagging from: John Baldwin, Fred Whiteside

MFC after:	5 days
2006-09-21 20:35:12 +00:00
Matt Jacob
a7303be1a8 Create a 'ready' handler for each personality. The purpose of this handler
is to able to be called after *all* attach and enable events are done.

We establish a SYSINIT hook to call this handler. The current usage for it
is to add scsi target resources *after* all enables are done. There seems
to be some dependencies between different halves of a dual-port with respect
to target mode.

Put in more meaningful event messages for some events- in particular
QUEUE FULL events so we can see what the queue depth was when the
IOC sent us this message.

MFC after:	1 week
2006-09-07 23:08:21 +00:00
Matt Jacob
b2d24734cd The poison pill of death: adding a target mode reply handler and target
resources to a non-FC card killed us dead. Sorry for the breakage since
last July 12.
2006-09-05 23:53:07 +00:00
Matt Jacob
1dad8bb0ba When probing to attach the CAM functionality, check against
desired role configuration instead of existing role. This gets
us out of the mess where we configured a role of NONE (or were
LAN only, for example), but didn't continue to attach the CAM
module (because we had neither initiator nor target role
set). Unfortunately, the code that rewrites NVRAM to match
actual to desired role only works if the CAM module attaches.

MFC after:	2 weeks
2006-07-25 00:59:54 +00:00
Matt Jacob
970043d7cd Add sysctl information about things like WWNN/WWPN.
MFC after:	2 weeks
2006-07-16 06:05:44 +00:00
Matt Jacob
6621d786eb If we're in mpt_wait_req and the command times out,
mark it as timed out. Don't try and free the config
request for read_cfg_header that times out because
it's still active. Put in code for the config reply
handler that will then free up timed out requests.

Fix the FC_PRIMITIVE_SEND completion to not try
and free a command twice. Dunno how this possibly
could have been working for awhile.

MFC after:	2 weeks
2006-07-16 03:34:55 +00:00
Matt Jacob
73651fd1ef If the card has target mode enabled, and we hang
out ELS buffers but *don't* hang out commands,
we hang folks on the SAN because the LSI-Logic
f/w apparently sends back BUSY or QFULL or some
darn thing.

If we add command buffers, we have to respond to
them sensibly even if we don't have any upstream
listeners (scsi_targ or scsi_targ_bh), so put in
some local command reponse stuff.

MFC after:	2 weeks
2006-07-15 22:58:09 +00:00
Matt Jacob
b4c618c099 Fix config page writes to not strip out the attributes when you
actually go write the config page. This fixes the long standing
problem about updating NVRAM on Fibre Channel cards and seems
so far to not break SPI config page writes.

Put back role setting into mpt. That is, you can set a desired role
for mpt as a hint. On the next reboot, it'll pick that up and redo
the NVRAM settings appropriately and warn you that this won't take
effect until the next reboot. This saves people the step of having
to find a BIOS utilities disk to set target and/or initiator role
for the MPT cards.
2006-07-12 07:48:50 +00:00
Matt Jacob
8ca0124685 VMWare ESX reports > 16 targets for the LSI-Logic
U320 model it emulates. Then it crashes and burns
when you probe that high.
2006-06-26 05:44:18 +00:00
Matt Jacob
9fe6d25444 Major Fixes:
Don't enable/disable I/O space except for SAS adapters.
  This fixes a problem with VMware 4.5 Workstation.

  Fix an egregious bug introduced to target mode so it actually
  will not panic when you first enable a lun.

Minor fixes:

  Take more infor from port facts and configuration pages.

MFC after:	1 week
2006-06-25 04:23:26 +00:00
Jung-uk Kim
672e707a61 Add ability to reset individual devices and fix SCSI speed negotiation.
Reviewed by:	mjacob (initial version)
2006-06-09 23:11:43 +00:00
Matt Jacob
fcd9a16b1f Do some source && comment cleanup.
Clean out the abortive start to homegrown, per-mpt,
Domain Validation. This should really be done at a
higher level.

Use the PIM_SEQSCAN flag for U320- this seems to correct
cases of being unable to consistently negotiate U320 in
the cases where I'd seen this before.

Between this and other recent checkins, this driver is
pretty close to being ready for MFC.

Reviewed by:	scottl, ken, scsi@
MFC after:	1 week
2006-06-05 22:25:49 +00:00
Matt Jacob
5580ce963e More checkpointing on the way toward really (finally)
fixing speed negotiation.

Also fix the mpt_execute_req function to actually
match mpt_execute_req_a64. This may explain why
i386 users were having more grief.
2006-06-02 18:50:39 +00:00
Matt Jacob
ec5fe39d39 Add acknowledgements to LSI-Logic for support 2006-05-29 20:34:28 +00:00
Matt Jacob
800d362b5d + Change some debug messages to MPT_PRT_NEGOTIATE level (so we
can see the results of SPI negotiation w/o being overwhelmed
with other crap).

+ For U320 devices, check against both Settings *and* DV flags before
deciding whether we need to skip actual SPI settings for a device.

+ Go back to creating a 'physical disk' side of a raid/passthru bus that
is limited to the number of maximum physical disks. Actually, this isn't
probably *quite* right yet for one RAID volume, and if we ever end up
with finding a device that supports more than one RAID volume (not likely),
it probably won't quite be right either.

The problem here is that the creating of this 'physical' passthru sim is
just a cheap way to leverage off the CAM midlayer to do our negotiation
for us on the subentities that make up a RAID volume. It almost causes
more trouble than it is worth because we have to remember which side
we're talking to in terms of forming commands and which target ids are
real and so on. Bleah.

+ Skip trying to actually do SPI settings for the RAID volumes on the
real side of the raid/passthru bus pair- this just confuses the issue.
The underlying real physical devices will have the negotiation performed
and the Raid volume will inherit the resultant settings. At the sime time,
non-RAID devices can be on the same real bus, so *do* perform negotiations
with them.

+ At the end of doing all of the settings twiddling, *ahem*, remember to
go update the settings on the card itself (dunno how this got nuked).

At this point, negotiations *seem* to be being done (again) correctly for
both RAID volumes and their subentities. And they seem to be *mostly*
now right for other non-RAID entities on the same bus (I ended up with
3 out of 8 other disks still at narror/async- haven't the slightest
idea why yes).

Finally, negotiations on a normal bus seem to work (again).

There's still more work coming into this area, but we're in the
final stretch.
2006-05-29 20:30:40 +00:00