From Bugzilla Helper: 
User-Agent: Mozilla/5.0 (compatible; Konqueror/3) 
 
Description of problem: 
I am using the X-4.2.0 on S3 KM133 prosavage video (driver version 1.1.23). I 
get hard lockups under various circumstances (all perfectly reproducible) such 
that manual power-on reset is the only way out (even ping from from external 
machine fails). There's no info stored about this lockup in 
/var/log/XFree86.0.log as the lockup is very fast and the next reboot always 
runs fsck and clears stuff. So I can't supply any log file. 
The lockup is triggered only when hardware acceleration is enabled and I run 
xine with the xvideo ("Xv") driver or mplayer with xvideo ("-vo xv") driver. 
 
Below is a simple way to reproduce the bug: 
Compiled and run a small program (about 150 lines) as follows: 
 
* download from http://freshmeat.net/projects/xvattr/  
the file http://www.dtek.chalmers.se/~dvd/dist/xvattr-1.1.tgz 
 
* Run all these commands as a non-root user -> 
        tar -zxf xvattr-1.1.tgz; cd xvattr; make; 
 
* Now run this as a non-root user -> 
        ./xvattr -a XV_BRIGHTNESS -v 10 
 
The system will hang (manual reset required). 
 
I am stressing the "non-root user" just to indicate that u don't have to have 
root access to do cause the hang (which could be a security issue as well). 
 
Further investigations revealed that calls to the functions 
XvSetPortAttribute and XvGetPortAttribute are causing the lockup. 
Each function is being called only once (after line 130) and either call alone 
is capable of causing the hang. 
 
Version-Release number of selected component (if applicable): 
 
 
How reproducible: 
Always 
 
Steps to Reproduce: 
1.See above 
2. 
3. 
	 
 
Actual Results:  system hard lockup with manual reset the only way out 
 
Expected Results:  No problem at all 
 
Additional info: 
 
This bug was in XFree86-4.1.0 and has continued in  XFree86-4.2.0. Obviously, 
there is the possibility of data corruption with such frequent lockups, 
inspite of journaling file systems such as ext3.