El campo de fabricante del AFBR-89BDDZ QSFP28 muestra 0905000000000000 tras pasar la interfaz SP/FPGA a un FIFO
Nosotros mantenemos el firmware de gestión de switch en nuestro propio hardware, y desde que la interfaz SP/FPGA se cambió de buffers mapeados en memoria a un FIFO, el inventario de transceptores está devolviendo basura en algunos puertos.
- ópticos QSFP28, todos AFBR-89BDDZ del mismo lote
- las lecturas pasan por la ruta del service processor y la FPGA hasta la EEPROM del módulo
- el helper del lado del host es get_i2c_status_and_read_buffer: comprobar estado, leer todo el buffer, comprobar estado otra vez
Lo que obtenemos en lugar de los datos de fabricante:
one port, vendor field: 0905000000000000
the next port, vendor field: all ones
on another machine: vendor field all zeros, elsewhere repeated digit charactersLo que hemos probado hasta ahora:
- releer el mismo puerto varias veces seguidas, y la basura es estable por puerto en vez de ruido aleatorio
- ciclar la alimentación de los módulos, sin diferencia
- confirmamos que todos los módulos del chasis son el mismo número de parte, así que no somos nosotros decodificando mal algún bloque de fabricante exótico
Antes de empezar a sacar ópticos de producción, ¿es más probable que sea culpa de los módulos, de la ruta I2C, o de nuestro propio helper de lectura?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 7
Eso apunta directamente a la ruta de lectura, y el cambio a FIFO es la razón. Un buffer mapeado en memoria devuelve el mismo contenido sin importar cuántas veces lo consultes; un FIFO entrega cada byte exactamente una vez y luego desaparece. La secuencia que heredó get_i2c_status_and_read_buffer, comprobar estado, leer el buffer completo, comprobar estado otra vez, tenía sentido con memoria detrás y no lo tiene con un FIFO: vacía la cola mientras la lectura de la EEPROM del módulo todavía está en el cable. Obtienes lo que estuviera ahí en ese instante, y los bytes que llegan tarde se quedan atrás y aparecen en la siguiente lectura.
Ese es exactamente el patrón que describes. Basura estable por puerto, la corrupción caminando junto con la secuencia, todo ceros en una máquina y patrones de dígitos repetidos en otra según cómo caiga el timing. Nada de eso requiere un módulo defectuoso, y tu resultado de intercambio descarta la óptica de todos modos.
La solución es dejar de hacer que quien llama sea responsable de la comprobación de finalización. Mueve esa responsabilidad dentro de la rutina de lectura del driver del transceptor mismo: espera hasta que la transacción I2C reporte terminado y solo entonces toca el buffer, así ningún llamador puede vaciarlo antes de tiempo por construcción. Parchear un solo punto de llamada solo empujaría la condición de carrera a otro lugar.
Aviso justo de que esta es la forma propuesta de la solución y no algo con años detrás, así que valídala en tu propia plataforma antes de volver a confiar en el inventario. Lección barata para llevarse de todos modos: las cadenas de fabricante corrompidas merecen primero una prueba de módulo contra puerto, porque el orden de lectura resulta ser el culpable con mucha más frecuencia que la óptica.
La única medición que zanja esto por la mitad: ¿la corrupción se queda con el módulo o con el puerto? Saca el módulo del puerto que devuelve
0905000000000000, cámbialo con un módulo de un puerto que lee correctamente, y vuelve a leer ambos. Si la cadena mala sigue al módulo físico, ve a mirar la óptica. Si se queda en el número de puerto, o peor, se traslada al siguiente módulo que se lea, los módulos son inocentes y tienes un problema de lectura en el host.Ya que estás en eso, vuelca los bytes crudos de la EEPROM junto con los campos decodificados. Basura en una cadena de fabricante decodificada con bytes sanos debajo es un bug completamente distinto de basura en los bytes mismos.
Ejecuté ese intercambio en un par de puertos. Los datos malos no se movieron con el módulo: el puerto que devolvía
0905000000000000siguió devolviéndolo con otro módulo puesto, y el módulo que sacamos leyó perfecto en su nueva ranura.Mejor aún, cuando cambiamos el orden en que se leen los puertos, la corrupción se movió con la secuencia. La basura cae en el módulo que se lee justo después del que falla. Así que sigue el orden de lectura, no la pieza física. Los bytes crudos también están mal, así que no es un problema de decodificación de nuestro lado.
Causa raíz distinta, misma trampa, del lado del driver. En un Intel E810-C con el ice 1.15.4 fuera del árbol obtuve páginas incompletas e incorrectas de
ethtool -men ópticos QSFP28: los datos de las páginas 1 y 3, umbrales y monitores por carril, no coincidían con lo que realmente contenía el módulo. Nunca obtuve una declaración de causa raíz apropiada, el hilo se cerró como resuelto sin muchos detalles, así que trata esto como anécdota y no como palabra santa.Lo que terminé haciendo fue actualizar el driver ice y el NVM del E810 con
nvmupdate64e, comparar contra una lectura del driver ice del propio kernel en otro host, y sacar páginas específicas conmás offset y longitud explícitos, en vez de confiar en la salida decodificada. Si tu plataforma puede hacer un volcado crudo, compara crudo contra decodificado antes de creer en cualquiera de los dos.
Vale la pena explicar las capas, porque acorta mucho este tipo de búsqueda. En Linux
ethtool -mdecodifica la EEPROM del módulo (nombre de fabricante, OUI, número de parte, número de serie, código de fecha, y valores DDM cuando el módulo los tiene),ethtool -evuelca los bytes crudos, y donde el bus I2C está expuestoi2cdump -y 1 0x50lee A0h mientrasi2cdump -y 1 0x51lee A2h.En A0h el nombre de fabricante vive en los bytes 20-35 y PN, revisión y SN en 40-59. Así que si el campo de fabricante está corrompido y el número de parte dos docenas de bytes más adelante está intacto, eso por sí solo dice que la lectura depende del timing en vez de que la EEPROM esté mala, lo cual encaja con lo que estás viendo.
Un fallo que no hay que confundir con este:
ethtool -mdevolviendo Input/output error normalmente es solo un módulo sin DDM. El bit 6 del byte 92 de A0h es la bandera de si A2h existe siquiera, y esa comprobación se metió en los drivers ixgbe y bnx2x del kernel hace mucho para que dejaran de buscar otros 256 bytes que no existen.Mismo género de problema en equipos SONiC, para quien llegue de ese lado.
sfputil show eepromdice Cannot get Module EEPROM data: Invalid argument para ciertos módulos, o discrepa silenciosamente conshow interfaces transceiver eepromen el mismo puerto.Por lo que me he encontrado son mayormente huecos de plataforma y driver y no la óptica: los dos comandos usaban nombres de clave inconsistentes en la rama 202012 y eso se arregló en 202205, algunas plataformas pierden los módulos QSFP de sfputil tras un ciclo de energía hasta que llega un fix de driver, y en otras get_transceiver_info simplemente no está implementado. Cuando necesito algo en lo que pueda confiar para scripting voy al driver de kernel optoe y hago yo mismo lecturas crudas de la EEPROM SFP, QSFP o CMIS. De todos modos compruébalo en tu propia plataforma, el comportamiento varía mucho entre ellas.
Actualización de nuestro lado. Movimos la comprobación de finalización a la función de lectura del driver como se sugirió, y las cadenas de fabricante han estado correctas en todos los puertos a lo largo de varios cientos de pasadas de inventario, incluyendo los dos puertos que solían intercambiar basura entre ellos. Los bytes crudos ahora coinciden con los campos decodificados.
Lo llamo parcial en vez de cerrado por ahora: lo llevamos como un parche que todavía no ha llegado a nuestro árbol, y hay una plataforma más con un build de FPGA distinto por verificar antes de confiar en esto en todas partes. Pero la óptica estuvo bien todo el tiempo, que es la parte en la que yo mismo me habría equivocado.