* at91sam9: watchdog: period
@ 2015-05-15 7:16 Jiří Prchal
2015-05-15 13:59 ` Bryan Evenson
` (3 more replies)
0 siblings, 4 replies; 23+ messages in thread
From: Jiří Prchal @ 2015-05-15 7:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I'm trying to discover what's wrong with watchdog on my board. I didn't find anything about it on internet so I would
ask you for help.
I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors to GND. Frequency seems to be good since
hwclock (RTC) runs pretty precisely powered from backup and main power too (no NTP). But watchdog time to reset is still
61s regardless default (16s) or 4s heartbeat setting. No change to WDT_MR in bootstrap, so in Linux should work.
Here is dump:
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.0.2_cpm9g25 (prchal at prchal) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #10
PREEMPT Thu May 14 15:20:24 CEST 2015
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine model: AKsignal CDU9G25_v6
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] AT91: Detected soc type: at91sam9x5
[ 0.000000] AT91: Detected soc subtype: at91sam9g25
...
[ 4.669669] AT91: Starting after watchdog reset
[ 4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1)
...
/ # killall watchdog
[ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped!
/ # [ 1821.123123] watchdog watchdog0: watchdog did not stop!
[ 1882.294294] at91sam9_wdt: I will reset your machine !
Thanks for any help.
Jiri
^ permalink raw reply [flat|nested] 23+ messages in thread* at91sam9: watchdog: period 2015-05-15 7:16 at91sam9: watchdog: period Jiří Prchal @ 2015-05-15 13:59 ` Bryan Evenson 2015-05-15 14:19 ` Nicolas Ferre 2015-05-15 15:25 ` Boris Brezillon ` (2 subsequent siblings) 3 siblings, 1 reply; 23+ messages in thread From: Bryan Evenson @ 2015-05-15 13:59 UTC (permalink / raw) To: linux-arm-kernel Jiri, > -----Original Message----- > From: linux-arm-kernel [mailto:linux-arm-kernel- > bounces at lists.infradead.org] On Behalf Of Jir? Prchal > Sent: Friday, May 15, 2015 3:17 AM > To: linux-arm-kernel at lists.infradead.org > Cc: Boris Brezillon; Jean-Christophe Plagniol-Villard; Nicolas Ferre > Subject: at91sam9: watchdog: period > > Hi all, > I'm trying to discover what's wrong with watchdog on my board. I didn't find > anything about it on internet so I would ask you for help. > I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors > to GND. Frequency seems to be good since hwclock (RTC) runs pretty > precisely powered from backup and main power too (no NTP). But watchdog > time to reset is still 61s regardless default (16s) or 4s heartbeat setting. No > change to WDT_MR in bootstrap, so in Linux should work. I have the same hardware setup and the watchdog timeout is 15 seconds for me. For my kernel, I am using the Atmel fork at github.com/linux4sam/linux-at91, master branch at commit 5d5b332821753d616e65da6237f0a3330e59b98f. Even though this is based upon the 3.10 kernel, there isn't much that has changed with regard to the RTC or watchdog between 3.10 and 4.03; Atmel has been good on backporting their changes to their fork. Maybe try an older kernel and see if the problem goes away? Regards, Bryan > Here is dump: > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 4.0.2_cpm9g25 (prchal at prchal) (gcc version 4.7.3 > (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #10 > PREEMPT Thu May 14 15:20:24 CEST 2015 > [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), > cr=0005317f > [ 0.000000] CPU: VIVT data cache, VIVT instruction cache > [ 0.000000] Machine model: AKsignal CDU9G25_v6 > [ 0.000000] Memory policy: Data cache writeback > [ 0.000000] AT91: Detected soc type: at91sam9x5 > [ 0.000000] AT91: Detected soc subtype: at91sam9g25 > ... > [ 4.669669] AT91: Starting after watchdog reset > [ 4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1) > ... > > / # killall watchdog > [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being > stopped! > / # [ 1821.123123] watchdog watchdog0: watchdog did not stop! > [ 1882.294294] at91sam9_wdt: I will reset your machine ! > > Thanks for any help. > Jiri > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-15 13:59 ` Bryan Evenson @ 2015-05-15 14:19 ` Nicolas Ferre 2015-05-18 6:25 ` Jiří Prchal 0 siblings, 1 reply; 23+ messages in thread From: Nicolas Ferre @ 2015-05-15 14:19 UTC (permalink / raw) To: linux-arm-kernel Le 15/05/2015 15:59, Bryan Evenson a ?crit : > Jiri, > >> -----Original Message----- >> From: linux-arm-kernel [mailto:linux-arm-kernel- >> bounces at lists.infradead.org] On Behalf Of Jir? Prchal >> Sent: Friday, May 15, 2015 3:17 AM >> To: linux-arm-kernel at lists.infradead.org >> Cc: Boris Brezillon; Jean-Christophe Plagniol-Villard; Nicolas Ferre >> Subject: at91sam9: watchdog: period >> >> Hi all, >> I'm trying to discover what's wrong with watchdog on my board. I didn't find >> anything about it on internet so I would ask you for help. >> I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors >> to GND. Frequency seems to be good since hwclock (RTC) runs pretty >> precisely powered from backup and main power too (no NTP). But watchdog >> time to reset is still 61s regardless default (16s) or 4s heartbeat setting. No >> change to WDT_MR in bootstrap, so in Linux should work. > > I have the same hardware setup and the watchdog timeout is 15 > seconds for me. For my kernel, I am using the Atmel fork at > github.com/linux4sam/linux-at91, master branch at commit > 5d5b332821753d616e65da6237f0a3330e59b98f. FYI, I've just moved the master branch of our github to the newer 3.18-based branch: linux-3.18-at91. Bye, > Even though this is based upon > the 3.10 kernel, there isn't much that has changed with regard to the > RTC or watchdog between 3.10 and 4.03; Atmel has been good on > backporting their changes to their fork. Maybe try an older kernel and > see if the problem goes away? > > > Regards, > Bryan > >> Here is dump: >> [ 0.000000] Booting Linux on physical CPU 0x0 >> [ 0.000000] Linux version 4.0.2_cpm9g25 (prchal at prchal) (gcc version 4.7.3 >> (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #10 >> PREEMPT Thu May 14 15:20:24 CEST 2015 >> [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), >> cr=0005317f >> [ 0.000000] CPU: VIVT data cache, VIVT instruction cache >> [ 0.000000] Machine model: AKsignal CDU9G25_v6 >> [ 0.000000] Memory policy: Data cache writeback >> [ 0.000000] AT91: Detected soc type: at91sam9x5 >> [ 0.000000] AT91: Detected soc subtype: at91sam9g25 >> ... >> [ 4.669669] AT91: Starting after watchdog reset >> [ 4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1) >> ... >> >> / # killall watchdog >> [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being >> stopped! >> / # [ 1821.123123] watchdog watchdog0: watchdog did not stop! >> [ 1882.294294] at91sam9_wdt: I will reset your machine ! >> >> Thanks for any help. >> Jiri >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel at lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > -- Nicolas Ferre ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-15 14:19 ` Nicolas Ferre @ 2015-05-18 6:25 ` Jiří Prchal 0 siblings, 0 replies; 23+ messages in thread From: Jiří Prchal @ 2015-05-18 6:25 UTC (permalink / raw) To: linux-arm-kernel On 15.5.2015 16:19, Nicolas Ferre wrote: >> I have the same hardware setup and the watchdog timeout is 15 >> seconds for me. For my kernel, I am using the Atmel fork at >> github.com/linux4sam/linux-at91, master branch at commit >> 5d5b332821753d616e65da6237f0a3330e59b98f. > > FYI, I've just moved the master branch of our github to the newer > 3.18-based branch: linux-3.18-at91. > > Bye, Since this files at91sam9_wdt.c and at91sam9_wdt.h are without changes between git 3.18 and 4.0.3 I think the problem is somewhere else. Later I can try whole git 3.18 kernel, now I don't have time for it. Bye ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-15 7:16 at91sam9: watchdog: period Jiří Prchal 2015-05-15 13:59 ` Bryan Evenson @ 2015-05-15 15:25 ` Boris Brezillon 2015-05-18 6:27 ` Jiří Prchal 2015-10-06 13:07 ` Jiří Prchal 2015-10-06 18:03 ` Sylvain Rochet 3 siblings, 1 reply; 23+ messages in thread From: Boris Brezillon @ 2015-05-15 15:25 UTC (permalink / raw) To: linux-arm-kernel Hi Jiri, On Fri, 15 May 2015 09:16:37 +0200 Ji?? Prchal <jiri.prchal@aksignal.cz> wrote: > Hi all, > I'm trying to discover what's wrong with watchdog on my board. I didn't find anything about it on internet so I would > ask you for help. > I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors to GND. Frequency seems to be good since > hwclock (RTC) runs pretty precisely powered from backup and main power too (no NTP). But watchdog time to reset is still > 61s regardless default (16s) or 4s heartbeat setting. No change to WDT_MR in bootstrap, so in Linux should work. > Here is dump: > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 4.0.2_cpm9g25 (prchal at prchal) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #10 > PREEMPT Thu May 14 15:20:24 CEST 2015 > [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f > [ 0.000000] CPU: VIVT data cache, VIVT instruction cache > [ 0.000000] Machine model: AKsignal CDU9G25_v6 > [ 0.000000] Memory policy: Data cache writeback > [ 0.000000] AT91: Detected soc type: at91sam9x5 > [ 0.000000] AT91: Detected soc subtype: at91sam9g25 > ... > [ 4.669669] AT91: Starting after watchdog reset > [ 4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1) > ... > > / # killall watchdog > [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped! > / # [ 1821.123123] watchdog watchdog0: watchdog did not stop! > [ 1882.294294] at91sam9_wdt: I will reset your machine ! Is this file present on your board ? /proc/device-tree/ahb/apb/watchdog at fffffe40/atmel,idle-halt If it is then you should patch your DT to remove the property. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-15 15:25 ` Boris Brezillon @ 2015-05-18 6:27 ` Jiří Prchal 2015-05-18 7:27 ` Boris Brezillon 2015-05-19 7:12 ` Boris Brezillon 0 siblings, 2 replies; 23+ messages in thread From: Jiří Prchal @ 2015-05-18 6:27 UTC (permalink / raw) To: linux-arm-kernel On 15.5.2015 17:25, Boris Brezillon wrote: > Is this file present on your board ? > /proc/device-tree/ahb/apb/watchdog at fffffe40/atmel,idle-halt > > If it is then you should patch your DT to remove the property. > > Best Regards, > > Boris > > No, there is only: drwxrwxr-x 2 root root 0 May 18 06:12 . drwxrwxr-x 35 root root 0 May 18 06:12 .. -r--rw-r-- 1 root root 0 May 18 06:12 atmel,dbg-halt -r--rw-r-- 1 root root 4 May 18 06:12 atmel,reset-type -r--rw-r-- 1 root root 9 May 18 06:12 atmel,watchdog-type -r--rw-r-- 1 root root 22 May 18 06:12 compatible -r--rw-r-- 1 root root 12 May 18 06:12 interrupts -r--rw-r-- 1 root root 9 May 18 06:12 name -r--rw-r-- 1 root root 8 May 18 06:12 reg -r--rw-r-- 1 root root 5 May 18 06:12 status -r--rw-r-- 1 root root 4 May 18 06:12 timeout-sec ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-18 6:27 ` Jiří Prchal @ 2015-05-18 7:27 ` Boris Brezillon 2015-05-18 8:17 ` Jiří Prchal 2015-05-19 7:12 ` Boris Brezillon 1 sibling, 1 reply; 23+ messages in thread From: Boris Brezillon @ 2015-05-18 7:27 UTC (permalink / raw) To: linux-arm-kernel On Mon, 18 May 2015 08:27:43 +0200 Ji?? Prchal <jiri.prchal@aksignal.cz> wrote: > > > On 15.5.2015 17:25, Boris Brezillon wrote: > > Is this file present on your board ? > > /proc/device-tree/ahb/apb/watchdog at fffffe40/atmel,idle-halt > > > > If it is then you should patch your DT to remove the property. > > > > Best Regards, > > > > Boris > > > > > No, there is only: > drwxrwxr-x 2 root root 0 May 18 06:12 . > drwxrwxr-x 35 root root 0 May 18 06:12 .. > -r--rw-r-- 1 root root 0 May 18 06:12 atmel,dbg-halt > -r--rw-r-- 1 root root 4 May 18 06:12 atmel,reset-type > -r--rw-r-- 1 root root 9 May 18 06:12 atmel,watchdog-type > -r--rw-r-- 1 root root 22 May 18 06:12 compatible > -r--rw-r-- 1 root root 12 May 18 06:12 interrupts > -r--rw-r-- 1 root root 9 May 18 06:12 name > -r--rw-r-- 1 root root 8 May 18 06:12 reg > -r--rw-r-- 1 root root 5 May 18 06:12 status > -r--rw-r-- 1 root root 4 May 18 06:12 timeout-sec > Can you dump watchdog registers (using devmem) ? -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-18 7:27 ` Boris Brezillon @ 2015-05-18 8:17 ` Jiří Prchal 2015-05-19 3:07 ` Yang, Wenyou 0 siblings, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2015-05-18 8:17 UTC (permalink / raw) To: linux-arm-kernel On 18.5.2015 09:27, Boris Brezillon wrote: > > Can you dump watchdog registers (using devmem) ? / # devmem 0xfffffe40 0x00000000 / # devmem 0xfffffe44 0x1FFF2FFF / # devmem 0xfffffe48 0x00000000 ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-18 8:17 ` Jiří Prchal @ 2015-05-19 3:07 ` Yang, Wenyou 2015-05-19 7:14 ` Boris Brezillon 0 siblings, 1 reply; 23+ messages in thread From: Yang, Wenyou @ 2015-05-19 3:07 UTC (permalink / raw) To: linux-arm-kernel On 2015/5/18 16:17, Ji?? Prchal wrote: > > > On 18.5.2015 09:27, Boris Brezillon wrote: >> >> Can you dump watchdog registers (using devmem) ? > > / # devmem 0xfffffe40 > 0x00000000 > / # devmem 0xfffffe44 > 0x1FFF2FFF > / # devmem 0xfffffe48 > 0x00000000 > The register value is right. I tested the Linux-3.18-at91-linux4sam_4.7 on the at91sam9g35ek. It reset the system in the 16s after removing atmel,idle-halt property. Best Regards, Wenyou Yang ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-19 3:07 ` Yang, Wenyou @ 2015-05-19 7:14 ` Boris Brezillon 2015-05-19 9:01 ` Jiří Prchal 0 siblings, 1 reply; 23+ messages in thread From: Boris Brezillon @ 2015-05-19 7:14 UTC (permalink / raw) To: linux-arm-kernel On Tue, 19 May 2015 11:07:29 +0800 "Yang, Wenyou" <wenyou.yang@atmel.com> wrote: > > > On 2015/5/18 16:17, Ji?? Prchal wrote: > > > > > > On 18.5.2015 09:27, Boris Brezillon wrote: > >> > >> Can you dump watchdog registers (using devmem) ? > > > > / # devmem 0xfffffe40 > > 0x00000000 > > / # devmem 0xfffffe44 > > 0x1FFF2FFF > > / # devmem 0xfffffe48 > > 0x00000000 > > > The register value is right. It seems correct to me too. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-19 7:14 ` Boris Brezillon @ 2015-05-19 9:01 ` Jiří Prchal 2015-05-19 9:14 ` Boris Brezillon 0 siblings, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2015-05-19 9:01 UTC (permalink / raw) To: linux-arm-kernel On 19.5.2015 09:14, Boris Brezillon wrote: > On Tue, 19 May 2015 11:07:29 +0800 > "Yang, Wenyou" <wenyou.yang@atmel.com> wrote: > >> >> >> On 2015/5/18 16:17, Ji?? Prchal wrote: >>> >>> >>> On 18.5.2015 09:27, Boris Brezillon wrote: >>>> >>>> Can you dump watchdog registers (using devmem) ? >>> >>> / # devmem 0xfffffe40 >>> 0x00000000 >>> / # devmem 0xfffffe44 >>> 0x1FFF2FFF >>> / # devmem 0xfffffe48 >>> 0x00000000 >>> >> The register value is right. > > It seems correct to me too. > Not to me, I want 4s: [ 4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1) ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-19 9:01 ` Jiří Prchal @ 2015-05-19 9:14 ` Boris Brezillon 2015-05-19 9:52 ` Jiří Prchal 0 siblings, 1 reply; 23+ messages in thread From: Boris Brezillon @ 2015-05-19 9:14 UTC (permalink / raw) To: linux-arm-kernel On Tue, 19 May 2015 11:01:49 +0200 Ji?? Prchal <jiri.prchal@aksignal.cz> wrote: > > > On 19.5.2015 09:14, Boris Brezillon wrote: > > On Tue, 19 May 2015 11:07:29 +0800 > > "Yang, Wenyou" <wenyou.yang@atmel.com> wrote: > > > >> > >> > >> On 2015/5/18 16:17, Ji?? Prchal wrote: > >>> > >>> > >>> On 18.5.2015 09:27, Boris Brezillon wrote: > >>>> > >>>> Can you dump watchdog registers (using devmem) ? > >>> > >>> / # devmem 0xfffffe40 > >>> 0x00000000 > >>> / # devmem 0xfffffe44 > >>> 0x1FFF2FFF > >>> / # devmem 0xfffffe48 > >>> 0x00000000 > >>> > >> The register value is right. > > > > It seems correct to me too. > > > Not to me, I want 4s: > [ 4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1) There's a difference between your heartbeat (the frequency you refresh/reset your watchdog) and the watchdog expiration time (here set to 16 secs). We usually set the heartbeat to 1/2 or 1/4 the expiration time, so that we're (almost) sure we can reset the watchdog before its expiration. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-19 9:14 ` Boris Brezillon @ 2015-05-19 9:52 ` Jiří Prchal 2015-05-19 10:04 ` Boris Brezillon 0 siblings, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2015-05-19 9:52 UTC (permalink / raw) To: linux-arm-kernel On 19.5.2015 11:14, Boris Brezillon wrote: > > There's a difference between your heartbeat (the frequency you > refresh/reset your watchdog) and the watchdog expiration time (here set > to 16 secs). > We usually set the heartbeat to 1/2 or 1/4 the expiration time, so that > we're (almost) sure we can reset the watchdog before its expiration. > > I'm confused. Why need kernel to know the time in witch userspace process will reset watchdog? And how to change watchdog expiration time? ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-19 9:52 ` Jiří Prchal @ 2015-05-19 10:04 ` Boris Brezillon 2015-05-20 12:39 ` Jiří Prchal 2015-05-21 12:41 ` Jiří Prchal 0 siblings, 2 replies; 23+ messages in thread From: Boris Brezillon @ 2015-05-19 10:04 UTC (permalink / raw) To: linux-arm-kernel On Tue, 19 May 2015 11:52:16 +0200 Ji?? Prchal <jiri.prchal@aksignal.cz> wrote: > > > On 19.5.2015 11:14, Boris Brezillon wrote: > > > > There's a difference between your heartbeat (the frequency you > > refresh/reset your watchdog) and the watchdog expiration time (here set > > to 16 secs). > > We usually set the heartbeat to 1/2 or 1/4 the expiration time, so that > > we're (almost) sure we can reset the watchdog before its expiration. > > > > > I'm confused. Why need kernel to know the time in witch userspace process will reset watchdog? This time is not exposed to userspace, it's the internal heartbeat used by the driver to refresh the watchdog. > And how to change watchdog expiration time? With the atmel,max-heartbeat-sec property. Anyway, that does not explain why your system takes 61 secs to trigger a reset (instead of 16 secs). Can you try to revert this commit [1] ? [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/watchdog/at91sam9_wdt.c?id=d677772e1358924bf487cd833bdc4d50f3f6f64d -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-19 10:04 ` Boris Brezillon @ 2015-05-20 12:39 ` Jiří Prchal 2015-05-21 12:41 ` Jiří Prchal 1 sibling, 0 replies; 23+ messages in thread From: Jiří Prchal @ 2015-05-20 12:39 UTC (permalink / raw) To: linux-arm-kernel On 19.5.2015 12:04, Boris Brezillon wrote: >> I'm confused. Why need kernel to know the time in witch userspace process will reset watchdog? > > This time is not exposed to userspace, it's the internal heartbeat used > by the driver to refresh the watchdog. Kernel driver does refresh? For what is utility "watchdog" in busybox? When I stop this util then it will reboot. > >> And how to change watchdog expiration time? > > With the atmel,max-heartbeat-sec property. No effect on it, still 61s. > > Anyway, that does not explain why your system takes 61 secs to trigger > a reset (instead of 16 secs). > Can you try to revert this commit [1] ? Because of our company internet policy I can't clone git so I tried kernel 3.18.13. No change, still 61s. > > > [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/watchdog/at91sam9_wdt.c?id=d677772e1358924bf487cd833bdc4d50f3f6f64d > ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-19 10:04 ` Boris Brezillon 2015-05-20 12:39 ` Jiří Prchal @ 2015-05-21 12:41 ` Jiří Prchal 2015-05-27 7:11 ` Jiří Prchal 1 sibling, 1 reply; 23+ messages in thread From: Jiří Prchal @ 2015-05-21 12:41 UTC (permalink / raw) To: linux-arm-kernel On 19.5.2015 12:04, Boris Brezillon wrote: > > Anyway, that does not explain why your system takes 61 secs to trigger > a reset (instead of 16 secs). > Can you try to revert this commit [1] ? > > > [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/watchdog/at91sam9_wdt.c?id=d677772e1358924bf487cd833bdc4d50f3f6f64d I reverted this commit: still 61s. By the way, between # [ 109.117117] at91sam9_wdt: I will reset your machine ! and RomBOOT is another 27s. Whole watchdog reboot sequence is about 90s! Slow clock is measured by counter as 32786Hz. ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-21 12:41 ` Jiří Prchal @ 2015-05-27 7:11 ` Jiří Prchal 0 siblings, 0 replies; 23+ messages in thread From: Jiří Prchal @ 2015-05-27 7:11 UTC (permalink / raw) To: linux-arm-kernel On 21.5.2015 14:41, Ji?? Prchal wrote: > On 19.5.2015 12:04, Boris Brezillon wrote: >> >> Anyway, that does not explain why your system takes 61 secs to trigger >> a reset (instead of 16 secs). >> Can you try to revert this commit [1] ? >> >> >> [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/watchdog/at91sam9_wdt.c?id=d677772e1358924bf487cd833bdc4d50f3f6f64d >> > > I reverted this commit: still 61s. > By the way, between > # [ 109.117117] at91sam9_wdt: I will reset your machine ! > and > RomBOOT > is another 27s. > Whole watchdog reboot sequence is about 90s! > Slow clock is measured by counter as 32786Hz. Is something new? ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-18 6:27 ` Jiří Prchal 2015-05-18 7:27 ` Boris Brezillon @ 2015-05-19 7:12 ` Boris Brezillon 2015-05-19 9:00 ` Jiří Prchal 1 sibling, 1 reply; 23+ messages in thread From: Boris Brezillon @ 2015-05-19 7:12 UTC (permalink / raw) To: linux-arm-kernel On Mon, 18 May 2015 08:27:43 +0200 Ji?? Prchal <jiri.prchal@aksignal.cz> wrote: > > > On 15.5.2015 17:25, Boris Brezillon wrote: > > Is this file present on your board ? > > /proc/device-tree/ahb/apb/watchdog at fffffe40/atmel,idle-halt > > > > If it is then you should patch your DT to remove the property. > > > > Best Regards, > > > > Boris > > > > > No, there is only: > drwxrwxr-x 2 root root 0 May 18 06:12 . > drwxrwxr-x 35 root root 0 May 18 06:12 .. > -r--rw-r-- 1 root root 0 May 18 06:12 atmel,dbg-halt Are you debugging your platform with a JTAG (if that's the case and you still want the watchdog to expire in 16 seconds, then you should remove the dbg-halt property). > -r--rw-r-- 1 root root 4 May 18 06:12 atmel,reset-type > -r--rw-r-- 1 root root 9 May 18 06:12 atmel,watchdog-type > -r--rw-r-- 1 root root 22 May 18 06:12 compatible > -r--rw-r-- 1 root root 12 May 18 06:12 interrupts > -r--rw-r-- 1 root root 9 May 18 06:12 name > -r--rw-r-- 1 root root 8 May 18 06:12 reg > -r--rw-r-- 1 root root 5 May 18 06:12 status > -r--rw-r-- 1 root root 4 May 18 06:12 timeout-sec > -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-19 7:12 ` Boris Brezillon @ 2015-05-19 9:00 ` Jiří Prchal 0 siblings, 0 replies; 23+ messages in thread From: Jiří Prchal @ 2015-05-19 9:00 UTC (permalink / raw) To: linux-arm-kernel On 19.5.2015 09:12, Boris Brezillon wrote: > > Are you debugging your platform with a JTAG (if that's the case and you > still want the watchdog to expire in 16 seconds, then you should remove > the dbg-halt property). > No, not debugging. ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-15 7:16 at91sam9: watchdog: period Jiří Prchal 2015-05-15 13:59 ` Bryan Evenson 2015-05-15 15:25 ` Boris Brezillon @ 2015-10-06 13:07 ` Jiří Prchal 2015-10-06 18:03 ` Sylvain Rochet 3 siblings, 0 replies; 23+ messages in thread From: Jiří Prchal @ 2015-10-06 13:07 UTC (permalink / raw) To: linux-arm-kernel Again hi to all, is something new about watchdog period? I just tried kernel 4.3-rc3 with same result. There must be some hw error seems to me. On 15.5.2015 09:16, Ji?? Prchal wrote: > Hi all, > I'm trying to discover what's wrong with watchdog on my board. I didn't find anything about it on internet so I would > ask you for help. > I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors to GND. Frequency seems to be good since > hwclock (RTC) runs pretty precisely powered from backup and main power too (no NTP). But watchdog time to reset is still > 61s regardless default (16s) or 4s heartbeat setting. No change to WDT_MR in bootstrap, so in Linux should work. > Here is dump: > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 4.0.2_cpm9g25 (prchal at prchal) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #10 > PREEMPT Thu May 14 15:20:24 CEST 2015 > [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f > [ 0.000000] CPU: VIVT data cache, VIVT instruction cache > [ 0.000000] Machine model: AKsignal CDU9G25_v6 > [ 0.000000] Memory policy: Data cache writeback > [ 0.000000] AT91: Detected soc type: at91sam9x5 > [ 0.000000] AT91: Detected soc subtype: at91sam9g25 > ... > [ 4.669669] AT91: Starting after watchdog reset > [ 4.675675] at91sam9_wdt: enabled (heartbeat=4 sec, nowayout=1) > ... > > / # killall watchdog > [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped! > / # [ 1821.123123] watchdog watchdog0: watchdog did not stop! > [ 1882.294294] at91sam9_wdt: I will reset your machine ! > > Thanks for any help. > Jiri ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-05-15 7:16 at91sam9: watchdog: period Jiří Prchal ` (2 preceding siblings ...) 2015-10-06 13:07 ` Jiří Prchal @ 2015-10-06 18:03 ` Sylvain Rochet 2015-10-07 7:16 ` Jiří Prchal 2015-10-07 9:22 ` Sylvain Rochet 3 siblings, 2 replies; 23+ messages in thread From: Sylvain Rochet @ 2015-10-06 18:03 UTC (permalink / raw) To: linux-arm-kernel Hi Ji??, On Fri, May 15, 2015 at 09:16:37AM +0200, Ji?? Prchal wrote: > Hi all, > I'm trying to discover what's wrong with watchdog on my board. I didn't find > anything about it on internet so I would ask you for help. > I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors > to GND. Frequency seems to be good since hwclock (RTC) runs pretty precisely > powered from backup and main power too (no NTP). But watchdog time to reset > is still 61s regardless default (16s) or 4s heartbeat setting. No change to > WDT_MR in bootstrap, so in Linux should work. I'm a bit late here but it looks like there is a misunderstanding about the watchdog stack involved here: userland ------- /dev/watchdog0 ------ watchdog0 -> userland wanted reset time value -> userland wanted ping time value ------- internal kernel watchdog interface ------ atmel,at91sam9260-wdt -> atmel,min-heartbeat-sec -> atmel,max-heartbeat-sec watchdog0 is the software interface, controlled by your userland, is it always on top of the hardware watchdog and it calls the watchdog_ops hooks, like watchdog_ops->start(), watchdog_ops->stop(), or watchdog_ops->set_timeout() for this driver depending on the userland willingness to (re)start, stop the watchdog or change the hardware timeout value. watchdog0 have two configurable values, reset time and ping time, the default is 60s for timeout and 30s for ping (the 61s you are seeing is the default timeout value). For example, the watchdog binary from BusyBox allows you to set the watchdog0 reset and ping time using -T and -t arguments: -T N Reboot after N seconds if not reset (default 60) -t N Reset every N seconds (default 30) The -T value is sent to the hardware driver using the watchdog_ops->set_timeout() hook. The -t value is how often you want the watchdog to be (re)started using the watchdog_ops->start() hook. In a perfect world, the watchdog_ops->set_timeout() hook should be able to precisely set the hardware timeout you want, but there is two problems here: - 60 secs timeout is more than supported by this hardware watchdog, which have a maximum timeout value of 16 secs. The driver is able to return to userland that wanted values are not acceptable, but it would means the default watchdog values wouldn't work. - This hardware watchdog is a bit special: its period cannot be changed once started, usually the hardware timeout follows the watchdog0 timeout value wanted by userspace but that's not possible here. That's why this driver is using its own heartbeat software timer to reset the hardware watchdog more often than actually asked by userland. Thus, because we are resetting on your own the hardware watchdog it means that once the software watchdog embedded into this driver expire there is still the hardware watchdog to expire. We try to reset the watchdog counter 4 or 2 times more often than actually requested, in order to avoid spurious watchdog reset. For the 4 times case (the default), we get a hardware timeout between 12 and 16 secs. Conclusion, if you want a fast reset, you have to use a lower atmel,max-heartbeat-sec value as well as using low values for the timeouts values passed to kernel through the watchdog interface "watchdog -T -t". I wonder if we should substract from the watchdog_ops->set_timeout() new_timeout argument value the previously set hardware timeout period, this way we would have a "60 - 16 + 12~16" instead of a "60 + 12~16" watchdog timeout. If someone agree I will propose a patch to do that. > / # killall watchdog > [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped! > [ 1821.123123] watchdog watchdog0: watchdog did not stop! 60 seconds software timeout, this is the default set by userland tools. > [ 1882.294294] at91sam9_wdt: I will reset your machine ! Then 12 to 16 seconds timeout, this is the hardware timeout. Sylvain ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-10-06 18:03 ` Sylvain Rochet @ 2015-10-07 7:16 ` Jiří Prchal 2015-10-07 9:22 ` Sylvain Rochet 1 sibling, 0 replies; 23+ messages in thread From: Jiří Prchal @ 2015-10-07 7:16 UTC (permalink / raw) To: linux-arm-kernel Thanks Sylvain, good explanation, now it's clear for me. It works! The problem is SOLVED! On 6.10.2015 20:03, Sylvain Rochet wrote: > Hi Ji??, > > On Fri, May 15, 2015 at 09:16:37AM +0200, Ji?? Prchal wrote: >> Hi all, >> I'm trying to discover what's wrong with watchdog on my board. I didn't find >> anything about it on internet so I would ask you for help. >> I have a board with sam9g25 and slow clock xtal 32768Hz with 10p capacitors >> to GND. Frequency seems to be good since hwclock (RTC) runs pretty precisely >> powered from backup and main power too (no NTP). But watchdog time to reset >> is still 61s regardless default (16s) or 4s heartbeat setting. No change to >> WDT_MR in bootstrap, so in Linux should work. > > I'm a bit late here but it looks like there is a misunderstanding about > the watchdog stack involved here: > > userland > ------- /dev/watchdog0 ------ > watchdog0 > -> userland wanted reset time value > -> userland wanted ping time value > ------- internal kernel watchdog interface ------ > atmel,at91sam9260-wdt > -> atmel,min-heartbeat-sec > -> atmel,max-heartbeat-sec > > watchdog0 is the software interface, controlled by your userland, is it > always on top of the hardware watchdog and it calls the watchdog_ops > hooks, like watchdog_ops->start(), watchdog_ops->stop(), or > watchdog_ops->set_timeout() for this driver depending on the userland > willingness to (re)start, stop the watchdog or change the hardware > timeout value. > > watchdog0 have two configurable values, reset time and ping time, the > default is 60s for timeout and 30s for ping (the 61s you are > seeing is the default timeout value). > > For example, the watchdog binary from BusyBox allows you to set the > watchdog0 reset and ping time using -T and -t arguments: > -T N Reboot after N seconds if not reset (default 60) > -t N Reset every N seconds (default 30) > > The -T value is sent to the hardware driver using the > watchdog_ops->set_timeout() hook. The -t value is how often you want the > watchdog to be (re)started using the watchdog_ops->start() hook. > > In a perfect world, the watchdog_ops->set_timeout() hook should be able > to precisely set the hardware timeout you want, but there is two > problems here: > > - 60 secs timeout is more than supported by this hardware watchdog, > which have a maximum timeout value of 16 secs. The driver is able to > return to userland that wanted values are not acceptable, but it would > means the default watchdog values wouldn't work. > > - This hardware watchdog is a bit special: its period cannot be > changed once started, usually the hardware timeout follows the watchdog0 > timeout value wanted by userspace but that's not possible here. That's > why this driver is using its own heartbeat software timer to reset the > hardware watchdog more often than actually asked by userland. Thus, > because we are resetting on your own the hardware watchdog it means that > once the software watchdog embedded into this driver expire there is > still the hardware watchdog to expire. > > We try to reset the watchdog counter 4 or 2 times more often than > actually requested, in order to avoid spurious watchdog reset. For the 4 > times case (the default), we get a hardware timeout between 12 and 16 > secs. > > Conclusion, if you want a fast reset, you have to use a lower > atmel,max-heartbeat-sec value as well as using low values for the > timeouts values passed to kernel through the watchdog interface > "watchdog -T -t". > > I wonder if we should substract from the watchdog_ops->set_timeout() > new_timeout argument value the previously set hardware timeout period, > this way we would have a "60 - 16 + 12~16" instead of a "60 + 12~16" > watchdog timeout. If someone agree I will propose a patch to do that. > > >> / # killall watchdog >> [ 1821.114114] watchdog watchdog0: nowayout prevents watchdog being stopped! >> [ 1821.123123] watchdog watchdog0: watchdog did not stop! > > 60 seconds software timeout, this is the default set by userland tools. > >> [ 1882.294294] at91sam9_wdt: I will reset your machine ! > > Then 12 to 16 seconds timeout, this is the hardware timeout. > > > Sylvain > ^ permalink raw reply [flat|nested] 23+ messages in thread
* at91sam9: watchdog: period 2015-10-06 18:03 ` Sylvain Rochet 2015-10-07 7:16 ` Jiří Prchal @ 2015-10-07 9:22 ` Sylvain Rochet 1 sibling, 0 replies; 23+ messages in thread From: Sylvain Rochet @ 2015-10-07 9:22 UTC (permalink / raw) To: linux-arm-kernel Hi, On Tue, Oct 06, 2015 at 08:03:43PM +0200, Sylvain Rochet wrote: > > I wonder if we should substract from the watchdog_ops->set_timeout() > new_timeout argument value the previously set hardware timeout period, > this way we would have a "60 - 16 + 12~16" instead of a "60 + 12~16" > watchdog timeout. If someone agree I will propose a patch to do that. A night of thinking later, it may sounds appealing but this is a stupid idea. We have an overlap hard to deal with if user chooses a ping time close to the timeout (e.g.: 60s timeout, 55s ping time), it sounds stupid to do so but we can't prevent nor check that. So let's keep it simple. Sylvain ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2015-10-07 9:22 UTC | newest] Thread overview: 23+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-05-15 7:16 at91sam9: watchdog: period Jiří Prchal 2015-05-15 13:59 ` Bryan Evenson 2015-05-15 14:19 ` Nicolas Ferre 2015-05-18 6:25 ` Jiří Prchal 2015-05-15 15:25 ` Boris Brezillon 2015-05-18 6:27 ` Jiří Prchal 2015-05-18 7:27 ` Boris Brezillon 2015-05-18 8:17 ` Jiří Prchal 2015-05-19 3:07 ` Yang, Wenyou 2015-05-19 7:14 ` Boris Brezillon 2015-05-19 9:01 ` Jiří Prchal 2015-05-19 9:14 ` Boris Brezillon 2015-05-19 9:52 ` Jiří Prchal 2015-05-19 10:04 ` Boris Brezillon 2015-05-20 12:39 ` Jiří Prchal 2015-05-21 12:41 ` Jiří Prchal 2015-05-27 7:11 ` Jiří Prchal 2015-05-19 7:12 ` Boris Brezillon 2015-05-19 9:00 ` Jiří Prchal 2015-10-06 13:07 ` Jiří Prchal 2015-10-06 18:03 ` Sylvain Rochet 2015-10-07 7:16 ` Jiří Prchal 2015-10-07 9:22 ` Sylvain Rochet
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).