From nobody Wed Jan 12 16:19:12 2022 X-Original-To: freebsd-scsi@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CFE81193B542 for ; Wed, 12 Jan 2022 16:19:35 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (mithlond.kdm.org [96.89.93.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mithlond.kdm.org", Issuer "mithlond.kdm.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JYt7B56N8z4S6T for ; Wed, 12 Jan 2022 16:19:34 +0000 (UTC) (envelope-from ken@kdm.org) Received: from mithlond.kdm.org (localhost [127.0.0.1]) by mithlond.kdm.org (8.15.2/8.14.9) with ESMTPS id 20CGJDda032224 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Jan 2022 11:19:13 -0500 (EST) (envelope-from ken@mithlond.kdm.org) Received: (from ken@localhost) by mithlond.kdm.org (8.15.2/8.15.2/Submit) id 20CGJCdl032223; Wed, 12 Jan 2022 11:19:12 -0500 (EST) (envelope-from ken) Date: Wed, 12 Jan 2022 11:19:12 -0500 From: "Kenneth D. Merry" To: Douglas Gilbert Cc: Gerrit Kuehn , freebsd-scsi@FreeBSD.org Subject: Re: Broadcom 3808 support Message-ID: <20220112161912.GA31353@mithlond.kdm.org> References: <20220106112904.2ed0eba2@comet2.terra.ger> <20220110203150.GA93020@mithlond.kdm.org> <20220110222230.1f24d9af@comet2.terra.ger> <20220110214019.GA93940@mithlond.kdm.org> <61684bd2-e557-f1be-d9f1-6345dde8f1a0@interlog.com> List-Id: SCSI subsystem List-Archive: https://lists.freebsd.org/archives/freebsd-scsi List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61684bd2-e557-f1be-d9f1-6345dde8f1a0@interlog.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mithlond.kdm.org [127.0.0.1]); Wed, 12 Jan 2022 11:19:14 -0500 (EST) X-Spam-Status: No, score=-2.7 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mithlond.kdm.org X-Rspamd-Queue-Id: 4JYt7B56N8z4S6T X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of ken@kdm.org designates 96.89.93.250 as permitted sender) smtp.mailfrom=ken@kdm.org X-Spamd-Result: default: False [-2.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.969]; FREEFALL_USER(0.00)[ken]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mithlond.kdm.org]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[FreeBSD.ORG]; NEURAL_HAM_LONG(-0.99)[-0.995]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[ken@FreeBSD.ORG,ken@kdm.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7922, ipnet:96.64.0.0/11, country:US]; FROM_NEQ_ENVFROM(0.00)[ken@FreeBSD.ORG,ken@kdm.org]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jan 10, 2022 at 21:37:03 -0500, Douglas Gilbert wrote: > On 2022-01-10 4:40 p.m., Kenneth D. Merry wrote: > > On Mon, Jan 10, 2022 at 22:22:30 +0100, Gerrit Kuehn wrote: > >> On Mon, 10 Jan 2022 15:31:51 -0500 > >> "Kenneth D. Merry" wrote: > >> > >> Hello Ken, > >> > >>> To put it in different words, what Sreekanth was trying to say in the > >>> message linked above is that Broadcom commits their driver changes > >>> directly to the FreeBSD source tree. So, "inbox" means the driver is > >>> "in the OS box", as it would have been back in the days when you > >>> bought an OS from a store on CDROM. > >>> > >>> They used to provide an "out of box" driver that you could download on > >>> their web site, but they don't provide that anymore. They'll just > >>> tell you it works with FreeBSD as-is, so the downloadable driver > >>> isn't needed. > >> > >> Ah, I see. Thanks for the explanation. I found downloadable drivers and > >> firmware quite handy in the past as a fall-back option in case the one > >> bundled with the OS didn't work properly (had to do that once or twice, > >> but that was something like 10y+ ago). > >> > >>> The last time they added PCI IDs to the mpr(4) driver was in December > >>> 2018. So, FreeBSD 12.3 or 13.0 should work with it, as would a number > >>> of earlier releases. If you want a precise answer, that will take > >>> more digging through the tree to figure out. You would need to look > >>> at sys/dev/mpr/mpr_pci.c in the branch you're interested in. > >> > >> That's already everything I wanted to know, actually. Thank you very > >> much again. > >> I had looked into the source tree of the mpr driver in 13.0, but > >> somehow failed to find references to the 3808 chipset (just had looked > >> for "3808" as a string, which isn't there, in contrast to 3816 - but > >> maybe that was a too shallow idea on my side :-). The 38* chipsets also > >> aren't mentioned in the mpr manpage at all - maybe that one isn't > >> up-to-date then (although it claims to be from June 1, 2019 here)? > > > > Yes, it looks like Steve McConnell (who used to be the Broadcom maintainer, > > but moved to their firmware group) was the last one to update the list of > > supported devices in 2017. > > > > So the man page is indeed out of date. > > > > The mpr(4) driver supports all of their 12Gb SAS (non-RAID) chips as far > > as I know. > > > > I think the last two digits of their SAS chip and board model names are > > the number of SAS lanes. > > Any word of SAS-4 support from Broadcomm? Their new boards are going to combine SAS and RAID functionality, they're going to call the interface MPI 3.0: https://www.spinics.net/lists/linux-scsi/msg147868.html They're working on a FreeBSD driver, and intend to put it into the tree, but we don't have it yet. It has been a few weeks since I last heard from them, my assumption is they're still getting it finished up. The mpi3mr driver is already in Linux. > I have a Adaptec (Microsemi) HBA 1200 (PCIe 4 SAS-4(/NVMe/SATA)) and this page: > https://storage.microsemi.com/en-us/support/sas/sas/aha-1200-8i/ > > references a "SmartPQI 64-bit Driver for FreeBSD 11, 12 & 13". Has anyone > tested that driver? The hardware seems to work fine on Linux. One new feature > (that I had not seen previously) is that the HBA itself presents a SES device > internally (i.e. it can't be seen by on another initiator connected to the > same expander). There is a SmartPQI driver in FreeBSD, see sys/dev/smartpqi. I don't know whether it supports that card or not. Looks like it was last updated with new hardware support (by Microsemi via Warner Losh) in May 2021. The binary-only driver on their web site is from November. If you get the PCI ID for that card, you could look through the driver in the FreeBSD tree and see if it supports the card. > From the machine with the HBA 1200 installed I see: > > # sg_ses -af /dev/sg3 > Adaptec Smart Adapter 0107 > Primary enclosure logical identifier (hex): > Internal Device [0,-1] Element type: Array device slot > Enclosure Status: > Predicted failure=0, Disabled=0, Swap=0, status: OK > Controller Temperature Sensors [1,-1] Element type: Temperature sensor > Enclosure Status: > Predicted failure=0, Disabled=0, Swap=0, status: OK > Temperature=35 C > emc_1414_int:0:0:Inlet Ambient [1,0] Element type: Temperature sensor > Enclosure Status: > Predicted failure=0, Disabled=0, Swap=0, status: OK > Temperature=29 C > emc_1414_ext1:1:1:Chip ASIC [1,1] Element type: Temperature sensor > Enclosure Status: > Predicted failure=0, Disabled=0, Swap=0, status: OK > Temperature=35 C > emc_1414_ext2:2:2:Vendor define [1,2] Element type: Temperature sensor > Enclosure Status: > Predicted failure=0, Disabled=0, Swap=0, status: OK > Temperature=30 C > emc_1414_ext3:3:3:Vendor define [1,3] Element type: Temperature sensor > Enclosure Status: > Predicted failure=0, Disabled=0, Swap=0, status: OK > Temperature=34 C > > So it has 4 different temperature sensors on the card! Those figures are with > a fan attached to its heatsink. Without that fan (and with no other air blowing > on that card), I have seen temperatures above 70C. So a fan is needed (as > MicroSemi recommend). Interesting! From the picture on the web site the heat sink looks huge. Too bad they don't try to emulate drive slots in the onboard SES device, but I guess they really can't figure that out. I've got an enclosure that has a bunch of cabled slots, no expander and therefore no SES. In order to map drives to physical slots, it requires the enclosure to be cabled the same way every time from the factory, and then hard-coding the mapping via the target ID/SAS controller lane. Ken -- Kenneth Merry ken@FreeBSD.ORG