[BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Steffen Trumtrar]

Hi all!

I'm seeing an issue with the dw_wdt watchdog on the SoCFPGA ARM 
platform with the latest linux-rt v4.18.5-rt4. Actually I seem to 
have the same problem, that these patches try to fix:

  38a1222ae4f364d5bd5221fe305dbb0889f45d15
  Author:     Christophe Leroy <christophe.leroy@c-s.fr>
  AuthorDate: Fri Dec 8 11:18:35 2017 +0100
  Commit:     Wim Van Sebroeck <wim@iguana.be>
  CommitDate: Thu Dec 28 20:45:57 2017 +0100

  Follows:    v4.15-rc3 (345)
  Precedes:   v4.16-rc1 (13997)

  watchdog: core: make sure the watchdog worker always works

  When running a command like 'chrt -f 50 dd if=/dev/zero 
  of=/dev/null',
  the watchdog_worker fails to service the HW watchdog and the
  HW watchdog fires long before the watchdog soft timeout.

  At the moment, the watchdog_worker is invoked as a delayed work.
  Delayed works are handled by non realtime kernel threads. The
  WQ_HIGHPRI flag only increases the niceness of that threads.

  This patch replaces the delayed work logic by kthread delayed 
  work,
  and sets the associated kernel task to SCHED_FIFO with the 
  highest
  priority, in order to ensure that the watchdog worker will run 
  as
  soon as possible.


  1ff688209e2ed23f699269b9733993e2ce123fd2
  Author:     Christophe Leroy <christophe.leroy@c-s.fr>
  AuthorDate: Thu Jan 18 12:11:21 2018 +0100
  Commit:     Wim Van Sebroeck <wim@iguana.be>
  CommitDate: Sun Jan 21 12:44:59 2018 +0100

  Follows:    v4.15-rc3 (349)
  Precedes:   v4.16-rc1 (13993)

  watchdog: core: make sure the watchdog_worker is not deferred

  commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has 
  the
  effect of deferring timer handling in case of high CPU load, 
  hence
  delaying the delayed work allthought the worker is running which
  high realtime priority.

  As hrtimers are not managed by softirqs, this patch replaces the
  delayed work by a plain work and uses an hrtimer to schedule 
  that work.


If I run the same test or 'chrt 50 hackbench 20 -l 150' or any 
task where I change the prio with chrt and that runs long enough, 
I get a system reset from the watchdog because it times out. This 
only happens if the watchdog is already enabled on boot and 
CONFIG_PREEMPT_RT_FULL is set.

Any idea if I'm missing something essential? If I understand it 
correctly, the two commits fix the framework and therefore the 
dw_wdt driver doesn't need any updates.


Best regards,
Steffen

--
Pengutronix e.K.                          | Steffen Trumtrar 
|
Industrial Linux Solutions                | 
http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany| Phone: 
+49-5121-206917-0   |
Amtsgericht Hildesheim, HRA 2686          | Fax: 
+49-5121-206917-5555|

Re: [BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Guenter Roeck]

On 09/18/2018 06:21 AM, Steffen Trumtrar wrote:
> 
> Hi all!
> 
> I'm seeing an issue with the dw_wdt watchdog on the SoCFPGA ARM platform with the latest linux-rt v4.18.5-rt4. Actually I seem to have the same problem, that these patches try to fix:
> 
>   38a1222ae4f364d5bd5221fe305dbb0889f45d15
>   Author:     Christophe Leroy <christophe.leroy@c-s.fr>
>   AuthorDate: Fri Dec 8 11:18:35 2017 +0100
>   Commit:     Wim Van Sebroeck <wim@iguana.be>
>   CommitDate: Thu Dec 28 20:45:57 2017 +0100
> 
>   Follows:    v4.15-rc3 (345)
>   Precedes:   v4.16-rc1 (13997)
> 
>   watchdog: core: make sure the watchdog worker always works
> 
>   When running a command like 'chrt -f 50 dd if=/dev/zero  of=/dev/null',
>   the watchdog_worker fails to service the HW watchdog and the
>   HW watchdog fires long before the watchdog soft timeout.
> 
>   At the moment, the watchdog_worker is invoked as a delayed work.
>   Delayed works are handled by non realtime kernel threads. The
>   WQ_HIGHPRI flag only increases the niceness of that threads.
> 
>   This patch replaces the delayed work logic by kthread delayed  work,
>   and sets the associated kernel task to SCHED_FIFO with the  highest
>   priority, in order to ensure that the watchdog worker will run  as
>   soon as possible.
> 
> 
>   1ff688209e2ed23f699269b9733993e2ce123fd2
>   Author:     Christophe Leroy <christophe.leroy@c-s.fr>
>   AuthorDate: Thu Jan 18 12:11:21 2018 +0100
>   Commit:     Wim Van Sebroeck <wim@iguana.be>
>   CommitDate: Sun Jan 21 12:44:59 2018 +0100
> 
>   Follows:    v4.15-rc3 (349)
>   Precedes:   v4.16-rc1 (13993)
> 
>   watchdog: core: make sure the watchdog_worker is not deferred
> 
>   commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has  the
>   effect of deferring timer handling in case of high CPU load,  hence
>   delaying the delayed work allthought the worker is running which
>   high realtime priority.
> 
>   As hrtimers are not managed by softirqs, this patch replaces the
>   delayed work by a plain work and uses an hrtimer to schedule  that work.
> 
> 
> If I run the same test or 'chrt 50 hackbench 20 -l 150' or any task where I change the prio with chrt and that runs long enough, I get a system reset from the watchdog because it times out. This only happens if the watchdog is already enabled on boot and CONFIG_PREEMPT_RT_FULL is set.
> 
> Any idea if I'm missing something essential? If I understand it correctly, the two commits fix the framework and therefore the dw_wdt driver doesn't need any updates.
> 

I find your e-mail confusing, sorry. The subject says that the watchdog is not
triggering, the description says that it is triggering when it should not.

You also provide no information if the watchdog is active (open from user space)
or not. There is some indication in "This only happens if the watchdog is already
enabled on boot" but that isn't really precise - it may be enabled on boot but still
open. On top of that, your e-mail suggests that the problem may be a regression,
since you refer to a specific kernel release, yet you provide no information if
the very same test worked with a different kernel version, or what that kernel
version would be.

Please not only describe what you are doing, but also provide the complete context.
Specifically,
- Did this ever work ? If yes, what are working kernel versions ?
- Is the watchdog device open ?
- Does it make a difference if it is ?
- What is the configured watchdog timeout (both from BIOS/ROMMON and in Linux) ?

Thanks,
Guenter

Re: [BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Julia Cartwright]

On Tue, Sep 18, 2018 at 03:21:08PM +0200, Steffen Trumtrar wrote:
> 
> Hi all!
> 
> I'm seeing an issue with the dw_wdt watchdog on the SoCFPGA ARM platform
> with the latest linux-rt v4.18.5-rt4. Actually I seem to have the same
> problem, that these patches try to fix:
> 
>  38a1222ae4f364d5bd5221fe305dbb0889f45d15
>  Author:     Christophe Leroy <christophe.leroy@c-s.fr>
>  AuthorDate: Fri Dec 8 11:18:35 2017 +0100
>  Commit:     Wim Van Sebroeck <wim@iguana.be>
>  CommitDate: Thu Dec 28 20:45:57 2017 +0100
> 
>  Follows:    v4.15-rc3 (345)
>  Precedes:   v4.16-rc1 (13997)
> 
>  watchdog: core: make sure the watchdog worker always works
> 
>  When running a command like 'chrt -f 50 dd if=/dev/zero  of=/dev/null',
>  the watchdog_worker fails to service the HW watchdog and the
>  HW watchdog fires long before the watchdog soft timeout.
> 
>  At the moment, the watchdog_worker is invoked as a delayed work.
>  Delayed works are handled by non realtime kernel threads. The
>  WQ_HIGHPRI flag only increases the niceness of that threads.
> 
>  This patch replaces the delayed work logic by kthread delayed  work,
>  and sets the associated kernel task to SCHED_FIFO with the  highest
>  priority, in order to ensure that the watchdog worker will run  as
>  soon as possible.
> 
> 
>  1ff688209e2ed23f699269b9733993e2ce123fd2
>  Author:     Christophe Leroy <christophe.leroy@c-s.fr>
>  AuthorDate: Thu Jan 18 12:11:21 2018 +0100
>  Commit:     Wim Van Sebroeck <wim@iguana.be>
>  CommitDate: Sun Jan 21 12:44:59 2018 +0100
> 
>  Follows:    v4.15-rc3 (349)
>  Precedes:   v4.16-rc1 (13993)
> 
>  watchdog: core: make sure the watchdog_worker is not deferred
> 
>  commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has  the
>  effect of deferring timer handling in case of high CPU load,  hence
>  delaying the delayed work allthought the worker is running which
>  high realtime priority.
> 
>  As hrtimers are not managed by softirqs, this patch replaces the
>  delayed work by a plain work and uses an hrtimer to schedule  that work.

These above two commits are trying very hard to ensure timely wakeup and
execution of the watchdogd thread.  First by moving moving to kthread
delayed work, and secondly to vanilla kthread work + hardirq.

This is sufficient on mainline, because hardirq expiry fns are
unconditionally executed in hardirq context.  With PREEMPT_RT_FULL,
however, the hrtimer expiry functions are executed in softirq context
unless explicitly opted out.

...meaning that w/ PREEMPT_RT_FULL the expiry (and therefore the
watchdogd wakeup) may be indefinitely starved if there are runnable RT
tasks of higher priority than the softirq callback thread (ktimersoftd @
SCHED_FIFO 1 by default).

This is an inversion.

One possible solution is to opt-out of the hrtimer softirq deferral by
making use of the HRTIMER_MODE_HARD, however, the expiry function will
need to be vetted for use in hardirq context w/ PREEMPT_RT_FULL.  From a
cursory glance at the kthread_worker locking, it is not hardirq safe. :-\

   Julia

Re: [BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Steffen Trumtrar]

On Tue, Sep 18, 2018 at 06:46:15AM -0700, Guenter Roeck wrote:
> On 09/18/2018 06:21 AM, Steffen Trumtrar wrote:
> > 
> > Hi all!
> > 
> > I'm seeing an issue with the dw_wdt watchdog on the SoCFPGA ARM platform with the latest linux-rt v4.18.5-rt4. Actually I seem to have the same problem, that these patches try to fix:
> > 
> >   38a1222ae4f364d5bd5221fe305dbb0889f45d15
> >   Author:     Christophe Leroy <christophe.leroy@c-s.fr>
> >   AuthorDate: Fri Dec 8 11:18:35 2017 +0100
> >   Commit:     Wim Van Sebroeck <wim@iguana.be>
> >   CommitDate: Thu Dec 28 20:45:57 2017 +0100
> > 
> >   Follows:    v4.15-rc3 (345)
> >   Precedes:   v4.16-rc1 (13997)
> > 
> >   watchdog: core: make sure the watchdog worker always works
> > 
> >   When running a command like 'chrt -f 50 dd if=/dev/zero  of=/dev/null',
> >   the watchdog_worker fails to service the HW watchdog and the
> >   HW watchdog fires long before the watchdog soft timeout.
> > 
> >   At the moment, the watchdog_worker is invoked as a delayed work.
> >   Delayed works are handled by non realtime kernel threads. The
> >   WQ_HIGHPRI flag only increases the niceness of that threads.
> > 
> >   This patch replaces the delayed work logic by kthread delayed  work,
> >   and sets the associated kernel task to SCHED_FIFO with the  highest
> >   priority, in order to ensure that the watchdog worker will run  as
> >   soon as possible.
> > 
> > 
> >   1ff688209e2ed23f699269b9733993e2ce123fd2
> >   Author:     Christophe Leroy <christophe.leroy@c-s.fr>
> >   AuthorDate: Thu Jan 18 12:11:21 2018 +0100
> >   Commit:     Wim Van Sebroeck <wim@iguana.be>
> >   CommitDate: Sun Jan 21 12:44:59 2018 +0100
> > 
> >   Follows:    v4.15-rc3 (349)
> >   Precedes:   v4.16-rc1 (13993)
> > 
> >   watchdog: core: make sure the watchdog_worker is not deferred
> > 
> >   commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has  the
> >   effect of deferring timer handling in case of high CPU load,  hence
> >   delaying the delayed work allthought the worker is running which
> >   high realtime priority.
> > 
> >   As hrtimers are not managed by softirqs, this patch replaces the
> >   delayed work by a plain work and uses an hrtimer to schedule  that work.
> > 
> > 
> > If I run the same test or 'chrt 50 hackbench 20 -l 150' or any task where I change the prio with chrt and that runs long enough, I get a system reset from the watchdog because it times out. This only happens if the watchdog is already enabled on boot and CONFIG_PREEMPT_RT_FULL is set.
> > 
> > Any idea if I'm missing something essential? If I understand it correctly, the two commits fix the framework and therefore the dw_wdt driver doesn't need any updates.
> > 
> 
> I find your e-mail confusing, sorry. The subject says that the watchdog is not
> triggering, the description says that it is triggering when it should not.
> 

Sorry. Let me try again.
The problem I observe, is that the watchdog is trigged, because it doesn't get pinged.
The ksoftirqd seems to be blocked although it runs at a much higher priority than the
blocking userspace task.

> You also provide no information if the watchdog is active (open from user space)
> or not. There is some indication in "This only happens if the watchdog is already
> enabled on boot" but that isn't really precise - it may be enabled on boot but still
> open. On top of that, your e-mail suggests that the problem may be a regression,
> since you refer to a specific kernel release, yet you provide no information if
> the very same test worked with a different kernel version, or what that kernel
> version would be.
> 
> Please not only describe what you are doing, but also provide the complete context.
> Specifically,
> - Did this ever work ? If yes, what are working kernel versions ?

I don't know, if it ever worked or not. This is the first kernel version I tried.
According to the two commits mentioned, I assume that it won't work in older versions.

> - Is the watchdog device open ?
> - Does it make a difference if it is ?

In my test case, the device is not open. It gets started by the bootloader and than is
running. I tried opening the device after it was already running, but it does not make
a difference. If the watchdog is put into running state by opening it from userspace,
the bug does not occur. If the bootloader starts it and the kernel just continues pinging
the watchdog, it does occur, open or not.

> - What is the configured watchdog timeout (both from BIOS/ROMMON and in Linux) ?

The watchdog is configured to a timeout of 5 seconds, both in bootloader and kernel.
The dw_wdt driver will round it to the nearest value it supports. Higher values do not make
the bug go away.


Thanks,
Steffen

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Guenter Roeck]

On Wed, Sep 19, 2018 at 08:46:19AM +0200, Steffen Trumtrar wrote:
> On Tue, Sep 18, 2018 at 06:46:15AM -0700, Guenter Roeck wrote:
> > On 09/18/2018 06:21 AM, Steffen Trumtrar wrote:
> > > 
> > > Hi all!
> > > 
> > > I'm seeing an issue with the dw_wdt watchdog on the SoCFPGA ARM platform with the latest linux-rt v4.18.5-rt4. Actually I seem to have the same problem, that these patches try to fix:
> > > 
> > >   38a1222ae4f364d5bd5221fe305dbb0889f45d15
> > >   Author:     Christophe Leroy <christophe.leroy@c-s.fr>
> > >   AuthorDate: Fri Dec 8 11:18:35 2017 +0100
> > >   Commit:     Wim Van Sebroeck <wim@iguana.be>
> > >   CommitDate: Thu Dec 28 20:45:57 2017 +0100
> > > 
> > >   Follows:    v4.15-rc3 (345)
> > >   Precedes:   v4.16-rc1 (13997)
> > > 
> > >   watchdog: core: make sure the watchdog worker always works
> > > 
> > >   When running a command like 'chrt -f 50 dd if=/dev/zero  of=/dev/null',
> > >   the watchdog_worker fails to service the HW watchdog and the
> > >   HW watchdog fires long before the watchdog soft timeout.
> > > 
> > >   At the moment, the watchdog_worker is invoked as a delayed work.
> > >   Delayed works are handled by non realtime kernel threads. The
> > >   WQ_HIGHPRI flag only increases the niceness of that threads.
> > > 
> > >   This patch replaces the delayed work logic by kthread delayed  work,
> > >   and sets the associated kernel task to SCHED_FIFO with the  highest
> > >   priority, in order to ensure that the watchdog worker will run  as
> > >   soon as possible.
> > > 
> > > 
> > >   1ff688209e2ed23f699269b9733993e2ce123fd2
> > >   Author:     Christophe Leroy <christophe.leroy@c-s.fr>
> > >   AuthorDate: Thu Jan 18 12:11:21 2018 +0100
> > >   Commit:     Wim Van Sebroeck <wim@iguana.be>
> > >   CommitDate: Sun Jan 21 12:44:59 2018 +0100
> > > 
> > >   Follows:    v4.15-rc3 (349)
> > >   Precedes:   v4.16-rc1 (13993)
> > > 
> > >   watchdog: core: make sure the watchdog_worker is not deferred
> > > 
> > >   commit 4cd13c21b207e ("softirq: Let ksoftirqd do its job") has  the
> > >   effect of deferring timer handling in case of high CPU load,  hence
> > >   delaying the delayed work allthought the worker is running which
> > >   high realtime priority.
> > > 
> > >   As hrtimers are not managed by softirqs, this patch replaces the
> > >   delayed work by a plain work and uses an hrtimer to schedule  that work.
> > > 
> > > 
> > > If I run the same test or 'chrt 50 hackbench 20 -l 150' or any task where I change the prio with chrt and that runs long enough, I get a system reset from the watchdog because it times out. This only happens if the watchdog is already enabled on boot and CONFIG_PREEMPT_RT_FULL is set.
> > > 
> > > Any idea if I'm missing something essential? If I understand it correctly, the two commits fix the framework and therefore the dw_wdt driver doesn't need any updates.
> > > 
> > 
> > I find your e-mail confusing, sorry. The subject says that the watchdog is not
> > triggering, the description says that it is triggering when it should not.
> > 
> 
> Sorry. Let me try again.
> The problem I observe, is that the watchdog is trigged, because it doesn't get pinged.
> The ksoftirqd seems to be blocked although it runs at a much higher priority than the
> blocking userspace task.
> 
Are you sure about that ? The other email seemed to suggest that the userspace
task is running at higher priority.

> > You also provide no information if the watchdog is active (open from user space)
> > or not. There is some indication in "This only happens if the watchdog is already
> > enabled on boot" but that isn't really precise - it may be enabled on boot but still
> > open. On top of that, your e-mail suggests that the problem may be a regression,
> > since you refer to a specific kernel release, yet you provide no information if
> > the very same test worked with a different kernel version, or what that kernel
> > version would be.
> > 
> > Please not only describe what you are doing, but also provide the complete context.
> > Specifically,
> > - Did this ever work ? If yes, what are working kernel versions ?
> 
> I don't know, if it ever worked or not. This is the first kernel version I tried.
> According to the two commits mentioned, I assume that it won't work in older versions.
> 
> > - Is the watchdog device open ?
> > - Does it make a difference if it is ?
> 
> In my test case, the device is not open. It gets started by the bootloader and than is
> running. I tried opening the device after it was already running, but it does not make
> a difference. If the watchdog is put into running state by opening it from userspace,
> the bug does not occur. If the bootloader starts it and the kernel just continues pinging
> the watchdog, it does occur, open or not.
> 
The big question here is if the watchdog daemon that keeps the watchdog open is
running at higher priority than the userspace task taking all available CPU
time.

If the watchdog daemon runs at lower priority, the observed behavior would be
as expected.

Overall, we have a number possibilities to consider:

- The kernel watchdog timer thread is not triggered at all under some
  circumstances, meaning it is not set properly. So far we have no real
  indication that this is the case (since the code works fine unless some
  userspace task takes all available CPU time).
- The watchdog device is closed. The kernel watchdog timer thread is
  starved and does not get to run. The question is what to do in this
  situation. In a real time system, this is almost always a fatal
  condition. Should the system really be kept alive in this situation ?
- The watchdog device is open.
  - The watchdog daemon runs at higher priority than the process taking
    all CPU time. Everything should work as expected.
  - The watchdog daemon runs at the same or at a lower priority than
    the process taking all CPU time. I would argue that, in this case,
    everything is also working as expected: The watchdog daemon is starved,
    does not get to run, and the system resets because, per its configuration,
    it is in bad shape.

Overall, the only real possible problem would be if the watchdog thread
in the kernel does not run because of some bug, and that it is not really
starved. We would probably have to instrument the kernel to find out if
this is the case, unless someone has a better idea.

Am I missing something ?

Thanks,
Guenter

Re: [BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Tim Sander]

Hi

I am also seeing this problem. 
Am Dienstag, 18. September 2018, 15:46:15 CEST schrieb Guenter Roeck:
> Please not only describe what you are doing, but also provide the complete
> context. Specifically,
> - Did this ever work ?
I have not found a working kernel version.
> If yes, what are working kernel versions ?
I have tried different kernel version which where *not* working:
patch-4.11.12-rt15 (with some Altera/Intel driver patches)
4.16.8-rt3
4.18-rc8-rt1
4.18.7-rt5 (with adxl372 iio patches and denali nand race fix reported on 
mainline)
> - Is the watchdog device open ?
Good point: The bootloader arms the watchdog.  Then 
WATCHDOG_HANDLE_BOOT_ENABLED is enabled in kernel.
But i forgot to let usermode take over.

> - Does it make a difference if it is ?
If i set RuntimeWatchdogSec=30 in /etc/systemd/system.conf (i.e. enable 
usermode watchdog) the problem seems to go away (at least i didn't had a 
reboot dony with my short testruns by now).

> - What is the configured watchdog timeout (both from BIOS/ROMMON and in
> Linux) ?
30s

So to wrap up: i have the suspicion that the option 
WATCHDOG_HANDLE_BOOT_ENABLED without usermode taking over in Linux leads to 
some strange behaviour with preempt rt?

Best regards
Tim

Re: [BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Julia Cartwright]

Hello all-

On Wed, Sep 19, 2018 at 12:43:03PM -0700, Guenter Roeck wrote:
> On Wed, Sep 19, 2018 at 08:46:19AM +0200, Steffen Trumtrar wrote:
> > On Tue, Sep 18, 2018 at 06:46:15AM -0700, Guenter Roeck wrote:
[..]
> > The problem I observe, is that the watchdog is trigged, because it doesn't get pinged.
> > The ksoftirqd seems to be blocked although it runs at a much higher priority than the
> > blocking userspace task.
> >
> Are you sure about that ? The other email seemed to suggest that the userspace
> task is running at higher priority.

Also: ksoftirqd is irrelevant on RT for the kernel watchdog thread.  The
relevant thread is ktimersoftd, which is the thread responsible for
invoking hrtimer expiry functions, like what's being used for watchdogd.

[..]
> Overall, we have a number possibilities to consider:
>
> - The kernel watchdog timer thread is not triggered at all under some
>   circumstances, meaning it is not set properly. So far we have no real
>   indication that this is the case (since the code works fine unless some
>   userspace task takes all available CPU time).

What do you mean by "not triggered".  Do you mean woken-up/activated
from a scheduling perspective?  In the case I identified in my other
email, the watchdogd thread wakeup doesn't even occur, even when the
periodic ping timer expires, because ktimersoftd has been starved.

I suspect that's what's going on for Steffen, but am not yet sure.

> - The watchdog device is closed. The kernel watchdog timer thread is
>   starved and does not get to run. The question is what to do in this
>   situation. In a real time system, this is almost always a fatal
>   condition. Should the system really be kept alive in this situation ?

Sometimes its the right decision, sometimes its not.  The only sensible
thing to do is to allow the user make the decision that's right for
their application needs by allowing the relative prioritization of
watchdogd and their application threads.

...which they can do now, but it's not effective on RT because of the
timer deferral through ktimersoftd.

The solution, in my mind, and like I mentioned in my other email, is to
opt-out of the ktimersoftd-deferral mechanism.  This requires some
tweaking with the kthread_worker bits to ensure safety in hardirq
context, but that seems straightforward.  See the below.

   Julia

-- 8< --
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index ffbdc4642ea5..9c2b3e5cebdc 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -945,7 +945,7 @@ static int watchdog_cdev_register(struct watchdog_device *wdd, dev_t devno)
 		return -ENODEV;
 
 	kthread_init_work(&wd_data->work, watchdog_ping_work);
-	hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+	hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD);
 	wd_data->timer.function = watchdog_timer_expired;
 
 	if (wdd->id == 0) {
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index c1961761311d..ad292898f7f2 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -85,7 +85,7 @@ enum {
 
 struct kthread_worker {
 	unsigned int		flags;
-	spinlock_t		lock;
+	raw_spinlock_t		lock;
 	struct list_head	work_list;
 	struct list_head	delayed_work_list;
 	struct task_struct	*task;
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 486dedbd9af5..c1d9ee6671c6 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -597,7 +597,7 @@ void __kthread_init_worker(struct kthread_worker *worker,
 				struct lock_class_key *key)
 {
 	memset(worker, 0, sizeof(struct kthread_worker));
-	spin_lock_init(&worker->lock);
+	raw_spin_lock_init(&worker->lock);
 	lockdep_set_class_and_name(&worker->lock, key, name);
 	INIT_LIST_HEAD(&worker->work_list);
 	INIT_LIST_HEAD(&worker->delayed_work_list);
@@ -639,21 +639,21 @@ int kthread_worker_fn(void *worker_ptr)
 
 	if (kthread_should_stop()) {
 		__set_current_state(TASK_RUNNING);
-		spin_lock_irq(&worker->lock);
+		raw_spin_lock_irq(&worker->lock);
 		worker->task = NULL;
-		spin_unlock_irq(&worker->lock);
+		raw_spin_unlock_irq(&worker->lock);
 		return 0;
 	}
 
 	work = NULL;
-	spin_lock_irq(&worker->lock);
+	raw_spin_lock_irq(&worker->lock);
 	if (!list_empty(&worker->work_list)) {
 		work = list_first_entry(&worker->work_list,
 					struct kthread_work, node);
 		list_del_init(&work->node);
 	}
 	worker->current_work = work;
-	spin_unlock_irq(&worker->lock);
+	raw_spin_unlock_irq(&worker->lock);
 
 	if (work) {
 		__set_current_state(TASK_RUNNING);
@@ -810,12 +810,12 @@ bool kthread_queue_work(struct kthread_worker *worker,
 	bool ret = false;
 	unsigned long flags;
 
-	spin_lock_irqsave(&worker->lock, flags);
+	raw_spin_lock_irqsave(&worker->lock, flags);
 	if (!queuing_blocked(worker, work)) {
 		kthread_insert_work(worker, work, &worker->work_list);
 		ret = true;
 	}
-	spin_unlock_irqrestore(&worker->lock, flags);
+	raw_spin_unlock_irqrestore(&worker->lock, flags);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(kthread_queue_work);
@@ -841,7 +841,7 @@ void kthread_delayed_work_timer_fn(struct timer_list *t)
 	if (WARN_ON_ONCE(!worker))
 		return;
 
-	spin_lock(&worker->lock);
+	raw_spin_lock(&worker->lock);
 	/* Work must not be used with >1 worker, see kthread_queue_work(). */
 	WARN_ON_ONCE(work->worker != worker);
 
@@ -850,7 +850,7 @@ void kthread_delayed_work_timer_fn(struct timer_list *t)
 	list_del_init(&work->node);
 	kthread_insert_work(worker, work, &worker->work_list);
 
-	spin_unlock(&worker->lock);
+	raw_spin_unlock(&worker->lock);
 }
 EXPORT_SYMBOL(kthread_delayed_work_timer_fn);
 
@@ -906,14 +906,14 @@ bool kthread_queue_delayed_work(struct kthread_worker *worker,
 	unsigned long flags;
 	bool ret = false;
 
-	spin_lock_irqsave(&worker->lock, flags);
+	raw_spin_lock_irqsave(&worker->lock, flags);
 
 	if (!queuing_blocked(worker, work)) {
 		__kthread_queue_delayed_work(worker, dwork, delay);
 		ret = true;
 	}
 
-	spin_unlock_irqrestore(&worker->lock, flags);
+	raw_spin_unlock_irqrestore(&worker->lock, flags);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(kthread_queue_delayed_work);
@@ -949,7 +949,7 @@ void kthread_flush_work(struct kthread_work *work)
 	if (!worker)
 		return;
 
-	spin_lock_irq(&worker->lock);
+	raw_spin_lock_irq(&worker->lock);
 	/* Work must not be used with >1 worker, see kthread_queue_work(). */
 	WARN_ON_ONCE(work->worker != worker);
 
@@ -961,7 +961,7 @@ void kthread_flush_work(struct kthread_work *work)
 	else
 		noop = true;
 
-	spin_unlock_irq(&worker->lock);
+	raw_spin_unlock_irq(&worker->lock);
 
 	if (!noop)
 		wait_for_completion(&fwork.done);
@@ -994,9 +994,9 @@ static bool __kthread_cancel_work(struct kthread_work *work, bool is_dwork,
 		 * any queuing is blocked by setting the canceling counter.
 		 */
 		work->canceling++;
-		spin_unlock_irqrestore(&worker->lock, *flags);
+		raw_spin_unlock_irqrestore(&worker->lock, *flags);
 		del_timer_sync(&dwork->timer);
-		spin_lock_irqsave(&worker->lock, *flags);
+		raw_spin_lock_irqsave(&worker->lock, *flags);
 		work->canceling--;
 	}
 
@@ -1043,7 +1043,7 @@ bool kthread_mod_delayed_work(struct kthread_worker *worker,
 	unsigned long flags;
 	int ret = false;
 
-	spin_lock_irqsave(&worker->lock, flags);
+	raw_spin_lock_irqsave(&worker->lock, flags);
 
 	/* Do not bother with canceling when never queued. */
 	if (!work->worker)
@@ -1060,7 +1060,7 @@ bool kthread_mod_delayed_work(struct kthread_worker *worker,
 fast_queue:
 	__kthread_queue_delayed_work(worker, dwork, delay);
 out:
-	spin_unlock_irqrestore(&worker->lock, flags);
+	raw_spin_unlock_irqrestore(&worker->lock, flags);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(kthread_mod_delayed_work);
@@ -1074,7 +1074,7 @@ static bool __kthread_cancel_work_sync(struct kthread_work *work, bool is_dwork)
 	if (!worker)
 		goto out;
 
-	spin_lock_irqsave(&worker->lock, flags);
+	raw_spin_lock_irqsave(&worker->lock, flags);
 	/* Work must not be used with >1 worker, see kthread_queue_work(). */
 	WARN_ON_ONCE(work->worker != worker);
 
@@ -1088,13 +1088,13 @@ static bool __kthread_cancel_work_sync(struct kthread_work *work, bool is_dwork)
 	 * In the meantime, block any queuing by setting the canceling counter.
 	 */
 	work->canceling++;
-	spin_unlock_irqrestore(&worker->lock, flags);
+	raw_spin_unlock_irqrestore(&worker->lock, flags);
 	kthread_flush_work(work);
-	spin_lock_irqsave(&worker->lock, flags);
+	raw_spin_lock_irqsave(&worker->lock, flags);
 	work->canceling--;
 
 out_fast:
-	spin_unlock_irqrestore(&worker->lock, flags);
+	raw_spin_unlock_irqrestore(&worker->lock, flags);
 out:
 	return ret;
 }

Re: [BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Guenter Roeck]

On 09/20/2018 01:48 PM, Julia Cartwright wrote:
> Hello all-
> 
> On Wed, Sep 19, 2018 at 12:43:03PM -0700, Guenter Roeck wrote:
>> On Wed, Sep 19, 2018 at 08:46:19AM +0200, Steffen Trumtrar wrote:
>>> On Tue, Sep 18, 2018 at 06:46:15AM -0700, Guenter Roeck wrote:
> [..]
>>> The problem I observe, is that the watchdog is trigged, because it doesn't get pinged.
>>> The ksoftirqd seems to be blocked although it runs at a much higher priority than the
>>> blocking userspace task.
>>>
>> Are you sure about that ? The other email seemed to suggest that the userspace
>> task is running at higher priority.
> 
> Also: ksoftirqd is irrelevant on RT for the kernel watchdog thread.  The
> relevant thread is ktimersoftd, which is the thread responsible for
> invoking hrtimer expiry functions, like what's being used for watchdogd.
> 
> [..]
>> Overall, we have a number possibilities to consider:
>>
>> - The kernel watchdog timer thread is not triggered at all under some
>>    circumstances, meaning it is not set properly. So far we have no real
>>    indication that this is the case (since the code works fine unless some
>>    userspace task takes all available CPU time).
> 
> What do you mean by "not triggered".  Do you mean woken-up/activated
> from a scheduling perspective?  In the case I identified in my other
> email, the watchdogd thread wakeup doesn't even occur, even when the
> periodic ping timer expires, because ktimersoftd has been starved.
> 

Sorry for not using the correct term. Sometimes I am a bit sloppy.
Yes, I meant "woken-up/activated from a scheduling perspective".

> I suspect that's what's going on for Steffen, but am not yet sure.
> 
>> - The watchdog device is closed. The kernel watchdog timer thread is
>>    starved and does not get to run. The question is what to do in this
>>    situation. In a real time system, this is almost always a fatal
>>    condition. Should the system really be kept alive in this situation ?
> 
> Sometimes its the right decision, sometimes its not.  The only sensible
> thing to do is to allow the user make the decision that's right for
> their application needs by allowing the relative prioritization of
> watchdogd and their application threads.
> 
Agreed, but that doesn't help if the watchdog daemon is not open or if the
hardware watchdog interval is too small and the kernel mechanism is needed
to ping the watchdog.

> ...which they can do now, but it's not effective on RT because of the
> timer deferral through ktimersoftd.
> 
> The solution, in my mind, and like I mentioned in my other email, is to
> opt-out of the ktimersoftd-deferral mechanism.  This requires some
> tweaking with the kthread_worker bits to ensure safety in hardirq
> context, but that seems straightforward.  See the below.
> 
Makes sense to me, though I have no idea what it would take to push
the necessary changes into the core kernel.

However, I must be missing something: Looking into the kernel code,
it seems to me that the spin_lock functions call the respective raw_
spinlock functions right away. With that in mind, why would the kernel
code change be necessary ? Also, I don't see HRTIMER_MODE_REL_HARD
defined anywhere. Is this RT specific ?

Thanks,
Guenter

>     Julia
> 
> -- 8< --
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index ffbdc4642ea5..9c2b3e5cebdc 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -945,7 +945,7 @@ static int watchdog_cdev_register(struct watchdog_device *wdd, dev_t devno)
>   		return -ENODEV;
>   
>   	kthread_init_work(&wd_data->work, watchdog_ping_work);
> -	hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> +	hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD);
>   	wd_data->timer.function = watchdog_timer_expired;
>   
>   	if (wdd->id == 0) {
> diff --git a/include/linux/kthread.h b/include/linux/kthread.h
> index c1961761311d..ad292898f7f2 100644
> --- a/include/linux/kthread.h
> +++ b/include/linux/kthread.h
> @@ -85,7 +85,7 @@ enum {
>   
>   struct kthread_worker {
>   	unsigned int		flags;
> -	spinlock_t		lock;
> +	raw_spinlock_t		lock;
>   	struct list_head	work_list;
>   	struct list_head	delayed_work_list;
>   	struct task_struct	*task;
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index 486dedbd9af5..c1d9ee6671c6 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -597,7 +597,7 @@ void __kthread_init_worker(struct kthread_worker *worker,
>   				struct lock_class_key *key)
>   {
>   	memset(worker, 0, sizeof(struct kthread_worker));
> -	spin_lock_init(&worker->lock);
> +	raw_spin_lock_init(&worker->lock);
>   	lockdep_set_class_and_name(&worker->lock, key, name);
>   	INIT_LIST_HEAD(&worker->work_list);
>   	INIT_LIST_HEAD(&worker->delayed_work_list);
> @@ -639,21 +639,21 @@ int kthread_worker_fn(void *worker_ptr)
>   
>   	if (kthread_should_stop()) {
>   		__set_current_state(TASK_RUNNING);
> -		spin_lock_irq(&worker->lock);
> +		raw_spin_lock_irq(&worker->lock);
>   		worker->task = NULL;
> -		spin_unlock_irq(&worker->lock);
> +		raw_spin_unlock_irq(&worker->lock);
>   		return 0;
>   	}
>   
>   	work = NULL;
> -	spin_lock_irq(&worker->lock);
> +	raw_spin_lock_irq(&worker->lock);
>   	if (!list_empty(&worker->work_list)) {
>   		work = list_first_entry(&worker->work_list,
>   					struct kthread_work, node);
>   		list_del_init(&work->node);
>   	}
>   	worker->current_work = work;
> -	spin_unlock_irq(&worker->lock);
> +	raw_spin_unlock_irq(&worker->lock);
>   
>   	if (work) {
>   		__set_current_state(TASK_RUNNING);
> @@ -810,12 +810,12 @@ bool kthread_queue_work(struct kthread_worker *worker,
>   	bool ret = false;
>   	unsigned long flags;
>   
> -	spin_lock_irqsave(&worker->lock, flags);
> +	raw_spin_lock_irqsave(&worker->lock, flags);
>   	if (!queuing_blocked(worker, work)) {
>   		kthread_insert_work(worker, work, &worker->work_list);
>   		ret = true;
>   	}
> -	spin_unlock_irqrestore(&worker->lock, flags);
> +	raw_spin_unlock_irqrestore(&worker->lock, flags);
>   	return ret;
>   }
>   EXPORT_SYMBOL_GPL(kthread_queue_work);
> @@ -841,7 +841,7 @@ void kthread_delayed_work_timer_fn(struct timer_list *t)
>   	if (WARN_ON_ONCE(!worker))
>   		return;
>   
> -	spin_lock(&worker->lock);
> +	raw_spin_lock(&worker->lock);
>   	/* Work must not be used with >1 worker, see kthread_queue_work(). */
>   	WARN_ON_ONCE(work->worker != worker);
>   
> @@ -850,7 +850,7 @@ void kthread_delayed_work_timer_fn(struct timer_list *t)
>   	list_del_init(&work->node);
>   	kthread_insert_work(worker, work, &worker->work_list);
>   
> -	spin_unlock(&worker->lock);
> +	raw_spin_unlock(&worker->lock);
>   }
>   EXPORT_SYMBOL(kthread_delayed_work_timer_fn);
>   
> @@ -906,14 +906,14 @@ bool kthread_queue_delayed_work(struct kthread_worker *worker,
>   	unsigned long flags;
>   	bool ret = false;
>   
> -	spin_lock_irqsave(&worker->lock, flags);
> +	raw_spin_lock_irqsave(&worker->lock, flags);
>   
>   	if (!queuing_blocked(worker, work)) {
>   		__kthread_queue_delayed_work(worker, dwork, delay);
>   		ret = true;
>   	}
>   
> -	spin_unlock_irqrestore(&worker->lock, flags);
> +	raw_spin_unlock_irqrestore(&worker->lock, flags);
>   	return ret;
>   }
>   EXPORT_SYMBOL_GPL(kthread_queue_delayed_work);
> @@ -949,7 +949,7 @@ void kthread_flush_work(struct kthread_work *work)
>   	if (!worker)
>   		return;
>   
> -	spin_lock_irq(&worker->lock);
> +	raw_spin_lock_irq(&worker->lock);
>   	/* Work must not be used with >1 worker, see kthread_queue_work(). */
>   	WARN_ON_ONCE(work->worker != worker);
>   
> @@ -961,7 +961,7 @@ void kthread_flush_work(struct kthread_work *work)
>   	else
>   		noop = true;
>   
> -	spin_unlock_irq(&worker->lock);
> +	raw_spin_unlock_irq(&worker->lock);
>   
>   	if (!noop)
>   		wait_for_completion(&fwork.done);
> @@ -994,9 +994,9 @@ static bool __kthread_cancel_work(struct kthread_work *work, bool is_dwork,
>   		 * any queuing is blocked by setting the canceling counter.
>   		 */
>   		work->canceling++;
> -		spin_unlock_irqrestore(&worker->lock, *flags);
> +		raw_spin_unlock_irqrestore(&worker->lock, *flags);
>   		del_timer_sync(&dwork->timer);
> -		spin_lock_irqsave(&worker->lock, *flags);
> +		raw_spin_lock_irqsave(&worker->lock, *flags);
>   		work->canceling--;
>   	}
>   
> @@ -1043,7 +1043,7 @@ bool kthread_mod_delayed_work(struct kthread_worker *worker,
>   	unsigned long flags;
>   	int ret = false;
>   
> -	spin_lock_irqsave(&worker->lock, flags);
> +	raw_spin_lock_irqsave(&worker->lock, flags);
>   
>   	/* Do not bother with canceling when never queued. */
>   	if (!work->worker)
> @@ -1060,7 +1060,7 @@ bool kthread_mod_delayed_work(struct kthread_worker *worker,
>   fast_queue:
>   	__kthread_queue_delayed_work(worker, dwork, delay);
>   out:
> -	spin_unlock_irqrestore(&worker->lock, flags);
> +	raw_spin_unlock_irqrestore(&worker->lock, flags);
>   	return ret;
>   }
>   EXPORT_SYMBOL_GPL(kthread_mod_delayed_work);
> @@ -1074,7 +1074,7 @@ static bool __kthread_cancel_work_sync(struct kthread_work *work, bool is_dwork)
>   	if (!worker)
>   		goto out;
>   
> -	spin_lock_irqsave(&worker->lock, flags);
> +	raw_spin_lock_irqsave(&worker->lock, flags);
>   	/* Work must not be used with >1 worker, see kthread_queue_work(). */
>   	WARN_ON_ONCE(work->worker != worker);
>   
> @@ -1088,13 +1088,13 @@ static bool __kthread_cancel_work_sync(struct kthread_work *work, bool is_dwork)
>   	 * In the meantime, block any queuing by setting the canceling counter.
>   	 */
>   	work->canceling++;
> -	spin_unlock_irqrestore(&worker->lock, flags);
> +	raw_spin_unlock_irqrestore(&worker->lock, flags);
>   	kthread_flush_work(work);
> -	spin_lock_irqsave(&worker->lock, flags);
> +	raw_spin_lock_irqsave(&worker->lock, flags);
>   	work->canceling--;
>   
>   out_fast:
> -	spin_unlock_irqrestore(&worker->lock, flags);
> +	raw_spin_unlock_irqrestore(&worker->lock, flags);
>   out:
>   	return ret;
>   }
> 

Re: [BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Julia Cartwright]

On Fri, Sep 21, 2018 at 06:34:24AM -0700, Guenter Roeck wrote:
> On 09/20/2018 01:48 PM, Julia Cartwright wrote:
> > On Wed, Sep 19, 2018 at 12:43:03PM -0700, Guenter Roeck wrote:
[..]
> > > Overall, we have a number possibilities to consider:
> > > 
> > > - The kernel watchdog timer thread is not triggered at all under some
> > >    circumstances, meaning it is not set properly. So far we have no real
> > >    indication that this is the case (since the code works fine unless some
> > >    userspace task takes all available CPU time).
> > 
> > What do you mean by "not triggered".  Do you mean woken-up/activated
> > from a scheduling perspective?  In the case I identified in my other
> > email, the watchdogd thread wakeup doesn't even occur, even when the
> > periodic ping timer expires, because ktimersoftd has been starved.
> > 
> 
> Sorry for not using the correct term. Sometimes I am a bit sloppy.
> Yes, I meant "woken-up/activated from a scheduling perspective".

Thanks for the clarification.  I think we're on the same page. :)

> > I suspect that's what's going on for Steffen, but am not yet sure.
> > 
> > > - The watchdog device is closed. The kernel watchdog timer thread is
> > >    starved and does not get to run. The question is what to do in this
> > >    situation. In a real time system, this is almost always a fatal
> > >    condition. Should the system really be kept alive in this situation ?
> > 
> > Sometimes its the right decision, sometimes its not.  The only sensible
> > thing to do is to allow the user make the decision that's right for
> > their application needs by allowing the relative prioritization of
> > watchdogd and their application threads.
>
> Agreed, but that doesn't help if the watchdog daemon is not open or if the
> hardware watchdog interval is too small and the kernel mechanism is needed
> to ping the watchdog.

Makes sense.

> > ...which they can do now, but it's not effective on RT because of the
> > timer deferral through ktimersoftd.
> > 
> > The solution, in my mind, and like I mentioned in my other email, is to
> > opt-out of the ktimersoftd-deferral mechanism.  This requires some
> > tweaking with the kthread_worker bits to ensure safety in hardirq
> > context, but that seems straightforward.  See the below.
>
> Makes sense to me, though I have no idea what it would take to push
> the necessary changes into the core kernel.

As of now, this bug doesn't exist in mainline because the hrtimer
deferral bits haven't landed yet, as you note below.

> However, I must be missing something: Looking into the kernel code,
> it seems to me that the spin_lock functions call the respective raw_
> spinlock functions right away. With that in mind, why would the kernel
> code change be necessary ? Also, I don't see HRTIMER_MODE_REL_HARD
> defined anywhere. Is this RT specific ?

Yes, there is no functional difference in mainline currently between a
spin_lock_t and a raw_spin_lock_t.  There is also no
HRTIMER_MODE_REL_HARD like mentioned before.  These are
features/concepts currently only in the RT tree, but should be making
their way into mainline soon.

As far as path forward, I'd like to get some confirmation from Steffen
and/or Tim that the proposed patch fixes their issue, then I'll cook
some proper patches; the kthread_worker bits could go mainline now
because there is no dependency, but the watchdog change will need to be
RT-only for now.

   Julia

Re: [BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Guenter Roeck]

On Fri, Sep 21, 2018 at 04:42:04PM +0000, Julia Cartwright wrote:
> On Fri, Sep 21, 2018 at 06:34:24AM -0700, Guenter Roeck wrote:
> > On 09/20/2018 01:48 PM, Julia Cartwright wrote:
> > > On Wed, Sep 19, 2018 at 12:43:03PM -0700, Guenter Roeck wrote:
> [..]
> > > > Overall, we have a number possibilities to consider:
> > > > 
> > > > - The kernel watchdog timer thread is not triggered at all under some
> > > >    circumstances, meaning it is not set properly. So far we have no real
> > > >    indication that this is the case (since the code works fine unless some
> > > >    userspace task takes all available CPU time).
> > > 
> > > What do you mean by "not triggered".  Do you mean woken-up/activated
> > > from a scheduling perspective?  In the case I identified in my other
> > > email, the watchdogd thread wakeup doesn't even occur, even when the
> > > periodic ping timer expires, because ktimersoftd has been starved.
> > > 
> > 
> > Sorry for not using the correct term. Sometimes I am a bit sloppy.
> > Yes, I meant "woken-up/activated from a scheduling perspective".
> 
> Thanks for the clarification.  I think we're on the same page. :)
> 
> > > I suspect that's what's going on for Steffen, but am not yet sure.
> > > 
> > > > - The watchdog device is closed. The kernel watchdog timer thread is
> > > >    starved and does not get to run. The question is what to do in this
> > > >    situation. In a real time system, this is almost always a fatal
> > > >    condition. Should the system really be kept alive in this situation ?
> > > 
> > > Sometimes its the right decision, sometimes its not.  The only sensible
> > > thing to do is to allow the user make the decision that's right for
> > > their application needs by allowing the relative prioritization of
> > > watchdogd and their application threads.
> >
> > Agreed, but that doesn't help if the watchdog daemon is not open or if the
> > hardware watchdog interval is too small and the kernel mechanism is needed
> > to ping the watchdog.
> 
> Makes sense.
> 
> > > ...which they can do now, but it's not effective on RT because of the
> > > timer deferral through ktimersoftd.
> > > 
> > > The solution, in my mind, and like I mentioned in my other email, is to
> > > opt-out of the ktimersoftd-deferral mechanism.  This requires some
> > > tweaking with the kthread_worker bits to ensure safety in hardirq
> > > context, but that seems straightforward.  See the below.
> >
> > Makes sense to me, though I have no idea what it would take to push
> > the necessary changes into the core kernel.
> 
> As of now, this bug doesn't exist in mainline because the hrtimer
> deferral bits haven't landed yet, as you note below.
> 
> > However, I must be missing something: Looking into the kernel code,
> > it seems to me that the spin_lock functions call the respective raw_
> > spinlock functions right away. With that in mind, why would the kernel
> > code change be necessary ? Also, I don't see HRTIMER_MODE_REL_HARD
> > defined anywhere. Is this RT specific ?
> 
> Yes, there is no functional difference in mainline currently between a
> spin_lock_t and a raw_spin_lock_t.  There is also no
> HRTIMER_MODE_REL_HARD like mentioned before.  These are
> features/concepts currently only in the RT tree, but should be making
> their way into mainline soon.
> 
> As far as path forward, I'd like to get some confirmation from Steffen
> and/or Tim that the proposed patch fixes their issue, then I'll cook
> some proper patches; the kthread_worker bits could go mainline now
> because there is no dependency, but the watchdog change will need to be
> RT-only for now.
> 
SGTM.

Thanks,
Guenter

Re: [BUG] dw_wdt watchdog on linux-rt 4.18.5-rt4 not triggering

[Steffen Trumtrar]

Hi!

Julia Cartwright <julia@ni.com> writes:

> Hello all-
>
> On Wed, Sep 19, 2018 at 12:43:03PM -0700, Guenter Roeck wrote:
>> On Wed, Sep 19, 2018 at 08:46:19AM +0200, Steffen Trumtrar 
>> wrote:
>> > On Tue, Sep 18, 2018 at 06:46:15AM -0700, Guenter Roeck 
>> > wrote:
> [..]
>> > The problem I observe, is that the watchdog is trigged, 
>> > because it doesn't get pinged.
>> > The ksoftirqd seems to be blocked although it runs at a much 
>> > higher priority than the
>> > blocking userspace task.
>> >
>> Are you sure about that ? The other email seemed to suggest 
>> that the userspace
>> task is running at higher priority.
>
> Also: ksoftirqd is irrelevant on RT for the kernel watchdog 
> thread.  The
> relevant thread is ktimersoftd, which is the thread responsible 
> for
> invoking hrtimer expiry functions, like what's being used for 
> watchdogd.
>
> [..]
>> Overall, we have a number possibilities to consider:
>>
>> - The kernel watchdog timer thread is not triggered at all 
>> under some
>>   circumstances, meaning it is not set properly. So far we have 
>>   no real
>>   indication that this is the case (since the code works fine 
>>   unless some
>>   userspace task takes all available CPU time).
>
> What do you mean by "not triggered".  Do you mean 
> woken-up/activated
> from a scheduling perspective?  In the case I identified in my 
> other
> email, the watchdogd thread wakeup doesn't even occur, even when 
> the
> periodic ping timer expires, because ktimersoftd has been 
> starved.
>
> I suspect that's what's going on for Steffen, but am not yet 
> sure.
>
>> - The watchdog device is closed. The kernel watchdog timer 
>> thread is
>>   starved and does not get to run. The question is what to do 
>>   in this
>>   situation. In a real time system, this is almost always a 
>>   fatal
>>   condition. Should the system really be kept alive in this 
>>   situation ?
>
> Sometimes its the right decision, sometimes its not.  The only 
> sensible
> thing to do is to allow the user make the decision that's right 
> for
> their application needs by allowing the relative prioritization 
> of
> watchdogd and their application threads.
>
> ...which they can do now, but it's not effective on RT because 
> of the
> timer deferral through ktimersoftd.
>
> The solution, in my mind, and like I mentioned in my other 
> email, is to
> opt-out of the ktimersoftd-deferral mechanism.  This requires 
> some
> tweaking with the kthread_worker bits to ensure safety in 
> hardirq
> context, but that seems straightforward.  See the below.
>

I just tested your patch and it works for me \o/


Thanks,
Steffen

-- 
Pengutronix e.K.                          | Steffen Trumtrar 
|
Industrial Linux Solutions                | 
http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany| Phone: 
+49-5121-206917-0   |
Amtsgericht Hildesheim, HRA 2686          | Fax: 
+49-5121-206917-5555|