Bug 69766 - Hard lockup with s3 prosavage km133 video
Summary: Hard lockup with s3 prosavage km133 video
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-07-25 05:18 UTC by NILMONI DEB
Modified: 2007-04-18 16:44 UTC (History)
0 users

Fixed In Version: FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-01 21:43:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description NILMONI DEB 2002-07-25 05:18:25 UTC
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 18:34:25 UTC
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 11:50:34 UTC
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 16:35:01 UTC
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.