On 06/08/2015 11:37 PM, Fu Wei wrote:
I would like to stress that pretimeout == 0 should not happen in a
real server system, that is why we defined a SBSA watchdog, but not
a normal one
Clarification - In _your opinion_, a server should always use pretimeout.
But we still need to thinking about the situation that administrator
want to do this on a very special purpose.
I could as well argue that setting pretimeout is the special situation.
Some administrators may not want to bother but just want the system to reset
if a watchdog timeout occurs. _Maybe_ if it happens multiple times,
they might want to set up pretimeout to figure out why.
Declaring that one _has_ to configure pretimeout is just a personal
opinion, nothing else. We don't know what server administrators want,
and we should not dictate anything unless technically necessary.
maybe we can set min_pretimeout = 1 for this driver. that is just a suggestion.
No. It is not technically necessary.
if it must be set to a value > 0 I don't understand why
setting it to 1 (instead of 1 second) would not be sufficient.
it don't have to be 1 second , it can be 0.1, 0.5 or 0.01 second. like
I said before, we just need a time slot to setup WCV in
sbsa_gwdt_start. I have commented this in sbsa_gwdt_set_pretimeout in
this patchset.
I think what you really want to say is that you want to have time to
handle the interrupt. But handling the interrupt is not asked for if
pretimeout == 0.
But I think the minimum time slot depend on implementation, the spec
doesn't mention about this.
Yes, because a minimum value does not exist.
If pretimeout == 0, and we set up WOR a little bigger, it *ONLY*
affect "the worst case" I mention above. in this case, a administrator
set up pretimeout == 0 which should not happen in a real server, then
the system goes very wrong. I don't think it is important that this
server system reset in 1 second or 0.0001 second, at this time, this
server can not provide any useful info anyway(because we don't use
pretimeout).
If system may go wrong, the administrator should set up pretimeout >
0 to figure out what is wrong with it just like he always should do.
Yes, exactly. But otherwise, if pretimeout is set to 0, we want
to reset immediately as directed.
As I interpret the specification, WOR=0 forces WS1 immediately after WS0.
1) if TimeoutRefresh = True:
CompareValue := SystemCounter + WOR (= SystemCounter
WS0 := True
2) TimeoutRefresh is True again, WS0 == True:
WS1 = True
This is exactly the behavior we want if pretimeout == 0. In this situation,
we don't want to handle the interrupt, we just want to reset the system as
fast as possible.
Having said that, have you tested what happens in your system if you
set WOR=0 ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
