Bug 238792 - X freakout / server lockup on Thinkpad T43 resume with intel video (i915)
Summary: X freakout / server lockup on Thinkpad T43 resume with intel video (i915)
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: hal   
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: FC7Blocker
TreeView+ depends on / blocked
 
Reported: 2007-05-02 22:49 UTC by Will Woods
Modified: 2013-03-06 03:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-17 17:33:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Will Woods 2007-05-02 22:49:14 UTC
+++ 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).

Comment 1 Will Woods 2007-05-02 23:00:09 UTC
Could this be fixed by the patches in bug #237871?

Comment 2 David Zeuthen 2007-05-02 23:23:35 UTC
(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).


Comment 3 David Zeuthen 2007-05-02 23:25:47 UTC
(In reply to comment #1)
> Could this be fixed by the patches in bug #237871?

Yes, it appears our quirks are wrong

 http://lists.freedesktop.org/archives/hal/2007-April/008158.html

This is definitely something that needs fixing before F7 is out

Comment 4 David Zeuthen 2007-05-02 23:28:21 UTC
(expanding on comment 3: the fix for bug 237871 just made it evident that the
quirks were wrong.)

Comment 5 Will Woods 2007-05-03 01:31:13 UTC
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.

Comment 6 David Zeuthen 2007-05-03 04:16:29 UTC
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
IBM/Lenovo. Thanks.

Comment 7 Will Woods 2007-05-17 17:33:43 UTC
Yep, bad quirks. This will be fixed by hal-info-20070516-1.fc7. 

Further info about fixing quirks can be found here:
http://www.freedesktop.org/wiki/Software/HalSleepQuirks


Note You need to log in before you can comment on or make changes to this bug.