On Tue, Aug 21, 2012 at 8:33 PM, Daniel Vetter wrote: > On Tue, Aug 21, 2012 at 08:20:35PM +0200, Sedat Dilek wrote: >> On Tue, Aug 21, 2012 at 6:39 PM, Daniel Vetter wrote: >> > On Tue, Aug 21, 2012 at 3:24 PM, Sedat Dilek wrote: >> >> On Tue, Aug 21, 2012 at 1:53 PM, Daniel Vetter wrote: >> >>> On Tue, Aug 21, 2012 at 1:14 PM, Sedat Dilek wrote: >> >>>> On Tue, Aug 21, 2012 at 1:03 PM, Sedat Dilek wrote: >> >>>>> On Tue, Aug 21, 2012 at 1:02 PM, Sedat Dilek wrote: >> >>>>>> On Tue, Aug 21, 2012 at 8:04 AM, Stephen Rothwell wrote: >> >>>>>>> Hi all, >> >>>>>>> >> >>>>>>> Changes since 20120820: >> >>>>>>> >> >>>>>>> The rr tree gained a conflict against Linus' tree. >> >>>>>>> >> >>>>>>> The tip tree still has its build failure so I used the version from >> >>>>>>> next-20120814. >> >>>>>>> >> >>>>>>> The workqueues tree gained a conflict against the hid tree. >> >>>>>>> >> >>>>>>> The drivers-x86 tree still has its build failure so I used the version >> >>>>>>> from next-20120817. >> >>>>>>> >> >>>>>>> The signal tree gained a conflict against Linus' tree. I have still >> >>>>>>> reverted 3 commits from the signal tree at the request of the arm >> >>>>>>> maintainer. >> >>>>>>> >> >>>>>>> ---------------------------------------------------------------------------- >> >>>>>>> >> >>>>>> >> >>>>>> Hi, >> >>>>>> >> >>>>>> I have compiled linux-next (next-20120821) and see the attached >> >>>>>> call-trace when suspending. >> >>>>>> Suspending did NOT work (Xorg seems to cause it) - machine came back to desktop. >> >>>>>> >> >>>>>> With yesterday's next-20120820 I haven't seen this. >> >>>>>> >> >>>>>> I am not sure what is this causing... PM, x86/sched or even VFS? >> >>>>>> Any help for debugging appreciated. >> >>>>>> >> >>>>>> I am on Ubuntu/precise AMD64 and use systemd-v43 as init-system. >> >>>>>> >> >>>>>> Regards, >> >>>>>> - Sedat - >> >>>>> >> >>>>> Forgot attachment! >> >>>>> If you don't succeed - try try try... >> >>>>> >> >>>>> - Sedat - >> >>>> >> >>>> [ CC danvet ] >> >>>> >> >>>> I have pulled in drm-intel-fixes into my local GIT tree and rebuilt >> >>>> i915 - this seems to fix the problem. >> >>>> Daniel any suggestion which patch in d-i-f did it? >> >>> >> >>> Without the backtrace it's kinda hard to tell ... Also, if you can >> >>> dump a git log of the commits from -fixes that you don't yet have. >> >>> -Daniel >> >>> >> >> >> >> Hi Daniel, >> >> >> >> $ git log --oneline v3.6.0-rc2-next20120821-1-iniza-generic..drm-intel-fixes >> >> 1ee9ae3 drm/i915: use hsw rps tuning values everywhere on gen6+ >> >> f1a2f5b drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads >> >> 4eab813 drm/i915: extract connector update from intel_ddc_get_modes() for reuse >> >> a843af1 drm/i915: fix hsw uncached pte >> >> b6c7488 drm/i915/contexts: fix list corruption >> >> 38ab8a2 drm/i915: fix EDID memory leak in SDVO >> >> >> >> Looks like "1ee9ae3 drm/i915: use hsw rps tuning values everywhere on >> >> gen6+" has PM fixes for i915. >> >> >> >> I tried with only that patch on top of today's linux-next - and I can >> >> suspend/resume again! >> > >> > Well, this is slightly shocking - this patch /should/ only optimize >> > power consumption, it should in now way fix suspend/resume (i.e. it >> > doesn't even apply any h/w workaround). Do you have any more details >> > what's going wrong here (logs, ...)? >> > >> >> Forgot to CC you on my 1st emails. >> [2] has the call-trace I have seen. >> >> - Sedat - >> >> [2] http://marc.info/?l=linux-next&m=134554704504603&w=2 > > Hm, that smells more like a race, and changing the gpu turbo settins is > known to rather massively move such races around (since this affects the > power consumption and hence also max cpu turbo states, besides massively > changing wakeup latency, since only when the gpu is in rc6 the entire > cpu+gpu package can go into the lowest power state). > > I'd wager this thing will pop up again :( I have re-installed the problematic kernel. After 3 suspends I could twice resume successfully. I have attached both kern-logs (1st reported call-trace, 2nd new one). First was caused by Xorg and the 2nd by aptd. $ sudo grep -A1 "Freezing of tasks failed after" /var/log/kern.log Aug 21 12:53:18 fambox kernel: [ 2569.853137] Freezing of tasks failed after 20.00 seconds (1 tasks refusing to freeze, wq_busy=0): Aug 21 12:53:18 fambox kernel: [ 2569.853151] Xorg D 0000000000000000 0 762 724 0x00400004 -- Aug 21 20:37:46 fambox kernel: [ 125.031876] Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0): Aug 21 20:37:46 fambox kernel: [ 125.031909] aptd D ffffffff8180cd00 0 2071 1 0x00000004 IIRC PM is now async? - Sedat - > -Daniel > -- > Daniel Vetter > Mail: daniel@ffwll.ch > Mobile: +41 (0)79 365 57 48