Bug 47650

Summary: system hangs on xdvi
Product: [Retired] Red Hat Linux Reporter: Rutger Noot <rutger.noot>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED ERRATA QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: high    
Version: 7.1CC: mharris, rutger.noot
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: 2002-03-14 12:06:55 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
result of strace xdvi rubin
none
tarfile of confuguration to reproduce bug
none
XFree86 configuration file
none
Xfree log file
none
Xfree log file
none
XFree86 log file
none
XFree log file
none
XFree log file none

Description Rutger Noot 2001-07-06 12:48:43 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/4.51 [en] (X11; I; Linux 2.2.16-3 sparc64)

Description of problem:
Changing the shrink factor while viewing a file with xdvi make 
_the entire system_ hang. 
This may actually be a kernel bug... 

How reproducible:
Always

Steps to Reproduce:
1. xdvi rubin  (rubin.dvi is a file in 10pt created by plain tex)
2. change the shrink factor like so 6s 5s 4s 3s
3
	

Actual Results:  system hangs completely! Screen is frozen, cannot switch
virtual
consoles, can't kill X (by Ctr-Alt-Backspace), telnet connection 
to the machine is frozen as well. No response to ping requests

Expected Results:  I would of course expect the size of my charaters to
change on screen,
but at worst a crash of xdvi, not a complete lockup. 

Additional info:

1. The problem does not occur when xdvi is run with display on
another machine
2. The problem also happens with a brand new xdvi from CTAN
3. strace xdvi ends by 
read(3, 0xbffff3e0, 32)                 = -1 EAGAIN (Resource temporarily
unavailable)
select(4, [3], NULL, NULL, NULL

where 
socket(PF_UNIX, SOCK_STREAM, 0)         = 3
Comment 1 Rutger Noot 2001-07-06 12:50:24 UTC 
Created attachment 22849 [details]
result of  strace xdvi rubin
Comment 2 Tim Waugh 2001-07-06 12:52:22 UTC 
Definitely a kernel problem.  Reassigning.
Comment 3 Tim Waugh 2001-07-06 12:53:24 UTC 
(Or, come to think of it, maybe X.)
Comment 4 Rutger Noot 2001-07-06 13:10:48 UTC 
This seems to an X problem indeed. 
It happens under XFree-4 (the server I use by default), but it stops 
happening when I pass to XF86_SVGA.
Comment 5 Rutger Noot 2001-07-11 12:22:15 UTC 
This is more difficult to reproduce than I thought, it seems that the
sawfish configuration has something to do with it! (I am using sawfish-0.38
from ximian, but the hang still occurs after downgrading to 0.36 from the 
seawolf cd). I'll attach a tarfile with the simpelest reproduction of the 
problem that I could find. To reproduce
1. create a new account
2. throw away all files (including .*)
3. unpack testcase.tar in the home dir
4. open an Xsession (this will just open an xterm and launch sawfish)
5. type "xdvi rubin" into the xterm (rubin.dvi is supplied in the tarball)
Comment 6 Rutger Noot 2001-07-11 12:24:59 UTC 
Created attachment 23287 [details]
tarfile of confuguration to reproduce bug
Comment 7 Rutger Noot 2001-07-11 12:37:35 UTC 
Sorry, forgot last step to reproduce
6. place mouse in xdvi window and type  6s5s4s3s
Comment 8 Rutger Noot 2001-10-15 07:37:57 UTC 
This may very well be a bug of XFree86 4.0.3 (trident chipset).
Starting  xfig hangs the system in similar fashion, see bug 
41230
Comment 9 Mike A. Harris 2001-10-27 22:23:11 UTC 
If you add the following to your /etc/XF86Config-4, in the
Screen section:

     Option "NoAccel"

Does the problem still occur?  If the problem goes away, we
can try to narrow it down.
Comment 10 Rutger Noot 2001-10-28 21:10:16 UTC 
yes, the problem disappears with Option NoAccel.
Comment 11 Mike A. Harris 2001-10-29 04:37:00 UTC 
Ok, can you please attach a copy of your XFree86 config file, your
log file both as separate text file attachments using the link below.

Next step is to determine what specific XAA acceleration primitives
are failing to work correctly.  To do that, you need to comment out the
freshly added Option Noaccel, and go through each of the individual
XAA primitive disabling directives in the config file.  If you look
at "man XF86Config"  you'll find a bunch of options starting with
XAANoxxxxxxx such as XAANoScreenToScreenCopy.  Use these directives
one at a time, and see which ones stop the problems from occuring.
Once you've determined which ones fix it, we can set it to default that 
particular option to off until the driver can be fixed.  At the same time
you'll be able to enjoy a mostly accelerated setup.
Comment 12 Rutger Noot 2001-10-29 17:34:16 UTC 
Created attachment 35461 [details]
XFree86 configuration file
Comment 13 Rutger Noot 2001-10-30 09:35:06 UTC 
Created attachment 35641 [details]
XFree log file
Comment 14 Rutger Noot 2001-10-30 09:40:21 UTC 
Finally succeeded to attach the log file. 
Please note that (as I tried to attach it in vain yesterday)
the log file does not correspond exactly to the Config file.
The  Option "NoAccel" has been replaced by 

Option "XaaNoScreenToScreenCopy"

That seems to be sufficient to get rid of the problems of both xdvi
and xfig! I'll test it over a longer period to be sure. 

Thanks for your help, please let me know if you want me to do some 
more testing.
Comment 15 Rutger Noot 2002-03-14 12:06:51 UTC 
You closed bug 41230 and you can also close this one, with resolution  ERRATA
Comment 16 Mike A. Harris 2002-03-14 18:04:08 UTC 
Ok great, thanks.