#
321945 |
|
02-Aug-2017 |
ken |
MFC r321622, r321623:
------------------------------------------------------------------------ r321622 | ken | 2017-07-27 09:33:57 -0600 (Thu, 27 Jul 2017) | 44 lines
Fix probing FC targets with hard addressing turned on.
This largely reverts FreeBSD SVN change 289937 from October 25th, 2015.
The intent of that change was to keep loop IDs persistent across chip reinits.
The problem is that the change turned on the PREVLOOP / PREV_ADDRESS bit (bit 7 in Firmware Options 2), which tells the Qlogic chip to not participate in the loop if it can't get the requested loop address. It also turned off soft addressing on 2400 (4Gb) and newer controllers.
The isp(4) driver defaults to loop address 0, and the tape drives I have tested default to loop address 0 if hard addressing is turned on. So when hard loop addressing is turned on on the drive, the isp(4) driver just refuses to participate in the loop.
The solution is to largely revert that change. I left some elements in place that are related to virtual ports, since they were new.
This does work with IBM tape drives with hard and soft addressing turned on. I have tested it with 4Gb, 8Gb, and 16Gb controllers.
sys/dev/isp.c: Largely revert FreeBSD SVN change 289937. I left the ispmbox.h changes in place.
Don't use the PREV_ADDRESS bit on initialization. It tells the chip to not participate if it can't get the requested loop ID.
Do use soft addressing on 2400 and newer chips.
Use hard addressing when the user has requested a specific initiator ID. (hint.isp.X.iid=N in /boot/loader.conf)
Leave some of the virtual port options from that change in place, but don't turn on the PREV_ADDRESS bit.
Reviewed by: mav Sponsored by: Spectra Logic
------------------------------------------------------------------------ r321623 | ken | 2017-07-27 09:51:56 -0600 (Thu, 27 Jul 2017) | 6 lines
Remove duplicate assignments from r321622.
Submitted by: mav Sponsored by: Spectra Logic
------------------------------------------------------------------------
|
#
318149 |
|
10-May-2017 |
ken |
MFC r317740:
Correct loop mode CRN resets to adhere to FCP-4 section 4.10
Prior to this change, the CRN (Command Reference Number) is reset on any firmware LIP, LOOP DOWN, or LOOP RESET event in violation of FCP-4 which specifies that the CRN should only be reset in response to a LIP Reset (LIPyx) primitive. FCP-4 also indicates PLOGI/LOGO and PRLI/PRLO ELS actions as conditions for resetting the CRN for the associated initiator port.
These violations manifest themselves when the HBA is removed from the loop, or a target device is removed (especially during an outstanding command) without power cycling. If the HBA and and the target device determine upon re-establishing the loop that no PLOGI or PRLI is required, and the target does not issue a LIPxy to the initiator, the CRN for the target will have been improperly reset by the isp driver. As a result, the target port will silently ignore all FCP commands issued during the device probe (which will time out) preventing the device from attaching.
This change corrects thie CRN reset behavior in response to loop state changes, also introduces CRN resets for the above mentioned ELS actions as encountered through async PDB change events.
This change also adds cleanup of outstanding commands in isp_loop_dead() that was previously missing.
sys/dev/isp/isp.c Add the last login state to debug output when syncing the pdb
sys/dev/isp/isp_freebsd.c Replace binary statement setting aborted ccb status in isp_watchdog() with the XS_SETERR macro used elsewhere
In isp_loop_dead(), abort or complete pending commands as done in isp_watchdog()
In isp_async(), segregate the ISPASYNC_LOOP_RESET action from ISPASYNC_LIP, ISPASYNC_LOOP_DOWN, and ISPASYNC_LOOP_UP fallthroughs, and only reset the CRN in the RESET case. Also add checks to handle false LOOP RESET actions that do not have a proper associated LIP primitive, and log the primitive in the debug messages
In isp_async(), remove the goto from ISP_ASYNC_DEV_STAYED, and only reset the CRN in the DEV_CHANGED action
In isp_async(), when processing an ISPASYNC_CHANGE_PDB status, reset CRN(s) for the associated nphdl (or all ports) if the change reason is some form of ELS login/logout. Also remove assignment to fc since it is not used in the scope
sys/dev/isp/ispmbox.h Add macro definition for the global N-Port handle, and correct a macro typo 'PDB24XX_AE_PRLI_DONJE'
sys/dev/isp/ispvar.h Add macros FCP_AL_DA_ALL, FCP_AL_PA, and FCP_IS_DEST_ALPD for more legible code when determining if an AL_PD port matches the portid for a given struct fcparam* by value or by virtue of the AL_PD port being 0xFF
Submitted by: Reid Linnemann Sponsored by: Spectra Logic
|
#
317636 |
|
01-May-2017 |
mav |
MFC r317356: Switch isp_reset to scratchpad not requiring ISP_MBOXDMASETUP.
|
#
317363 |
|
24-Apr-2017 |
mav |
MFC r315708: Cleanup response queue processing.
|
#
317322 |
|
23-Apr-2017 |
mav |
MFC r316652: Fix few minor issues found by Clang Analyzer.
|
#
316407 |
|
02-Apr-2017 |
mav |
MFC r315681: Improve command timeout handling.
Let firmware do its best first, and if it can't, try software recovery. I would remove software timeout handler completely, but found bunch of complains on command timeout on sparc64 mailing list few years ago, so better be safe in case of interrupt loss.
|
#
316405 |
|
02-Apr-2017 |
mav |
MFC r315678: Remove questionable reqp->req_time access.
|
#
316401 |
|
02-Apr-2017 |
mav |
MFC r315587, r315652: Remove some dead/useless code.
|
#
316399 |
|
02-Apr-2017 |
mav |
MFC r315579, r315670: Add initial support for multiple MSI-X vectors.
For 24xx and above use 2 vectors (default and response queue). For 26xx and above use 3 vectors (default, response and ATIO queues). Due to global lock interrupt hardlers never run simultaneously now, but at least this allows to save one regitster read per interrupt.
|
#
316169 |
|
29-Mar-2017 |
mav |
MFC r315545: Remove hackish code delaying ATIOs to unknown virtual port.
Since we support RQSTYPE_RPT_ID_ACQ, that functionality is only useful in loop mode, which probably doesn't worth having this hack in 2017.
|
#
316155 |
|
29-Mar-2017 |
mav |
MFC r315485: Remove dead remnants of SPI target.
|
#
316146 |
|
29-Mar-2017 |
mav |
MFC r315307: Refactor interrupt handling.
Instead of single isp_intr() function doing all possible magic, introduce four different functions to handle mailbox operation completions, async events, response and ATIO queues. The goal is to isolate different code paths to make code more readable, and to make easier support for multiple interrupt vectors. Even oldest hardware in many cases can identify what code path it should run on interrupt. Contemporary hardware can assign them to different interrupt vectors.
|
#
316093 |
|
28-Mar-2017 |
mav |
MFC r315279: Remove some dead/broken code paths around async handling
|
#
316091 |
|
28-Mar-2017 |
mav |
MFC r315273: Remove tangled isp_mbox_continue() mechanism.
It was implemented to reduce context switches when uploading firmware to card's RAM. But this mechanism is not used last 10 years since all mbox operations are now polled, and it was never used for cards produced in last 15 years. Newer cards can use DMA to upload firmware.
|
#
316089 |
|
28-Mar-2017 |
mav |
MFC r315236: Remove dangerous and questionable isp_mboxcmd_qnw() call.
|
#
316087 |
|
28-Mar-2017 |
mav |
MFC r315234: Improvements around attach, reset and detach.
This change fixes DMA resource leak on driver unload. Also it removes DMA resources allocation for hardcoded number of requests before fetching the real number from firmware. Also it prepares ground for more flexible IRQs allocation according to firmware capabilities.
|
#
315980 |
|
26-Mar-2017 |
mav |
MFC r315161: Try to slight untangle I/O and loop status handling.
|
#
315978 |
|
26-Mar-2017 |
mav |
MFC r315160: Remove code for unsupported FreeBSD versions.
|
#
314765 |
|
06-Mar-2017 |
mav |
MFC r314326: Send TERMINATE to firmware when aborting active ATIO.
|
#
314759 |
|
06-Mar-2017 |
mav |
MFC r314302: Return better error code in case of too long CDB.
Its more important for SPI HBAs, as they don't support CDBs above 12 bytes. The new error code makes CAM to fall back to alternative commands.
|
#
313700 |
|
13-Feb-2017 |
ken |
MFC r313568:
------------------------------------------------------------------------ r313568 | ken | 2017-02-10 15:02:45 -0700 (Fri, 10 Feb 2017) | 68 lines
Change the isp(4) driver to not adjust the tag type for REQUEST SENSE.
The isp(4) driver was changing the tag type for REQUEST SENSE commands to Head of Queue, when the CAM CCB flag CAM_TAG_ACTION_VALID was NOT set. CAM_TAG_ACTION_VALID is set when the tag action in the XPT_SCSI_IO is not CAM_TAG_ACTION_NONE and when the target has tagged queueing turned on.
In most cases when CAM_TAG_ACTION_VALID is not set, it is because the target is not doing tagged queueing. In those cases, trying to send a Head of Queue tag may cause problems. Instead, default to sending a simple tag.
IBM tape drives claim to support tagged queueing in their standard Inquiry data, but have the DQue bit set in the control mode page (mode page 10). CAM correctly detects that these drives do not support tagged queueing, and clears the CAM_TAG_ACTION_VALID flag on CCBs sent down to the drives.
This caused the isp(4) driver to go down the path of setting the tag action to a default value, and for Request Sense commands only, set the tag action to Head of Queue.
If an IBM tape drive does get a Head of Queue tag, it rejects it with Invalid Message Error (0x49,0x00). (The Qlogic firmware translates that to a Transport Error, which the driver translates to an Unrecoverable HBA Error, or CAM_UNREC_HBA_ERROR.) So, by default, it wasn't possible to get a good response from a REQUEST SENSE to an FC-attached IBM tape drive with the isp(4) driver.
IBM tape drives (tested on an LTO-5 with G9N1 firmware and a TS1150 with 4470 firmware) also have a bug in that sending a command with a non-simple tag attribute breaks the tape drive's Command Reference Number (CRN) accounting and causes it to ignore all subsequent commands because it and the initiator disagree about the next expected CRN. The drives do reject the initial command with a head of queue tag with an Invalid Message Error (0x49,0x00), but after that they ignore any subsequent commands. IBM confirmed that it is a bug, and sent me test firmware that fixes the bug. However tape drives in the field will still exhibit the bug until they are upgraded.
Request Sense is not often sent to targets because most errors are reported automatically through autosense in Fibre Channel and other modern transports. ("Modern" meaning post SCSI-2.) So this is not an error that would crop up frequently. But Request Sense is useful on tape devices to report status information, aside from error reporting.
This problem is less serious without FC-Tape features turned on, specifically precise delivery of commands (which enables Command Reference Numbers), enabled on the target and initiator. Without FC-Tape features turned on, the target would return an error and things would continue on.
And it also does not cause problems for targets that do tagged queueing, because in those cases the isp(4) driver just uses the tag type that is specified in the CCB, assuming the CAM_TAG_ACTION_VALID flag is set, and defaults to sending a Simple tag action if it isn't an ordered or head of queue tag.
sys/dev/isp/isp.c: In isp_start(), don't try to send Request Sense commands with the Head of Queue tag attribute if the CCB doesn't have a valid tag action. The tag action likely isn't valid because the target doesn't support tagged queueing.
Sponsored by: Spectra Logic
------------------------------------------------------------------------
|
#
304416 |
|
18-Aug-2016 |
mav |
MFC r300222: Fix delaying requests to unknown virtual ports 2s after init.
This code was originally implemented 7 years ago, but never really worked due to trivial error. I think this functionality may be not required. Initiators supporting optional periodic command status checks detected those terminated commands and retried them 3 seconds later. But thinking about less featured initiators and the fact that it is our race makes virtual ports "unknown" it may be good to have this feature.
|
#
300583 |
|
24-May-2016 |
mav |
MFC r300217: Add IOCB debugging for ISPCTL_RESET_DEV and ISPCTL_ABORT_CMD.
|
#
300581 |
|
24-May-2016 |
mav |
MFC r300058: Make RQCS_PORT_LOGGED_OUT for ZOMBIE ports retriable.
It is normal for ZOMBIE ports to be logged out. This status is not really an error until Gone Device Timeout expires, so make CAM retry after delay.
|
#
300580 |
|
24-May-2016 |
mav |
MFC r300052: Completely remove broken now autologin port flag.
Firmware automatically logs in only to local loop ports, and those ports can be easily identified without extra flag by zero domain and area IDs.
|
#
300578 |
|
24-May-2016 |
mav |
MFC r299955: No need to check login status for ZOMBIE ports.
ZOMBIE ports are always logged out, and so initiator may try to relogin.
|
#
298975 |
|
03-May-2016 |
mav |
MFC r298103: Simplify memory allocation for NS requests.
Since we no longer need additional buffers for request and response IOCBs, we can increase receive space by 192 bytes, that is enough for fetching 48 more ports. The new limit is 1020 fabric ports per virtual port.
|
#
298972 |
|
03-May-2016 |
mav |
MFC r297991: Extract virtual port address from RQSTYPE_RPT_ID_ACQ.
This should close the race between request arriving on new target mode virtual port and its scanner thread finally fetch its address for request routing.
|
#
298970 |
|
03-May-2016 |
mav |
MFC r297915: Filter Port Database Changed notifications.
For some reason firmware sends Port Database Changed notifications in case of explicit login requests from the driver when target port is unavailabe. Those notifications don't give driver any new information, but only cause infinite scan loop.
|
#
298969 |
|
03-May-2016 |
mav |
MFC r297912: Respect NVRAM topology settings on 24xx and above chips.
|
#
298968 |
|
03-May-2016 |
mav |
MFC r297867: Make all CT Pass-Through (name server requests) asynchronous.
Previously we had to do it synchronously because we could not drop the lock due to potential scratch memory use conflicts. Previous commits fixed that collision, so here it goes -- slower and less reliable external requests are executed asynchronously without spinning in tight loop and with more safe timeout handling.
|
#
298967 |
|
03-May-2016 |
mav |
MFC r297859: Switch isp_getpdb() to synchronous IOCB DMA area.
While technically it is not IOCB, it is synchronous and can be called from different places, so calling FC_SCRATCH_ACQUIRE() here is inconvenient.
|
#
298966 |
|
03-May-2016 |
mav |
MFC r297858: Allocate separate DMA area for synchronous IOCB execution.
Usually IOCBs should be put on queue for asynchronous processing and should not require additional DMA memory. But there are some cases like aborts and resets that for external reasons has to be synchronous. Give those cases separate 2*64 byte DMA area to decouple them from other DMA scratch area users, using it for asynchronous requests.
|
#
298964 |
|
03-May-2016 |
mav |
MFC r297854: Add couple missing memory barriers.
|
#
298963 |
|
03-May-2016 |
mav |
MFC r297817: Polish debugging IOCB dumping.
Add few more missing cases, unify byte order.
|
#
298962 |
|
03-May-2016 |
mav |
MFC r297751: Register symbolic port/node names in FC name server.
This is cosmetics that simplifies identification of new ports on FC switch.
It would be good to use target name from CTL here instead of hostname, but it is not passed here through CAM now.
|
#
298961 |
|
03-May-2016 |
mav |
MFC r297741: Reduce code duplication when executing Passthrough IOCB.
|
#
292931 |
|
30-Dec-2015 |
mav |
MFC r292765: Allocate separate scratch space for scanner purposes.
This space does not require DMA syncing. It reduces lock scope of the DMA scratch space. It allows whole DMA scratch space to be used to I/O, so now we can fetch up to ~1000 ports from SNS.
Due to the last fact, increase maximal number of ports from 256 to 1024.
|
#
292924 |
|
30-Dec-2015 |
mav |
MFC r292741: Make port logins asynchronous, following r292739 logic.
This is even more important since it involves more network operations and more prone to delays and timeouts.
|
#
292922 |
|
30-Dec-2015 |
mav |
MFC r292739: Make virtual ports control asynchronous.
Before this change virtual ports control IOCBs were executed synchronously via Execute IOCB mailbox command. It required exclusive use of scratch space of driver and mailbox registers of the hardware. Because of that shared resources use this code could not really sleep, having to spin for completion, blocking any other operation.
This change introduces new asynchronous design, sending the IOCBs directly on request queue and gracefully waiting for their return on response queue. Returned IOCBs are identified with unified handle space from r292725.
|
#
292921 |
|
30-Dec-2015 |
mav |
MFC r292725: Unify handles allocation for initiator and target IOCBs.
I am not sure why this was split long ago, but I see no reason for it. At this point this unification just slightly reduces memory usage, but as next step I plan to reuse shared handle space for other IOCB types.
|
#
292919 |
|
30-Dec-2015 |
mav |
MFC r292715: Clear virtual port's port database when disabling it.
Previously it was done only on full chip reinit, that caused old ports resurrect in case of virtual port reenabling.
|
#
292918 |
|
30-Dec-2015 |
mav |
MFC r292690: Some polishing for command timeouts handling.
|
#
292916 |
|
30-Dec-2015 |
mav |
MFC r292610: Fix speed setting by NVRAM for 24xx and above chips.
|
#
292598 |
|
22-Dec-2015 |
mav |
MFC r291654, r291727, r291821, r291872, r292034, r292041, r292249, r292042: Add initial support for 16Gbps FC QLogic chips.
|
#
291532 |
|
30-Nov-2015 |
mav |
MFC r291365, r291369: One more round of port scanner rewrite.
- Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
|
#
291531 |
|
30-Nov-2015 |
mav |
MFC r291265: Rename ASYNC_LIP_F8 to ASYNC_LIP_NOS_OLS_RECV.
New name better repsents its meaning for modern chips.
|
#
291529 |
|
30-Nov-2015 |
mav |
MFC r291209: Fix target mode support for Qlogic 2200 FC adapters.
Now target mode works for all supported FC adapters except ancient 2100, which is not tested.
|
#
291528 |
|
30-Nov-2015 |
mav |
MFC r291188: Rip off target mode support for parallel SCSI QLogic adapters.
Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting.
Initiator mode tested with Qlogic 1080 adapter is still working fine.
|
#
291523 |
|
30-Nov-2015 |
mav |
MFC r291163: Explicitly call SEND CHANGE REQUEST for pre-24xx chips in target mode.
While later firmware always registers for RSCN requests, older one does it only in initiator mode. But in target mode there RSCN can be the only way to detect gone intiator.
|
#
291521 |
|
30-Nov-2015 |
mav |
MFC r291161: Gracefully stop firmware before resetting chip when changing role.
|
#
291520 |
|
30-Nov-2015 |
mav |
MFC r291160: Add some more asynchronous event status codes.
|
#
291519 |
|
30-Nov-2015 |
mav |
MFC r291159: Add more mailbox command codes.
|
#
291517 |
|
30-Nov-2015 |
mav |
MFC r291144: Fix target mode with fabric for pre-24xx chips.
For those chips we are not receiving login events, adding initiators based on ATIO requests. But there is no port ID in that structure, so in fabric mode we have to explicitly fetch it from firmware to be able to do normal scan after that.
|
#
291516 |
|
30-Nov-2015 |
mav |
MFC r291099: Some cosmetics for ancient cards.
|
#
291515 |
|
30-Nov-2015 |
mav |
MFC r291092: Optimize SNS_GID_FT request scratch memory usage.
Now with present 4K of scratch we can fetch up to 508 ports (16 more).
|
#
291514 |
|
30-Nov-2015 |
mav |
MFC r291080: Another round of port scanner rewrite.
This change simplifies and unifies port adding/updating for loop and fabric scanners. It also fixes problems with scanning restarts due to concurrent port databases changes. It also fixes many cosmetic issues.
|
#
291513 |
|
30-Nov-2015 |
mav |
MFC r291014: Simplify fabric tasting code.
Except cosmetic changes this removes fabric ports from our port database. It is always firmware duty to manage them, so driver don't need to worry.
|
#
291512 |
|
30-Nov-2015 |
mav |
MFC r291013: Remove some confusions between loopid and nphdl.
Modern cards in most cases operate abstract port handles, that have no any relation to real loop IDs. Leave loopid used only where it really goes about local loop IDs.
While there, fix few more cases where LUNs were still printed in decimal.
|
#
291511 |
|
30-Nov-2015 |
mav |
MFC r291000: Register our FC4 Features in SNS.
|
#
291510 |
|
30-Nov-2015 |
mav |
MFC r290993, r290994: Unify and cleanup FC ports scan.
|
#
291509 |
|
30-Nov-2015 |
mav |
MFC r290981: Off-by-one correctiont to r290980.
|
#
291508 |
|
30-Nov-2015 |
mav |
MFC r290980: Make firmware handle virtual ports SNS logins for us.
|
#
291507 |
|
30-Nov-2015 |
mav |
MFC r290978: Add real initial support for RQSTYPE_RPT_ID_ACQ.
|
#
291505 |
|
30-Nov-2015 |
mav |
MFC r290507: Rework r290504.
|
#
291504 |
|
30-Nov-2015 |
mav |
MFC r290506: Specify VP when sending a marker.
|
#
291503 |
|
30-Nov-2015 |
mav |
MFC r290504: Make ISP_SLEEP() really sleep instead of spinning.
While there, simplify the wait logic.
|
#
291502 |
|
30-Nov-2015 |
mav |
MFC r290160: Remove some unneeded code.
|
#
291501 |
|
30-Nov-2015 |
mav |
MFC r290159: Remove reset delays for which I see neither explanation nor need.
|
#
291500 |
|
30-Nov-2015 |
mav |
MFC r290147: Fix and improve error masking and reporting.
|
#
291499 |
|
30-Nov-2015 |
mav |
MFC r290118: Change the way how target mode is enabled on 23xx chips.
Without docs I am not completely sure about this, but on my tests new method works better then previous, at least with our latest firmware.
|
#
291498 |
|
30-Nov-2015 |
mav |
MFC r290104: Improve/fix loop scanning routine.
For the most of chips (except anscient ones) port handlers have no relation to port IDs. In such situation old code scanning first 125 handlers was quite naive. Instead of doing that, send to chip single request to get full list of port handlers available on specific virtual port and scan only them.
Old code had problems with case of several virtual ports enabled, when port handlers allocated from global address space could easily go above 125. This change was successfully tested on 23xx, 24xx and 25xx chips in loop mode with 4 virtual initiator ports, each seing 50 virtual target ports.
|
#
290800 |
|
13-Nov-2015 |
mav |
MFC r290054: Reimplement next port handle generation.
For some reason port handles should be allocated from HBA-global space, while old code was not very specific, mixing per-HBA and per-VP logic.
|
#
290798 |
|
13-Nov-2015 |
mav |
MFC r290018: Reimplement enable and implement disable of virtual ports.
Now on 24xx and above chips it is really possible to simulate several virtual FC ports with single physical one. For example, it allows to configure several targets in ctl.conf, assign each of them to separate virtual port, and let user to control access to them with switch zoning.
I still doubt that all problems are solved there, but at now it passes at least basic tests.
|
#
290796 |
|
13-Nov-2015 |
mav |
MFC r289937: Try to keep Loop IDs persistent across chip reinits.
|
#
290795 |
|
13-Nov-2015 |
mav |
MFC r289933, r289939: Improve Port Database Changed handling and reporting.
|
#
290794 |
|
13-Nov-2015 |
mav |
MFC r289930: Formalize/unify chip (re-)inits.
|
#
290793 |
|
13-Nov-2015 |
mav |
MFC r289890: Skip reserved IP Broadcast handle from using.
|
#
290791 |
|
13-Nov-2015 |
mav |
MFC r289882: Add PIM_EXTLUNS support to isp(4) driver.
Now 24xx and above chips support full 8-byte LUN address space. Older FC chips may support up to 16K LUNs when firmware allows. Tested in both initiator and target modes for 23xx, 24xx and 25xx.
|
#
290789 |
|
13-Nov-2015 |
mav |
MFC r289875: Decode few more response info codes.
Though CAM still does not send any requests that would require those.
|
#
290785 |
|
13-Nov-2015 |
mav |
MFC r289812, r289852: Some polishing and unification in ISR code.
|
#
290784 |
|
13-Nov-2015 |
mav |
MFC r289681: Some more defines and polishing for INIT_FIRMWARE.
|
#
290781 |
|
13-Nov-2015 |
mav |
MFC r289622: Zero mbox[1] for INIT_FIRMWARE to fix version 7.3 firmware.
While there, add new fields to isp_icb_2400_t structure.
|
#
290780 |
|
13-Nov-2015 |
mav |
MFC r289620: Decode more firmware attributes.
|
#
288717 |
|
05-Oct-2015 |
mav |
MFC r285600: MULTI_ID supported does not mean it is used.
|
#
288714 |
|
05-Oct-2015 |
mav |
MFC r285459: Unify port database use for target and initiator roles.
Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any.
|
#
288712 |
|
05-Oct-2015 |
mav |
MFC r285154: Remove extra level of target ID indirection (isp_dev_map).
FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too.
|
#
288709 |
|
05-Oct-2015 |
mav |
MFC r285146: Drop discovered targets when initiator role is disabled.
|
#
284907 |
|
28-Jun-2015 |
mav |
MFC r284808: Remove limitations on setting WWNNs starting from 2.
It is odd that driver first tries to generate synthetic WWNN based on WWPN starting from 2, but then refuses to use it. If we don't trust generated WWNN, we should probably not generate it. Same time this limitation prevents potentially valid WWNN setting by user.
|
#
284802 |
|
25-Jun-2015 |
mav |
MFC r284698: Dump additional config bytes for INIT_FIRMWARE_MULTI_ID.
|
#
284801 |
|
25-Jun-2015 |
mav |
MFC r284697: Add logging of executed mailbox command names.
Previously those commands were logged only as part of register dump, that is not very readable.
|
#
278171 |
|
03-Feb-2015 |
ken |
MFC isp(4) driver changes:
r276839, r276842, r277513, r277514, r277515
------------------------------------------------------------------------ r276839 | ken | 2015-01-08 10:41:28 -0700 (Thu, 08 Jan 2015) | 49 lines
Fix Fibre Channel Command Reference Number handling in the isp(4) driver.
The Command Reference Number is used for precise delivery of commands, and is part of the FC-Tape functionality set. (This is only enabled for devices that support precise delivery of commands.) It is an 8-bit unsigned number that increments from 1 to 255. The commands sent by the initiator must be processed by the target in CRN order if the CRN is non-zero.
There are certain scenarios where the Command Reference Number sequence needs to be reset. When the target is power cycled, for instance, the initiator needs to reset the CRN to 1. The initiator will know this because it will see a LIP (when directly connected) or get a logout/login event (when connected to a switch).
The isp(4) driver was not resetting the CRN when a target went away and came back. When it saw the target again after a power cycle, it would continue the CRN sequence where it left off. The target would ignore the command because the CRN sequence is supposed to be reset to 1 after a power cycle or other similar event.
The symptom that the user would see is that there would be lots of aborted INQUIRY commands after a tape library was power cycled, and the library would fail to probe. The INQUIRY commands were being ignored by the tape drive due to the CRN issue mentioned above.
isp_freebsd.c: Add a new function, isp_fcp_reset_crn(). This will reset all of the CRNs for a given port, or the CRNs for all LUNs on a target.
Reset the CRNs for all targets on a port when we get a LIP, loop reset, or loop down event.
Reset the CRN for a particular target when it arrives, is changed or departs. This is less precise behavior than the clearing behavior specified in the FCP-4 spec (which says that it should be reset for PRLI, PRLO, PLOGI and LOGO), but this is the level of information we have here. If this is insufficient, then we will need to add more precise notification from the lower level isp(4) code.
isp_freebsd.h: Add a prototype for isp_fcp_reset_crn().
Sponsored by: Spectra Logic MFC after: 1 week
------------------------------------------------------------------------ r276842 | ken | 2015-01-08 10:51:12 -0700 (Thu, 08 Jan 2015) | 44 lines
Close a race in the isp(4) driver that caused devices to disappear and not automatically come back if they were gone for a short period of time.
The isp(4) driver has a 30 second gone device timer that gets activated whenever a device goes away. If the device comes back before the timer expires, we don't send a notification to CAM that it has gone away. If, however, there is a command sent to the device while it is gone and before it comes back, the isp(4) driver sends the command back with CAM_SEL_TIMEOUT status.
CAM responds to the CAM_SEL_TIMEOUT status by removing the device. In the case where a device comes back within the 30 second gone device timer window, though, we weren't telling CAM the device came back.
So, fix this by tracking whether we have told CAM the device is gone, and if we have, send a rescan if it comes back within the 30 second window.
ispvar.h: In the fcportdb_t structure, add a new bitfield, reported_gone. This gets set whenever we return a command with CAM_SEL_TIMEOUT status on a Fibre Channel device.
isp_freebsd.c: In isp_done(), if we're sending CAM_SEL_TIMEOUT for for a command sent to a FC device, set the reported_gone bit.
In isp_async(), in the ISPASYNC_DEV_STAYED case, rescan the device in question if it is mapped to a target ID and has been reported gone.
In isp_make_here(), take a port database entry argument, and clear the reported_gone bit when we send a rescan to CAM.
In isp_make_gone(), take a port database entry as an argument, and set the reported_gone bit when we send an async event telling CAM consumers that the device is gone.
Sponsored by: Spectra Logic MFC after: 1 week
------------------------------------------------------------------------ r277514 | will | 2015-01-21 13:27:11 -0700 (Wed, 21 Jan 2015) | 18 lines
Force commit to record the correct log for r277513.
If the user sends an XPT_RESET_DEV CCB, make sure to reset the Fibre Channel Command Reference Number if we're running on a FC controller.
We send a SCSI Target Reset when we get this CCB, and as a result need to reset the CRN to 1 on the next command.
isp_freebsd.c: In the XPT_RESET_DEV implementation in isp_action(), reset the CRN if we're on a FC controller.
Submitted by: ken MFC after: 1 week Sponsored by: Spectra Logic MFSpectraBSD: 1112787 on 2015/01/15
------------------------------------------------------------------------ r277515 | will | 2015-01-21 13:32:36 -0700 (Wed, 21 Jan 2015) | 25 lines
Fix SCSI status byte reporting on 4Gb and 8Gb Qlogic boards.
The newer boards don't have the response field that indicates whether the SCSI status byte is present. You have to just look to see whether it is non-zero.
The code was looking to see whether the sense length was valid before propagating the SCSI status byte (and sense information) up the stack. With a status like Reservation Conflict, there is no sense information, only the SCSI status byte. So it wasn't getting correctly returned.
isp.c: In isp_intr(), if we are on a 2400 or 2500 type board and get a response, look at the actual contents of the SCSI status value and set the RQSF_GOT_STATUS flag accordingly so that return any SCSI status value we get. The RQSF_GOT_SENSE flag will get set later on if there is actual sense information returned.
Submitted by: ken MFC after: 1 week Sponsored by: Spectra Logic MFSpectraBSD: 1112791 on 2015/01/15
------------------------------------------------------------------------
Sponsored by: Spectra Logic
|
#
275443 |
|
03-Dec-2014 |
mav |
MFC r275123: Fix incorrect check, blocking MULTIID functionality.
|
#
263384 |
|
19-Mar-2014 |
dim |
MFC r259860 (by mjacob):
Harvest one no longer used constant string.
Remove another and place it into play in the normally ifdef protected zone it would be used int.
Noticed by: dim
|
#
260346 |
|
05-Jan-2014 |
mav |
MFC r257930: Some more registers access optimizations: - Process ATIO queue only if interrupt status tells so; - Do not update queue out pointers after each processed command, do it only once at the end of the loop.
|
#
260341 |
|
05-Jan-2014 |
mav |
MFC r256705: Optimize isp(4) to reduce CPU usage, especially in target mode: - Remove two excessive and slow register reads from isp_intr(). Instead of rereading value every time, assume that registers contain what we have written there. - Avoid sequential search through 4096 array elements when looking for command tag. Use hash of lists to store active tags separately from free ones and so greatly speedup the searches.
|
#
288717 |
|
05-Oct-2015 |
mav |
MFC r285600: MULTI_ID supported does not mean it is used.
|
#
288714 |
|
05-Oct-2015 |
mav |
MFC r285459: Unify port database use for target and initiator roles.
Aside from cleaner and more consistent code, this allows ports to be both target and initiator same time, and easily switch from any role to any.
|
#
288712 |
|
05-Oct-2015 |
mav |
MFC r285154: Remove extra level of target ID indirection (isp_dev_map).
FreeBSD never had limitation on number of target IDs, and there is no any other requirement to allocate them densely. Since slots of port database already populated just sequentially, there is no much need for another indirection to allocate sequentially too.
|
#
288709 |
|
05-Oct-2015 |
mav |
MFC r285146: Drop discovered targets when initiator role is disabled.
|
#
284907 |
|
28-Jun-2015 |
mav |
MFC r284808: Remove limitations on setting WWNNs starting from 2.
It is odd that driver first tries to generate synthetic WWNN based on WWPN starting from 2, but then refuses to use it. If we don't trust generated WWNN, we should probably not generate it. Same time this limitation prevents potentially valid WWNN setting by user.
|
#
284802 |
|
25-Jun-2015 |
mav |
MFC r284698: Dump additional config bytes for INIT_FIRMWARE_MULTI_ID.
|
#
284801 |
|
25-Jun-2015 |
mav |
MFC r284697: Add logging of executed mailbox command names.
Previously those commands were logged only as part of register dump, that is not very readable.
|
#
278171 |
|
03-Feb-2015 |
ken |
MFC isp(4) driver changes:
r276839, r276842, r277513, r277514, r277515
------------------------------------------------------------------------ r276839 | ken | 2015-01-08 10:41:28 -0700 (Thu, 08 Jan 2015) | 49 lines
Fix Fibre Channel Command Reference Number handling in the isp(4) driver.
The Command Reference Number is used for precise delivery of commands, and is part of the FC-Tape functionality set. (This is only enabled for devices that support precise delivery of commands.) It is an 8-bit unsigned number that increments from 1 to 255. The commands sent by the initiator must be processed by the target in CRN order if the CRN is non-zero.
There are certain scenarios where the Command Reference Number sequence needs to be reset. When the target is power cycled, for instance, the initiator needs to reset the CRN to 1. The initiator will know this because it will see a LIP (when directly connected) or get a logout/login event (when connected to a switch).
The isp(4) driver was not resetting the CRN when a target went away and came back. When it saw the target again after a power cycle, it would continue the CRN sequence where it left off. The target would ignore the command because the CRN sequence is supposed to be reset to 1 after a power cycle or other similar event.
The symptom that the user would see is that there would be lots of aborted INQUIRY commands after a tape library was power cycled, and the library would fail to probe. The INQUIRY commands were being ignored by the tape drive due to the CRN issue mentioned above.
isp_freebsd.c: Add a new function, isp_fcp_reset_crn(). This will reset all of the CRNs for a given port, or the CRNs for all LUNs on a target.
Reset the CRNs for all targets on a port when we get a LIP, loop reset, or loop down event.
Reset the CRN for a particular target when it arrives, is changed or departs. This is less precise behavior than the clearing behavior specified in the FCP-4 spec (which says that it should be reset for PRLI, PRLO, PLOGI and LOGO), but this is the level of information we have here. If this is insufficient, then we will need to add more precise notification from the lower level isp(4) code.
isp_freebsd.h: Add a prototype for isp_fcp_reset_crn().
Sponsored by: Spectra Logic MFC after: 1 week
------------------------------------------------------------------------ r276842 | ken | 2015-01-08 10:51:12 -0700 (Thu, 08 Jan 2015) | 44 lines
Close a race in the isp(4) driver that caused devices to disappear and not automatically come back if they were gone for a short period of time.
The isp(4) driver has a 30 second gone device timer that gets activated whenever a device goes away. If the device comes back before the timer expires, we don't send a notification to CAM that it has gone away. If, however, there is a command sent to the device while it is gone and before it comes back, the isp(4) driver sends the command back with CAM_SEL_TIMEOUT status.
CAM responds to the CAM_SEL_TIMEOUT status by removing the device. In the case where a device comes back within the 30 second gone device timer window, though, we weren't telling CAM the device came back.
So, fix this by tracking whether we have told CAM the device is gone, and if we have, send a rescan if it comes back within the 30 second window.
ispvar.h: In the fcportdb_t structure, add a new bitfield, reported_gone. This gets set whenever we return a command with CAM_SEL_TIMEOUT status on a Fibre Channel device.
isp_freebsd.c: In isp_done(), if we're sending CAM_SEL_TIMEOUT for for a command sent to a FC device, set the reported_gone bit.
In isp_async(), in the ISPASYNC_DEV_STAYED case, rescan the device in question if it is mapped to a target ID and has been reported gone.
In isp_make_here(), take a port database entry argument, and clear the reported_gone bit when we send a rescan to CAM.
In isp_make_gone(), take a port database entry as an argument, and set the reported_gone bit when we send an async event telling CAM consumers that the device is gone.
Sponsored by: Spectra Logic MFC after: 1 week
------------------------------------------------------------------------ r277514 | will | 2015-01-21 13:27:11 -0700 (Wed, 21 Jan 2015) | 18 lines
Force commit to record the correct log for r277513.
If the user sends an XPT_RESET_DEV CCB, make sure to reset the Fibre Channel Command Reference Number if we're running on a FC controller.
We send a SCSI Target Reset when we get this CCB, and as a result need to reset the CRN to 1 on the next command.
isp_freebsd.c: In the XPT_RESET_DEV implementation in isp_action(), reset the CRN if we're on a FC controller.
Submitted by: ken MFC after: 1 week Sponsored by: Spectra Logic MFSpectraBSD: 1112787 on 2015/01/15
------------------------------------------------------------------------ r277515 | will | 2015-01-21 13:32:36 -0700 (Wed, 21 Jan 2015) | 25 lines
Fix SCSI status byte reporting on 4Gb and 8Gb Qlogic boards.
The newer boards don't have the response field that indicates whether the SCSI status byte is present. You have to just look to see whether it is non-zero.
The code was looking to see whether the sense length was valid before propagating the SCSI status byte (and sense information) up the stack. With a status like Reservation Conflict, there is no sense information, only the SCSI status byte. So it wasn't getting correctly returned.
isp.c: In isp_intr(), if we are on a 2400 or 2500 type board and get a response, look at the actual contents of the SCSI status value and set the RQSF_GOT_STATUS flag accordingly so that return any SCSI status value we get. The RQSF_GOT_SENSE flag will get set later on if there is actual sense information returned.
Submitted by: ken MFC after: 1 week Sponsored by: Spectra Logic MFSpectraBSD: 1112791 on 2015/01/15
------------------------------------------------------------------------
Sponsored by: Spectra Logic
|
#
275443 |
|
03-Dec-2014 |
mav |
MFC r275123: Fix incorrect check, blocking MULTIID functionality.
|
#
263384 |
|
19-Mar-2014 |
dim |
MFC r259860 (by mjacob):
Harvest one no longer used constant string.
Remove another and place it into play in the normally ifdef protected zone it would be used int.
Noticed by: dim
|
#
260346 |
|
05-Jan-2014 |
mav |
MFC r257930: Some more registers access optimizations: - Process ATIO queue only if interrupt status tells so; - Do not update queue out pointers after each processed command, do it only once at the end of the loop.
|
#
260341 |
|
05-Jan-2014 |
mav |
MFC r256705: Optimize isp(4) to reduce CPU usage, especially in target mode: - Remove two excessive and slow register reads from isp_intr(). Instead of rereading value every time, assume that registers contain what we have written there. - Avoid sequential search through 4096 array elements when looking for command tag. Use hash of lists to store active tags separately from free ones and so greatly speedup the searches.
|