"clock timer configuration lost" on Serverworks chipset

"clock timer configuration lost" on Serverworks chipset

[Jim Castleberry]

I'm getting messages saying "clock timer configuration lost - probably
a VIA686a" from 2.2.19 running on a board using the Serverworks HE
chipset.  Reading the list archives it sounds like this problem has
previously been attributed to a possible bug in the VIA chipset.

According to RedHat's bugzilla database, others have seen it on
Serverworks chipsets, too.  And it sounds like using "noapic" sometimes
makes it go away, which doesn't make much sense to me.

How well has the problem been nailed down?  Could it be that it just
showed up first on VIA and the real cause (and fix) remains to be
discovered?  Or does Serverworks somehow have an identical bug in
their chipset?

jcastle

Re: "clock timer configuration lost" on Serverworks chipset

[Alan Cox]

> How well has the problem been nailed down?  Could it be that it just
> showed up first on VIA and the real cause (and fix) remains to be
> discovered?  Or does Serverworks somehow have an identical bug in
> their chipset?

There is a notional off by one in the check at least by the rules of the
original chip which do allow the overflow value to be visible momentarily.
Later -ac checks for > not >=

Re: "clock timer configuration lost" on Serverworks chipset

[Jim Castleberry]

I'm confused.  The 2.2.19 time.c is already doing ">":
    /* VIA686a test code... reset the latch if count > max */
    if (count > LATCH-1) {
        [adjust count and whine]
The 2.2.20-pre2 patch doesn't change time.c, and I don't see
this code in 2.4.4 or 2.4.5pre.

Are you saying the code should be doing the equivalent of
"(count > LATCH)", or is 2.2.19 correct and the whines I'm
seeing mean there really is a problem with the Serverworks
chipset?

Thanks,

jcastle

Alan Cox wrote:
>Jim Castleberry)wrote:
>> How well has the problem been nailed down?  Could it be that it just
>> showed up first on VIA and the real cause (and fix) remains to be
>> discovered?  Or does Serverworks somehow have an identical bug in
>> their chipset?
>
>There is a notional off by one in the check at least by the rules of the
>original chip which do allow the overflow value to be visible momentarily.
>Later -ac checks for > not >=
>

Re: "clock timer configuration lost" on Serverworks chipset

[Alan Cox]

> The 2.2.20-pre2 patch doesn't change time.c, and I don't see
> this code in 2.4.4 or 2.4.5pre.

its in 2.4.4-ac where Im testing the change

>