https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271062
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: b...@freebsd.org
Reporter: joerg.p...@frm2.tum.de
Flags: mfc-stable13?
Created attachment 241735
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=241735&action=edit
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 Gen4
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 NVRAM":
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 default
frame size lower than 2048.
Therefor I decided to set it to 2048 as default for ISP28xx based HBAs as long
as there is no way to read it from NVRAM.
I would have changed this also for ISP27xx based HBAs (there is no NVRAM access
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
--
You are receiving this mail because:
You are the assignee for the bug.
