Description of problem: I'm following the instructions at http://people.freedesktop.org/~hughsient/temp/quirk/quirk-debug.html to try to get suspend working on this HP Pavillion dv1100 with rawhide. echo 1 > /sys/power/pm_trace pm-suspend It suspends, resume fails; so power off, then power on Resulting dmesg is attached. It contains this fragment: Using IPI No-Shortcut mode Magic number: 0:150:827 hash matches drivers/base/power/resume.c:28 hash matches device 0000:06:09.0 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Version-Release number of selected component (if applicable): kernel-2.6.21-1.3175.fc7 hal-info-20070516-2.fc7 Steps to Reproduce: As root: 1. echo 1 > /sys/power/pm_trace 2. pm-suspend 3. Suspends, press power button to resume 4. Resume fails, hold power to power off, then press power to power on 5. dmesg > dmesg.txt Actual results: Magic number: 0:150:827 hash matches drivers/base/power/resume.c:28 hash matches device 0000:06:09.0 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Expected results: No "unable to open rtc device (rtc0)" error More "hash matches" lines, hopefully with some indication of what's going on
Created attachment 155220 [details] dmesg output
Do you have normally /dev/rtc or /dev/rtc0? Thanks.
[david@brick ~]$ ll /dev/rt* crw-r--r-- 1 root root 10, 135 2007-05-23 08:39 /dev/rtc
Found the problem with suspend: had a stray acpi=noirq in my grub.conf kernel boot line from (I think) the FC4 era when I had probelms getting ipw2200 to work, with failure to allocate IRC18; it appears this isn't necessary now. Perhaps the troubleshooter web pages could list "do you have anything weird in your grub.conf from a bygone era" or somesuch. Upon removing that, it resumes from suspend, but with a non-functioning screen, and upon replacing "i810" with "intel" in my Xorg.conf suspend/resume appears to be fully working on this laptop (HP Pavilion dv1000). Yay! (thanks for the excellent debugging pages) Should the video-quirk-suspend FDI files list models for which it's known that no quirk is needed? (Perhaps could even encode some of the knowledge of the debugging web pages into gnome-power-manager? e.g. advising people to switch from "i810" to "intel" - do we change this sort of thing when upgrading distros? probably overkill at this stage, web site works well) Still get the "unable to open rtc device (rtc0)" message FWIW, though now that suspend/resume is working for me I'm not so bothered.
(In reply to comment #4) > Found the problem with suspend: had a stray > acpi=noirq > in my grub.conf kernel boot line from (I think) the FC4 era when I had probelms > getting ipw2200 to work, with failure to allocate IRC18; it appears this isn't > necessary now. Perhaps the troubleshooter web pages could list "do you have > anything weird in your grub.conf from a bygone era" or somesuch. Hmm, I'm hesitant asking users to remove things from the grub.conf, in case we get a non-booting system. On new installs (95% I of people I'm guessing) we dont have junk left in grub.conf and the issue isn't important. > upon replacing "i810" with "intel" in my Xorg.conf suspend/resume appears to > be fully working on this laptop (HP Pavilion dv1000). Sweet! > Yay! (thanks for the excellent debugging pages) No problem, they are there to make my life easier too :-) > Should the video-quirk-suspend FDI files list models for which it's known that > no quirk is needed? Well, there was talk of this on the HAL mailing list. I think David wants something like: <merge key="power_management.quirk.none" type="bool">true</merge> ...so software like g-p-m knows the suspend is likely to work. Could you generate a patch and send it to the hal mailing list, and we can discuss it there. > Still get the "unable to open rtc device (rtc0)" message FWIW, though now that > suspend/resume is working for me I'm not so bothered. Yes, I get that too now. I'm trying to debug that. Richard.
I think we set the system time via some other method on boot. This message should probably not even be printing.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp