¿Quién está actualizando el watchdog de hardware en Linux?

Question

Tengo un procesador AT91SAM9G20 que ejecuta un kernel 2.6. Watchdog está habilitado en el nivel de arranque y configurado durante 16 segundos. El registro del modo de vigilancia se puede configurar solo una vez. Cuando el código se bloquea en bootstrap, gestor de arranque o kernel, la placa se reinicia. Pero una vez que aparece el kernel aunque el watchdog no se actualiza en ninguna de las aplicaciones, la placa no se reinicia después de 16 segundos, sino de 15 minutos.

¿Quién está refrescando al perro guardián?

En nuestro caso, las aplicaciones deben influir en el regulador, de modo que el tablero pueda restablecerse si se bloquea nuestra aplicación.

Estos son los procesos en ejecución:

1 root  init 
2 root  [kthreadd] 
3 root  [ksoftirqd/0] 
4 root  [watchdog/0] 
5 root  [events/0] 
6 root  [khelper] 
63 root  [kblockd/0] 
72 root  [ksuspend_usbd] 
78 root  [khubd] 
85 root  [kmmcd] 
107 root  [pdflush] 
108 root  [pdflush] 
109 root  [kswapd0] 
110 root  [aio/0] 
740 root  [mtdblockd] 
828 root  [rpciod/0] 
982 root  [jffs2_gcd_mtd10] 
1003 root  /sbin/udevd -d 
1145 daemon portmap 
1158 dbus  dbus-daemon --system 
1178 root  /usr/sbin/ifplugd -i eth0 -fwI -u0 -d5 -l -q 
1190 root  /usr/sbin/ifplugd -i eth1 -fwI -u0 -d5 -l -q 
1221 default avahi-daemon: running [SP14.local] 
1226 root  /usr/sbin/dropbear 
1246 root  /root/bin/host_app 
1254 root  /root/bin/mini_httpd -c *.cgi -d /root/bin -u root -E /root/bin/ 
1256 root  -sh 
1257 root  /sbin/syslogd -n -m 0 
1258 root  /sbin/klogd -n 
1259 root  /usr/bin/tail -f /var/log/messages 
1265 root  ps -e 

Estamos utilizando el organismo de control de bloqueos blandos disponibles en kernel-2.6.25-ts.at91sam9g20/kernel/softlockup.c

Answer 1

¿No sería la kernel estar refrescando el temporizador de vigilancia? El perro guardián está diseñado para restablecer el tablero si todo el sistema se cuelga, no solo una aplicación.

Answer 2

Esto le puede dar una pista: http://www.mjmwired.net/kernel/Documentation/watchdog/watchdog-api.txt

tiene todo el sentido de tener un manejo de la vigilancia demonio de espacio de usuario. Probablemente sea un tiempo de espera de 15 minutos.

Answer 3

Si habilitó el controlador de vigilancia en su núcleo, el controlador de vigilancia configura un temporizador de kernel, a cargo de restablecer el watchdog. El código correspondiente es here. Por lo tanto, funciona así:

Si ninguna aplicación abre el archivo/dev/watchdog, el kernel se encarga de restablecer el watchdog. Debido a que es un temporizador, no aparecerá como un hilo de kernel dedicado, sino que será manejado por el hilo de IRQ suave. Ahora, si una aplicación abre este archivo, se convierte en el responsable del perro guardián y puede restablecerlo escribiendo en el archivo, según lo documenta la documentación vinculada en la publicación de Richard.

¿El controlador de vigilancia está configurado en su kernel? De lo contrario, debe configurarlo y ver si el reinicio continúa. Si aún sucede, es probable que su restablecimiento provenga de otro lugar.

Si su kernel es demasiado viejo para tener un controlador de watchdog adecuado (no está presente en 2.6.25), debe respaldarlo desde 2.6.28. O puede intentar desactivar el perro guardián en su gestor de arranque y ver si aún se produce el reinicio.

Answer 4

tuvimos un problema similar con respecto a WDT en AT91SAM9263. El problema fue con el bit 29 WDIDLEHLT de WDT_MR (Address: 0xFFFFFD44) register. Este bit se estableció en 1, pero debería ser 0 para las necesidades de nuestra aplicación.

Bit explicación por parte de la documentación técnica de:

• WDIDLEHLT: Watchdog Halt inactivo

1. 0: El perro guardián se ejecuta cuando el sistema está en modo inactivo.
2. 1: El Watchdog se detiene cuando el sistema está inactivo.

Esto significa que el contador WDT no se incrementa cuando el kernel está en estado inactivo, de ahí que haya 15 o más retrasos hasta que se restablezca.

Puede intentar "dd if =/dev/zero of =/dev/null" que evitará que kernel ingrese al estado inactivo y debería obtener un restablecimiento en 16 segundos (o cualquier período que haya establecido en el registro WDT_MR) .

Por lo tanto, la solución es actualizar el código u-boot u otro código que establezca el registro WDT_MR. Recuerde que este registro se escribe una vez ...

Answer 5

En julio de 2016 a commit in the 4.7 kernel a watchdog_dev.c habilitado el mismo comportamiento que la respuesta de shodanex para todos los controladores de temporizador de vigilancia. Esto no parece estar documentado en ninguna otra parte que no sea este hilo y el código fuente.

/* 
* A worker to generate heartbeat requests is needed if all of the 
* following conditions are true. 
* - Userspace activated the watchdog. 
* - The driver provided a value for the maximum hardware timeout, and 
* thus is aware that the framework supports generating heartbeat 
* requests. 
* - Userspace requests a longer timeout than the hardware can handle. 
* 
* Alternatively, if userspace has not opened the watchdog 
* device, we take care of feeding the watchdog if it is 
* running. 
*/ 

return (hm && watchdog_active(wdd) && t > hm) || 
     (t && !watchdog_active(wdd) && watchdog_hw_running(wdd));