On Thu, Dec 15, 2011 at 1:16 PM, Daniel Lezcano daniel.lezcano@linaro.org wrote:
[Me]
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.
I am not sure to get the point. Do you mean cpufreq max frequency ?
It means that the kernel idea of sleep(1) is, sleep atleast 1 second, possibly more. When the system scales down frequency, say to half the frequency, things start to take twice the time. So sleep(1) may result in 2 seconds of sleep or so.
The patches below are intended to address this...
What happens if you disable CPUfreq? cd /sys/devices/system/cpu/cpu0/cpufreq cat scaling_max_freq > scaling_min_freq
(This should set the CPU to max speed, always.)
Does the problem go away?
Then it's CPUfreq-related.
If it persists we have to look for something else...
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
These three patches do not solve the problem.
How typical :-/
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
I tried to apply these patches on linux-next (again at the point the snowball boots), but they don't apply. They are trying to modify arch/arm/lib/delay.c which does not exist in the current commit neither in the HEAD. Isn't there a patch to be applied before ?
No I think they just need to be rebased.... nobody seems to be driving this right now.
By the way, while reading the description of the patches, I tested with an UP kernel instead of SMP and the problem does not appear.
Hmmmm.
I tried again with a SMP kernel but unplugging cpu1 and the problem is still there.
Try with deactivated CPUfreq and see what happens.
Yours, Linus Walleij