2012-08-21 11:02:51

by Sedat Dilek

[permalink] [raw]
Subject: Re: inux-next: Tree for Aug 21 (call-trace when suspending: PM?)

On Tue, Aug 21, 2012 at 8:04 AM, Stephen Rothwell <[email protected]> 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 -


2012-08-21 11:04:07

by Sedat Dilek

[permalink] [raw]
Subject: Re: inux-next: Tree for Aug 21 (call-trace when suspending: PM?)

On Tue, Aug 21, 2012 at 1:02 PM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 21, 2012 at 8:04 AM, Stephen Rothwell <[email protected]> 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 -


Attachments:
CALL-TRACE_PM-related_3.6.0-rc2-next20120821-1-iniza-generic.txt (3.76 kB)

2012-08-21 11:14:40

by Sedat Dilek

[permalink] [raw]
Subject: Re: inux-next: Tree for Aug 21 (call-trace when suspending: PM?)

On Tue, Aug 21, 2012 at 1:03 PM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 21, 2012 at 1:02 PM, Sedat Dilek <[email protected]> wrote:
>> On Tue, Aug 21, 2012 at 8:04 AM, Stephen Rothwell <[email protected]> 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?

[1] http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-fixes

2012-08-21 11:53:14

by Daniel Vetter

[permalink] [raw]
Subject: Re: inux-next: Tree for Aug 21 (call-trace when suspending: PM?)

On Tue, Aug 21, 2012 at 1:14 PM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 21, 2012 at 1:03 PM, Sedat Dilek <[email protected]> wrote:
>> On Tue, Aug 21, 2012 at 1:02 PM, Sedat Dilek <[email protected]> wrote:
>>> On Tue, Aug 21, 2012 at 8:04 AM, Stephen Rothwell <[email protected]> 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

>
> [1] http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-fixes



--
Daniel Vetter
[email protected] - +41 (0) 79 364 57 48 - http://blog.ffwll.ch

2012-08-21 13:24:37

by Sedat Dilek

[permalink] [raw]
Subject: Re: inux-next: Tree for Aug 21 (call-trace when suspending: PM?)

On Tue, Aug 21, 2012 at 1:53 PM, Daniel Vetter <[email protected]> wrote:
> On Tue, Aug 21, 2012 at 1:14 PM, Sedat Dilek <[email protected]> wrote:
>> On Tue, Aug 21, 2012 at 1:03 PM, Sedat Dilek <[email protected]> wrote:
>>> On Tue, Aug 21, 2012 at 1:02 PM, Sedat Dilek <[email protected]> wrote:
>>>> On Tue, Aug 21, 2012 at 8:04 AM, Stephen Rothwell <[email protected]> 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!

$ git log --oneline
v3.6.0-rc2-next20120821-1-iniza-generic..drm-intel-fixes-1ee9ae3
88eb888 drm/i915: use hsw rps tuning values everywhere on gen6+

Hope this helps others - sorry for bothering other maintainers.

- Sedat -

>>
>> [1] http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-fixes
>
>
>
> --
> Daniel Vetter
> [email protected] - +41 (0) 79 364 57 48 - http://blog.ffwll.ch


Attachments:
0001-drm-i915-use-hsw-rps-tuning-values-everywhere-on-gen.patch (3.18 kB)

2012-08-21 16:39:18

by Daniel Vetter

[permalink] [raw]
Subject: Re: inux-next: Tree for Aug 21 (call-trace when suspending: PM?)

On Tue, Aug 21, 2012 at 3:24 PM, Sedat Dilek <[email protected]> wrote:
> On Tue, Aug 21, 2012 at 1:53 PM, Daniel Vetter <[email protected]> wrote:
>> On Tue, Aug 21, 2012 at 1:14 PM, Sedat Dilek <[email protected]> wrote:
>>> On Tue, Aug 21, 2012 at 1:03 PM, Sedat Dilek <[email protected]> wrote:
>>>> On Tue, Aug 21, 2012 at 1:02 PM, Sedat Dilek <[email protected]> wrote:
>>>>> On Tue, Aug 21, 2012 at 8:04 AM, Stephen Rothwell <[email protected]> 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, ...)?

Thanks, Daniel
--
Daniel Vetter
[email protected] - +41 (0) 79 364 57 48 - http://blog.ffwll.ch

2012-08-21 18:20:44

by Sedat Dilek

[permalink] [raw]
Subject: Re: inux-next: Tree for Aug 21 (call-trace when suspending: PM?)

On Tue, Aug 21, 2012 at 6:39 PM, Daniel Vetter <[email protected]> wrote:
> On Tue, Aug 21, 2012 at 3:24 PM, Sedat Dilek <[email protected]> wrote:
>> On Tue, Aug 21, 2012 at 1:53 PM, Daniel Vetter <[email protected]> wrote:
>>> On Tue, Aug 21, 2012 at 1:14 PM, Sedat Dilek <[email protected]> wrote:
>>>> On Tue, Aug 21, 2012 at 1:03 PM, Sedat Dilek <[email protected]> wrote:
>>>>> On Tue, Aug 21, 2012 at 1:02 PM, Sedat Dilek <[email protected]> wrote:
>>>>>> On Tue, Aug 21, 2012 at 8:04 AM, Stephen Rothwell <[email protected]> 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

> Thanks, Daniel
> --
> Daniel Vetter
> [email protected] - +41 (0) 79 364 57 48 - http://blog.ffwll.ch

2012-08-21 18:32:45

by Daniel Vetter

[permalink] [raw]
Subject: Re: inux-next: Tree for Aug 21 (call-trace when suspending: PM?)

On Tue, Aug 21, 2012 at 08:20:35PM +0200, Sedat Dilek wrote:
> On Tue, Aug 21, 2012 at 6:39 PM, Daniel Vetter <[email protected]> wrote:
> > On Tue, Aug 21, 2012 at 3:24 PM, Sedat Dilek <[email protected]> wrote:
> >> On Tue, Aug 21, 2012 at 1:53 PM, Daniel Vetter <[email protected]> wrote:
> >>> On Tue, Aug 21, 2012 at 1:14 PM, Sedat Dilek <[email protected]> wrote:
> >>>> On Tue, Aug 21, 2012 at 1:03 PM, Sedat Dilek <[email protected]> wrote:
> >>>>> On Tue, Aug 21, 2012 at 1:02 PM, Sedat Dilek <[email protected]> wrote:
> >>>>>> On Tue, Aug 21, 2012 at 8:04 AM, Stephen Rothwell <[email protected]> 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 :(
-Daniel
--
Daniel Vetter
Mail: [email protected]
Mobile: +41 (0)79 365 57 48

2012-08-21 18:52:49

by Sedat Dilek

[permalink] [raw]
Subject: Re: inux-next: Tree for Aug 21 (call-trace when suspending: PM?)

On Tue, Aug 21, 2012 at 8:33 PM, Daniel Vetter <[email protected]> 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 <[email protected]> wrote:
>> > On Tue, Aug 21, 2012 at 3:24 PM, Sedat Dilek <[email protected]> wrote:
>> >> On Tue, Aug 21, 2012 at 1:53 PM, Daniel Vetter <[email protected]> wrote:
>> >>> On Tue, Aug 21, 2012 at 1:14 PM, Sedat Dilek <[email protected]> wrote:
>> >>>> On Tue, Aug 21, 2012 at 1:03 PM, Sedat Dilek <[email protected]> wrote:
>> >>>>> On Tue, Aug 21, 2012 at 1:02 PM, Sedat Dilek <[email protected]> wrote:
>> >>>>>> On Tue, Aug 21, 2012 at 8:04 AM, Stephen Rothwell <[email protected]> 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: [email protected]
> Mobile: +41 (0)79 365 57 48


Attachments:
CALL-TRACE_kern-log_1.txt (5.46 kB)
CALL-TRACE_kern-log_2.txt (7.24 kB)
Download all attachments