From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@roeck-us.net (Guenter Roeck) Date: Mon, 15 Feb 2016 17:38:06 -0800 Subject: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...' In-Reply-To: <20160215213606.GD19432@atomide.com> References: <20160215170527.GA24453@roeck-us.net> <20160215190116.GX19432@atomide.com> <56C229A5.8020901@roeck-us.net> <20160215195839.GA19432@atomide.com> <20160215213606.GD19432@atomide.com> Message-ID: <56C27D7E.4060603@roeck-us.net> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 02/15/2016 01:36 PM, Tony Lindgren wrote: > * Rafael J. Wysocki [160215 12:39]: >> On Mon, Feb 15, 2016 at 8:58 PM, Tony Lindgren wrote: >>> * Guenter Roeck [160215 11:41]: >>>> On 02/15/2016 11:01 AM, Tony Lindgren wrote: >>>>> >>>>> https://kernelci.org/boot/all/job/next/kernel/next-20160215/ >>>>> >>>>> The SMP ones seem to fail with some regulator issues? >>>>> >>>> >>>> There is another problem, introduced with 6a0712f6f199e ("PM / OPP: Add >>>> dev_pm_opp_set_rate()"). The kernelci boot log for next-20160212:omap3-overo-tobi >>>> and others experience that problem. >>>> >>>> Essentially, the code now assumes that a CPU clock always has a voltage >>>> regulator attached to it, which is not correct. I sent out a patch to fix >>>> that problem a minute ago. >>> >>> Yes that fixed it thanks. >> >> Can you please also check if this alternative fix from Viresh works: >> >> https://patchwork.kernel.org/patch/8316611/ > > Yes that one too seems to fix the issue on SMP systems for > me: > > Tested-by: Tony Lindgren > Same here. Tested-by: Guenter Roeck Guenter