lkml.org 
[lkml]   [2004]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG] r200 dri driver deadlocks
On Sun, 05 Sep 2004 20:14:43 -0400
Lee Revell <rlrevell@joe-job.com> wrote:

> On Sun, 2004-09-05 at 16:18, Patrick McFarland wrote:
[snip]
> >
> > That shouldn't matter, should it? The userland stuff should never lock
> > the machine up.
> > I'll test it anyhow, though.
>
> No, it shouldn't. Anything that directly accesses hardware belongs in
> the kernel. How to fix this is a pretty hot topic now.

That's not the whole truth. There are just too many ways to lock up
those 3D chips. For instance I fixed a lockup in the r100 driver where
the order in which state changing commands were sent to the hardware
would cause a lockup. Each individual state changing command is
perfectly valid. Finding all permutations that trigger a lockup would
have been too much of a hassle and may not even have been true for all
supported hardware out there. So we made the user-space driver emit
state changing commands in a fixed order, which seems to work
everywhere.

Regars,
Felix

>
> Lee
>

| Felix Kühling <fxkuehl@gmx.de> http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.413 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site