[systemd-devel] Hardware watchdog support, slug speed.

[Lennart Poettering]

On Tue, 12.03.13 00:53, Sébastien Luttringer (seblu at seblu.net) wrote:

> 
> On Mon, Mar 11, 2013 at 11:57 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > On Mon, Mar 11, 2013 at 11:46:55PM +0100, Lennart Poettering wrote:
> >> On Mon, 11.03.13 23:42, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> >>
> >> >
> >> > On Mon, Mar 11, 2013 at 11:11:19PM +0100, Sébastien Luttringer wrote:
> >> > > After reexecuting the daemon, I got the following info in the journal.
> >> Humm the ioctl() is supposed to be cheap. And it is on all hw I have
> >> tested it with. It appears that ob the hw in question it is not so
> >> cheap, but that really sounds like a driver issue to me.
> > It is definitely not cheap:
> >
> > static void wdt_send_data(unsigned char command, unsigned char data)
> > {
> >         outb(data, DATA_PORT);
> >         msleep(200);
> >         outb(command, COMMAND_PORT);
> >         msleep(100);
> > }
> Nice ! This explain why it's so sensitive with this hardware. I see
> there is others drivers doing this.
> 
> rwolf ~/scm/misc/linux/drivers/watchdog $ git grep sleep|cat
> pc87413_wdt.c:		pr_info("Watchdog disabled, sleeping again...\n");
> pcwd.c:			msleep(500);
> sbc8360.c:	msleep_interruptible(100);
> sbc8360.c:	msleep_interruptible(100);
> sbc8360.c:	msleep_interruptible(100);
> sbc_fitpc2_wdt.c:	msleep(200);
> sbc_fitpc2_wdt.c:	msleep(100);
> smsc37b787_wdt.c:		pr_info("Watchdog disabled, sleeping again...\n");
> smsc37b787_wdt.c:	pr_info("Watchdog initialized and sleeping
> (nowayout=%d)...\n",
> wm831x_wdt.c:		gpio_set_value_cansleep(driver_data->update_gpio,
> 
> I'm not sure ioctl to watchdog API can be considered as nonblocking
> and can be used in an event loop calmly.

Ah, if there are sleeps of 500ms in the ioctl and this is used
everywhere then we have to consider the ioctl of the "blocking"
kind. What a fuckup. 

I think the best approach for this might be to make it "non-blocking" in
userspace, i.e. spawn a thread that invokes the ioctl and be done with
it. This should be hidden away as well as we can in watchdog.c, because
threads in PID 1 are just an awful idea, but I guess that's what it takes.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.