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. http://www.smolts.org/client/show/pub_39aac23f-48cc-4fae-98a8-70f2aa0fb15e 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-2.6.29.1-102.fc11.i686 nomodeset xorg-x11-drv-ati-6.12.2-4.fc11.i586
Does it also fail with the f10 kernel in updates-testing (2.6.29.1-30.fc10)?
Yes, kernel-2.6.29.1-30.fc10.i686 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?
*** Bug 497460 has been marked as a duplicate of this bug. ***
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.
I am experiencing the same problem without lvm encryption.
kernel-PAE-2.6.29.2-123.fc11.i686 does not solve this problem. modeset/nomodeset does not matter.
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.
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 : 2.6.29.3-142.fc11.i686.PAE Using fedora rawide fully updated
Also described for F10 https://bugzilla.redhat.com/show_bug.cgi?id=499047 Seems to be a bug in (Fedora-) kernel 2.6.29 2.6.29.3-155.fc11.i686.PAE has still this problem.
Created attachment 345167 [details] Trace from first suspend/resume cycle During first suspend/resume two stack traces are written.
seems to be in 2.6.30 too http://bugzilla.kernel.org/show_bug.cgi?id=13197 http://bugzilla.kernel.org/show_bug.cgi?id=13269
tried yesterday Kernel 2.6.30-0.97.rc8 compiled for F11. This seemed to fix this issue. http://koji.fedoraproject.org/koji/buildinfo?buildID=104641 (needs to be compiled for F11)
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
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.
I can confirm that suspend/resume seems to work when cpuspeed is disabled. Disabling cpuspeed is a usable workaround, but not a solution. kernel-PAE-2.6.29.4-167.fc11.i686
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 )
A potential fix for this issue?: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b14893a62c73af0eca414cfed505b8c09efc613c#patch1
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.
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.
kernel-PAE-2.6.30.5-28.rc2.fc11.i686 works fine for me even with cpuspeed. closing.
Not sure if this is the same bug: since the same kernel upgrade (kernel-2.6.30.5-28.rc2.fc11.i586), my ThinkPad T43 has been suspending when inactive with the lid *open* for some lengthy period. xorg-x11-server-Xorg-1.6.1.901-1.fc11.i586 xorg-x11-drv-ati-6.12.2-14.fc11.i586