summaryrefslogtreecommitdiffstats
path: root/sys/dev/isp/isp.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC r313568:ken2017-02-131-13/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ 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 ------------------------------------------------------------------------
* MFC r300222: Fix delaying requests to unknown virtual ports 2s after init.mav2016-08-181-0/+5
| | | | | | | | | 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.
* MFC r300217: Add IOCB debugging for ISPCTL_RESET_DEV and ISPCTL_ABORT_CMD.mav2016-05-241-0/+8
|
* MFC r300058: Make RQCS_PORT_LOGGED_OUT for ZOMBIE ports retriable.mav2016-05-241-4/+18
| | | | | 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.
* MFC r300052: Completely remove broken now autologin port flag.mav2016-05-241-2/+1
| | | | | 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.
* MFC r299955: No need to check login status for ZOMBIE ports.mav2016-05-241-0/+3
| | | | ZOMBIE ports are always logged out, and so initiator may try to relogin.
* MFC r298103: Simplify memory allocation for NS requests.mav2016-05-031-33/+28
| | | | | | 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.
* MFC r297991: Extract virtual port address from RQSTYPE_RPT_ID_ACQ.mav2016-05-031-4/+12
| | | | | | 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.
* MFC r297915: Filter Port Database Changed notifications.mav2016-05-031-2/+9
| | | | | | | 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.
* MFC r297912: Respect NVRAM topology settings on 24xx and above chips.mav2016-05-031-16/+31
|
* MFC r297867: Make all CT Pass-Through (name server requests) asynchronous.mav2016-05-031-57/+78
| | | | | | | | 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.
* MFC r297859: Switch isp_getpdb() to synchronous IOCB DMA area.mav2016-05-031-18/+11
| | | | | While technically it is not IOCB, it is synchronous and can be called from different places, so calling FC_SCRATCH_ACQUIRE() here is inconvenient.
* MFC r297858: Allocate separate DMA area for synchronous IOCB execution.mav2016-05-031-37/+23
| | | | | | | | 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.
* MFC r297854: Add couple missing memory barriers.mav2016-05-031-1/+3
|
* MFC r297817: Polish debugging IOCB dumping.mav2016-05-031-27/+36
| | | | Add few more missing cases, unify byte order.
* MFC r297751: Register symbolic port/node names in FC name server.mav2016-05-031-6/+128
| | | | | | | 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.
* MFC r297741: Reduce code duplication when executing Passthrough IOCB.mav2016-05-031-187/+80
|
* MFC r292765: Allocate separate scratch space for scanner purposes.mav2015-12-301-113/+92
| | | | | | | | 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.
* MFC r292741: Make port logins asynchronous, following r292739 logic.mav2015-12-301-66/+55
| | | | | This is even more important since it involves more network operations and more prone to delays and timeouts.
* MFC r292739: Make virtual ports control asynchronous.mav2015-12-301-82/+96
| | | | | | | | | | | | 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.
* MFC r292725: Unify handles allocation for initiator and target IOCBs.mav2015-12-301-11/+5
| | | | | | 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.
* MFC r292715: Clear virtual port's port database when disabling it.mav2015-12-301-0/+153
| | | | | Previously it was done only on full chip reinit, that caused old ports resurrect in case of virtual port reenabling.
* MFC r292690: Some polishing for command timeouts handling.mav2015-12-301-15/+17
|
* MFC r292610: Fix speed setting by NVRAM for 24xx and above chips.mav2015-12-301-2/+26
|
* MFC r291654, r291727, r291821, r291872, r292034, r292041, r292249, r292042:mav2015-12-221-23/+46
| | | | Add initial support for 16Gbps FC QLogic chips.
* MFC r291365, r291369: One more round of port scanner rewrite.mav2015-11-301-40/+63
| | | | | | | - 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.
* MFC r291265: Rename ASYNC_LIP_F8 to ASYNC_LIP_NOS_OLS_RECV.mav2015-11-301-1/+1
| | | | New name better repsents its meaning for modern chips.
* MFC r291209: Fix target mode support for Qlogic 2200 FC adapters.mav2015-11-301-5/+9
| | | | | Now target mode works for all supported FC adapters except ancient 2100, which is not tested.
* MFC r291188: Rip off target mode support for parallel SCSI QLogic adapters.mav2015-11-301-34/+15
| | | | | | | 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.
* MFC r291163:mav2015-11-301-3/+18
| | | | | | | | 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.
* MFC r291161: Gracefully stop firmware before resetting chip when changing role.mav2015-11-301-2/+25
|
* MFC r291160: Add some more asynchronous event status codes.mav2015-11-301-4/+22
|
* MFC r291159: Add more mailbox command codes.mav2015-11-301-30/+30
|
* MFC r291144: Fix target mode with fabric for pre-24xx chips.mav2015-11-301-13/+63
| | | | | | | 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.
* MFC r291099: Some cosmetics for ancient cards.mav2015-11-301-3/+7
|
* MFC r291092: Optimize SNS_GID_FT request scratch memory usage.mav2015-11-301-13/+14
| | | | Now with present 4K of scratch we can fetch up to 508 ports (16 more).
* MFC r291080: Another round of port scanner rewrite.mav2015-11-301-578/+221
| | | | | | 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.
* MFC r291014: Simplify fabric tasting code.mav2015-11-301-87/+22
| | | | | 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.
* MFC r291013: Remove some confusions between loopid and nphdl.mav2015-11-301-21/+21
| | | | | | | | 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.
* MFC r291000: Register our FC4 Features in SNS.mav2015-11-301-0/+122
|
* MFC r290993, r290994: Unify and cleanup FC ports scan.mav2015-11-301-187/+130
|
* MFC r290981: Off-by-one correctiont to r290980.mav2015-11-301-1/+1
|
* MFC r290980: Make firmware handle virtual ports SNS logins for us.mav2015-11-301-14/+6
|
* MFC r290978: Add real initial support for RQSTYPE_RPT_ID_ACQ.mav2015-11-301-9/+20
|
* MFC r290507: Rework r290504.mav2015-11-301-3/+5
|
* MFC r290506: Specify VP when sending a marker.mav2015-11-301-0/+1
|
* MFC r290504: Make ISP_SLEEP() really sleep instead of spinning.mav2015-11-301-47/+6
| | | | While there, simplify the wait logic.
* MFC r290160: Remove some unneeded code.mav2015-11-301-4/+0
|
* MFC r290159: Remove reset delays for which I see neither explanation nor need.mav2015-11-301-25/+7
|
* MFC r290147: Fix and improve error masking and reporting.mav2015-11-301-41/+45
|
OpenPOWER on IntegriCloud