Bug 26872

Created attachment 33739 [details]
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...