Bug 6851

Summary: Suspend to RAM and Ondemand Lockup/Stack trace
Product: Power Management Reporter: Brandon Philips (brandon)
Component: cpufreqAssignee: Rafael J. Wysocki (rjwysocki)
Status: CLOSED CODE_FIX    
Severity: normal CC: acpi-bugzilla, davej, pavel, rjwysocki
Priority: P2    
Hardware: i386   
OS: Linux   
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

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.