Bug 102248 - twm hangs with Xinerama under RH9
twm hangs with Xinerama under RH9
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-08-12 18:24 EDT by Dennis Brylow
Modified: 2007-04-18 12:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-01 16:46:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dennis Brylow 2003-08-12 18:24:57 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
RedHat 9. 

Version-Release number of selected component (if applicable):

How reproducible:

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
partially displayed.
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.

Additional info:

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".
Comment 1 Mike A. Harris 2003-08-16 20:12:54 EDT
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.
Comment 2 Mike A. Harris 2003-08-17 22:38:29 EDT

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.


Comment 3 Kyle Bateman 2003-09-15 14:37:14 EDT
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
procedure is:

On a stock RH9 box, install the eagle rpm:

Execute: "eagle" (as root)
Choose: "Run as freeware"
Do: File->New->Schematic
Do: Edit->Add
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.


Comment 4 Mike A. Harris 2004-09-01 06:50:18 EDT
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- 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.

Comment 5 Mike A. Harris 2004-09-01 06:50:48 EDT
Setting status to "MODIFIED", pending testing of rawhide xorg-x11
by reporter.

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