Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-30 Thread Sedat Dilek
On Thu, Dec 29, 2016 at 12:58 PM, Mika Kuoppala
 wrote:
> Sedat Dilek  writes:
>
>> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki  
>> wrote:
>>> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
 On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
> On Wed, 28 Dec 2016, Sedat Dilek  wrote:
>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
>>> Hi!
>>>
 [ Add some pm | i915 | x86 folks ]

 Hi,

 I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
 and I see some call-traces.
 It is reproducible on suspend and resume.

 I cannot say which area touches the problem or if these are several
 independent problems.

 For a full dmesg-log see attachments (my linux-config is attached, 
 too).

 Here some hunks...

 [   29.003601] BUG: sleeping function called from invalid context at
 drivers/base/power/runtime.c:1032
 [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: 
 Xorg
 [   29.003610] 1 lock held by Xorg/1469:
 [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
 [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
 [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
 4.10.0-rc1-1-iniza-small #1
 [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
 [   29.003656] Call Trace:
>>>
>>> Just a note, at least 2 machines here refuse to resume with
>>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>>> common cause...
>>>
>>
>> [ Correct linux-pm ML and add Mika & Jani ]
>>
>> Thanks for the feedback.
>>
>> There are some cpu/hotplug fixes post-v4.10-rc1.
>> Give that a try.
>>
>> Yesterday, after answers from drm-intel folks I have seen that a
>> cpu/hotplug commit [1] was reverted in
>> drm-intel.git#drm-intel-nightly.
>> I haven't tried that.
>>
>> It's good when Thomas knows of this and gets in contact with drm-intel 
>> folks.
>>
>> Regards,
>> - Sedat -
>>
>> [1] 
>> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
>> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>>
>> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>>
>> This reverts commit dc280d93623927570da279e99393879dbbab39e7
>> Author: Thomas Gleixner 
>> Date: Wed Dec 21 20:19:49 2016 +0100
>> cpu/hotplug: Prevent overwriting of callbacks
>>
>> It started hanging all machines in CI s3 test:
>> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>>
>> Bisected-by: Mika Kuoppala 
>> Signed-off-by: Jani Nikula 
>
> Thomas -
>
> Indeed, basically all of the boxes in the intel-gfx CI hang at the
> suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
> of callbacks"), and after the revert in the tree that feeds to the CI,
> we're back on track.
>
> I found [1], was hoping to get feedback from Mika whether that helps
> before reporting. Chris also suggested [2] as a quick fix but I don't
> know if anyone tried that.
>

 Hi Jani,

 I know you were not CCed in the original thread, please see [5].

 The patchset from Thomas you mention [1] does fix one of the problems
 I have seen, please see [6].
 With these post-v4.10-rc1 patches applied a clean revert of Revert
 "cpu/hotplug: Prevent overwriting of callbacks" is not possible.

 Can you give a clear statement if the quick-fix from Chris is in
 combination with the above revert or not?
 Against v4.10-rc1?
 Tested together with the patchset of Thomas?
>>>
>>> Please test the Linus' tree from today, it should work.
>>>
>>
>> Latest Linus tree (v4.10-rc1-17-g2d706e790f05) does not fix it.
>>
>
> Latest Linus tree 2d706e790f0508dff4fb72eca9b4892b79757feb fixes our S3
> problems. It survives gem_exec_suspend --r basic-S3 on kabylake.
>
> It contains the fix to the bisected commit:
>
> commit b9d9d6911bd5c370ad4b3aa57d758c093d17aed5
> Author: Thomas Gleixner 
> Date:   Mon Dec 26 22:58:19 2016 +0100
>
> smp/hotplug: Undo tglxs brainfart
>
>

These are good news!

I still see another issue and this seems independent of Thomas'
"brainfart" patch.

Will post a separate email on the other issue.

- Sedat -


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-30 Thread Sedat Dilek
On Thu, Dec 29, 2016 at 12:58 PM, Mika Kuoppala
 wrote:
> Sedat Dilek  writes:
>
>> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki  
>> wrote:
>>> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
 On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
> On Wed, 28 Dec 2016, Sedat Dilek  wrote:
>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
>>> Hi!
>>>
 [ Add some pm | i915 | x86 folks ]

 Hi,

 I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
 and I see some call-traces.
 It is reproducible on suspend and resume.

 I cannot say which area touches the problem or if these are several
 independent problems.

 For a full dmesg-log see attachments (my linux-config is attached, 
 too).

 Here some hunks...

 [   29.003601] BUG: sleeping function called from invalid context at
 drivers/base/power/runtime.c:1032
 [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: 
 Xorg
 [   29.003610] 1 lock held by Xorg/1469:
 [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
 [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
 [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
 4.10.0-rc1-1-iniza-small #1
 [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
 [   29.003656] Call Trace:
>>>
>>> Just a note, at least 2 machines here refuse to resume with
>>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>>> common cause...
>>>
>>
>> [ Correct linux-pm ML and add Mika & Jani ]
>>
>> Thanks for the feedback.
>>
>> There are some cpu/hotplug fixes post-v4.10-rc1.
>> Give that a try.
>>
>> Yesterday, after answers from drm-intel folks I have seen that a
>> cpu/hotplug commit [1] was reverted in
>> drm-intel.git#drm-intel-nightly.
>> I haven't tried that.
>>
>> It's good when Thomas knows of this and gets in contact with drm-intel 
>> folks.
>>
>> Regards,
>> - Sedat -
>>
>> [1] 
>> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
>> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>>
>> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>>
>> This reverts commit dc280d93623927570da279e99393879dbbab39e7
>> Author: Thomas Gleixner 
>> Date: Wed Dec 21 20:19:49 2016 +0100
>> cpu/hotplug: Prevent overwriting of callbacks
>>
>> It started hanging all machines in CI s3 test:
>> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>>
>> Bisected-by: Mika Kuoppala 
>> Signed-off-by: Jani Nikula 
>
> Thomas -
>
> Indeed, basically all of the boxes in the intel-gfx CI hang at the
> suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
> of callbacks"), and after the revert in the tree that feeds to the CI,
> we're back on track.
>
> I found [1], was hoping to get feedback from Mika whether that helps
> before reporting. Chris also suggested [2] as a quick fix but I don't
> know if anyone tried that.
>

 Hi Jani,

 I know you were not CCed in the original thread, please see [5].

 The patchset from Thomas you mention [1] does fix one of the problems
 I have seen, please see [6].
 With these post-v4.10-rc1 patches applied a clean revert of Revert
 "cpu/hotplug: Prevent overwriting of callbacks" is not possible.

 Can you give a clear statement if the quick-fix from Chris is in
 combination with the above revert or not?
 Against v4.10-rc1?
 Tested together with the patchset of Thomas?
>>>
>>> Please test the Linus' tree from today, it should work.
>>>
>>
>> Latest Linus tree (v4.10-rc1-17-g2d706e790f05) does not fix it.
>>
>
> Latest Linus tree 2d706e790f0508dff4fb72eca9b4892b79757feb fixes our S3
> problems. It survives gem_exec_suspend --r basic-S3 on kabylake.
>
> It contains the fix to the bisected commit:
>
> commit b9d9d6911bd5c370ad4b3aa57d758c093d17aed5
> Author: Thomas Gleixner 
> Date:   Mon Dec 26 22:58:19 2016 +0100
>
> smp/hotplug: Undo tglxs brainfart
>
>

These are good news!

I still see another issue and this seems independent of Thomas'
"brainfart" patch.

Will post a separate email on the other issue.

- Sedat -


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-29 Thread Mika Kuoppala
Sedat Dilek  writes:

> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki  wrote:
>> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
>>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
 On Wed, 28 Dec 2016, Sedat Dilek  wrote:
> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
>> Hi!
>>
>>> [ Add some pm | i915 | x86 folks ]
>>>
>>> Hi,
>>>
>>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>> and I see some call-traces.
>>> It is reproducible on suspend and resume.
>>>
>>> I cannot say which area touches the problem or if these are several
>>> independent problems.
>>>
>>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>>
>>> Here some hunks...
>>>
>>> [   29.003601] BUG: sleeping function called from invalid context at
>>> drivers/base/power/runtime.c:1032
>>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>> [   29.003610] 1 lock held by Xorg/1469:
>>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>> 4.10.0-rc1-1-iniza-small #1
>>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> [   29.003656] Call Trace:
>>
>> Just a note, at least 2 machines here refuse to resume with
>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>> common cause...
>>
>
> [ Correct linux-pm ML and add Mika & Jani ]
>
> Thanks for the feedback.
>
> There are some cpu/hotplug fixes post-v4.10-rc1.
> Give that a try.
>
> Yesterday, after answers from drm-intel folks I have seen that a
> cpu/hotplug commit [1] was reverted in
> drm-intel.git#drm-intel-nightly.
> I haven't tried that.
>
> It's good when Thomas knows of this and gets in contact with drm-intel 
> folks.
>
> Regards,
> - Sedat -
>
> [1] 
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>
> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>
> This reverts commit dc280d93623927570da279e99393879dbbab39e7
> Author: Thomas Gleixner 
> Date: Wed Dec 21 20:19:49 2016 +0100
> cpu/hotplug: Prevent overwriting of callbacks
>
> It started hanging all machines in CI s3 test:
> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>
> Bisected-by: Mika Kuoppala 
> Signed-off-by: Jani Nikula 

 Thomas -

 Indeed, basically all of the boxes in the intel-gfx CI hang at the
 suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
 of callbacks"), and after the revert in the tree that feeds to the CI,
 we're back on track.

 I found [1], was hoping to get feedback from Mika whether that helps
 before reporting. Chris also suggested [2] as a quick fix but I don't
 know if anyone tried that.

>>>
>>> Hi Jani,
>>>
>>> I know you were not CCed in the original thread, please see [5].
>>>
>>> The patchset from Thomas you mention [1] does fix one of the problems
>>> I have seen, please see [6].
>>> With these post-v4.10-rc1 patches applied a clean revert of Revert
>>> "cpu/hotplug: Prevent overwriting of callbacks" is not possible.
>>>
>>> Can you give a clear statement if the quick-fix from Chris is in
>>> combination with the above revert or not?
>>> Against v4.10-rc1?
>>> Tested together with the patchset of Thomas?
>>
>> Please test the Linus' tree from today, it should work.
>>
>
> Latest Linus tree (v4.10-rc1-17-g2d706e790f05) does not fix it.
>

Latest Linus tree 2d706e790f0508dff4fb72eca9b4892b79757feb fixes our S3
problems. It survives gem_exec_suspend --r basic-S3 on kabylake.

It contains the fix to the bisected commit:

commit b9d9d6911bd5c370ad4b3aa57d758c093d17aed5
Author: Thomas Gleixner 
Date:   Mon Dec 26 22:58:19 2016 +0100

smp/hotplug: Undo tglxs brainfart


-Mika


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-29 Thread Mika Kuoppala
Sedat Dilek  writes:

> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki  wrote:
>> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
>>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
 On Wed, 28 Dec 2016, Sedat Dilek  wrote:
> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
>> Hi!
>>
>>> [ Add some pm | i915 | x86 folks ]
>>>
>>> Hi,
>>>
>>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>> and I see some call-traces.
>>> It is reproducible on suspend and resume.
>>>
>>> I cannot say which area touches the problem or if these are several
>>> independent problems.
>>>
>>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>>
>>> Here some hunks...
>>>
>>> [   29.003601] BUG: sleeping function called from invalid context at
>>> drivers/base/power/runtime.c:1032
>>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>> [   29.003610] 1 lock held by Xorg/1469:
>>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>> 4.10.0-rc1-1-iniza-small #1
>>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> [   29.003656] Call Trace:
>>
>> Just a note, at least 2 machines here refuse to resume with
>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>> common cause...
>>
>
> [ Correct linux-pm ML and add Mika & Jani ]
>
> Thanks for the feedback.
>
> There are some cpu/hotplug fixes post-v4.10-rc1.
> Give that a try.
>
> Yesterday, after answers from drm-intel folks I have seen that a
> cpu/hotplug commit [1] was reverted in
> drm-intel.git#drm-intel-nightly.
> I haven't tried that.
>
> It's good when Thomas knows of this and gets in contact with drm-intel 
> folks.
>
> Regards,
> - Sedat -
>
> [1] 
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>
> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>
> This reverts commit dc280d93623927570da279e99393879dbbab39e7
> Author: Thomas Gleixner 
> Date: Wed Dec 21 20:19:49 2016 +0100
> cpu/hotplug: Prevent overwriting of callbacks
>
> It started hanging all machines in CI s3 test:
> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>
> Bisected-by: Mika Kuoppala 
> Signed-off-by: Jani Nikula 

 Thomas -

 Indeed, basically all of the boxes in the intel-gfx CI hang at the
 suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
 of callbacks"), and after the revert in the tree that feeds to the CI,
 we're back on track.

 I found [1], was hoping to get feedback from Mika whether that helps
 before reporting. Chris also suggested [2] as a quick fix but I don't
 know if anyone tried that.

>>>
>>> Hi Jani,
>>>
>>> I know you were not CCed in the original thread, please see [5].
>>>
>>> The patchset from Thomas you mention [1] does fix one of the problems
>>> I have seen, please see [6].
>>> With these post-v4.10-rc1 patches applied a clean revert of Revert
>>> "cpu/hotplug: Prevent overwriting of callbacks" is not possible.
>>>
>>> Can you give a clear statement if the quick-fix from Chris is in
>>> combination with the above revert or not?
>>> Against v4.10-rc1?
>>> Tested together with the patchset of Thomas?
>>
>> Please test the Linus' tree from today, it should work.
>>
>
> Latest Linus tree (v4.10-rc1-17-g2d706e790f05) does not fix it.
>

Latest Linus tree 2d706e790f0508dff4fb72eca9b4892b79757feb fixes our S3
problems. It survives gem_exec_suspend --r basic-S3 on kabylake.

It contains the fix to the bisected commit:

commit b9d9d6911bd5c370ad4b3aa57d758c093d17aed5
Author: Thomas Gleixner 
Date:   Mon Dec 26 22:58:19 2016 +0100

smp/hotplug: Undo tglxs brainfart


-Mika


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-29 Thread Jani Nikula
On Thu, 29 Dec 2016, Sedat Dilek  wrote:
> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki  wrote:
>> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
>>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
 On Wed, 28 Dec 2016, Sedat Dilek  wrote:
> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
>> Hi!
>>
>>> [ Add some pm | i915 | x86 folks ]
>>>
>>> Hi,
>>>
>>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>> and I see some call-traces.
>>> It is reproducible on suspend and resume.
>>>
>>> I cannot say which area touches the problem or if these are several
>>> independent problems.
>>>
>>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>>
>>> Here some hunks...
>>>
>>> [   29.003601] BUG: sleeping function called from invalid context at
>>> drivers/base/power/runtime.c:1032
>>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>> [   29.003610] 1 lock held by Xorg/1469:
>>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>> 4.10.0-rc1-1-iniza-small #1
>>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> [   29.003656] Call Trace:
>>
>> Just a note, at least 2 machines here refuse to resume with
>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>> common cause...
>>
>
> [ Correct linux-pm ML and add Mika & Jani ]
>
> Thanks for the feedback.
>
> There are some cpu/hotplug fixes post-v4.10-rc1.
> Give that a try.
>
> Yesterday, after answers from drm-intel folks I have seen that a
> cpu/hotplug commit [1] was reverted in
> drm-intel.git#drm-intel-nightly.
> I haven't tried that.
>
> It's good when Thomas knows of this and gets in contact with drm-intel 
> folks.
>
> Regards,
> - Sedat -
>
> [1] 
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>
> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>
> This reverts commit dc280d93623927570da279e99393879dbbab39e7
> Author: Thomas Gleixner 
> Date: Wed Dec 21 20:19:49 2016 +0100
> cpu/hotplug: Prevent overwriting of callbacks
>
> It started hanging all machines in CI s3 test:
> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>
> Bisected-by: Mika Kuoppala 
> Signed-off-by: Jani Nikula 

 Thomas -

 Indeed, basically all of the boxes in the intel-gfx CI hang at the
 suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
 of callbacks"), and after the revert in the tree that feeds to the CI,
 we're back on track.

 I found [1], was hoping to get feedback from Mika whether that helps
 before reporting. Chris also suggested [2] as a quick fix but I don't
 know if anyone tried that.

>>>
>>> Hi Jani,
>>>
>>> I know you were not CCed in the original thread, please see [5].
>>>
>>> The patchset from Thomas you mention [1] does fix one of the problems
>>> I have seen, please see [6].
>>> With these post-v4.10-rc1 patches applied a clean revert of Revert
>>> "cpu/hotplug: Prevent overwriting of callbacks" is not possible.
>>>
>>> Can you give a clear statement if the quick-fix from Chris is in
>>> combination with the above revert or not?
>>> Against v4.10-rc1?
>>> Tested together with the patchset of Thomas?
>>
>> Please test the Linus' tree from today, it should work.
>>
>
> Latest Linus tree (v4.10-rc1-17-g2d706e790f05) does not fix it.

It seems to me there are more than one bug at play here.

BR,
Jani.


>
> - Sedat -

-- 
Jani Nikula, Intel Open Source Technology Center


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-29 Thread Jani Nikula
On Thu, 29 Dec 2016, Sedat Dilek  wrote:
> On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki  wrote:
>> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
>>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
 On Wed, 28 Dec 2016, Sedat Dilek  wrote:
> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
>> Hi!
>>
>>> [ Add some pm | i915 | x86 folks ]
>>>
>>> Hi,
>>>
>>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>> and I see some call-traces.
>>> It is reproducible on suspend and resume.
>>>
>>> I cannot say which area touches the problem or if these are several
>>> independent problems.
>>>
>>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>>
>>> Here some hunks...
>>>
>>> [   29.003601] BUG: sleeping function called from invalid context at
>>> drivers/base/power/runtime.c:1032
>>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>> [   29.003610] 1 lock held by Xorg/1469:
>>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>> 4.10.0-rc1-1-iniza-small #1
>>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> [   29.003656] Call Trace:
>>
>> Just a note, at least 2 machines here refuse to resume with
>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>> common cause...
>>
>
> [ Correct linux-pm ML and add Mika & Jani ]
>
> Thanks for the feedback.
>
> There are some cpu/hotplug fixes post-v4.10-rc1.
> Give that a try.
>
> Yesterday, after answers from drm-intel folks I have seen that a
> cpu/hotplug commit [1] was reverted in
> drm-intel.git#drm-intel-nightly.
> I haven't tried that.
>
> It's good when Thomas knows of this and gets in contact with drm-intel 
> folks.
>
> Regards,
> - Sedat -
>
> [1] 
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>
> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>
> This reverts commit dc280d93623927570da279e99393879dbbab39e7
> Author: Thomas Gleixner 
> Date: Wed Dec 21 20:19:49 2016 +0100
> cpu/hotplug: Prevent overwriting of callbacks
>
> It started hanging all machines in CI s3 test:
> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>
> Bisected-by: Mika Kuoppala 
> Signed-off-by: Jani Nikula 

 Thomas -

 Indeed, basically all of the boxes in the intel-gfx CI hang at the
 suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
 of callbacks"), and after the revert in the tree that feeds to the CI,
 we're back on track.

 I found [1], was hoping to get feedback from Mika whether that helps
 before reporting. Chris also suggested [2] as a quick fix but I don't
 know if anyone tried that.

>>>
>>> Hi Jani,
>>>
>>> I know you were not CCed in the original thread, please see [5].
>>>
>>> The patchset from Thomas you mention [1] does fix one of the problems
>>> I have seen, please see [6].
>>> With these post-v4.10-rc1 patches applied a clean revert of Revert
>>> "cpu/hotplug: Prevent overwriting of callbacks" is not possible.
>>>
>>> Can you give a clear statement if the quick-fix from Chris is in
>>> combination with the above revert or not?
>>> Against v4.10-rc1?
>>> Tested together with the patchset of Thomas?
>>
>> Please test the Linus' tree from today, it should work.
>>
>
> Latest Linus tree (v4.10-rc1-17-g2d706e790f05) does not fix it.

It seems to me there are more than one bug at play here.

BR,
Jani.


>
> - Sedat -

-- 
Jani Nikula, Intel Open Source Technology Center


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Sedat Dilek
On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki  wrote:
> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
>>> On Wed, 28 Dec 2016, Sedat Dilek  wrote:
 On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
> Hi!
>
>> [ Add some pm | i915 | x86 folks ]
>>
>> Hi,
>>
>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>> and I see some call-traces.
>> It is reproducible on suspend and resume.
>>
>> I cannot say which area touches the problem or if these are several
>> independent problems.
>>
>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>
>> Here some hunks...
>>
>> [   29.003601] BUG: sleeping function called from invalid context at
>> drivers/base/power/runtime.c:1032
>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>> [   29.003610] 1 lock held by Xorg/1469:
>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>> 4.10.0-rc1-1-iniza-small #1
>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> [   29.003656] Call Trace:
>
> Just a note, at least 2 machines here refuse to resume with
> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
> common cause...
>

 [ Correct linux-pm ML and add Mika & Jani ]

 Thanks for the feedback.

 There are some cpu/hotplug fixes post-v4.10-rc1.
 Give that a try.

 Yesterday, after answers from drm-intel folks I have seen that a
 cpu/hotplug commit [1] was reverted in
 drm-intel.git#drm-intel-nightly.
 I haven't tried that.

 It's good when Thomas knows of this and gets in contact with drm-intel 
 folks.

 Regards,
 - Sedat -

 [1] 
 https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
 [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly

 P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"

 This reverts commit dc280d93623927570da279e99393879dbbab39e7
 Author: Thomas Gleixner 
 Date: Wed Dec 21 20:19:49 2016 +0100
 cpu/hotplug: Prevent overwriting of callbacks

 It started hanging all machines in CI s3 test:
 https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html

 Bisected-by: Mika Kuoppala 
 Signed-off-by: Jani Nikula 
>>>
>>> Thomas -
>>>
>>> Indeed, basically all of the boxes in the intel-gfx CI hang at the
>>> suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
>>> of callbacks"), and after the revert in the tree that feeds to the CI,
>>> we're back on track.
>>>
>>> I found [1], was hoping to get feedback from Mika whether that helps
>>> before reporting. Chris also suggested [2] as a quick fix but I don't
>>> know if anyone tried that.
>>>
>>
>> Hi Jani,
>>
>> I know you were not CCed in the original thread, please see [5].
>>
>> The patchset from Thomas you mention [1] does fix one of the problems
>> I have seen, please see [6].
>> With these post-v4.10-rc1 patches applied a clean revert of Revert
>> "cpu/hotplug: Prevent overwriting of callbacks" is not possible.
>>
>> Can you give a clear statement if the quick-fix from Chris is in
>> combination with the above revert or not?
>> Against v4.10-rc1?
>> Tested together with the patchset of Thomas?
>
> Please test the Linus' tree from today, it should work.
>

Latest Linus tree (v4.10-rc1-17-g2d706e790f05) does not fix it.

- Sedat -


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Sedat Dilek
On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysocki  wrote:
> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
>>> On Wed, 28 Dec 2016, Sedat Dilek  wrote:
 On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
> Hi!
>
>> [ Add some pm | i915 | x86 folks ]
>>
>> Hi,
>>
>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>> and I see some call-traces.
>> It is reproducible on suspend and resume.
>>
>> I cannot say which area touches the problem or if these are several
>> independent problems.
>>
>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>
>> Here some hunks...
>>
>> [   29.003601] BUG: sleeping function called from invalid context at
>> drivers/base/power/runtime.c:1032
>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>> [   29.003610] 1 lock held by Xorg/1469:
>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>> 4.10.0-rc1-1-iniza-small #1
>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> [   29.003656] Call Trace:
>
> Just a note, at least 2 machines here refuse to resume with
> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
> common cause...
>

 [ Correct linux-pm ML and add Mika & Jani ]

 Thanks for the feedback.

 There are some cpu/hotplug fixes post-v4.10-rc1.
 Give that a try.

 Yesterday, after answers from drm-intel folks I have seen that a
 cpu/hotplug commit [1] was reverted in
 drm-intel.git#drm-intel-nightly.
 I haven't tried that.

 It's good when Thomas knows of this and gets in contact with drm-intel 
 folks.

 Regards,
 - Sedat -

 [1] 
 https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
 [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly

 P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"

 This reverts commit dc280d93623927570da279e99393879dbbab39e7
 Author: Thomas Gleixner 
 Date: Wed Dec 21 20:19:49 2016 +0100
 cpu/hotplug: Prevent overwriting of callbacks

 It started hanging all machines in CI s3 test:
 https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html

 Bisected-by: Mika Kuoppala 
 Signed-off-by: Jani Nikula 
>>>
>>> Thomas -
>>>
>>> Indeed, basically all of the boxes in the intel-gfx CI hang at the
>>> suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
>>> of callbacks"), and after the revert in the tree that feeds to the CI,
>>> we're back on track.
>>>
>>> I found [1], was hoping to get feedback from Mika whether that helps
>>> before reporting. Chris also suggested [2] as a quick fix but I don't
>>> know if anyone tried that.
>>>
>>
>> Hi Jani,
>>
>> I know you were not CCed in the original thread, please see [5].
>>
>> The patchset from Thomas you mention [1] does fix one of the problems
>> I have seen, please see [6].
>> With these post-v4.10-rc1 patches applied a clean revert of Revert
>> "cpu/hotplug: Prevent overwriting of callbacks" is not possible.
>>
>> Can you give a clear statement if the quick-fix from Chris is in
>> combination with the above revert or not?
>> Against v4.10-rc1?
>> Tested together with the patchset of Thomas?
>
> Please test the Linus' tree from today, it should work.
>

Latest Linus tree (v4.10-rc1-17-g2d706e790f05) does not fix it.

- Sedat -


RE: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Doug Smythies
On 2016.12.28 14:33 Rafael J. Wysocki wrote:
> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
>>> On Wed, 28 Dec 2016, Sedat Dilek  wrote:
 On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:

 P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"

 This reverts commit dc280d93623927570da279e99393879dbbab39e7
 Author: Thomas Gleixner 
 Date: Wed Dec 21 20:19:49 2016 +0100
 cpu/hotplug: Prevent overwriting of callbacks

With respect to kernel 4.10-rc1 and the above referenced commit:

On my computer rdmsr was not working, and therefore many tools
that use it (i.e. turbostat) were also broken.

I bisected the kernel down to the same above referenced commit.
After finding some potentially related e-mails, I built a
4.10-rc1+ kernel with these:

0dad3a3 x86/mce/AMD: Make the init code more robust
b9d9d69 smp/hotplug: Undo tglxs brainfart
b4b8664 arm64: don't pull uaccess.h into *.S
7ce7d89 Linux 4.10-rc1

And now rdmsr is working fine, as is trubostat.




RE: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Doug Smythies
On 2016.12.28 14:33 Rafael J. Wysocki wrote:
> On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
>> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
>>> On Wed, 28 Dec 2016, Sedat Dilek  wrote:
 On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:

 P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"

 This reverts commit dc280d93623927570da279e99393879dbbab39e7
 Author: Thomas Gleixner 
 Date: Wed Dec 21 20:19:49 2016 +0100
 cpu/hotplug: Prevent overwriting of callbacks

With respect to kernel 4.10-rc1 and the above referenced commit:

On my computer rdmsr was not working, and therefore many tools
that use it (i.e. turbostat) were also broken.

I bisected the kernel down to the same above referenced commit.
After finding some potentially related e-mails, I built a
4.10-rc1+ kernel with these:

0dad3a3 x86/mce/AMD: Make the init code more robust
b9d9d69 smp/hotplug: Undo tglxs brainfart
b4b8664 arm64: don't pull uaccess.h into *.S
7ce7d89 Linux 4.10-rc1

And now rdmsr is working fine, as is trubostat.




Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Rafael J. Wysocki
On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
>> On Wed, 28 Dec 2016, Sedat Dilek  wrote:
>>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
 Hi!

> [ Add some pm | i915 | x86 folks ]
>
> Hi,
>
> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> and I see some call-traces.
> It is reproducible on suspend and resume.
>
> I cannot say which area touches the problem or if these are several
> independent problems.
>
> For a full dmesg-log see attachments (my linux-config is attached, too).
>
> Here some hunks...
>
> [   29.003601] BUG: sleeping function called from invalid context at
> drivers/base/power/runtime.c:1032
> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
> [   29.003610] 1 lock held by Xorg/1469:
> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
> 4.10.0-rc1-1-iniza-small #1
> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [   29.003656] Call Trace:

 Just a note, at least 2 machines here refuse to resume with
 v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
 common cause...

>>>
>>> [ Correct linux-pm ML and add Mika & Jani ]
>>>
>>> Thanks for the feedback.
>>>
>>> There are some cpu/hotplug fixes post-v4.10-rc1.
>>> Give that a try.
>>>
>>> Yesterday, after answers from drm-intel folks I have seen that a
>>> cpu/hotplug commit [1] was reverted in
>>> drm-intel.git#drm-intel-nightly.
>>> I haven't tried that.
>>>
>>> It's good when Thomas knows of this and gets in contact with drm-intel 
>>> folks.
>>>
>>> Regards,
>>> - Sedat -
>>>
>>> [1] 
>>> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
>>> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>>>
>>> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>>>
>>> This reverts commit dc280d93623927570da279e99393879dbbab39e7
>>> Author: Thomas Gleixner 
>>> Date: Wed Dec 21 20:19:49 2016 +0100
>>> cpu/hotplug: Prevent overwriting of callbacks
>>>
>>> It started hanging all machines in CI s3 test:
>>> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>>>
>>> Bisected-by: Mika Kuoppala 
>>> Signed-off-by: Jani Nikula 
>>
>> Thomas -
>>
>> Indeed, basically all of the boxes in the intel-gfx CI hang at the
>> suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
>> of callbacks"), and after the revert in the tree that feeds to the CI,
>> we're back on track.
>>
>> I found [1], was hoping to get feedback from Mika whether that helps
>> before reporting. Chris also suggested [2] as a quick fix but I don't
>> know if anyone tried that.
>>
>
> Hi Jani,
>
> I know you were not CCed in the original thread, please see [5].
>
> The patchset from Thomas you mention [1] does fix one of the problems
> I have seen, please see [6].
> With these post-v4.10-rc1 patches applied a clean revert of Revert
> "cpu/hotplug: Prevent overwriting of callbacks" is not possible.
>
> Can you give a clear statement if the quick-fix from Chris is in
> combination with the above revert or not?
> Against v4.10-rc1?
> Tested together with the patchset of Thomas?

Please test the Linus' tree from today, it should work.

Thanks,
Rafael


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Rafael J. Wysocki
On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilek  wrote:
> On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
>> On Wed, 28 Dec 2016, Sedat Dilek  wrote:
>>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
 Hi!

> [ Add some pm | i915 | x86 folks ]
>
> Hi,
>
> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> and I see some call-traces.
> It is reproducible on suspend and resume.
>
> I cannot say which area touches the problem or if these are several
> independent problems.
>
> For a full dmesg-log see attachments (my linux-config is attached, too).
>
> Here some hunks...
>
> [   29.003601] BUG: sleeping function called from invalid context at
> drivers/base/power/runtime.c:1032
> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
> [   29.003610] 1 lock held by Xorg/1469:
> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
> 4.10.0-rc1-1-iniza-small #1
> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [   29.003656] Call Trace:

 Just a note, at least 2 machines here refuse to resume with
 v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
 common cause...

>>>
>>> [ Correct linux-pm ML and add Mika & Jani ]
>>>
>>> Thanks for the feedback.
>>>
>>> There are some cpu/hotplug fixes post-v4.10-rc1.
>>> Give that a try.
>>>
>>> Yesterday, after answers from drm-intel folks I have seen that a
>>> cpu/hotplug commit [1] was reverted in
>>> drm-intel.git#drm-intel-nightly.
>>> I haven't tried that.
>>>
>>> It's good when Thomas knows of this and gets in contact with drm-intel 
>>> folks.
>>>
>>> Regards,
>>> - Sedat -
>>>
>>> [1] 
>>> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
>>> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>>>
>>> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>>>
>>> This reverts commit dc280d93623927570da279e99393879dbbab39e7
>>> Author: Thomas Gleixner 
>>> Date: Wed Dec 21 20:19:49 2016 +0100
>>> cpu/hotplug: Prevent overwriting of callbacks
>>>
>>> It started hanging all machines in CI s3 test:
>>> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>>>
>>> Bisected-by: Mika Kuoppala 
>>> Signed-off-by: Jani Nikula 
>>
>> Thomas -
>>
>> Indeed, basically all of the boxes in the intel-gfx CI hang at the
>> suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
>> of callbacks"), and after the revert in the tree that feeds to the CI,
>> we're back on track.
>>
>> I found [1], was hoping to get feedback from Mika whether that helps
>> before reporting. Chris also suggested [2] as a quick fix but I don't
>> know if anyone tried that.
>>
>
> Hi Jani,
>
> I know you were not CCed in the original thread, please see [5].
>
> The patchset from Thomas you mention [1] does fix one of the problems
> I have seen, please see [6].
> With these post-v4.10-rc1 patches applied a clean revert of Revert
> "cpu/hotplug: Prevent overwriting of callbacks" is not possible.
>
> Can you give a clear statement if the quick-fix from Chris is in
> combination with the above revert or not?
> Against v4.10-rc1?
> Tested together with the patchset of Thomas?

Please test the Linus' tree from today, it should work.

Thanks,
Rafael


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Sedat Dilek
On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
> On Wed, 28 Dec 2016, Sedat Dilek  wrote:
>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
>>> Hi!
>>>
 [ Add some pm | i915 | x86 folks ]

 Hi,

 I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
 and I see some call-traces.
 It is reproducible on suspend and resume.

 I cannot say which area touches the problem or if these are several
 independent problems.

 For a full dmesg-log see attachments (my linux-config is attached, too).

 Here some hunks...

 [   29.003601] BUG: sleeping function called from invalid context at
 drivers/base/power/runtime.c:1032
 [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
 [   29.003610] 1 lock held by Xorg/1469:
 [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
 [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
 [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
 4.10.0-rc1-1-iniza-small #1
 [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
 [   29.003656] Call Trace:
>>>
>>> Just a note, at least 2 machines here refuse to resume with
>>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>>> common cause...
>>>
>>
>> [ Correct linux-pm ML and add Mika & Jani ]
>>
>> Thanks for the feedback.
>>
>> There are some cpu/hotplug fixes post-v4.10-rc1.
>> Give that a try.
>>
>> Yesterday, after answers from drm-intel folks I have seen that a
>> cpu/hotplug commit [1] was reverted in
>> drm-intel.git#drm-intel-nightly.
>> I haven't tried that.
>>
>> It's good when Thomas knows of this and gets in contact with drm-intel folks.
>>
>> Regards,
>> - Sedat -
>>
>> [1] 
>> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
>> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>>
>> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>>
>> This reverts commit dc280d93623927570da279e99393879dbbab39e7
>> Author: Thomas Gleixner 
>> Date: Wed Dec 21 20:19:49 2016 +0100
>> cpu/hotplug: Prevent overwriting of callbacks
>>
>> It started hanging all machines in CI s3 test:
>> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>>
>> Bisected-by: Mika Kuoppala 
>> Signed-off-by: Jani Nikula 
>
> Thomas -
>
> Indeed, basically all of the boxes in the intel-gfx CI hang at the
> suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
> of callbacks"), and after the revert in the tree that feeds to the CI,
> we're back on track.
>
> I found [1], was hoping to get feedback from Mika whether that helps
> before reporting. Chris also suggested [2] as a quick fix but I don't
> know if anyone tried that.
>

Hi Jani,

I know you were not CCed in the original thread, please see [5].

The patchset from Thomas you mention [1] does fix one of the problems
I have seen, please see [6].
With these post-v4.10-rc1 patches applied a clean revert of Revert
"cpu/hotplug: Prevent overwriting of callbacks" is not possible.

Can you give a clear statement if the quick-fix from Chris is in
combination with the above revert or not?
Against v4.10-rc1?
Tested together with the patchset of Thomas?

Thanks.

Regards,
- Sedat -

[5] http://marc.info/?t=14827939021=1=2
[6] http://marc.info/?l=linux-kernel=148282459901267=2


> BR,
> Jani.
>
>
> [1] https://lkml.org/lkml/2016/12/26/156
> [2] http://paste.debian.net/904973/
>
>
> --
> Jani Nikula, Intel Open Source Technology Center


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Sedat Dilek
On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikula  wrote:
> On Wed, 28 Dec 2016, Sedat Dilek  wrote:
>> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
>>> Hi!
>>>
 [ Add some pm | i915 | x86 folks ]

 Hi,

 I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
 and I see some call-traces.
 It is reproducible on suspend and resume.

 I cannot say which area touches the problem or if these are several
 independent problems.

 For a full dmesg-log see attachments (my linux-config is attached, too).

 Here some hunks...

 [   29.003601] BUG: sleeping function called from invalid context at
 drivers/base/power/runtime.c:1032
 [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
 [   29.003610] 1 lock held by Xorg/1469:
 [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
 [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
 [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
 4.10.0-rc1-1-iniza-small #1
 [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
 [   29.003656] Call Trace:
>>>
>>> Just a note, at least 2 machines here refuse to resume with
>>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>>> common cause...
>>>
>>
>> [ Correct linux-pm ML and add Mika & Jani ]
>>
>> Thanks for the feedback.
>>
>> There are some cpu/hotplug fixes post-v4.10-rc1.
>> Give that a try.
>>
>> Yesterday, after answers from drm-intel folks I have seen that a
>> cpu/hotplug commit [1] was reverted in
>> drm-intel.git#drm-intel-nightly.
>> I haven't tried that.
>>
>> It's good when Thomas knows of this and gets in contact with drm-intel folks.
>>
>> Regards,
>> - Sedat -
>>
>> [1] 
>> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
>> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>>
>> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>>
>> This reverts commit dc280d93623927570da279e99393879dbbab39e7
>> Author: Thomas Gleixner 
>> Date: Wed Dec 21 20:19:49 2016 +0100
>> cpu/hotplug: Prevent overwriting of callbacks
>>
>> It started hanging all machines in CI s3 test:
>> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>>
>> Bisected-by: Mika Kuoppala 
>> Signed-off-by: Jani Nikula 
>
> Thomas -
>
> Indeed, basically all of the boxes in the intel-gfx CI hang at the
> suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
> of callbacks"), and after the revert in the tree that feeds to the CI,
> we're back on track.
>
> I found [1], was hoping to get feedback from Mika whether that helps
> before reporting. Chris also suggested [2] as a quick fix but I don't
> know if anyone tried that.
>

Hi Jani,

I know you were not CCed in the original thread, please see [5].

The patchset from Thomas you mention [1] does fix one of the problems
I have seen, please see [6].
With these post-v4.10-rc1 patches applied a clean revert of Revert
"cpu/hotplug: Prevent overwriting of callbacks" is not possible.

Can you give a clear statement if the quick-fix from Chris is in
combination with the above revert or not?
Against v4.10-rc1?
Tested together with the patchset of Thomas?

Thanks.

Regards,
- Sedat -

[5] http://marc.info/?t=14827939021=1=2
[6] http://marc.info/?l=linux-kernel=148282459901267=2


> BR,
> Jani.
>
>
> [1] https://lkml.org/lkml/2016/12/26/156
> [2] http://paste.debian.net/904973/
>
>
> --
> Jani Nikula, Intel Open Source Technology Center


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Jani Nikula
On Wed, 28 Dec 2016, Sedat Dilek  wrote:
> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
>> Hi!
>>
>>> [ Add some pm | i915 | x86 folks ]
>>>
>>> Hi,
>>>
>>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>> and I see some call-traces.
>>> It is reproducible on suspend and resume.
>>>
>>> I cannot say which area touches the problem or if these are several
>>> independent problems.
>>>
>>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>>
>>> Here some hunks...
>>>
>>> [   29.003601] BUG: sleeping function called from invalid context at
>>> drivers/base/power/runtime.c:1032
>>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>> [   29.003610] 1 lock held by Xorg/1469:
>>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>> 4.10.0-rc1-1-iniza-small #1
>>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> [   29.003656] Call Trace:
>>
>> Just a note, at least 2 machines here refuse to resume with
>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>> common cause...
>>
>
> [ Correct linux-pm ML and add Mika & Jani ]
>
> Thanks for the feedback.
>
> There are some cpu/hotplug fixes post-v4.10-rc1.
> Give that a try.
>
> Yesterday, after answers from drm-intel folks I have seen that a
> cpu/hotplug commit [1] was reverted in
> drm-intel.git#drm-intel-nightly.
> I haven't tried that.
>
> It's good when Thomas knows of this and gets in contact with drm-intel folks.
>
> Regards,
> - Sedat -
>
> [1] 
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>
> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>
> This reverts commit dc280d93623927570da279e99393879dbbab39e7
> Author: Thomas Gleixner 
> Date: Wed Dec 21 20:19:49 2016 +0100
> cpu/hotplug: Prevent overwriting of callbacks
>
> It started hanging all machines in CI s3 test:
> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>
> Bisected-by: Mika Kuoppala 
> Signed-off-by: Jani Nikula 

Thomas -

Indeed, basically all of the boxes in the intel-gfx CI hang at the
suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
of callbacks"), and after the revert in the tree that feeds to the CI,
we're back on track.

I found [1], was hoping to get feedback from Mika whether that helps
before reporting. Chris also suggested [2] as a quick fix but I don't
know if anyone tried that.

BR,
Jani.


[1] https://lkml.org/lkml/2016/12/26/156
[2] http://paste.debian.net/904973/


-- 
Jani Nikula, Intel Open Source Technology Center


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Jani Nikula
On Wed, 28 Dec 2016, Sedat Dilek  wrote:
> On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
>> Hi!
>>
>>> [ Add some pm | i915 | x86 folks ]
>>>
>>> Hi,
>>>
>>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>> and I see some call-traces.
>>> It is reproducible on suspend and resume.
>>>
>>> I cannot say which area touches the problem or if these are several
>>> independent problems.
>>>
>>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>>
>>> Here some hunks...
>>>
>>> [   29.003601] BUG: sleeping function called from invalid context at
>>> drivers/base/power/runtime.c:1032
>>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>> [   29.003610] 1 lock held by Xorg/1469:
>>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>> 4.10.0-rc1-1-iniza-small #1
>>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> [   29.003656] Call Trace:
>>
>> Just a note, at least 2 machines here refuse to resume with
>> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
>> common cause...
>>
>
> [ Correct linux-pm ML and add Mika & Jani ]
>
> Thanks for the feedback.
>
> There are some cpu/hotplug fixes post-v4.10-rc1.
> Give that a try.
>
> Yesterday, after answers from drm-intel folks I have seen that a
> cpu/hotplug commit [1] was reverted in
> drm-intel.git#drm-intel-nightly.
> I haven't tried that.
>
> It's good when Thomas knows of this and gets in contact with drm-intel folks.
>
> Regards,
> - Sedat -
>
> [1] 
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
> [2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly
>
> P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"
>
> This reverts commit dc280d93623927570da279e99393879dbbab39e7
> Author: Thomas Gleixner 
> Date: Wed Dec 21 20:19:49 2016 +0100
> cpu/hotplug: Prevent overwriting of callbacks
>
> It started hanging all machines in CI s3 test:
> https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html
>
> Bisected-by: Mika Kuoppala 
> Signed-off-by: Jani Nikula 

Thomas -

Indeed, basically all of the boxes in the intel-gfx CI hang at the
suspend/resume test with dc280d936239 ("cpu/hotplug: Prevent overwriting
of callbacks"), and after the revert in the tree that feeds to the CI,
we're back on track.

I found [1], was hoping to get feedback from Mika whether that helps
before reporting. Chris also suggested [2] as a quick fix but I don't
know if anyone tried that.

BR,
Jani.


[1] https://lkml.org/lkml/2016/12/26/156
[2] http://paste.debian.net/904973/


-- 
Jani Nikula, Intel Open Source Technology Center


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Sedat Dilek
On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
> Hi!
>
>> [ Add some pm | i915 | x86 folks ]
>>
>> Hi,
>>
>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>> and I see some call-traces.
>> It is reproducible on suspend and resume.
>>
>> I cannot say which area touches the problem or if these are several
>> independent problems.
>>
>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>
>> Here some hunks...
>>
>> [   29.003601] BUG: sleeping function called from invalid context at
>> drivers/base/power/runtime.c:1032
>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>> [   29.003610] 1 lock held by Xorg/1469:
>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>> 4.10.0-rc1-1-iniza-small #1
>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> [   29.003656] Call Trace:
>
> Just a note, at least 2 machines here refuse to resume with
> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
> common cause...
>

[ Correct linux-pm ML and add Mika & Jani ]

Thanks for the feedback.

There are some cpu/hotplug fixes post-v4.10-rc1.
Give that a try.

Yesterday, after answers from drm-intel folks I have seen that a
cpu/hotplug commit [1] was reverted in
drm-intel.git#drm-intel-nightly.
I haven't tried that.

It's good when Thomas knows of this and gets in contact with drm-intel folks.

Regards,
- Sedat -

[1] 
https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
[2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly

P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"

This reverts commit dc280d93623927570da279e99393879dbbab39e7
Author: Thomas Gleixner 
Date: Wed Dec 21 20:19:49 2016 +0100
cpu/hotplug: Prevent overwriting of callbacks

It started hanging all machines in CI s3 test:
https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html

Bisected-by: Mika Kuoppala 
Signed-off-by: Jani Nikula 

- EOT -


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-28 Thread Sedat Dilek
On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machek  wrote:
> Hi!
>
>> [ Add some pm | i915 | x86 folks ]
>>
>> Hi,
>>
>> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>> and I see some call-traces.
>> It is reproducible on suspend and resume.
>>
>> I cannot say which area touches the problem or if these are several
>> independent problems.
>>
>> For a full dmesg-log see attachments (my linux-config is attached, too).
>>
>> Here some hunks...
>>
>> [   29.003601] BUG: sleeping function called from invalid context at
>> drivers/base/power/runtime.c:1032
>> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>> [   29.003610] 1 lock held by Xorg/1469:
>> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>> 4.10.0-rc1-1-iniza-small #1
>> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> [   29.003656] Call Trace:
>
> Just a note, at least 2 machines here refuse to resume with
> v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
> common cause...
>

[ Correct linux-pm ML and add Mika & Jani ]

Thanks for the feedback.

There are some cpu/hotplug fixes post-v4.10-rc1.
Give that a try.

Yesterday, after answers from drm-intel folks I have seen that a
cpu/hotplug commit [1] was reverted in
drm-intel.git#drm-intel-nightly.
I haven't tried that.

It's good when Thomas knows of this and gets in contact with drm-intel folks.

Regards,
- Sedat -

[1] 
https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly=e558f178f5390185b7324ff4b816b52c6ae3a928
[2] https://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-nightly

P.S.: Revert "cpu/hotplug: Prevent overwriting of callbacks"

This reverts commit dc280d93623927570da279e99393879dbbab39e7
Author: Thomas Gleixner 
Date: Wed Dec 21 20:19:49 2016 +0100
cpu/hotplug: Prevent overwriting of callbacks

It started hanging all machines in CI s3 test:
https://intel-gfx-ci.01.org/CI/igt@gem_exec_susp...@basic-s3.html

Bisected-by: Mika Kuoppala 
Signed-off-by: Jani Nikula 

- EOT -


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-27 Thread Pavel Machek
Hi!

> [ Add some pm | i915 | x86 folks ]
> 
> Hi,
> 
> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> and I see some call-traces.
> It is reproducible on suspend and resume.
> 
> I cannot say which area touches the problem or if these are several
> independent problems.
> 
> For a full dmesg-log see attachments (my linux-config is attached, too).
> 
> Here some hunks...
> 
> [   29.003601] BUG: sleeping function called from invalid context at
> drivers/base/power/runtime.c:1032
> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
> [   29.003610] 1 lock held by Xorg/1469:
> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
> 4.10.0-rc1-1-iniza-small #1
> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [   29.003656] Call Trace:

Just a note, at least 2 machines here refuse to resume with
v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
common cause...

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-27 Thread Pavel Machek
Hi!

> [ Add some pm | i915 | x86 folks ]
> 
> Hi,
> 
> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> and I see some call-traces.
> It is reproducible on suspend and resume.
> 
> I cannot say which area touches the problem or if these are several
> independent problems.
> 
> For a full dmesg-log see attachments (my linux-config is attached, too).
> 
> Here some hunks...
> 
> [   29.003601] BUG: sleeping function called from invalid context at
> drivers/base/power/runtime.c:1032
> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
> [   29.003610] 1 lock held by Xorg/1469:
> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
> 4.10.0-rc1-1-iniza-small #1
> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [   29.003656] Call Trace:

Just a note, at least 2 machines here refuse to resume with
v4.10-rc1. One has intel graphics, one has AMD. It may or may not have
common cause...

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-27 Thread Sedat Dilek
On Tue, Dec 27, 2016 at 4:55 PM, Sedat Dilek  wrote:
> On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter  wrote:
>> On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
>>> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
>>> > [ Add some pm | i915 | x86 folks ]
>>> >
>>> > Hi,
>>> >
>>> > I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>> > and I see some call-traces.
>>> > It is reproducible on suspend and resume.
>>> >
>>> > I cannot say which area touches the problem or if these are several
>>> > independent problems.
>>> >
>>> > For a full dmesg-log see attachments (my linux-config is attached, too).
>>> >
>>> > Here some hunks...
>>> >
>>> > [   29.003601] BUG: sleeping function called from invalid context at
>>> > drivers/base/power/runtime.c:1032
>>> > [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>> > [   29.003610] 1 lock held by Xorg/1469:
>>> > [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>> > [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>> > [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>> > 4.10.0-rc1-1-iniza-small #1
>>> > [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> > [   29.003656] Call Trace:
>>> > [   29.003663]  dump_stack+0x85/0xc2
>>> > [   29.003666]  ___might_sleep+0x196/0x260
>>> > [   29.003668]  __might_sleep+0x53/0xb0
>>> > [   29.003671]  __pm_runtime_resume+0x7a/0x90
>>> > [   29.003691]  intel_runtime_pm_get+0x25/0x90 [i915]
>>> > [   29.003711]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>>> > [   29.003733]  i915_vma_bind+0xaf/0x1e0 [i915]
>>> > [   29.003752]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>>> > [   29.003755]  ? find_get_entry+0x5/0x240
>>> > [   29.003774]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 
>>> > [i915]
>>> > [   29.003796]  ? __i915_vma_do_pin+0x334/0x590 [i915]
>>> > [   29.003815]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 
>>> > [i915]
>>> > [   29.003833]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
>>> > [   29.003851]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>>> > [   29.003854]  ? __might_fault+0x4e/0xb0
>>> > [   29.003872]  i915_gem_execbuffer2+0xc5/0x260 [i915]
>>> > [   29.003873]  ? __might_fault+0x4e/0xb0
>>> > [   29.003888]  drm_ioctl+0x206/0x450 [drm]
>>> > [   29.003913]  ? i915_gem_execbuffer+0x340/0x340 [i915]
>>> > [   29.003918]  ? __fget+0x5/0x200
>>> > [   29.003922]  do_vfs_ioctl+0x91/0x6f0
>>> > [   29.003925]  ? __fget+0x111/0x200
>>> > [   29.003926]  ? __fget+0x5/0x200
>>> > [   29.003929]  SyS_ioctl+0x79/0x90
>>> > [   29.003934]  entry_SYSCALL_64_fastpath+0x23/0xc6
>>> > [   29.003936] RIP: 0033:0x7fb9e09e7bb7
>>> > [   29.003938] RSP: 002b:7ffe2dba2ea8 EFLAGS: 3202 ORIG_RAX:
>>> > 0010
>>> > [   29.003941] RAX: ffda RBX: 0012 RCX: 
>>> > 7fb9e09e7bb7
>>> > [   29.003942] RDX: 7ffe2dba2fa8 RSI: 40406469 RDI: 
>>> > 0009
>>> > [   29.003944] RBP: 7ffe2dba2dc0 R08: 0040 R09: 
>>> > 0101010101010101
>>> > [   29.003945] R10:  R11: 3202 R12: 
>>> > 0008
>>> > [   29.003947] R13: 00f5 R14:  R15: 
>>> > 
>>>
>>> This should be independent of suspend/resume and should be fixed with
>>> https://patchwork.freedesktop.org/patch/116373/
>>>
>>> commit ebc0808fa2da0548a78e715858024cb81cd732bc
>>> Author: Chris Wilson 
>>> Date:   Tue Oct 18 13:02:51 2016 +0100
>>>
>>> drm/i915: Restrict pagefault disabling to just around copy_from_user()
>>>
>>> It is in drm-intel-next-fixes, so should be picked up 4.10 in due
>>> course.
>>
>> Also note that our CI is unhappy with -rc1, and it was not due to i915
>> patches. So very likely something else is also broken.
>>
>
> Can you explain what "CI" means and its function in drm-intel development?
>
> The mentioned patch is 4/4 of a series [1].
> The single patch does not apply on top of Linux v4.10-rc1.
>
> 1/4 does not apply, etc.
>
> 2/4 is already in Linus tree [2].
> Can you explain why the other 3 did not got into v4.10-rc1?
>
> So, what is your advise to test Chris' patch?
>
> - Sedat -
>
> [1] https://patchwork.freedesktop.org/series/13950/
> [2] 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4bcbe2a90a1127a6dad72fbda27e77705d9e0f4

Linux v4.10-rc1 contains Chris 4/4 patch.

commit ebc0808fa2da0548a78e715858024cb81cd732bc
drm/i915: Restrict pagefault disabling to just around copy_from_user()

/me confused.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ebc0808fa2da0548a78e715858024cb81cd732bc


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-27 Thread Sedat Dilek
On Tue, Dec 27, 2016 at 4:55 PM, Sedat Dilek  wrote:
> On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter  wrote:
>> On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
>>> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
>>> > [ Add some pm | i915 | x86 folks ]
>>> >
>>> > Hi,
>>> >
>>> > I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>>> > and I see some call-traces.
>>> > It is reproducible on suspend and resume.
>>> >
>>> > I cannot say which area touches the problem or if these are several
>>> > independent problems.
>>> >
>>> > For a full dmesg-log see attachments (my linux-config is attached, too).
>>> >
>>> > Here some hunks...
>>> >
>>> > [   29.003601] BUG: sleeping function called from invalid context at
>>> > drivers/base/power/runtime.c:1032
>>> > [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>>> > [   29.003610] 1 lock held by Xorg/1469:
>>> > [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>>> > [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>>> > [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>>> > 4.10.0-rc1-1-iniza-small #1
>>> > [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>>> > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>>> > [   29.003656] Call Trace:
>>> > [   29.003663]  dump_stack+0x85/0xc2
>>> > [   29.003666]  ___might_sleep+0x196/0x260
>>> > [   29.003668]  __might_sleep+0x53/0xb0
>>> > [   29.003671]  __pm_runtime_resume+0x7a/0x90
>>> > [   29.003691]  intel_runtime_pm_get+0x25/0x90 [i915]
>>> > [   29.003711]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>>> > [   29.003733]  i915_vma_bind+0xaf/0x1e0 [i915]
>>> > [   29.003752]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>>> > [   29.003755]  ? find_get_entry+0x5/0x240
>>> > [   29.003774]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 
>>> > [i915]
>>> > [   29.003796]  ? __i915_vma_do_pin+0x334/0x590 [i915]
>>> > [   29.003815]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 
>>> > [i915]
>>> > [   29.003833]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
>>> > [   29.003851]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>>> > [   29.003854]  ? __might_fault+0x4e/0xb0
>>> > [   29.003872]  i915_gem_execbuffer2+0xc5/0x260 [i915]
>>> > [   29.003873]  ? __might_fault+0x4e/0xb0
>>> > [   29.003888]  drm_ioctl+0x206/0x450 [drm]
>>> > [   29.003913]  ? i915_gem_execbuffer+0x340/0x340 [i915]
>>> > [   29.003918]  ? __fget+0x5/0x200
>>> > [   29.003922]  do_vfs_ioctl+0x91/0x6f0
>>> > [   29.003925]  ? __fget+0x111/0x200
>>> > [   29.003926]  ? __fget+0x5/0x200
>>> > [   29.003929]  SyS_ioctl+0x79/0x90
>>> > [   29.003934]  entry_SYSCALL_64_fastpath+0x23/0xc6
>>> > [   29.003936] RIP: 0033:0x7fb9e09e7bb7
>>> > [   29.003938] RSP: 002b:7ffe2dba2ea8 EFLAGS: 3202 ORIG_RAX:
>>> > 0010
>>> > [   29.003941] RAX: ffda RBX: 0012 RCX: 
>>> > 7fb9e09e7bb7
>>> > [   29.003942] RDX: 7ffe2dba2fa8 RSI: 40406469 RDI: 
>>> > 0009
>>> > [   29.003944] RBP: 7ffe2dba2dc0 R08: 0040 R09: 
>>> > 0101010101010101
>>> > [   29.003945] R10:  R11: 3202 R12: 
>>> > 0008
>>> > [   29.003947] R13: 00f5 R14:  R15: 
>>> > 
>>>
>>> This should be independent of suspend/resume and should be fixed with
>>> https://patchwork.freedesktop.org/patch/116373/
>>>
>>> commit ebc0808fa2da0548a78e715858024cb81cd732bc
>>> Author: Chris Wilson 
>>> Date:   Tue Oct 18 13:02:51 2016 +0100
>>>
>>> drm/i915: Restrict pagefault disabling to just around copy_from_user()
>>>
>>> It is in drm-intel-next-fixes, so should be picked up 4.10 in due
>>> course.
>>
>> Also note that our CI is unhappy with -rc1, and it was not due to i915
>> patches. So very likely something else is also broken.
>>
>
> Can you explain what "CI" means and its function in drm-intel development?
>
> The mentioned patch is 4/4 of a series [1].
> The single patch does not apply on top of Linux v4.10-rc1.
>
> 1/4 does not apply, etc.
>
> 2/4 is already in Linus tree [2].
> Can you explain why the other 3 did not got into v4.10-rc1?
>
> So, what is your advise to test Chris' patch?
>
> - Sedat -
>
> [1] https://patchwork.freedesktop.org/series/13950/
> [2] 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4bcbe2a90a1127a6dad72fbda27e77705d9e0f4

Linux v4.10-rc1 contains Chris 4/4 patch.

commit ebc0808fa2da0548a78e715858024cb81cd732bc
drm/i915: Restrict pagefault disabling to just around copy_from_user()

/me confused.

- Sedat -

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ebc0808fa2da0548a78e715858024cb81cd732bc


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-27 Thread Sedat Dilek
On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter  wrote:
> On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
>> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
>> > [ Add some pm | i915 | x86 folks ]
>> >
>> > Hi,
>> >
>> > I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>> > and I see some call-traces.
>> > It is reproducible on suspend and resume.
>> >
>> > I cannot say which area touches the problem or if these are several
>> > independent problems.
>> >
>> > For a full dmesg-log see attachments (my linux-config is attached, too).
>> >
>> > Here some hunks...
>> >
>> > [   29.003601] BUG: sleeping function called from invalid context at
>> > drivers/base/power/runtime.c:1032
>> > [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>> > [   29.003610] 1 lock held by Xorg/1469:
>> > [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>> > [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> > [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>> > 4.10.0-rc1-1-iniza-small #1
>> > [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> > [   29.003656] Call Trace:
>> > [   29.003663]  dump_stack+0x85/0xc2
>> > [   29.003666]  ___might_sleep+0x196/0x260
>> > [   29.003668]  __might_sleep+0x53/0xb0
>> > [   29.003671]  __pm_runtime_resume+0x7a/0x90
>> > [   29.003691]  intel_runtime_pm_get+0x25/0x90 [i915]
>> > [   29.003711]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>> > [   29.003733]  i915_vma_bind+0xaf/0x1e0 [i915]
>> > [   29.003752]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>> > [   29.003755]  ? find_get_entry+0x5/0x240
>> > [   29.003774]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
>> > [   29.003796]  ? __i915_vma_do_pin+0x334/0x590 [i915]
>> > [   29.003815]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 
>> > [i915]
>> > [   29.003833]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
>> > [   29.003851]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>> > [   29.003854]  ? __might_fault+0x4e/0xb0
>> > [   29.003872]  i915_gem_execbuffer2+0xc5/0x260 [i915]
>> > [   29.003873]  ? __might_fault+0x4e/0xb0
>> > [   29.003888]  drm_ioctl+0x206/0x450 [drm]
>> > [   29.003913]  ? i915_gem_execbuffer+0x340/0x340 [i915]
>> > [   29.003918]  ? __fget+0x5/0x200
>> > [   29.003922]  do_vfs_ioctl+0x91/0x6f0
>> > [   29.003925]  ? __fget+0x111/0x200
>> > [   29.003926]  ? __fget+0x5/0x200
>> > [   29.003929]  SyS_ioctl+0x79/0x90
>> > [   29.003934]  entry_SYSCALL_64_fastpath+0x23/0xc6
>> > [   29.003936] RIP: 0033:0x7fb9e09e7bb7
>> > [   29.003938] RSP: 002b:7ffe2dba2ea8 EFLAGS: 3202 ORIG_RAX:
>> > 0010
>> > [   29.003941] RAX: ffda RBX: 0012 RCX: 
>> > 7fb9e09e7bb7
>> > [   29.003942] RDX: 7ffe2dba2fa8 RSI: 40406469 RDI: 
>> > 0009
>> > [   29.003944] RBP: 7ffe2dba2dc0 R08: 0040 R09: 
>> > 0101010101010101
>> > [   29.003945] R10:  R11: 3202 R12: 
>> > 0008
>> > [   29.003947] R13: 00f5 R14:  R15: 
>> > 
>>
>> This should be independent of suspend/resume and should be fixed with
>> https://patchwork.freedesktop.org/patch/116373/
>>
>> commit ebc0808fa2da0548a78e715858024cb81cd732bc
>> Author: Chris Wilson 
>> Date:   Tue Oct 18 13:02:51 2016 +0100
>>
>> drm/i915: Restrict pagefault disabling to just around copy_from_user()
>>
>> It is in drm-intel-next-fixes, so should be picked up 4.10 in due
>> course.
>
> Also note that our CI is unhappy with -rc1, and it was not due to i915
> patches. So very likely something else is also broken.
>

Can you explain what "CI" means and its function in drm-intel development?

The mentioned patch is 4/4 of a series [1].
The single patch does not apply on top of Linux v4.10-rc1.

1/4 does not apply, etc.

2/4 is already in Linus tree [2].
Can you explain why the other 3 did not got into v4.10-rc1?

So, what is your advise to test Chris' patch?

- Sedat -

[1] https://patchwork.freedesktop.org/series/13950/
[2] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4bcbe2a90a1127a6dad72fbda27e77705d9e0f4


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-27 Thread Sedat Dilek
On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetter  wrote:
> On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
>> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
>> > [ Add some pm | i915 | x86 folks ]
>> >
>> > Hi,
>> >
>> > I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
>> > and I see some call-traces.
>> > It is reproducible on suspend and resume.
>> >
>> > I cannot say which area touches the problem or if these are several
>> > independent problems.
>> >
>> > For a full dmesg-log see attachments (my linux-config is attached, too).
>> >
>> > Here some hunks...
>> >
>> > [   29.003601] BUG: sleeping function called from invalid context at
>> > drivers/base/power/runtime.c:1032
>> > [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
>> > [   29.003610] 1 lock held by Xorg/1469:
>> > [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
>> > [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
>> > [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
>> > 4.10.0-rc1-1-iniza-small #1
>> > [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
>> > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
>> > [   29.003656] Call Trace:
>> > [   29.003663]  dump_stack+0x85/0xc2
>> > [   29.003666]  ___might_sleep+0x196/0x260
>> > [   29.003668]  __might_sleep+0x53/0xb0
>> > [   29.003671]  __pm_runtime_resume+0x7a/0x90
>> > [   29.003691]  intel_runtime_pm_get+0x25/0x90 [i915]
>> > [   29.003711]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
>> > [   29.003733]  i915_vma_bind+0xaf/0x1e0 [i915]
>> > [   29.003752]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
>> > [   29.003755]  ? find_get_entry+0x5/0x240
>> > [   29.003774]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
>> > [   29.003796]  ? __i915_vma_do_pin+0x334/0x590 [i915]
>> > [   29.003815]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 
>> > [i915]
>> > [   29.003833]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
>> > [   29.003851]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
>> > [   29.003854]  ? __might_fault+0x4e/0xb0
>> > [   29.003872]  i915_gem_execbuffer2+0xc5/0x260 [i915]
>> > [   29.003873]  ? __might_fault+0x4e/0xb0
>> > [   29.003888]  drm_ioctl+0x206/0x450 [drm]
>> > [   29.003913]  ? i915_gem_execbuffer+0x340/0x340 [i915]
>> > [   29.003918]  ? __fget+0x5/0x200
>> > [   29.003922]  do_vfs_ioctl+0x91/0x6f0
>> > [   29.003925]  ? __fget+0x111/0x200
>> > [   29.003926]  ? __fget+0x5/0x200
>> > [   29.003929]  SyS_ioctl+0x79/0x90
>> > [   29.003934]  entry_SYSCALL_64_fastpath+0x23/0xc6
>> > [   29.003936] RIP: 0033:0x7fb9e09e7bb7
>> > [   29.003938] RSP: 002b:7ffe2dba2ea8 EFLAGS: 3202 ORIG_RAX:
>> > 0010
>> > [   29.003941] RAX: ffda RBX: 0012 RCX: 
>> > 7fb9e09e7bb7
>> > [   29.003942] RDX: 7ffe2dba2fa8 RSI: 40406469 RDI: 
>> > 0009
>> > [   29.003944] RBP: 7ffe2dba2dc0 R08: 0040 R09: 
>> > 0101010101010101
>> > [   29.003945] R10:  R11: 3202 R12: 
>> > 0008
>> > [   29.003947] R13: 00f5 R14:  R15: 
>> > 
>>
>> This should be independent of suspend/resume and should be fixed with
>> https://patchwork.freedesktop.org/patch/116373/
>>
>> commit ebc0808fa2da0548a78e715858024cb81cd732bc
>> Author: Chris Wilson 
>> Date:   Tue Oct 18 13:02:51 2016 +0100
>>
>> drm/i915: Restrict pagefault disabling to just around copy_from_user()
>>
>> It is in drm-intel-next-fixes, so should be picked up 4.10 in due
>> course.
>
> Also note that our CI is unhappy with -rc1, and it was not due to i915
> patches. So very likely something else is also broken.
>

Can you explain what "CI" means and its function in drm-intel development?

The mentioned patch is 4/4 of a series [1].
The single patch does not apply on top of Linux v4.10-rc1.

1/4 does not apply, etc.

2/4 is already in Linus tree [2].
Can you explain why the other 3 did not got into v4.10-rc1?

So, what is your advise to test Chris' patch?

- Sedat -

[1] https://patchwork.freedesktop.org/series/13950/
[2] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4bcbe2a90a1127a6dad72fbda27e77705d9e0f4


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-27 Thread Daniel Vetter
On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
> > [ Add some pm | i915 | x86 folks ]
> > 
> > Hi,
> > 
> > I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> > and I see some call-traces.
> > It is reproducible on suspend and resume.
> > 
> > I cannot say which area touches the problem or if these are several
> > independent problems.
> > 
> > For a full dmesg-log see attachments (my linux-config is attached, too).
> > 
> > Here some hunks...
> > 
> > [   29.003601] BUG: sleeping function called from invalid context at
> > drivers/base/power/runtime.c:1032
> > [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
> > [   29.003610] 1 lock held by Xorg/1469:
> > [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
> > [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> > [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
> > 4.10.0-rc1-1-iniza-small #1
> > [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> > [   29.003656] Call Trace:
> > [   29.003663]  dump_stack+0x85/0xc2
> > [   29.003666]  ___might_sleep+0x196/0x260
> > [   29.003668]  __might_sleep+0x53/0xb0
> > [   29.003671]  __pm_runtime_resume+0x7a/0x90
> > [   29.003691]  intel_runtime_pm_get+0x25/0x90 [i915]
> > [   29.003711]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> > [   29.003733]  i915_vma_bind+0xaf/0x1e0 [i915]
> > [   29.003752]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> > [   29.003755]  ? find_get_entry+0x5/0x240
> > [   29.003774]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
> > [   29.003796]  ? __i915_vma_do_pin+0x334/0x590 [i915]
> > [   29.003815]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
> > [   29.003833]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
> > [   29.003851]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> > [   29.003854]  ? __might_fault+0x4e/0xb0
> > [   29.003872]  i915_gem_execbuffer2+0xc5/0x260 [i915]
> > [   29.003873]  ? __might_fault+0x4e/0xb0
> > [   29.003888]  drm_ioctl+0x206/0x450 [drm]
> > [   29.003913]  ? i915_gem_execbuffer+0x340/0x340 [i915]
> > [   29.003918]  ? __fget+0x5/0x200
> > [   29.003922]  do_vfs_ioctl+0x91/0x6f0
> > [   29.003925]  ? __fget+0x111/0x200
> > [   29.003926]  ? __fget+0x5/0x200
> > [   29.003929]  SyS_ioctl+0x79/0x90
> > [   29.003934]  entry_SYSCALL_64_fastpath+0x23/0xc6
> > [   29.003936] RIP: 0033:0x7fb9e09e7bb7
> > [   29.003938] RSP: 002b:7ffe2dba2ea8 EFLAGS: 3202 ORIG_RAX:
> > 0010
> > [   29.003941] RAX: ffda RBX: 0012 RCX: 
> > 7fb9e09e7bb7
> > [   29.003942] RDX: 7ffe2dba2fa8 RSI: 40406469 RDI: 
> > 0009
> > [   29.003944] RBP: 7ffe2dba2dc0 R08: 0040 R09: 
> > 0101010101010101
> > [   29.003945] R10:  R11: 3202 R12: 
> > 0008
> > [   29.003947] R13: 00f5 R14:  R15: 
> > 
> 
> This should be independent of suspend/resume and should be fixed with
> https://patchwork.freedesktop.org/patch/116373/
> 
> commit ebc0808fa2da0548a78e715858024cb81cd732bc
> Author: Chris Wilson 
> Date:   Tue Oct 18 13:02:51 2016 +0100
> 
> drm/i915: Restrict pagefault disabling to just around copy_from_user()
> 
> It is in drm-intel-next-fixes, so should be picked up 4.10 in due
> course.

Also note that our CI is unhappy with -rc1, and it was not due to i915
patches. So very likely something else is also broken.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-27 Thread Daniel Vetter
On Tue, Dec 27, 2016 at 10:24:42AM +, Chris Wilson wrote:
> On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
> > [ Add some pm | i915 | x86 folks ]
> > 
> > Hi,
> > 
> > I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> > and I see some call-traces.
> > It is reproducible on suspend and resume.
> > 
> > I cannot say which area touches the problem or if these are several
> > independent problems.
> > 
> > For a full dmesg-log see attachments (my linux-config is attached, too).
> > 
> > Here some hunks...
> > 
> > [   29.003601] BUG: sleeping function called from invalid context at
> > drivers/base/power/runtime.c:1032
> > [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
> > [   29.003610] 1 lock held by Xorg/1469:
> > [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
> > [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> > [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
> > 4.10.0-rc1-1-iniza-small #1
> > [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> > [   29.003656] Call Trace:
> > [   29.003663]  dump_stack+0x85/0xc2
> > [   29.003666]  ___might_sleep+0x196/0x260
> > [   29.003668]  __might_sleep+0x53/0xb0
> > [   29.003671]  __pm_runtime_resume+0x7a/0x90
> > [   29.003691]  intel_runtime_pm_get+0x25/0x90 [i915]
> > [   29.003711]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> > [   29.003733]  i915_vma_bind+0xaf/0x1e0 [i915]
> > [   29.003752]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> > [   29.003755]  ? find_get_entry+0x5/0x240
> > [   29.003774]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
> > [   29.003796]  ? __i915_vma_do_pin+0x334/0x590 [i915]
> > [   29.003815]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
> > [   29.003833]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
> > [   29.003851]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> > [   29.003854]  ? __might_fault+0x4e/0xb0
> > [   29.003872]  i915_gem_execbuffer2+0xc5/0x260 [i915]
> > [   29.003873]  ? __might_fault+0x4e/0xb0
> > [   29.003888]  drm_ioctl+0x206/0x450 [drm]
> > [   29.003913]  ? i915_gem_execbuffer+0x340/0x340 [i915]
> > [   29.003918]  ? __fget+0x5/0x200
> > [   29.003922]  do_vfs_ioctl+0x91/0x6f0
> > [   29.003925]  ? __fget+0x111/0x200
> > [   29.003926]  ? __fget+0x5/0x200
> > [   29.003929]  SyS_ioctl+0x79/0x90
> > [   29.003934]  entry_SYSCALL_64_fastpath+0x23/0xc6
> > [   29.003936] RIP: 0033:0x7fb9e09e7bb7
> > [   29.003938] RSP: 002b:7ffe2dba2ea8 EFLAGS: 3202 ORIG_RAX:
> > 0010
> > [   29.003941] RAX: ffda RBX: 0012 RCX: 
> > 7fb9e09e7bb7
> > [   29.003942] RDX: 7ffe2dba2fa8 RSI: 40406469 RDI: 
> > 0009
> > [   29.003944] RBP: 7ffe2dba2dc0 R08: 0040 R09: 
> > 0101010101010101
> > [   29.003945] R10:  R11: 3202 R12: 
> > 0008
> > [   29.003947] R13: 00f5 R14:  R15: 
> > 
> 
> This should be independent of suspend/resume and should be fixed with
> https://patchwork.freedesktop.org/patch/116373/
> 
> commit ebc0808fa2da0548a78e715858024cb81cd732bc
> Author: Chris Wilson 
> Date:   Tue Oct 18 13:02:51 2016 +0100
> 
> drm/i915: Restrict pagefault disabling to just around copy_from_user()
> 
> It is in drm-intel-next-fixes, so should be picked up 4.10 in due
> course.

Also note that our CI is unhappy with -rc1, and it was not due to i915
patches. So very likely something else is also broken.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-27 Thread Chris Wilson
On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
> [ Add some pm | i915 | x86 folks ]
> 
> Hi,
> 
> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> and I see some call-traces.
> It is reproducible on suspend and resume.
> 
> I cannot say which area touches the problem or if these are several
> independent problems.
> 
> For a full dmesg-log see attachments (my linux-config is attached, too).
> 
> Here some hunks...
> 
> [   29.003601] BUG: sleeping function called from invalid context at
> drivers/base/power/runtime.c:1032
> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
> [   29.003610] 1 lock held by Xorg/1469:
> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
> 4.10.0-rc1-1-iniza-small #1
> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [   29.003656] Call Trace:
> [   29.003663]  dump_stack+0x85/0xc2
> [   29.003666]  ___might_sleep+0x196/0x260
> [   29.003668]  __might_sleep+0x53/0xb0
> [   29.003671]  __pm_runtime_resume+0x7a/0x90
> [   29.003691]  intel_runtime_pm_get+0x25/0x90 [i915]
> [   29.003711]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> [   29.003733]  i915_vma_bind+0xaf/0x1e0 [i915]
> [   29.003752]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> [   29.003755]  ? find_get_entry+0x5/0x240
> [   29.003774]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
> [   29.003796]  ? __i915_vma_do_pin+0x334/0x590 [i915]
> [   29.003815]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
> [   29.003833]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
> [   29.003851]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> [   29.003854]  ? __might_fault+0x4e/0xb0
> [   29.003872]  i915_gem_execbuffer2+0xc5/0x260 [i915]
> [   29.003873]  ? __might_fault+0x4e/0xb0
> [   29.003888]  drm_ioctl+0x206/0x450 [drm]
> [   29.003913]  ? i915_gem_execbuffer+0x340/0x340 [i915]
> [   29.003918]  ? __fget+0x5/0x200
> [   29.003922]  do_vfs_ioctl+0x91/0x6f0
> [   29.003925]  ? __fget+0x111/0x200
> [   29.003926]  ? __fget+0x5/0x200
> [   29.003929]  SyS_ioctl+0x79/0x90
> [   29.003934]  entry_SYSCALL_64_fastpath+0x23/0xc6
> [   29.003936] RIP: 0033:0x7fb9e09e7bb7
> [   29.003938] RSP: 002b:7ffe2dba2ea8 EFLAGS: 3202 ORIG_RAX:
> 0010
> [   29.003941] RAX: ffda RBX: 0012 RCX: 
> 7fb9e09e7bb7
> [   29.003942] RDX: 7ffe2dba2fa8 RSI: 40406469 RDI: 
> 0009
> [   29.003944] RBP: 7ffe2dba2dc0 R08: 0040 R09: 
> 0101010101010101
> [   29.003945] R10:  R11: 3202 R12: 
> 0008
> [   29.003947] R13: 00f5 R14:  R15: 
> 

This should be independent of suspend/resume and should be fixed with
https://patchwork.freedesktop.org/patch/116373/

commit ebc0808fa2da0548a78e715858024cb81cd732bc
Author: Chris Wilson 
Date:   Tue Oct 18 13:02:51 2016 +0100

drm/i915: Restrict pagefault disabling to just around copy_from_user()

It is in drm-intel-next-fixes, so should be picked up 4.10 in due
course.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)

2016-12-27 Thread Chris Wilson
On Tue, Dec 27, 2016 at 12:09:22AM +0100, Sedat Dilek wrote:
> [ Add some pm | i915 | x86 folks ]
> 
> Hi,
> 
> I have built Linux v4.10-rc1 today on my Ubuntu/precise AMD64 system
> and I see some call-traces.
> It is reproducible on suspend and resume.
> 
> I cannot say which area touches the problem or if these are several
> independent problems.
> 
> For a full dmesg-log see attachments (my linux-config is attached, too).
> 
> Here some hunks...
> 
> [   29.003601] BUG: sleeping function called from invalid context at
> drivers/base/power/runtime.c:1032
> [   29.003608] in_atomic(): 1, irqs_disabled(): 0, pid: 1469, name: Xorg
> [   29.003610] 1 lock held by Xorg/1469:
> [   29.003611]  #0:  (>struct_mutex){+.+.+.}, at:
> [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
> [   29.003653] CPU: 0 PID: 1469 Comm: Xorg Not tainted
> 4.10.0-rc1-1-iniza-small #1
> [   29.003655] Hardware name: SAMSUNG ELECTRONICS CO., LTD.
> 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013
> [   29.003656] Call Trace:
> [   29.003663]  dump_stack+0x85/0xc2
> [   29.003666]  ___might_sleep+0x196/0x260
> [   29.003668]  __might_sleep+0x53/0xb0
> [   29.003671]  __pm_runtime_resume+0x7a/0x90
> [   29.003691]  intel_runtime_pm_get+0x25/0x90 [i915]
> [   29.003711]  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
> [   29.003733]  i915_vma_bind+0xaf/0x1e0 [i915]
> [   29.003752]  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
> [   29.003755]  ? find_get_entry+0x5/0x240
> [   29.003774]  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
> [   29.003796]  ? __i915_vma_do_pin+0x334/0x590 [i915]
> [   29.003815]  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
> [   29.003833]  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
> [   29.003851]  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
> [   29.003854]  ? __might_fault+0x4e/0xb0
> [   29.003872]  i915_gem_execbuffer2+0xc5/0x260 [i915]
> [   29.003873]  ? __might_fault+0x4e/0xb0
> [   29.003888]  drm_ioctl+0x206/0x450 [drm]
> [   29.003913]  ? i915_gem_execbuffer+0x340/0x340 [i915]
> [   29.003918]  ? __fget+0x5/0x200
> [   29.003922]  do_vfs_ioctl+0x91/0x6f0
> [   29.003925]  ? __fget+0x111/0x200
> [   29.003926]  ? __fget+0x5/0x200
> [   29.003929]  SyS_ioctl+0x79/0x90
> [   29.003934]  entry_SYSCALL_64_fastpath+0x23/0xc6
> [   29.003936] RIP: 0033:0x7fb9e09e7bb7
> [   29.003938] RSP: 002b:7ffe2dba2ea8 EFLAGS: 3202 ORIG_RAX:
> 0010
> [   29.003941] RAX: ffda RBX: 0012 RCX: 
> 7fb9e09e7bb7
> [   29.003942] RDX: 7ffe2dba2fa8 RSI: 40406469 RDI: 
> 0009
> [   29.003944] RBP: 7ffe2dba2dc0 R08: 0040 R09: 
> 0101010101010101
> [   29.003945] R10:  R11: 3202 R12: 
> 0008
> [   29.003947] R13: 00f5 R14:  R15: 
> 

This should be independent of suspend/resume and should be fixed with
https://patchwork.freedesktop.org/patch/116373/

commit ebc0808fa2da0548a78e715858024cb81cd732bc
Author: Chris Wilson 
Date:   Tue Oct 18 13:02:51 2016 +0100

drm/i915: Restrict pagefault disabling to just around copy_from_user()

It is in drm-intel-next-fixes, so should be picked up 4.10 in due
course.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre