[Bug 299226] cxgbe(4): integer divide fault in alloc_eq_hwq() on VF interface up

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=299226

            Bug ID: 299226
           Summary: cxgbe(4): integer divide fault in alloc_eq_hwq() on VF
                    interface up
           Product: Base System
           Version: 16.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: thomas.pasqualini@orange.com

On a system with a Chelsio T6225-SO-CR NIC,
which runs main@b6d10a962448,
I am creating VF successfully with iovctl(8) and want to pass som through a
FreeBSd gust, which also runs main@b6d10a962448:

root@ipsec09:/data/vm # vm passthru | grep VF
ppt0       59/0/8       Yes          T6225-SO-CR Unified Wire Ethernet
Controller [VF]
ppt1       59/0/12      Yes          T6225-SO-CR Unified Wire Ethernet
Controller [VF]
ppt2       59/0/9       Yes          T6225-SO-CR Unified Wire Ethernet
Controller [VF]
ppt3       59/0/13      Yes          T6225-SO-CR Unified Wire Ethernet
Controller [VF]
ppt4       216/0/8      Yes          T6225-SO-CR Unified Wire Ethernet
Controller [VF]
ppt5       216/0/12     Yes          T6225-SO-CR Unified Wire Ethernet
Controller [VF]
ppt6       216/0/9      Yes          T6225-SO-CR Unified Wire Ethernet
Controller [VF]
ppt7       216/0/13     Yes          T6225-SO-CR Unified Wire Ethernet
Controller [VF]

root@ipsec09:/data/vm # cat /data/vm/test/test.conf 
loader="bhyveload"
cpu=1
memory=1024M
network0_type="virtio-net"
network0_switch="mgmt"
disk0_type="virtio-blk"
disk0_type="ahci-hd"
disk0_name="disk0.img"
console="tmux"
uuid="d0ee6a6d-c32c-11f1-bec9-78ac4441d36c"
network0_mac="58:9c:fc:0a:36:c6"
passthru0="59/0/8"

Once the guest has boot, as soon as I try to bing a ccvX netif up, it immedialy
panics. It is 100% reproducible:

Fatal trap 18: integer divide fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer     = 0x20:0xffffffff8059a08c
stack pointer           = 0x28:0xfffffe004a5918c0
frame pointer           = 0x28:0xfffffe004a591920
processor eflags        = interrupt enabled, resume, IOPL = 0
current thread          = 17223/100082 (ifconfig/ifconfig)
rdi: fffffe004d649000 rsi: 0000000000000000 rdx: 0000000000000000
rcx: 0000000000000400  r8: 0000000000000000  r9: fffffe004d639000
rax: 0000000000000000 rbx: fffff800034a3800 rbp: fffffe004a591920
r10: 0000000000000000 r11: 8d9a94ffd6b1beb3 r12: 0000000000000000
r13: 0000000000000000 r14: fffff8000349a000 r15: fffff80003508a00
panic: integer divide fault
cpuid = 0
time = 1791469634
KDB: stack backtrace:
#0 0xffffffff80a96ae5 at kdb_backtrace+0x75
#1 0xffffffff80a482a9 at vpanic+0x149
#2 0xffffffff80a48153 at panic+0x43
#3 0xffffffff80eb853f at trap_fatal+0x6f
#4 0xffffffff80e89ea8 at calltrap+0x8
#5 0xffffffff80594cc2 at t4_setup_vi_queues+0x1ef2
#6 0xffffffff8056ea46 at vi_full_init+0x26
#7 0xffffffff80582de0 at cxgbe_init_synchronized+0x70
#8 0xffffffff805822a9 at cxgbe_ioctl+0x829
#9 0xffffffff80b79d65 at ifhwioctl+0xca5
#10 0xffffffff80b7af6d at ifioctl+0x19d
#11 0xffffffff80abaa02 at kern_ioctl+0x2a2
#12 0xffffffff80aba6f7 at sys_ioctl+0x117
#13 0xffffffff80eb9206 at amd64_syscall+0x136
#14 0xffffffff80e8a79b at fast_syscall_common+0xf8

The faulty RIP resolves to:
nm -n ./kernel | awk '$1 <= "ffffffff8059a08c"' | tail -3
ffffffff80599c50 t free_iq_fl
ffffffff80599da0 t alloc_wrq
ffffffff80599f10 t alloc_eq_hwq

Seems relative to params.ncores which may have not been properly initilialzed
in t4_vf.
This patch is fixing the behavior on my systems:

diff --git a/sys/dev/cxgbe/t4_vf.c b/sys/dev/cxgbe/t4_vf.c
index 8e9d3b34d6a..56cb383d477 100644
--- a/sys/dev/cxgbe/t4_vf.c
+++ b/sys/dev/cxgbe/t4_vf.c
@@ -331,6 +331,9 @@ get_params__post_init(struct adapter *sc)
        }
        sc->params.portvec = sc->params.vfres.pmask;

+       if (sc->params.ncores == 0)
+               sc->params.ncores = 1;
+
        param = FW_PARAM_PFVF(MAX_PKTS_PER_ETH_TX_PKTS_WR);
        rc = -t4vf_query_params(sc, 1, &param, &val);
        if (rc == 0)

This guard is fixing the panic while params.ncores is not properly initialized
before.

-- 
You are receiving this mail because:
You are the assignee for the bug.