[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kernel losing time
This bit of code was in 2.4.19 in

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.
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

George Anzinger
Preemption patch:
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.184 / U:5.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site