Bug 6851 - Suspend to RAM and Ondemand Lockup/Stack trace
Suspend to RAM and Ondemand Lockup/Stack trace
Status: CLOSED CODE_FIX
Product: Power Management
Classification: Unclassified
Component: cpufreq
i386 Linux
: P2 normal
Assigned To: Rafael J. Wysocki
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-17 08:38 UTC by Brandon Philips
Modified: 2007-04-28 12:49 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.16.18-rc1, 2.6.18-rc1-mm1, 2.6.18-rc1-mm2
Tree: Mainline
Regression: ---


Attachments
2.6.18-rc1-mm1 .config (57.33 KB, text/plain)
2006-07-17 08:44 UTC, Brandon Philips
Details

Description Brandon Philips 2006-07-17 08:38:50 UTC
Most recent kernel where this bug did not occur:

Distribution: Debian GNU/Linux (unstable)

Hardware Environment: Thinkpad x60s w/ Forrest Zhao's patches for AHCI suspend:
http://marc.theaimsgroup.com/?l=linux-ide&m=115277002327654&w=2

Software Environment: gcc version 4.1.2 20060630 (prerelease) (Debian 4.1.1-6)

Problem Description: Suspend to ram failure (echo mem > /sys/power/state) w/
backtrace on 2.6.18-rc1-mm1

Steps to reproduce:

1) Use ondemand governor
2) echo mem > /sys/power/state
3) 
Freezing cpus ...
CPU 1 is now offline
SMP alternatives: switching to UP code
divide error: 0000 [#1]
8K_STACKS SMP
last sysfs file: /power/state
Modules linked in: binfmt_misc rfcomm l2cap bluetooth ipv6 nvram uinput button
ac battery joydev ibm_acpi hdaps cpufreq_userspace speedstep_centrino freq_table
sbp2
cpufreq_ondemand tsdev intelfb i2c_algo_bit snd_hda_intel i2c_i801 psmouse
nsc_ircc snd_hda_codec pcspkr intel_agp agpgart eth1394 evdev i2c_core serio_raw
irda snd_pcm
snd_timer snd soundcore yenta_socket rsrc_nonstatic pcmcia_core snd_page_alloc
crc_ccitt ata_piix piix sd_mod generic ide_core uhci_hcd ohci1394 ieee1394
ehci_hcd usbcore
e1000 ahci libata scsi_mod thermal processor fan
CPU:    0
EIP:    0060:[<f8a0d20d>]    Not tainted VLI
EFLAGS: 00210246   (2.6.18-rc1-mm1 #2)
EIP is at do_dbs_timer+0xcb/0x14e [cpufreq_ondemand]
eax: 00000000   ebx: 00000000   ecx: 00000001   edx: 00000000
esi: c1dda380   edi: 00000002   ebp: c1dda380   esp: f7d5ff4c
ds: 007b   es: 007b   ss: 0068
Process kondemand/0 (pid: 5266, ti=f7d5e000 task=dff48b90 task.ti=f7d5e000)
Stack: 00000000 c1bfaba0 00000000 00000000 c1c02bb4 c1c02bb8 f7f69d80 00200286
       c012c04c 00000000 f8a0d142 00000000 f7f69d94 f7f69d80 f7f69d8c 00000000
       c012c9a2 00000001 00000000 c1c01280 00010000 00000000 00000000 dff48b90
Call Trace:
 [<c012c04c>] run_workqueue+0x80/0xbc
 [<f8a0d142>] do_dbs_timer+0x0/0x14e [cpufreq_ondemand]
 [<c012c9a2>] worker_thread+0xf3/0x125
 [<c0117c57>] default_wake_function+0x0/0x15
 [<c012c8af>] worker_thread+0x0/0x125
 [<c012ef9c>] kthread+0xc3/0xef
 [<c012eed9>] kthread+0x0/0xef
 [<c0101005>] kernel_thread_helper+0x5/0xb
Code: 00 39 44 24 0c 0f 46 44 24 0c 89 44 24 0c 56 57 e8 2f 79 7c c7 5b 89 c7 5d
83 ff 01 76 a3 8b 44 24 08 31 d2 2b 44 24 0c 6b c0 64 <f7> 74 24 08 89 c1 a1 a8
e6 a0 f8
39 c1 76 0d 8b 46 1c 39 46 20
EIP: [<f8a0d20d>] do_dbs_timer+0xcb/0x14e [cpufreq_ondemand] SS:ESP 0068:f7d5ff4c

Note: 2.6.18-rc1 and 2.16.18-rc1-mm2 do not create the stack trace and simply
stop suspending at: SMP alternatives: switching to UP code.  

5) A ctrl+alt+del reboots the box cleanly
Comment 1 Brandon Philips 2006-07-17 08:40:35 UTC
Suspend to RAM _not_ software suspend.
Comment 2 Brandon Philips 2006-07-17 08:44:57 UTC
Created attachment 8568 [details]
2.6.18-rc1-mm1 .config
Comment 3 Rafael J. Wysocki 2006-07-17 13:03:15 UTC
Does Comment #1 mean that the system resumes successfully from suspend to disk 
if the ondemand governor is used?
Comment 4 Brandon Philips 2006-07-17 17:10:56 UTC
Problem: When ondemand is the govenor suspend to ram fails.  

Suspend to ram works with the performance govenor.
Comment 5 Pavel Machek 2006-07-26 02:06:08 UTC
On lkml, there's currently discussion about ondemand's locking being termianlly
broken. This is probably one of the symptoms
Comment 6 Len Brown 2006-08-09 21:17:55 UTC
Please verify that this issue is gone using 2.6.18-rc4 or later.
(moving to PM/cpufreq, since this is not an ACPI issue)
Comment 7 Rafael J. Wysocki 2006-10-30 10:02:30 UTC
Does the lack of activity mean the issue has been fixed?
Comment 8 Rafael J. Wysocki 2006-11-19 04:20:07 UTC
I assume the problem has been fixed, so I'm closing the bug.  Please reopen if
I'm wrong.

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