Bug 473175 - drm lockdep trace
drm lockdep trace
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FCMETA_LOCKDEP
  Show dependency treegraph
 
Reported: 2008-11-26 17:39 EST by Dave Jones
Modified: 2015-01-04 17:30 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-01 21:23:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Jones 2008-11-26 17:39:20 EST
=============================================
[ INFO: possible recursive locking detected ]
2.6.27.5-117.fc10.x86_64.debug #1
---------------------------------------------
Xorg/2689 is trying to acquire lock:
 (&bo->mutex){--..}, at: [<ffffffffa001d694>] drm_bo_mem_space+0x2ad/0x371 [drm]

but task is already holding lock:
 (&bo->mutex){--..}, at: [<ffffffffa001d924>] drm_bo_do_validate+0x52/0x533 [drm]

other info that might help us debug this:
2 locks held by Xorg/2689:
 #0:  (&bo->mutex){--..}, at: [<ffffffffa001d924>] drm_bo_do_validate+0x52/0x533 [drm]
 #1:  (&dev->bm.evict_mutex){--..}, at: [<ffffffffa001d7bd>] drm_bo_move_buffer+0x65/0x17a [drm]

stack backtrace:
Pid: 2689, comm: Xorg Not tainted 2.6.27.5-117.fc10.x86_64.debug #1

Call Trace:
 [<ffffffff81064759>] __lock_acquire+0x82c/0xc06
 [<ffffffff81064bc0>] lock_acquire+0x8d/0xba
 [<ffffffffa001d694>] ? drm_bo_mem_space+0x2ad/0x371 [drm]
 [<ffffffff8134c87a>] __mutex_lock_common+0xed/0x35d
 [<ffffffffa001d694>] ? drm_bo_mem_space+0x2ad/0x371 [drm]
 [<ffffffffa001d694>] ? drm_bo_mem_space+0x2ad/0x371 [drm]
 [<ffffffff8134cb93>] mutex_lock_nested+0x35/0x3a
 [<ffffffffa001d694>] drm_bo_mem_space+0x2ad/0x371 [drm]
 [<ffffffffa001d7f5>] drm_bo_move_buffer+0x9d/0x17a [drm]
 [<ffffffffa001dbbb>] drm_bo_do_validate+0x2e9/0x533 [drm]
 [<ffffffff81016a55>] ? native_sched_clock+0x8e/0xa8
 [<ffffffffa0050183>] radeon_gem_set_domain+0x100/0x149 [radeon]
 [<ffffffff8117cf8c>] ? _raw_spin_unlock+0x8e/0x93
 [<ffffffffa00501f7>] radeon_gem_do_relocate+0x2b/0x89 [radeon]
 [<ffffffffa001323e>] ? drm_gem_object_lookup+0x46/0x52 [drm]
 [<ffffffffa0050312>] radeon_gem_prelocate+0xbd/0x149 [radeon]
 [<ffffffffa0053bb4>] radeon_cs2_ioctl+0x2b4/0x364 [radeon]
 [<ffffffffa0011e8a>] drm_ioctl+0x1df/0x26a [drm]
 [<ffffffff8117cff9>] ? _raw_spin_lock+0x68/0x116
 [<ffffffffa0053900>] ? radeon_cs2_ioctl+0x0/0x364 [radeon]
 [<ffffffff810d53a3>] vfs_ioctl+0x5f/0x78
 [<ffffffff810d5613>] do_vfs_ioctl+0x257/0x274
 [<ffffffff810d5685>] sys_ioctl+0x55/0x78
 [<ffffffff8101022a>] system_call_fastpath+0x16/0x1b
Comment 1 François Cami 2009-02-16 10:26:46 EST
Dave,

Is this reproductible on current F10 ?
Could you post full dmesg and /var/log/Xorg.0.log as uncompressed text/plain attachments to this bug, please ?

Thanks

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 2 Dave Airlie 2009-10-01 21:23:24 EDT
won't probably fix this at this stage, upstream code doesn't have this issue.

Note You need to log in before you can comment on or make changes to this bug.