search for: exclusive_lock

...I've been working on tracking it down and here's what I've got so far: 1. I create a file from node 0. This succeeds; I can /bin/cat the file, append, edit, or whatever. 2. From node 1, I do an operation that accesses the DirNode (e.g. /bin/ls) 3. Node 0 immediately acquires a OCFS_DLM_EXCLUSIVE_LOCK on the DirNode itself (although I seem to still be able to *read* the DirNode from node 1) 4. I attempt to create a file from node 1... node 1 hangs, waiting for the exclusive lock on the DirNode to be released. *** node 1 is now completely dysfunctional. OCFS is hung. 5. I delete the file I crea...

...I've been working on tracking it down and here's what I've got so far: 1. I create a file from node 0. This succeeds; I can /bin/cat the file, append, edit, or whatever. 2. From node 1, I do an operation that accesses the DirNode (e.g. /bin/ls) 3. Node 0 immediately acquires a OCFS_DLM_EXCLUSIVE_LOCK on the DirNode itself (although I seem to still be able to *read* the DirNode from node 1) 4. I attempt to create a file from node 1... node 1 hangs, waiting for the exclusive lock on the DirNode to be released. *** node 1 is now completely dysfunctional. OCFS is hung. 5. I delete the file I crea...

...store(&rdev->irq.lock, irqflags); > +} > + > /** > * radeon_gpu_reset - reset the asic > * > @@ -1624,6 +1673,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) > > int i, r; > int resched; > + uint32_t sw_mask; > > down_write(&rdev->exclusive_lock); > > @@ -1637,6 +1687,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) > radeon_save_bios_scratch_regs(rdev); > /* block TTM */ > resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev); > + sw_mask = radeon_gpu_mask_sw_irq(rdev); > radeon_pm_suspend(rde...

...>>>> [SNIP] >>>> The problem here is that the whole approach collides with the way >>>> we do reset handling from a conceptual point of view. Every IOCTL >>>> or other call chain into the driver is protected by the read side >>>> of the exclusive_lock semaphore. So in the case of a GPU lockup we >>>> can take the write side of the semaphore and so make sure that we >>>> have nobody else accessing the hardware or internal driver >>>> structures only changed at init time. >>>> >>>> Lea...

...ck, irqflags); + radeon_irq_set(rdev); + spin_unlock_irqrestore(&rdev->irq.lock, irqflags); +} + /** * radeon_gpu_reset - reset the asic * @@ -1624,6 +1673,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) int i, r; int resched; + uint32_t sw_mask; down_write(&rdev->exclusive_lock); @@ -1637,6 +1687,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) radeon_save_bios_scratch_regs(rdev); /* block TTM */ resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev); + sw_mask = radeon_gpu_mask_sw_irq(rdev); radeon_pm_suspend(rdev); radeon_suspend(rdev); @@ -...

...ck, irqflags); + radeon_irq_set(rdev); + spin_unlock_irqrestore(&rdev->irq.lock, irqflags); +} + /** * radeon_gpu_reset - reset the asic * @@ -1624,6 +1673,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) int i, r; int resched; + uint32_t sw_mask; down_write(&rdev->exclusive_lock); @@ -1637,6 +1687,7 @@ int radeon_gpu_reset(struct radeon_device *rdev) radeon_save_bios_scratch_regs(rdev); /* block TTM */ resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev); + sw_mask = radeon_gpu_mask_sw_irq(rdev); radeon_pm_suspend(rdev); radeon_suspend(rdev); @@ -...

Changes since v1: - Fixed interaction with reset handling. + Use exclusive_lock, either with trylock or blocking. + Bump sw irq refcount in the recovery function to prevent fiddling with irq registers during gpu recovery. - Add radeon lockup detection to the default fence wait function. --- diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h...

Am 02.06.2014 12:09, schrieb Maarten Lankhorst: > Changes since v1: > - Fixed interaction with reset handling. > + Use exclusive_lock, either with trylock or blocking. > + Bump sw irq refcount in the recovery function to prevent fiddling > with irq registers during gpu recovery. > - Add radeon lockup detection to the default fence wait function. First of all please separate out adding the timeout parameter to the...

Am 04.08.2014 um 17:09 schrieb Maarten Lankhorst: > op 04-08-14 17:04, Christian K?nig schreef: >> Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst: >>> op 04-08-14 16:45, Christian K?nig schreef: >>>> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst: >>>>> op 04-08-14 16:37, Christian K?nig schreef: >>>>>>> It'a pain to deal

...;>>>> + return radeon_fence_wait_seq_timeout(fence->rdev, >>>>>>> target_seq, intr, timeout); >>>>>>> +} >>>>>> When this call is comming from outside the radeon driver you need >>>>>> to lock rdev->exclusive_lock here to make sure not to interfere >>>>>> with a possible reset. >>>>> Ah thanks, I'll add that. >>>>> >>>>>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>>>>> .enable_signaling = ra...

....2014 10:00, schrieb Maarten Lankhorst: >> [SNIP] >> The problem here is that the whole approach collides with the way we >> do reset handling from a conceptual point of view. Every IOCTL or >> other call chain into the driver is protected by the read side of the >> exclusive_lock semaphore. So in the case of a GPU lockup we can take >> the write side of the semaphore and so make sure that we have nobody >> else accessing the hardware or internal driver structures only >> changed at init time. >> >> Leaking a drivers IRQ context into another...

...fence->ring] = fence->seq; >>>>>>>> + return radeon_fence_wait_seq_timeout(fence->rdev, target_seq, intr, timeout); >>>>>>>> +} >>>>>>> When this call is comming from outside the radeon driver you need to lock rdev->exclusive_lock here to make sure not to interfere with a possible reset. >>>>>> Ah thanks, I'll add that. >>>>>> >>>>>>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>>>>>> .enable_signaling = radeon_fence...

...e->ring] = fence->seq; >>>>> + return radeon_fence_wait_seq_timeout(fence->rdev, target_seq, >>>>> intr, timeout); >>>>> +} >>>> When this call is comming from outside the radeon driver you need >>>> to lock rdev->exclusive_lock here to make sure not to interfere >>>> with a possible reset. >>> Ah thanks, I'll add that. >>> >>>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>>> .enable_signaling = radeon_fence_enable_signaling, >>&gt...

...> + >>> + target_seq[fence->ring] = fence->seq; >>> + return radeon_fence_wait_seq_timeout(fence->rdev, target_seq, >>> intr, timeout); >>> +} >> When this call is comming from outside the radeon driver you need to >> lock rdev->exclusive_lock here to make sure not to interfere with a >> possible reset. > Ah thanks, I'll add that. > >>> .get_timeline_name = radeon_fence_get_timeline_name, >>> .enable_signaling = radeon_fence_enable_signaling, >>> .signaled = __radeon_fence_signal...

...gt; Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst: >>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> >>> --- >>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not >>> allowing radeon_fence_driver_check_lockup to take exclusive_lock, >>> and kill it during lockup recovery instead. >> That looks like the delayed work starts running as soon as we submit a fence, and not when it's needed for waiting. >> >> Since it's a backup for failing IRQs I would rather put it into radeon_irq_kms.c and start...

...gt;> + target_seq[fence->ring] = fence->seq; >>>>>> + return radeon_fence_wait_seq_timeout(fence->rdev, target_seq, intr, timeout); >>>>>> +} >>>>> When this call is comming from outside the radeon driver you need to lock rdev->exclusive_lock here to make sure not to interfere with a possible reset. >>>> Ah thanks, I'll add that. >>>> >>>>>> .get_timeline_name = radeon_fence_get_timeline_name, >>>>>> .enable_signaling = radeon_fence_enable_signaling, >>>&...

...ndle the lockup cause otherwise it could happen that radeon waits for the lockup to be resolved and the lockup handling needs to wait for a fence that's never signaled because of the lockup. Christian. > > This is also why fence_is_signaled should never block, and why it trylocks the exclusive_lock. :-) I think lockdep would complain if I grabbed exclusive_lock while blocking in is_signaled. > >>> So from the core fence framework I think we already have exactly this, >>> and we only need to adjust the radeon implementation a bit to make it >>> less risky and inva...

...>>> Am 19.05.2014 10:00, schrieb Maarten Lankhorst: >>> [SNIP] >>> The problem here is that the whole approach collides with the way we do reset handling from a conceptual point of view. Every IOCTL or other call chain into the driver is protected by the read side of the exclusive_lock semaphore. So in the case of a GPU lockup we can take the write side of the semaphore and so make sure that we have nobody else accessing the hardware or internal driver structures only changed at init time. >>> >>> Leaking a drivers IRQ context into another driver as well as call...

...eb Maarten Lankhorst: >>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> >>>>> --- >>>>> V1 had a nasty bug breaking gpu lockup recovery. The fix is not >>>>> allowing radeon_fence_driver_check_lockup to take exclusive_lock, >>>>> and kill it during lockup recovery instead. >>>> That looks like the delayed work starts running as soon as we submit a fence, and not when it's needed for waiting. >>>> >>>> Since it's a backup for failing IRQs I would rather put it...

Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst: > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > V1 had a nasty bug breaking gpu lockup recovery. The fix is not > allowing radeon_fence_driver_check_lockup to take exclusive_lock, > and kill it during lockup recovery instead. That looks like the delayed work starts running as soon as we submit a fence, and not when it's needed for waiting. Since it's a backup for failing IRQs I would rather put it into radeon_irq_kms.c and start/stop it when the IRQs are star...