Date: Tue, 25 Apr 2023 11:44:49 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 271062] [PATCH] add support for 28xx based device to isp(4) Message-ID: <bug-271062-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271062 Bug ID: 271062 Summary: [PATCH] add support for 28xx based device to isp(4) Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: Joerg.Pulz@frm2.tum.de Flags: mfc-stable13? Created attachment 241735 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D241735&action= =3Dedit patch for CURRENT and RELENG-13.2 Add support for QLogic devices based on 28xx to isp(4) namely: ISP2812-based 64/32G Fibre Channel to PCIe Controller: QLE2770 Single Port 32GFC PCIe Gen4 x8 Adapter QLE2772 Dual Port 32GFC PCIe Gen4 x8 Adapter QLE2870 Single Port 64GFC PCIe Gen4 x8 Adapter QLE2872 Dual Port 64GFC PCIe Gen4 x8 Adapter ISP2814-based 64/32G Fibre Channel to PCIe Controller: QLE2774 Quad Port 32GFC PCIe Gen4 x16 Adapter QLE2874 Quad Port 64GFC PCIe Gen4 x16 Adapter The attached patch enables device detection and adds support for 64GB FC. Sample dmesg(8) output of an ISP2812-based "QLE2772 Dual Port 32GFC PCIe Ge= n4 x8 Adapter" with an 16GBit/s storage attached: ----- isp0: <Qlogic ISP 2812 PCI FC Adapter> mem 0xeea05000-0xeea05fff,0xeea02000-0xeea03fff,0xee900000-0xee9fffff at device= 0.0 numa-domain 1 on pci13 isp0: Board Type 2800, Chip Revision 0x2, resident F/W Revision 9.4.1 isp0: Attributes: Class2 MultiID T10CRC MQ MSIX VP0_Decoupling HotFW EXMOFF NPMOFF DIFCHOP ASICTMP ATIOMQ (unknown 0x0000162078020000) isp0: 2048 max I/O command limit set isp0: invalid NVRAM header (ff ff ff) isp0: invalid NVRAM header (ff ff ff) isp0: Chan 0 0x400000007f000000/0x410000007f000000 Role Initiator isp0: bad frame length (0) from NVRAM - using 2048 isp1: <Qlogic ISP 2812 PCI FC Adapter> mem 0xeea04000-0xeea04fff,0xeea00000-0xeea01fff,0xee800000-0xee8fffff at device= 0.1 numa-domain 1 on pci13 isp1: invalid NVRAM header (ff ff ff) isp1: invalid NVRAM header (ff ff ff) isp1: bad frame length (0) from NVRAM - using 2048 isp0: Chan 0 LIP Received isp0: Chan 0 LIP Received isp0: Chan 0 LOOP Up isp0: Chan 0 Port Database Changed (nphdl 0xffff state 0x6 reason 0x0) isp0: Chan 0 Firmware state <Config Wait->Ready> isp0: Chan 0 WWPN 410000007f000000 WWNN 400000007f000000 isp0: Chan 0 16Gb Point-to-Point (N_Port) PortID 0x0000e8 LoopID 0x00 isp0: Chan 0 [0] WWPN 0x500000e0dc8ac220 PortID 0x0000ef handle 0x0 (REC,TGT,RdXfrDis) arrived da1 at isp0 bus 0 scbus18 target 0 lun 0 da1: <0000> Fixed Direct Access SPC-4 SCSI device da1: Serial Number XXXXXX da1: 1600.000MB/s transfers WWNN 0x500000e0dc8ac200 WWPN 0x500000e0dc8ac220 PortID 0xef da1: Command Queueing enabled da1: 14931722MB (30580166656 512 byte sectors) ----- Some notes on the "invalid NVRAM header" and "bad frame length (0) from NVR= AM": They do not harm and one will get the same messages with already supported ISP27xx (QLE2690/2692) devices. Looking at the linux driver code the NVRAM access is done somehow different. I'm currently further investigating this but it maybe related to the added "Firmware Integrity Protection with Hardware Root of Trust" and primary/secondary firmware images. A note to the default frame size: I haven't seen a single FC HBA or other FC device with a pre-configured def= ault frame size lower than 2048. Therefor I decided to set it to 2048 as default for ISP28xx based HBAs as l= ong as there is no way to read it from NVRAM. I would have changed this also for ISP27xx based HBAs (there is no NVRAM ac= cess too) but kept it for now on those and all others at 1024 just to not break = any existing setups. Build and runtime tested on CURRENT and RELENG-13.2 on amd64. Probably a very good candidate for an MFC --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271062-227>