mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Felix Kühling" <fxkuehl@gmx.de>
To: Lee Revell <rlrevell@joe-job.com>
Cc: diablod3@gmail.com, dri-devel@lists.sf.net, linux-kernel@vger.kernel.org
Subject: Re: [BUG] r200 dri driver deadlocks
Date: Mon, 6 Sep 2004 12:51:15 +0200	[thread overview]
Message-ID: <20040906125115.0d49db62.felix@trabant> (raw)
In-Reply-To: <1094429682.29921.6.camel@krustophenia.net>

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 |

  reply	other threads:[~2004-09-06 10:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-04  9:16 Patrick McFarland
2004-09-04 10:59 ` Dave Airlie
2004-09-05  8:40   ` Patrick McFarland
2004-09-04 18:14 ` Michel Dänzer
2004-09-04 20:36   ` Patrick McFarland
2004-09-05  6:34     ` Michel Dänzer
2004-09-05  8:22       ` Patrick McFarland
2004-09-05 17:40         ` Michel Dänzer
2004-09-05 20:18           ` Patrick McFarland
2004-09-05 20:25             ` Michel Dänzer
2004-09-05 21:47               ` Patrick McFarland
2004-09-06  0:14             ` Lee Revell
2004-09-06 10:51               ` Felix Kühling [this message]
2004-09-07  6:34                 ` Mike Mestnik
2004-09-07  6:54                   ` Dave Airlie
2004-09-07  7:06                     ` Mike Mestnik
2004-09-07  9:40                       ` Roland Scheidegger
2004-09-06 11:01               ` Patrick McFarland
2004-09-06 18:12                 ` Michel Dänzer
2004-09-07  9:07                   ` Patrick McFarland
2004-09-07  9:09                     ` Patrick McFarland
2004-09-07  9:41                     ` Alan Cox
2004-09-09  4:24                     ` Alexander E. Patrakov
     [not found] <21d7e997040907013071ebb60d@mail.gmail.com>
2004-09-08  4:13 ` Mike Mestnik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040906125115.0d49db62.felix@trabant \
    --to=fxkuehl@gmx.de \
    --cc=diablod3@gmail.com \
    --cc=dri-devel@lists.sf.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rlrevell@joe-job.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome