On 03/08/2014 04:27 AM, Jean Delvare wrote:
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?
Bad terminology. We use two watchdogs in parallel. If oe fails to work,
the other does (hopefully ;-)
Do you have one daemon writing to both watchdog device nodes? Or two
daemon instances each writing to one device node?
systemd uses one, the watchdog application the other.
As I understand it, the only benefit of using multiple watchdogs, is if
the watchdog devices (or their drivers) are not 100% reliable, right?
Correct.
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.
Ok, makes sense, but I think it was much earlier than 3.5.
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.
Just like pretty much everything else ;-). I absolutely agree that it
would be great to have a better means to determine both the driver
and the name of the watchdog.
Guenter
--
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
