[Bug 15685] New: Kernel 2.6.33 fails to suspend (bisected)

* [Bug 15685] New: Kernel 2.6.33 fails to suspend (bisected)
@ 2010-04-02 19:21 bugzilla-daemon
  2010-04-02 19:30 ` [Bug 15685] " bugzilla-daemon
                   ` (14 more replies)
  0 siblings, 15 replies; 16+ messages in thread
From: bugzilla-daemon @ 2010-04-02 19:21 UTC (permalink / raw)
  To: dri-devel

https://bugzilla.kernel.org/show_bug.cgi?id=15685

           Summary: Kernel 2.6.33 fails to suspend (bisected)
           Product: Drivers
           Version: 2.5
    Kernel Version: 2.6.33
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Video(DRI - non Intel)
        AssignedTo: drivers_video-dri@kernel-bugs.osdl.org
        ReportedBy: nix@esperi.org.uk
        Regression: Yes

Created an attachment (id=25828)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=25828)
Kernel config on crashing machine ('make oldconfig' from working 2.6.32
configuration)

(This is a re-report of fdo bug 26872, because I've seen no evidence that
anyone's looking at fdo DRI bugs at all, but bugs reported to the kernel list
at least get Rafael's scripts looking at them.)

(Crash persists with 2.6.33.2 and the tip of drm-radeon-testing.)

I found to my unhappiness that suspension locks up solid in the atomic
copy/restore phase, on my x86-64 KMS system. There's no need to start X or do
anything 3D, I can reproduce this from a framebuffer console login prompt. The
fault is plainly Radeon KMS's: compile it out and suspension works file.

Nothing is logged on the netconsole, even with verbose PM debugging on.

The graphics card is an HD4870, and suspension mostly worked with it in 2.6.32
(there are circumstances in which TuxOnIce does two suspensions without an
intervening resume, and those have always caused Radeon KMS to lock up).

My attempts to bisect it were somewhat hampered by *another* suspend-resume bug
with similar symptoms (for me, a triple flash of the caps-lock light followed
by a spontaneous reboot, at atomic copy/restore time), fixed by commit
9270eb1b496cb002d75f49ef82c9ef4cbd22a5a0. (The log for this commit helpfully
didn't mention suspend/resume at all, only the fdo bug number, so my grepping
checks were fruitless and I wasted six hours bisecting to a fixed bug. Bah.)

The faulty pair of commits is a regression from a major API rework :/ applying
one but not the other will not compile (obviously). After this commit,
suspension never works, although the failure mode changes a few times.

commit ca262a9998d46196750bb19a9dc4bd465b170ff7
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Tue Dec 8 15:33:32 2009 +0100

    drm/ttm: Rework validation & memory space allocation (V3)

commit 312ea8da049a1830aa50c6e00002e50e30df476e
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Mon Dec 7 15:52:58 2009 +0100

    drm/radeon/kms: Convert radeon to new TTM validation API (V2)

Before these commits, suspension works. Afterwards, instead of suspension I see
a quintuple(?) flash of the caps lock light and a hard reboot. I'm not certain
what this means: a triple fault?

The second change in behaviour, between abrupt reboot on suspend and hard hang,
I haven't yet fully bisected (forty-three reboots in one evening was quite
enough), but it lies in the range
2c761270d5520dd84ab0b4e47c24d99ff8503c38..004b35063296b6772fa72404a35b498f1e71e87e.
In practice I strongly suspect that this is the same bug, manifesting
differently.

Comparison with other Radeon and KMS users indicates that this is almost
certainly r6xx-r7xx-specific. (rv3xx works, r3xx works, Intel works.)

(Well, either that or I'm the only person in the world who's seeing it: I
haven't found anyone else with a r6xx or r7xx who's trying to suspend, yet.)

If there's anything else I can do to help debug a hard lockup like this, please
say. I do have a second machine available to debug the first, but if the first
is *dead* it's hard to do anything...

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--

^ permalink raw reply	[flat|nested] 16+ messages in thread