pmx50: watchdog, límites de captura y firmware — 20 octubre 2026¶
Análisis documental tras el reinicio no ordenado comunicado por el coordinador
alrededor de00:03CEST. Fuentes públicas oficiales de fabricante y kernel; no
lecturas adicionales de hosts, apertura de /dev/watchdog, cambios de drivers,
boot/sysctl, firmware, módulos ni pruebas de panic. No se contactó al fabricante
ni se descargó/ejecutó ningún paquete BIOS. El planner queda pausado e inacabado.
1. Datos recibidos y conclusión permitida¶
El coordinador observó:
- SP5100 bootstatus32; watchdog-mux es el único proceso con FD del watchdog; timeout hardware10s.
- Último journal del arranque previo00:02:14, sin shutdown; primer registro del nuevo00:03:03, boot time estimado00:03:01.
- Pstore vacío;
/var/crashsólo kdump_lock y kexec_cmd; crash kernel loaded1. - nmi_watchdog, hardlockup_panic y softlockup_panic ya estaban en1, con watchdog_thresh5. No son mitigaciones nuevas que falte volver a activar.
- Kernel7.0.14-19-pve con max_cstate1/APSToff.
- DMI: MicroComputer(HK)TechLimited / Venusseries / placaF7BFD / AMI1.15, fecha11/30/2023.
Estos valores son evidencia proporcionada por el coordinador, no una segunda verificación en vivo por este agente. La discontinuidad de journal es49s entre los registros citados; no mide por sí sola49s de cuelgue: puede incluir cola no persistida, reset, firmware/POST y arranque.
La conclusión respaldada es reinicio por mecanismo watchdog, con causa del latido perdido todavía sin identificar. No demuestra BIOS defectuosa, RAM, fuente, temperatura, kernel, scheduler o fencing como causa raíz.
2. Qué significa bootstatus32¶
La cabecera oficial Linux define WDIOF_CARDRESET como0x0020. En SP5100 upstream v7.0, inicialización lee el bit WatchDogFired y lo guarda en bootstatus como CARDRESET antes de limpiar el flag. Eso explica32 y acredita la señal de reset reportada por ese mecanismo; no almacena el proceso, CPU o acontecimiento que interrumpió los keepalives. La propiedad exclusiva actual por watchdog-mux no reconstruye automáticamente la secuencia del arranque previo.
El driver upstream anuncia timeout, keepalive y magic close; no anuncia soporte pretimeout ni implementa su callback. Esto describe el upstream consultado, no una comparación binaria completa con todos los parches de PVE7.0.14-19. No proponer un pretimeout hardware como si ya existiera. Fuentes: cabecera oficial watchdog, SP5100 upstream.
No abrir el dispositivo para «probar lectura»: su interfaz participa en el armado/mantenimiento del watchdog. La investigación actual no requiere competir con el FD existente ni tocar watchdog-mux o la política HA.
3. Por qué captura activada no equivale a causa capturada¶
Kdump carga anticipadamente otro kernel en memoria reservada, pero la captura
requiere alcanzar un trigger de crash y transferir control mediante kexec.
Después debe arrancar el kernel de captura y guardar /proc/vmcore. Un kernel
cargado sólo acredita esa preparación; los dos ficheros auxiliares observados
no equivalen a vmcore ni a traza de panic. Un reset hardware puede ocurrir sin
que se haya alcanzado esa ruta o antes de terminar el guardado. No hay evidencia
aquí de cuál de esas fases se alcanzó. Fuente:
kdump oficial.
Los detectores dependen de hrtimer y, para NMI/Perf, de que funcione esa maquinaria de interrupción. Con thresh5, el umbral nominal softlockup es10s; la detección NMI no es instantánea y depende de la fase de muestreo. La documentación ilustra una latencia de hasta dos ventanas en su ejemplo. Por tanto, inferimos una posible carrera con el watchdog hardware10s: detección, panic y captura pueden no completarse a tiempo. Es una explicación posible de la ausencia de dump, no una causa probada ni una recomendación de retuning. Los valores ya activos no permiten suponer cobertura de todo fallo de plataforma. Fuente: detectores de lockup.
Pstore vacío tampoco excluye un fallo. Ramoops, como ejemplo documentado de backend, necesita una región RAM persistente y que se escriba el registro; retención, backend y filtros importan. No se ha acreditado aquí qué backend tenía operativo este host ni que hubiese escritura antes del reset. No se propone habilitar otro backend ni reservar memoria ahora. Fuente: ramoops oficial.
4. Firmware: separar familia de placa y modelo comercial¶
El fabricante publica ramas distintas en su portal oficial consultado hoy:
| Entrada del portal | BIOS mostrado | Archivo enlazado |
|---|---|---|
| UM773 | 1.20 | F7BFC_BIOS_V1.20.zip |
| UM773 Lite | 1.15 | F7BFD_BIOS_V1.15.zip |
| UM773 SE | 1.15 | F7BFD_BIOS_V1.15.zip |
El manual enlazado para Lite/SE lleva F7BFD y UM773SE-Lite-ME en su nombre. La placaF7BFD y versión1.15 son compatibles con esa rama documental, pero no identifican por sí solas variante, revisión física ni SN. No extrapolar el 1.20 de F7BFC como actualización para F7BFD. Tampoco se demuestra que la1.15 instalada sea byte a byte el paquete del portal ni que no exista otra revisión facilitada individualmente por soporte. Fuente: centro oficial de descargas.
La consulta web del portal excedía el límite del lector de páginas; se contrastó su HTML oficial mediante urllib, extrayendo sólo títulos de producto y enlaces BIOS/manual. No se usaron foros ni repositorios de terceros como fuente de compatibilidad. Enlaces de referencia para identificar la rama, no órdenes de descarga o flasheo:
5. Identificación verificable y siguiente evidencia útil¶
Antes de seleccionar firmware, obtener modelo comercial y revisión de etiqueta, SN y referencia de compra, comparándolos con placa y BIOS actuales. El soporte oficial indica cómo localizar SN en la etiqueta inferior/lateral y dispone de canal técnico. No es necesario publicar el número en Git. Fuentes: localización oficial SN, contacto técnico oficial.
Preparar para revisión, sin enviarlo automáticamente: solicitud a soporte con modelo/SN confirmado, placaF7BFD, BIOS1.15(2023-11-30), kernel y secuencia de resets; pedir confirmación del archivo exacto para esa revisión, versión recomendada, changelog, checksum y procedimiento/recuperación soportados. Esta petición es un próximo paso propuesto, no evidencia de que un flash resolvería el cuelgue ni autorización para hacerlo.
Para el incidente actual, correlacionar offline los logs ya conservados por el coordinador: último pulso remoto y último kernel/journal, estado de quorum/HA y watchdog-mux inmediatamente antes, presión IO/memoria/CPU, mensajes hardware y primera información de arranque. La ausencia de shutdown acota el tipo de reinicio; la ausencia de una traza no discrimina sola un cuelgue de plataforma de una secuencia de watchdog ligada a software/política. Si existe una decisión de fencing explícita en esos logs, analizarla como evidencia independiente; bootstatus no la identifica por sí mismo.
No repetir ajustes ya activos ni forzar SysRq/panic para «probar captura» en medio de esta recuperación. No se hizo ningún cambio operativo por este análisis, ni se reanudó/publicó el planner pendiente.
Cronología consolidada de cinco eventos, revisión de fuentes 02:18 CEST¶
Sin nuevas consultas runtime para esta tabla; procede de los informes de cada boot y de la evidencia seleccionada del peer. Todas las horas son CEST del20.
| Evento | Último journal previo | Peer enlace caído | Primer kernel nuevo | btime acreditado | CRM online del peer |
|---|---|---|---|---|---|
| 1 | 00:02:14 | ND | 00:03:03 | 00:03:01 | ND |
| 2 | 00:24:42 | 00:25:04 | 00:25:27 | 00:25:25 | 00:25:53 |
| 3 | 00:57:40 | 00:57:45 | 00:58:08 | 00:58:06 | 00:58:25 |
| 4 | 02:10:43 | 02:10:52.955693 | 02:11:16.602295 | ND | 02:11:42.256445 |
| 5 | 02:12:42 | 02:13:19.770374 | 02:13:43.046069 | 02:13:41 | 02:13:58.282691 |
Los cinco kernels registran resetreason0x02000800/watchdog. ND significa no acreditado: no se reconstruye btime restando dos segundos al kernel. Los tiempos CRM son del peer, no sustituyen transiciones locales a slave.
En eventos2–5, enlace caído→primer kernel nuevo ronda23–24s; no representa último ping del mux→reset y no excluye caducidad de cliente60s. Último journal→ kernel varía49/45/28/33,60/61,05s: tampoco identifica comienzo del bloqueo. El node-exporter respondió00:02:30.323 tras el último journal00:02:14 del primer evento; evidencia concreta contra interpretar ese corte como congelación inmediata. Los kernels de eventos4y5 distan146,44s; la serie completa no tiene cadencia fija.
No hay registro retenido que acredite retirada del latido, expiración de cliente o petición de fencing. La ausencia de mensajes de ping no demuestra ausencia de pings. La causa permanece sin identificar; no se alteran watchdog/HA/BIOS/RAM.
Coincidencias de tareas: revisión local sin nuevas ejecuciones¶
Ningún horario acreditado explica los cinco eventos. SMART terminó antes de los primeros tres con separaciones24m47/20m19/36s, y hubo éxitos sin reset próximo. Su OnBoot2min y el guardPBSOnBoot2min+jitter podrían coincidir con el último intervalo, pero no se acredita aquí ejecución alrededor02:13:16. El guard posterior sí empezó02:15:43 y no se observó otro boot hasta02:18:31.
Ansible-pullOnBoot5min no encaja como primer disparo natural entre los dos últimos boots; no prueba ausencia de otras invocaciones. BackupsPVEdeclarados 01:00/02:00 no explican por horario los tres primeros y faltan UPID/ejecuciones. FrecuenciasRunWispde1/2/5/10min generan coincidencias por sí solas: sin runIDs no acreditan una tarea común. Picsacabó00:30:08; dumpnatural declarado01:30, originals11:10. Ninguno se acredita activo en todos los incidentes.
El backend instalado02:09:03 es posterior a los tres primeros; el ensayo sintético se inició después del corte02:10:52; el reloadPrometheus02:12:28CEST ocurrió en el peer. Su cronología no permite atribuirles los episodios anteriores ni excluir otras interacciones en los posteriores. No se deshabilitaron tareas.