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 se
On 16-02-16, 02:27, Rafael J. Wysocki wrote:
> Yes, that's what we should be doing, but it seemed to me that we didn't.
>
> Or maybe the trace just contained the last one, because that's when the
> crash happened.
Ofcourse, it wouldn't mention the function calls that have already
finished :)
--
On Tuesday, February 16, 2016 06:43:35 AM Viresh Kumar wrote:
> On 15-02-16, 19:41, Rafael J. Wysocki wrote:
> > On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote:
> > > [1.34] [] (__cpufreq_driver_target) from []
> > > (dbs_check_cpu+0x1ac/0x1e8)
> > > [1.34] [] (dbs_check_cpu
On 15-02-16, 19:41, Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote:
> > [1.34] [] (__cpufreq_driver_target) from []
> > (dbs_check_cpu+0x1ac/0x1e8)
> > [1.34] [] (dbs_check_cpu) from []
> > (cpufreq_governor_dbs+0x1fc/0x608)
> > [1.34] []
On 02/15/2016 02:29 PM, Peter Maydell wrote:
On 15 February 2016 at 17:05, Guenter Roeck wrote:
I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
timers with utilization update callbacks' with next-20160215. An example
crash log and bisect results are attached below.
P
On 15 February 2016 at 17:05, Guenter Roeck wrote:
> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
> timers with utilization update callbacks' with next-20160215. An example
> crash log and bisect results are attached below.
>
> Please let me know if there is anything
* 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
On Mon, Feb 15, 2016 at 8:23 PM, Russell King - ARM Linux
wrote:
> On Mon, Feb 15, 2016 at 07:03:33PM +, Marc Zyngier wrote:
>> On 15/02/16 18:54, Rafael J. Wysocki wrote:
>> > That would explain it, thanks.
>> >
>> > So it looks like we should always use irq_work_queue() on UP even if
>> > CO
On Mon, Feb 15, 2016 at 9:09 PM, Guenter Roeck wrote:
> On 02/15/2016 11:58 AM, 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 t
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
On 02/15/2016 11:58 AM, 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 6a0712f6f1
* 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_
* Guenter Roeck [160215 11:47]:
> On Mon, Feb 15, 2016 at 11:42:27AM -0800, Tony Lindgren wrote:
> > * Rafael J. Wysocki [160215 11:28]:
> > >
> > > Guenter, Tony,
> > >
> > > Below is a patch to try, on top of linux-next.
> >
> > Fixes the issue on UP for me:
> >
> > Tested-by: Tony Lindgren
On Mon, Feb 15, 2016 at 11:42:27AM -0800, Tony Lindgren wrote:
> * Rafael J. Wysocki [160215 11:28]:
> >
> > Guenter, Tony,
> >
> > Below is a patch to try, on top of linux-next.
>
> Fixes the issue on UP for me:
>
> Tested-by: Tony Lindgren
>
> > Please let me know if the problem is still a
* Rafael J. Wysocki [160215 11:28]:
>
> Guenter, Tony,
>
> Below is a patch to try, on top of linux-next.
Fixes the issue on UP for me:
Tested-by: Tony Lindgren
> Please let me know if the problem is still around with that patch applied.
It seems we still have another issue with SMP systems
On 02/15/2016 11:01 AM, Tony Lindgren wrote:
* Rafael J. Wysocki [160215 10:44]:
On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote:
Rafael,
Hi,
Thanks for the report!
I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
timers with utilization update callbacks' w
On Monday, February 15, 2016 08:12:33 PM Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 8:03 PM, Marc Zyngier wrote:
> > On 15/02/16 18:54, Rafael J. Wysocki wrote:
> >> On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier wrote:
> >>> On 15/02/16 18:41, Rafael J. Wysocki wrote:
> On Mon, Feb 1
On Mon, Feb 15, 2016 at 07:03:33PM +, Marc Zyngier wrote:
> On 15/02/16 18:54, Rafael J. Wysocki wrote:
> > That would explain it, thanks.
> >
> > So it looks like we should always use irq_work_queue() on UP even if
> > CONFIG_SMP is set, shouldn't we?
>
> Something like that, yes. CONFIG_SMP
On Mon, Feb 15, 2016 at 8:03 PM, Marc Zyngier wrote:
> On 15/02/16 18:54, Rafael J. Wysocki wrote:
>> On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier wrote:
>>> On 15/02/16 18:41, Rafael J. Wysocki wrote:
On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote:
> Rafael,
Hi,
>
On Mon, Feb 15, 2016 at 07:54:26PM +0100, Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier wrote:
> > Given that OMAP3 is a UP system, there is zero chance that it has
> > registered the magic hook that delivers IPIs (its interrupt controller
> > is not even capable of doin
On 15/02/16 18:54, Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier wrote:
>> On 15/02/16 18:41, Rafael J. Wysocki wrote:
>>> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote:
Rafael,
>>>
>>> Hi,
>>>
>>> Thanks for the report!
>>>
I see crashes in various arm
On Mon, Feb 15, 2016 at 07:41:21PM +0100, Rafael J. Wysocki wrote:
> Since this is ARM, arch_send_call_function_single_ipi() looks like this:
>
> void arch_send_call_function_single_ipi(int cpu)
> {
> smp_cross_call(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
> }
>
> so I'm not sure how the
* Rafael J. Wysocki [160215 10:44]:
> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote:
> > Rafael,
>
> Hi,
>
> Thanks for the report!
>
> > I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
> > timers with utilization update callbacks' with next-20160215. An examp
On Mon, Feb 15, 2016 at 7:49 PM, Marc Zyngier wrote:
> On 15/02/16 18:41, Rafael J. Wysocki wrote:
>> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote:
>>> Rafael,
>>
>> Hi,
>>
>> Thanks for the report!
>>
>>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
>>> time
On 15/02/16 18:41, Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote:
>> Rafael,
>
> Hi,
>
> Thanks for the report!
>
>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
>> timers with utilization update callbacks' with next-20160215. An e
On Mon, Feb 15, 2016 at 7:41 PM, Rafael J. Wysocki wrote:
> On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote:
>> Rafael,
>
> Hi,
>
> Thanks for the report!
>
>> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
>> timers with utilization update callbacks' with next-20
On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote:
> Rafael,
Hi,
Thanks for the report!
> I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
> timers with utilization update callbacks' with next-20160215. An example
> crash log and bisect results are attached below.
>
Rafael,
I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace
timers with utilization update callbacks' with next-20160215. An example
crash log and bisect results are attached below.
Please let me know if there is anything I can do to help tracking down
the problem.
Thanks,
28 matches
Mail list logo