On Tue, 20 Jan 2009, Jesse Barnes wrote: > > On Monday, January 19, 2009 8:56 pm Linus Torvalds wrote: > > On Mon, 19 Jan 2009, Jesse Barnes wrote: > > > Is i915 loaded? Hopefully you can suspend/resume in text mode using its > > > suspend/resume code w/o using the s3_bios stuff? > > > > You're right, that works fine. So text-mode suspends and (immediately) > > resumes without any issues, multiple times. But X doesn't. The second > > resume will just hang when X re-initializes (sometimes I see the cursor, > > so I know X actually started up) > > Getting register dumps before and after resume (and also preferably before and > after X VT switches) might help us figure out what's going on (sounds like > the driver's VT enter routine is broken somehow)... So just looking at the Xorg.0.log after rebooting, I can tell that the failure looks to be around the time when we do the DRI mapping. A successful suspend-resume cycle will look like: ... (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): Existing errors found in hardware state. (II) intel(0): using SSC reference clock of 100 MHz (II) intel(0): Selecting standard 18 bit TMDS pixel format. (II) intel(0): Output configuration: (II) intel(0): Pipe A is off (II) intel(0): Display plane A is now disabled and connected to pipe A. (II) intel(0): Pipe B is on (II) intel(0): Display plane B is now enabled and connected to pipe B. (II) intel(0): Output VGA is connected to pipe none (II) intel(0): Output LVDS is connected to pipe B (II) intel(0): [drm] mapped front buffer at 0xd1000000, handle = 0xd1000000 (II) intel(0): [drm] mapped back buffer at 0xd0c00000, handle = 0xd0c00000 (II) intel(0): [drm] mapped depth buffer at 0xd0800000, handle = 0xd0800000 (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. ... and an unsuccessful one will always get stuck before it logs that "[drm] mapped front buffer" thing, but after doing the "Output LVDS is connected to pipe B". I checked a couple of times - the log always ended at that same place. No interesting kernel logs survive this thing (and it's obviously in graphics mode, so I can't see any oops if any), so I can't tell what happens. But it looks DRI-related. And btw, I was wrong - it's not always on the second suspend. It's happened on the first suspends too. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
