+++ This bug was initially created as a clone of Bug #238776 +++
When I resume from suspend, X freaks out - it looks like it's going to resume,
then the screen goes all gray and the pointer locks up. Then it repeats. This
happens whether or not I am running compiz at the time.
This works fine in F7t4. Running from an F7t4 liveCD, everything
suspends/resumes OK until I upgrade hal.
So I guess the post-t4 hal (0.5.9-6.fc7) messed with the way resume is done on
the thinkpad compared to the t4 hal (0.5.9-5.fc7).
Could this be fixed by the patches in bug #237871?
(In reply to comment #0)
> This works fine in F7t4. Running from an F7t4 liveCD, everything
> suspends/resumes OK until I upgrade hal.
Are you saying you are trying to suspend/remove from the live CD itself? Or is
this an installed system?
> So I guess the post-t4 hal (0.5.9-6.fc7) messed with the way resume is done on
> the thinkpad compared to the t4 hal (0.5.9-5.fc7).
What other packages (e.g. hal-info) did you upgrade? Did you reboot after
updating hal? If so, can you attach lshal before and after the upgrade?
(remember you need to restart haldaemon or reboot since hal doesn't do
condrestart on upgrades).
(In reply to comment #1)
> Could this be fixed by the patches in bug #237871?
Yes, it appears our quirks are wrong
This is definitely something that needs fixing before F7 is out
(expanding on comment 3: the fix for bug 237871 just made it evident that the
quirks were wrong.)
Here's the timeline:
Apr. 26: F7t4. Suspend/resume working fine.
Apr. 27: updates, including hal, hal-libs, and kernel. suspend/resume fails.
Anyway, there were a bunch of other relevant updates, and I wasn't sure what the
problem was (kernel? hal? something else?) So today I did an experiment by
booting a Live USB image of F7t4:
F7t4: suspend/resume works
+ xorg updates: works
+ pm-utils updates: works
+ hal updates: broken
After each upgrade I stopped X and logged back in. After the hal updates I
dropped to runlevel 3 and restarted haldaemon, then went back to runlevel 5 and
logged back in.
hal-info is the same now as in F7t4, so I don't think that's the issue.
OK, thanks for the information. It's obviously bad quirks from HAL. I've got the
ball - will go through most of the quirks / solicit input from the source
(s2ram) on what is happening. Worst case is that we delete all the quirks for
Yep, bad quirks. This will be fixed by hal-info-20070516-1.fc7.
Further info about fixing quirks can be found here: