| Summary: | [SNB] gtfifodbg WARN_ON triggered on suspend | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Ben Widawsky <ben> | ||||||
| Component: | DRM/Intel | Assignee: | Ben Widawsky <ben> | ||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||
| Severity: | minor | ||||||||
| Priority: | medium | CC: | ben, chris, daniel, jbarnes, wrar | ||||||
| Version: | unspecified | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
Ben Widawsky
2012-04-20 13:55:08 UTC
I've managed to hit this once on my snb, but now fail to reproduce. The same here on my ASUS K53E every time I suspend with X running even if it's just kdm login prompt. No visible problems after resuming. Is it always the IPS function i915_update_gfx_val? Could it just be that the chipset if unhappy with us writing to this bogus register, or is it merely just frequent enough to be blamed most of the time? (In reply to comment #3) > Is it always the IPS function i915_update_gfx_val? Could it just be that the > chipset if unhappy with us writing to this bogus register, or is it merely just > frequent enough to be blamed most of the time? For me at least it seems it's always this backtrace. I only get 2 per suspend/resume; so I doubt it's a frequency thing. (In reply to comment #3) > Is it always the IPS function i915_update_gfx_val? Could it just be that the > chipset if unhappy with us writing to this bogus register, or is it merely just > frequent enough to be blamed most of the time? I get two WARNINGs in each suspend/resume. The first one looks like the one included in the first message and contains i915_update_gfx_val: [<ffffffff8102a5c1>] warn_slowpath_common+0x7e/0x96 [<ffffffff8102a66d>] warn_slowpath_fmt+0x41/0x43 [<ffffffffa01e03b7>] gen6_gt_check_fifodbg.isra.5+0x31/0x44 [i915] [<ffffffffa01e062e>] __gen6_gt_force_wake_put+0x19/0x1b [i915] [<ffffffffa01e0884>] i915_read32+0x61/0x82 [i915] [<ffffffffa01fa1f6>] ? intel_disable_plane+0x60/0x60 [i915] [<ffffffffa01e27ea>] i915_update_gfx_val+0x61/0xb9 [i915] [<ffffffffa01fa23b>] intel_idle_update+0x45/0x18b [i915] [<ffffffff810463e9>] ? need_resched+0x1e/0x28 [<ffffffffa01fa1f6>] ? intel_disable_plane+0x60/0x60 [i915] [<ffffffff8103c29e>] process_one_work+0x13c/0x21e [<ffffffff8103cb9f>] worker_thread+0xce/0x152 [<ffffffff8103cad1>] ? manage_workers.isra.28+0x16c/0x16c [<ffffffff8103ffb7>] kthread+0x86/0x8e [<ffffffff812f2054>] kernel_thread_helper+0x4/0x10 [<ffffffff8103ff31>] ? kthread_freezable_should_stop+0x3e/0x3e [<ffffffff812f2050>] ? gs_change+0xb/0xb The second one is different but occurs at the same source line: [<ffffffff8102a5c1>] warn_slowpath_common+0x7e/0x96 [<ffffffff8102a66d>] warn_slowpath_fmt+0x41/0x43 [<ffffffffa01e03b7>] gen6_gt_check_fifodbg.isra.5+0x31/0x44 [i915] [<ffffffffa01e062e>] __gen6_gt_force_wake_put+0x19/0x1b [i915] [<ffffffffa01e0884>] i915_read32+0x61/0x82 [i915] [<ffffffffa01fa293>] intel_idle_update+0x9d/0x18b [i915] [<ffffffffa01fa1f6>] ? intel_disable_plane+0x60/0x60 [i915] [<ffffffff8103c29e>] process_one_work+0x13c/0x21e [<ffffffff8103cb9f>] worker_thread+0xce/0x152 [<ffffffff8103cad1>] ? manage_workers.isra.28+0x16c/0x16c [<ffffffff8103ffb7>] kthread+0x86/0x8e [<ffffffff812f2054>] kernel_thread_helper+0x4/0x10 [<ffffffff8103ff31>] ? kthread_freezable_should_stop+0x3e/0x3e [<ffffffff812f2050>] ? gs_change+0xb/0xb Created attachment 60883 [details] [review] only enable ips polling on ilk Please test this patch. (In reply to comment #6) > Created attachment 60883 [details] [review] [review] > only enable ips polling on ilk > > Please test this patch. The first WARNING disappeared but the second one still happens. Created attachment 60890 [details] [review] Don't read the non-existent DPLL register on ILK+ (In reply to comment #8) > Created attachment 60890 [details] [review] [review] > Don't read the non-existent DPLL register on ILK+ This patch removes the second WARNING. Both patches are merged to -fixes and should land in 3.4-rc6 soon: commit e90f3b61f4432e3c5bb6b57f4b3e8d8cba747541 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 30 19:35:02 2012 +0100 drm/i915: Only enable IPS polling for gen5 On SandyBridge IPS was entirely implemented in hardware and not reliant on the driver monitoring power consumption and feeding back desired run states, so the hardware is able to adapt quicker and more flexibly. Which is a huge relief for us as we no longer have to carry empirically derived magic algorithms. Yet despite the advance in technology, the driver was still doing its IPS polling on all machines. Restrict it to the only supported hardware, Clarkdale/Arrandale. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49025 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> commit 074b5e1a99fb5017122591d70098601e0484ca6a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed May 2 12:07:06 2012 +0100 drm/i915: Do not read non-existent DPLL registers on PCH hardware We only execute intel_decrease_pllclock for pre-PCH hardware, typically gen4 mobiles. However, in the variable declaration we did read from the non-PCH DPLL register, quite naughty and detected by SandyBridge. Reported-and-tested-by: Andrey Rahmatullin <wrar@wrar.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49025 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.