Re: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
On Thu, 2014-07-31 at 23:47 +0200, Ian Kumlien wrote: On tor, 2014-07-31 at 14:39 +0300, Imre Deak wrote: On Wed, 2014-07-30 at 22:52 +0200, Ian Kumlien wrote: Sorry for the delay, it's been damned hot - vacation is over and overtime has been all the rage at work... No problem, thanks for the feedback. On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote: On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote: Try four, now including CC lists for the intel driver... Could you give a try to the 2 patches at: https://patchwork.kernel.org/patch/4437061/ Didn't quite get that it was two separate patches at first, but when i did i also spotted a v2 of the patch set. I applied: https://patchwork.kernel.org/patch/4648961/ https://patchwork.kernel.org/patch/4648951/ On to 3.16-rc7 (there was some fuzz but it applied fine) I didn't see any OOPS:es (didn't scroll around too much) but otoh the screen never turned off? (it's one of those silly mac things, the apple is still lit) and the machine doesn't suspend/sleep anymore. AFAIR it does, after some coaxing, on the unpatched kernel (ie, not the first time but the second time i turn down the lid, i tried three times and play:ed with brightness as i assume you can see in the log) Hm, I can't see how these patches could prevent system suspend. Also according to the dmesg you sent suspend didn't even start, so I guess you're seeing a separate issue. Maybe the lid notification isn't properly handled, but I can't really help tracking that down. It works without the drm.debug=14 so it might be something else... In any case to reproduce the particular bug in question (or see if the fix works) you need to get the machine to suspend/resume somehow. One way is to 'echo mem /sys/power/state' as root and resume by pressing power button or similar; could you still try this, again sending the dmesg? You'll find it attached ;) Ok, I see the trace of suspend/resume now, but the bug has vanished.. I can't see the WARN backtrace in your original report, nor the debug message from the above fix, that would indicate that it had fixed anything (VDD left on by BIOS, adjusting state tracking). So I'm a bit lost, I would need a full dmesg with either the WARN or this debug message. --Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
On Fri, Aug 1, 2014 at 3:16 PM, Imre Deak imre.d...@intel.com wrote: [--8--] Ok, I see the trace of suspend/resume now, but the bug has vanished.. I can't see the WARN backtrace in your original report, nor the debug message from the above fix, that would indicate that it had fixed anything (VDD left on by BIOS, adjusting state tracking). So I'm a bit lost, I would need a full dmesg with either the WARN or this debug message. Well the bug seemed to be a unbalanced _put _get thing. At least that's the impression i got when reading the code, so what i did, which is part of the original patch, is to make sure that the _put happens so that the mode isn't '0' and thus triggers a warn_on. What we can say is that due to the patch you sent these are now balanced in that code... Actually reading the patches again i can't see how that happened, esp without the debug message... I think I'll have to play some more with this and get back to you when $clue has increased by at least one =) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
On Wed, 2014-07-30 at 22:52 +0200, Ian Kumlien wrote: Sorry for the delay, it's been damned hot - vacation is over and overtime has been all the rage at work... No problem, thanks for the feedback. On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote: On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote: Try four, now including CC lists for the intel driver... Could you give a try to the 2 patches at: https://patchwork.kernel.org/patch/4437061/ Didn't quite get that it was two separate patches at first, but when i did i also spotted a v2 of the patch set. I applied: https://patchwork.kernel.org/patch/4648961/ https://patchwork.kernel.org/patch/4648951/ On to 3.16-rc7 (there was some fuzz but it applied fine) I didn't see any OOPS:es (didn't scroll around too much) but otoh the screen never turned off? (it's one of those silly mac things, the apple is still lit) and the machine doesn't suspend/sleep anymore. AFAIR it does, after some coaxing, on the unpatched kernel (ie, not the first time but the second time i turn down the lid, i tried three times and play:ed with brightness as i assume you can see in the log) Hm, I can't see how these patches could prevent system suspend. Also according to the dmesg you sent suspend didn't even start, so I guess you're seeing a separate issue. Maybe the lid notification isn't properly handled, but I can't really help tracking that down. In any case to reproduce the particular bug in question (or see if the fix works) you need to get the machine to suspend/resume somehow. One way is to 'echo mem /sys/power/state' as root and resume by pressing power button or similar; could you still try this, again sending the dmesg? Thanks, Imre signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote: Try four, now including CC lists for the intel driver... Could you give a try to the 2 patches at: https://patchwork.kernel.org/patch/4437061/ If these don't fix the issue, could you send a full dmesg log with the drm.debug=14 kernel option set? Thanks, Imre --- Hi again, Playing some more with the new kernel release i noticed this: [ 9064.008821] WARNING: CPU: 3 PID: 22929 at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160() [ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill snd_hda_codec_cirrus uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma [ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW 3.16.0-rc6 #23 [ 9064.008840] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B03.1211161133 11/16/2012 [ 9064.008843] Workqueue: events edp_panel_vdd_work [ 9064.008844] 0009 88015ba77d28 8198ea2d [ 9064.008846] 88015ba77d60 810cbac8 8802610b002c 000c7204 [ 9064.008848] 0001 8802610b80f0 8802610b 88015ba77d70 [ 9064.008850] Call Trace: [ 9064.008854] [8198ea2d] dump_stack+0x4e/0x7a [ 9064.008857] [810cbac8] warn_slowpath_common+0x78/0xa0 [ 9064.008858] [810cbba5] warn_slowpath_null+0x15/0x20 [ 9064.008860] [815bdb3d] intel_display_power_put+0x12d/0x160 [ 9064.008862] [8161e084] edp_panel_vdd_off_sync+0xf4/0x1c0 [ 9064.008863] [8161e17f] edp_panel_vdd_work+0x2f/0x40 [ 9064.008866] [810e63be] process_one_work+0x16e/0x480 [ 9064.008868] [810e6cbb] worker_thread+0x11b/0x520 [ 9064.008870] [810e6ba0] ? create_and_start_worker+0x50/0x50 [ 9064.008872] [810ecb24] kthread+0xc4/0xe0 [ 9064.008874] [810eca60] ? kthread_create_on_node+0x170/0x170 [ 9064.008877] [81997e6c] ret_from_fork+0x7c/0xb0 [ 9064.008878] [810eca60] ? kthread_create_on_node+0x170/0x170 [ 9064.008880] ---[ end trace 17f9738f20aec288 ]--- I had multiples of them in my dmesg, however, this seems to fix it: diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 8a1a4fb..4c3249d 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1252,6 +1252,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp *intel_dp) intel_dp-last_power_cycle = jiffies; power_domain = intel_display_port_power_domain(intel_encoder); + intel_display_power_get(dev_priv, power_domain); intel_display_power_put(dev_priv, power_domain); } } @@ -1371,6 +1372,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp) /* We got a reference when we enabled the VDD. */ power_domain = intel_display_port_power_domain(intel_encoder); + intel_display_power_get(dev_priv, power_domain); intel_display_power_put(dev_priv, power_domain); } --- The question however is: Is this the correct approach? Should it be done differently? (This handles the close and open lid usecase, i don't know if there are others, a grep indicated that there might be two more missing...) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG?] 3.16-rc6 ... at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160()
On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote: On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote: Try four, now including CC lists for the intel driver... Could you give a try to the 2 patches at: https://patchwork.kernel.org/patch/4437061/ If these don't fix the issue, could you send a full dmesg log with the drm.debug=14 kernel option set? I will, but the tests will be a bit delayed (earliest tomorrow evening) Thanks, Imre --- Hi again, Playing some more with the new kernel release i noticed this: [ 9064.008821] WARNING: CPU: 3 PID: 22929 at drivers/gpu/drm/i915/intel_pm.c:5997 intel_display_power_put+0x12d/0x160() [ 9064.008822] Modules linked in: uas bnep b43 mac80211 cfg80211 snd_hda_codec_hdmi btusb bluetooth 6lowpan_iphc rfkill snd_hda_codec_cirrus uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops videobuf2_core snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer sdhci_pci snd sdhci soundcore mmc_core bcma [ 9064.008839] CPU: 3 PID: 22929 Comm: kworker/3:2 Tainted: GW 3.16.0-rc6 #23 [ 9064.008840] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B03.1211161133 11/16/2012 [ 9064.008843] Workqueue: events edp_panel_vdd_work [ 9064.008844] 0009 88015ba77d28 8198ea2d [ 9064.008846] 88015ba77d60 810cbac8 8802610b002c 000c7204 [ 9064.008848] 0001 8802610b80f0 8802610b 88015ba77d70 [ 9064.008850] Call Trace: [ 9064.008854] [8198ea2d] dump_stack+0x4e/0x7a [ 9064.008857] [810cbac8] warn_slowpath_common+0x78/0xa0 [ 9064.008858] [810cbba5] warn_slowpath_null+0x15/0x20 [ 9064.008860] [815bdb3d] intel_display_power_put+0x12d/0x160 [ 9064.008862] [8161e084] edp_panel_vdd_off_sync+0xf4/0x1c0 [ 9064.008863] [8161e17f] edp_panel_vdd_work+0x2f/0x40 [ 9064.008866] [810e63be] process_one_work+0x16e/0x480 [ 9064.008868] [810e6cbb] worker_thread+0x11b/0x520 [ 9064.008870] [810e6ba0] ? create_and_start_worker+0x50/0x50 [ 9064.008872] [810ecb24] kthread+0xc4/0xe0 [ 9064.008874] [810eca60] ? kthread_create_on_node+0x170/0x170 [ 9064.008877] [81997e6c] ret_from_fork+0x7c/0xb0 [ 9064.008878] [810eca60] ? kthread_create_on_node+0x170/0x170 [ 9064.008880] ---[ end trace 17f9738f20aec288 ]--- I had multiples of them in my dmesg, however, this seems to fix it: diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 8a1a4fb..4c3249d 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1252,6 +1252,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp *intel_dp) intel_dp-last_power_cycle = jiffies; power_domain = intel_display_port_power_domain(intel_encoder); + intel_display_power_get(dev_priv, power_domain); intel_display_power_put(dev_priv, power_domain); } } @@ -1371,6 +1372,7 @@ void intel_edp_panel_off(struct intel_dp *intel_dp) /* We got a reference when we enabled the VDD. */ power_domain = intel_display_port_power_domain(intel_encoder); + intel_display_power_get(dev_priv, power_domain); intel_display_power_put(dev_priv, power_domain); } --- The question however is: Is this the correct approach? Should it be done differently? (This handles the close and open lid usecase, i don't know if there are others, a grep indicated that there might be two more missing...) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
