Messages in this thread | | | Date | Tue, 7 Sep 2004 21:13:07 -0700 (PDT) | From | Mike Mestnik <> | Subject | Re: [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/
| |