-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/15/2011 02:06 PM, Linus Walleij wrote: > 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.
Ok, if cpufreq is compiled out, the problem does not occur. If it is compiled in, the problem occurs even if I set the governor to 'performance' or 'userspace' + frequency set to 1000000. - -- <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO6fs5AAoJEAKBbMCpUGYATFQIALtKMkXyCXBjcczOee0oAJ7p kXQBQRS6X6qdPWxewLVvC6UB8Yt7SrpzkM0tpq5KEcWH5MHtd8QgC7g1nw7Fjzkk tIynAaQVG9Sn9NnDR0YFUs/fBISKZtqsp7JfXqJiLVWaeyiyln8OXxiZCw9fRg40 oinhCizvmWn+tnYJcyEMomrIw+tRDy3yBSzmaALgntgWhxeVYHcPKY7lD+1PQ9Ze 9nOP+qfnneI6RWB30bK6frjI6lG97m8wQ5MVBoxnAidrDephgi1I+zGXcvTiWZuZ p4PcgzUSnnulK1aHiSwc3cllgLaMJ4AApGF7VJNAKrGXLDUIPzA6GA9Z3qHKzco= =LymN -----END PGP SIGNATURE----- _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
