On Tue, 27 Jun 2006 12:16:15 +0200, Roman Zippel said: > Could you please try the patch below? > tv_nsec can shortly become negative, but its absolute value will always be > smaller then the current nsec offset. > Index: linux-2.6-mm/kernel/timer.c > =================================================================== > --- linux-2.6-mm.orig/kernel/timer.c 2006-06-27 11:59:19.000000000 +0200 > +++ linux-2.6-mm/kernel/timer.c 2006-06-27 12:10:28.000000000 +0200 > @@ -1129,7 +1129,7 @@ static void update_wall_time(void) > clocksource_adjust(clock, offset); > > /* store full nanoseconds into xtime */ > - xtime.tv_nsec = clock->xtime_nsec >> clock->shift; > + xtime.tv_nsec = (s64)clock->xtime_nsec >> clock->shift; > clock->xtime_nsec -= (s64)xtime.tv_nsec << clock->shift; > > /* check to see if there is a new clocksource to use */ Sorry Roman... This may indeed be a legitimate bugfix, but it doesn't fix the problem I'm seeing. I've been doing the mm-bisect polka for a bit, and have it narrowed down to this set of patches: time-clocksource-infrastructure.patch time-clocksource-infrastructure-dont-enable-irq-too-early.patch time-use-clocksource-infrastructure-for-update_wall_time.patch time-use-clocksource-infrastructure-for-update_wall_time-mark-few-functions-as-__init.patch time-let-user-request-precision-from-current_tick_length.patch time-use-clocksource-abstraction-for-ntp-adjustments.patch time-use-clocksource-abstraction-for-ntp-adjustments-optimize-out-some-mults-since-gcc-cant-avoid-them.patch time-introduce-arch-generic-time-accessors.patch hangcheck-remove-monotomic_clock-on-x86.patch time-i386-conversion-part-1-move-timer_pitc-to-i8253c.patch time-i386-conversion-part-2-rework-tsc-support.patch time-i386-conversion-part-3-enable-generic-timekeeping.patch time-i386-conversion-part-4-remove-old-timer_opts-code.patch time-i386-clocksource-drivers.patch time-i386-clocksource-drivers-pm-timer-doesnt-use-workaround-if-chipset-is-not-buggy.patch time-i386-clocksource-drivers-pm-timer-doesnt-use-workaround-if-chipset-is-not-buggy-acpi_pm-cleanup.patch time-i386-clocksource-drivers-pm-timer-doesnt-use-workaround-if-chipset-is-not-buggy-acpi_pm-cleanup-fix-missing-to-rename-pmtmr_good-to-acpi_pm_good.patch time-i386-clocksource-drivers-fix-spelling-typos.patch time-rename-clocksource-functions.patch make-pmtmr_ioport-__read_mostly.patch generic-time-add-macro-to-simplify-hide-mask.patch time-fix-time-going-backward-w-clock=pit.patch fix-and-optimize-clock-source-update.patch Does anybody know offhand if it's safe to bisect through here, or if there's a gotcha along the way?
Attachment:
pgpPXxtboz9gh.pgp
Description: PGP signature
- Follow-Ups:
- Re: 2.6.17-mm2 hrtimer code wedges at boot?
- From: Roman Zippel <[email protected]>
- Re: 2.6.17-mm2 hrtimer code wedges at boot?
- References:
- 2.6.17-mm2
- From: Andrew Morton <[email protected]>
- 2.6.17-mm2 hrtimer code wedges at boot?
- From: [email protected]
- Re: 2.6.17-mm2 hrtimer code wedges at boot?
- From: Roman Zippel <[email protected]>
- 2.6.17-mm2
- Prev by Date: [PATCH 3/17] [PATCH] 64bit resource: fix up printks for resources in networks drivers
- Next by Date: Re: [patch] fix static linking of NFS
- Previous by thread: Re: 2.6.17-mm2 hrtimer code wedges at boot?
- Next by thread: Re: 2.6.17-mm2 hrtimer code wedges at boot?
- Index(es):
 |