[lkml]   [2011]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume_
    On Wed, Feb 9, 2011 at 10:56 AM, Indan Zupancic <> wrote:
    > On Wed, February 9, 2011 02:05, Jeff Chua wrote:
    >> On Wed, Feb 9, 2011 at 8:55 AM, Jeff Chua <> wrote:
    >>> And the console hangs even without starting X.
    >> I went back to retry suspending without starting X and realized that
    >> it's only the "screen" that's hang .. and that's without drm and i915
    >> loaded.
    > According to the dmesg you sent, you do have drm (and probably i915 too) loaded.
    > It seems the hang is the first bit, and then you rebooted into X to capture the
    > log.
    > Perhaps relevant message (probably not):
    > "No ACPI video bus found"
    >> On the console, I could still reboot the machine normally, but
    >> not when in X (everything hangs including keybard).
    >> Here's the kernel log without X.
    >> Thanks.
    >> Jeff
    > Looking at the commit, all it does is changing the timing.
    > It used to set active to true when intel_crtc_init() was called, but now
    > it does it always when the drm reset() callback is called.
    > intel_crtc->active = true; /* force the pipe off on setup_init_config */
    > I can't find a setup_init_config anywhere, but looking at the other code
    > it assumes that *_crtc_disable() will be called just after the forced true.
    > All in all it seems quite wrong, no matter if it happens to work, because
    > it depends on the calling order done by the drm layer. If *_crtc_enable()
    > is called instead it won't do anything because of that active = true thing.
    > This seems to be happening in your case.
    > So I'd get rid of that dodgy active = true assignment altogether. Isn't
    > the introduction of the reset() callback done to avoid exactly this kind
    > of subtle state fiddling? And removing it might solve the original problem
    > that the move tried to fix as well.
    > I can't check the rest of the code as I'm still on patched 37 (won't move
    > till the fix for bug 23472 is upstream), but my gut feeling is that removing
    > that weird active = true will solve most problems.

    This may help a little. I added printk("intel_crtc 2") inside
    intel_crtc_reset() and added printk("intel_crtc 1") before calling

    Looking at dmesg, it looks like something else is calling
    intel_crtc_reset() and not from intel_crtc_init() during resume.

    intel_crtc 2 ffff880239cdf000
    intel_crtc 2 ffff880239cdf800


     \ /
      Last update: 2011-02-09 06:47    [W:0.023 / U:9.764 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site