Forwarding this bug from Ubuntu reporter Martin Albicker: http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/982251 [Problem] Black screen lockup, possibly correlated to external monitor hot plug and/or RANDR. [Original Description] I hope my description in english is good enought, that you can understood it. if i conect an external monitor, it is sometimes impossible to select all modis (clone, dualview, only laptop, only external monitor). And after i reconect the monitor, the default resolution of the laptop monitor, dont come back. Sometimes i get a resoltion of 4:3 instead of 16:10, and sometimes the screen persists black. So i musst restart the laptop, that the default resolution come back. An other Bug that don't associate with this bug is, that the mousepad freezes sometimes. To solve this i musst restart my laptop. My used Hardware is a Samsung x360 laptop. Wenn man den Externen Bildschrim ber den VGA stecker anschliet, lassen sich manchmal nicht alle Modis einstellen. Ebenfalls kam es schon vor das anschlieend das Bild nicht mehr auf den Laptop zurckzuholen ging. Erst nach einem Neustart funktionierte es dann wieder. Bei meiner Hardware handelt es sich um einen Samsung x360 gre Martin ProblemType: Crash DistroRelease: Ubuntu 12.04 Package: xserver-xorg-video-intel 2:2.17.0-1ubuntu4 ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14 Uname: Linux 3.2.0-23-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.0.1-0ubuntu2 Architecture: amd64 Chipset: gm45 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz Date: Sun Apr 15 09:29:58 2012 DistUpgraded: Fresh install DistroCodename: precise DistroVariant: ubuntu DkmsStatus: virtualbox, 4.1.12, 3.2.0-21-generic, x86_64: installed virtualbox, 4.1.12, 3.2.0-22-generic, x86_64: installed virtualbox, 4.1.12, 3.2.0-23-generic, x86_64: installed DuplicateSignature: [gm45] GPU lockup render.IPEHR: 0x01820000 Ubuntu 12.04 ExecutablePath: /usr/share/apport/apport-gpu-error-intel.py GraphicsCard: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Samsung Electronics Co Ltd Device [144d:c03e] Subsystem: Samsung Electronics Co Ltd Device [144d:c03e] InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20120321) InterpreterPath: /usr/bin/python2.7 MachineType: SAMSUNG ELECTRONICS CO., LTD. X360 ProcCmdline: /usr/bin/python /usr/share/apport/apport-gpu-error-intel.py ProcEnviron: ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic root=UUID=816ba687-c7bc-472a-aae3-89afe5cd0d54 ro quiet splash acpi_osi=Linux acpi_backlight=vendor RelatedPackageVersions: xserver-xorg 1:7.6+12ubuntu1 libdrm2 2.4.32-1ubuntu1 xserver-xorg-video-intel 2:2.17.0-1ubuntu4 SourcePackage: xserver-xorg-video-intel Title: [gm45] False GPU lockup render.IPEHR: 0x01820000 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: dmi.bios.date: 08/05/2010 dmi.bios.vendor: Phoenix Technologies Ltd. dmi.bios.version: 10LM.M014.20100805.KSY dmi.board.name: X360 dmi.board.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: SAMSUNG ELECTRONICS CO., LTD. dmi.chassis.version: N/A dmi.modalias: dmi:bvnPhoenixTechnologiesLtd.:bvr10LM.M014.20100805.KSY:bd08/05/2010:svnSAMSUNGELECTRONICSCO.,LTD.:pnX360:pvrNotApplicable:rvnSAMSUNGELECTRONICSCO.,LTD.:rnX360:rvrNotApplicable:cvnSAMSUNGELECTRONICSCO.,LTD.:ct10:cvrN/A: dmi.product.name: X360 dmi.product.version: Not Applicable dmi.sys.vendor: SAMSUNG ELECTRONICS CO., LTD. version.compiz: compiz 1:0.9.7.4-0ubuntu3 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.32-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu3 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu3 version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu10 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2
Created attachment 60206 [details] BootDmesg.txt
Created attachment 60207 [details] CurrentDmesg.txt
Created attachment 60208 [details] i915_error_state.txt
Created attachment 60209 [details] XorgLog.txt
commit 14667a4bde4361b7ac420d68a2e9e9b9b2df5231 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 3 17:58:35 2012 +0100 drm/i915: Finish any pending operations on the framebuffer before disabling Similar to the case where we are changing from one framebuffer to another, we need to be sure that there are no pending WAIT_FOR_EVENTs on the pipe for the current framebuffer before switching. If we disable the pipe, and then try to execute a WAIT_FOR_EVENT it will block indefinitely and cause a GPU hang. And a few patches to the DDX to shrink the race.
Which DDX patches?
In this particular case, just the kernel patch should be sufficient. In the general case, the ddx needs: commit b817200371bfe16f44b879a793cf4a75ad17bc5c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 17 17:54:58 2012 +0100 Don't issue a scanline wait while VT switched and commit cc20c45aa0ca15720510668d6918bf3c99104626 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Mar 30 22:51:21 2012 +0100 sna: Minimise the risk of hotplug hangs by checking fb before vsync (which is just papering over the bugs).
Thanks; we don't ship/support sna but will look into the other ddx patch.
And the last patch landed in drm-intel-next-queued: commit 0f91128d88bbb8b0a8e7bb93df2c40680871d45a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 17 10:05:38 2012 +0100 drm/i915: Wait for all pending operations to the fb before disabling the pip During modeset we have to disable the pipe to reconfigure its timings and maybe its size. Userspace may have queued up command buffers that depend upon the pipe running in a certain configuration and so the commands may become confused across the modeset. At the moment, we use a less than satisfactory kick-scanline-waits should the GPU hang during the modeset. It should be more reliable to wait for the pending operations to complete first, even though we still have a window for userspace to submit a broken command buffer during the modeset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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.