Detecting ichlpcib watchdog "NO_REBOOT" state
Sergey Katsev
Question about the ichlpcib watchdog: is there any way to detect from user-space that the driver found "TCO timer reboot disabled by hardware"? (other than looking through the dmesg output?)
If I'm understanding correctly, this message is triggered by the driver detecting and not being able to reset the NO_REBOOT flag on the chip, and means that the watchdog is in NMI-only mode, and will not actually reboot the system.
I'd like to be able to detect this state and use a different watchdog instead in this situation.
Thanks in advance.
Sergey Katsev
Coyote Point Systems
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Thor Lancelot Simon
> Hi all,
>
> Question about the ichlpcib watchdog: is there any way to detect from user-space that the driver found "TCO timer reboot disabled by hardware"? (other than looking through the dmesg output?)
>
> If I'm understanding correctly, this message is triggered by the driver detecting and not being able to reset the NO_REBOOT flag on the chip, and means that the watchdog is in NMI-only mode, and will not actually reboot the system.
>
> I'd like to be able to detect this state and use a different watchdog instead in this situation.
I would suggest modifying the driver so that it does not attach in this case (since it is
not generally useful when configured this way).
(Please send patches)
Thor
Christos Zoulas
Thor Lancelot Simon <t...@panix.com> wrote:
>On Fri, Jun 03, 2011 at 11:20:12AM -0400, Sergey Katsev wrote:
>> Hi all,
>>
>> Question about the ichlpcib watchdog: is there any way to detect from
>user-space that the driver found "TCO timer reboot disabled by
>hardware"? (other than looking through the dmesg output?)
>>
>> If I'm understanding correctly, this message is triggered by the
>driver detecting and not being able to reset the NO_REBOOT flag on the
>chip, and means that the watchdog is in NMI-only mode, and will not
>actually reboot the system.
>>
>> I'd like to be able to detect this state and use a different watchdog
>instead in this situation.
>
>I would suggest modifying the driver so that it does not attach in this
>case (since it is
>not generally useful when configured this way).
Or set a sysctl to indicate this.
christos
David Young
> On Fri, Jun 03, 2011 at 11:20:12AM -0400, Sergey Katsev wrote:
> > Hi all,
> >
> > Question about the ichlpcib watchdog: is there any way to detect from user-space that the driver found "TCO timer reboot disabled by hardware"? (other than looking through the dmesg output?)
> >
> > If I'm understanding correctly, this message is triggered by the driver detecting and not being able to reset the NO_REBOOT flag on the chip, and means that the watchdog is in NMI-only mode, and will not actually reboot the system.
> >
> > I'd like to be able to detect this state and use a different watchdog instead in this situation.
>
> I would suggest modifying the driver so that it does not attach in
> this case (since it is not generally useful when configured this way).
I agree with Thor on "principle of least surprise" grounds: NetBSD
shouldn't attach the watchdog that will not actually reboot the system.
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24
Joerg Sonnenberger
> I agree with Thor on "principle of least surprise" grounds: NetBSD
Having the watchdog still allows you to enter DDB. Think one step ahead:
certain ICH6 generations can't reboot the system, but are not detectable
by software. The Thinkpad R52 had that problem. Either the watchdog API
should allow to specify what types of watch dog actions are (not)
possible or it needs to be exported via side channel. The functionality
of the hardware is still useful.
Joerg
Thor Lancelot Simon
> On Sat, Jun 04, 2011 at 11:01:09AM -0500, David Young wrote:
>
> Having the watchdog still allows you to enter DDB. Think one step ahead:
> certain ICH6 generations can't reboot the system, but are not detectable
> by software. The Thinkpad R52 had that problem. Either the watchdog API
> should allow to specify what types of watch dog actions are (not)
> possible or it needs to be exported via side channel. The functionality
> of the hardware is still useful.
It's not the same semantics as any other known watchdog.
Semantic confusion benefits nobody. Until the watchdog code can
express a "does something useful but doesn't reboot the system"
watchdog, it should be disabled by default.
--
Thor Lancelot Simon t...@panix.com
"All of my opinions are consistent, but I cannot present them all
at once." -Jean-Jacques Rousseau, On The Social Contract
Matt Thomas
On Jun 4, 2011, at 9:05 PM, Thor Lancelot Simon wrote:
> On Sat, Jun 04, 2011 at 11:25:16PM +0200, Joerg Sonnenberger wrote:
>> On Sat, Jun 04, 2011 at 11:01:09AM -0500, David Young wrote:
>>> I agree with Thor on "principle of least surprise" grounds: NetBSD
>>> shouldn't attach the watchdog that will not actually reboot the system.
>>
>> Having the watchdog still allows you to enter DDB. Think one step ahead:
>> certain ICH6 generations can't reboot the system, but are not detectable
>> by software. The Thinkpad R52 had that problem. Either the watchdog API
>> should allow to specify what types of watch dog actions are (not)
>> possible or it needs to be exported via side channel. The functionality
>> of the hardware is still useful.
>
> It's not the same semantics as any other known watchdog.
>
> Semantic confusion benefits nobody. Until the watchdog code can
> express a "does something useful but doesn't reboot the system"
> watchdog, it should be disabled by default.
Well, for mpc85xx, the watchdog will cause a panic which enters ddb if sysctl allows it. If nothing is done, the system will reset in the next watchdog interval.