Description of problem: X11 locks up (usually after hibernate/thaw cycle) the system. The machine is not accessible from the outside either (i.e. SSH access doesn't work any more). The only thing I was able to find is the kernel error in the log below. The disk activity appears to continue for a while, even after the lock up. This is on Lenovo ThinkPad T510, hardware: http://www.smolts.org/client/show/pub_ebd16c9b-ba21-4d39-964a-cfd361713146 Version-Release number of selected component (if applicable): kernel-2.6.34.7-56.fc13.x86_64 (but seen symptoms with the previous kernel too) How reproducible: Sometimes. Steps to Reproduce: 1. Hibernate/thaw from X11 on Intel graphics 2. X11 hangs the system. Actual results: Hangs. Expected results: Shouldn't hang. Additional info: Sep 20 22:34:18 shrek kernel: general protection fault: 0000 [#1] SMP Sep 20 22:34:18 shrek kernel: last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/PNP0C09:00/PNP0C0A:00/power_supply/BAT0/voltage_now Sep 20 22:34:18 shrek kernel: CPU 3 Sep 20 22:34:18 shrek kernel: Modules linked in: nfs lockd fscache nfs_acl auth_rpcgss nls_utf8 udf fuse rfcomm sco bridge stp llc bnep l2cap autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table ipv6 uinput arc4 snd_hda_codec_intelhdmi ecb btusb snd_hda_intel bluetooth snd_hda_codec iwlagn uvcvideo videodev snd_hwdep sdhci_pci sdhci snd_seq snd_seq_device e1000e iwlcore v4l1_compat thinkpad_acpi iTCO_wdt mac80211 snd_pcm cfg80211 snd_timer joydev v4l2_compat_ioctl32 mmc_core microcode snd rfkill iTCO_vendor_support i2c_i801 wmi soundcore snd_page_alloc firewire_ohci firewire_core crc_itu_t i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] Sep 20 22:34:18 shrek kernel: Sep 20 22:34:18 shrek kernel: Pid: 9763, comm: Xorg Not tainted 2.6.34.7-56.fc13.x86_64 #1 4313CTO/4313CTO Sep 20 22:34:18 shrek kernel: RIP: 0010:[<ffffffff810ca1b4>] [<ffffffff810ca1b4>] page_cache_get_speculative+0xd/0x44 Sep 20 22:34:18 shrek kernel: RSP: 0018:ffff8801c6487a88 EFLAGS: 00010286 Sep 20 22:34:18 shrek kernel: RAX: 00aaaaaa00aaaaa9 RBX: ffffffffffffffff RCX: 0000000000000000 Sep 20 22:34:18 shrek kernel: RDX: 0000000000000000 RSI: 000000000000020b RDI: 00aaaaaa00aaaaaa Sep 20 22:34:18 shrek kernel: RBP: ffff8801c6487a98 R08: 00000000000a13d2 R09: 0000000000000002 Sep 20 22:34:18 shrek kernel: R10: 000000000000020a R11: ffff8801c6487ac8 R12: ffff8801e040b3f0 Sep 20 22:34:18 shrek kernel: R13: 000000000000020b R14: 00aaaaaa00aaaaaa R15: ffff88022dcc0700 Sep 20 22:34:18 shrek kernel: FS: 00007fe1f8430840(0000) GS:ffff880002180000(0000) knlGS:0000000000000000 Sep 20 22:34:18 shrek kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Sep 20 22:34:18 shrek kernel: CR2: 00007fe1f52c0000 CR3: 00000001afe6d000 CR4: 00000000000006e0 Sep 20 22:34:18 shrek kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Sep 20 22:34:18 shrek kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Sep 20 22:34:18 shrek kernel: Process Xorg (pid: 9763, threadinfo ffff8801c6486000, task ffff880223311770) Sep 20 22:34:18 shrek kernel: Stack: Sep 20 22:34:18 shrek kernel: 0000000000000000 000000000000020a ffff8801c6487ae8 ffffffff810cacee Sep 20 22:34:18 shrek kernel: <0> ffff8801c6487ac8 00aaaaaa00aaaaaa 00000000000a13d2 000000000000020b Sep 20 22:34:18 shrek kernel: <0> ffff8801e040b3e8 0000000000000500 00000000000a13d2 0000000000000000 Sep 20 22:34:18 shrek kernel: Call Trace: Sep 20 22:34:18 shrek kernel: [<ffffffff810cacee>] find_get_page+0x55/0x80 Sep 20 22:34:18 shrek kernel: [<ffffffff810cbca5>] do_read_cache_page+0x38/0x126 Sep 20 22:34:18 shrek kernel: [<ffffffff810dab43>] ? shmem_readpage+0x0/0x41 Sep 20 22:34:18 shrek kernel: [<ffffffff810cbdae>] read_cache_page_gfp+0x1b/0x25 Sep 20 22:34:18 shrek kernel: [<ffffffffa007dc65>] i915_gem_object_get_pages+0xe0/0x17b [i915] Sep 20 22:34:18 shrek kernel: [<ffffffffa00804db>] i915_gem_object_bind_to_gtt+0x195/0x2bb [i915] Sep 20 22:34:18 shrek kernel: [<ffffffffa0080925>] i915_gem_object_pin+0x9d/0x136 [i915] Sep 20 22:34:18 shrek kernel: [<ffffffffa0082208>] ? i915_gem_do_execbuffer+0x2d4/0xdd6 [i915] Sep 20 22:34:18 shrek kernel: [<ffffffffa0082443>] i915_gem_do_execbuffer+0x50f/0xdd6 [i915] Sep 20 22:34:18 shrek kernel: [<ffffffff810eed1a>] ? __vmalloc_node+0x82/0x92 Sep 20 22:34:18 shrek kernel: [<ffffffffa007d683>] ? might_fault+0x21/0x23 [i915] Sep 20 22:34:18 shrek kernel: [<ffffffffa0082dd8>] i915_gem_execbuffer2+0xce/0x12c [i915] Sep 20 22:34:18 shrek kernel: [<ffffffffa002c5f2>] drm_ioctl+0x26c/0x36a [drm] Sep 20 22:34:18 shrek kernel: [<ffffffffa0082d0a>] ? i915_gem_execbuffer2+0x0/0x12c [i915] Sep 20 22:34:18 shrek kernel: [<ffffffff81210828>] ? rb_erase+0x24f/0x277 Sep 20 22:34:18 shrek kernel: [<ffffffff8111aabf>] vfs_ioctl+0x32/0xa6 Sep 20 22:34:18 shrek kernel: [<ffffffff8111b032>] do_vfs_ioctl+0x483/0x4c9 Sep 20 22:34:18 shrek kernel: [<ffffffff81051508>] ? do_setitimer+0xc2/0x1e3 Sep 20 22:34:18 shrek kernel: [<ffffffff8111b0ce>] sys_ioctl+0x56/0x79 Sep 20 22:34:18 shrek kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b Sep 20 22:34:18 shrek kernel: Code: f2 ff ff ff 74 13 4c 89 06 49 2b 4b 08 eb 05 49 39 d8 72 ad 48 89 0a 31 c0 5b 41 5c c9 c3 55 48 89 e5 48 83 ec 10 0f 1f 44 00 00 <8b> 57 08 48 83 c7 08 85 d2 75 04 31 c0 eb 26 8d 42 01 89 55 f8 Sep 20 22:34:18 shrek kernel: RIP [<ffffffff810ca1b4>] page_cache_get_speculative+0xd/0x44 Sep 20 22:34:18 shrek kernel: RSP <ffff8801c6487a88> Sep 20 22:34:18 shrek kernel: ---[ end trace 44bd699dbb6dd1b8 ]---
same for me, nothing to find in he logs. I am on f14: Linux version 2.6.35.10-74.fc14.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 SMP Thu Dec 23 16:04:50 UTC 2010 It doesn't happen right after thawing, can take a few hours. No way to easily reproduce.
I'm also on F-14 now, but I haven't see this in a long, long time, if at all on F-14. Weird...
Me too, on F-13 and F-14.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping