search for: ttm_bo_delayed_delete

ttm_bo_delayed_delete has a race condition, because after we do: kref_put(&nentry->list_kref, ttm_bo_release_list); we are not holding the list lock and not holding any reference to objects, and thus every bo in the list can be removed and freed at this point. However, we then use the next pointer we stored, wh...

Resending this with Thomas Hellstrom's signoff for merging into 2.6.33 ttm_bo_delayed_delete has a race condition, because after we do: kref_put(&nentry->list_kref, ttm_bo_release_list); we are not holding the list lock and not holding any reference to objects, and thus every bo in the list can be removed and freed at this point. However, we then use the next pointer we stored, wh...

ttm_bo_delayed_delete has a race condition, because after we do: kref_put(&nentry->list_kref, ttm_bo_release_list); we are not holding the list lock and not holding any reference to objects, and thus every bo in the list can be removed and freed at this point. However, we then use the next pointer we stored, wh...

Am 23.07.2014 09:31, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 9:26 AM, Christian K?nig > <deathsimple at vodafone.de> wrote: >> It's not a locking problem I'm talking about here. Radeons lockup handling >> kicks in when anything calls into the driver from the outside, if you have a >> fence wait function that's called from the outside but

...here is something wrong here. As far as I can tell it wouldn't need to be reworked for the fence implementation currently, only the moment you want to allow callers outside of radeon. :-) Doing a GPU lockup recovery in the wait function would be messy even right now, you would hit a deadlock in ttm_bo_delayed_delete -> ttm_bo_cleanup_refs_and_unlock. Regardless of the fence implementation, why would it be a good idea to do a full lockup recovery when some other driver is calling your wait function? That doesn't seem to be a nice thing to do, so I think a timeout is the best error you could return here,...

Hey Jeremy, Please pull from devel/pat (based off your xen/dom0/core tree) which has one patch: Konrad Rzeszutek Wilk (1): xen/pat: make pte_flags(x) a pvops function. which is neccessary for the drivers/gpu/drm/radeon driver to work properly with AGP based cards (which look to be the only ones that try to set WC on pages). Also please pull from devel/kms.fixes-05 (based off your

On Thu, Jul 04, 2019 at 12:17:48PM -0700, Chia-I Wu wrote: > On Thu, Jul 4, 2019 at 4:10 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > Hi, > > > > > > - r = ttm_bo_reserve(&bo->tbo, true, false, NULL); > > > > + r = reservation_object_lock_interruptible(bo->gem_base.resv, NULL); > > > Can you elaborate a

...mething wrong here. > As far as I can tell it wouldn't need to be reworked for the fence implementation currently, only the moment you want to allow callers outside of radeon. :-) > Doing a GPU lockup recovery in the wait function would be messy even right now, you would hit a deadlock in ttm_bo_delayed_delete -> ttm_bo_cleanup_refs_and_unlock. > > Regardless of the fence implementation, why would it be a good idea to do a full lockup recovery when some other driver is > calling your wait function? That doesn't seem to be a nice thing to do, so I think a timeout is the best error you coul...

https://bugs.freedesktop.org/show_bug.cgi?id=111642 Bug ID: 111642 Summary: NV43 GeForce 6600 Nouveau is not stable on legacy hardware Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: Driver/nouveau