Bug 24035

Created attachment 29681 [details]
xorg.conf

Created attachment 29682 [details]
Xorg.0.log

Created attachment 29683 [details]
Output of `xrandr --verbose`

Created attachment 29684 [details]
BootDmesg.txt

Created attachment 29685 [details]
CurrentDmesg.txt

Created attachment 29686 [details]
glxinfo

Created attachment 29687 [details]
Output of `lspci -vvnn`

Created attachment 29688 [details]
Screenshot taken when screen is corrupted, but showing correct setup

Created attachment 29689 [details]
Manipulated version of the screenshot to show what the screens actually look like

I asked Volker to provide outputs of dmesg, intel_reg_dumper and intel_gpu_dump before and after suspend (by `echo mem > /sys/power/state` from a VT). The outputs are following in the next attachments. dmesg output get the following after resume:

[  725.124751] PM: resume devices took 5.092 seconds
[  725.124755] ------------[ cut here ]------------
[  725.124769] WARNING: at /build/buildd/linux-2.6.31/kernel/power/suspend_test.c:52 suspend_test_finish+0x7c/0x80()
[  725.124774] Hardware name: AMILO Si 2636
[  725.124778] Component: resume devices
[  725.124781] Modules linked in: cryptd aes_x86_64 aes_generic hidp binfmt_misc ppdev bridge stp bnep arc4 snd_hda_codec_intelhdmi snd_hda_codec_conexant ecb snd_hda_intel snd_hda_codec joydev iwlagn iwlcore snd_pcm_oss snd_mixer_oss led_class snd_pcm snd_seq_dummy snd_seq_oss sbp2 snd_seq_midi mac80211 snd_rawmidi snd_seq_midi_event snd_seq psmouse cfg80211 lp parport serio_raw snd_timer snd_seq_device btusb snd soundcore snd_page_alloc reiserfs sha256_generic twofish twofish_common cbc dm_crypt ohci1394 usb_storage i915 ieee1394 usbhid intel_agp sky2 drm i2c_algo_bit video output fbcon tileblit font bitblit softcursor dm_raid45 xor
[  725.124875] Pid: 4511, comm: bash Not tainted 2.6.31-10-generic #34-Ubuntu
[  725.124880] Call Trace:
[  725.124892]  [<ffffffff81059778>] warn_slowpath_common+0x78/0xb0
[  725.124900]  [<ffffffff8105980c>] warn_slowpath_fmt+0x3c/0x40
[  725.124907]  [<ffffffff8108e53c>] suspend_test_finish+0x7c/0x80
[  725.124915]  [<ffffffff8108e2e9>] suspend_devices_and_enter+0xa9/0xe0
[  725.124922]  [<ffffffff8108e3f8>] enter_state+0xd8/0x110
[  725.124929]  [<ffffffff8108d9b2>] state_store+0x92/0x100
[  725.124937]  [<ffffffff8126f0f7>] kobj_attr_store+0x17/0x20
[  725.124946]  [<ffffffff8117f740>] sysfs_write_file+0xe0/0x160
[  725.124954]  [<ffffffff81119db8>] vfs_write+0xb8/0x1a0
[  725.124964]  [<ffffffff81525fe4>] ? do_page_fault+0x194/0x370
[  725.124971]  [<ffffffff8111a86c>] sys_write+0x4c/0x80
[  725.124980]  [<ffffffff81011fc2>] system_call_fastpath+0x16/0x1b
[  725.124986] ---[ end trace a8899a6920f93795 ]---
[  725.125086] PM: Finishing wakeup.
[  725.125090] Restarting tasks ... done.

Created attachment 29690 [details]
dmesg_before.txt

Created attachment 29691 [details]
dmesg_after.txt

Created attachment 29692 [details]
intelreg_before.txt

Created attachment 29693 [details]
intelreg_after.txt

Created attachment 29694 [details]
intelgpu_before.txt (gzipped to get below bugzilla limit)

Created attachment 29695 [details]
intelgpu_after.txt (gzipped to get below bugzilla limit)

Quote from the original bug report:
> If I put the laptop to suspend with this
> configuration it shows the following behavior after waking up:
>
> [...]
>   * Windows placed on the external monitor are NOT cloned to the internal
>     screen.
>

After my system update yesterday (2009-09-18), this is not true anymore. As you can see on the attached manipulated screenshot, windows are cloned, too.

Just for clarification and to avoid confusion....

Funky... I'll see if I can reproduce this.

Btw does this also happen with the xorg edgers bits (i.e. the 2.9.0 driver)?

Sorry for the late reply... I was too dumb to put me on the CC-list for updates...


So, here is what I've done:

  * Updated the system from the regular sources. This installed the intel driver 2:2.8.1-1ubuntu2. No change, the problem remains.

  * Installed 2:3a2.9.0~git20090930.2841a4cd-0ubuntu0tormod_amd64 and related packets from ppa:tormodvolden/ppa. That seemed to be the latest version. Unfortunately, X crashed after the update because the intel drivers ABI major version (5) did not fit to the server's version (6) anymore.

  * Used ppa-purge to clean up. X worked again afterwards.

  * Installed 2:3a2.9.0-1ubuntu1~xup~1_amd64 from ppa:ubuntu-x-swat/x-updates. X works, but the original resume problem still remains.


I've kept the last configuration 2:3a2.9.0-1ubuntu1~xup~1_amd64 since it obviously makes no problems (as far as I can tell after 10 minutes).

>   * Installed 2:3a2.9.0~git20090930.2841a4cd-0ubuntu0tormod_amd64 and related
> packets from ppa:tormodvolden/ppa. That seemed to be the latest version.
> Unfortunately, X crashed after the update because the intel drivers ABI major
> version (5) did not fit to the server's version (6) anymore.

Did you upgrade to the xorg-edgers version of _all_ relevant packages? The best way to do this is to add
deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main 
deb-src http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main 
to /etc/apt/sources.list and apt-get dist-upgrade. Of course, it is in the nature of this PPA that things break every now and then, but this sounds more like a configuration error.

(In reply to comment #20)
> Did you upgrade to the xorg-edgers version of _all_ relevant packages?

Well, I always did a normal update/upgrade-cycle (which of course included upgrades of all packets) but I had BOTH PPAs -- xorg-edgers and tormodvolden -- activated in apt at the same time. Because from browsing the PPA, the latter one seemed to have the more recent version. I guess this mixture broke my X.


So tonight I've purged my system from all PPA-packets and subsequently re-installed only from x-org-edgers. To cut a long story short: even with this new configuration, the bug is as healthy as before... :-(


For the records:
The intel driver is now 2:2.9.0~git20090930.2841a4cd-0ubuntu0tormod. The rest of X is working fine. Of course I can provide the version numbers of other X-related packages if you need.

(In reply to comment #18)
> Funky... I'll see if I can reproduce this.

Were you able to reproduce it? I tried to hook up an external monitor to my Thinkpad X61 Tablet (with 965GM) and I could reproduce it straight away (but I haven't tried with xorg-edgers yet). Switching to VT1 and back restores the expected behaviour. If you can't reproduce it, would it be useful to have 3 sets of logs: (1) before suspend, (2) after resume and (3) after a VT switch back to VT1 and back so that expected behaviour is restored?

I'll have to reproduce when I get back home (travelling in Japan until next week).  Yes, the dumps you mentioned should be helpful.  Thanks.

*** Bug 24745 has been marked as a duplicate of this bug. ***

I have added my files to the duplicate bug 24745 to avoid mixing logs from my system with logs from Volker's.

It looks like a suspect could be the registers DSPABASE and DSPATILEOFF which are set to 0x00000000 when it comes back from suspend and are returned to their original value after a VT switch restores the correct picture on the external monitor.

Just tried this, and it works (both heads come back) with the bits from karmic.  Can you confirm?  I suspect the edgers bits with a recent kernel would be sufficient, but it may only be fixed with KMS.

(In reply to comment #26)
> Just tried this, and it works (both heads come back) with the bits from karmic.
>  Can you confirm?  I suspect the edgers bits with a recent kernel would be
> sufficient, but it may only be fixed with KMS.

Last night it still didn't work with Karmic with xorg-edgers (with KMS). I will try a more recent kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/ and see if that helps. Note that I suspended from X and not from a VT (I forgot to the latter, but I would expect it to work fine, since a VT switch fixes the problem).

Yeah, I suspended from X too, with a VGA monitor attached and a window displayed on it.  Everything came back ok, but like I said I'm running in KMS mode (this is the default for karmic though, so you should be too).

Yes, I run KMS. I must admit I don't have any intuition for what is functionality is still left in the driver when using KMS (but I guess this is the wrong place to ask?). In other words: if the kernel or the driver is responsible for a particular bug.

What kernel are you running? intel-drm-next from git, I suppose?
 

I was testing with a 64 bit 2.6.31-11-generic kernel, part of karmic I think.  Generally with KMS if resume is broken it's a kernel bug.  The fact that you narrowed it down to DSPA* helps, but afaik the kernel is saving & restoring those.  It's possible your firmware clobbers them before the kernel saves them though, or somehow the VT switch code in the X driver is losing part of the config...

I'm normally running linux-image-2.6.31-14-generic (2.6.31-14.48 amd64) which is the current default in Karmic. This and also 2.6.31-10-generic has the problem. However, when I tried to use the mainline kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ , I could not reproduce it. I tried 2.6.31.4 (on which the ubuntu packages 2.6.31-14-generic is based), 2.6.31.5, 2.6.32rc1, and 2.6.32rc5.

I guess this means that this is a NOTOURBUG here.

Ok, thanks for the update.