[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#234388: related bug 179660?



On Tue, 6 Apr 2004 02:46:42 -0500
Branden Robinson <branden@debian.org> wrote:

> On Fri, Apr 02, 2004 at 09:06:54PM -0500, raseesink@hotpop.com wrote:
> > The behaviour the patch (035_tdfx_disable_dri_on_16mb_with_highres.diff)
> > prevented sounds a lot like bug #179660.
> 
> Okay.
> 
> > I did some strace back then on an old version of xfree86. The thread
> > mentioned in the bug report which contains them is moved. It is now in:
> > http://bzbb.bzflag.org/viewtopic.php?t=105
> 
> Hm.  That thread seems to be mostly about NVidia cards and AMD systems.
> 
> Are you sure that's the right URL?
> 
> If so, could you please summarize the information of relevance here?
It's the right url. Since the nature of the bug is general (screen freezes)
I suspect some of the reports in that thread are not about the same bug.
Difficult to draw conclusion...

Anyway this is what I think could be relevant:
* When playing fullscreen X cannot be killed. Complete system freeze, no console switching possible, remote ssh still works.
* It is reported that playing in a window will let you kill the xserver and prevent a reboot.
* There are report of this happening with NVIDIA and tdfx. Not sure if this is the saem bug.
* AMD processor seems unrelated to me. I have intel
* Somebody reported a freeze on windows. This must be unrelated, or the bug is in shared openGL code. Mouse in windows still worked.
* Somebody else reported it happend on a mac. Detail on mac: "First, at least on the mac, there appears to be a direct relation between enabling the "Lighting" and "Blending" options and the crashes. If you are unable to debug, eager to simply play, or both disabling one or both of those options may solve your problem."
* Somebody reported it went away with a motherboard switch, Old MB: Albatron KM266PRO, New MB: Asus A7N8X Deluxe
* Problem is reported for Radeon 7200 as well

It is in some library somewhere since I tried to track down where it happened in the bzflag source.
BZflag has two threads, one for sounds and one for graphics. Graphics thread stops on a freeze,
but it seems it stops at entirely different spots in the code. This led me to believe it is in
a graphics library, probably opengl related.

And then I gave up, not sure how to futher track it down. Maybe I should brush up on my debugger knowledge
and try -dbg packages. The strace at the start of the thread is of bzflag and not the xserver. It always
ended in the same way on a freeze.
 
> > Not sure if this helps, but it might solve / close 179660 as well.
> [...]
> 
> So what you're saying is, we should have closed bug #179660 when patch
> #035 was added?  Do I understand you correctly?
Well, if patch #035 disables circumstances in which it can happen, which I
haven't tested yet, it would make sense to close it. The correlation is based
on the desciption of the behaviour by Mike A. Harris about quake freezing.
But removing a feature is probably not the best way of solving a bug.

> 
> > P.S. I have a tdfx card (monster Fusion) and can do tests. Mail me if
> > needed.
> 
> Cool.  I've been wondering if a "LiveDangerously" option should be added
> to the tdfx driver to enable people so switch this restriction on the
> maximum resolution under DRI on and off.
> 
> Then they could decide for themselves whether they can live with the
> instability, or verify if it even still exists.

That would seem the best solution to me if it can't be fixed.

Cheers,
Remco.

> 
> -- 
> G. Branden Robinson                |    If you wish to strive for peace of
> Debian GNU/Linux                   |    soul, then believe; if you wish to
> branden@debian.org                 |    be a devotee of truth, then
> http://people.debian.org/~branden/ |    inquire.     -- Friedrich Nietzsche
> 




Reply to: