Bug 223604
| Summary: | kernel 2.6.19-1.2895.fc6 oops when suspend to disk with cpufreq_ondemand loaded | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Roy Dragseth <roy.dragseth> | ||||||||
| Component: | pm-utils | Assignee: | Phil Knirsch <pknirsch> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brian Brock <bbrock> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 6 | CC: | adellam, bloch, choeger, daveiro, opensource, pasteur, roth, rvokal, stickster, wtogami | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | i686 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | pm-utils-0.99.4-3.fc7 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2007-12-30 21:23:39 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Roy Dragseth
2007-01-20 17:36:08 UTC
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. |