Commit 305e683 introduced a wrap bug that causes task scheduling to failafter sched_clock() wrap. On a 1000 HZ system with 32bit jiffies, thisoccurs after 49.7 days.

Bug was introduced in 2.6.35.12 and is still present in linux-2.6.35.y HEAD.

Symptoms include one task getting all available cpu time while others get_none_. Setting niceness seems to make things even worse. Running this codein a new process after wrap completely lock up user space, thus triggering awatchdog reboot:{ nice(1); while(1); }To reproduce bug in reasonable time, one can up HZ. With 16000 HZ, bug occursafter 3.1 days.Modifying sched_clock() to wrap when jiffies does triggers bug after 5 mins.

The basic problem seems to be that rq->clock_task get stuck forever with areally high value when rq->clock starts over from 0.

I can create a proper patch if the above is acceptable.A more appropriate solution would perhaps be to pull some additional schedcommits into stable branch, like fe44d62 and friends. I don't know enoughabout scheduler internals to tell.

All tests were performed on mips32 systems, but all systems with 32bitjiffies should be affected.