On Feb 05, Marco d'Itri wrote:
> I cannot even find anymore this i810_tco/i8xx_tco module, so in the next
> udev upload I will remove all watchdog drivers from the blacklist and
> maybe add back the ones reported as broken.
Done, with the exception of iTCO_wdt which is still blacklisted as
reques
> Any chances of uploading the new version (after it has stabilized and made
> it to testing) to backports.org?
Sure, I'm currently just waiting for it to migrate.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes
On Fri, 19 Feb 2010, Michael Meskes wrote:
> > For the record, the watchdog daemon seems not to be able to deal with 1Hz
> > cleanly (must have something to do with these zombies it likes to keep
> > around for 1s) in my test boxes. It can do 0.5Hz just fine though.
>
> The latest upload 5.7-4 or
> For the record, the watchdog daemon seems not to be able to deal with 1Hz
> cleanly (must have something to do with these zombies it likes to keep
> around for 1s) in my test boxes. It can do 0.5Hz just fine though.
The latest upload 5.7-4 or an older version? The older versions use sleep()
wh
On Mon, 08 Feb 2010, Henrique de Moraes Holschuh wrote:
> On Tue, 09 Feb 2010, Darren Salt wrote:
> > I demand that Guillem Jover may or may not have written...
> > > On Mon, 2010-02-08 at 20:15:30 +0100, Michael Meskes wrote:
> > >> Please keep in mind the OOM killer will only influence watchdog i
> If you want to test forking ability just enable test-binary test without
> giving
> it a test-binary or use an empty one. This will make watchdog fork() and react
> if not possible.
Thinking about this some more, the test for an emtpy test-binary is done
*after* the fork, so it should find the
On Tue, 09 Feb 2010, Michael Meskes wrote:
> > drivers have different defaults, and as far as I recall, some of them
> > default to whatever the BIOS or BMC programmed in the watchdog.
> >
> > A period of 1s would be a much safer default on the userland side.
>
> Okay, will change.
Thanks.
--
On Tue, Feb 09, 2010 at 12:57:29PM -0200, Henrique de Moraes Holschuh wrote:
> The kernel drivers don't always expect pats at 0.016Hz by default. Some
That's what it was years ago.
> drivers have different defaults, and as far as I recall, some of them
> default to whatever the BIOS or BMC progr
On Mon, Feb 08, 2010 at 08:54:23PM +0100, Guillem Jover wrote:
> The OOM killer can be disabled for precious processes by writting the
> string "-17" to “/proc//oom_adj”.
Added in git. Thanks for the hint.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|
On Tue, Feb 09, 2010 at 12:57:29PM -0200, Henrique de Moraes Holschuh wrote:
> On Tue, 09 Feb 2010, Michael Meskes wrote:
> > This looks like a workaround for some other problem to me. Patting at 0.1Hz
> > should be sufficient if the kernel expects a change at 0.016 Hz. I don't
> > have
> > any r
On Tue, 09 Feb 2010, Michael Meskes wrote:
> TOn Mon, Feb 08, 2010 at 11:44:55PM -0200, Henrique de Moraes Holschuh wrote:
> > And while at it, change wd_keepalive and watchdog to default to pat at 1Hz
> > instead of 0.1Hz. That will reduce a _lot_ the changes of spurious
> > reboots.
>
> This lo
TOn Mon, Feb 08, 2010 at 11:44:55PM -0200, Henrique de Moraes Holschuh wrote:
> And while at it, change wd_keepalive and watchdog to default to pat at 1Hz
> instead of 0.1Hz. That will reduce a _lot_ the changes of spurious
> reboots.
This looks like a workaround for some other problem to me. Pat
On Tue, Feb 09, 2010 at 01:20:31AM +, Darren Salt wrote:
> > The OOM killer can be disabled for precious processes by writting the
> > string "-17" to “/proc//oom_adj”.
>
> That sounds to me like a good thing to do by default.
Absolutely agreed. As soon as I find the time.
Michael
--
Michae
On Tue, 09 Feb 2010, Darren Salt wrote:
> I demand that Guillem Jover may or may not have written...
> > On Mon, 2010-02-08 at 20:15:30 +0100, Michael Meskes wrote:
> >> Please keep in mind the OOM killer will only influence watchdog if it
> >> happens to kill it. If you happen to run out of memory
I demand that Guillem Jover may or may not have written...
> On Mon, 2010-02-08 at 20:15:30 +0100, Michael Meskes wrote:
>> Please keep in mind the OOM killer will only influence watchdog if it
>> happens to kill it. If you happen to run out of memory though, you can
>> tell watchdog to test if e
Hi!
On Mon, 2010-02-08 at 20:15:30 +0100, Michael Meskes wrote:
> Please keep in mind the OOM killer will only influence watchdog if it happens
> to kill it. If you happen to run out of memory though, you can tell watchdog
> to
> test if enough free mem is available.
The OOM killer can be disabl
On Mon, Feb 08, 2010 at 04:12:10PM +, Mark Brown wrote:
> The core problem with watchdog WRT stuff like that that is that it's a
> fairly small program and doesn't monitor the state of the rest of
Plus it locks itself into main memory and will not suffer from swappiness
itself.
> userspace so
On Mon, Feb 08, 2010 at 04:02:17PM +0100, Marco d'Itri wrote:
> I am not aware of any other users of /dev/watchdog.
There used to be other programs accessing it, but maybe they all vanished.
> I use the default configuration. The system is broken enough that new
The default configuration in Debi
On Mon, Feb 08, 2010 at 03:51:24PM +0100, Michael Meskes wrote:
> On Mon, Feb 08, 2010 at 04:45:53AM +0100, Marco d'Itri wrote:
> > (BTW, is there any other watchdog daemon? The watchdog package reliably
> > fails to detect when the system is half-killed by OOM.)
> How about explaing your problem
On Feb 08, Michael Meskes wrote:
> On Mon, Feb 08, 2010 at 04:45:53AM +0100, Marco d'Itri wrote:
> > If the defaults for some drivers are wrong then I can't see why they
> > should not be fixed, but if default configuration parameters are needed
> > then they should be provided by the watchdog pa
On Mon, Feb 08, 2010 at 04:45:53AM +0100, Marco d'Itri wrote:
> If the defaults for some drivers are wrong then I can't see why they
> should not be fixed, but if default configuration parameters are needed
> then they should be provided by the watchdog package.
If the watchdog package is the only
On Feb 07, Henrique de Moraes Holschuh wrote:
> I'd rather we had a watchdog mini policy that boils down to:
As the udev and module-init-tools maintainer my goal is to support
automatically loading all the drivers which their maintainers intended
to be automatically loaded and blacklist until the
On Sat, 06 Feb 2010, Marco d'Itri wrote:
> On Feb 06, Henrique de Moraes Holschuh 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
I demand that Marco d'Itri may or may not have written...
> On Feb 06, Henrique de Moraes Holschuh wrote:
>> It got renamed to wdt_tco, I think,
Do you mean iTCO_wdt? If so, then you should know that that's working fine on
my EeePC 901.
>> and it will hard-hang a lot of thinkpads if it ever tri
On Feb 06, Henrique de Moraes Holschuh 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.
> Anyway, if for any reason we load a watchdog driver, AND any of the watchd
On Fri, 05 Feb 2010, Marco d'Itri wrote:
> On Feb 05, Petter Reinholdtsen wrote:
> > do not remember any more details. This was discovered a few years
> > ago, and I hope that crazy driver has been fixed in the mean time.
> So it looks like this *is* my fault, in my defense I can only say that I
On Feb 05, Petter Reinholdtsen wrote:
> do not remember any more details. This was discovered a few years
> ago, and I hope that crazy driver has been fixed in the mean time.
So it looks like this *is* my fault, in my defense I can only say that I
got bad advice from the kernel maintainers...
ht
Petter Reinholdtsen wrote:
> This caused the installer to stop after 1 minute.
Not sure how this could have affected the installer as we don't include any
watchdog modules in D-I (at least, not that I'm aware of).
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
w
On Fri, Feb 05, 2010 at 10:11:25AM +0100, Petter Reinholdtsen wrote:
> [Marco d'Itri]
> > I maintain the package providing it, but I fear it is the result of
> > cargo cult sysadmining. A driver will not engage the watchdog
> > anyway until /dev/watchdog is opened.
> If I remember correctly, the
[Marco d'Itri]
> I maintain the package providing it, but I fear it is the result of
> cargo cult sysadmining. A driver will not engage the watchdog
> anyway until /dev/watchdog is opened.
If I remember correctly, the reason is that the observed behaviour is
that a driver sometimes will engage t
/etc/modprobe.d/blacklist.conf contains this comment, but why?
# watchdog drivers should be loaded only if a watchdog daemon is installed
I maintain the package providing it, but I fear it is the result of
cargo cult sysadmining.
A driver will not engage the watchdog anyway until /dev/watchdog
31 matches
Mail list logo
