mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mike Mestnik <cheako911@yahoo.com>
To: Dave Airlie <airlied@gmail.com>,
	arjanv@redhat.com,
	Roland Scheidegger <rscheidegger_lists@hispeed.ch>
Cc: " \"Felix_Kühling\"" <fxkuehl@gmx.de>,
	"Lee Revell" <rlrevell@joe-job.com>,
	diablod3@gmail.com, dri-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: [BUG] r200 dri driver deadlocks
Date: Tue, 7 Sep 2004 21:13:07 -0700 (PDT)	[thread overview]
Message-ID: <20040908041307.34927.qmail@web11908.mail.yahoo.com> (raw)
In-Reply-To: <21d7e997040907013071ebb60d@mail.gmail.com>

Sorry, I don't know why we are cross posting and including subscribers in
CC.  This belongs on the DRI list, as it is only with 3rd party DRI-client
code that the problem exists.

--- Dave Airlie <airlied@gmail.com> wrote:

> On Tue, 07 Sep 2004 09:07:11 +0200, Arjan van de Ven <arjanv@redhat.com>
> wrote:
> > On Tue, 2004-09-07 at 08:54, Dave Airlie wrote:
> > 
> > > Feel free to implement it and profile it, but there are so many ways
> > > to lock up a radeon chip it is scary, the above was just one
> example,
> > > some days if you look at it funny it can lockup :-), it is accepted
> > > that userland can crap out 3D chips, the Intel ones are fairly easy
> to
> > > hangup also..
> > 
> > 
> > hmmm.. I thought the entire reason for having part of DRM in the
> kernel
> > was to be able to prevent such events from happening....
> 
> only one reason...
> http://dri.sourceforge.net/doc/drm_low_level.html
> 
> But to be honest the chips are entirely capable of locking up on what
> the docs say are valid things, writing enough workarounds and test
> would bloat the drm considerably,
> at the moment we try and have it so a valid OpenGL application doesn't
> lock it up, but someone writing directly to the DRM would be able to
> lockup a fair few chips in many interesting ways....
> 
> Dave.
> 

--- Roland Scheidegger <rscheidegger_lists@hispeed.ch> wrote:
> 
> I seriously doubt this is doable. Unless you put the whole driver in the
> 
> kernel, which of course nobody wants. I frequently caused gpu lockups by
> 
> experimental driver changes (for instance, wrong vertex setup). I think 
> the consensus was that it's ok for the driver to lock up the gpu, but it
> 
> should not lock up the kernel.
> It might be possible to prevent lockups by a watchdog, resetting the gpu
> 
> if a lockup is detected. This is how ATI deals with lockups in windows 
> (dubbed "VPU Recover"), and there is a patch floating around for DRI too
> 
> (though it is not exactly for that, and doesn't always work).
> 
> Roland
> 

It's a simple matter of enforcing 3rd party(this means every DRM user)
clients to use DRI's *dialect or style*.  If the DRM see activities that
are not expected to be generated by pure DRI-clients, action should be
taken to prevent a posible lockup.  This means that even valid activities
should be treated as invalid IF the DRM can clerly detect a deviation from
pure DRI-client activities.

For example, pure DRI-clients emit state changing commands is a vary
specific order.  The DRM could easily spot if these cmds where out of any
knowen/used order or if any other cmds where also inserted into the
expected order.  This should be denied"."  Only DRI-clients(any client)
using the DRI supplied order(the one used by pure DRI-clients) should be
allowed to access the hardware.






		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

       reply	other threads:[~2004-09-08  4:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <21d7e997040907013071ebb60d@mail.gmail.com>
2004-09-08  4:13 ` Mike Mestnik [this message]
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
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

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=20040908041307.34927.qmail@web11908.mail.yahoo.com \
    --to=cheako911@yahoo.com \
    --cc=airlied@gmail.com \
    --cc=arjanv@redhat.com \
    --cc=diablod3@gmail.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=fxkuehl@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rlrevell@joe-job.com \
    --cc=rscheidegger_lists@hispeed.ch \
    /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

all inboxes | Powered by JetHome®