[Bug 26872] New: Kernel 2.6.33 fails to suspend (semi-bisected)

* [Bug 26872] New: Kernel 2.6.33 fails to suspend (semi-bisected)
@ 2010-03-03 21:37 bugzilla-daemon
  2010-03-03 21:38 ` [Bug 26872] " bugzilla-daemon
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: bugzilla-daemon @ 2010-03-03 21:37 UTC (permalink / raw)
  To: dri-devel

http://bugs.freedesktop.org/show_bug.cgi?id=26872

           Summary: Kernel 2.6.33 fails to suspend (semi-bisected)
           Product: DRI
           Version: XOrg 6.7.0
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Radeon
        AssignedTo: dri-devel@lists.sourceforge.net
        ReportedBy: nix@esperi.org.uk

Created an attachment (id=33739)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33739)
Log of bisection of failure; I believe all but the last few lines, but
repeating those last few bisections dumps me back in the same ridiculous place
again

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 bug number, so my grepping
checks were fruitless and I wasted six hours bisecting to a fixed bug. Bah.)

Unfortunately, my later attempt to bisect to the start of the freeze that I see
in 2.6.33 failed, dumping me on a PowerPC commit. It's all completely
reproducible -- bisection log attached -- but I'm sufficiently unconfident of
it that I'll reproduce it again tomorrow with a few skips in there to see if I
get any better results. (It *is* clear that I see a working 2.6.32, then f.d.o
bug 25733, then a period of working suspend, and then a period of hard lockup
which persists until 2.6.33.)

If there's anything 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: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for 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] 8+ messages in thread