On Sat, 06 Feb 2010, Marco d'Itri wrote: > On Feb 06, Henrique de Moraes Holschuh <h...@debian.org> wrote: > > It got renamed to wdt_tco, I think, and it will hard-hang a lot of thinkpads > > if it ever triggers, for example: the SMBIOS can't handle it. > OK, I will blacklist this one.
I'd rather we had a watchdog mini policy that boils down to: Watchdog drivers have to default to *at least* N seconds timeout (N can't be too large, some watchdogs have hardware/firmware limits). All watchdog-enabled packages have to default to *at most* N/2 seconds timeout (probably N/3 is better, though). The blacklisting of watchdog drivers would be switched to default options to ensure the "N seconds timeout", or alternatively, we would need to fix it on the kernel tree. I prefer the options, because AFAIK some kernel drivers default to "leave the timeout to whatever was set by the BIOS", and it would be tough to get that policy changed upstream. > > Anyway, if for any reason we load a watchdog driver, AND any of the watchdog > > userspace packages by mistake, we can cause data loss. > root can cause data loss by running rm -rf / by mistake as well, so this > is not a great argument. And if that happens because of any default config or package maintainer script, it is a "critical" bug. At least the watchdog issues would warrant at most "grave" bugs (and personally I would place them at severity "important", since spurious reboots are a normal and expected failure mode of a watchdog system). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
