Bug 92367

Summary: Video crashes xinerama system
Product: [Retired] Red Hat Linux Reporter: Mark H Johnson <mark_h_johnson>
Component: XFree86Assignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-10-01 06:00:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
System log file
none
Output of lspci -v -x
none
XFree86 Configuration File
none
Output from XFree86 none

Description Mark H Johnson 2003-06-05 15:08:19 UTC
Description of problem:

We have had problems with a Red Hat 7.3 system running motv / xawtv on
a three display system. The problem occurs when moving a window where it
appears on more than one screen. This is "somewhat" repeatable - most
of the time it works, sometimes - if I do repeated moves, it may occur
within 5-15 minutes. It also appears to be more frequent if I have more
than one video window active at a time.

Symptom in 7.3 is the X server will reset, going back to the login screen,
without any messages in the XFree86 log file nor /var/log/messages.

Updated to Red Hat 9, and the symptom changes and the whole system is
unusable.

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


How reproducible:

Move video window between two windows.

Steps to Reproduce:
1. Start system, log in.
2. Start xawtv (or motv).
3. Move video window repeatedly across the multiple displays until it occurs
    
Actual results:
As noted above, the X server resets (7.3) or the system locks up (9).

Expected results:
Window moves w/o any problems.

Additional info:
The system being used has...
 - SMP (two CPU's active)
 - using 3 of 4 multihead Savage displays (Colorgraphix Predator Pro)
 - using 1, 2, or 3 Happauge WinTV cards for video input
 - 16 bit color to avoid PCI bandwidth problems

The command line for motv is...
  /usr/X11R6/bin/motv -remote -noxv -c /dev/video0
(the xawtv command line is similar; can also use video1 and video2)
For reference, we use -remote and -noxv since the images are unusable
when showing two video windows on the same display.

I will be sending additional files w/ lspci output, X configuration file,
relevant sections from XFree86.0.log and /var/log/messages (showing no
significant information). Let me know if you need something else.

I realize you won't necessarily have the hardware - I am mostly interested
in suggestions on how to diagnose the problem / how to avoid it.

Comment 1 Mark H Johnson 2003-06-05 15:16:21 UTC
Created attachment 92162 [details]
System log file

Output from /var/log/messages. Have removed unrelated material. First
section shows all messages from boot through restart. Subsequent sections
have the boot sequence removed and show just the messages from login
to failure of the system.

Comment 2 Mark H Johnson 2003-06-05 15:20:01 UTC
Created attachment 92163 [details]
Output of lspci -v -x

Output showing hardware and first part of configuration space for
each card.

Comment 3 Mark H Johnson 2003-06-05 15:24:11 UTC
Created attachment 92165 [details]
XFree86 Configuration File

For reference, three displays - all at 1280 x 1024, horizontal alignment
(left, center, right), all at 16 bit color. Fourth display is not
configured.

Comment 4 Mark H Johnson 2003-06-05 15:28:06 UTC
Another thing we tried...

We tried changing the window manager (KDE) to move windows with outline
instead of with contents. We noted all windows were "frozen" when we moved
any one window. The failure did not occur with the outline crossing the
display boundary. It did occasionally occur when the mouse button was
released (and the video display began to draw again). From this, we
believe it is a "first time" problem when the video image is split across
the two displays.

Also, since we have multiple video inputs available, we tried to determine
if overlapping video windows would increase / decrease the frequency of
occurrence. We did not note any change in frequency when windows were
overlapping.



Comment 5 Mark H Johnson 2003-06-05 15:32:51 UTC
Created attachment 92169 [details]
Output from XFree86

I believe this has the proper output; must confirm with the person who
did the test run. Usually the log file is overwritten when XFree86 starts
again [sigh]. Do you have a suggestion on keeping these log files across
reboots?

Comment 6 Mark H Johnson 2003-09-16 15:28:51 UTC
Have repeated the problem with Red Hat 9.

Opened a bug at 
  http://bugs.xfree86.org/show_bug.cgi?id=512
and have a minor change that should work OK on Intel processors but may cause
alignment problems on other platforms. The patch is...

Index: xaaImage.c
===================================================================
RCS file: /opt/repository/cvs/xc/programs/Xserver/hw/xfree86/xaa/xaaImage.c,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.14.1
diff -u -r1.1.1.1 -r1.1.1.1.14.1
--- xaaImage.c  20 Jun 2001 11:26:28 -0000      1.1.1.1
+++ xaaImage.c  21 Mar 2003 22:33:55 -0000      1.1.1.1.14.1
@@ -236,12 +236,16 @@
     (*infoRec->SetupForImageWrite)(pScrn, rop, planemask, trans, bpp, depth);
     (*infoRec->SubsequentImageWriteRect)(pScrn, x, y, w, h, skipleft);

+#if 0
     if(beCareful) {
        /* in cases with bad alignment we have to be careful not
           to read beyond the end of the source */
        if(((x * Bpp) + (dwords << 2)) > srcwidth) h--;
        else beCareful = FALSE;
     }
+#endif
+    if (beCareful)
+       h--;

     if(dwords > infoRec->ImageWriteRange) {
        while(h--) {

If some variant of this can be incorporated into a future release - that would
be great.


Comment 7 Mike A. Harris 2004-10-01 06:00:03 UTC
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:

If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.