(In reply to comment #0)
> Created attachment 60299 [details]
> Kernel logs for a full working day, ending in failure to suspend-to-disk
> 
> Occasionally suspend-to-disk will fail, leaving the laptop with a black screen,
> getting very hot (fan starts to ramp up to maximum speed). Suspend-to-ram seems
> unaffected, and always works.
> 
> The issue has been present with every kernel I've used on this laptop,
> which goes back almost one year. Recent kernels which I have used include 
> 3.0.0, 3.1.0, 3.2.0, 3.2.6, 3.3.0, and now 3.4.0-rc2.
> 
> This seems unrelated to RC6, or to the failures to resume (bug #48912), and
> happens with both RC6 on and off.
> 
> 
> 
> Hardware is Dell XPS 15 (L502x) with:
> 00:02.0 VGA compatible controller: Intel Corporation Device 0116 (rev 09)
> [    13.803] (II) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge
> Mobile (GT2)
> 
> Software versions (current):
> xf86-video-intel: fd81408b978c9b57c046ee43d2d32e1370e83a7d
> xorg-server: 1.11.2-r2
> kernel: 3.4-rc2
> 
> I'm attaching yesterday's kernel messages, which ended in a suspend failure.
> Note that the next item to appear in the logs is the laptop booting this
> morning (not included).

I experienced this again yesterday with kernel 3.4.0-rc6-00197-ga98e48e (v3.4-rx6 + drm-intel-next + the rps patch from bug #48912), so that patch doesn't seem to fix this issue. I checked the system logs again, and there still was nothing in there.

Looks like i915 is getting suspended (the "suspend of devices complete after 1128.954 msecs" seems to indicate that at least).

We can try to be sure though by removing the i915 device.  Can you try using a stress script like http://ubuntu.5.n6.nabble.com/PATCH-0-1-Jaunty-suspend-resume-stress-test-scripts-td368223.html and isolate which module might be breaking things?  It could also be an ACPI bug, in which case a BIOS upgrade may help...

(In reply to comment #2)
> Looks like i915 is getting suspended (the "suspend of devices complete after
> 1128.954 msecs" seems to indicate that at least).
> 
> We can try to be sure though by removing the i915 device.  Can you try using
> a stress script like
> http://ubuntu.5.n6.nabble.com/PATCH-0-1-Jaunty-suspend-resume-stress-test-
> scripts-td368223.html and isolate which module might be breaking things?  It
> could also be an ACPI bug, in which case a BIOS upgrade may help...

I don't have any modules, except for 'bbswitch'. This is because everything is compiled into the kernel. Would doing a hibernate-stresstest without X running be of any help in pin-pointing the problem?

The BIOS is at the the second-to-last version (at least, it was the second-to-last version the last time I checked). This is because of a power-management bug, which is (hopefully) almost resolved. After that I will test the newer version of the BIOS again, however it appeared that windows might also have had a higher power consumption under that BIOS, in which case I will need stick with my current BIOS version.

Sorry, this bug seems to have been neglegted a bit. Are you still seeing this with recent kernels?

If yes, please try drm-intel-nightly branch of git://people.freedesktop.org/~danvet/drm. Attach dmesg with drm.debug=0xe parameter set.

Also worth checking is building i915 as module; while built-in should of course work it doesn't get nearly as much test coverage as module.

(In reply to comment #4)
> Sorry, this bug seems to have been neglegted a bit. Are you still seeing
> this with recent kernels?
> 
> If yes, please try drm-intel-nightly branch of
> git://people.freedesktop.org/~danvet/drm. Attach dmesg with drm.debug=0xe
> parameter set.
> 
> Also worth checking is building i915 as module; while built-in should of
> course work it doesn't get nearly as much test coverage as module.

Da Fox, ping for test.

Cause unknown.