illumos gate

The immediate cause for the panic is that idp->id_nfuncs is zero in i40e_get_available_resources(). The idp->id_nfuncs is set to zero in i40e_device_find() because hw->num_partitions is zero as well and finally, the hw->num_partitions is set to zero due to this code in i40e_common.c:

3823    /* count the enabled ports (aka the "not disabled" ports) */
3824    hw->num_ports = 0;
3825    for (i = 0; i < 4; i++) {
3826        u32 port_cfg_reg = I40E_PRTGEN_CNF + (4 * i);
3827        u64 port_cfg = 0;
3828
3829        /* use AQ read to get the physical register offset instead
3830         * of the port relative offset
3831         */
3832        i40e_aq_debug_read_register(hw, port_cfg_reg, &port_cfg, NULL);
3833        if (!(port_cfg & I40E_PRTGEN_CNF_PORT_DIS_MASK))
3834            hw->num_ports++;
3835    }
3836
3837    valid_functions = p->valid_functions;
3838    num_functions = 0;
3839    while (valid_functions) {
3840        if (valid_functions & 1)
3841            num_functions++;
3842        valid_functions >>= 1;
3843    }
3844
3845    /* partition id is 1-based, and functions are evenly spread
3846     * across the ports as partitions
3847     */
3848    if (hw->num_ports != 0) {
3849        hw->partition_id = (hw->pf_id / hw->num_ports) + 1;
3850        hw->num_partitions = num_functions / hw->num_ports;
3851    }

In the above code the four i40e_aq_debug_read_register() calls (in the for loop) returns 0, 0, 2, and 2 in port_cfg respectively, so hw->num_ports is set to 4. Because p->valid_functions is set to 0x3 (so num_functions is 2) the value of hw->num_partitions is calculated as zero (at line 3850).

This outcome is unexpected by i40e_device_find() (please note the ASSERT there) so we fail miserably later.

The code cited above comes from Intel ixl-1.6.10 driver and it is suspicious for various reasons:

1. It reads from PRTGEN_CNF and three subsequent locations after PRTGEN_CNF. In the controller specification there is only PRTGEN_CNF documented (at address 0x000B8120, 32bits), but three subsequent addresses 0x000B8124, 0x000B8128, and 0x000B812C are simply left undocumented.
2. The i40e_aq_debug_read_register() function is used to read those four locations. It is unclear why the generic rd32() is not used here instead. Maybe the initial intention was to read four NVM copies of PRTGEN_CNF, but in this case the i40e_read_nvm_word() function had to be used instead.
3. The return value of i40e_aq_debug_read_register() is completely ignored, so in a case the i40e_aq_debug_read_register() function fails we will count the port as active because port_cfg is initialized to zero (this is not our case; in all four cases the i40e_aq_debug_read_register() function succeeds).

I tried to use rd32() to read PRTGEN_CNF and three following addresses, but it always returns zero:

rd32(0x000B8120) = 0
rd32(0x000B8124) = 0
rd32(0x000B8128) = 0
rd32(0x000B812C) = 0

Then I noticed in the specification that we probably should consult PRTGEN_STATUS instead of PRTGEN_CNF to get the actual port status. Namely its PORT_VALID bit looked promising, so I tried to read PRTGEN_STATUS (and subsequent three locations as well) using both i40e_aq_debug_read_register() and rd32() with the following results:

i40e_aq_debug_read_register(0x000B8100) = 3
i40e_aq_debug_read_register(0x000B8104) = 3
i40e_aq_debug_read_register(0x000B8108) = 0
i40e_aq_debug_read_register(0x000B810C) = 0
rd32(0x000B8100) = 3
rd32(0x000B8104) = 3
rd32(0x000B8108) = 3
rd32(0x000B810C) = 3

Based on this observation my proposal to fix this issue is to change the code at lines 3823-3835 to check bit PORT_VALID in the PRTGEN_STATUS register instead of currently used bit PORT_DIS in the PRTGEN_CNF register.

Review: https://www.illumos.org/rb/r/1116/