Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 69766 - Hard lockup with s3 prosavage km133 video
Hard lockup with s3 prosavage km133 video
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-07-25 01:18 EDT by NILMONI DEB
Modified: 2007-04-18 12:44 EDT (History)
0 users

See Also:
Fixed In Version: FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-01 16:43:30 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 NILMONI DEB 2002-07-25 01:18:25 EDT
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: 
Steps to Reproduce: 
1.See above 
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.
Comment 1 Mike A. Harris 2002-07-25 14:34:25 EDT
This problem should be reported to xfree86@XFree86.org as a bug,
and to xpert@xfree86.org for discussion.  The Savage driver maintainer
should be notified, so that he can look into the issue.

Savage documentation is not available, and I have no Savage hardware
with which to investigate Savage related problems currently.

I will investigate if there is a newer driver available that we might
be able to test with.
Comment 2 Mike A. Harris 2002-11-03 06:50:34 EST
Problem is fixed in 4.2.0-72 in Red Hat Linux 8.0.  Future erratum for
7.3 and 8.0 will contain this new Savage driver as well.  I'm setting
this bug report to MODIFIED for now pending testing results from you
with either 8.0, or with the new erratum once released.

As soon as you can confirm this is fixed, or still broken, please update
the report.
Comment 3 NILMONI DEB 2002-11-03 11:35:01 EST
To start with, the problem was not there with acceleration disabled (x11 video 
output). It was solely related to the xvideo output. As per the driver release 
(v1.1.25t) from http://www.probo.com/timr/savage40.html , this problem with 
xvideo seems to be fixed. So if the latest errata release includes this 
version, this bug should be considered close.

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