Re: [Linux v4.10.0-rc1] call-traces after suspend-resume (pm? i915? cpu/hotplug?)
On Thu, Dec 29, 2016 at 12:58 PM, Mika Kuoppalawrote: > 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?)
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?)
Sedat Dilekwrites: > 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?)
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?)
On Thu, 29 Dec 2016, Sedat Dilekwrote: > 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?)
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?)
On Wed, Dec 28, 2016 at 11:32 PM, Rafael J. Wysockiwrote: > 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?)
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?)
On 2016.12.28 14:33 Rafael J. Wysocki wrote: > On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilekwrote: >> 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?)
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?)
On Wed, Dec 28, 2016 at 11:00 AM, Sedat Dilekwrote: > 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?)
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?)
On Wed, Dec 28, 2016 at 9:29 AM, Jani Nikulawrote: > 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?)
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?)
On Wed, 28 Dec 2016, Sedat Dilekwrote: > 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?)
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?)
On Tue, Dec 27, 2016 at 10:13 PM, Pavel Machekwrote: > 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?)
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?)
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?)
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?)
On Tue, Dec 27, 2016 at 4:55 PM, Sedat Dilekwrote: > 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?)
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?)
On Tue, Dec 27, 2016 at 4:10 PM, Daniel Vetterwrote: > 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?)
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?)
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?)
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?)
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 WilsonDate: 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?)
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