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

kernel arm

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 Watchdog solo se puede configurar una vez. Cuando el código se cuelga en bootstrap, bootloader o kernel, la placa se reinicia. Pero una vez que el kernel se activa, 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 el perro guardián?

En nuestro caso, el watchdog debe estar influenciado por las aplicaciones, de modo que la placa pueda restablecerse si nuestra aplicación se bloquea.

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 usando el watchdog para bloqueos de software disponibles en kernel-2.6.25-ts.at91sam9g20 / kernel / softlockup.c

Answer 1

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

Answer 2

En julio de 2016, una confirmación en el kernel 4.7 para watchdog_dev.c habilitó el mismo comportamiento que la respuesta de shodanex para todos los controladores del temporizador de vigilancia. Esto no parece estar documentado en ningún otro lugar 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));

Answer 3

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

Tiene mucho sentido que un demonio de espacio de usuario maneje el perro guardián. Probablemente el valor predeterminado es un tiempo de espera de 15 minutos.

Answer 4

Si habilitó el controlador de vigilancia en su kernel, el controlador de vigilancia configura un temporizador de kernel, que se encarga de restablecer la vigilancia. El código correspondiente está here . Así funciona así:

Si ninguna aplicación abre el archivo / dev / watchdog, entonces el núcleo se encarga de restablecer el watchdog. Dado que es un temporizador, no aparecerá como un subproceso del kernel dedicado, sino que se manejará mediante el subproceso IRQ suave. Ahora, si una aplicación abre este archivo, se hace responsable del perro guardián y puede restablecerla escribiendo en el archivo, como se documenta en la documentación vinculada en la publicación de Richard.

¿Está configurado el controlador de vigilancia en su núcleo? De lo contrario, debe configurarlo y ver si el restablecimiento sigue ocurriendo. Si aún sucede, es probable que el reinicio se realice en otro lugar.

Si su kernel es demasiado viejo para tener un controlador de vigilancia adecuado (no presente en 2.6.25), debe realizar una copia de seguridad desde 2.6.28. O puede intentar deshabilitar el watchdog en su gestor de arranque y ver si el reinicio sigue ocurriendo.

Answer 5

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

Explicación de bits de la documentación de la hoja de datos:

• WDIDLEHLT: Watchdog Idle Halt

1. 0: El Watchdog 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 aumenta cuando el kernel está en estado inactivo, por lo tanto, el retardo de 15 o más hasta que se reinicie.

Puede probar "dd if = / dev / zero of = / dev / null", lo que evitará que el kernel entre en estado inactivo y debería restablecerse en 16 segundos (o el período que haya establecido en el registro WDT_MR).

Entonces, la solución es actualizar el código u-boot u otra pieza de código que establezca el registro WDT_MR. Recuerda que este registro es escribir una vez ...