Red Hat Bugzilla – Bug 223604
kernel 2.6.19-1.2895.fc6 oops when suspend to disk with cpufreq_ondemand loaded
Last modified: 2015-03-04 20:18:03 EST
Description of problem: The latest and greatest fc6 kernel (2.6.19-1.2895.fc6) gives and oops when one tries suspend to disk with echo disk > /sys/power/state This goes away when one stops cpuspeed first so the cpufreq_ondemand module get unloaded. This was not necessary with the 2.6.18 line of kernels. Version-Release number of selected component (if applicable): kernel 2.6.19-1.2895.fc6 How reproducible: echo disk > /sys/power/state Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: This is on my dual core Asus S6F laptop. You'll find the content of cpuinfo and the output of hal-device ganged together in the attachment. I can probably provide a full oops info if needed, but I need to attach a bigger screen to make the whole content visible and to copy it off screen by hand.
Created attachment 146060 [details] Content of /proc/cpuinfo and output hal-device
This also happens on my dual core T60p ThinkPad. Thank you for the temporary fix, by the way. I'm not sure whether it's necessary, but I'm attaching similar info for the T60p.
Created attachment 146654 [details] Output of /proc/cpuinfo and hal-device for T60p
To any visiting this bug: A quick workaround is to add a script to /etc/pm/hooks to stop the cpuspeed service before suspend, and start it after resume. One example that seems to work: #!/bin/sh case "$1" in suspend) /sbin/service cpuspeed stop ;; resume) /sbin/service cpuspeed start ;; *) ;; esac exit $? # -=--=--=--=--=-- >8 There's a lot of nifty logic left out to make the example simple. :-) If you enable the workaround, and a kernel update hits the updates-testing repo (or, if you're timid, the real updates repo), please disable this hook script to test the fixes. Just leaving a note here to make people's lives easier while they wait for something to test.
Please try to provide the oops message if possible. You can take a picture of the screen with a digital camera.
(In reply to comment #5) > Please try to provide the oops message if possible. > > You can take a picture of the screen with a digital camera. How? The screen is already blank when the kernel crashes. Is there any suspend hooks to disable? NB: the 'service cpuspeed stop' workaround works for me too.
Created attachment 147972 [details] A picture of the oops message dump. I finally managed to take a picture of the screen message by using an external crt monitor. The long backtrace makes the first lines of the message to scroll off the top of the screen. For some obscure reason I could not get the console to stay in 80x60 mode, it starts booting with 80x60 res but somewhere further down it resets to 80x25. I hope you can make some sense of this. Regards, r.
Well, I can see what's happening but don't see a fix. pm-utils should be handling this automatically AFAICT -- at least there are scripts there that look like they try to do what your workaround does.
*** Bug 228275 has been marked as a duplicate of this bug. ***
I guess this should be marked as a pm-utils bug rather than a kernel bug then. The strange thing is that earlier kernels didn't have this problem, I wasn't using pm-utils earlier, just the good old hackish echo disk > /sys/power/state which bypasses all the safety measures taken in pm-hibernate and that worked just fine on the 2.6.18 line of kernels. r.
Sony SZ3XP has the same behaviour: pm-utils-0.19-3.x86_64 kernel-2.6.18-1.2869.fc6.x86_64 -> suspend ok kernel-2.6.19-1.2911.fc6.x86_64 -> blank screen/no suspend unless cpuspeed is turned off prior to suspension refers to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223731 ?
Is this bug still present in Fedora 7 or 8?
No, it seems to be fixed now.