dri xscreensaver/kernel lockups

[Pekka Savola]

Hi,

A huge number of (probably DRI -related) xscreensaver lockups (especially 
with screensavers with a lot of 3D effects) have been reported in the 
past; check a list e.g. from:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84214

(I tried to collect a few I found there).

1) have folks tested whether these still persist in Fedora Core as well?

2) is there any hope of getting these bugs fixed?
 b) if one wants a workaround, just simply removing "too flashy" 
screensavers might help .. but then the bugs would not get fixed ;-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

[Elton Woo]

On October 1, 2003 01:56 am, Pekka Savola <Pekka Savola <pekkas(a)netcore.fi&gt;&gt; 
wrote:
>  Hi,
>
>  A huge number of (probably DRI -related) xscreensaver lockups (especially
>  with screensavers with a lot of 3D effects) have been reported in the
>  past; check a list e.g. from:
>
>  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84214
>  
Uh-oh! Buzgilla is out of commission:
"Bugzilla is currently experiencing technical difficulties. 

We apologize for any inconvenience, please check back soon. "
(01 Oct. 2003 - 13:15 EST).

Elton.
-- 
http://setiathome.ssl.berkeley.edu/stats/team/team_4504.html
"You only live once: let's make life BETTER for each other."
LINUX User #193975 [AMD ATHLON CPU] ICQ #149608718.

[Mike A. Harris]

On Wed, 1 Oct 2003, Pekka Savola wrote:

> A huge number of (probably DRI -related) xscreensaver lockups
> (especially with screensavers with a lot of 3D effects) have
> been reported in the past; check a list e.g. from:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84214
>
> (I tried to collect a few I found there).
>
> 1) have folks tested whether these still persist in Fedora Core as well?
>
> 2) is there any hope of getting these bugs fixed?
>  b) if one wants a workaround, just simply removing "too flashy" 
> screensavers might help .. but then the bugs would not get fixed ;-) 
More likely than not, all reported issues still exist.  The easy 
workaround is to either disable DRI, or to disable the 
screensavers that trigger the lockup.  This allows one to use 
their computer for day to day work, etc. without experiencing the 
lockup issues.

In some cases, simply disabling the screensavers triggering the
issue will allow the user to use other 3D applications without 
problem, while other cases the problem is deeper and affects all 
3D applications including non-screensavers.

Debugging 3D acceleration related problems in the DRI is one of 
the more complex and time consuming of all problems that get 
reported against XFree86.  Problems can take anywhere from a day 
to a week or two if not more in order to diagnose.  Since it is 
often easy to workaround the problem by disabling a screensaver 
or whatnot, such problems aren't of the highest priority, in 
particular when most problems with DRI are reported against 
screensavers and/or video games.

Currently, there are only 2 developers here at Red Hat working on 
XFree86 - myself, and John Dennis.  John's work has mostly 
focused on handling XFree86 related problems on ia64 and other 
architectures for our Red Hat Enterprise Linux development so 
far, however we hope to work more closely in the future with 
development/troubleshooting/debugging/etc.

With only 2 developers, and the plethora of incoming bug reports
that do get reported, it's not possible for every single bug
report to get immediate attention and guaranteed fixes due to the 
need to prioritize work.  Also, XFree86 isn't the only work we're 
responsible for, so we need to balance the various duties we're 
responsible for in order to accomplish the most amount of work in 
the least amount of time, and to fix the most number of problems 
that affect the most number of people.

When it comes to bugs in the DRI and the kernel portion of it 
(the DRM), spending an unknown amount of time debugging an issue 
which may require up to a week or 3 and may end up still being 
unable to determine the cause of a given problem - just to fix a 
hangup caused by a screensaver that can be easily disabled, or to 
a bug triggered by Quake 3, Unreal Tournament 2003 or somesuch, 
just isn't the best usage of Red Hat engineering resources.  As 
such, these kinds of problems tend to be much lower priority.  

Also, for the video game issues at least, I often do not have the 
video game which triggers the question, so am unable to 
investigate the issue without forking out $70 or more out of my 
own pocket, although I do have RTCW, and a few others...

Often, the problems are bugs in the kernel DRM code, and
sometimes get fixed magically when the DRM gets updated and a new
kernel pushed out in an update.  Other times the problems are 
motherboard or video card specific, and we simply don't have the 
hardware.  Or it could be the specific combination of video card 
and motherboard chipset, operating with a specific AGP speed.  
The number of variables one can chase around are staggering 
potentially, and a lot of time can be spent.

In short, DRI/DRM related bugs found in X, should always be 
reported directly to the DRI project, as there are 10+ developers 
who more or less do nothing but develop DRI all day long, and 
troubleshoot these types of issues.  It's much more likely to be 
fixed by them, and patches that come out of it possibly included 
in our future kernel and/or XFree86 updates, than it is likely to 
get 2 or 3 weeks of my or John's very limited time.  However, 
even if someone does report this upstream to the DRI project 
(preferably by way of http://bugs.xfree86.org), it's always a 
good idea to keep reporting the bugs in Red Hat bugzilla also, in 
order for me to be aware of the problem, and be able to track it 
upstream, or to have some fun poking at video games on the 
weekend to try and fix it in my own personal time.

I know these types of responses are not the kind that users 
expect or want to hear from developers, however I like to be 
straightforward and honest about these types of things.  
Developer resources are a very limited thing, and we need to 
spend our Red Hat engineering time on things that give the 
biggest bang and affect the most users out there, and bugs 
affecting business usage generally get preference over "toy" bugs 
such as video games and screensavers (although what I do in my 
spare time on weekends can definitely be quite the opposite 
<grin>).

Also, the more a person is willing to crack out a debugger, or to
sprinkle printk()'s in the DRM source code, and hop on #dri-devel
on irc.freenode.net and stay in the channel for a week or more
along with developers, the more us foolish developers can be
sucked into devoting some of our personal time to such problems 
too.  Not that it's easy or anything, but some determined folk 
have showed up, and hounded us until they were able to fix a 
problem themselves, with no prior XFree86 or kernel programming 
knowledge, so it is possible.  ;o)

I can be found usually on #dri-devel, #xfree86, #xwin, 
#freedesktop and other channels on irc.freenode.net, however I'm 
not always there when I'm there...  If someone comes hunting me 
down, you're best off staying in the channel and idling until 
myself or others can help with debugging/etc.

Hope this helps explain things, and at the same time give people 
some perspective, and some insight into the best way to go about 
seeking solutions to these types of problems in a way that can 
yield faster fixes and whatnot.

TTYL

-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat

[Alan]

I have seen something that looks like a lockup, but is not.  (The system 
still works, but X is stuck in an alarm wait loop.)

The telling difference is that you can still ssh into the box and strace 
X.  X will be pegging at 99+%.  Of course, if you only have one CPU, it 
may seem like you are dead.

Want a copy of the strace for exact messages?

On Thu, 9 Oct 2003, Mike A. Harris wrote:

>  On Wed, 1 Oct 2003, Pekka Savola wrote:
>  
>  >A huge number of (probably DRI -related) xscreensaver lockups
>  >(especially with screensavers with a lot of 3D effects) have
>  >been reported in the past; check a list e.g. from:
>  >
>  >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84214
>  >
>  >(I tried to collect a few I found there).
>  >
>  >1) have folks tested whether these still persist in Fedora Core as well?
>  >
>  >2) is there any hope of getting these bugs fixed?
>  > b) if one wants a workaround, just simply removing "too flashy" 
>  >screensavers might help .. but then the bugs would not get fixed ;-)
>  
>  More likely than not, all reported issues still exist.  The easy 
>  workaround is to either disable DRI, or to disable the 
>  screensavers that trigger the lockup.  This allows one to use 
>  their computer for day to day work, etc. without experiencing the 
>  lockup issues.
>  
>  In some cases, simply disabling the screensavers triggering the
>  issue will allow the user to use other 3D applications without 
>  problem, while other cases the problem is deeper and affects all 
>  3D applications including non-screensavers.
>  
>  Debugging 3D acceleration related problems in the DRI is one of 
>  the more complex and time consuming of all problems that get 
>  reported against XFree86.  Problems can take anywhere from a day 
>  to a week or two if not more in order to diagnose.  Since it is 
>  often easy to workaround the problem by disabling a screensaver 
>  or whatnot, such problems aren't of the highest priority, in 
>  particular when most problems with DRI are reported against 
>  screensavers and/or video games.
>  
>  Currently, there are only 2 developers here at Red Hat working on 
>  XFree86 - myself, and John Dennis.  John's work has mostly 
>  focused on handling XFree86 related problems on ia64 and other 
>  architectures for our Red Hat Enterprise Linux development so 
>  far, however we hope to work more closely in the future with 
>  development/troubleshooting/debugging/etc.
>  
>  With only 2 developers, and the plethora of incoming bug reports
>  that do get reported, it's not possible for every single bug
>  report to get immediate attention and guaranteed fixes due to the 
>  need to prioritize work.  Also, XFree86 isn't the only work we're 
>  responsible for, so we need to balance the various duties we're 
>  responsible for in order to accomplish the most amount of work in 
>  the least amount of time, and to fix the most number of problems 
>  that affect the most number of people.
>  
>  When it comes to bugs in the DRI and the kernel portion of it 
>  (the DRM), spending an unknown amount of time debugging an issue 
>  which may require up to a week or 3 and may end up still being 
>  unable to determine the cause of a given problem - just to fix a 
>  hangup caused by a screensaver that can be easily disabled, or to 
>  a bug triggered by Quake 3, Unreal Tournament 2003 or somesuch, 
>  just isn't the best usage of Red Hat engineering resources.  As 
>  such, these kinds of problems tend to be much lower priority.  
>  
>  Also, for the video game issues at least, I often do not have the 
>  video game which triggers the question, so am unable to 
>  investigate the issue without forking out $70 or more out of my 
>  own pocket, although I do have RTCW, and a few others...
>  
>  Often, the problems are bugs in the kernel DRM code, and
>  sometimes get fixed magically when the DRM gets updated and a new
>  kernel pushed out in an update.  Other times the problems are 
>  motherboard or video card specific, and we simply don't have the 
>  hardware.  Or it could be the specific combination of video card 
>  and motherboard chipset, operating with a specific AGP speed.  
>  The number of variables one can chase around are staggering 
>  potentially, and a lot of time can be spent.
>  
>  In short, DRI/DRM related bugs found in X, should always be 
>  reported directly to the DRI project, as there are 10+ developers 
>  who more or less do nothing but develop DRI all day long, and 
>  troubleshoot these types of issues.  It's much more likely to be 
>  fixed by them, and patches that come out of it possibly included 
>  in our future kernel and/or XFree86 updates, than it is likely to 
>  get 2 or 3 weeks of my or John's very limited time.  However, 
>  even if someone does report this upstream to the DRI project 
>  (preferably by way of http://bugs.xfree86.org), it's always a 
>  good idea to keep reporting the bugs in Red Hat bugzilla also, in 
>  order for me to be aware of the problem, and be able to track it 
>  upstream, or to have some fun poking at video games on the 
>  weekend to try and fix it in my own personal time.
>  
>  I know these types of responses are not the kind that users 
>  expect or want to hear from developers, however I like to be 
>  straightforward and honest about these types of things.  
>  Developer resources are a very limited thing, and we need to 
>  spend our Red Hat engineering time on things that give the 
>  biggest bang and affect the most users out there, and bugs 
>  affecting business usage generally get preference over "toy" bugs 
>  such as video games and screensavers (although what I do in my 
>  spare time on weekends can definitely be quite the opposite 
>  <grin>).
>  
>  Also, the more a person is willing to crack out a debugger, or to
>  sprinkle printk()'s in the DRM source code, and hop on #dri-devel
>  on irc.freenode.net and stay in the channel for a week or more
>  along with developers, the more us foolish developers can be
>  sucked into devoting some of our personal time to such problems 
>  too.  Not that it's easy or anything, but some determined folk 
>  have showed up, and hounded us until they were able to fix a 
>  problem themselves, with no prior XFree86 or kernel programming 
>  knowledge, so it is possible.  ;o)
>  
>  I can be found usually on #dri-devel, #xfree86, #xwin, 
>  #freedesktop and other channels on irc.freenode.net, however I'm 
>  not always there when I'm there...  If someone comes hunting me 
>  down, you're best off staying in the channel and idling until 
>  myself or others can help with debugging/etc.
>  
>  Hope this helps explain things, and at the same time give people 
>  some perspective, and some insight into the best way to go about 
>  seeking solutions to these types of problems in a way that can 
>  yield faster fixes and whatnot.
>  
>  TTYL
>  
>