On 04/25/2014 10:11 AM, Viresh Kumar wrote:
> On 25 April 2014 00:33, Meelis Roos wrote:
>
>> [ 240.140176] INFO: task kworker/0:1:116 blocked for more than 120 seconds.
>> [ 240.140353] Not tainted 3.15.0-rc2-dirty #37
>> [ 240.140485] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
On 24 April 2014 15:26, Meelis Roos wrote:
> This is VIA EPIA board with 533 MHz VIA Samuel 2 CPU. Normally, longhaul
> is not enabled automatically but with longhaul.enable=1. It used to work
> up to 3.14 but in 3.15-rc, different cpufreq-related codepaths block for
> long times and cause warning
On 25 April 2014 01:14, Srivatsa S. Bhat
wrote:
> On 04/25/2014 12:33 AM, Meelis Roos wrote:
>>> I see traces of mutex_lock_slowpath() etc in your logs.. Can you please
>>> enable lockdep and sleep-inside-atomic-section check and let us know if
>>> it complains? Specifically, enable these config o
On 25 April 2014 00:33, Meelis Roos wrote:
> [ 240.140176] INFO: task kworker/0:1:116 blocked for more than 120 seconds.
> [ 240.140353] Not tainted 3.15.0-rc2-dirty #37
> [ 240.140485] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 240.140687] kworker/
On 04/25/2014 12:33 AM, Meelis Roos wrote:
>> I see traces of mutex_lock_slowpath() etc in your logs.. Can you please
>> enable lockdep and sleep-inside-atomic-section check and let us know if
>> it complains? Specifically, enable these config options:
>>
>> CONFIG_LOCKDEP_SUPPORT=y
>> CONFIG_DEBUG
> I see traces of mutex_lock_slowpath() etc in your logs.. Can you please
> enable lockdep and sleep-inside-atomic-section check and let us know if
> it complains? Specifically, enable these config options:
>
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_DEBUG_RT_MUTEXES=y
> CONFIG_DEBUG_PI_LIST=y
> CONFIG_
> On 24 April 2014 15:46, Meelis Roos wrote:
> > I can add debug to where needed and try it.
>
> I am quite sure below wouldn't fix it, but just wanted to check
> for the corner case :(
>
> Can you please try attached patch (mail's content would be
> broken):
Did not help. Will try lock debuggi
On 04/24/2014 03:46 PM, Meelis Roos wrote:
>>> This is VIA EPIA board with 533 MHz VIA Samuel 2 CPU. Normally, longhaul
>>> is not enabled automatically but with longhaul.enable=1. It used to work
>>> up to 3.14 but in 3.15-rc, different cpufreq-related codepaths block for
>>> long times and cause
On 24 April 2014 15:46, Meelis Roos wrote:
> I can add debug to where needed and try it.
I am quite sure below wouldn't fix it, but just wanted to check
for the corner case :(
Can you please try attached patch (mail's content would be
broken):
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cp
> > This is VIA EPIA board with 533 MHz VIA Samuel 2 CPU. Normally, longhaul
> > is not enabled automatically but with longhaul.enable=1. It used to work
> > up to 3.14 but in 3.15-rc, different cpufreq-related codepaths block for
> > long times and cause warnings.
>
> Probably we haven't introduc
Cc'ing Srivatsa,
On 24 April 2014 15:26, Meelis Roos wrote:
> This is VIA EPIA board with 533 MHz VIA Samuel 2 CPU. Normally, longhaul
> is not enabled automatically but with longhaul.enable=1. It used to work
> up to 3.14 but in 3.15-rc, different cpufreq-related codepaths block for
> long times
This is VIA EPIA board with 533 MHz VIA Samuel 2 CPU. Normally, longhaul
is not enabled automatically but with longhaul.enable=1. It used to work
up to 3.14 but in 3.15-rc, different cpufreq-related codepaths block for
long times and cause warnings.
/usr/bin/cpufreq-set --cpu 0 --governor ondem
12 matches
Mail list logo
