El chip BCM57800 es uno de los que, en el kernel de Linux, van gestionados por el controlador bnx2x. También es el que lleva una de las tarjetas rNDC de Dell para los r630 más populares, con 2 SFP+ y 2 «cobres» de 1G.
Estas tarjetas con BCM57[0-9][0-9][0-9]* «Everest» son uno de esos productos con una historia meandrosa. Los chips fueron diseñados por Broadcom, que los anunció en Diciembre de 2010, y en poco tiempo usados por Brocade en varios productos. En 2014, QLogic compró a Brocade el negocio de Fibre Channel y adaptadores de red, incluyendo tarjetas que usaban estos chips, cuyo controlador pasó a mantener como atestigua el .h del bnx2x. En Junio de 2016, QLogic fue adquirida por Cavium, que a su vez fue adquirida por Marvell. Por su parte, Brocade fue comprada por Broadcom en 2016. Las tarjetas con chips BCM57 eran de Cavium cuando Dell los empezó a utilizar, y de hecho algunos documentos técnicos en la web de Dell llevan la marca de Cavium.
Toda esta historia implica curiosidades como que en el código fuente, el copyright de Broadcom es anterior al de Qlogic.
Con toda esta florida historia de adquisiciones y pases, no es de extrañar que el bnx2x y sus hermanos hayan pasado por tantas manos que la calidad, al final, se haya resentido. Y esto es lo que parece haber ocurrido para que en algunas versiones, cuando reciben un poco de caña (digamos, una migración masiva de contenedores en un cluster de Proxmox), la red se caiga con todo el equipo:
May 30 20:35:20 hv149 kernel: [ 1272.998710] RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000006
May 30 20:35:20 hv149 kernel: [ 1273.021980] call_timer_fn+0x32/0x130
May 30 20:35:20 hv149 kernel: [ 1273.052021] RDX: 0000012862241f85 RSI: 0000000037a6f674 RDI: 0000000000000000
May 30 20:35:20 hv149 kernel: [ 1273.075905] ---[ end trace 179564100f322278 ]---
May 30 20:35:20 hv149 kernel: [ 1273.099027] bnx2x: [bnx2x_panic_dump:1021(eno1)] indexes (0x0 0xe97e 0x0 0x0 0x0 0x186d 0x0 0x0)pf_id(0x0) vf_id(0xff) vf_valid(0x0) vnic_id(0x0) same_igu_sb_1b(0x1) state(0x1)
May 30 20:35:20 hv149 kernel: [ 1273.158754] INDEX[6] flags (0x3) timeout (0xc)
May 30 20:35:20 hv149 kernel: [ 1273.218986] bnx2x: [bnx2x_panic_dump:1015(eno1)] run indexes (0x7d14 0x0)
May 30 20:35:20 hv149 kernel: [ 1273.334124] bnx2x: [bnx2x_panic_dump:1004(eno1)]fp6: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
May 30 20:35:20 hv149 kernel: [ 1273.365957] bnx2x: [bnx2x_panic_dump:1004(eno1)]fp7: tx_pkt_prod(0x0) tx_pkt_cons(0x0) tx_bd_prod(0x0) tx_bd_cons(0x0) *tx_cons_sb(0x0)
May 30 20:35:20 hv149 kernel: [ 1273.374863] SM[1] __flags (0x0) igu_sb_id (0x9) igu_seg_id(0x0) time_to_expire (0x4ad6f466) timer_value(0xff)
May 30 20:35:20 hv149 kernel: [ 1273.377750] INDEX[1] flags (0x2) timeout (0x6)
May 30 20:35:20 hv149 kernel: [ 1273.440571] bnx2x: [bnx2x_mc_assert:736(eno1)]XSTORM_ASSERT_INDEX 0x12 = 0x0002ef76 0x00000000 0x0400000d 0x000200
El caso es que esto no le hace mucha gracia a los contenedores ni, en cascada, a los cientos de servicios que hay en ellos corriendo; por lo que parece conveniente investigar un poco el problema.
El bnx2x sigue recibiendo un activo mantenimiento, y no pasa un mes sin que reciba una actualización. El comportamiento problemático ha sido observado en los kernel 5.4.78 (Noviembre de 2020) y 5.4.189 (Abril de 2022). Pero la rama 5.4, incluso en este último kernel, a pesar de su reciente factura, sigue llevando una versión de bnx2x fechada en 2014, y bnx2x ha recibido importantes actualizaciones en todas las versiones principales desde entonces. De hecho, ha dejado de tener su propio número de versión; su código fuente está en github, en el repo del bueno de Linus, desde hace más de diez años; si bien parece que le ha costado una temporada de su tortuosa historia armonizarse completamente.
Pero a día de hoy, las actualizaciones van siendo cada vez más tranquilas y de mantenimiento progresivo. En la rama 5.15, que en el momento de escribir este artículo es la más actual de mantenimiento «longterm», ha recibido actualizaciones en media docena de versiones. De todas, solamente llama la atención que en la 5.15.38, «While handling PCI errors (AER flow) driver tries to disable NAPI [napi_disable()] after NAPI is deleted [__netif_napi_del()] which causes unexpected system hang/crash.» Que es una bonita forma de decir que vaya, que fíjate, que el sistema entero se la puede pegar en cualquier momento; pero solamente después de que ya haya habido un error de PCI, es decir, que es un caso bastante raro. Todo lo demás son cosas del estilo de «Fix unused-function warning«, reorganizaciones, limpieza y usar las características más modernas del kernel.
TL;DR: No es de esperar que esto se la pegue tras actualizar a Proxmox 7.2, que lleva el kernel 5.15.35. Siguiente problema.
Comentarios recientes