Re: kernel losing time

[george anzinger <george@mvista.com>]

This bit of code was in 2.4.19 in
.../arch/i386/kernel/time.c

The suggestion (from the code) is that the PIT does not
reset to the proper value and that reprogramming it fixes
the problem.  At the same time, this being in the interrupt
handler, it does generate at least one interrupt at or after
it fails to do the right thing.

Notes:  1.) This fix, each time it reprograms the PIT, will
loose (leak) a bit of time.
        2.) The three I/O instructions to read the latch are
slow, AND this is done each interrupt.
        3.) This version does not have a way to eliminate
the code on machines that don't have the problem.
        4.) I reserve judgment on the comment that the spin
lock is not needed.  It, I think, assumes that the PIT is
only accessed from the timer code, but this is not really
true (it ought to be true but is not :()


#if 0 /*
       * SUBTLE: this is not necessary from here because
it's implicit in the
       * write xtime_lock.
       */
		spin_lock(&i8253_lock);
#endif
		outb_p(0x00, 0x43);     /* latch the count ASAP */

		count = inb_p(0x40);    /* read the latched count */
		count |= inb(0x40) << 8;

		/* VIA686a test code... reset the latch if count > max */
		if (count > LATCH-1) {
			static int last_whine;
			outb_p(0x34, 0x43);
			outb_p(LATCH & 0xff, 0x40);
			outb(LATCH >> 8, 0x40);
			count = LATCH - 1;
			if(time_after(jiffies, last_whine))
			{
				printk(KERN_WARNING "probable hardware bug: clock timer
configuration lost - probably a VIA686a.\n");
				printk(KERN_WARNING "probable hardware bug: restoring
chip configuration.\n");
				last_whine = jiffies + HZ;
			}			
		}	

#if 0
		spin_unlock(&i8253_lock);
#endif

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml