Processing control commands:
> reassign -1 src:debian-installer
Bug #794468 {Done: m...@linux.it (Marco d'Itri)} [general] general: no watchdog
support in installer kernel
Bug reassigned from package 'general' to 'src:debian-installer'.
Ignoring request to alter foun
Your message dated Mon, 3 Aug 2015 14:10:04 +0200
with message-id <20150803121004.gb31...@bongo.bofh.it>
and subject line Re: Bug#794468: general: no watchdog support in installer
kernel
has caused the Debian Bug report #794468,
regarding general: no watchdog support in installer kernel
Control: reassign -1 src:debian-installer
Hi,
Dominik George (2015-08-03):
> The Debian installer images for jessie apparently do not have watchdog
> support enabled in the kernel, so they do not send heartbeats to the
> BIOS.
>
> This results in the installer system aborting
Package: general
Severity: normal
The Debian installer images for jessie apparently do not have watchdog
support enabled in the kernel, so they do not send heartbeats to the
BIOS.
This results in the installer system aborting and the machine resetting
after five minutes, or whatever the BIOS
Package: wnpp
Severity: wishlist
Owner: "gustavo panizzo "
* Package name : python-watchdog
Version : 0.7.0
Upstream Author : Yesudeep Mangalapilly
* URL : https://github.com/gorakhargosh/watchdog
* License : Apache-2.0
Programming Lang: Python
D
_generic.c:255
dev_watchdog+0xb1/0x104()
Feb 7 02:04:47 djuro-desktop kernel: [100141.008060] Hardware name: To Be
Filled By O.E.M.
Feb 7 02:04:47 djuro-desktop kernel: [100141.008063] NETDEV WATCHDOG: eth0
(skge): transmit queue 0 timed out
Feb 7 02:04:47 djuro-desktop kernel: [100141.00806
> > Does it actually perform some kind of checks? What I got from the
>
> Watchdog itself? Yes, which ones depends on your configuration.
> wd_keepalive only triggers the hardware watchdog.
No, I meant wd_keepalive and not watchdog.
> > documentation is that it only wr
> Does it actually perform some kind of checks? What I got from the
Watchdog itself? Yes, which ones depends on your configuration. wd_keepalive
only triggers the hardware watchdog.
> documentation is that it only writes to /dev/watchdog periodically regardless
> what happens. Th
Thanks for the reply.
> Why? Sorry, I'm not sure I actually understand what you're saying.
wd_keepalive
> is started to still have basic watchdog functionality without the additional
> checks performed by the watchdog daemon.
Does it actually perform some kind of checks?
> 1) Is it really the desired behavior that wd_keepalive is started in
> /etc/init.d/watchdog when the watchdog daemon is stopped? If the system shall
Yes.
> be kept from rebooting due to terminating the watchdog process, does it not
> suffice to close /dev/watchdog as it is docum
Hello,
I hope my general questions about the watchdog package belong on this list.
1) Is it really the desired behavior that wd_keepalive is started in
/etc/init.d/watchdog when the watchdog daemon is stopped? If the system shall
be kept from rebooting due to terminating the watchdog process
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
> 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.
>
>
> 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
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 kille
> 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 sho
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.
>
&
ver 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.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) d
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|
defaults, and as far as I recall, some of them
> default to whatever the BIOS or BMC programmed in the watchdog.
This is definitely the case for embedded drivers, they'll generally
inherit the configuration that the hardware has. For many devices a
timeout as long as 10s may not even be possib
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
> &g
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 prob
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.
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
>> tel
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 k
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
itse
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 confi
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.)
>
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 sho
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 watc
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 blackli
is 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
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,
e I can only say that I
> got bad advice from the kernel maintainers...
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249600
>
> 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
ainers...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249600
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.
--
ciao,
Marco
signature.asc
Description: D
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...@lis
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.
[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 sometim
/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
Programming Lang: C
Description : AVR watchdog daemon for Linkstation/Kuroboxes
avr_evtd is a simple and small user space interface to the Linkstation
AVR micro-controller. It doesn't have a lot of special features, but
it's main task is to provide 'keep-alive' messages
43 matches
Mail list logo
