pmx50: watchdog, límites de captura y firmware — 20 octubre 2026

Evento 10, 23:24:41 CEST: nuevo boot pmx50 10196fa7…, firma SP5100, 0x02000800 y bootstatus 32; causa de perder keepalives desconocida. VM208 completó arranque automático y estaba running a las 23:25:55. Véase el apéndice fechado y sus recibos. Las muestras y guardas del boot 82d105f6… son anteriores al nuevo epoch; no acreditan continuidad ni recuperación funcional posterior.

Nuevo arranque15:55:04 CEST: confirmado por btime y boot ID a las15:56:35. El informe separado distingue este evento del ciclo natural de Ansible correcto15:50–15:51. No se había aplicado fsync. Causa pendiente; el éxito de Ansible no acredita estabilidad del host.

Evento posterior15:11:50 CEST: el nuevo informe separado acredita otro arranque con firma literal hardware watchdog timer expired. Sigue pendiente identificar la causa; las observaciones de13:35 son anteriores.

Actualización20oct14:52 CEST: otro arranque de pmx50 confirmado directamente en /proc/stat y boot ID:13:35:18CEST. Es posterior al último arranque02:13 analizado abajo. El motivo de este nuevo arranque está en investigación; no se atribuye aún al watchdog ni se levanta el hold. Las observaciones anteriores conservan sus fechas y no acreditan continuidad de ese boot hasta ahora.

La revisión nativa y del peer del nuevo arranque13:35 registra también bootstatus32 y el código0x02000800, compatibles con mecanismo watchdog, sin identificar su causa. El fallo Git posterior se documenta aparte.

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.

Los apéndices distinguen las lecturas pasivas autorizadas posteriores. La ampliación de rotaciones de13:49 sí recupera cobertura del primer evento: pulso previo hasta00:02:36, frente al journal local retenido hasta00:02:14; los pulsos de00:03:12–15 son posteriores al arranque y se mantienen separados. No se acredita la causa del reset.

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/crash só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:

• F7BFD1.15, enlazado en Lite/SE.
• F7BFC1.20, enlazado en UM773.

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.

Pulso remoto ya existente: lectura pasiva de12:57–12:58CEST

Se resolvió el receptor en proxmox2 (pmx51), con pulso-rx.service y netconsole-rx.service active/running y ejecutable/destino coincidentes con fuente ansible/roles/power_safety. Se leyeron exclusivamente los archivos existentes /var/log/pulso-nodos.log y /var/log/netconsole.log; ningún datagrama, instrumentación, cambio, probe, sensor, test o job nuevo. El parser se probó antes con fixtures sintéticas de formato, filtrado y segmentación.

Dos lecturas a12:57:15 y12:58:44CEST acumularon39.665.997bytes del pulso y 65.787.889bytes del journal remoto: cada archivo quedó por debajo del límite acumulado64MiB. Cada pasada tuvo deadline15s, filas≤16KiB y snapshot del tamaño inicial; ambas conservaron identidad/stat antes/después, sin truncado ni append durante la lectura. Archivos regulares root:root0644/nlink1, con inodes183981 y 183514 respectivamente. No se exploraron rotaciones ni otros logs.

Se procesó el formato conocido de recepción y se filtró IP origen .50; las filas de pulso además debían llevar hostname proxmox. El prefijo temporal es hora de recepción del peer, con offset+0200 observado. El datagrama lleva uptime y lag del emisor, no un timestamp de emisión ni boot_id. UDP puede perder, retrasar o reordenar mensajes; no se equipara recepción a ejecución exacta.

Evento / ventana recibida CEST (90s)	Pulsos previos seleccionados	Uptime emisor, s	CPU Tctl, °C	PSI IO full avg10, min–máx / último
1 · 00:01:45–00:03:15	Sin cobertura	—	—	—
2 · 00:24:00–00:25:30	30 · 00:24:30–00:24:59	1289,04→1318,25	48,6–52,8	0–0 /0
3 · 00:56:45–00:58:15	54 · 00:56:45–00:57:38	1880,15→1933,54	48,4–51,2	0–1,09 /0,32
4 · 02:10:00–02:11:30	49 PRE · 02:10:00–02:10:48	4314,02→4362,36	48,5–52,2	0–0,33 /0,02
5 · 02:12:15–02:13:45	59 · 02:12:15–02:13:13	61,35→119,80	53–60,5	3,89–9,02 /7,97

En evento4 hay otro pulso POST, recibido02:11:30 con uptime16,02s: no se mezcla con los49 anteriores. La caída de uptime es coherente con el boot intermedio acreditado por kernel/journal; el pulso por sí solo no identifica su boot_id. Todos los segmentos seleccionados registran lag0,01s (precisión impresa) y NVMe state live; no prueban avance del mux ni salud de las operaciones NVMe.

Los dos archivos actuales comienzan sus filas del emisor .50 a00:24:30: el evento1 queda fuera de la cobertura de esos archivos activos inspeccionados, y el evento2 sólo tiene cobertura parcial. La rotación examinada después añade cobertura del evento1, sin cambiar el resultado de aquella lectura. Las ventanas no contienen KMSG ni firmas de error hardware/lockup/timeout NVMe, IO/OOM, expiración de cliente, salto de reloj o aviso térmico de la allowlist. Esto describe esos archivos y filtros, no ausencia global de tales eventos.

En evento5, el journal_stream recibido por el peer tiene una sola fila a 02:12:23, mientras los59 pulsos alcanzan02:13:13:50s después de esa recepción. Esto es distinto del journal local previamente retenido hasta02:12:42. El avance de uptime muestra progreso del emisor de pulso más allá del último registro recibido por esa vía de journal; no demuestra que journald se detuviera, que el disco fallara ni cuándo cesó CPU/red. La retención y transporte difieren.

En ese segmento, MemAvailable tiene rango13.209–18.935MiB (último13.265MiB), PSI memoria full avg10=0 y PSI IO some avg10=5,82–11,56% (último10,30%). Hay mayor presión IO registrada que en los segmentos2–4, pero coincide también con un arranque reciente. No atribuye el reset a IO/cargas; el máximo60,5°C no excluye un cambio brusco posterior al último pulso ni certifica térmica estable. No se observa el intervalo final: faltan unos30s de recepción hasta el primer kernel nuevo02:13:43, incluidos potencialmente reset/firmware/arranque. Esa comparación usa pared del receptor y pared del kernel sin medir su desfase: no es una duración precisa del bloqueo.

El emisor intenta mlockall, pero el código no comprueba su retorno: no se acredita memoria efectivamente bloqueada ni independencia absoluta de fallos del sistema. Este resultado acota evidencia de progreso y presión; no identifica la causa del watchdog ni justifica tuning, reinicio, migración o cambio de política.

Proyección privada0600/fsync projection-segmented.json, en el stage local ~/.local/state/watchdog-pulse-review-20261020-d3u_x3hv/, SHA256 <REDACTED>. Parser SHA256 <REDACTED>. Transporte: SSH existente pmx2, BatchMode, host trust estricto y Python -B por stdin; salida sólo agregados y firmas permitidas, sin publicar mensajes, argumentos, tokens, títulos, datos de aplicaciones ni logs crudos. No más lecturas tras consumir ese presupuesto.

Rotaciones del receptor: primer evento, 20 de octubre, 13:49 CEST

La inspección de metadatos a 13:47:29,467780 CEST se limitó a 23 nombres explícitos previstos por las fuentes de logrotate: .1 y .1.gz–.7.gz de pulso, .1 y .1.gz–.14.gz de journal remoto. No hubo glob, exploración de directorios, lectura de archivos activos ni consultas de journal. Existían sólo pulso-nodos.log.1.gz, netconsole.log.1.gz y netconsole.log.2.gz; los otros 20 nombres estaban ausentes. Los receptores de proxmox2 figuraban active/running con identidad de unidad esperada.

Se consumieron únicamente las dos rotaciones .1.gz, con comprobación de identidad antes/después y CRC de gzip correctos. La pasada terminó a 13:49:39,287033 CEST: 6.470.567 bytes comprimidos y 64.319.502 bytes expandidos, dentro de los presupuestos acumulados 8 MiB/64 MiB y deadline de 15 s. Cada fila quedó acotada a 16 KiB y la ventana seleccionada en RAM a 1 MiB. El recorrido del stream comprueba prefijos temporales y CRC; sólo procesa cuerpos del emisor .50 dentro de 00:01:45–00:03:15. No se conservaron ni mostraron mensajes crudos. netconsole.log.2.gz no se abrió: no hacía falta ampliar la búsqueda.

Las dos rotaciones son archivos regulares root:root0644, un enlace e identidades sin cambios. Pulso:inode 185043, 3.796.445 bytes; journal:inode 185042, 2.674.122 bytes. Sus registros del emisor abarcan respectivamente 18 oct20:15:32–20 oct00:24:29 y 19 oct00:43:51–20 oct00:23:31: ambos intervalos incluyen la ventana del primer evento.

Segmento de pulso	Recepción CEST	Filas	Uptime emisor
PRE	00:01:45–00:02:36	51	11196,65→11247,02s
POST	00:03:12–00:03:15	7	8,82→14,86s

La caída de uptime separa los segmentos; no se mezclan sus extremos o máximos. El último PRE llega 22s después del journal local retenido hasta00:02:14, y después de la respuesta node-exporter00:02:30,323 ya acreditada. Eso amplía la evidencia de progreso de otro proceso del emisor; no acredita el último keepalive, funcionamiento de journald/disco, instante del cuelgue o causa del reset. El progreso del pulso no mide el del mux o HA: contradice identificar sin más el corte del journal con una congelación total, pero no excluye un bloqueo parcial ni una congelación posterior. La recepción UDP no es timestamp de emisión ni prueba de ausencia de pérdida, retraso o reordenación; el datagrama no lleva boot_id. No restar uptime de un datagrama recibido para reemplazar el btime ya acreditado ni medir con ello un timeout.

Los60s del análisis del mux son la edad virtual del cliente, no el intervalo desde el último pulso de este proceso. El cierre inseguro tiene una ruta inmediata y el hardware tiene su timeout separado de10s. Que el pulso avance no acredita ping de HA, ejecución del mux o un ioctl keepalive exitoso: la fuente del emisor no recoge esas señales. No hay base para excluir esas rutas comparando el pulso con el siguiente boot.

En las 51 muestras PRE, CPU Tctl 51,5–55,6 °C (última 52,1), MemAvailable 13.161–13.776 MiB (última 13.723), PSI memoria full avg10=0–0,50% (última 0,49), PSI IO some avg10=29,52–45,10% (última 29,52) e IO full=26,87–38,86% (última 26,87). Lag impreso 0,01 s y NVMe state live en todas. Hay presión IO observada, sin identificar proceso, dispositivo ni relación causal; live no prueba salud IO. No atribuir el reinicio a RAM, temperatura, IO, hold o tareas a partir de esto.

El journal remoto tiene 103 filas seleccionadas en la ventana total; no se les atribuye un único boot porque ese formato no lo acredita. En ninguno de los dos streams aparecen KMSG ni firmas de la allowlist ya documentada. Esto sólo cubre los registros y filtros retenidos, no descarta errores no registrados.

Cinco fixtures locales validaron segmentación PRE/POST, ventana excluida, CRC corrupto, límites de expansión/fila e identidad/symlink. Proyección privada 0600, fsync de archivo/directorio: ~/.local/state/watchdog-rotation-review-20261020/projection.json, SHA256 <REDACTED>. Metadatos previos: metadata.json, SHA256 <REDACTED>. Sin escritura runtime, nueva instrumentación, reinicios, cargas o cambios de HA/watchdog. Terminada la pasada autorizada, no se consultaron más archivos.