Hi Thomas, The logic in hrtimer_start() which controls the reprogram argument to enqueue_hrtimer() looks broken to me. I assume that intent is to set the hardware timer only if the hrtimer is being enqueued on a local base.
The existing test "base == new_base" will skip programming the timer if it was moved from another cpu. Normally switch_hrtimer_base() will find that the timer is already on the local base or will move the timer to the local base. In both of these cases it seems necessary to program the timer. The case where the timer should not be programmed is if switch_hrtimer_base() failed to move the timer and it is still associated with a non-local base. There are two failure mechanisms. The common case fails to set the hardware timer even though the timer has been moved to the local base. This would cause the hrtimer's expiry to be delayed until the time when the hardware timer was currently programmed to expire. In the case where timer could not be moved, we program the local timer using a mishmash of information from the local and remote bases. I ran into this with a Concurrent kernel based on your patch-2.6.18-hrt-dyntick2. I have checked that the logic is still the same in kernel.org. Jim Houston - Concurrent Computer Corp. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
