Red Hat Bugzilla – Bug 102248
twm hangs with Xinerama under RH9
Last modified: 2007-04-18 12:56:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030708
Description of problem:
The twm window manager hangs immediately on dual-headed xinerama boxes running
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Configured RH 9 box with dual VG175 flatpanels on a Matrox G450.
2.Edited .Xclients file in home directory to launch twm.
3.Selected "default" session from gdm menu.
4.Login proceeds normally. Once twm is running, click left mouse button to pull
up menu. (Other actions also cause hang, but this is fastest way to demonstrate.)
Actual Results: Menu box appears, but text inside box is not displayed, or only
Window Manager becomes entirely unresponsive; windows cannot be selected, moved,
or closed. Menu never fully renders, additional clicks produce no response.
Window decorations gradually disappear.
Mouse remains movable, and applications like Xload continue to render data.
Virtual consoles can be switched to, and top shows no unusual process activity.
However, twm cannot be reawakened by any means that we have found. Twm must be
killed, or X restarted for normal operation to resume.
Expected Results: Twm should have behaved normally.
This behavior appears only on our dual-headed RH 9 machines. Behavior does not
appear on dual-headed RH 7.3 boxes, nor on single-head RH 9 machines. Other
window managers (Gnome, KDE, third-party RPMs for fvwm and WindowMaker,) behave
normally on the RH 9 xinerama boxes.
Latest rawhide version of XFree86 (4.3.0-18) does not correct problem, despite
blurb in changelog about "Pull twm fixes (signal handler, empty windows menu)
from CVS head".
Your best bet for now, is to report this problem in XFree86 bugzilla as well,
at: http://bugs.xfree86.org and then paste the upstream bug report URL
here for me to track it. When they fix the problem, I will backport the
fixes for future builds.
This bug is already reported in XFree86.org bugzilla at the following URL:
The above bug report is still open and awaiting further information from the
original reporter. Egbert Eich is handling this one it seems.
I'm changing this report's status to UPSTREAM, and will track it's progress
there. If it gets fixed and the fix is small enough to not be risky, I may
backport the fix for future builds.
Please handle all further communication on this problem via the above upstream
bug report so that all info is in one single location, as that will help
expediate a solution.
I may have more data on this bug:
I have 2 CAD programs which act erratically only when Xinerama is enabled on
XFree86 4.3 (RH 9). One program (eagle) hangs soon after it is invoked. Since
this program is freely downloadable from:
others may want to recreate the problem if this helps debug XFree86. The
On a stock RH9 box, install the eagle rpm:
Execute: "eagle" (as root)
Choose: "Run as freeware"
Open 19inch and select any part (like VG32)
If it doesn't lock right away, try selecting a few more parts until it does.
I've tried this on multiple computers, with multiple brands of video cards, and
multiple window managers. The only thing that makes the bug go away is to turn
off Xinerama in the config file.
I've reviewed the upstream XFree86 bug report, and it seem that
they're unable to reproduce this problem. Without the ability
to reproduce the problem, it's unlikely the issue will get
fixed by XFree86.org. We've since switched from XFree86's X11
implementation to the official X.Org X11 implementation starting
with our Fedora Core 2 release. As such, XFree86.org is no longer
our official upstream.
Please test our latest OS release (Fedora Core 2) and if the problem
persists, try our latest development release of xorg-x11, which is
xorg-x11-184.108.40.2063 at the time of this writing. If the problem
still exists in the current X.Org snapshot in rawhide, you can
file a bug in X.Org bugzilla if you would still like us to track
this issue upstream, and once you've added the X.Org bug URL here,
we'll add it to our list of tracker bugs. It's highly recommended
to use our stock builds of things and not replace any of it with
recompiled binaries, etc. Also, if you can give the upstream
developers as much information as possible to assist them in
trying to reproduce the issue, it may expediate resolution if the
problem still exists.
Thanks in advance for testing X.Org X11 in our latest OS release,
and hopefully this will resolve the issue.
Setting status to "MODIFIED", pending testing of rawhide xorg-x11