On Thu, Dec 15, 2011 at 1:16 PM, Daniel Lezcano <daniel.lezc...@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 _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
