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
Created attachment 22849 [details] result of strace xdvi rubin
Definitely a kernel problem. Reassigning.
(Or, come to think of it, maybe X.)
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.
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)
Created attachment 23287 [details] tarfile of confuguration to reproduce bug
Sorry, forgot last step to reproduce 6. place mouse in xdvi window and type 6s5s4s3s
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
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.
yes, the problem disappears with Option NoAccel.
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.
Created attachment 35461 [details] XFree86 configuration file
Created attachment 35641 [details] XFree log file
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.
You closed bug 41230 and you can also close this one, with resolution ERRATA
Ok great, thanks.