On Tuesday, July 16, 2013 08:49:30 PM Srivatsa S. Bhat wrote:
> On 07/16/2013 04:14 PM, Sergey Senozhatsky wrote:
> > On (07/16/13 14:03), Srivatsa S. Bhat wrote:
> So here is the solution:
>
> On 3.11-rc1, apply these patches in the order mentioned below, and check
> whether
On 07/16/2013 04:14 PM, Sergey Senozhatsky wrote:
> On (07/16/13 14:03), Srivatsa S. Bhat wrote:
So here is the solution:
On 3.11-rc1, apply these patches in the order mentioned below, and check
whether it fixes _all_ problems (both the warnings about IPI as well as the
On (07/16/13 14:03), Srivatsa S. Bhat wrote:
> >> So here is the solution:
> >>
> >> On 3.11-rc1, apply these patches in the order mentioned below, and check
> >> whether it fixes _all_ problems (both the warnings about IPI as well as the
> >> lockdep splat).
> >>
> >> 1. Patch given in:
On 07/16/2013 04:50 AM, Sergey Senozhatsky wrote:
> On (07/15/13 18:49), Srivatsa S. Bhat wrote:
> [..]
>> So here is the solution:
>>
>> On 3.11-rc1, apply these patches in the order mentioned below, and check
>> whether it fixes _all_ problems (both the warnings about IPI as well as the
>>
Hi Peter,
On 07/16/2013 02:19 AM, Peter Wu wrote:
> Hi,
>
> I think I also encountered this similar issue after resume (and possibly a
> real deadlock yesterday before/during suspend?). One message:
>
> [ 71.204848] ==
> [ 71.204850] [
Hi Peter,
On 07/16/2013 02:19 AM, Peter Wu wrote:
Hi,
I think I also encountered this similar issue after resume (and possibly a
real deadlock yesterday before/during suspend?). One message:
[ 71.204848] ==
[ 71.204850] [ INFO:
On 07/16/2013 04:50 AM, Sergey Senozhatsky wrote:
On (07/15/13 18:49), Srivatsa S. Bhat wrote:
[..]
So here is the solution:
On 3.11-rc1, apply these patches in the order mentioned below, and check
whether it fixes _all_ problems (both the warnings about IPI as well as the
lockdep splat).
On (07/16/13 14:03), Srivatsa S. Bhat wrote:
So here is the solution:
On 3.11-rc1, apply these patches in the order mentioned below, and check
whether it fixes _all_ problems (both the warnings about IPI as well as the
lockdep splat).
1. Patch given in:
On 07/16/2013 04:14 PM, Sergey Senozhatsky wrote:
On (07/16/13 14:03), Srivatsa S. Bhat wrote:
So here is the solution:
On 3.11-rc1, apply these patches in the order mentioned below, and check
whether it fixes _all_ problems (both the warnings about IPI as well as the
lockdep splat).
1.
On Tuesday, July 16, 2013 08:49:30 PM Srivatsa S. Bhat wrote:
On 07/16/2013 04:14 PM, Sergey Senozhatsky wrote:
On (07/16/13 14:03), Srivatsa S. Bhat wrote:
So here is the solution:
On 3.11-rc1, apply these patches in the order mentioned below, and check
whether it fixes _all_ problems
On 07/15/2013 09:19 PM, Srivatsa S. Bhat wrote:
> On 07/15/2013 01:59 PM, Sergey Senozhatsky wrote:
>> On (07/15/13 15:52), Michael Wang wrote:
And may be we could try below patch to get more info, I've moved the timing
of restore stop flag from 'after STOP' to 'before START', I
On (07/15/13 18:49), Srivatsa S. Bhat wrote:
[..]
> So here is the solution:
>
> On 3.11-rc1, apply these patches in the order mentioned below, and check
> whether it fixes _all_ problems (both the warnings about IPI as well as the
> lockdep splat).
>
> 1. Patch given in:
Hi,
I think I also encountered this similar issue after resume (and possibly a
real deadlock yesterday before/during suspend?). One message:
[ 71.204848] ==
[ 71.204850] [ INFO: possible circular locking dependency detected ]
[ 71.204852]
On 07/15/2013 06:49 PM, Srivatsa S. Bhat wrote:
[...]
> The intent of this commit was to avoid warnings during CPU hotplug, which
> indicated that offline CPUs were getting IPIs from the cpufreq governor's
> work items. But the real root-cause of that problem was commit a66b2e5
> (cpufreq:
On 07/15/2013 01:59 PM, Sergey Senozhatsky wrote:
> On (07/15/13 15:52), Michael Wang wrote:
>>>
>>> And may be we could try below patch to get more info, I've moved the timing
>>> of restore stop flag from 'after STOP' to 'before START', I suppose that
>>> could create a window to prevent the
On (07/15/13 15:52), Michael Wang wrote:
> >
> > And may be we could try below patch to get more info, I've moved the timing
> > of restore stop flag from 'after STOP' to 'before START', I suppose that
> > could create a window to prevent the work re-queue, it could at least
> > provide
> > us
On 07/15/2013 11:50 AM, Michael Wang wrote:
> On 07/14/2013 08:06 PM, Sergey Senozhatsky wrote:
>> On (07/14/13 14:47), Sergey Senozhatsky wrote:
>>>
>>> Now, as I fixed radeon kms, I can see:
>>>
>>> [ 806.660530] [ cut here ]
>>> [ 806.660539] WARNING: CPU: 0 PID: 2389
On 07/15/2013 11:50 AM, Michael Wang wrote:
On 07/14/2013 08:06 PM, Sergey Senozhatsky wrote:
On (07/14/13 14:47), Sergey Senozhatsky wrote:
Now, as I fixed radeon kms, I can see:
[ 806.660530] [ cut here ]
[ 806.660539] WARNING: CPU: 0 PID: 2389 at
On (07/15/13 15:52), Michael Wang wrote:
And may be we could try below patch to get more info, I've moved the timing
of restore stop flag from 'after STOP' to 'before START', I suppose that
could create a window to prevent the work re-queue, it could at least
provide
us more info...
On 07/15/2013 01:59 PM, Sergey Senozhatsky wrote:
On (07/15/13 15:52), Michael Wang wrote:
And may be we could try below patch to get more info, I've moved the timing
of restore stop flag from 'after STOP' to 'before START', I suppose that
could create a window to prevent the work re-queue,
On 07/15/2013 06:49 PM, Srivatsa S. Bhat wrote:
[...]
The intent of this commit was to avoid warnings during CPU hotplug, which
indicated that offline CPUs were getting IPIs from the cpufreq governor's
work items. But the real root-cause of that problem was commit a66b2e5
(cpufreq: Preserve
Hi,
I think I also encountered this similar issue after resume (and possibly a
real deadlock yesterday before/during suspend?). One message:
[ 71.204848] ==
[ 71.204850] [ INFO: possible circular locking dependency detected ]
[ 71.204852]
On (07/15/13 18:49), Srivatsa S. Bhat wrote:
[..]
So here is the solution:
On 3.11-rc1, apply these patches in the order mentioned below, and check
whether it fixes _all_ problems (both the warnings about IPI as well as the
lockdep splat).
1. Patch given in:
On 07/15/2013 09:19 PM, Srivatsa S. Bhat wrote:
On 07/15/2013 01:59 PM, Sergey Senozhatsky wrote:
On (07/15/13 15:52), Michael Wang wrote:
And may be we could try below patch to get more info, I've moved the timing
of restore stop flag from 'after STOP' to 'before START', I suppose that
On 07/14/2013 08:06 PM, Sergey Senozhatsky wrote:
> On (07/14/13 14:47), Sergey Senozhatsky wrote:
>>
>> Now, as I fixed radeon kms, I can see:
>>
>> [ 806.660530] [ cut here ]
>> [ 806.660539] WARNING: CPU: 0 PID: 2389 at arch/x86/kernel/smp.c:124
>>
On 07/14/2013 11:56 PM, Rafael J. Wysocki wrote:
[snip]
>> +
>> +/*
>> + * Since there is no lock to prvent re-queue the
>> + * cancelled work, some early cancelled work might
>> + * have been queued again by later cancelled work.
>> + *
>> + * Flush the work again with
On 07/14/2013 07:47 PM, Sergey Senozhatsky wrote:
[snip]
>
> Hello,
>
> I just realized that lockdep was disabling itself at startup (after recent AMD
> radeon patch set) due to radeon kms error:
>
> [4.790019] [drm] Loading CEDAR Microcode
> [4.790943] r600_cp: Failed to load firmware
On Thursday, July 11, 2013 10:43:45 AM Michael Wang wrote:
> Hi, Sergey
>
> On 07/11/2013 07:13 AM, Sergey Senozhatsky wrote:
> [snip]
> >
> >
> > Please kindly review the following patch.
> >
> >
> >
> > Remove cpu device only upon succesful cpu down on CPU_POST_DEAD event,
> > so we can
On (07/14/13 14:47), Sergey Senozhatsky wrote:
>
> Now, as I fixed radeon kms, I can see:
>
> [ 806.660530] [ cut here ]
> [ 806.660539] WARNING: CPU: 0 PID: 2389 at arch/x86/kernel/smp.c:124
> native_smp_send_reschedule+0x57/0x60()
Well, this one is obviously not a
On (07/11/13 10:43), Michael Wang wrote:
> [..]
> Nice to know you have some idea on solving the issue ;-)
>
> I'm not sure whether I catch the idea, but seems like you are trying
> to re-organize the timing of add/remove device.
>
> I'm sure that we have more than one way to solve the issues,
On (07/11/13 10:43), Michael Wang wrote:
[..]
Nice to know you have some idea on solving the issue ;-)
I'm not sure whether I catch the idea, but seems like you are trying
to re-organize the timing of add/remove device.
I'm sure that we have more than one way to solve the issues, but what
On (07/14/13 14:47), Sergey Senozhatsky wrote:
Now, as I fixed radeon kms, I can see:
[ 806.660530] [ cut here ]
[ 806.660539] WARNING: CPU: 0 PID: 2389 at arch/x86/kernel/smp.c:124
native_smp_send_reschedule+0x57/0x60()
Well, this one is obviously not a lockdep
On Thursday, July 11, 2013 10:43:45 AM Michael Wang wrote:
Hi, Sergey
On 07/11/2013 07:13 AM, Sergey Senozhatsky wrote:
[snip]
Please kindly review the following patch.
Remove cpu device only upon succesful cpu down on CPU_POST_DEAD event,
so we can kill off
On 07/14/2013 07:47 PM, Sergey Senozhatsky wrote:
[snip]
Hello,
I just realized that lockdep was disabling itself at startup (after recent AMD
radeon patch set) due to radeon kms error:
[4.790019] [drm] Loading CEDAR Microcode
[4.790943] r600_cp: Failed to load firmware
On 07/14/2013 11:56 PM, Rafael J. Wysocki wrote:
[snip]
+
+/*
+ * Since there is no lock to prvent re-queue the
+ * cancelled work, some early cancelled work might
+ * have been queued again by later cancelled work.
+ *
+ * Flush the work again with
On 07/14/2013 08:06 PM, Sergey Senozhatsky wrote:
On (07/14/13 14:47), Sergey Senozhatsky wrote:
Now, as I fixed radeon kms, I can see:
[ 806.660530] [ cut here ]
[ 806.660539] WARNING: CPU: 0 PID: 2389 at arch/x86/kernel/smp.c:124
On 07/11/2013 07:47 PM, Bartlomiej Zolnierkiewicz wrote:
[snip]
>
> Michael's patch also works for me. Thanks to everyone involved!
> (My only nitpick for the patch is that ->queue_stop can be made bool.)
>
> Reported-and-Tested-by: Bartlomiej Zolnierkiewicz
>
> I think that it would also be
Hi,
On Thursday, July 11, 2013 04:48:51 PM Michael Wang wrote:
> On 07/11/2013 04:47 PM, Michael Wang wrote:
> > On 07/11/2013 04:22 PM, Sergey Senozhatsky wrote:
> > [snip]
> >>>
> >>
> >> Hello Michael,
> >> nice job! works fine for me.
> >>
> >> Reported-and-Tested-by: Sergey Senozhatsky
> >
On (07/11/13 16:47), Michael Wang wrote:
> On 07/11/2013 04:22 PM, Sergey Senozhatsky wrote:
> [snip]
> >>
> >
> > Hello Michael,
> > nice job! works fine for me.
> >
> > Reported-and-Tested-by: Sergey Senozhatsky
>
> Thanks for the test :)
>
> Borislav may also doing some testing, let's wait
On 07/11/2013 04:47 PM, Michael Wang wrote:
> On 07/11/2013 04:22 PM, Sergey Senozhatsky wrote:
> [snip]
>>>
>>
>> Hello Michael,
>> nice job! works fine for me.
>>
>> Reported-and-Tested-by: Sergey Senozhatsky
>
> Thanks for the test :)
>
> Borislav may also doing some testing, let's wait for
On 07/11/2013 04:22 PM, Sergey Senozhatsky wrote:
[snip]
>>
>
> Hello Michael,
> nice job! works fine for me.
>
> Reported-and-Tested-by: Sergey Senozhatsky
Thanks for the test :)
Borislav may also doing some testing, let's wait for few days and see
whether there are any point we missed.
And
On (07/11/13 10:43), Michael Wang wrote:
> Hi, Sergey
>
> On 07/11/2013 07:13 AM, Sergey Senozhatsky wrote:
> [snip]
> >
> >
> > Please kindly review the following patch.
> >
> >
> >
> > Remove cpu device only upon succesful cpu down on CPU_POST_DEAD event,
> > so we can kill off
On (07/11/13 10:43), Michael Wang wrote:
Hi, Sergey
On 07/11/2013 07:13 AM, Sergey Senozhatsky wrote:
[snip]
Please kindly review the following patch.
Remove cpu device only upon succesful cpu down on CPU_POST_DEAD event,
so we can kill off CPU_DOWN_FAILED case and
On 07/11/2013 04:22 PM, Sergey Senozhatsky wrote:
[snip]
Hello Michael,
nice job! works fine for me.
Reported-and-Tested-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
Thanks for the test :)
Borislav may also doing some testing, let's wait for few days and see
whether there are any
On 07/11/2013 04:47 PM, Michael Wang wrote:
On 07/11/2013 04:22 PM, Sergey Senozhatsky wrote:
[snip]
Hello Michael,
nice job! works fine for me.
Reported-and-Tested-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
Thanks for the test :)
Borislav may also doing some testing, let's
On (07/11/13 16:47), Michael Wang wrote:
On 07/11/2013 04:22 PM, Sergey Senozhatsky wrote:
[snip]
Hello Michael,
nice job! works fine for me.
Reported-and-Tested-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
Thanks for the test :)
Borislav may also doing some testing,
Hi,
On Thursday, July 11, 2013 04:48:51 PM Michael Wang wrote:
On 07/11/2013 04:47 PM, Michael Wang wrote:
On 07/11/2013 04:22 PM, Sergey Senozhatsky wrote:
[snip]
Hello Michael,
nice job! works fine for me.
Reported-and-Tested-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
On 07/11/2013 07:47 PM, Bartlomiej Zolnierkiewicz wrote:
[snip]
Michael's patch also works for me. Thanks to everyone involved!
(My only nitpick for the patch is that -queue_stop can be made bool.)
Reported-and-Tested-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
I think that it
Hi, Sergey
On 07/11/2013 07:13 AM, Sergey Senozhatsky wrote:
[snip]
>
>
> Please kindly review the following patch.
>
>
>
> Remove cpu device only upon succesful cpu down on CPU_POST_DEAD event,
> so we can kill off CPU_DOWN_FAILED case and eliminate potential extra
> remove/add path:
>
On (07/01/13 12:42), Michael Wang wrote:
> On 06/26/2013 05:15 AM, Sergey Senozhatsky wrote:
> [snip]
> >
> > [ 60.277848] Chain exists of:
> > (&(_cdbs->work)->work) --> _cdbs->timer_mutex --> cpu_hotplug.lock
> >
> > [ 60.277864] Possible unsafe locking scenario:
> >
> > [ 60.277869]
On (07/01/13 12:42), Michael Wang wrote:
On 06/26/2013 05:15 AM, Sergey Senozhatsky wrote:
[snip]
[ 60.277848] Chain exists of:
((j_cdbs-work)-work) -- j_cdbs-timer_mutex -- cpu_hotplug.lock
[ 60.277864] Possible unsafe locking scenario:
[ 60.277869]CPU0
Hi, Sergey
On 07/11/2013 07:13 AM, Sergey Senozhatsky wrote:
[snip]
Please kindly review the following patch.
Remove cpu device only upon succesful cpu down on CPU_POST_DEAD event,
so we can kill off CPU_DOWN_FAILED case and eliminate potential extra
remove/add path:
Hi, Sergey
On 06/26/2013 05:15 AM, Sergey Senozhatsky wrote:
[snip]
>
> [ 60.277848] Chain exists of:
> (&(_cdbs->work)->work) --> _cdbs->timer_mutex --> cpu_hotplug.lock
>
> [ 60.277864] Possible unsafe locking scenario:
>
> [ 60.277869]CPU0CPU1
> [
Hi, Sergey
On 06/26/2013 05:15 AM, Sergey Senozhatsky wrote:
[snip]
[ 60.277848] Chain exists of:
((j_cdbs-work)-work) -- j_cdbs-timer_mutex -- cpu_hotplug.lock
[ 60.277864] Possible unsafe locking scenario:
[ 60.277869]CPU0CPU1
[ 60.277873]
On (06/28/13 19:43), Srivatsa S. Bhat wrote:
> On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
> > Hello,
> > Yes, this helps, of course, but at the same time it returns the previous
> > problem -- preventing cpu_hotplug in some places.
> >
> >
> > I have a bit different (perhaps naive) RFC
On (06/28/13 19:43), Srivatsa S. Bhat wrote:
On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
Hello,
Yes, this helps, of course, but at the same time it returns the previous
problem -- preventing cpu_hotplug in some places.
I have a bit different (perhaps naive) RFC patch and would
On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
> Hello,
> Yes, this helps, of course, but at the same time it returns the previous
> problem -- preventing cpu_hotplug in some places.
>
>
> I have a bit different (perhaps naive) RFC patch and would like to hear
> comments.
>
>
>
> The idead
On (06/28/13 15:01), Srivatsa S. Bhat wrote:
> On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
> > On (06/28/13 10:13), Viresh Kumar wrote:
> >> On 26 June 2013 02:45, Sergey Senozhatsky
> >> wrote:
> >>>
> >>> [ 60.277396] ==
> >>> [
On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
> On (06/28/13 10:13), Viresh Kumar wrote:
>> On 26 June 2013 02:45, Sergey Senozhatsky
>> wrote:
>>>
>>> [ 60.277396] ==
>>> [ 60.277400] [ INFO: possible circular locking dependency
On (06/28/13 10:13), Viresh Kumar wrote:
> On 26 June 2013 02:45, Sergey Senozhatsky
> wrote:
> >
> > [ 60.277396] ==
> > [ 60.277400] [ INFO: possible circular locking dependency detected ]
> > [ 60.277407]
On (06/28/13 10:13), Viresh Kumar wrote:
On 26 June 2013 02:45, Sergey Senozhatsky sergey.senozhat...@gmail.com
wrote:
[ 60.277396] ==
[ 60.277400] [ INFO: possible circular locking dependency detected ]
[ 60.277407]
On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
On (06/28/13 10:13), Viresh Kumar wrote:
On 26 June 2013 02:45, Sergey Senozhatsky sergey.senozhat...@gmail.com
wrote:
[ 60.277396] ==
[ 60.277400] [ INFO: possible circular locking
On (06/28/13 15:01), Srivatsa S. Bhat wrote:
On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
On (06/28/13 10:13), Viresh Kumar wrote:
On 26 June 2013 02:45, Sergey Senozhatsky sergey.senozhat...@gmail.com
wrote:
[ 60.277396] ==
On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
Hello,
Yes, this helps, of course, but at the same time it returns the previous
problem -- preventing cpu_hotplug in some places.
I have a bit different (perhaps naive) RFC patch and would like to hear
comments.
The idead is to
On 26 June 2013 02:45, Sergey Senozhatsky wrote:
>
> [ 60.277396] ==
> [ 60.277400] [ INFO: possible circular locking dependency detected ]
> [ 60.277407] 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 Not tainted
> [ 60.277411]
On 26 June 2013 02:45, Sergey Senozhatsky sergey.senozhat...@gmail.com wrote:
[ 60.277396] ==
[ 60.277400] [ INFO: possible circular locking dependency detected ]
[ 60.277407] 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 Not tainted
[
[ 60.277396] ==
[ 60.277400] [ INFO: possible circular locking dependency detected ]
[ 60.277407] 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 Not tainted
[ 60.277411] ---
[ 60.277417]
[ 60.277396] ==
[ 60.277400] [ INFO: possible circular locking dependency detected ]
[ 60.277407] 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 Not tainted
[ 60.277411] ---
[ 60.277417]
68 matches
Mail list logo
