Bug 497067 - Resume fails second time
Resume fails second time
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: 497460 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-04-22 04:49 EDT by Mads Kiilerich
Modified: 2009-08-28 16:43 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-08-19 18:30:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg describing the system (31.70 KB, text/plain)
2009-04-22 04:49 EDT, Mads Kiilerich
no flags Details
Trace from first suspend/resume cycle (5.44 KB, text/plain)
2009-05-22 17:34 EDT, Matthias Runge
no flags Details

  None (edit)
Description Mads Kiilerich 2009-04-22 04:49:39 EDT
Created attachment 340688 [details]
dmesg describing the system

Description of problem:

After the system has been rebooted I can suspend and resume. It works fine, but only once.

Next time I try to resume the disk spins up and the backlight turns on, but nothing else happens. Nothing on the screen, nothing written to logs and no caps lock toggling.

Latitude D610
ATI Technologies Inc M22 [Radeon Mobility M300]

It worked fine with F10 kernels, so this is a regression. I am not sure if it has worked with earlier F11 kernels, but I think it did.

Version-Release number of selected component (if applicable):

kernel-PAE- nomodeset
Comment 1 Chuck Ebbert 2009-04-22 10:31:10 EDT
Does it also fail with the f10 kernel in updates-testing (
Comment 2 Mads Kiilerich 2009-04-22 11:58:30 EDT
Yes, kernel- and fully updated f11 userspace fails the same way.

So it is either a change also present in that kernel, or something else such as the quirks.

Which other kernels would it make sense to try ... if any? The latest 2.6.27 fc10?
Comment 3 Chuck Ebbert 2009-04-23 22:47:49 EDT
*** Bug 497460 has been marked as a duplicate of this bug. ***
Comment 4 Matthias Runge 2009-04-27 03:31:04 EDT
Same here on Thinkpad T43 (Radeon X300). 
First suspend/resume cycle works fine, second does not. No output is given, no log. Harddisk spins up, but nothing more happens. The suspend led (small moon) does not switch off, panel backlight remains dark. Only way to solve this is to power-cycle.

Installation is a fresh F11 with lvm encryption (if that's interesting)
F10 kernels (2.6.27 series) worked fine.
Comment 5 Saikat Guha 2009-04-27 04:43:06 EDT
I am experiencing the same problem without lvm encryption.
Comment 6 Matthias Runge 2009-05-04 03:22:24 EDT
kernel-PAE- does not solve this problem.
modeset/nomodeset does not matter.
Comment 7 Matthias Runge 2009-05-10 14:49:34 EDT
Maybe the same issue: (another way to reproduce the error?)

boot, then switch to console, type init 3. Make sure, haldaemon is running (it should be, on a standard installation)
Afterwards issue pm-suspend. My T43 does not wake up again with the same symptoms as it shows at this bug.
Comment 8 Sergio Monteiro Basto 2009-05-16 15:09:52 EDT
I have the same messages as same bug 497460
but on first cycle, which seems that prevent resume.

See attached /var/log/messages:
Kernel BUG reported during the first suspend/resume cycle:
  BUG: sleeping function called from invalid context at kernel/workqueue.c:440
Also, on both attempts:
  kernel: [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for
disabled pipe 0

kernel : 

Using fedora rawide fully updated
Comment 9 Matthias Runge 2009-05-21 16:05:50 EDT
Also described for F10
Seems to be a bug in (Fedora-) kernel 2.6.29 has still this problem.
Comment 10 Matthias Runge 2009-05-22 17:34:52 EDT
Created attachment 345167 [details]
Trace from first suspend/resume cycle

During first suspend/resume two stack traces are written.
Comment 12 Matthias Runge 2009-06-05 03:06:37 EDT
tried yesterday Kernel 2.6.30-0.97.rc8 compiled for F11. This seemed to fix this issue.

(needs to be compiled for F11)
Comment 13 Bug Zapper 2009-06-09 10:23:02 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 14 Roman Kagan 2009-06-10 07:29:02 EDT
Same here on IBM T43p: first s/r succeeds, resume from the second suspend doesn't happen.

The power led doesn't go on in that case but the hard drive spins off.
Comment 15 Roman Kagan 2009-06-15 06:18:03 EDT
Not starting cpuspeed service at boot time (chkconfig --level 12345 cpuspeed off) makes the BUG and the WARNING go away, and the system suspends and resumes fine multiple times.

I'll gather more details tonight when I have some time.
Comment 16 Mads Kiilerich 2009-06-15 19:25:16 EDT
I can confirm that suspend/resume seems to work when cpuspeed is disabled. 

Disabling cpuspeed is a usable workaround, but not a solution.

Comment 17 Matthias Runge 2009-06-17 03:15:08 EDT
That's right. 
cpuspeed loads kernel module cpufreq_ondemand by default. Without cpufreq_ondemand loaded, system suspends fine. When loading cpufreq_ondemand suspend/resume breaks with a stack trace during first suspend/resume and a hard freeze during the second one. 

(for trace, please see https://bugzilla.redhat.com/show_bug.cgi?id=499651#c3 )
Comment 19 Roman Kagan 2009-06-17 17:20:26 EDT
Well, the initial

  BUG: sleeping function called from invalid context at kernel/workqueue.c:440

happens in acpi-cpufreq (as the calltrace suggests).

This is a might_sleep() check in flush_work() called from the notorious work_on_cpu() which is called under interrupts disabled.

The current upstream has it replaced by smp_call_function_{single,many}(), see commit 01599fca6758d2cd133e78f87426fc851c9ea725.

I haven't yet tracked down how this induces the eventual issue of not resuming upon the second suspend, though.
Comment 20 Samuel Sieb 2009-07-12 01:48:57 EDT
This is the same bug as bug 499047 and bug 499651.  The workaround is to disable cpuspeed so it doesn't load the acpi_cpufreq module.  If it's already loaded and you remove it, suspending and resuming will work properly.
Comment 21 Mads Kiilerich 2009-08-19 18:30:16 EDT
kernel-PAE- works fine for me even with cpuspeed.

Comment 22 Peter Bloomfield 2009-08-28 16:43:01 EDT
Not sure if this is the same bug: since the same kernel upgrade (kernel-, my ThinkPad T43 has been suspending when inactive with the lid *open* for some lengthy period.


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