On Wed, Dec 14, 2011 at 4:27 PM, Daniel Lezcano
<daniel.lezc...@linaro.org> wrote:

> while trying the linux-next at the point it boots (commit
> be9b7335e70696bee731c152429b1737e42fe163, after v3.2-rc4), I noticed the
> timers were not working properly with CONFIG_NO_HZ.
>
> It is easy to reproduce with 'time sleep 1' where the timer expires 1, 2
> or 3 seconds later.
>
> It seems that does not happen with linux-linaro-3.1 but I was able to
> reproduce the problem on a vanilla kernel 3.1.5.
>
> Is it a known problem ?

Sleeps are only guaranteed at max speed.

Since this is jiffy-based sleep I think these patches (which I just updated
and put into Russell's patch tracker) are needed:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7210/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7211/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7212/1

If these patches solve your issue please ACK them on the linux-arm-kernel
maillist, so Russell et al can see that they solve problems for people...

You will then encounter the same problem at the udelay(), mdelay() etc
to which these patches provide a solution (with an additional ux500 MTU
patch that is somewhere in our tree):
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6873/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6874/1
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6875/1

Linus Walleij

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to