Re: gettimeofday non-monotonic on 2.2.7 SMP

Andrea Arcangeli (andrea@suse.de)
Thu, 20 May 1999 13:34:00 +0200 (CEST)


On Wed, 19 May 1999, dave madden wrote:

>A lot of the ticks are lost from 0x40... is that userland? How can I

Yep. If the process is doing iopl(3); cli(), then that's the culprit.

>find out which process? (I suspect the X server: the easiest way to

To discover which is the task that is masking irq for a so long time just
apply this patch against 2.2.*_andrea*.bz2:

Index: arch/i386/kernel/time.c
===================================================================
RCS file: /var/cvs/linux/arch/i386/kernel/time.c,v
retrieving revision 1.1.2.23
diff -u -r1.1.2.23 time.c
--- arch/i386/kernel/time.c 1999/05/07 00:30:11 1.1.2.23
+++ arch/i386/kernel/time.c 1999/05/20 11:27:14
@@ -436,8 +436,9 @@
return;

delta -= 1;
- printk(KERN_NOTICE "recover_lost_timer: lost %lu tick%c from %08lx\n",
- delta, delta > 1 ? 's' : ' ', regs->eip);
+ printk(KERN_NOTICE "recover_lost_timer: lost %lu tick%c from %08lx "
+ "process %s pid %d\n", delta, delta > 1 ? 's' : ' ', regs->eip,
+ current->comm, current->pid);
/*
* With APM enabled the TSC can break, so we don't trust it. -Andrea
*/

I'll checkin it now.

> =>In my patch I implemented a recover_lost_ticks mechanizm that will detect
> =>a lost timer interrupt and will update xtime to take care of the lost irq.
> =>This will only work with TSC enabled, if you don't have the i386 TSC you
> =>will continue to lose time over the time ;) and gettimeofday can't be
> =>monotone in presence of a lost tick.
>
>Is there any way to force gettimeofday not to return an earlier time?

Apply my patch :-). If you want you can disable the printk, then my code
will run silenty and will make your sistem robust against complete cli()
of the order of many seconds. And since it will make sure that your
system-time will be always ok even if many irq got lost, then gettimeofday
will stay monotone all the time and will also report the _right_ time.

Right now there is a KERN_NOTICE just because code that cli() for more
than 1/HZ sec should _not_ run all the time and if it run all the time we
must find where this code is placed.

Andrea Arcangeli

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