summaryrefslogtreecommitdiffstats
path: root/sys/dev/mpt
Commit message (Collapse)AuthorAgeFilesLines
* Catch up to MSI-X API changes. Tested with both MSI and MSI-X.jhb2007-02-141-8/+23
|
* Whoops- #ifdef problem caused uninitialized transport. Not horriblymjacob2007-01-251-1/+1
| | | | a problem, but caused annoying messages.
* (commented out) multipath fault injection code.mjacob2007-01-054-2/+21
| | | | Some code to make diffs with RELENG_6 easier.
* Another (minor) CAM_NEW_TRAN backport thingie, plus a slightlymjacob2007-01-051-1/+17
| | | | closer to __FreeBSD_version comparison for this.
* Make some slight reorganization (bringing back in somemjacob2006-12-161-12/+86
| | | | | non-CAM_NEW_TRAN code) to make diffs to previous FreeBSD versions more manageable.
* Make mpt_pci depend on pci and mpt_cam depend on CAM.mjacob2006-12-102-0/+2
| | | | | | PR: 106536 Suggested by: Norikatsu Shigemura MFC after: 3 days
* PH! Forgot to do my cross-compile check. Also now rearranged things somjacob2006-12-072-14/+17
| | | | the ENDIAN defines are consistent between mpt.h and mpt.c.
* MFP4: principally to reapply tagged command support to FC and SAS cards.mjacob2006-12-075-285/+389
|
* use xpt_print functionmjacob2006-12-051-3/+2
|
* Fix a massive couple of botches here: the NVRAM settingsmjacob2006-12-031-23/+15
| | | | | | | | | | | | | 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.
* Forced commit: previous revision just correctly reflected thatmjacob2006-12-031-1/+0
| | | | the number of attached devices is 16 bits wide, not 8 bits wide.
* Fix a debug message which didn't quite get it right about data direction.mjacob2006-12-034-102/+163
| | | | | | 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.
* Pointy hat handed to me by Andrew: had msi_enable on as a default.mjacob2006-11-191-1/+1
|
* Play it safe and make MSI and MSI-X an option you have to turn on for MPT.mjacob2006-11-192-4/+15
|
* If a TMF request fails to start, make sure that we pull it off themjacob2006-11-191-2/+4
| | | | | pending list and set the state back to free prior to calling mpt_reset so we don't panic at a later point.
* *smack* - forgot to do i386 compile, so lastmjacob2006-11-171-2/+2
| | | | commit broke things.
* Finally fix local command responses to set residual correctly.mjacob2006-11-161-19/+35
| | | | | | 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.
* After tests on 2 different AMD platforms with severalmjacob2006-11-161-2/+0
| | | | | | | | 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.
* Add big endian support.jb2006-11-152-61/+85
| | | | | Submitted by: scottl Reviewed by: mjacob
* Get the parent dma tag if one exists. This is required on sun4v. Otherjb2006-11-151-2/+2
| | | | | | arches will default to NULL if they have no parent. Reviewed by: mjacob
* Turn off MSI until some testing is done.mjacob2006-11-151-0/+2
|
* Add MSI support to em(4), bce(4), and mpt(4). For now, we only supportjhb2006-11-152-1/+15
| | | | | 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.
* Fix some negotiation issues (like not being able to negotiate async)mjacob2006-11-021-6/+36
|
* add some missing MPT<>CAM and CAM<>MPT bogolocksmjacob2006-11-021-0/+3
|
* 2nd and final commit that moves us to CAM_NEW_TRAN_CODEmjacob2006-11-021-91/+0
| | | | | | as the default. Reviewed by multitudes.
* The first of 3 major steps to move the CAM layer forward to usingmjacob2006-10-311-5/+23
| | | | | | | | | | | | | | | | | | | | | 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
* Connect up a QUEUE FULL event with CAM and adjust openings.mjacob2006-09-211-2/+32
| | | | | | | | | | | | | | | 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
* Support for PCI-Express 4Gb Cards.mjacob2006-09-081-5/+14
|
* Create a 'ready' handler for each personality. The purpose of this handlermjacob2006-09-073-13/+66
| | | | | | | | | | | | | | | 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
* The poison pill of death: adding a target mode reply handler and targetmjacob2006-09-051-5/+5
| | | | | resources to a non-FC card killed us dead. Sorry for the breakage since last July 12.
* bus_alloc_resource_any is actually defined in themjacob2006-07-251-5/+0
| | | | | RELENG_4 branch, so there's no need to have a compilation difference here any more.
* When probing to attach the CAM functionality, check againstmjacob2006-07-251-5/+13
| | | | | | | | | | | 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
* Add sysctl information about things like WWNN/WWPN.mjacob2006-07-162-0/+40
| | | | MFC after: 2 weeks
* If we're in mpt_wait_req and the command times out,mjacob2006-07-162-4/+18
| | | | | | | | | | | | | 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
* Define out unused and incomplete raid quiesce functions.mjacob2006-07-162-8/+12
| | | | | The code never could be called, so we might as well not compile it for now.
* If the card has target mode enabled, and we hangmjacob2006-07-152-40/+177
| | | | | | | | | | | | | | 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
* Fix config page writes to not strip out the attributes when youmjacob2006-07-125-38/+147
| | | | | | | | | | | | | 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.
* VMWare ESX reports > 16 targets for the LSI-Logicmjacob2006-06-261-0/+6
| | | | | U320 model it emulates. Then it crashes and burns when you probe that high.
* Major Fixes:mjacob2006-06-254-28/+45
| | | | | | | | | | | | | | 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
* Add PCI ids for the FC919Xmjacob2006-06-101-0/+8
| | | | MFC after: 1 week
* Add ability to reset individual devices and fix SCSI speed negotiation.jkim2006-06-091-50/+48
| | | | Reviewed by: mjacob (initial version)
* Do some source && comment cleanup.mjacob2006-06-052-35/+14
| | | | | | | | | | | | | | | | 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
* Make the code able to compile again in RELENG_4.mjacob2006-06-021-0/+1
|
* More checkpointing on the way toward really (finally)mjacob2006-06-024-110/+123
| | | | | | | | 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.
* Pick reasonable alignment constraints so that wemjacob2006-05-311-27/+25
| | | | | | | don't ask too much of bus_dmamem_alloc/malloc. Replace the device_printf calls in the memalloc function mpt_prt.
* Add acknowledgements to LSI-Logic for supportmjacob2006-05-299-0/+39
|
* + Change some debug messages to MPT_PRT_NEGOTIATE level (so wemjacob2006-05-291-74/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add a mpt_is_raid_volume function which will tell you whethermjacob2006-05-292-2/+20
| | | | | | | | the passed target id is one of the RAID VolumeID. This result is used to decide whether to try and do actual SPI negotiations on the real side of the raid/passthru bus pair. The reason we check this is that we can have both RAID volumes and real devices on the same bus.
* Add a MPT_PRT_NEGOTIATION print level.mjacob2006-05-291-0/+1
|
* When setting verbose, *set* it, don't *add* it.mjacob2006-05-291-1/+1
|
OpenPOWER on IntegriCloud