Description of problem: When hibernating, the machine doesn't really shut itself off and restarts immediately. Suspending to RAM works only one time, but USB is broken afterwards (the ports don't even have power), a second suspend/resume cycle hangs the machine. Version-Release number of selected component (if applicable): kernel-2.6.25-0.185.rc7.git6.fc9.x86_64 How reproducible: Reproducible Steps to Reproduce: I.1. Hibernate the system by clicking Shutdown/Hibernate or issuing the pm-hibernate command II.1 Suspend the system by clicking Shutdown/Suspend or issuing the pm-suspend command II.2 Resume the machine by opening the lid or pressing the power button II.3 (Repeat) Actual results: I. Doesn't shut down the machine, but resumes immediately II. After resuming for the first time, USB is broken (powerless), attempts to "modprobe -r" the probably offending ehci_hcd module hangs the modprobe command, no obvious telltales in "dmesg". Suspending/resuming for a second time hangs while resuming (SysRq S/U/B doesn't work). Expected results: Both suspend to disk and to RAM work flawalessly, USB works afterwards.
Created attachment 300196 [details] Output of "dmidecode"
Created attachment 300197 [details] Output of "lspci"
Created attachment 300198 [details] Output of "lspci -n"
Created attachment 300199 [details] Output of "lspci -v -n"
Created attachment 300200 [details] Output of "lspci -v"
NB: it seems that suspend/resume killed USB only on the third cycle this time.
NB: I just attempted to hibernate now and found next to no disk activity before it dropped me into the screensaver again, which is a bit dubious to me given that the system uses >800MB of RAM right now without buffers/cache.
NB: STR doesn suspend anymore as well, time to try out if 2.6.25-0.195.rc8.git1.fc9 improves things...
kernel-2.6.25-0.195.rc8.git1.fc9.x86_64 doesn't improve things on the hibernation/STD side of things, trying out suspend/STR (will probably take some time as the problems only showed after resuming for the seoncd or third time...).
No improvements with kernel-2.6.25-0.204.rc8.git4.fc9.x86_64.
Hibernate isn't better with kernel-2.6.25-0.218.rc8.git7.fc9.x86_64.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
STR works with 2.6.25.9-76.fc9.x86_64, STD doesn't (doesn't even seem to write memory to disk, can't really say because the screen is black with only a blinking cursor during the suspend operation). Is there any additional information that you need to work on this?
Something similar happens to me, only on second suspend attempt: bug 473864
The story continues on F11: kernel-2.6.29.4-167.fc11.x86_64 kernel-2.6.29.4-168.fc11.x86_64 STR seems to work, but sometimes after I resumed, I get "Disabling IRQ #17"(*) on dmesg and things go on very sluggishly from there. STD still doesn't work, this time it also screws up the X11 mouse cursor (which got restored when I used GIMP to capture a screenshot of it ;-). Has somebody even looked at this? It's been going on for over a year without reaction. (*): more complete log snip, and no I wouldn't know what tainted my kernel: --- 8< --- Jun 3 18:16:17 gibraltar kernel: PM: Syncing filesystems ... done. Jun 4 10:51:17 gibraltar kernel: Freezing user space processes ... (elapsed 0.03 seconds) done. Jun 4 10:51:17 gibraltar kernel: Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. Jun 4 10:51:17 gibraltar kernel: Suspending console(s) (use no_console_suspend to debug) Jun 4 10:51:17 gibraltar kernel: sd 2:0:0:0: [sda] Synchronizing SCSI cache Jun 4 10:51:17 gibraltar kernel: sd 2:0:0:0: [sda] Stopping disk Jun 4 10:51:17 gibraltar kernel: serial 00:09: disabled Jun 4 10:51:17 gibraltar kernel: ata_piix 0000:00:1f.2: PCI INT B disabled Jun 4 10:51:17 gibraltar kernel: ata_piix 0000:00:1f.1: PCI INT A disabled Jun 4 10:51:17 gibraltar kernel: ehci_hcd 0000:00:1d.7: PCI INT A disabled Jun 4 10:51:17 gibraltar kernel: ehci_hcd 0000:00:1d.7: PME# disabled Jun 4 10:51:17 gibraltar kernel: uhci_hcd 0000:00:1d.2: PCI INT C disabled Jun 4 10:51:17 gibraltar kernel: uhci_hcd 0000:00:1d.1: PCI INT B disabled Jun 4 10:51:17 gibraltar kernel: uhci_hcd 0000:00:1d.0: PCI INT A disabled Jun 4 10:51:17 gibraltar kernel: HDA Intel 0000:00:1b.0: PCI INT A disabled Jun 4 10:51:17 gibraltar kernel: ehci_hcd 0000:00:1a.7: PCI INT C disabled Jun 4 10:51:17 gibraltar kernel: ehci_hcd 0000:00:1a.7: PME# disabled Jun 4 10:51:17 gibraltar kernel: uhci_hcd 0000:00:1a.1: PCI INT B disabled Jun 4 10:51:17 gibraltar kernel: uhci_hcd 0000:00:1a.0: PCI INT A disabled Jun 4 10:51:17 gibraltar kernel: [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0 Jun 4 10:51:17 gibraltar kernel: ACPI: Preparing to enter system sleep state S3 Jun 4 10:51:17 gibraltar kernel: Disabling non-boot CPUs ... Jun 4 10:51:17 gibraltar kernel: kvm: disabling virtualization on CPU1 Jun 4 10:51:17 gibraltar kernel: CPU 1 is now offline Jun 4 10:51:17 gibraltar kernel: SMP alternatives: switching to UP code Jun 4 10:51:17 gibraltar kernel: CPU1 is down Jun 4 10:51:17 gibraltar kernel: Extended CMOS year: 2000 Jun 4 10:51:17 gibraltar kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 Jun 4 10:51:17 gibraltar kernel: CPU0: Thermal monitoring enabled (TM2) Jun 4 10:51:17 gibraltar kernel: Extended CMOS year: 2000 Jun 4 10:51:17 gibraltar kernel: Enabling non-boot CPUs ... Jun 4 10:51:17 gibraltar kernel: SMP alternatives: switching to SMP code Jun 4 10:51:17 gibraltar kernel: Booting processor 1 APIC 0x1 ip 0x6000 Jun 4 10:51:17 gibraltar kernel: Initializing CPU#1 Jun 4 10:51:17 gibraltar kernel: Calibrating delay using timer specific routine.. 4789.56 BogoMIPS (lpj=2394781) Jun 4 10:51:17 gibraltar kernel: CPU: L1 I cache: 32K, L1 D cache: 32K Jun 4 10:51:17 gibraltar kernel: CPU: L2 cache: 4096K Jun 4 10:51:17 gibraltar kernel: CPU 1/0x1 -> Node 0 Jun 4 10:51:17 gibraltar kernel: CPU: Physical Processor ID: 0 Jun 4 10:51:17 gibraltar kernel: CPU: Processor Core ID: 1 Jun 4 10:51:17 gibraltar kernel: CPU1: Thermal monitoring enabled (TM2) Jun 4 10:51:17 gibraltar kernel: x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106 Jun 4 10:51:17 gibraltar kernel: CPU1: Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz stepping 0a Jun 4 10:51:17 gibraltar kernel: kvm: enabling virtualization on CPU1 Jun 4 10:51:17 gibraltar kernel: CPU1 is up Jun 4 10:51:17 gibraltar kernel: ACPI: Waking up from system sleep state S3 Jun 4 10:51:17 gibraltar kernel: [drm] LVDS-8: set mode 1680x1050 17 Jun 4 10:51:17 gibraltar kernel: irq 17: nobody cared (try booting with the "irqpoll" option) Jun 4 10:51:17 gibraltar kernel: Pid: 11903, comm: pm-suspend Tainted: G D 2.6.29.4-167.fc11.x86_64 #1 Jun 4 10:51:17 gibraltar kernel: Call Trace: Jun 4 10:51:17 gibraltar kernel: <IRQ> [<ffffffff8108d209>] __report_bad_irq+0x3d/0x8c Jun 4 10:51:17 gibraltar kernel: [<ffffffff8108d370>] note_interrupt+0x118/0x17c Jun 4 10:51:17 gibraltar kernel: [<ffffffff8108da33>] handle_fasteoi_irq+0xa7/0xde Jun 4 10:51:17 gibraltar kernel: [<ffffffff81013ba4>] do_IRQ+0xd9/0x151 Jun 4 10:51:17 gibraltar kernel: [<ffffffff81011e93>] ret_from_intr+0x0/0x2e Jun 4 10:51:17 gibraltar kernel: <EOI> [<ffffffffa0066a42>] ? intel_lvds_set_power+0x32/0x94 [i915] Jun 4 10:51:17 gibraltar kernel: [<ffffffffa0066c7a>] ? intel_lvds_commit+0x3b/0x3d [i915] Jun 4 10:51:17 gibraltar kernel: [<ffffffffa002f5dc>] ? drm_crtc_helper_set_mode+0x2e4/0x35a [drm] Jun 4 10:51:17 gibraltar kernel: [<ffffffffa002f694>] ? drm_helper_resume_force_mode+0x42/0x7b [drm] Jun 4 10:51:17 gibraltar kernel: [<ffffffffa005c731>] ? i915_restore_state+0xba5/0xbaf [i915] Jun 4 10:51:17 gibraltar kernel: [<ffffffffa0058076>] ? i915_resume+0x5f/0xc6 [i915] Jun 4 10:51:17 gibraltar kernel: [<ffffffffa00580f2>] ? i915_pci_resume+0x15/0x17 [i915] Jun 4 10:51:17 gibraltar kernel: [<ffffffff811c5db7>] ? pci_legacy_resume+0x38/0x47 Jun 4 10:51:17 gibraltar kernel: [<ffffffff811c5f10>] ? pci_pm_resume+0x54/0x87 Jun 4 10:51:17 gibraltar kernel: [<ffffffff81256ad0>] ? pm_op+0x6b/0xea Jun 4 10:51:17 gibraltar kernel: [<ffffffff81257457>] ? device_resume+0xd5/0x38e Jun 4 10:51:17 gibraltar kernel: [<ffffffff81070271>] ? suspend_devices_and_enter+0x16f/0x1ab Jun 4 10:51:17 gibraltar kernel: [<ffffffff81070437>] ? enter_state+0x15c/0x1c1 Jun 4 10:51:17 gibraltar kernel: [<ffffffff81070552>] ? state_store+0xb6/0xd4 Jun 4 10:51:17 gibraltar kernel: [<ffffffff811b3813>] ? kobj_attr_store+0x17/0x19 Jun 4 10:51:17 gibraltar kernel: [<ffffffff8112444b>] ? sysfs_write_file+0xf7/0x133 Jun 4 10:51:17 gibraltar kernel: [<ffffffff810d58fb>] ? vfs_write+0xae/0x10b Jun 4 10:51:17 gibraltar kernel: [<ffffffff810d5a18>] ? sys_write+0x4a/0x6e Jun 4 10:51:17 gibraltar kernel: [<ffffffff8101133a>] ? system_call_fastpath+0x16/0x1b Jun 4 10:51:17 gibraltar kernel: handlers: Jun 4 10:51:17 gibraltar kernel: [<ffffffff812881cc>] (ata_sff_interrupt+0x0/0xc9) Jun 4 10:51:17 gibraltar kernel: Disabling IRQ #17 Jun 4 10:51:17 gibraltar kernel: pci 0000:00:02.1: PME# disabled Jun 4 10:51:17 gibraltar kernel: uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 Jun 4 10:51:17 gibraltar kernel: usb usb3: root hub lost power or was reset Jun 4 10:51:17 gibraltar kernel: uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21 Jun 4 10:51:17 gibraltar kernel: usb usb4: root hub lost power or was reset Jun 4 10:51:17 gibraltar kernel: ehci_hcd 0000:00:1a.7: PME# disabled Jun 4 10:51:17 gibraltar kernel: ehci_hcd 0000:00:1a.7: PCI INT C -> GSI 22 (level, low) -> IRQ 22 Jun 4 10:51:17 gibraltar kernel: ehci_hcd 0000:00:1a.7: PME# disabled Jun 4 10:51:17 gibraltar kernel: HDA Intel 0000:00:1b.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 Jun 4 10:51:17 gibraltar kernel: uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 --- >8 ---
FYI: This IRQ problem doesn't occur if I add "irqpoll" to the kernel command line.
(In reply to comment #16) > FYI: This IRQ problem doesn't occur if I add "irqpoll" to the kernel command > line. Not really :-(. After resuming from a STR, the system sooner or later runs into "Disabling IRQ #17" and becomes unusably slow once it tries to access the internal disk.
The restart problem is happening with my DELL inspiron 1525 on fedora 11, it had worked before (maybe on fedora 10).
I've resorted to using an F-10 kernel and with kernel-2.6.29.6-93.fc10.x86_64 (everything else is F-11), resuming from STR works again (without the snail-like qualities of all the F-11 kernels I tried). Oh, and I'd really appreciated if some kernel maintainer at least acknowledged that there is a problem. Granted, things haven't been this bad before F-11 but this bug has been sitting in "NEW" for 1 1/2 years without any maintainer reaction whatsoever, which is entirely too long.
Fedora 12 and kernel 2.6.31.5-127.fc12.x86_64. STR shows the same interrupt disabling symptoms that F-11 kernels did. STD is not that clear cut: Using the internal WLAN, 1. Hibernate (suspend to disk)... 2. ... and resume several times 3. Resuming gives frozen display (screensaver with non-moving pointer) Blindly: 4. Alt+SysRq+R (Unraw keyboard) 5. Ctrl+Alt+F2 6. Ctrl+Alt+Delete to Reboot Then abrt flags this (but doesn't let me submit this into BZ directly, oh joy). Nov 26 09:53:15 gibraltar kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Nov 26 09:53:15 gibraltar kernel: IP: [<ffffffff810c90c1>] file_ra_state_init+0xd/0x1d Nov 26 09:53:15 gibraltar kernel: PGD 355eb067 PUD acdc9067 PMD 0 Nov 26 09:53:15 gibraltar kernel: Oops: 0000 [#1] SMP Nov 26 09:53:15 gibraltar kernel: last sysfs file: /sys/devices/virtual/block/ram11/uevent Nov 26 09:53:15 gibraltar kernel: CPU 0 Nov 26 09:53:15 gibraltar kernel: Modules linked in: rfcomm sco bnep l2cap btusb bluetooth fuse bridge stp llc sunrpc autofs4 coretemp ipv6 ipt_LOG xt_limit ipt_MASQUERADE iptable_nat nf_nat iptable_mangle cpufreq_ondemand acpi_cpufreq freq_table dm_multipath sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt kvm_intel kvm uinput snd_hda_codec_idt arc4 snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device ecb ppdev iwlagn snd_pcm dell_laptop iwlcore parport_pc mac80211 snd_timer firewire_ohci cfg80211 rfkill firewire_core crc_itu_t parport iTCO_wdt iTCO_vendor_support joydev i2c_i801 dcdbas snd soundcore snd_page_alloc tg3 wmi yenta_socket rsrc_nonstatic i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: microcode] Nov 26 09:53:15 gibraltar kernel: Pid: 12564, comm: udev-acl.ck Not tainted 2.6.31.5-127.fc12.x86_64 #1 Latitude D830 Nov 26 09:53:15 gibraltar kernel: RIP: 0010:[<ffffffff810c90c1>] [<ffffffff810c90c1>] file_ra_state_init+0xd/0x1d Nov 26 09:53:15 gibraltar kernel: RSP: 0018:ffff880100103d58 EFLAGS: 00010206 Nov 26 09:53:15 gibraltar kernel: RAX: 0000000000000000 RBX: ffff88011846a800 RCX: 0000000000100002 Nov 26 09:53:15 gibraltar kernel: RDX: 0000000000000000 RSI: ffff880117f42768 RDI: ffff8800b38bd7f0 Nov 26 09:53:15 gibraltar kernel: RBP: ffff880100103d58 R08: ffff880100103c68 R09: 0000000000000000 Nov 26 09:53:15 gibraltar kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff88011b493240 Nov 26 09:53:15 gibraltar kernel: R13: ffff8800b38bd780 R14: 0000000000000000 R15: ffff880117f42650 Nov 26 09:53:15 gibraltar kernel: FS: 00007f5306e4c700(0000) GS:ffff88002801f000(0000) knlGS:0000000000000000 Nov 26 09:53:15 gibraltar kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Nov 26 09:53:15 gibraltar kernel: CR2: 0000000000000000 CR3: 00000000b0810000 CR4: 00000000000026f0 Nov 26 09:53:15 gibraltar kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Nov 26 09:53:15 gibraltar kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Nov 26 09:53:15 gibraltar kernel: Process udev-acl.ck (pid: 12564, threadinfo ffff880100102000, task ffff8800860e0000) Nov 26 09:53:15 gibraltar kernel: Stack: Nov 26 09:53:15 gibraltar kernel: ffff880100103da8 ffffffff810fad04 ffff880100103e28 ffff8801010f6600 Nov 26 09:53:15 gibraltar kernel: <0> ffff880100103dc8 0000000000008001 0000000000000024 0000000000000000 Nov 26 09:53:15 gibraltar kernel: <0> ffff880100103e28 0000000000000000 ffff880100103dc8 ffffffff810faede Nov 26 09:53:15 gibraltar kernel: Call Trace: Nov 26 09:53:15 gibraltar kernel: [<ffffffff810fad04>] __dentry_open+0x162/0x26c Nov 26 09:53:15 gibraltar kernel: [<ffffffff810faede>] nameidata_to_filp+0x42/0x53 Nov 26 09:53:15 gibraltar kernel: [<ffffffff81106c32>] do_filp_open+0x4ec/0x967 Nov 26 09:53:15 gibraltar kernel: [<ffffffff811118f5>] ? mntput_no_expire+0x29/0xec Nov 26 09:53:15 gibraltar kernel: [<ffffffff81202544>] ? might_fault+0x1f/0x21 Nov 26 09:53:15 gibraltar kernel: [<ffffffff81202643>] ? __strncpy_from_user+0x1e/0x49 Nov 26 09:53:15 gibraltar kernel: [<ffffffff811100a3>] ? alloc_fd+0x7b/0x124 Nov 26 09:53:15 gibraltar kernel: [<ffffffff810faaaa>] do_sys_open+0x63/0x10f Nov 26 09:53:15 gibraltar kernel: [<ffffffff810fab89>] sys_open+0x20/0x22 Nov 26 09:53:15 gibraltar kernel: [<ffffffff81011cf2>] system_call_fastpath+0x16/0x1b Nov 26 09:53:15 gibraltar kernel: Code: 4c 89 ee 48 c7 c7 14 58 94 81 e8 6b 1a 35 00 5b 44 89 e0 41 5c 41 5d 41 5e c9 c3 90 90 90 55 48 89 e5 0f 1f 44 00 00 48 8b 46 68 <48> 8b 00 48 c7 47 18 ff ff ff ff 89 47 10 c9 c3 55 48 89 e5 41 Nov 26 09:53:15 gibraltar kernel: RIP [<ffffffff810c90c1>] file_ra_state_init+0xd/0x1d Nov 26 09:53:15 gibraltar kernel: RSP <ffff880100103d58> Nov 26 09:53:15 gibraltar kernel: CR2: 0000000000000000 Nov 26 09:53:15 gibraltar kernel: ---[ end trace 71e4b55c3e5bdfdf ]---
STD seems to have recovered a bit with 2.6.31.6-166.fc12.x86_64 -- the machine still freezes occasionally (after, not during resuming) but I don't know whether that are hibernation side-effects or something unrelated.
With these kernels, I observe that while suspending and resuming from disk works on most cases, the CPU frequency is fixed to 800MHz (the CPU is capable of scaling from 800MHz to 2.4GHz). This was not the case with previous F-12 kernels.
Oops: "With these kernels..." --> kernel-2.6.31.12-174.2.22.fc12.x86_64 kernel-2.6.32.9-67.fc12.x86_64 I haven't seen this behaviour with kernel-2.6.31.12-174.2.19.fc12.x86_64, though (but it might have slipped by me unnoticed).
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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
I don't know if this is related, but on my Dell830 with Fedora 13, the computer does not always come back from suspend, and the problem here seems to be a problem with the i915 driver: Nov 10 05:36:59 mslap kernel: kernel BUG at drivers/gpu/drm/i915/i915_gem.c:4201! Nov 10 05:36:59 mslap kernel: invalid opcode: 0000 [#1] SMP Nov 10 05:36:59 mslap kernel: last sysfs file: /sys/power/state Nov 10 05:36:59 mslap kernel: Modules linked in: tcp_lp tun vfat fat usb_storage cpufreq_stats fuse rfcomm sco bridge stp llc bnep l2cap sunrpc cpufreq_ondemand acpi_cpufreq ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_idt snd_hda_intel arc4 snd_hda_codec ecb snd_hwdep snd_seq iwlagn snd_seq_device i2c_i801 snd_pcm btusb iTCO_wdt bluetooth dell_laptop snd_timer snd iwlcore mac80211 iTCO_vendor_support cfg80211 rfkill soundcore snd_page_alloc tg3 dcdbas dell_wmi wmi joydev firewire_ohci firewire_core crc_itu_t yenta_socket rsrc_nonstatic i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: scsi_wait_scan] Nov 10 05:36:59 mslap kernel: Nov 10 05:36:59 mslap kernel: Pid: 1576, comm: X Not tainted 2.6.34.7-61.fc13.i686 #1 /Latitude D830 Nov 10 05:36:59 mslap kernel: EIP: 0060:[<f7e62f23>] EFLAGS: 00013282 CPU: 0 Nov 10 05:36:59 mslap kernel: EIP is at i915_gem_object_unpin+0x41/0x8a [i915] Nov 10 05:36:59 mslap kernel: EAX: fffffff8 EBX: f017b600 ECX: 000214ab EDX: f6ca2000 Nov 10 05:36:59 mslap kernel: ESI: f6d7e400 EDI: 00020000 EBP: f1d4ddc0 ESP: f1d4ddb4 Nov 10 05:36:59 mslap kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Nov 10 05:36:59 mslap kernel: Process X (pid: 1576, ti=f1d4c000 task=eee30cc0 task.ti=f1d4c000) Nov 10 05:36:59 mslap kernel: Stack: Nov 10 05:36:59 mslap kernel: 00000001 00000000 f1d1f1e0 f1d4de3c f7e67bdb 00000001 f6ca2000 00000000 Nov 10 05:36:59 mslap kernel: <0> 000001d6 00000012 eb2cf000 04a201e0 f0554380 f6d7e414 00000000 04a20000 Nov 10 05:36:59 mslap kernel: <0> 00000000 f6ca2014 c097c198 fcae9000 f6ca2fec 00000016 f1d1f1e0 00000016 Nov 10 05:36:59 mslap kernel: Call Trace: Nov 10 05:36:59 mslap kernel: [<f7e67bdb>] ? i915_gem_do_execbuffer+0xaa1/0xbc9 [i915] Nov 10 05:36:59 mslap kernel: [<c05abd40>] ? might_fault+0x1e/0x20 Nov 10 05:36:59 mslap kernel: [<c05abeb7>] ? _copy_from_user+0x36/0x119 Nov 10 05:36:59 mslap kernel: [<f7e67da4>] ? i915_gem_execbuffer2+0xa1/0xe7 [i915] Nov 10 05:36:59 mslap kernel: [<f7d43ad8>] ? drm_ioctl+0x26d/0x359 [drm] Nov 10 05:36:59 mslap kernel: [<f7e67d03>] ? i915_gem_execbuffer2+0x0/0xe7 [i915] Nov 10 05:36:59 mslap kernel: [<c0576e80>] ? file_has_perm+0x8c/0xa6 Nov 10 05:36:59 mslap kernel: [<c04dc67d>] ? vfs_ioctl+0x2c/0x96 Nov 10 05:36:59 mslap kernel: [<f7d4386b>] ? drm_ioctl+0x0/0x359 [drm] Nov 10 05:36:59 mslap kernel: [<c04dcc13>] ? do_vfs_ioctl+0x488/0x4c6 Nov 10 05:36:59 mslap kernel: [<c0577124>] ? selinux_file_ioctl+0x43/0x46 Nov 10 05:36:59 mslap kernel: [<c04dcc97>] ? sys_ioctl+0x46/0x66 Nov 10 05:36:59 mslap kernel: [<c0790944>] ? syscall_call+0x7/0xb Nov 10 05:36:59 mslap kernel: Code: 89 c3 89 c8 81 e1 ff 3f fc ff c1 e0 0e 8b 96 40 02 00 00 c1 f8 1c 48 c1 e0 04 c0 f8 04 21 c7 c1 e7 0e 09 f9 84 c0 89 4b 68 79 04 <0f> 0b eb fe 83 7b 54 00 75 04 0f 0b eb fe 81 e1 00 c0 03 00 75 Nov 10 05:36:59 mslap kernel: EIP: [<f7e62f23>] i915_gem_object_unpin+0x41/0x8a [i915] SS:ESP 0068:f1d4ddb4
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.