Bug 197404 - Suspend to RAM and hibernate does not work
Suspend to RAM and hibernate does not work
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
: 197543 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-30 18:08 EDT by Orion Poplawski
Modified: 2008-02-23 03:31 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-23 03:31:16 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)
dmesg output (23.02 KB, text/plain)
2006-07-13 13:25 EDT, Orion Poplawski
no flags Details

  None (edit)
Description Orion Poplawski 2006-06-30 18:08:34 EDT
Description of problem:

New Dell Latitude D620 with Intel Core Duo and Intel 950 graphics.  Installed
FC6test1 and suspend to ram and hibernate didn't work.  Then upgraded to today's
(2006/06/30) development kernel 2.6.17-1.2336.fc6.  Still don't work, but much
different symptoms:

[root@leka ~]# pm-suspend
open: No such file or directory
/etc/pm/functions: line 191: echo: write error: Resource temporarily unavailable
[root@leka ~]# 
         
Unit starts to go into suspend mode, but comes back. dmesg:
 
PM: Preparing system for mem sleep
Freezing cpus ...
CPU 1 is now offline
SMP alternatives: switching to UP code
CPU1 is down
Stopping tasks:
==========================================================================
 stopping tasks timed out after 20 seconds (8 tasks remaining):
  rt-test-0
  rt-test-1
  rt-test-2
  rt-test-3
  rt-test-4
  rt-test-5
  rt-test-6
  rt-test-7
Restarting tasks...<6> Strange, rt-test-0 not stopped
 Strange, rt-test-1 not stopped
 Strange, rt-test-2 not stopped
 Strange, rt-test-3 not stopped
 Strange, rt-test-4 not stopped
 Strange, rt-test-5 not stopped
 Strange, rt-test-6 not stopped
 Strange, rt-test-7 not stopped
 done
Thawing cpus ...
SMP alternatives: switching to SMP code
Booting processor 1/1 eip 3000
CPU 1 irqstacks, hard=c07b2000 soft=c0792000
Initializing CPU#1
Calibrating delay using timer specific routine.. 3990.30 BogoMIPS (lpj=7980601)
CPU: After generic identify, caps: bfe9fbff 00100000 00000000 00000000 0000c1a9
00000000 00000000
CPU: After vendor identify, caps: bfe9fbff 00100000 00000000 00000000 0000c1a9
00000000 00000000
monitor/mwait feature present.
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU: After all inits, caps: bfe9f3ff 00100000 00000000 00000940 0000c1a9
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Genuine Intel(R) CPU           T2500  @ 2.00GHz stepping 08
CPU1 is up
ACPI: Lid Switch [LID]
ACPI: Power Button (CM) [PBTN]
ACPI: Sleep Button (CM) [SBTN]
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: HIDP (Human Interface Emulation) ver 1.1
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.7

Hibernate is similar:

[root@leka ~]# pm-hibernate
/etc/pm/functions: line 196: echo: write error: Device or resource busy
[root@leka ~]#

PM: suspend-to-disk mode set to 'platform'
Freezing cpus ...
CPU 1 is now offline
SMP alternatives: switching to UP code
CPU1 is down
Stopping tasks:
===========================================================================
 stopping tasks timed out after 20 seconds (8 tasks remaining):
  rt-test-0
  rt-test-1
  rt-test-2
  rt-test-3
  rt-test-4
  rt-test-5
  rt-test-6
  rt-test-7
Restarting tasks...<6> Strange, rt-test-0 not stopped
 Strange, rt-test-1 not stopped
 Strange, rt-test-2 not stopped
 Strange, rt-test-3 not stopped
 Strange, rt-test-4 not stopped
 Strange, rt-test-5 not stopped
 Strange, rt-test-6 not stopped
 Strange, rt-test-7 not stopped
 done
Thawing cpus ...
....
Comment 1 Alexandre Oliva 2006-07-04 10:41:13 EDT
*** Bug 197543 has been marked as a duplicate of this bug. ***
Comment 2 Alexandre Oliva 2006-07-04 10:42:28 EDT
According to Levin Fritz, in bug 197543 (sorry about the dupe),
kernel-2.6.17-1.2328.fc6 didn't have this problem.
Comment 3 Orion Poplawski 2006-07-06 13:09:08 EDT
Now trying with 2.6.17-1.2356.fc6.  Things still don't work for me, but they
behave differently.

With pm-suspend, the screen blanks, but never goes into suspend.  pm-suspend
hangs here:

+ pm-pmu --suspend
open: No such file or directory
+ echo -n mem

Perhaps a problem with the circular lock dependency reported in the testing
list?  I'm seeing that too.

dmesg from suspend shows:

PM: Preparing system for mem sleep
Freezing cpus ...
CPU 1 is now offline
lockdep: not fixing up alternatives.
Comment 4 Orion Poplawski 2006-07-07 16:44:02 EDT
Going back to FC5 and 2.6.17-1.2145_FC5smp, pm-suspend puts it into suspend, but
it does not recover.  Power light goes back solid and there is some activity,
but screen stays blank and network is unresponsive.

pm-hibernate likewise puts the unit into hibernate, but on boot it displays
"Resuming from /dev/sda7", then screen goes blank and unit reboots.

This is what I was getting on the D620 with rawhide before the rt-test-N issue
that I reported earlier showed up.
Comment 5 Orion Poplawski 2006-07-11 16:12:53 EDT
With 2.6.17-1.2364.fc6, pm-suspend still fails:

PM: Preparing system for mem sleep
Freezing cpus ...

=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
pm-suspend/2882 is trying to acquire lock:
 (&policy->lock){--..}, at: [<c060d4fd>] mutex_lock+0x21/0x24

but task is already holding lock:
 ((cpu_chain).rwsem){..--}, at: [<c0430dd6>] blocking_notifier_call_chain+0x11/0x2d

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #3 ((cpu_chain).rwsem){..--}:
       [<c043c54e>] lock_acquire+0x4b/0x6d
       [<c0439528>] down_read+0x2d/0x40
       [<c0430dd6>] blocking_notifier_call_chain+0x11/0x2d
       [<c043fa91>] cpu_up+0x41/0xb3
       [<c0400355>] init+0x81/0x29a
       [<c0402005>] kernel_thread_helper+0x5/0xb

-> #2 (cpucontrol){--..}:
       [<c043c54e>] lock_acquire+0x4b/0x6d
       [<c060d360>] __mutex_lock_slowpath+0xbf/0x23b
       [<c060d4fd>] mutex_lock+0x21/0x24
       [<c043f9ed>] __lock_cpu_hotplug+0x36/0x56
       [<c043fa26>] lock_cpu_hotplug+0xa/0xc
       [<c05a735c>] __cpufreq_driver_target+0x15/0x6d
       [<c05a82e8>] cpufreq_governor_userspace+0x199/0x1cc
       [<c05a6e03>] __cpufreq_governor+0x57/0xd8
       [<c05a701b>] __cpufreq_set_policy+0x197/0x1a9
       [<c05a705a>] cpufreq_set_policy+0x2d/0x6f
       [<c05a7a63>] cpufreq_add_dev+0x348/0x4c4
       [<c054ecd0>] sysdev_driver_register+0x7a/0xe5
       [<c05a6cfc>] cpufreq_register_driver+0x9e/0x14e
       [<c07b220b>] centrino_init+0x9b/0xa2
       [<c04003f0>] init+0x11c/0x29a
       [<c0402005>] kernel_thread_helper+0x5/0xb

-> #1 (userspace_mutex){--..}:
       [<c043c54e>] lock_acquire+0x4b/0x6d
       [<c060d360>] __mutex_lock_slowpath+0xbf/0x23b
       [<c060d4fd>] mutex_lock+0x21/0x24
       [<c05a81a2>] cpufreq_governor_userspace+0x53/0x1cc
       [<c05a6e03>] __cpufreq_governor+0x57/0xd8
       [<c05a6fc1>] __cpufreq_set_policy+0x13d/0x1a9
       [<c05a705a>] cpufreq_set_policy+0x2d/0x6f
       [<c05a7a63>] cpufreq_add_dev+0x348/0x4c4
       [<c054ecd0>] sysdev_driver_register+0x7a/0xe5
       [<c05a6cfc>] cpufreq_register_driver+0x9e/0x14e
       [<c07b220b>] centrino_init+0x9b/0xa2
       [<c04003f0>] init+0x11c/0x29a
       [<c0402005>] kernel_thread_helper+0x5/0xb

-> #0 (&policy->lock){--..}:
       [<c043c54e>] lock_acquire+0x4b/0x6d
       [<c060d360>] __mutex_lock_slowpath+0xbf/0x23b
       [<c060d4fd>] mutex_lock+0x21/0x24
       [<c05a73e0>] cpufreq_driver_target+0x2c/0x52
       [<c05a7c21>] cpufreq_cpu_callback+0x42/0x52
       [<c060fdf1>] notifier_call_chain+0x20/0x31
       [<c0430de2>] blocking_notifier_call_chain+0x1d/0x2d
       [<c043fb59>] cpu_down+0x56/0x1c5
       [<c0447908>] disable_nonboot_cpus+0x35/0xa1
       [<c044475e>] enter_state+0x90/0x1c3
       [<c0444917>] state_store+0x86/0x9c
       [<c04aaec8>] subsys_attr_store+0x20/0x25
       [<c04aafcc>] sysfs_write_file+0xab/0xd1
       [<c0471ef7>] vfs_write+0xab/0x157
       [<c047253a>] sys_write+0x3b/0x60
       [<c0403f77>] syscall_call+0x7/0xb

other info that might help us debug this:

2 locks held by pm-suspend/2882:
 #0:  (cpucontrol){--..}, at: [<c060d19a>] mutex_lock_interruptible+0x21/0x24
 #1:  ((cpu_chain).rwsem){..--}, at: [<c0430dd6>]
blocking_notifier_call_chain+0x11/0x2d

stack backtrace:
 [<c04051af>] show_trace_log_lvl+0x54/0xfd
 [<c0405766>] show_trace+0xd/0x10
 [<c0405885>] dump_stack+0x19/0x1b
 [<c043b63b>] print_circular_bug_tail+0x59/0x64
 [<c043be4e>] __lock_acquire+0x808/0x997
 [<c043c54e>] lock_acquire+0x4b/0x6d
 [<c060d360>] __mutex_lock_slowpath+0xbf/0x23b
 [<c060d4fd>] mutex_lock+0x21/0x24
 [<c05a73e0>] cpufreq_driver_target+0x2c/0x52
 [<c05a7c21>] cpufreq_cpu_callback+0x42/0x52
 [<c060fdf1>] notifier_call_chain+0x20/0x31
 [<c0430de2>] blocking_notifier_call_chain+0x1d/0x2d
 [<c043fb59>] cpu_down+0x56/0x1c5
 [<c0447908>] disable_nonboot_cpus+0x35/0xa1
 [<c044475e>] enter_state+0x90/0x1c3
 [<c0444917>] state_store+0x86/0x9c
 [<c04aaec8>] subsys_attr_store+0x20/0x25
 [<c04aafcc>] sysfs_write_file+0xab/0xd1
 [<c0471ef7>] vfs_write+0xab/0x157
 [<c047253a>] sys_write+0x3b/0x60
 [<c0403f77>] syscall_call+0x7/0xb
CPU 1 is now offline
lockdep: not fixing up alternatives.
Comment 6 Orion Poplawski 2006-07-13 13:25:52 EDT
Created attachment 132389 [details]
dmesg output

Updated to 2.6.17-1.2366.fc6.  No more lock messages, but suspend still doesn't
work.  Sending full dmesg (minus avc: messages - running in permissive mode).
Comment 7 Deji Akingunola 2006-09-22 01:25:37 EDT
Got a similar locking dependency as comment #5 with 2.6.18-1.2679.fc6, was
trying to hibernate, but failed to.

Sep 22 01:09:08 agape kernel: end_request: I/O error, dev fd0, sector 0
Sep 22 01:09:08 agape last message repeated 2 times
Sep 22 01:09:08 agape kernel: Disabling non-boot CPUs ...
Sep 22 01:09:08 agape restorecond: Read error (Interrupted system call)
Sep 22 01:09:08 agape kernel: Breaking affinity for irq 6
Sep 22 01:09:08 agape kernel: Breaking affinity for irq 14
Sep 22 01:09:08 agape kernel: Breaking affinity for irq 58
Sep 22 01:09:08 agape kernel: Breaking affinity for irq 217
Sep 22 01:09:08 agape kernel: Breaking affinity for irq 233
Sep 22 01:09:08 agape kernel: CPU 1 is now offline
Sep 22 01:09:08 agape kernel: lockdep: not fixing up alternatives.
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel:
=======================================================
Sep 22 01:09:08 agape kernel: [ INFO: possible circular locking dependency
detected ]
Sep 22 01:09:08 agape kernel: 2.6.18-1.2679.fc6 #1
Sep 22 01:09:08 agape kernel:
-------------------------------------------------------
Sep 22 01:09:08 agape kernel: pm-hibernate/3012 is trying to acquire lock:
Sep 22 01:09:08 agape kernel:  ((cpu_chain).rwsem){----}, at:
[<ffffffff8029e086>] blocking_notifier_call_chain+0x1b/0x41
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: but task is already holding lock:
Sep 22 01:09:08 agape kernel:  (workqueue_mutex){--..}, at: [<ffffffff802666af>]
mutex_lock+0x2a/0x2e
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: which lock already depends on the new lock.
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: the existing dependency chain (in reverse order) is:
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: -> #1 (workqueue_mutex){--..}:
Sep 22 01:09:08 agape kernel:        [<ffffffff802a975e>] lock_acquire+0x4a/0x69
Sep 22 01:09:08 agape kernel:        [<ffffffff80266508>]
__mutex_lock_slowpath+0xe4/0x261
Sep 22 01:09:08 agape kernel:        [<ffffffff802666ae>] mutex_lock+0x29/0x2e
Sep 22 01:09:08 agape kernel:        [<ffffffff802a127f>]
workqueue_cpu_callback+0x13f/0x26c
Sep 22 01:09:08 agape kernel:        [<ffffffff8026a3af>]
notifier_call_chain+0x28/0x3e
Sep 22 01:09:08 agape kernel:        [<ffffffff8029e094>]
blocking_notifier_call_chain+0x29/0x41
Sep 22 01:09:08 agape kernel:        [<ffffffff802ac930>] _cpu_down+0x58/0x26c
Sep 22 01:09:08 agape kernel:        [<ffffffff802acd92>]
disable_nonboot_cpus+0xe9/0x185
Sep 22 01:09:08 agape kernel:        [<ffffffff802b3b4a>]
prepare_processes+0x12/0x47
Sep 22 01:09:08 agape kernel:        [<ffffffff802b3eb2>] pm_suspend_disk+0xd/0x106
Sep 22 01:09:08 agape kernel:        [<ffffffff802b2ba1>] enter_state+0x66/0x1fa
Sep 22 01:09:08 agape kernel:        [<ffffffff802b2dad>] state_store+0x67/0x86
Sep 22 01:09:08 agape kernel:        [<ffffffff8030c8fa>]
subsys_attr_store+0x23/0x26
Sep 22 01:09:08 agape kernel:        [<ffffffff8030cc32>]
sysfs_write_file+0xd0/0x103
Sep 22 01:09:08 agape kernel:        [<ffffffff802171cf>] vfs_write+0xce/0x175
Sep 22 01:09:08 agape kernel:        [<ffffffff80217ab7>] sys_write+0x46/0x70
Sep 22 01:09:08 agape kernel:        [<ffffffff8026080d>] system_call+0x7d/0x83
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: -> #0 ((cpu_chain).rwsem){----}:
Sep 22 01:09:08 agape kernel:        [<ffffffff802a975e>] lock_acquire+0x4a/0x69
Sep 22 01:09:08 agape kernel:        [<ffffffff802a623b>] down_read+0x3d/0x4a
Sep 22 01:09:08 agape kernel:        [<ffffffff8029e085>]
blocking_notifier_call_chain+0x1a/0x41
Sep 22 01:09:08 agape kernel:        [<ffffffff802aca69>] _cpu_down+0x191/0x26c
Sep 22 01:09:08 agape kernel:        [<ffffffff802acd92>]
disable_nonboot_cpus+0xe9/0x185
Sep 22 01:09:08 agape kernel:        [<ffffffff802b3b4a>]
prepare_processes+0x12/0x47
Sep 22 01:09:08 agape kernel:        [<ffffffff802b3eb2>] pm_suspend_disk+0xd/0x106
Sep 22 01:09:08 agape kernel:        [<ffffffff802b2ba1>] enter_state+0x66/0x1fa
Sep 22 01:09:08 agape kernel:        [<ffffffff802b2dad>] state_store+0x67/0x86
Sep 22 01:09:08 agape kernel:        [<ffffffff8030c8fa>]
subsys_attr_store+0x23/0x26
Sep 22 01:09:08 agape kernel:        [<ffffffff8030cc32>]
sysfs_write_file+0xd0/0x103
Sep 22 01:09:08 agape kernel:        [<ffffffff802171cf>] vfs_write+0xce/0x175
Sep 22 01:09:08 agape kernel:        [<ffffffff80217ab7>] sys_write+0x46/0x70
Sep 22 01:09:08 agape kernel:        [<ffffffff8026080d>] system_call+0x7d/0x83
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: other info that might help us debug this:
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: 2 locks held by pm-hibernate/3012:
Sep 22 01:09:08 agape kernel:  #0:  (cpu_add_remove_lock){--..}, at:
[<ffffffff802666af>] mutex_lock+0x2a/0x2e
Sep 22 01:09:08 agape kernel:  #1:  (workqueue_mutex){--..}, at:
[<ffffffff802666af>] mutex_lock+0x2a/0x2e
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: stack backtrace:
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: Call Trace:
Sep 22 01:09:08 agape kernel:  [<ffffffff8026ebcd>] show_trace+0xae/0x336
Sep 22 01:09:08 agape kernel:  [<ffffffff8026ee6a>] dump_stack+0x15/0x17
Sep 22 01:09:08 agape kernel:  [<ffffffff802a799c>]
print_circular_bug_tail+0x6c/0x77
Sep 22 01:09:08 agape kernel:  [<ffffffff802a8fa5>] __lock_acquire+0x84d/0xa64
Sep 22 01:09:08 agape kernel:  [<ffffffff802a975f>] lock_acquire+0x4b/0x69
Sep 22 01:09:08 agape kernel:  [<ffffffff802a623c>] down_read+0x3e/0x4a
Sep 22 01:09:08 agape kernel:  [<ffffffff8029e086>]
blocking_notifier_call_chain+0x1b/0x41
Sep 22 01:09:08 agape kernel:  [<ffffffff802aca6a>] _cpu_down+0x192/0x26c
Sep 22 01:09:08 agape kernel:  [<ffffffff802acd93>] disable_nonboot_cpus+0xea/0x185
Sep 22 01:09:08 agape kernel:  [<ffffffff802b3b4b>] prepare_processes+0x13/0x47
Sep 22 01:09:08 agape kernel:  [<ffffffff802b3eb3>] pm_suspend_disk+0xe/0x106
Sep 22 01:09:08 agape kernel:  [<ffffffff802b2ba2>] enter_state+0x67/0x1fa
Sep 22 01:09:08 agape kernel:  [<ffffffff802b2dae>] state_store+0x68/0x86
Sep 22 01:09:08 agape kernel:  [<ffffffff8030c8fb>] subsys_attr_store+0x24/0x26
Sep 22 01:09:08 agape kernel:  [<ffffffff8030cc33>] sysfs_write_file+0xd1/0x103
Sep 22 01:09:08 agape kernel:  [<ffffffff802171d0>] vfs_write+0xcf/0x175
Sep 22 01:09:08 agape kernel:  [<ffffffff80217ab8>] sys_write+0x47/0x70
Sep 22 01:09:08 agape kernel:  [<ffffffff8026080e>] system_call+0x7e/0x83
Sep 22 01:09:08 agape kernel: DWARF2 unwinder stuck at system_call+0x7e/0x83
Sep 22 01:09:08 agape kernel: Leftover inexact backtrace:
Sep 22 01:09:08 agape kernel: 
Sep 22 01:09:08 agape kernel: CPU1 is down
Comment 8 Richard Hughes 2007-05-24 07:48:36 EDT
Ick. Does this work with the latest rawhide kernel? Thanks.
Comment 9 petrosyan 2008-02-23 03:31:16 EST
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.

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