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

[Zbigniew Jędrzejewski-Szmek]

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.
> > > 
> > > # systemctl daemon-reexec
> > > # LC_ALL=C journalctl -f
> > > mars 11 20:50:15 slice systemd[1]: systemd 198 running in system mode.
> > > (+PAM -LIBWRAP -AUDIT -SELINUX -IMA -S...L +XZ)
> > > mars 11 20:50:15 slice systemd[1]: Hardware watchdog 'SBC-FITPC2
> > > Watchdog', version 0
> > > mars 11 20:50:16 slice systemd[1]: Set hardware watchdog to 1min.
> > > mars 11 20:50:16 slice systemd[1]: Failed to enable hardware watchdog:
> > > Inappropriate ioctl for device
> > Hi Sébastien,
> > thank you for the great bug report.
> 
> 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);
}

> > > So, I thnk this code should be reworked and only do the ioctl at
> > > interval defined in RuntimeWatchdogSec, firstly because we use too
> > > many cycle (global speed/power) and
> > > secondly, because there is no way to trigger a system reset by the
> > > wathdog in these condition.
> > > I'm also interogative about calling ioctl (and trying to reopen
> > > /dev/watchdog) even when the initial setup of the watchdog have
> > > failed.
> > > 
> > > I could provide some patches to fix this if you are interested.
> > Definitely. There are some places in systemd where unexpected failure
> > results in excessive usage of resources. Patches (preferably two,
> > for the two separate issues you describe) are always welcome.
> 
> Well, the ioctl issue above just indicates that the driver sucks, but
> given how weakly the kernel iface is defined this is generally not a
> reason not to continue to ping the hw.
> 
> To me this really appears as if the driver needs some updating, and we
> shouldn't attempt to tape over that by calling the ioctl less often.
> 
> I mean, the whole logic of a watchdog is to ping it when we are still
> alive and well, so that it gets triggered when we aren't. By pinging
> them in every loop we do this when we are awake anyway, so it's
> basically free...
Looking at 'git log drivers/watchdog/sbc_fitpc2_wdt.c', this board is
prone to hanging if not treated very carefully. Hence probably those
sleeps in there. If is a driver/hardward issue to some extent. The question
is whether it makes sense to support it.

Zbyszek