[coreboot] [PATCH] Halt TCO timer on Intel 3100 chipset
c-d.hailfinger.devel.2006 at gmx.net
Wed Apr 16 18:12:25 CEST 2008
I appreciate that you and others are looking into putting the watchdog
to good use, but most use cases break horribly when you would need the
watchdog timer most. See below.
On 16.04.2008 17:55, Jeremy Jackson wrote:
> On Wed, 2008-04-16 at 17:33 +0200, Carl-Daniel Hailfinger wrote:
>> Please avoid any POST code toggling. There are POST boards out there
>> which display the last n POST codes and make it a lot easier to follow
>> the code path. Once you add POST code toggling, that history is flushed
>> away really fast.
> Perhaps a config option? The same function/inline/macro could be put
> in the code, but de-toothed as far as toggling, for those with a fancier
> POST card.
We have some places where we output POST codes in a tight loop in a
die() function (or whatever it is called). Coupling watchdog timer reset
with outputting POST codes makes sure that the machine will NEVER reboot
on serious errors and we might as well disable the watchdog altogether.
> Toggling aside, the original idea was, to point out there is one thing
> which pokes "keepalive" info already, and perhaps it's just a matter of
> directing that poke to include the TCO timer.
> What is the longest amount of time between any two POST code updates?
> The only think I can think of is ECC ram clearing.
One hour, probably longer. A payload is not guaranteed to poke the TCO
timer, so as long as the payload is running, the TCO timer could fire in
To be honest, I care mostly about v3, so if there is no strong
opposition to this in v2, I won't authoritatively veto it although I
think even risking an interrupt before we can handle it is bad design.
However, once that code comes anywhere near v3, expect it to explode
badly, especially when the machine is already unable to boot and loads
recovery code over serial. Do not expect us to sprinkle watchdog pokes
all over the codebase in v3.
More information about the coreboot