Bug 440383 - Suspend/hibernate/resume does not work at all (Dell Latitude D830)
Suspend/hibernate/resume does not work at all (Dell Latitude D830)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Regression
Depends On:
Blocks: 513462
  Show dependency treegraph
 
Reported: 2008-04-03 04:46 EDT by Nils Philippsen
Modified: 2010-12-05 02:12 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 02:12:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of "dmidecode" (13.64 KB, text/plain)
2008-04-03 04:46 EDT, Nils Philippsen
no flags Details
Output of "lspci" (2.14 KB, text/plain)
2008-04-03 04:47 EDT, Nils Philippsen
no flags Details
Output of "lspci -n" (792 bytes, text/plain)
2008-04-03 04:48 EDT, Nils Philippsen
no flags Details
Output of "lspci -v -n" (8.92 KB, text/plain)
2008-04-03 04:48 EDT, Nils Philippsen
no flags Details
Output of "lspci -v" (10.65 KB, text/plain)
2008-04-03 04:49 EDT, Nils Philippsen
no flags Details

  None (edit)
Description Nils Philippsen 2008-04-03 04:46:36 EDT
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.
Comment 1 Nils Philippsen 2008-04-03 04:46:36 EDT
Created attachment 300196 [details]
Output of "dmidecode"
Comment 2 Nils Philippsen 2008-04-03 04:47:54 EDT
Created attachment 300197 [details]
Output of "lspci"
Comment 3 Nils Philippsen 2008-04-03 04:48:19 EDT
Created attachment 300198 [details]
Output of "lspci -n"
Comment 4 Nils Philippsen 2008-04-03 04:48:37 EDT
Created attachment 300199 [details]
Output of "lspci -v -n"
Comment 5 Nils Philippsen 2008-04-03 04:49:55 EDT
Created attachment 300200 [details]
Output of "lspci -v"
Comment 6 Nils Philippsen 2008-04-03 15:16:16 EDT
NB: it seems that suspend/resume killed USB only on the third cycle this time.
Comment 7 Nils Philippsen 2008-04-03 15:18:56 EDT
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.
Comment 8 Nils Philippsen 2008-04-03 15:22:49 EDT
NB: STR doesn suspend anymore as well, time to try out if
2.6.25-0.195.rc8.git1.fc9 improves things...
Comment 9 Nils Philippsen 2008-04-04 14:54:35 EDT
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...).
Comment 10 Nils Philippsen 2008-04-10 04:10:32 EDT
No improvements with kernel-2.6.25-0.204.rc8.git4.fc9.x86_64.
Comment 11 Nils Philippsen 2008-04-10 13:51:23 EDT
Hibernate isn't better with kernel-2.6.25-0.218.rc8.git7.fc9.x86_64.
Comment 12 Bug Zapper 2008-05-14 04:36:58 EDT
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
Comment 13 Nils Philippsen 2008-07-03 05:08:32 EDT
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?
Comment 14 ArmEagle 2009-02-04 08:46:15 EST
Something similar happens to me, only on second suspend attempt: bug 473864
Comment 15 Nils Philippsen 2009-06-04 06:36:44 EDT
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 ---
Comment 16 Nils Philippsen 2009-06-05 06:15:44 EDT
FYI: This IRQ problem doesn't occur if I add "irqpoll" to the kernel command line.
Comment 17 Nils Philippsen 2009-06-18 04:19:07 EDT
(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.
Comment 18 Victor Bogado 2009-06-24 11:31:32 EDT
The restart problem is happening with my DELL inspiron 1525 on fedora 11, it had worked before (maybe on fedora 10).
Comment 19 Nils Philippsen 2009-07-16 05:39:10 EDT
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.
Comment 20 Nils Philippsen 2009-11-26 04:47:42 EST
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 ]---
Comment 21 Nils Philippsen 2009-12-17 10:35:46 EST
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.
Comment 22 Nils Philippsen 2010-03-03 04:42:26 EST
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.
Comment 23 Nils Philippsen 2010-03-03 04:58:06 EST
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).
Comment 24 Bug Zapper 2010-11-04 07:58:07 EDT
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
Comment 25 Matthias Scheutz 2010-11-10 05:50:15 EST
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
Comment 26 Bug Zapper 2010-12-05 02:12:13 EST
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.

Note You need to log in before you can comment on or make changes to this bug.