FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F12.3.0 2020-12-08T00:58:02Z 2020-12-08T00:58:02Z Alexander Motin mav@FreeBSD.org 2020-12-08T00:58:02Z urn:sha1:fe7427eb08cc699e6b438626f6c97cee665069cb 2020-11-24T13:17:12Z Alexander Motin mav@FreeBSD.org 2020-11-24T13:17:12Z urn:sha1:4b74fa5dd5aef9786aee4f9359be15b9da9a096d SAM-3 specification introduced concept of Task Priority, that was renamed to Command Priority in SAM-4, and supported by all modern SCSI transports. It provides 15 levels of relative priorities: 1 - highest, 15 - lowest and 0 - default. SAT specification for SATA devices translates priorities 1-3 into NCQ high priority. This change adds new "priority" field into empty spots of struct ccb_scsiio and struct ccb_accept_tio of CAM and struct ctl_scsiio of CTL. Respective support is added into iscsi(4), isp(4), mpr(4), mps(4) and ocs_fc(4) drivers for both initiator and where applicable target roles. Minimal support was added to CTL to receive the priority value from different frontends, pass it between HA controllers and report in few places. This patch does not add consumers of this functionality, so nothing should really change yet, since the field is still set to 0 (default) on initiator and not actively used on target. Those are to be implemented separately. I've confirmed priority working on WD Red SATA disks connected via mpr(4) and properly transferred to CTL target via iscsi(4), isp(4) and ocs_fc(4). While there, added missing tag_action support to ocs_fc(4) initiator role. 2019-05-31T20:15:29Z Kenneth D. Merry ken@FreeBSD.org 2019-05-31T20:15:29Z urn:sha1:7aacf0554b29d47d340eccf6dca1b31eba35dd61 ------------------------------------------------------------------------ r348247 | ken | 2019-05-24 13:58:29 -0400 (Fri, 24 May 2019) | 57 lines Fix FC-Tape bugs caused in part by r345008. The point of r345008 was to reset the Command Reference Number (CRN) in some situations where a device stayed in the topology, but had changed somehow. This can include moving from a switch connection to a direct connection or vice versa, or a device that temporarily goes away and comes back. (e.g. moving to a different switch port) There were a couple of bugs in that change: - We were reporting that a device had not changed whenever the Establish Image Pair bit was not set. That is not quite correct. Instead, if the Establish Image Pair bit stays the same (set or not), the device hasn't changed in that way. - We weren't setting PRLI Word0 in the port database when a new device arrived, so comparisons with the old value for the Establish Image Pair bit weren't really possible. So, make sure PRLI Word0 is set in the port database for new devices. - We were resetting the CRN whenever the Establish Image Pair bit was set for a device, even when the device had stayed the same and the value of the bit hadn't changed. Now, only reset the CRN for devices that have changed, not devices that sayed the same. The result of all of this was that if we had a single FC device on an FC port and it went away and came back, we would wind up correctly resetting the CRN. But, if we had multiple devices connected via a switch, and there was any change in one or more of those devices, all of the devices that stayed the same would also have their CRN values reset. The result, from a user standpoint, is that the tape drives, etc. would all start to time out commands and the initiator would send aborts. sys/dev/isp/isp.c: In isp_pdb_add_update(), look at whether the Establish Image Pair bit has changed as part of the check to determine whether a device is still the same. This was causing erroneous change notifications. Also, when creating a new port database entry, initialize the PRLI Word 0 values. sys/dev/isp/isp_freebsd.c: In isp_async(), in the changed/stayed case, instead of looking at the Establish Image Pair bit to determine whether to reset the CRN, look at the command value. (Changed vs. Stayed.) Only reset the CRN for devices that have changed. ------------------------------------------------------------------------ Sponsored by: Spectra Logic 2019-05-17T14:29:56Z Kenneth D. Merry ken@FreeBSD.org 2019-05-17T14:29:56Z urn:sha1:5d949247b7e2a50cd8bba156bf4d09db6176c5a3 ------------------------------------------------------------------------ r345008 | ken | 2019-03-11 10:21:14 -0400 (Mon, 11 Mar 2019) | 59 lines Fix CRN resets in the isp(4) driver in certain situations. The Command Reference Number (CRN) is part of the FC-Tape features that we enable when talking to tape drives. It starts at 1, and goes to 255 and wraps around to 1. There are a number of reset type conditions that result in the CRN getting reset to 1. These are detailed in section 4.10 (table 8) of the FCP-4r02b specification. One of the conditions is when a PRLI (Process Login) is sent by the initiator, and the Establish Image Pair bit is set in Word 0 of the PRLI. Previously, the isp(4) driver core sent a notification via isp_async() that the target had changed or stayed in place, but there was no indication of whether a PRLI was sent and whether the Establish Image Pair bit was set. The result of this was that in some situations, notably switching back and forth between a direct connection and a switch connection to a tape drive, the isp(4) driver would fail to reset the CRN in situations that require it according to the spec. When the CRN isn't reset in a situation that requires it, the tape drive then rejects every subsequent command that is sent to the drive. It is assuming that the commands are being sent out of order. So, modify the isp(4) driver to include Word 0 of the PRLI command when it sends isp_async() notifications of target changes. Look at the Establish Image Pair bit, and reset the CRN if that bit is set. With this change, I am able to switch a tape drive back and forth between a direct connection and a switch connection, and the isp(4) driver resets the CRN when it should. sys/dev/isp_stds.h: Add bit definitions for PRLI Word 0. sys/dev/ispmbox.h: Add PRLI Word 0 to the port database type, isp_pdb_t. sys/dev/ispvar.h Add PRLI Word 0 to fcportdb_t. sys/dev/isp.c: Populate the new prli_word0 parameter in the port database. In isp_pdb_add_update(), add a check to see if the Establish Image Pair bit is set in PRLI Word 0. If it is, then that is an additional reason to create a change notification. sys/dev/isp_freebsd.c: In isp_async(), if the device changed or stayed, look at PRLI Word 0 to see if the Establish Image Pair bit is set. If it is, reset the CRN if we haven't already. Sponsored by: Spectra Logic ------------------------------------------------------------------------ Differential Revision: https://reviews.freebsd.org/D19472 2019-03-08T00:56:07Z Alexander Motin mav@FreeBSD.org 2019-03-08T00:56:07Z urn:sha1:4a611c712882ac9ab5d07c594aa82f2561e5bcaf This was actually the known good configuration we used before. Single MSI-X configuration doesn't even work there on my tests, just due to lack of documentation not sure whether by design or I am doing something wrong. 2019-03-08T00:54:34Z Alexander Motin mav@FreeBSD.org 2019-03-08T00:54:34Z urn:sha1:83d9b5559bedab547d7b05cc2f194283bdb47dc7 There are some problem reports possibly related to the new driver use of multiple interrupts on older cards. Hopefully this allow to workaround them. 2018-07-30T15:46:40Z Alan Somers asomers@FreeBSD.org 2018-07-30T15:46:40Z urn:sha1:6040822c4e20fb46638ecaaad543fc56f6ec2b0f The timespecadd(3) family of macros were imported from NetBSD back in r35029. However, they were initially guarded by #ifdef _KERNEL. In the meantime, we have grown at least 28 syscalls that use timespecs in some way, leading many programs both inside and outside of the base system to redefine those macros. It's better just to make the definitions public. Our kernel currently defines two-argument versions of timespecadd and timespecsub. NetBSD, OpenBSD, and FreeDesktop.org's libbsd, however, define three-argument versions. Solaris also defines a three-argument version, but only in its kernel. This revision changes our definition to match the common three-argument version. Bump _FreeBSD_version due to the breaking KPI change. Discussed with: cem, jilles, ian, bde Differential Revision: https://reviews.freebsd.org/D14725 2018-03-15T01:07:21Z Alexander Motin mav@FreeBSD.org 2018-03-15T01:07:21Z urn:sha1:db08ef43532879300dd6ea7903b8a9e0f5d7624b It seems default timeout of 100ms is not enough for my 2694L card, while it was perfectly fine for others, even for full-height 2694. MFC after: 1 week Sponsored by: iXsystems, Inc. 2018-03-13T19:56:10Z Brooks Davis brooks@FreeBSD.org 2018-03-13T19:56:10Z urn:sha1:8037cdcd9ab4f8e62ceabdded0f43afb2a11df0f For _IO() ioctls, addr is a pointer to uap->data which is a caddr_t. When the caddr_t stores an int, dereferencing addr as an (int *) results in truncation on little-endian 64-bit systems and corruption (owing to extracting top bits) on big-endian 64-bit systems. In practice the value of chan was probably always zero on systems of the latter type as all such FreeBSD platforms use a register-based calling convention. Reviewed by: mav Obtained from: CheriBSD MFC after: 1 week Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D14673 2018-02-28T16:24:32Z Alexander Motin mav@FreeBSD.org 2018-02-28T16:24:32Z urn:sha1:14e084ada59512441c9bb701303aac337aade61c MFC after: 2 weeks Sponsored by: iXsystems, Inc.