From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 26872] New: Kernel 2.6.33 fails to suspend (semi-bisected) Date: Wed, 3 Mar 2010 13:37:46 -0800 (PST) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.sourceforge.net To: dri-devel@lists.sourceforge.net List-Id: dri-devel@lists.freedesktop.org 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® 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 --