Forwarding a bug from ubuntu user Volker Knollmann: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/417608 [Problem] After a suspend-resume cycle, dual-head configuration is corrupted until external monitor is disabled and re-enabled with xrandr. [Original report] I run a dualhead configuration with an external LCD (1680 x 1050) and the internal laptop display (1280 x 800). If I put the laptop to suspend with this configuration it shows the following behavior after waking up: * The first 1280x800 pixel of the desktop background and the icons, which are shown on the external display, are repeated on the internal display. So the internal monitor "clones" a segment of the external monitor. * The mouse pointer is NOT cloned. It can be moved normally across both screens. * Windows placed on the external monitor are NOT cloned to the internal screen. * Windows disappear if they are moved from the external to the internal screen. The configuration can be fixed by de-activation and subsequent re-activation of the external screen using xrandr. I'm using an Intel GM965 controller and Ubuntu 9.10alpha4 (and later updates). Compiz is not enabled. The accelleration method is set to UXA. The bug described here did not occur in prior versions of Ubuntu. Additionally, I've created a screenshot directly after resuming and creating the register dumps. And the surprising result: while the displayed screen content was still corrupt, the screenshot contained the CORRECT picture that should have been displayed on screen. So obviously somewhere in the memory the correct screen content must exist but it isn't displayed correctly. I'll attach two more files: ScreenshotAfterResume.png: This is the original and unmodified file created by gnome-screenshot after resuming. It shows how the display should look like. The upper part of the screenshot is the external display, the lower, smaller part is built-in LCD. This file contains what VisibleOnScreen_Faked.png: This is a manipulated version of the previous file. It shows what I really saw on the screens. Please note that mouse pointer is not cloned (if this is of any help for you). Architecture: amd64 DistroRelease: Ubuntu 9.10 MachineType: FUJITSU SIEMENS AMILO Si 2636 Package: xserver-xorg-video-intel 2:2.8.1-1ubuntu1 PackageArchitecture: amd64 ProcCmdLine: root=/dev/mapper/root ro quiet splash ProcEnviron: SHELL=/bin/bash PATH=(custom, user) LANG=en_GB.UTF-8 LANGUAGE=en_GB.UTF-8 ProcVersionSignature: Ubuntu 2.6.31-10.34-generic RelatedPackageVersions: xserver-xorg 1:7.4+3ubuntu5 libgl1-mesa-glx 7.6.0~git20090817.7c422387-0ubuntu5 libdrm2 2.4.13-1ubuntu1 xserver-xorg-video-intel 2:2.8.1-1ubuntu1 xserver-xorg-video-ati 1:6.12.99+git20090825.fc74e119-0ubuntu1 Uname: Linux 2.6.31-10-generic x86_64 UserGroups: adm admin audio cdrom davfs2 dialout dip floppy fuse lp lpadmin mythtv plugdev vboxusers video dmi.bios.date: 03/25/2008 dmi.bios.vendor: Phoenix dmi.bios.version: 1.0D-1471-0012 dmi.board.name: MR030___ dmi.board.vendor: FUJITSU SIEMENS dmi.board.version: 8q8205219 dmi.chassis.type: 10 dmi.chassis.vendor: FUJITSU SIEMENS dmi.chassis.version: Version 1.0 dmi.modalias: dmi:bvnPhoenix:bvr1.0D-1471-0012:bd03/25/2008:svnFUJITSUSIEMENS:pnAMILOSi2636:pvrREFERENCE:rvnFUJITSUSIEMENS:rnMR030___:rvr8q8205219:cvnFUJITSUSIEMENS:ct10:cvrVersion1.0: dmi.product.name: AMILO Si 2636 dmi.product.version: REFERENCE dmi.sys.vendor: FUJITSU SIEMENS fglrx: Not loaded system: distro: Ubuntu architecture: x86_64kernel: 2.6.31-10-generic [lspci] 00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 03) Subsystem: Fujitsu Technology Solutions Device [1734:111f] 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 03) Subsystem: Fujitsu Technology Solutions Device [1734:111f]
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.