Dear all,
I got a new laptop, Lenovo Thinkpad Edge (intel , intel graphic)
and I am running 2.6.39-rc1 on it (but tried also 2.6.38).
Suspend to RAM, either by pm-suspend or by echo "mem" >/sys/..
works, both wiht running or from a recovery session where nothing
else is running.
But wake-up hangs the machine. The video comes back, I see the last
lines I typed before I suspended, but after that no keypress nor
anything else (Sysrq) does work, but 4sec-hard-off. No traces in the
log files.
ANy suggestions how to proceed and debug that?
Thanks a lot 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
------------------------------------------------------------------------
ARDSCALPSIE (n.)
Excuse made by rural Welsh hairdresser for completely massacring your
hair.
--- Douglas Adams, The Meaning of Liff
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.
> I got a new laptop, Lenovo Thinkpad Edge (intel , intel graphic)
> and I am running 2.6.39-rc1 on it (but tried also 2.6.38).
>
> Suspend to RAM, either by pm-suspend or by echo "mem" >/sys/..
> works, both wiht running or from a recovery session where nothing
> else is running.
>
> But wake-up hangs the machine. The video comes back, I see the last
> lines I typed before I suspended, but after that no keypress nor
> anything else (Sysrq) does work, but 4sec-hard-off. No traces in the
> log files.
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 <[email protected]> wrote:
> 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)
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?
--
Jesse Barnes, Intel Open Source Technology Center
On Fr, 01 Apr 2011, Jesse Barnes wrote:
> > 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)
>
> 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?).
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 <[email protected]> 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?).
>
> 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)
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;
Norbert Preining wrote:
> > Do you see what scrolls by above the text you took a picture of
>
> More than what I can see on the screen shot I cannot grasp.
Maybe try serial console, netconsole or usb debug device.
//Peter
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
