Re: Watchdog drivers and device driver model

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Guenter,

Le Friday 07 March 2014 à 09:29 -0800, Guenter Roeck a écrit :
> On Fri, Mar 07, 2014 at 04:30:46PM +0100, Jean Delvare wrote:
> > Not sure if it would help. If both the native watchdog driver and the
> > IPMI watchdog driver get loaded automatically via module aliases, it
> > will be racy. Only one driver can own /dev/watchdog at any given time,
> > and the use has to decide which one.
>
> At work we are using /dev/watchdog0 and /dev/watchdog1 directly,
> and don't depend on /dev/watchdog (which maps to /dev/watchdog0).
> This is actually quite convenient, as it lets us use the two watchdogs
> to watch each other (I've seen hard system lockups with the mei
> watchdog and the iTCO watchdog on a couple of systems, so I like to
> have a backup).

I admit I don't quite understand how watchdogs can "watch each other"?
Each watchdog is essentially watching the watchdog daemon which is
periodically writing to it, and assuming that daemon alive == system
alive, right?

Do you have one daemon writing to both watchdog device nodes? Or two
daemon instances each writing to one device node?

As I understand it, the only benefit of using multiple watchdogs, is if
the watchdog devices (or their drivers) are not 100% reliable, right?

> Sure, if you insist that the ipmi watchdog is tied to /dev/watchdog,
> no matter what, that is a different issue.

I think that's what the customer wants, yes. That being said, I seem to
recall that not so long ago (on the enterprise scale) you could only
have one watchdog driver running at once, right? Multiple watchdog
support was added with commit 45f5fed3 in kernel v3.5 if I'm not
mistaken. Only the latest SP of our latest product includes that commit.
I suppose this is the reason why our customers still stick
to /dev/watchdog and a single watchdog driver. It might change in the
future, but probably not before the next major version of our product is
released and widely deployed.

> Anyway, in our case it doesn't matter much which watchdog is on
> which device, because we just use both. But I agree that it would
> be nice to have an easy way to determine the underlying device
> from user space (without having to go through the ioctl to get
> the name).

I just checked on my own laptop with kernel 3.0.101 + lots of backports
and after boot I see 3 watchdog devices. All virtual so I have no way to
figure out which driver and physical device is behind
them. /dev/watchdog goes away if I unload iTCO_wdt, /dev/watchdog2 goes
away if I unload mei. /dev/watchdog1 is a mystery.

With kernel 3.12.12 + lots of backports, /dev/watchdog1 is owned by
iTCO_wdt (although sysfs points to driver lpc_ich, as mentioned in a
previous mail.) /dev/watchdog and /dev/watchdog0 are both owned by
mei_me, but I had to guess as they are still a virtual devices (one
misc, one watchdog.)

So there is still some work to get things in good shape. Also this
confirms that the watchdog device node <-> driver mapping is fragile and
can change from one kernel version to the next or even across reboot, so
users shouldn't assume it to be persistent.

-- 
Jean Delvare
SUSE L3 Support




--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux