lkml.org 
[lkml]   [2002]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Re: time() glitch on 2.4.18: solved
    On Tue, 5 Nov 2002, Jim Paris wrote:

    > > BTW, why not trying to resync, with something like :
    > >
    > > if (count >= LATCH)
    > > count = (count >> 8) | inb(0x40) << 8;
    >
    > That's best if we really are out of sync, but it's hard to tell. It
    > could be that the 8253's latch value got clobbered somehow, in which
    > case we definitely want to fix that or our timer interrupts will come
    > out at the wrong rate. We also still need to double-check that
    > count < LATCH after your code.
    >
    > Unless we assume that an unpaired read is more common than having the
    > latch value clobbered in some other way, then I think just resetting
    > the counter should be okay. Since none of this _should_ ever happen
    > (but did on my system, grr), it's probably not worth making it too
    > complicated just to try to figure out what went wrong.
    >
    > Updated patch with the printk and corrected conditional is below.
    >
    > -jim
    >
    > diff -urN linux-2.4.18/arch/i386/kernel/time.c linux-2.4.18-jim/arch/i386/kernel/time.c
    > --- linux-2.4.18/arch/i386/kernel/time.c Fri Mar 15 18:28:53 2002
    > +++ linux-2.4.18-jim/arch/i386/kernel/time.c Tue Nov 5 12:39:38 2002
    > @@ -501,6 +501,18 @@
    >
    > count = inb_p(0x40); /* read the latched count */
    > count |= inb(0x40) << 8;
    > +
    > + /* Any unpaired read will cause the above to swap MSB/LSB
    > + forever. Try to detect this and reset the counter. */
    > + if (count >= LATCH) {
    > + printk(KERN_WARNING
    > + "i8253 count too high! resetting..\n");
    > + outb_p(0x34, 0x43);
    > + outb_p(LATCH & 0xff, 0x40);
    > + outb(LATCH >> 8, 0x40);
    > + count = LATCH - 1;
    > + }
    > +
    > spin_unlock(&i8253_lock);
    >
    > count = ((LATCH-1) - count) * TICK_SIZE;
    > -

    No! You will break many machines. You cannot use out_p() when
    writing the latch it __must__ be out(). the "_p" puts a write
    to another port between the two writes. That will screw up
    the internal state-machine of most PITs including AMD-SC520.

    Again, any time you must make two consecutive writes to the
    same device port to set it, you must not use the "_p" version.
    The above latch setting must be:

    outb(LATCH & 0xff, 0x40);
    outb(LATCH >> 8, 0x40);

    Of course, the second write could have a "_p" option, but
    you won't need it.



    Cheers,
    Dick Johnson
    Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
    Bush : The Fourth Reich of America


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:0.052 / U:0.116 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site