FreeBSD source tree https://cgit-dev.freebsd.org/src-test2/atom?h=release%2F11.4.0 2020-04-28T20:14:38Z 2020-04-28T20:14:38Z Brooks Davis brooks@FreeBSD.org 2020-04-28T20:14:38Z urn:sha1:304301b2441e15870e530f3a8b6fa8169b16e3ee Centralize compatability translation macros. Copy the CP, PTRIN, etc macros from freebsd32.h into a sys/abi_compat.h and replace existing definitation with includes where required. This eliminates duplicate code and allows Linux and FreeBSD compatability headers to be included in the same files. Obtained from: CheriBSD Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D24275 2020-03-27T13:29:53Z Alexander Motin mav@FreeBSD.org 2020-03-27T13:29:53Z urn:sha1:4ab85e6ce05df968ac53d79e8def5e1246cf5240 192 bytes are not enough to print long commands, such as ATA COMMAND PASS THROUGH(16), that makes debug output difficult to read. 2018-11-13T18:49:43Z Scott Long scottl@FreeBSD.org 2018-11-13T18:49:43Z urn:sha1:b639b5bc3953f66c5bd2f5c894c61d686ab049cd allocation to fail. While here, refactor the code so that it's more clear and less likely to break in the future. This is not an MFC due to the code in 12/head being very different, but it follows the latter's structure more closely than before. Reported by: Harry Schmalzbauer 2018-03-31T19:18:07Z Steven Hartland smh@FreeBSD.org 2018-03-31T19:18:07Z urn:sha1:7f8aeb21e124a522ae3f9457e8deef826ed70482 Fix mps deadlock when handling panic Sponsored by: Multiplay 2018-03-29T02:50:57Z Eitan Adler eadler@FreeBSD.org 2018-03-29T02:50:57Z urn:sha1:4ab2e064d7950be84256d671a7ae93f87cc6aa36 This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code. Revert with prejudice. This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes. Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes. Requested by: gjb (re) 2018-03-27T20:34:49Z Kenneth D. Merry ken@FreeBSD.org 2018-03-27T20:34:49Z urn:sha1:b0416ce3cee402a1716ac4f21c6383319fee45c3 ------------------------------------------------------------------------ r331422 | ken | 2018-03-23 07:52:26 -0600 (Fri, 23 Mar 2018) | 42 lines Disable T10 Protection Information / EEDP handling for type 2 protection. The mps(4) and mpr(4) drivers and hardware handle T10 Protection Information, which is a system of checksums and guard blocks to protect data while it is being transferred and while it is on disk. It is also known as T10 DIF. For more details, see section 4.22 of the SBC-4 spec. Supporting Type 2 protection requires using 32 byte CDBs, and filling in the fields in those CDBs. We don't yet support that in the da(4) driver. Type 1 and Type 3 protection don't require that, and can be handled by the mps(4)/mpr(4) driver's code and firmware without any additional input from the da(4) driver. If a drive has Type 2 protection enabled (you frequently see this with SAS drives shipped from Dell), don't set the various EEDP fields in the mps(4)/mpr(4) driver command fields. Otherwise, you wind up with errors like this that would otherwise make no sense: (da9:mpr0:0:18:0): READ(10). CDB: 28 00 00 00 00 00 00 02 00 00 (da9:mpr0:0:18:0): CAM status: SCSI Status Error (da9:mpr0:0:18:0): SCSI status: Check Condition (da9:mpr0:0:18:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (da9:mpr0:0:18:0): (da9:mpr0:0:18:0): Field Replaceable Unit: 0 (da9:mpr0:0:18:0): Command Specific Info: 0 (da9:mpr0:0:18:0): (da9:mpr0:0:18:0): Descriptor 0x80: f8 21 (da9:mpr0:0:18:0): Descriptor 0x81: 00 00 00 00 00 00 (da9:mpr0:0:18:0): Error 22, Unretryable error In other words, what kind of strange SAS hard drive doesn't support a standard 10 byte SCSI READ command? In this case, one that has Type 2 protection enabled. We can revisit this when we put Type 2 protection support in the da(4) driver, but for now this will help people who put Type 2 formatted drives in a system and wonder what in the world is going on. Sponsored by: Spectra Logic ------------------------------------------------------------------------ 2018-03-14T03:19:51Z Eitan Adler eadler@FreeBSD.org 2018-03-14T03:19:51Z urn:sha1:be5d0b9566b13fdf8cabebb63334cbec12bfc409 These changes are incomplete but are making it difficult to determine what other changes can/should be merged. No objections from: pfg 2018-02-13T02:11:39Z Alexander Motin mav@FreeBSD.org 2018-02-13T02:11:39Z urn:sha1:106782d7caba4b4e87e077240d0a7cd4d3a49ae3 Both drivers were found to report CAM bigger queue depth then they really can handle. It made them later under high load with many disks return some of submitted requests back with CAM_REQUEUE_REQ status for later resubmission. 2017-08-18T14:25:07Z Kenneth D. Merry ken@FreeBSD.org 2017-08-18T14:25:07Z urn:sha1:b9db7df1b6b088561c8918750fa25f2515c645be ------------------------------------------------------------------------ r321502 | scottl | 2017-07-25 19:48:13 -0600 (Tue, 25 Jul 2017) | 2 lines Quiet a message that sounds far more dire than it really is. ------------------------------------------------------------------------ r321714 | scottl | 2017-07-30 00:53:58 -0600 (Sun, 30 Jul 2017) | 13 lines Split the interrupt setup code into two parts: allocation and configuration. Do the allocation before requesting the IOCFacts message. This triggers the LSI firmware to recognize the multiqueue should be enabled if available. Multiqueue isn't used by the driver yet, but this also fixes a problem with the cached IOCFacts not matching latter checks, leading to potential problems with error recovery. As a side-effect, fetch the driver tunables as early as possible. Reviewed by: slm Obtained from: Netflix Differential Revision: D9243 ------------------------------------------------------------------------ r321733 | scottl | 2017-07-30 16:34:24 -0600 (Sun, 30 Jul 2017) | 5 lines Change from using underbar function names to normal function names for the informational print functions. Collapse the debug API a bit to be more generic and not require as much code duplication. While here, fix a bug in MPS that was already fixed in MPR. ------------------------------------------------------------------------ r321737 | scottl | 2017-07-30 18:05:49 -0600 (Sun, 30 Jul 2017) | 3 lines Don't re-parse PCI IDs in order to set card-specific flags, use the flags field in the PCIID table. ------------------------------------------------------------------------ r321799 | scottl | 2017-07-31 10:55:56 -0600 (Mon, 31 Jul 2017) | 4 lines Fix a logic bug in the split PCI interrupt code that slipped through Reported by: Harry Schmalzbauer ------------------------------------------------------------------------ r322364 | ken | 2017-08-10 08:59:17 -0600 (Thu, 10 Aug 2017) | 39 lines Changes to make mps(4) and mpr(4) handle reinit with reallocation. When the mps(4) and mpr(4) drivers need to reinitialize the firmware, they sometimes need to reallocate all of the memory allocated by the driver. The reallocation happens whenever the IOC Facts change. That should only happen after a firmware upgrade. If the reinitialization happens as a result of a timed out command sent to the card, the command that timed out and triggered the reinit may have been freed if iocfacts_allocate() reallocated all memory. If the caller attempts to access the command after that, the kernel will panic because the caller will be dereferencing freed memory. The solution is to set a flag in the softc when we reallocate, and avoid dereferencing the command strucure if we've reallocated. The changes are largely the same in both drivers, since mpr(4) is a derivative of mps(4). o In iocfacts_allocate(), if the IOC Facts have changed and we need to reallocate, set the REALLOCATED flag in the softc. o Change wait_command() to take a struct mps_command ** instead of a struct mps_command *. This allows us to NULL out the caller's command pointer if we have to reinit the controller and the data structures get reallocated. (The REALLOCATED flag will be set in the softc if that has happened.) o In every place that calls wait_command(), make sure we handle the case where the command is NULL after the call. o The mpr(4) driver has mpr_request_polled() which can also reinitialize the card. Also check for reallocation there. Reviewed by: scottl, slm Sponsored by: Spectra Logic ------------------------------------------------------------------------ 2017-07-24T14:42:43Z Kenneth D. Merry ken@FreeBSD.org 2017-07-24T14:42:43Z urn:sha1:564c32bd3a23d82ac79f8102a3345921dcd531bf ------------------------------------------------------------------------ r321207 | ken | 2017-07-19 09:39:01 -0600 (Wed, 19 Jul 2017) | 14 lines Fix spurious timeouts on commands sent to mps(4) and mpr(4) controllers. mps_wait_command() and mpr_wait_command() were using getmicrotime() to determine elapsed time when checking for a timeout in polled mode. getmicrotime() isn't guaranteed to monotonically increase, and that caused spurious timeouts occasionally. Switch to using getmicrouptime(), which does increase monotonically. This fixes the spurious timeouts in my test case. ------------------------------------------------------------------------ Reviewed by: slm, scottl Sponsored by: Spectra Logic