Relative hrtimers with a large timeout value might end up as negativetimer values, when the current time is added in hrtimer_start().

This in turn is causing the clockevents_set_next() function to set anhuge timeout and sleep for quite a long time when we have a clocksource which is capable of long sleeps like HPET. With PIT this almostgoes unnoticed as the maximum delta is ~27ms. The non-hrt/nohz codesorts this out in the next timer interrupt, so we never noticed thatproblem which has been there since the first day of hrtimers.

This bug became more apparent in 2.6.24 which activates HPET on morehardware.