summaryrefslogtreecommitdiffstats
path: root/sys/dev/isp
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, r310338:ken2016-12-231-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r310338 | ken | 2016-12-20 14:17:07 -0700 (Tue, 20 Dec 2016) | 37 lines Turn on FC-Tape by default in the isp(4) driver. FC-Tape provides additional link level error recovery, and is highly recommended for tape devices. It will only be turned on for a given target if the target supports it. Without this setting, we default to whatever FC-Tape setting is in NVRAM on the card. This can be overridden by setting the following loader tunable, for example for isp0: hint.isp.0.nofctape=1 sys/conf/options: Add a new kernel config option, ISP_FCTAPE_OFF, that defaults the FC-Tape configuration to off. sys/dev/isp/isp_pci.c: If ISP_FCTAPE_OFF is defined, turn off FC-Tape. Otherwise, turn it on if the card supports it. share/man/man4/isp.4: Add a description of FC-Tape to the isp(4) man page. Add descriptions of the fctape and nofctape options, as well as the ISP_FCTAPE_OFF kernel configuration option. Add the ispfw module and kernel drivers to the suggested configurations at the top of the man page so that users are less likely to leave it out. The driver works well with the included firmware, but may not work at all with whatever firmware the user has flashed on their card. Sponsored by: Spectra Logic ------------------------------------------------------------------------ Sponsored by: Spectra Logic
* MFC r300296: Pass proper for 23xx arguments to isp_endcmd().mav2016-08-181-1/+1
|
* MFC r300293:mav2016-08-181-5/+15
| | | | | | | | Pass task management response information from CTL through CAM to isp(4), utilizing previously unused arg field of struct ccb_notify_acknowledge. This makes new QUERY TASK, QUERY TASK SET and QUERY ASYNC EVENT requests really functional for CAM target mode drivers.
* MFC r300222: Fix delaying requests to unknown virtual ports 2s after init.mav2016-08-182-1/+6
| | | | | | | | | 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 r300218: Add proper reporting for early task management errors.mav2016-05-243-6/+21
| | | | | This covers unknown requests and requests to unknown virtual ports. Previously it "worked" only because of timeout handling on initiator.
* MFC r300217: Add IOCB debugging for ISPCTL_RESET_DEV and ISPCTL_ABORT_CMD.mav2016-05-241-0/+8
|
* MFC r300157: Unify Multi ID target code by reusing isp_find_chan_by_did().mav2016-05-241-10/+9
|
* 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-243-9/+4
| | | | | 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 r299957: Reduce verbosity of "now sending synthesized status" message.mav2016-05-241-1/+1
|
* 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 r299691: Fix FCP_CMD LENGTH mask in ATIO7 IOCB.mav2016-05-241-1/+1
| | | | This caused "long IU length (16384) ignored" errors following by others.
* 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-033-14/+24
| | | | | | 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-032-2/+10
| | | | | | | 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-032-21/+37
|
* 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-034-39/+70
| | | | | | | | 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 r297856: Reimplement ISP_TSK_MGMT IOCTL via asynchronous request.mav2016-05-031-44/+59
| | | | | I am not sure this code is not completely dead, but it used DMA scratch are without good reason and asked to be refactored.
* MFC r297854: Add couple missing memory barriers.mav2016-05-031-1/+3
|
* MFC r297817: Polish debugging IOCB dumping.mav2016-05-032-31/+42
| | | | Add few more missing cases, unify byte order.
* MFC r297751: Register symbolic port/node names in FC name server.mav2016-05-036-6/+181
| | | | | | | 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-302-114/+95
| | | | | | | | 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 r292764: Split DMA buffers for request, response and ATIO queues.mav2015-12-303-180/+222
|
* MFC r292745: Use single DMA tag for scratch areas of all virtual ports.mav2015-12-302-28/+32
|
* 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-303-87/+111
| | | | | | | | | | | | 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-307-191/+60
| | | | | | 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-303-165/+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-303-20/+23
|
* 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-226-142/+281
| | | | Add initial support for 16Gbps FC QLogic chips.
* MFC r291868: Rework WWNs generation to make cards without NVRAM more useful.mav2015-12-221-67/+28
|
* MFC r291730: Update isp_put_icb_2400() for new structure fields.mav2015-12-221-3/+10
|
* MFC r291365, r291369: One more round of port scanner rewrite.mav2015-11-306-266/+181
| | | | | | | - 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-303-3/+3
| | | | New name better repsents its meaning for modern chips.
* MFC r291221: Remove "disable" hint, which duplicates system-wide "disabled".mav2015-11-303-34/+0
|
* MFC r291209: Fix target mode support for Qlogic 2200 FC adapters.mav2015-11-305-12/+20
| | | | | 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-309-1542/+127
| | | | | | | 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 r291162: Generate fake ISPASYNC_CHANGE_PDB on fake login on pre-24xx.mav2015-11-301-1/+7
| | | | This makes port scanner fix absent port ID for added initiator.
* 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-302-23/+45
|
* MFC r291159: Add more mailbox command codes.mav2015-11-302-47/+74
|
* MFC r291147: Increase maximal value of vports tunable to 254.mav2015-11-301-1/+1
| | | | | I am not sure this value is really viable yet, but that is what chips officially support in NPIV mode (in loop mode maximum is 125).
* MFC r291144: Fix target mode with fabric for pre-24xx chips.mav2015-11-304-19/+70
| | | | | | | 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
|
OpenPOWER on IntegriCloud