Created attachment 36133 [details] dmesg file System Environment: -------------------------- Arch: x86-64 Platform: piketon Libdrm:(master)2.4.20-20-g66375fd6e8d3e95df5d124883a1426460c1b8ed8 Mesa: (master)mesa_7_6_1_rc1-8672-gb4483823d9c1205fb9ab8cf5b4c36ee610347a36 Xserver: (master)xorg-server-1.8.0-361gbc26665661565918af484ccd17caad951010df60 Xf86_video_intel: (master)2.11.0-156-gd56ea7a852d7090360fe080acec268de55ee908d Kernel: for-linus)e3a815fcd38043b8f1bb526123d8ab6ae01deb77 Bug detailed description: ------------------------- When DPMS on, start X with ssh console, screen blank and GPU hang, if trying to kill X, system will hang. This issue happens on piketon. On other platform, When DPMS on, start X with ssh console, screen blank but GPU not hang, If kill X and restart it, erverything is ok. Reproduce steps: ---------------- 1. start system to text console 2. run “setterm –blank 1” 3. wait for 1 minute, after screen goes to blank, start X with ssh console
Created attachment 36134 [details] xorg log
Created attachment 36135 [details] dmesg file
Created attachment 36136 [details] xorg log
dmesg says: Pid: 3127, comm: X Not tainted 2.6.34-rc6_unstable_20100514 #1 H55M-UD2H/H55M-UD2H RIP: 0010:[<ffffffffa008f042>] [<ffffffffa008f042>] intel_crt_detect+0xb8/0x222 [i915] RSP: 0018:ffff88006b23fc18 EFLAGS: 00000286 RAX: 0000000083f50010 RBX: ffff88006b23fc58 RCX: ffffffffa00a5925 RDX: ffffffffa009ef90 RSI: ffffffffa00a5937 RDI: 0000000000000004 RBP: ffffffff810033ce R08: 0000000080f50010 R09: 000000000000000a R10: 0000000000000000 R11: 0000000000018600 R12: ffffffff811cc5b1 R13: ffff88006b23fbe8 R14: ffffffffa004cad0 R15: ffffffffa004caf0 FS: 00007fab110f4830(0000) GS:ffff880001a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000001cca238 CR3: 0000000072786000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process X (pid: 3127, threadinfo ffff88006b23e000, task ffff88006b282da0) Stack: ffff88006b2033c0 ffff880072218f00 ffff88006b23fc38 0000000000002000 <0> ffff880071e02800 0000000000002000 ffff880071e029a8 ffff88006eabfe40 <0> ffff88006b23fca8 ffffffffa006a185 fffffffffffffffd ffffffffa009ef70 Call Trace: [<ffffffffa006a185>] ? drm_helper_probe_single_connector_modes+0xc0/0x299 [drm_kms_helper] [<ffffffffa003cf05>] ? drm_mode_getconnector+0xef/0x3b9 [drm] [<ffffffff811c5bfa>] ? idr_get_new_above+0x11/0x31 [<ffffffffa00847fb>] ? i915_gem_create_ioctl+0x6e/0x8a [i915] [<ffffffffa003119e>] ? drm_ioctl+0x260/0x364 [drm] [<ffffffff810cb81e>] ? page_add_new_anon_rmap+0x75/0x88 [<ffffffffa003ce16>] ? drm_mode_getconnector+0x0/0x3b9 [drm] [<ffffffff810f11f4>] ? vfs_ioctl+0x2a/0x9e [<ffffffff810f1860>] ? do_vfs_ioctl+0x55b/0x59c [<ffffffff810f18f6>] ? sys_ioctl+0x55/0x77 [<ffffffff81002a6b>] ? system_call_fastpath+0x16/0x1b Code: 09 a0 48 c7 c6 37 59 0a a0 bf 04 00 00 00 e8 5d 68 fa ff 49 8b 45 18 48 05 00 11 0e 00 89 18 49 8b 45 18 48 05 00 11 0e 00 8b 00 <a9> 00 00 01 00 75 ed 49 8b 45 18 48 05 00 11 0e 00 8b 00 25 00 Call Trace: [<ffffffffa006a185>] ? drm_helper_probe_single_connector_modes+0xc0/0x299 [drm_kms_helper] [<ffffffffa003cf05>] ? drm_mode_getconnector+0xef/0x3b9 [drm] [<ffffffff811c5bfa>] ? idr_get_new_above+0x11/0x31 [<ffffffffa00847fb>] ? i915_gem_create_ioctl+0x6e/0x8a [i915] [<ffffffffa003119e>] ? drm_ioctl+0x260/0x364 [drm] [<ffffffff810cb81e>] ? page_add_new_anon_rmap+0x75/0x88 [<ffffffffa003ce16>] ? drm_mode_getconnector+0x0/0x3b9 [drm] [<ffffffff810f11f4>] ? vfs_ioctl+0x2a/0x9e [<ffffffff810f1860>] ? do_vfs_ioctl+0x55b/0x59c [<ffffffff810f18f6>] ? sys_ioctl+0x55/0x77 [<ffffffff81002a6b>] ? system_call_fastpath+0x16/0x1b
Created attachment 36693 [details] [review] DPMS status fix Just pushed this fix upstream.
The problem still happens on piketon with the patch. The patch fix screen blank issue on other platforms. On piketon, system hangs soon after start X with ssh console when DPMS on. It's a hard hang.
Created attachment 37721 [details] dmesg file
In anholt/drm-intel-next the intel_ironlake_crt_detect_hotplug() is now bounded and will timeout instead of causing a hang. However, this should not be the root cause of the bug and the hang should just be replaced with an ERROR in dmesg.
intel_ironlake_crt_detect_hotplug() has been almost completely rewritten, in particular: commit d5dd96cb280993a6096b42ab082f9cfd9c7ae0bd Author: Dave Airlie <airlied@redhat.com> Date: Wed Aug 4 15:52:19 2010 +1000 i915: disable DAC on Ironlake also when doing CRT load detection. Like on Sandybridge, disabling the DAC here when doing CRT load detect avoids forever hangs waiting on the hardware. test procedure on HP 2740p: boot with no VGA plugged in, start X, plug in VGA monitor (1280x1024) chvt 3 machine hangs waiting forever. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net> in anholt/for-linus.
Can you please verify the bug is fixed on the http://cgit.freedesktop.org/~ickle/drm-intel/ drm-fixes branch.
The is fixed on the ~ickle/drm-intel/drm-intel-fixes branch.
It is also fixed on the anholt/for-linus branch. Mark it as verified.
Closing old verified.
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.