lkml.org 
[lkml]   [2004]   [Sep]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG] r200 dri driver deadlocks
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
-
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:06    [W:0.024 / U:4.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site