Created attachment 61491 [details]
dmesg output before suspend

Created attachment 61492 [details]
Xorg.log (wake up from suspend happends at 1717.165

Created attachment 61493 [details]
intel_reg_dumper output before suspend

Created attachment 61494 [details]
intel_reg_dumper output after suspend

Created attachment 61495 [details]
VBIOS dump after suspend

Created attachment 61496 [details]
VBIOS dump before suspend

For starters, you've hit the race between upowerd (go and bug Ubuntu for using such an obsolete version) and resume. That race will only be fixed in 3.4, so you may as well try the experimental drm-intel-next from the xorg-edgers ppa for even more 8xx bug fixes.

Created attachment 61507 [details]
Xorg.log (from xorg-edgers ppa)

Created attachment 61508 [details]
dmesg (from xorg-edgers ppa)

Thanks for your prompt answer. I tried installing packages from the xorg-edgers ppa (including kernel-3.4) but unfortunately the symptoms are still the same (see new attachements).

[  159.984121] ------------[ cut here ]------------
[  159.984234] WARNING: at /build/buildd/linux-3.4.0/drivers/gpu/drm/i915/intel_display.c:994 assert_planes_disabled+0xc7/0x130 [i915]()
[  159.984241] Hardware name: 26724BG
...

Is there something else one could try? Like compiling the latest version of upowerd or applying some patches against kernel-3.4? I'm really not afraid to get my hands dirty.

You could try the drm-intel-next-queued branch, ubuntu has ppa packages of that at http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/current/

Tried that too. Unfortunately with the kernel from that PPA I can't event boot into XFCE. The backlight is on but the screen remains black. According to dmesg there seem to be some EDID problems.

Created attachment 61515 [details]
dmesg output for drm-intel-experimental

GMBUS is just returning garbage; probably best to either quirk it off again for i830. Should we add a module parameter to force gpio?

If it has a potential to fix standby problems with i830M, I'd be eager to test your patches. Are there kernel sources for 
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/current/
somewhere? In that case I could compile just the i915 module with your patches without compiling the whole kernel.

Also, forgive my ignorance, but could you elaborate a bit on the ForceEnablePipeA
option, which got removed when i915 switched to KMS completely? It's just that on some pages this option was recommended as a fix for suspend problems on older Intel chips, for example here
https://wiki.ubuntu.com/X/Quirks#Force_Pipe_A_Quirk
or here
http://www.thinkwiki.org/wiki/Problem_with_display_remaining_black_after_resume#Solution_for_ThinkPads_with_Intel_I830_Chipset

So I'm just wondering how that option in the current i915 builds.

*how that option in the current i915 builds.
how that option is handled in the current i915 builds.

Created attachment 61517 [details] [review]
disable gmbus on i830

Ok, it's time to break out the compiler. Please grab the latest drm-intel-next-queued branch from http://cgit.freedesktop.org/~danvet/drm-intel/ and apply this patch.

btw, the git branch I've pointed you it as what the drm-intel-experimental kernel is built from. The ForcePipeA option is the same as the quirk you've noticed, so setting that one should be unnecessary for your machine.

Thanks for the patch, but it looks like there might be something missing, provided that I applied everything correctly.

Here's what I did:

git clone -b drm-intel-next-queued git://people.freedesktop.org/~danvet/drm-intel
cd drm-intel
wget https://bugs.freedesktop.org/attachment.cgi?id=61517 -O i915_patch
patch -p1 < i915_patch
cd ..
mkdir my_i915
cd my_i915
cp /usr/src/linux-headers-3.4.0-994-generic-pae/Module.symvers .
cp /boot/config-3.4.0-994-generic-pae .config
cd ../drm-intel/
make EXTRAVERSION=-994-generic-pae O=../my_i915 oldconfig
make EXTRAVERSION=-994-generic-pae O=../my_i915 prepare
make EXTRAVERSION=-994-generic-pae O=../my_i915 outputmakefile
make EXTRAVERSION=-994-generic-pae O=../my_i915 archprepare
make EXTRAVERSION=-994-generic-pae O=../my_i915 modules SUBDIRS=scripts
grep 'gmbus seems to be broken on i830' drivers/gpu/drm/i915/intel_i2c.c
make EXTRAVERSION=-994-generic-pae O=../my_i915 modules SUBDIRS=drivers/gpu/drm/i915

Everything works well, until I really start compiling the patched module.
Output of the last make:

  CC [M]  drivers/gpu/drm/i915/i915_drv.o
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_drv.c: In function '__check_fbpercrtc':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_drv.c:48:1: warning: pointer targets in return differ in signedness [-Wpointer-sign]
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_drv.c: In function '__check_powersave':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_drv.c:57:1: warning: pointer targets in return differ in signedness [-Wpointer-sign]
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_drv.c: In function '__check_lvds_downclock':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_drv.c:82:1: warning: pointer targets in return differ in signedness [-Wpointer-sign]
  CC [M]  drivers/gpu/drm/i915/i915_dma.o
  CC [M]  drivers/gpu/drm/i915/i915_irq.o
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_irq.c: In function 'gen6_pm_rps_work':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_irq.c:354:14: warning: variable 'pm_imr' set but not used [-Wunused-but-set-variable]
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_irq.c: In function 'valleyview_irq_handler':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_irq.c:458:7: warning: variable 'blc_event' set but not used [-Wunused-but-set-variable]
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_irq.c:456:6: warning: variable 'vblank_status' set but not used [-Wunused-but-set-variable]
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_irq.c: In function 'i8xx_irq_handler':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_irq.c:2022:6: warning: variable 'irq_received' set but not used [-Wunused-but-set-variable]
  CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
  CC [M]  drivers/gpu/drm/i915/i915_suspend.o
  CC [M]  drivers/gpu/drm/i915/i915_gem.o
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_pwrite_ioctl':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_gem.c:863:5: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
  CC [M]  drivers/gpu/drm/i915/i915_gem_debug.o
  CC [M]  drivers/gpu/drm/i915/i915_gem_evict.o
  CC [M]  drivers/gpu/drm/i915/i915_gem_execbuffer.o
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_gem_execbuffer.c: In function 'i915_gem_do_execbuffer.isra.7':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/i915_gem_execbuffer.c:941:6: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
/home/vs/drm-intel-experimental/drm-intel/include/linux/pagemap.h:492:6: note: 'ret' was declared here
  CC [M]  drivers/gpu/drm/i915/i915_gem_gtt.o
  CC [M]  drivers/gpu/drm/i915/i915_gem_stolen.o
  CC [M]  drivers/gpu/drm/i915/i915_gem_tiling.o
  CC [M]  drivers/gpu/drm/i915/i915_sysfs.o
  CC [M]  drivers/gpu/drm/i915/i915_trace_points.o
  CC [M]  drivers/gpu/drm/i915/intel_display.o
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_display.c: In function 'ironlake_get_refclk':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_display.c:4256:24: warning: variable 'edp_encoder' set but not used [-Wunused-but-set-variable]
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_display.c: In function 'ironlake_crtc_mode_set':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_display.c:4309:27: warning: variable 'is_pch_edp' set but not used [-Wunused-but-set-variable]
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_display.c:4299:7: warning: variable 'is_crt' set but not used [-Wunused-but-set-variable]
  CC [M]  drivers/gpu/drm/i915/intel_crt.o
  CC [M]  drivers/gpu/drm/i915/intel_lvds.o
  CC [M]  drivers/gpu/drm/i915/intel_bios.o
  CC [M]  drivers/gpu/drm/i915/intel_ddi.o
  CC [M]  drivers/gpu/drm/i915/intel_dp.o
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_start_link_train':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_dp.c:1682:7: warning: variable 'clock_recovery' set but not used [-Wunused-but-set-variable]
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_complete_link_train':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_dp.c:1793:7: warning: variable 'channel_eq' set but not used [-Wunused-but-set-variable]
  CC [M]  drivers/gpu/drm/i915/intel_hdmi.o
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_hdmi.c: In function 'intel_hdmi_set_spd_infoframe':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_hdmi.c:315:2: warning: pointer targets in passing argument 1 of 'strcpy' differ in signedness [-Wpointer-sign]
/home/vs/drm-intel-experimental/drm-intel/arch/x86/include/asm/string_32.h:9:14: note: expected 'char *' but argument is of type 'uint8_t *'
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_hdmi.c:316:2: warning: pointer targets in passing argument 1 of 'strcpy' differ in signedness [-Wpointer-sign]
/home/vs/drm-intel-experimental/drm-intel/arch/x86/include/asm/string_32.h:9:14: note: expected 'char *' but argument is of type 'uint8_t *'
  CC [M]  drivers/gpu/drm/i915/intel_sdvo.o
  CC [M]  drivers/gpu/drm/i915/intel_modes.o
  CC [M]  drivers/gpu/drm/i915/intel_panel.o
  CC [M]  drivers/gpu/drm/i915/intel_pm.o
  CC [M]  drivers/gpu/drm/i915/intel_i2c.o
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_i2c.c: In function 'intel_setup_gmbus':
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_i2c.c:495:21: error: 'force_bit' undeclared (first use in this function)
/home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_i2c.c:495:21: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [drivers/gpu/drm/i915/intel_i2c.o] Error 1
make[1]: *** [_module_drivers/gpu/drm/i915] Error 2
make: *** [sub-make] Error 2

Created attachment 61526 [details] [review]
disable gmbus on i830 v2

Sorry, this time actually compile-tested.

Created attachment 61527 [details]
drm-intel-next-queued_dmesg

Created attachment 61528 [details]
drm-intel-next-queued_Xorg

No problem. With your patch I can graphics works again and I can boot into my desktop environment without any problems. The wake up problem is, however, still present. On the other hand, the oops now looks a bit different.

[  167.540096] ------------[ cut here ]------------
[  167.540209] WARNING: at /home/vs/drm-intel-experimental/drm-intel/drivers/gpu/drm/i915/intel_display.c:1120 intel_disable_pipe+0x14a/0x180 [i915]()
[  167.540217] Hardware name: 26724BG
[  167.540221] plane B assertion failure, should be off on pipe A but is still active
[  167.540226] Modules linked in: ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi thinkpad_acpi pcmcia snd_seq_midi snd_rawmidi bnep bluetooth snd_intel8x0 ppdev snd_ac97_codec microcode ipw2100 yenta_socket libipw snd_seq_midi_event lib80211 ac97_bus snd_seq pcmcia_rsrc cfg80211 pcmcia_core snd_pcm snd_seq_device snd_timer psmouse serio_raw snd_page_alloc snd shpchp soundcore irda nvram crc_ccitt parport_pc mac_hid lp parport dm_crypt i915(O) drm_kms_helper firewire_ohci drm firewire_core crc_itu_t e100 i2c_algo_bit video
[  167.540314] Pid: 1662, comm: upowerd Tainted: G        W  O 3.4.0-994-generic-pae #201205110405
[  167.540320] Call Trace:
[  167.540343]  [<c1044082>] warn_slowpath_common+0x72/0xa0
[  167.540375]  [<e002f0fa>] ? intel_disable_pipe+0x14a/0x180 [i915]
[  167.540406]  [<e002f0fa>] ? intel_disable_pipe+0x14a/0x180 [i915]
[  167.540416]  [<c1044153>] warn_slowpath_fmt+0x33/0x40
[  167.540448]  [<e002f0fa>] intel_disable_pipe+0x14a/0x180 [i915]
[  167.540482]  [<e0030598>] i9xx_crtc_disable+0xd8/0x160 [i915]
[  167.540513]  [<e0030647>] i9xx_crtc_dpms+0x27/0x30 [i915]
[  167.540544]  [<e002c9ff>] intel_crtc_dpms+0x3f/0x130 [i915]
[  167.540577]  [<e0033eab>] intel_crtc_disable+0x2b/0x90 [i915]
[  167.540597]  [<dfff02ff>] drm_helper_disable_unused_functions+0xef/0x140 [drm_kms_helper]
[  167.540630]  [<e003475a>] intel_release_load_detect_pipe+0xda/0x100 [i915]
[  167.540671]  [<e0037232>] intel_crt_detect+0x222/0x620 [i915]
[  167.540730]  [<e00c9cdc>] status_show+0x3c/0x80 [drm]
[  167.540757]  [<e00c9ca0>] ? dpms_show+0x60/0x60 [drm]
[  167.540770]  [<c13938e9>] dev_attr_show+0x29/0x50
[  167.540783]  [<c11a7b12>] fill_read_buffer+0x52/0xc0
[  167.540791]  [<c11a7bfa>] sysfs_read_file+0x7a/0x90
[  167.540801]  [<c114c30f>] vfs_read+0x9f/0x170
[  167.540808]  [<c11a7b80>] ? fill_read_buffer+0xc0/0xc0
[  167.540816]  [<c114c4b2>] sys_read+0x42/0x70
[  167.540827]  [<c15b789f>] sysenter_do_call+0x12/0x28
[  167.540833] ---[ end trace 10e504dd47a9fe63 ]---

This time the error message explicitly lists upowerd. Since Chris Wilson mentioned that Ubuntu ships an obsolete version, I'm just wondering, if using the latest version might help. In Ubuntu 12.10 repos there is a 0.9.16-2 version that should be quite recent (not sure if one can satisfy all the dependencies with Ubuntu 12.04). Alternatively, I could also try compiling it from the source if this is really needed.

By the way, thanks for your explanation concerning ForcePipeA. I guess the problem is that whitelisting machines that need this option assumes that the number of such machines is very small. I don't know how much laptops need this option to suspend properly, but I highly doubt that you really got them all in intel_quirks[]. For example, according to this bug
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/706386
Thinkpad R51 might also need this option, but currently there's no way to turn it on by hand. I believe that adding a i915.forcepipea=1 kernel cheat would greatly help, especially if one takes into account that such an option was present until i915 became KMS only. 

Of course, I understand that you might have your reasons to hide this option from users, but then I'd be interested to learn that reasons.

One more thing. Could it be that Thinkpad X30 doesn't need the quirk anymore because the underlying sleep problem was fixed elsewhere? In this case activating the pipe might be the true reason for the wake up problem. Or is ForcePipeA something that is intrinsically related to the i830 hardware and nothing else?

Created attachment 61565 [details]
dmesg output with upower 0.9.16-2

Updated to upower 0.9.16-2 and libupower-glib1 0.9.16-2. Wake up still fails.

Can you also attach xrandr --verbose output before and after suspend?

Created attachment 61566 [details]
xrandr --verbose before suspend

Created attachment 61567 [details]
xrandr --verbose after suspend

Created attachment 61568 [details]
output of dmesg with ForcePipeA turned off on Thinkpad X30

By the way, just for fun I also tried commenting out 
{ 0x3577, 0x1014, 0x0513, quirk_pipea_force } in intel_display.c
The system still booted into graphics mode without any problems, 
but the wake up problem was still there. Of course, I reverted the change thereafter.

Created attachment 61569 [details] [review]
debug patch to dump a few things into dmesg

Please try this and attach the dmesg after a suspend/resume cycle.

Created attachment 61573 [details]
dmesg output before suspend with the 2nd patch

Created attachment 61574 [details]
dmesg output after suspend with the 2nd patch

That's weird! With the second patch I see only mouse pointer on a black screen
but no lightdm login window. Consoles vie Ctrl+Alt+F[1-6] show black screens only (no text, backlight is on), i.e X11 doesn't seem to work properly
So I used pm-suspend to activate suspend via ssh.

After wake up the screen remains completely black, i.e. backlight is off now.

While patching I got this warnings:

patching file drivers/gpu/drm/i915/intel_display.c
Hunk #1 succeeded at 1658 (offset -4 lines).
Hunk #2 succeeded at 4034 (offset -4 lines).
Hunk #3 succeeded at 6283 (offset -4 lines).
Hunk #4 succeeded at 6292 (offset -4 lines).

but that's probably because of your previous patch which
doesn't seem to be in the git repo. 

Or did you mean it the way that I should revert your first patch before applying the second one?

Created attachment 61575 [details] [review]
debug patch v2

Ok, only seeing the cursor is not what should have happened, so debug patch v2. The patch to disable gmbus on i830 is already merged into drm-intel-next-queued, but yeah, definitely apply both that patch plus the updated debug patch.

Also, is this a regression, and if so, which kernel version is the last that worked?

Forgotten to add: The problem seems to be that we don't fix up the pipe A -> plane A and pipe B -> plane A setup that the bios likes to leave behind after resume.

Created attachment 61577 [details]
dmesg output before suspend with debug patch v2

Created attachment 61578 [details]
dmesg output after suspend with debug patch v2

O.K, reverted debug_patch and applied debug_patchv2. X11 works again. Wake up still fails, but now backlight is off.

Unfortunately, I can't tell if this a regression or not, since I got the machine
only last week and installed Xubuntu 12.04 right away. As I've already mentioned, according to
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/475559
suspend never really worked on i830 with KMS. It's just that everybody
used the i915.nomodeset=0 cheat which gave them working suspend. That's probably the reason why nobody cared to report the bug upstream

Note to self: The pipe/plane confusion does not seem to be the problem.

Can you please grab a new set of before/after reg dumps with the latest set of patches?

Created attachment 61581 [details]
reg dumps before suspend

Created attachment 61582 [details]
reg dumps after suspend

On the other hand, the pipe/plane confusion might be only one part of the problem. It really depends on how much suspend is broken with i830.

Anyway, if you need any logs or have any patches to test, feel free to buzz me.

On a quick check, pipe A is not running on suspend, whereas it is before suspend.

Could this also have something to do with pm-utils?

There seems to be a quirk for Thinkpad X30 in pm-utils, but as far as I understand, pm-utils should actually be intelligent enough to detect a drm driver and thus not to apply those quirks. Right?

cat /usr/lib/pm-utils/video-quirks/20-video-quirk-pm-ibm.quirkdb | grep -C 5 2672

 # <!-- X31, T30 , A31p-->
  match system.hardware.product regex ^(2366|2367|2653)
   addquirk --quirk-radeon-off
  endmatch
 # <!-- X22, X40, X32 -->
  match system.hardware.product regex ^(2662|2672|2673)
   addquirk --quirk-radeon-off
   match system.hardware.version regex_inverse X31
    addquirk --quirk-s3-bios
    addquirk --quirk-s3-mode
   endmatch
  endmatch
 # <!-- X31 -->
  match system.hardware.product regex ^(2672|2673|2884|2885|2890|2891)
   match system.hardware.version regex X31
    addquirk --quirk-dpms-suspend
    addquirk --quirk-radeon-off
   endmatch
   match system.hardware.version regex X32

> --- Comment #46 from Vladyslav Shtabovenko <DFEW.Entwickler@googlemail.com> 2012-05-19 16:21:01 PDT ---
> Could this also have something to do with pm-utils?
> 
> There seems to be a quirk for Thinkpad X30 in pm-utils, but as far as I
> understand, pm-utils should actually be intelligent enough to detect a drm
> driver and thus not to apply those quirks. Right?

Hm, can you try suspend with just the kernel code to rule that out?

# echo mem > /sys/power/state

Done. Same situation and nothing new. In addition, I also found the following lines in
/var/log/pm-suspend.log, so I guess everything should be fine.

/usr/lib/pm-utils/sleep.d/95led suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend:
Kernel modesetting video driver detected, not using quirks.

/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/99video suspend suspend:
kernel.acpi_video_flags = 0

BTW, should I update to the latest drm-intel-experimental kernel? It looks like there have been a lot of commits during the last 24 hours. On the other hand,
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/current/ currently seems to be down ...

On the other hand, if the commits are only about i915, it should suffice
just to update my local git copy and recompile i915, right?

Created attachment 61883 [details] [review]
do full register restore in kms

A little test patch for you to try out. drm-intel-next-queued doesn't have any changes that should affect your system, so you can try this on any recent kernel.

Created attachment 61887 [details]
dmesg before suspend

Created attachment 61888 [details]
dmesg after suspend

Created attachment 61889 [details]
reg dumps before suspend

Created attachment 61890 [details]
reg dumps after suspend

Created attachment 61891 [details]
dmesg after restarting lightdm

OK, did a "git remote update" (just in case) and applied your latest patch.
The result is rather interesting. Kernel oops are gone, but the screen is
still completely black. I also tried to restart lightdm or switch to virtual
consoles but that doesn't work either.

Hm, I've just reviewed the xrandr configuration, and noticed that you have VGA1 enabled even though it's not connected. Is that due to some xorg.conf stuff?

And can you try what happens when you disable VGA1 and move the LVDS1 to the first crtc before doing the suspend?

xrandr --output VGA1 --off
xrandr --output LVDS1 --auto --crtc 0

Please test this on the patched kernel.

Created attachment 61892 [details]
dmesg after suspend

Good point! I'm not using Xorg.conf so this must be the default behavior.
I executed both commands before suspend. After running the 2nd command, there was a short screen flicker, but then the picture was normal again. After suspend symptoms are still the same. Here's the xrandr --verbose output after suspend:

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
VGA1 connected (normal left inverted right x axis y axis)
	Identifier: 0x41
	Timestamp:  192527
	Subpixel:   unknown
	Clones:    
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
  1024x768 (0x43)   65.0MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz
  800x600 (0x44)   40.0MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
        v: height  600 start  601 end  605 total  628           clock   60.3Hz
  800x600 (0x45)   36.0MHz +HSync +VSync
        h: width   800 start  824 end  896 total 1024 skew    0 clock   35.2KHz
        v: height  600 start  601 end  603 total  625           clock   56.2Hz
  848x480 (0x46)   33.8MHz +HSync +VSync
        h: width   848 start  864 end  976 total 1088 skew    0 clock   31.0KHz
        v: height  480 start  486 end  494 total  517           clock   60.0Hz
  640x480 (0x47)   25.2MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
        v: height  480 start  489 end  492 total  525           clock   59.9Hz
LVDS1 connected 1024x768+0+0 (0x48) normal (normal left inverted right x axis y axis) 0mm x 0mm
	Identifier: 0x42
	Timestamp:  192527
	Subpixel:   horizontal rgb
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       0
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	BACKLIGHT: 7 (0x00000007)	range:  (0,7)
	Backlight: 7 (0x00000007)	range:  (0,7)
  1024x768 (0x48)   65.0MHz +HSync +VSync *current +preferred
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz
  1024x768 (0x43)   65.0MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz
  800x600 (0x44)   40.0MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
        v: height  600 start  601 end  605 total  628           clock   60.3Hz
  800x600 (0x45)   36.0MHz +HSync +VSync
        h: width   800 start  824 end  896 total 1024 skew    0 clock   35.2KHz
        v: height  600 start  601 end  603 total  625           clock   56.2Hz
  640x480 (0x49)   25.2MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
        v: height  480 start  490 end  492 total  525           clock   59.9Hz

Running both command after suspend doesn't seem to change anything.

LOL! To test you theory I connected a VGA monitor after an unsuccessful suspend and there was a picture! However, the screen was flickering as hell. Then I tried to switch the main picture to the laptop monitor and everything became completely dark again. So yeah, there really seems to be some kind of problem with LVDS after suspend, whereas VGA kind of works.

So you don't actually have anything connected on VGA1, but we have a spurious detection there (at least sometimes). Yet another bug :(

Can you also test what happens when you have a screen connected to VGA1 all the time (i.e. before booting up and throughout the s/r cycle)?

Will do. Just a minute ago I did a "xrandr --auto" via ssh and now VGA monitor is showing a perfect picture. Tried to suspend and after wake up it still works. However, no matter what I do, the laptop screen remains dark. Nevertheless, that's a huge progress compared to the original situation!

Hm, can you also check what happens with a screen connected on VGA1, but without the test patch to force register restoring?

OK, so the IBM bios has actually two video related options:
Default Primary Video Device [Internal/PCI (docking)] -> currently set to Internal
Boot Display Device [LCD/CRT/Both] -> currently set to LCD

If I boot with the VGA monitor connected, there's a significant flickering (VGA only) during boot process and when starting X11. After the login screen, VGA monitor is showing only a mouse pointer on a black screen, whereas laptop monitor shows normal picture. After I select "Both displays cloned" in XFCE display settings, the picture on the VGA monitor becomes fine as well. If I suspend, then after wake up the VGA monitor works fine but the laptop monitor
remains completely dark. The behavior seems to be reproducible.

Now I'll check what changes without your latest patch.

A small correction to my previous comment. The picture on the VGA monitor *does* flicker, it's just that the flickering happens only when you move the mouse. Moreover, if I select VGA monitor only in XFCE display settings, the picture on the VGA monitor disappears, so that I can see only a mouse
pointer on a black background. Now I'm recompiling i915 without the patch.

OK, so without your patch boot process looks the same. Before first suspend VGA monitor is *not* flickering, i.e. everything looks fine so far. Now suspend and wake up. Laptop display completely dark, VGA is flickering as hell. Selecting "Both displays cloned" in XFCE doesn't change anything. If I select VGA monitor only, there is a mouse pointer on a dark background, but after switching to the 1st console and then back to X11 (Ctrl-Alt-F1, Ctrl-Alt-F7), VGA picture looks perfect. Native VGA resolution and no flickering. 

Now if I select "both displays cloned", VGA switches to the resolution of the internal LCD, *but* the picture is still perfectly fine. LVDS is of course still black.

If I suspend again, VGA is again flickering after wakeup. Repeating the same procedure (VGA only in XFCE, Ctrl-Alt-F1, Ctrl-Alt-F7) gives me a normal picture again.

Tested the latest commits by Chris Wilson, although they apparently have nothing to do with 830M. Everything is as before, at least nothing got additionally broken.

Another random thing to try: What happens when you switch off LVDS1 and force VGA1 to crtc 1?

xrandr --output LVDS1 -off
xrandr --output VGA1 --auto --crtc 1

After the first line, laptop LCD is turned off. After the second line, VGA monitor becomes dark but with backlight on. Entering xrandr --auto seems to fix the situation, i.e. both displays become activated in clone mode. After "xrandr --auto", running "xrandr --output VGA1 --auto --crtc 1" doesn't change anything, but running "xrandr --output LVDS1 -off" immediately turns off both displays. Often VGA monitor would show only a mouse pointer on a black background and I have to do the Ctrl-Alt-F1, Ctrl-Alt-F7 trick to get a normal picture back.

To me, in the current state it looks rather broken.

I've just installed the drm-intel-experimental kernel from 22.05.2012 which contains "drm/i915: don't silently ignore sdvo mode_set failures" as the last commit. So far the symptoms are exactly the same as described in my previous comments.

Futhermore, I also tested the latest commits you guys made today. No changes at all. If you have more patches or need any logs, just let me now.

Wanted to test the new commits in drm-intel-next-queued until I realized how big the last merge ('airlied/drm-prime-vmap' into drm-intel-next-queued) is. So I'll better wait until there's a new drm-intel-experimental kernel build that incorporates those changes. 

I suppose that even after that huge merge the kernel is still compatible with xorg-edgers ppa packages, or do you expect some severe problems?

On Fri, Jun 1, 2012 at 3:34 PM,  <bugzilla-daemon@freedesktop.org> wrote:
> suppose that even after that huge merge the kernel is still compatible with
> xorg-edgers ppa packages, or do you expect some severe problems?

The kernel _should_ always be a drop-in replacement for older
userspace. Obsiously, we sometimes screw things up. If that happens,
please yell at us in the form of a bug report ;-)

btw, the pull request doesn't contain much interesting for drm/i915,
so you could also try out todays ppa build.

Damn! Something about IRQ handling got broken in the recent kernel. Now I get the
the famous "irq X: nobody cared" oops, that disables my network chip such that I can't access the machine via ssh. Kernel 3.4.0-1-generic-pae is fine, but kernel 3.4.0-3.7 from xorg-edgers-ppa already contains the bug. The same goes for linux-image-3.4.0-994-generic_3.4.0-994.201206010408_i386

As far as graphics is concerned with the newest xorg-edgers-ppa packages + image-3.4.0-994-generic_3.4.0-994.201206010408_i386 *both* screens remain black all the time. Whereas I still can switch to a virtual console when booting 3.4.0-3.7, this is not possible with 3.4.0-994-generic_3.4.0-994.201206010408_i386. Since network is also not working, I can't give you any logs for the latest drm-intel-experimental kernel.

However, I could provide logs for the 3.4.0-3.7 from xorg-edgers-ppa. There, graphics is also broken just like drm-intel-experimental, but at least I can use a virtual console.

Well let's hope, that the IRQ mess will get fixed soon :(

A patch referencing this bug report has been merged in Linux v3.5-rc1:

commit 83ee9e645846f0c56bd9b33ee28ead03b416bb25
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 13 14:44:20 2012 +0200

    drm/i915: disable gmbus on i830

Can you please try the modeset-rework-pipea-fix git branch from my personal
repo at http://cgit.freedesktop.org/~danvet/drm The patches in there ensure that we re-enable pipe A after resume (which we currently don't). Not doing that on i830M could result to the behaviour your describing ....

Please boot with drm.debug=0xe and also attach the full dmesg.

I'd like to, but beginning with 3.4.0-3.7 all the kernels are broken on my machine. I've just tested 3.5.0-994-generic_3.5.0-994.201207060407 from drm-intel-experimental and got the same behavior as in my last post:
Kernel segfaults on "irq X: nobody cared" leaving me without ethernet, wifi etc.
Futhermore, the screen remains black all the time, unless I boot with i915.nomodeset=0. Until this somehow gets fixed, there's not much sense to test i915, since it probably also gets affected by this new bug.

Created attachment 63947 [details]
Dmesg output with i915.nomodeset

Funny, it seems that kernel 3.5 boots even without i915.modeset=0 but it simply won't load any hardware modules: neither i915, nor wifi, ethernet or bluetooth.
To me, at the moment it looks badly broken on X30 and probably some other older machines.

Me again.

In the meantime I installed Xubuntu 12.10 Alpha 3 and did a dist-upgrade.
Futhermore, I installed the newest packages from the xorg-edgers ppa.

uname -a
Linux x30 3.5.0-10-generic #10-Ubuntu SMP Mon Aug 13 15:25:53 UTC 2012 i686 i686 i686 GNU/Linux


Packages installed:
xserver-xorg1:7.7+1ubuntu1

xserver-xorg/precise  1:7.6+12ubuntu1
xserver-xorg-video-intel/precise  2:2.17.0-1ubuntu4
libgl1-mesa-dri/precise  8.0.2-0ubuntu3
libgl1-mesa-glx/precise  8.0.2-0ubuntu3
libglapi-mesa/precise  8.0.2-0ubuntu3
libglu1-mesa/precise  8.0.2-0ubuntu3
mesa-utils/precise  8.0.1+git20110129+d8f7d6b-0ubuntu2
libdrm-intel1/precise  2.4.32-1ubuntu1
libdrm-nouveau1a/precise  2.4.32-1ubuntu1
libdrm-radeon1/precise  2.4.32-1ubuntu1
libdrm2/precise  2.4.32-1ubuntu1
intel-gpu-tools/precise 1.2-1

Me again.

In the meantime I installed Xubuntu 12.10 Alpha 3 and did a dist-upgrade.
Futhermore, I installed the newest packages from the xorg-edgers ppa.

uname -a
Linux x30 3.5.0-10-generic #10-Ubuntu SMP Mon Aug 13 15:25:53 UTC 2012 i686 i686 i686 GNU/Linux


Packages installed:
xserver-xorg  1:7.7+1ubuntu1
xserver-xorg-video-intel 2:2.20.3+git20120816.94871944-0ubuntu0sarvatt
libgl1-mesa-dri:i386 8.1~git20120816.1b11395a-0ubuntu0sarvatt
libgl1-mesa-glx:i386 8.1~git20120816.1b11395a-0ubuntu0sarvatt
libglapi-mesa:i386 8.1~git20120816.1b11395a-0ubuntu0sarvatt
libglu1-mesa:i3868.0.4-1ubuntu1
libdrm-intel1:i386 2.4.38+git20120814.3163cfe4-0ubuntu0ricotz
libdrm2:i386 2.4.38+git20120814.3163cfe4-0ubuntu0ricotz

Fortunately, the machine boots fine now. Unfortunately, the suspend bug is still present. At least this time one can clearly see some kernel oops in the dmesg log (I have drm.debug=0xe in my boot params).

I wanted to try out the drm-intel kernel, but Ubuntu servers are down at the moment, so I'll probably do this tomorrow.

The dmesg logs are attached.

Created attachment 65746 [details]
dmesg output before suspend

Created attachment 65747 [details]
dmesg output after suspend

Hmm, with the latest intel next kernel (linux-image-3.6.0-994-generic_3.6.0-994.201208170418) x-server fails to load leaving me with a black screen. 

This is *not* an X.org issue, because with the  v3.6-rc2-quantal kernel (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc2-quantal/) X11 loads flawlessly (up to the standby bug)

It looks like the problem starts here

[   26.936419] i915 0000:00:02.0: setting latency timer to 64
[   26.939820] [drm:intel_opregion_setup], graphic opregion physical addr: 0x0
[   26.939824] [drm:intel_opregion_setup], ACPI OpRegion not supported!
[   26.939859] BUG: unable to handle kernel paging request at e02c1208
[   26.939961] IP: [<e03efca9>] i915_read32+0x79/0x130 [i915]
[   26.939967] *pdpt = 000000000199e001 *pde = 000000001224f067 *pte = 0000000000000000 
[   26.939972] Oops: 0000 [#1] SMP 
[   26.940009] Modules linked in: snd_seq i915(+) ipw2100(+) libipw nsc_ircc psmouse snd_timer microcode(+) yenta_socket(+) lib80211 snd_seq_device pcmcia_rsrc cfg80211 pcmcia_core serio_raw irda snd drm_kms_helper nvram drm soundcore crc_ccitt parport_pc snd_page_alloc i2c_algo_bit shpchp lpc_ich mac_hid video lp parport firewire_ohci firewire_core e100 crc_itu_t
[   26.940018] Pid: 368, comm: modprobe Not tainted 3.6.0-994-generic #201208170418 IBM 26724BG/26724BG
[   26.940020] EIP: 0060:[<e03efca9>] EFLAGS: 00010282 CPU: 0
[   26.940058] EIP is at i915_read32+0x79/0x130 [i915]
...

Any ideas?

Created attachment 65779 [details]
dmesg for the linux-image-3.6.0-994-generic_3.6.0-994.201208170418 kernel

Created attachment 65780 [details]
Xorg output showing that server can't start

Tried the newest linux-image-3.6.0-994-generic_3.6.0-994.201208210421. X11 works again, but the suspend bug is still present. One can also clearly oops in dmesg logs.

Created attachment 65908 [details]
dmesg before suspend

Created attachment 65910 [details]
dmesg after suspend

The WARN backtrace in your latest dmesg should be fixed in my modeset-rework git branch at

http://cgit.freedesktop.org/~danvet/drm

Please test that kernel, thanks.

Um, IIRC there's no special kernel repository for the modeset-rework branch, right?

Anyway, I checked out that branch and compiled i915 using headers from
3.6.0-994-generic_3.6.0-994.201208210421:

git clone -b modeset-rework git://people.freedesktop.org/~danvet/drm)
rm -rf my_i915 && mkdir my_i915 && cd my_i915
cp /usr/src/linux-headers-3.6.0-994-generic/Module.symvers .
cp /boot/config-3.6.0-994-generic .config
cd ../drm
make EXTRAVERSION=-994-generic O=../my_i915 oldconfig
make EXTRAVERSION=-994-generic O=../my_i915 prepare
make EXTRAVERSION=-994-generic O=../my_i915 outputmakefile
make EXTRAVERSION=-994-generic O=../my_i915 archprepare
make EXTRAVERSION=-994-generic O=../my_i915 modules SUBDIRS=scripts
make EXTRAVERSION=-994-generic O=../my_i915 modules SUBDIRS=drivers/gpu/drm/i915
sudo cp ../my_i915/drivers/gpu/drm/i915/i915.ko /lib/modules/3.6.0-994-generic/kernel/drivers/gpu/drm/i915/
sudo depmod -a && sudo update-initramfs -u

However, with this flavor of i915 the whole machine fails to wake up from standby (even Magic SysRq is not working)

Is this somehow related to modeset-rework or did I do something wrong when compiling i915?

The output of dmesg before suspend is attached.

Created attachment 65981 [details]
Output of dmesg before suspend

Output of dmesg before suspend when using linux-image-3.6.0-994-generic_3.6.0-994.201208170418 kernel with i915 module from modeset-rework
branch

I am rather surprised that compiling just the module worked, usually you need to upgrade the entire kernel.

Anyway there are some nice new WARNs in the dmesg, I'll see whether I can cook up a patch - the good thing with the reworked modeset code is that it has tons more checks in place, and it looks like we don't set things up the way we should on i830M (or something with the check is wrong).

I guess compiling i915 only shouldn't be a problem as the kernel I'm using is created from drm-intel-next. As far as I can see, the modeset-rework branch was created after "Haswell HDMI audio initialization" commit. Luckily, this kernel
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/2012-08-17-quantal/
was also compiled just after that commit such that it should be compatible with i915 built from modeset-rework.

Apart from this, 830M is already quite an old peace of hardware and I really appreciate your attempts to fix it.

Anything relevant for i830M in intel-next worth trying out? Or should I rather wait for new stuff in modeset-rewortk?

I've added two bugfixes to my modeset-rework branch which might help for your issue. Can you please retest?

Done. Everything remains the same.

Created attachment 66423 [details]
dmesg before suspend

Created attachment 66424 [details]
dmesg after suspend

(In reply to comment #95)
> Done. Everything remains the same.

Actually not quite. I've managed to squash one WARN, and I've actually managed to squash the WARN I've wanted to squash ... still, it looks like that fix doesn't fix your issue :(

Thanks for testing, I'll try to come up with something new ...

Looks like I've got the same problem (kernel 3.6 rc4) here on a 2011 MacBook Pro 17.  If there's anything I can do to help out, let me know.

Hi Greg,

even though the symptoms may be similar, your problem is definitely not the same. Simply because Intel 830M graphics is more than 10 years old and is for sure not present in a 2011 MacBook. I suggest you find out which Intel graphics
you have in your machine and open a new bug report.

One of the fixes in modeset-rework was botched. I've pushed an updated patch to my modeset-rework branch, can you please retest and attach the dmesg with debug enabled?

A quick update.

The MBP has two cards and requires that the display be switched to the IGD for all to work.  This was being done by a user space utility.  I patched my kernel to do it during resume (as a PCI quirk) and all is now well.

(In reply to comment #101)
> One of the fixes in modeset-rework was botched. I've pushed an updated patch to
> my modeset-rework branch, can you please retest and attach the dmesg with debug
> enabled?

Some more warnings but still black screen after resume

Created attachment 66820 [details]
dmesg before suspend

Created attachment 66821 [details]
dmesg after suspend

Created attachment 66879 [details] [review]
initizalize crt output first

Shot in the dark: Can you please test this patch on top of the modeset-rework tree?

A patch referencing this bug report has been merged in Linux v3.7-rc2:

commit fa55583797d12b10928a1813f3dcf066637caf5e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Oct 10 23:14:00 2012 +0200

    drm/i915: fixup the plane->pipe fixup code

Timeout. Presumed fixed by Daniel's modesetting rework. Please reopen if the issue still reproduces and you can update the debug information.

Rest reassured that it's still broken ;-)

Somewhere on my giant todo there's an item to compare register dumps of the dvo lvds encoder on the X30 before/after resume and fixup anything we're failing to restore (which is where I suspect the problem lies).

Though before that I need to fixup the pipe A quirk to pipe B work a notch better. Black background + cursor on top isn't quite the desired result ...

In the present state (Xubuntu 12.04, xorg-edgers ppa, 3.8.0-030800rc7 kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc7-raring/) the machine freezes already while entering suspend. The problem is also i915 related, as with i915.modeset=0 cheat suspend works like it should. A dmesg output before suspend is attached.

Created attachment 74909 [details]
dmesg output before entering suspend

Hi there, sorry to dig this one out but I'm having the same issue with my X30, system resumes from sleep but monitor remains off, also the quirks such as VGA being detected as connected when it isn't. Appears to be identical to the original issue posted by Vladyslav Shtabovenko.

I'm running Linux 3.2.0-4-486 under Crunchbang Waldorf 486

I get the following trace in /var/log/messages, it seems to be repeating 3 times:
Jul 24 19:39:04 toaster kernel: [19980.072060] ------------[ cut here ]------------
Jul 24 19:39:04 toaster kernel: [19980.072151] WARNING: at /build/buildd-linux_3.2.41-2-i386-BfAj4s/linux-3.2.41/drivers/gpu/drm/i915/intel_display.c:1013 intel_disable_pipe+0xad/0x129 [i915]()
Jul 24 19:39:04 toaster kernel: [19980.072162] Hardware name: 267242G
Jul 24 19:39:04 toaster kernel: [19980.072168] plane B assertion failure, should be off on pipe A but is still active
Jul 24 19:39:04 toaster kernel: [19980.072175] Modules linked in: cryptd aes_i586 aes_generic arc4 rt2800pci rt2800lib rt2x00pci rt2x00lib eeprom_93cx6 mac80211 cfg80211 fuse speedstep_lib cpufreq_userspace cpufreq_powersave cpufreq_conservative cpufreq_stats bnep rfcomm bluetooth loop pata_pcmcia pcmcia thinkpad_acpi nvram snd_intel8x0 snd_intel8x0m snd_ac97_codec i915 yenta_socket snd_pcm snd_page_alloc pcmcia_rsrc iTCO_wdt iTCO_vendor_support snd_seq snd_seq_device snd_timer pcmcia_core hostap_pci hostap snd lib80211 soundcore irda crc_ccitt psmouse shpchp evdev rfkill ac97_bus ac serio_raw i2c_i801 pcspkr battery rng_core drm_kms_helper parport_pc parport drm acpi_cpufreq mperf i2c_algo_bit i2c_core video button processor ext4 crc16 jbd2 mbcache microcode sg sd_mod crc_t10dif ata_generic ata_piix libata firewire_ohci firewire_core scsi_mod e100 mii crc_itu_t uhci_hcd ehci_hcd usbcore thermal thermal_sys usb_common [last unloaded: scsi_wait_scan]
Jul 24 19:39:04 toaster kernel: [19980.072376] Pid: 1789, comm: Xorg Tainted: G        W    3.2.0-4-486 #1 Debian 3.2.41-2
Jul 24 19:39:04 toaster kernel: [19980.072384] Call Trace:
Jul 24 19:39:04 toaster kernel: [19980.072404]  [<c1022abc>] ? warn_slowpath_common+0x68/0x79
Jul 24 19:39:04 toaster kernel: [19980.072448]  [<f883f093>] ? intel_disable_pipe+0xad/0x129 [i915]
Jul 24 19:39:04 toaster kernel: [19980.072461]  [<c1022b35>] ? warn_slowpath_fmt+0x29/0x2d
Jul 24 19:39:04 toaster kernel: [19980.072506]  [<f883f093>] ? intel_disable_pipe+0xad/0x129 [i915]
Jul 24 19:39:04 toaster kernel: [19980.072552]  [<f8841982>] ? i9xx_crtc_disable+0xb6/0x148 [i915]
Jul 24 19:39:04 toaster kernel: [19980.072586]  [<f882675f>] ? i915_read32+0x72/0x7c [i915]
Jul 24 19:39:04 toaster kernel: [19980.072630]  [<f883ca3f>] ? intel_crtc_dpms+0x2e/0xc8 [i915]
Jul 24 19:39:04 toaster kernel: [19980.072675]  [<f884022f>] ? intel_crtc_disable+0x13/0x60 [i915]
Jul 24 19:39:04 toaster kernel: [19980.072698]  [<f81569b5>] ? drm_helper_disable_unused_functions+0xb0/0xd3 [drm_kms_helper]
Jul 24 19:39:04 toaster kernel: [19980.072744]  [<f88407e4>] ? intel_release_load_detect_pipe+0x83/0xb0 [i915]
Jul 24 19:39:04 toaster kernel: [19980.072793]  [<f8846a77>] ? intel_crt_detect+0x548/0x552 [i915]
Jul 24 19:39:04 toaster kernel: [19980.072812]  [<f8157101>] ? drm_kms_helper_poll_enable+0x9/0x69 [drm_kms_helper]
Jul 24 19:39:04 toaster kernel: [19980.072830]  [<f815723f>] ? drm_helper_probe_single_connector_modes+0x97/0x23a [drm_kms_helper]
Jul 24 19:39:04 toaster kernel: [19980.072874]  [<f8219066>] ? drm_mode_getconnector+0xf5/0x2b3 [drm]
Jul 24 19:39:04 toaster kernel: [19980.072908]  [<f88268ed>] ? i915_write32+0x1b/0x64 [i915]
Jul 24 19:39:04 toaster kernel: [19980.072936]  [<f820fc32>] ? drm_ioctl+0x26c/0x321 [drm]
Jul 24 19:39:04 toaster kernel: [19980.072969]  [<f8218f71>] ? drm_mode_getcrtc+0x9e/0x9e [drm]
Jul 24 19:39:04 toaster kernel: [19980.072997]  [<f820f9c6>] ? drm_copy_field+0x48/0x48 [drm]
Jul 24 19:39:04 toaster kernel: [19980.073011]  [<c10aec2f>] ? do_vfs_ioctl+0x462/0x499
Jul 24 19:39:04 toaster kernel: [19980.073030]  [<c10a3820>] ? wait_on_retry_sync_kiocb+0x2b/0x2b
Jul 24 19:39:04 toaster kernel: [19980.073041]  [<c10a37ee>] ? fsnotify_modify+0x4d/0x54
Jul 24 19:39:04 toaster kernel: [19980.073052]  [<c10aecaa>] ? sys_ioctl+0x44/0x66
Jul 24 19:39:04 toaster kernel: [19980.073064]  [<c1002b29>] ? math_state_restore+0x44/0x4c
Jul 24 19:39:04 toaster kernel: [19980.073079]  [<c12869e3>] ? sysenter_do_call+0x12/0x28
Jul 24 19:39:04 toaster kernel: [19980.073088] ---[ end trace f89cb5220a7ba7fd ]---

I don't really have much experience with the kernel or it's modules so I'm not sure where to start, but I'll try anything as being able to properly sleep and resume this laptop would be awesome.

Is there anything I can try that hasn't yet been tried?

I'm actually also interested to know what is the current status of the bug. I completely understand that the recent graphic chips (Haswell etc.) have much higher priority and that there are probably not much people left who use the old Thinkpad X30. Still, it would be very nice if this annoying bug could be fixed.

I'm on vacations until the end of August, such that I can compile and test patches when needed.

Am I correct that drm-intel-next is the right branch to test? Then at least for Ubuntu the kernel builds should be in
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/
and I could apply Daniel's patches to the i915 module on top of that builds as I did before.

Just let me know if you have some ideas to test.

I just checked the situation on Xubuntu 13.04 with xorg-edgers ppa and kernel
from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/

As before suspend is completely broken, i.e. I can't even reach it via ssh after wake up from suspend.

Created attachment 83465 [details]
dmesg output before suspend

By the way, Xubuntu 13.10 will be using XMir. Will this make things 
even more different for us, concerning debugging of i915?

Are there any patches I should try out?

According to
<http://www.heise.de/newsticker/meldung/Intel-gegen-Canonicals-neues-Grafiksystem-Mir-1952049.html>
Intel will not support XMir in its drivers. So, which distro should we (i.e. X30 owners) now test against? Debian?

Another interesting thing: Recently I installed FreeBSD 9.2 on my Thinkpad X30 and there both graphics (Intel KMS) and suspend work flawlessly. I have no idea how different Linux and FreeBSD drivers are, but if you think that this could help you to tackle the suspend problem under Linux, I surely could give you the FreeBSD logs.

(In reply to comment #117)
> According to
> <http://www.heise.de/newsticker/meldung/Intel-gegen-Canonicals-neues-
> Grafiksystem-Mir-1952049.html>
> Intel will not support XMir in its drivers. So, which distro should we (i.e.
> X30 owners) now test against? Debian?

Just disabling Mir (like it's done for the binary nvidia/ati drivers) should be sufficient for testing.

> Another interesting thing: Recently I installed FreeBSD 9.2 on my Thinkpad
> X30 and there both graphics (Intel KMS) and suspend work flawlessly. I have
> no idea how different Linux and FreeBSD drivers are, but if you think that
> this could help you to tackle the suspend problem under Linux, I surely
> could give you the FreeBSD logs.

Hm, I guess the question is whether freebsd uses kms. Since I have no clue about freebsd can you pls try to figure that out?

I also don't know much about FreeBSD, except for it is somewhat similar to Linux, although many things work quite differently. However, I'm pretty sure that in FreeBSD 9.1 they use KMS for i915. See here:

<http://www.freebsd.org/releases/9.1R/announce.html>
> New Intel GPU driver with GEM/KMS support
and here 
<http://www.phoronix.com/scan.php?page=news_item&px=MTIzMTU>

Here's the repository for the drm video modules in the 9.1 release

http://svnweb.freebsd.org/base/stable/9/sys/dev/drm/?pathrev=239965

It's all mixed together, but files beginning with i915_ should somewhat correspond to the i915 module in Linux

Oh, sorry. They call it drm2 not drm. Here's the correct link

http://svnweb.freebsd.org/base/release/9.1.0/sys/dev/drm2/i915/

Freebsd doesn't have any dvo support on gen2, which is requried to get the lvds output going on the x30 (I have one here, too). So I suspect freebsd doesn't actually enable kernel modesetting on gen2 :(

Thanks anyway for digging this out, always worth a bit of hope ;-)

(In reply to comment #122)
> Freebsd doesn't have any dvo support on gen2, which is requried to get the
> lvds output going on the x30 (I have one here, too). So I suspect freebsd
> doesn't actually enable kernel modesetting on gen2 :(

Is there a way I can check if KMS works explicitly? I will have no access to the machine until this Friday, but I'll do the check asap.

Since you also have an X30, I suspect that the suspend bug is more severe than exprected. Otherwise you probably would have already solved it. Looks like I'll have to stick to FreeBSD for longer time ;)

(In reply to comment #124)
> Since you also have an X30, I suspect that the suspend bug is more severe
> than exprected. Otherwise you probably would have already solved it. Looks
> like I'll have to stick to FreeBSD for longer time ;)

Haven't really analyzed the issue yet, I expect that we don't correctly restore the external dvo encoder though. It just requires a few hours of tinkering, but time for such projects is really hard to get by :(

Wrt figuring out whether *bsd has kms: No idea, but I'm really sure it doesn't have it for your machine ;-)

(In reply to comment #125)
> Haven't really analyzed the issue yet, I expect that we don't correctly
> restore the external dvo encoder though. It just requires a few hours of
> tinkering, but time for such projects is really hard to get by :(

I see. No problem, in the meantime I got myself a Thinkpad X200 for work, such that the X30 is more or less a hobby machine. I can wait ;)


> Wrt figuring out whether *bsd has kms: No idea, but I'm really sure it
> doesn't have it for your machine ;-)

Concerning KMS on gen 2, I've just sent a question to their mailing list. I'll let you know if I get an answer.

(In reply to comment #126)
> > Wrt figuring out whether *bsd has kms: No idea, but I'm really sure it
> > doesn't have it for your machine ;-)
> 
> Concerning KMS on gen 2, I've just sent a question to their mailing list.
> I'll let you know if I get an answer.

I guess you are right, they didn't enable KMS for Gen 2 in the 9.1 release
<http://www.mail-archive.com/freebsd-questions@freebsd.org/msg269224.html>

Which means that the suspend bug might propagate to FreeBSD as soon as KMS is enabled by default for all Intel graphic chips :(

Recently I tried FreeBSD 10 Beta 2. KMS is not enabled by default on Gen2 but all the ingredients are there. However if one tries to activate i915kms and start X.Org ("kldload i915kms && startx"), all you get is a black screen

....
info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
info: [drm] failed to find VBIOS tables
drmn0: taking over the fictitious range 0xe0000000-0xe7fff000
info: [drm] initialized overlay support
stray irq7
No connectors reported connected with modes
info: [drm] Cannot find any crtc or sizes - going 1024x768
info: [drm] Initialized i915 1.6.0 20080730
pid 1283 (Xorg), uid 0: exited on signal 6 (core dumped)

Without KMS (i.e. i915 driver only) everything works fine. So I guess that if the devs won't throw the non-KMS Intel drivers out, I could keep using FreeBSD on the old Thinkpad X30. Even though using Linux would be way better ;)

Any progress?

Soon this bug will celebrate its 2 year anniversary. It is kind of sad that the old Thinkpad X30 is unusable under Linux because KMS is not working properly. I wish people would have just kept the old non-KMS driver ...

I just got a very interesting piece of information from a friendly member of the German thinkpad-forum.de:

It looks like  Ville Syrjälä has already fixed the issue with the suspend problems on i830, but the fix is not in the mainline kernel. Here is the link to the fix branch on gitorious:

<https://gitorious.org/vsyrjala/linux/commits/ad6bb4b0eb5e981f28206a19cfa7fd21ed598e59>

The fix did not help that user with his suspend problems on R31, but may be it will work on my X30? 

May be you guys could tell me what patches are worth applying to see if it helps?

Did you test latest drm-intel-nightly? Could you please give a shot?

Also, did you tried this Ville's branch? Did it solved the issue for you?

Created attachment 107719 [details]
dmesg output after suspend

Created attachment 107720 [details]
dmesg output before suspend

I've just tried the latest drm-intel-nightly together with the xorg-edgers-ppa on Xubuntu 14.04. Nothing new (see attachments)

(In reply to Vladyslav Shtabovenko from comment #135)
> I've just tried the latest drm-intel-nightly together with the
> xorg-edgers-ppa on Xubuntu 14.04. Nothing new (see attachments)

Based on the logs it resumes just fine so I'm not sure what's the problem here. Display doesn't light up after resume or something? If so, what happens if you plug in a VGA monitor?

Yes, the machine resumes fine, but the display remains dark, no matter what you do. Concerning your question about the VGA monitor: Yes, I've already tested that, see
https://bugs.freedesktop.org/show_bug.cgi?id=49838#c59

So VGA comes back buggy and LVDS doesn't come back at all.  Sounds like we may be missing save/restore of some memory controller regs, starving the display of memory bw?  I'm just assuming the VGA flicker you saw was caused by underruns.  Another possibility is we're not restoring a source clock configuration, making the pixel clocks we try to drive bogus...

Got my hands on an X30 by accident, and finally was able to isolate the issue here. The problem is that the Bios leaves the timing registers of the DVO uninitialized after resume from standby, and hence leaves a completely useless DVO configuration behind.

I have a patch in the making, it is currently in the "works fine for me" state. I'll have to cleanup this patch a bit and then submit it, probably ready by next week.

OMG, does that mean I will finally be able to use the KMS mode with the intel Xorg driver, with XRandR and all?  That would be sweet.

From af7f1b8da36808a7369c0e209fc3de7f567b46b5 Mon Sep 17 00:00:00 2001
From: Thomas Richter <thor@math.tu-berlin.de>
Date: Thu, 30 Apr 2015 21:59:00 +0200
Subject: [PATCH 1/1] This patch fixes the resume from suspend on the X30
 thinkpad. The bug is due to the X30 bios failing to
 restore the IVCH (DVO) registers, specifically the PLL
 registers.

This patch makes a backup of the internal DVO registers upon
initialization - assuming that the BIOS sets up everything
correctly. The values are then restored whenever the mode
has to be restored.

Signed-off-by: Thomas Richter <thor@math.tu-berlin.de>
---
 drivers/gpu/drm/i915/dvo_ivch.c |   94 +++++++++++++++++++++++++++++++--------
 1 file changed, 75 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/dvo_ivch.c b/drivers/gpu/drm/i915/dvo_ivch.c
index 89b08a8..d60edf8 100644
--- a/drivers/gpu/drm/i915/dvo_ivch.c
+++ b/drivers/gpu/drm/i915/dvo_ivch.c
@@ -22,8 +22,6 @@
  *
  * Authors:
  *    Eric Anholt <eric@anholt.net>
- *
- * Minor modifications (Dithering enable):
  *    Thomas Richter <thor@math.tu-berlin.de>
  *
  */
@@ -62,7 +60,7 @@
 # define VR01_DVO_BYPASS_ENABLE		(1 << 1)
 /** Enables the DVO clock */
 # define VR01_DVO_ENABLE		(1 << 0)
-/** Enable dithering for 18bpp panels. Not documented. */
+/** Enables dithering */
 # define VR01_DITHER_ENABLE             (1 << 4)
 
 /*
@@ -79,8 +77,6 @@
 # define VR10_INTERFACE_2X18		(2 << 2)
 /** Enables 2x24-bit LVDS output */
 # define VR10_INTERFACE_2X24		(3 << 2)
-/** Mask that defines the depth of the pipeline */
-# define VR10_INTERFACE_DEPTH_MASK      (3 << 2)
 
 /*
  * VR20 LCD Horizontal Display Size
@@ -90,7 +86,7 @@
 /*
  * LCD Vertical Display Size
  */
-#define VR21	0x20
+#define VR21	0x21
 
 /*
  * Panel power down status
@@ -155,16 +151,41 @@
 # define VR8F_POWER_MASK		(0x3c)
 # define VR8F_POWER_POS			(2)
 
+/* Some Bios implementations do not restore the DVO state upon
+ * resume from standby. Thus, this driver has to handle it
+ * instead. The following list contains all registers that
+ * require saving.
+ */
+static const uint16_t backup_addresses[] = {
+	0x11, 0x12,
+	0x18, 0x19, 0x1a, 0x1f,
+	0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27,
+	0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
+	0x8e, 0x8f,
+	0x10		/* this must come last */
+};
+
 
 struct ivch_priv {
 	bool quiet;
 
 	uint16_t width, height;
+
+	/* Register backup */
+
+	uint16_t reg_backup[ARRAY_SIZE(backup_addresses)];
 };
 
 
 static void ivch_dump_regs(struct intel_dvo_device *dvo);
 
+static inline struct intel_gmbus *
+to_intel_gmbus(struct i2c_adapter *i2c)
+{
+	return container_of(i2c, struct intel_gmbus, adapter);
+}
+
+
 /**
  * Reads a register on the ivch.
  *
@@ -174,6 +195,7 @@ static bool ivch_read(struct intel_dvo_device *dvo, int addr, uint16_t *data)
 {
 	struct ivch_priv *priv = dvo->dev_priv;
 	struct i2c_adapter *adapter = dvo->i2c_bus;
+	struct intel_gmbus *bus = to_intel_gmbus(adapter);
 	u8 out_buf[1];
 	u8 in_buf[2];
 
@@ -198,9 +220,10 @@ static bool ivch_read(struct intel_dvo_device *dvo, int addr, uint16_t *data)
 	};
 
 	out_buf[0] = addr;
-
+	bus->force_bit++; /* the IVCH requires bit-banging */
 	if (i2c_transfer(adapter, msgs, 3) == 3) {
 		*data = (in_buf[1] << 8) | in_buf[0];
+		bus->force_bit--;
 		return true;
 	}
 
@@ -209,6 +232,7 @@ static bool ivch_read(struct intel_dvo_device *dvo, int addr, uint16_t *data)
 				"%s:%02x.\n",
 			  addr, adapter->name, dvo->slave_addr);
 	}
+	bus->force_bit--;
 	return false;
 }
 
@@ -217,6 +241,7 @@ static bool ivch_write(struct intel_dvo_device *dvo, int addr, uint16_t data)
 {
 	struct ivch_priv *priv = dvo->dev_priv;
 	struct i2c_adapter *adapter = dvo->i2c_bus;
+	struct intel_gmbus *bus = to_intel_gmbus(adapter);
 	u8 out_buf[3];
 	struct i2c_msg msg = {
 		.addr = dvo->slave_addr,
@@ -228,15 +253,19 @@ static bool ivch_write(struct intel_dvo_device *dvo, int addr, uint16_t data)
 	out_buf[0] = addr;
 	out_buf[1] = data & 0xff;
 	out_buf[2] = data >> 8;
+	bus->force_bit++; /* bit-banging required for the IVCH */
 
-	if (i2c_transfer(adapter, &msg, 1) == 1)
+	if (i2c_transfer(adapter, &msg, 1) == 1) {
+		bus->force_bit--;
 		return true;
+	}
 
 	if (!priv->quiet) {
 		DRM_DEBUG_KMS("Unable to write register 0x%02x to %s:%d.\n",
 			  addr, adapter->name, dvo->slave_addr);
 	}
 
+	bus->force_bit--;
 	return false;
 }
 
@@ -246,6 +275,7 @@ static bool ivch_init(struct intel_dvo_device *dvo,
 {
 	struct ivch_priv *priv;
 	uint16_t temp;
+	int i;
 
 	priv = kzalloc(sizeof(struct ivch_priv), GFP_KERNEL);
 	if (priv == NULL)
@@ -273,6 +303,14 @@ static bool ivch_init(struct intel_dvo_device *dvo,
 	ivch_read(dvo, VR20, &priv->width);
 	ivch_read(dvo, VR21, &priv->height);
 
+	/* Make a backup of the registers to be able to restore them
+	 * upon suspend.
+	 */
+	for (i = 0; i < ARRAY_SIZE(backup_addresses); i++)
+		ivch_read(dvo, backup_addresses[i], priv->reg_backup + i);
+
+	ivch_dump_regs(dvo);
+
 	return true;
 
 out:
@@ -294,12 +332,31 @@ static enum drm_mode_status ivch_mode_valid(struct intel_dvo_device *dvo,
 	return MODE_OK;
 }
 
+/* Restore the DVO registers after a resume
+ * from RAM. Registers have been saved during
+ * the initialization.
+ */
+static void ivch_reset(struct intel_dvo_device *dvo)
+{
+	struct ivch_priv *priv = dvo->dev_priv;
+	int i;
+
+	DRM_DEBUG_KMS("Resetting the IVCH registers\n");
+
+	ivch_write(dvo, VR10, 0x0000);
+
+	for (i = 0; i < ARRAY_SIZE(backup_addresses); i++)
+		ivch_write(dvo, backup_addresses[i], priv->reg_backup[i]);
+}
+
 /** Sets the power state of the panel connected to the ivch */
 static void ivch_dpms(struct intel_dvo_device *dvo, bool enable)
 {
 	int i;
 	uint16_t vr01, vr30, backlight;
 
+	ivch_reset(dvo);
+
 	/* Set the new power state of the panel. */
 	if (!ivch_read(dvo, VR01, &vr01))
 		return;
@@ -308,6 +365,7 @@ static void ivch_dpms(struct intel_dvo_device *dvo, bool enable)
 		backlight = 1;
 	else
 		backlight = 0;
+
 	ivch_write(dvo, VR80, backlight);
 
 	if (enable)
@@ -334,6 +392,8 @@ static bool ivch_get_hw_state(struct intel_dvo_device *dvo)
 {
 	uint16_t vr01;
 
+	ivch_reset(dvo);
+
 	/* Set the new power state of the panel. */
 	if (!ivch_read(dvo, VR01, &vr01))
 		return false;
@@ -349,24 +409,20 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
 			  struct drm_display_mode *adjusted_mode)
 {
 	uint16_t vr40 = 0;
-	uint16_t vr01 = 0;
-	uint16_t vr10;
+	uint16_t vr01;
 
-	ivch_read(dvo, VR10, &vr10);
-	/* Enable dithering for 18 bpp pipelines */
-	vr10 &= VR10_INTERFACE_DEPTH_MASK;
-	if (vr10 == VR10_INTERFACE_2X18 || vr10 == VR10_INTERFACE_1X18)
-		vr01 = VR01_DITHER_ENABLE;
+	ivch_reset(dvo);
 
-	vr40 = (VR40_STALL_ENABLE | VR40_VERTICAL_INTERP_ENABLE |
-		VR40_HORIZONTAL_INTERP_ENABLE);
+	vr01 = VR01_DITHER_ENABLE;
+	vr40 = VR40_STALL_ENABLE;
 
 	if (mode->hdisplay != adjusted_mode->hdisplay ||
 	    mode->vdisplay != adjusted_mode->vdisplay) {
 		uint16_t x_ratio, y_ratio;
 
 		vr01 |= VR01_PANEL_FIT_ENABLE;
-		vr40 |= VR40_CLOCK_GATING_ENABLE | VR40_ENHANCED_PANEL_FITTING;
+		vr40 |= VR40_CLOCK_GATING_ENABLE | VR40_VERTICAL_INTERP_ENABLE |
+		  VR40_HORIZONTAL_INTERP_ENABLE;
 		x_ratio = (((mode->hdisplay - 1) << 16) /
 			   (adjusted_mode->hdisplay - 1)) >> 2;
 		y_ratio = (((mode->vdisplay - 1) << 16) /
@@ -382,7 +438,7 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
 	ivch_write(dvo, VR01, vr01);
 	ivch_write(dvo, VR40, vr40);
 
-	ivch_dump_regs(dvo);
+	/* ivch_dump_regs(dvo); */
 }
 
 static void ivch_dump_regs(struct intel_dvo_device *dvo)
-- 
1.7.10.4

Thanks for the patch, but it doesn't seem to apply to the code in Linux's mainline, and it seems to include "unrelated" changes to dithering support.

I'd be grateful if you could send a fresh new patch that applies to something like the 4.0 kernel.

Also has it been submitted to some upstream, yet?

Created attachment 115645 [details] [review]
The "cleaned up patch" I'm using

OK, I applied the patch manually the best I could, skipping the parts that seemed related to dithering.  There are still parts related to bit-banging which I'm not sure are important, but in any case I'm using this right now (applied on top of 4.1.0-rc2) and it indeed seems to be working just fine (very limited testing, tho: just a few minutes of use so far, with about 10 sleep/restore with and without the "dock").

I can again use my 1600x1200 external display with my X30, Yay!

The XRandr code still suffers from the fact that the VGA1 output can only use CRTC 0, but that CRTC is used by default for LVDS1, so I need to "xrandr --output LVDS1 --crtc 1" before I can really use the VGA output, but this is an unrelated problem (that is also very long standing, and is very minor in comparison).

So, thank you very much.  I hope this gets into the mainline kernel soon(ish), so I don't have to keep patching it locally.

What is the problem with the dither-enable? Does not work? This should actually not cause any problem, but avoid ringing in 24bpp screens due to the 18bpp panel.

The problem with the dither-enable part of your patch is that it modifies code which AFAICT is not present in the 4.1.0-rc2 mainline kernel code.

It would probably help if you could add a comment on the intel-drm mailing list on your successful testing of the patch on your hardware. Without any second party commenting on the patch, I afraid nothing will happen.

I haven't found any "intel-drm" mailing-list, so I assume you meant the
"intel-gfx" mailing-list.  But I haven't found your patch there (I
replied to an related email of yours instead).  Where did you send your patch (IOW where should I send my comment describing my successful testing)?