Hi all,
adding dri-devel as I found it is actually not completely dead, but hanging in some i915 problem.
Copyied from screen: Process ips-adjust (.... Stack: .... .... ... Call Trace: <IRQ> ... ? tick_program_event call_sortirq do_softirq irq_exit smp_apic_timer_interrupt apic_timer_interrupt <EOI> ? _raw_spin_lock i915_gpu_busy ips_adjust ? show_cpu_temp kthread kernel_thread_helper ? kthread_worker_fn ? gs_change Code: ... (once more more or less the same as above)
Here the original message.
Full logs etc: kernel config: http://www.logic.at/people/preining/lenovo/config.edge dmesg output after boot: http://www.logic.at/people/preining/lenovo/dmesg.edge lsmod, lspci, lsusb http://www.logic.at/people/preining/lenovo/lsmod.edge http://www.logic.at/people/preining/lenovo/lspci.edge http://www.logic.at/people/preining/lenovo/lsusb.edge photo of the hang: http://www.logic.at/people/preining/lenovo/i915-hang-after-resume.jpg
Hope that helps, looking forward to any suggestions
Best wishes
Norbert ------------------------------------------------------------------------ Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org} JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ SCREMBY (n.) The dehydrated felt-tip pen attached by a string to the 'Don't Forget' board in the kitchen which has never worked in living memory but which no one can be bothered to throw away. --- Douglas Adams, The Meaning of Liff
On Fri, 1 Apr 2011 14:15:11 +0900 Norbert Preining preining@logic.at wrote:
Hm, ok so on resume we're checking GPU busyness, which is normal, but end up hanging on the spinlock? Do you see what scrolls by above the text you took a picture of (probably a "task hung" message?).
Does this happen reliably? Does a previous kernel work ok?
On Fr, 01 Apr 2011, Jesse Barnes wrote:
More than what I can see on the screen shot I cannot grasp.
Does this happen reliably? Does a previous kernel work ok?
Reliable: yes Previous: I don't know, but I can try out some older git release. which one do you suggest? (I got the laptop recently so I don't have a long history with that one)
Best wishes
Norbert ------------------------------------------------------------------------ Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org} JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ SCRONKEY (n.) Something that hits the window as a result of a violent sneeze. --- Douglas Adams, The Meaning of Liff
On Sat, 2 Apr 2011 09:24:10 +0900 Norbert Preining preining@logic.at wrote:
Well I'd start with something like 2.6.37, I think that's the first release that had IPS. At least it's good that you can reproduce it easily... Can you add something like this to your kernel to see why the gpu_busy call might be hanging? I'm guessing we hang trying to take the spinlock; if so enabling lockdep debugging might tell us who else took it.
Thanks, Jesse
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 8cb7f93..47fb29a 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1790,14 +1790,18 @@ bool i915_gpu_busy(void) struct drm_i915_private *dev_priv; bool ret = false;
+ DRM_ERROR("entering busy check, trying to take lock\n"); + spin_lock(&mchdev_lock); if (!i915_mch_dev) goto out_unlock; + DRM_ERROR("got lock, returning current busy status\n"); dev_priv = i915_mch_dev;
ret = dev_priv->busy;
out_unlock: + DRM_ERROR("unlock & return\n"); spin_unlock(&mchdev_lock);
return ret;
Hi Jesse, hi everyone,
ok, I give up for now.
On Fr, 01 Apr 2011, Jesse Barnes wrote:
Well I'd start with something like 2.6.37, I think that's the first
2.6.37 suspends and resumes fine, even with X running
Then I recompiled 2.6.39-rc1 with our patch and suspended, resume took 1min (exactely!) and worked out. I got a lot of the warning messages, every five seconds the DRM_ERROR msgs from the patch. [ 52.069753] [drm:i915_gpu_busy] *ERROR* entering busy check, trying to take lock [ 52.071813] [drm:i915_gpu_busy] *ERROR* got lock, returning current busy status [ 52.074233] [drm:i915_gpu_busy] *ERROR* unlock & return [ 57.074194] [drm:i915_gpu_busy] *ERROR* entering busy check, trying to take lock [ 57.076270] [drm:i915_gpu_busy] *ERROR* got lock, returning current busy status [ 57.078717] [drm:i915_gpu_busy] *ERROR* unlock & return
The resume was probably hanging at something different. I am not at the laptop now (travelling with a ifferent laptop), but it was: r8169: cannot apply firmware patch or something similar. It was always ... resume ... 60sec hang ... then this message and "resume of devices completed" or so in the dmesg output.
So I thought it might be that the patch changed a bit of timings but recompiling *without* the patch and rebooting I get now the same behaviour: Suspend and resume works, although hanging for 1min before coming back.
I guess that means we can close that problem for now.
Sorry for the noise. If someone has an ide awhere to search for the "cannot apply firmware patch" problem please let me know.
Thanks and all the best
Norbert
------------------------------------------------------------------------ Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org} JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ TILLICOULTRY (n.) The man-to-man chumminess adopted by an employer as a prelude for telling an employee that he's going to have to let him go. --- Douglas Adams, The Meaning of Liff
dri-devel@lists.freedesktop.org
-
Jesse Barnes -
Norbert Preining -
Peter Stuge