[MPlayer-dev-eng] machine lockup due to xv driver

[pl]

On Wed, Jul 24, 2002 at 01:10:36AM -0400, Nilmoni Deb wrote:
> 
> This is in reference to my earlier post in
> 
> http://mplayerhq.hu/pipermail/mplayer-users/2002-July/018457.html
> 
> My investigattion shows that till cvs 2002/7/19, things are ok but the cvs
> of 2002/7/20 is consistently leading to machine lockup when mplayer is run
> with "-vo xv". I found out (after 10 manual resets, the hard way) that 
> this is due to the changes made for audio and video equalizer handling.
> 
> Here's the tests I ran.
> 
> Test1
> -----
> - get cvs of 2002/7/19
> - version of mplayer.c is 1.527
> - update these files manually: 
> 	video_out.c (1.53), video_out.h (1.37), vo_xv.c (1.105)
> 
> This one has no problems.
> 
> Test2
> -----
> Do everything in test1 and also update mplayer.c to v1.528.
> 
> This one caused hard lockup.
> 
> 
> This means the changes in mplayer.c _alone_ (between v1.527 and v1.528) 
> are triggerring the savage driver bug. It may be working with mga g400
> [x]mga,xv,xvidix and radeon xv,xvidix etc. but its failing with
> the prosavage km133 xv. 
> 
> So I commented out line 1387 of mplayer.c (cvs version v1.528), which is:
> 
> 	set_video_eq( v_hw_equ_cap );
> 
> This change made the lockup problem go away which means something in the
> function set_video_eq( int cap ) is going wrong and causing the lockup.
> 
> While this new problem may be hard to solve, if left unattended, users
> of km133 prosavage video (and other similar chipsets) will be stuck
> forever. I am ready to test out each revision (at the cost of manual
> resets!!), only if somebody is ready to address the issue.
> 
> Here's a part of the output of xvinfo on my system:
> 
>     number of attributes: 5
>       "XV_COLORKEY" (range 0 to 16777215)
>               client settable attribute
>               client gettable attribute (current value is 66046)
>       "XV_BRIGHTNESS" (range -128 to 127)
>               client settable attribute
>               client gettable attribute (current value is 0)
>       "XV_CONTRAST" (range 0 to 255)
>               client settable attribute
>               client gettable attribute (current value is 128)
>       "XV_SATURATION" (range 0 to 255)
>               client settable attribute
>               client gettable attribute (current value is 128)
>       "XV_HUE" (range -180 to 180)
>               client settable attribute
>               client gettable attribute (current value is 0)
> 
> 
> Compare this with the initial values (in video_out.c)
> 
> int vo_gamma_brightness=-101;
> int vo_gamma_saturation=-101;
> int vo_gamma_contrast=-101;
> int vo_gamma_hue=-101;
> 
> Obviously, vo_gamma_saturation and vo_gamma_contrast are outside their
> permitted range. Could this be the problem ?

It is a problem. I reported the bug on the -cvs mailing list as it was
triggered with nvidia drivers. Pontscho commited a quick workaround for
nvidia but the initialization does not seem fixed :/

You might try replacing in libvo/vo_xv.c:
                    if(!port_value && use_reset) continue
by a
                    if(port_value < -100 || port_value > 100) continue;

This should prevent out of range values from being sent to your xv driver
which should ignore them instead of crashing.

-- 
Best regards,
  pl