Bug 478583
| Summary: | Possible circular locking dependencies detected in 2.6.29 series | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | James <james> | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | rawhide | CC: | kernel-maint, kmcmartin, quintela, rwarsow | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-02-27 13:43:17 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 328037 [details]
2.6.29git3 log
got this one
...
hda-intel: Invalid position buffer, using LPIB read method instead.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-0.25.rc0.git14.fc11.i686 #1
-------------------------------------------------------
pulseaudio/2686 is trying to acquire lock:
(&pcm->open_mutex){--..}, at: [<f7df5b23>] snd_pcm_release+0x55/0x9e [snd_pcm]
but task is already holding lock:
(&mm->mmap_sem){----}, at: [<c0493c6b>] sys_munmap+0x23/0x3f
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&mm->mmap_sem){----}:
[<c044feaf>] __lock_acquire+0x9af/0xb22
[<c045007d>] lock_acquire+0x5b/0x81
[<c048dfe9>] might_fault+0x53/0x73
[<f7ee8f24>] snd_hda_mixer_amp_tlv+0x33/0xad [snd_hda_codec]
[<f7d1a2e4>] alc_cap_vol_tlv+0x45/0x59 [snd_hda_codec_realtek]
[<f7da6bb0>] snd_ctl_tlv_ioctl+0xcc/0x131 [snd]
[<f7da8177>] snd_ctl_ioctl+0xb0c/0xcd0 [snd]
[<c04b0e93>] vfs_ioctl+0x22/0x69
[<c04b1367>] do_vfs_ioctl+0x3c9/0x3f3
[<c04b13d1>] sys_ioctl+0x40/0x5a
[<c0403b76>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #2 (&codec->spdif_mutex){--..}:
[<c044feaf>] __lock_acquire+0x9af/0xb22
[<c045007d>] lock_acquire+0x5b/0x81
[<c06e16f8>] __mutex_lock_common+0xd5/0x329
[<c06e19e4>] mutex_lock_nested+0x2e/0x36
[<f7ee7516>] snd_hda_multi_out_analog_open+0x9b/0xed [snd_hda_codec]
[<f7d15ff0>] alc880_playback_pcm_open+0x14/0x19 [snd_hda_codec_realtek]
[<f7f02639>] azx_pcm_open+0x13c/0x1a7 [snd_hda_intel]
[<f7df6185>] snd_pcm_open_substream+0x46/0x97 [snd_pcm]
[<f7df627c>] snd_pcm_open+0xa6/0x182 [snd_pcm]
[<f7df63a4>] snd_pcm_playback_open+0x23/0x26 [snd_pcm]
[<f7da44db>] snd_open+0xd2/0x12f [snd]
[<c04a9244>] chrdev_open+0x124/0x13b
[<c04a55a0>] __dentry_open+0x168/0x267
[<c04a5739>] nameidata_to_filp+0x2c/0x43
[<c04af681>] do_filp_open+0x35f/0x67b
[<c04a5364>] do_sys_open+0x42/0xb7
[<c04a541b>] sys_open+0x1e/0x26
[<c0403b76>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #1 (&chip->open_mutex){--..}:
[<c044feaf>] __lock_acquire+0x9af/0xb22
[<c045007d>] lock_acquire+0x5b/0x81
[<c06e16f8>] __mutex_lock_common+0xd5/0x329
[<c06e19e4>] mutex_lock_nested+0x2e/0x36
[<f7f02534>] azx_pcm_open+0x37/0x1a7 [snd_hda_intel]
[<f7df6185>] snd_pcm_open_substream+0x46/0x97 [snd_pcm]
[<f7df627c>] snd_pcm_open+0xa6/0x182 [snd_pcm]
[<f7df63a4>] snd_pcm_playback_open+0x23/0x26 [snd_pcm]
[<f7da44db>] snd_open+0xd2/0x12f [snd]
[<c04a9244>] chrdev_open+0x124/0x13b
[<c04a55a0>] __dentry_open+0x168/0x267
[<c04a5739>] nameidata_to_filp+0x2c/0x43
[<c04af681>] do_filp_open+0x35f/0x67b
[<c04a5364>] do_sys_open+0x42/0xb7
[<c04a541b>] sys_open+0x1e/0x26
[<c0403b76>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #0 (&pcm->open_mutex){--..}:
[<c044fd84>] __lock_acquire+0x884/0xb22
[<c045007d>] lock_acquire+0x5b/0x81
[<c06e16f8>] __mutex_lock_common+0xd5/0x329
[<c06e19e4>] mutex_lock_nested+0x2e/0x36
[<f7df5b23>] snd_pcm_release+0x55/0x9e [snd_pcm]
[<c04a7b2a>] __fput+0xcf/0x15f
[<c04a7bd3>] fput+0x19/0x1b
[<c0492e81>] remove_vma+0x3c/0x5b
[<c0493c2d>] do_munmap+0x21c/0x237
[<c0493c78>] sys_munmap+0x30/0x3f
[<c0403b76>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
other info that might help us debug this:
1 lock held by pulseaudio/2686:
#0: (&mm->mmap_sem){----}, at: [<c0493c6b>] sys_munmap+0x23/0x3f
stack backtrace:
Pid: 2686, comm: pulseaudio Not tainted 2.6.29-0.25.rc0.git14.fc11.i686 #1
Call Trace:
[<c06e0513>] ? printk+0xf/0x14
[<c044f2e9>] print_circular_bug_tail+0x5d/0x68
[<c044fd84>] __lock_acquire+0x884/0xb22
[<c045007d>] lock_acquire+0x5b/0x81
[<f7df5b23>] ? snd_pcm_release+0x55/0x9e [snd_pcm]
[<c06e16f8>] __mutex_lock_common+0xd5/0x329
[<f7df5b23>] ? snd_pcm_release+0x55/0x9e [snd_pcm]
[<c044d7d7>] ? lock_release_holdtime+0x30/0x131
[<c049331b>] ? unlink_file_vma+0x73/0x79
[<c06e19e4>] mutex_lock_nested+0x2e/0x36
[<f7df5b23>] ? snd_pcm_release+0x55/0x9e [snd_pcm]
[<f7df5b23>] snd_pcm_release+0x55/0x9e [snd_pcm]
[<c04a7b2a>] __fput+0xcf/0x15f
[<c04a7bd3>] fput+0x19/0x1b
[<c0492e81>] remove_vma+0x3c/0x5b
[<c0493c2d>] do_munmap+0x21c/0x237
[<c0493c78>] sys_munmap+0x30/0x3f
[<c0403b76>] syscall_call+0x7/0xb
Seen another one, this on 2.6.29-0.53.rc2.git1.fc11.x86_64:
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-0.53.rc2.git1.fc11.x86_64 #1
-------------------------------------------------------
flurry/4259 is trying to acquire lock:
(&mm->mmap_sem){----}, at: [<ffffffff810ba071>] might_fault+0x5d/0xb1
but task is already holding lock:
(&dev->struct_mutex){--..}, at: [<ffffffffa03b7da1>] i915_gem_execbuffer+0x139/0xb2a [i915]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&dev->struct_mutex){--..}:
[<ffffffff8106e95d>] __lock_acquire+0xaab/0xc41
[<ffffffff8106eb80>] lock_acquire+0x8d/0xba
[<ffffffff813818aa>] __mutex_lock_common+0x107/0x39c
[<ffffffff81381be8>] mutex_lock_nested+0x35/0x3a
[<ffffffffa0387bf0>] drm_vm_open+0x31/0x46 [drm]
[<ffffffff8104860c>] dup_mm+0x2e6/0x3cc
[<ffffffff810492b0>] copy_process+0xb82/0x136d
[<ffffffff81049bfb>] do_fork+0x160/0x31f
[<ffffffff8100f62d>] sys_clone+0x23/0x25
[<ffffffff810117c3>] stub_clone+0x13/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
-> #1 (&mm->mmap_sem/1){--..}:
[<ffffffff8106e95d>] __lock_acquire+0xaab/0xc41
[<ffffffff8106eb80>] lock_acquire+0x8d/0xba
[<ffffffff8106234a>] down_write_nested+0x4b/0x7f
[<ffffffff810483f5>] dup_mm+0xcf/0x3cc
[<ffffffff810492b0>] copy_process+0xb82/0x136d
[<ffffffff81049bfb>] do_fork+0x160/0x31f
[<ffffffff8100f62d>] sys_clone+0x23/0x25
[<ffffffff810117c3>] stub_clone+0x13/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
-> #0 (&mm->mmap_sem){----}:
[<ffffffff8106e7fe>] __lock_acquire+0x94c/0xc41
[<ffffffff8106eb80>] lock_acquire+0x8d/0xba
[<ffffffff810ba09e>] might_fault+0x8a/0xb1
[<ffffffffa03b27f8>] i915_emit_box+0x2f/0x259 [i915]
[<ffffffffa03b83db>] i915_gem_execbuffer+0x773/0xb2a [i915]
[<ffffffffa0381e59>] drm_ioctl+0x1e6/0x271 [drm]
[<ffffffff810eab55>] vfs_ioctl+0x5f/0x78
[<ffffffff810eafd9>] do_vfs_ioctl+0x46b/0x4ab
[<ffffffff810eb06e>] sys_ioctl+0x55/0x77
[<ffffffff810112ba>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
other info that might help us debug this:
1 lock held by flurry/4259:
#0: (&dev->struct_mutex){--..}, at: [<ffffffffa03b7da1>] i915_gem_execbuffer+0x139/0xb2a [i915]
stack backtrace:
Pid: 4259, comm: flurry Not tainted 2.6.29-0.53.rc2.git1.fc11.x86_64 #1
Call Trace:
[<ffffffff8106dc01>] print_circular_bug_tail+0x71/0x7c
[<ffffffff8106e7fe>] __lock_acquire+0x94c/0xc41
[<ffffffff8106eb80>] lock_acquire+0x8d/0xba
[<ffffffff810ba071>] ? might_fault+0x5d/0xb1
[<ffffffff810ba09e>] might_fault+0x8a/0xb1
[<ffffffff810ba071>] ? might_fault+0x5d/0xb1
[<ffffffffa03b27f8>] i915_emit_box+0x2f/0x259 [i915]
[<ffffffffa03b83db>] i915_gem_execbuffer+0x773/0xb2a [i915]
[<ffffffffa0381e1f>] ? drm_ioctl+0x1ac/0x271 [drm]
[<ffffffffa0381e59>] drm_ioctl+0x1e6/0x271 [drm]
[<ffffffff8119a5cc>] ? _raw_spin_lock+0x68/0x116
[<ffffffffa03b7c68>] ? i915_gem_execbuffer+0x0/0xb2a [i915]
[<ffffffff810eab55>] vfs_ioctl+0x5f/0x78
[<ffffffff81383055>] ? _spin_unlock_irqrestore+0x47/0x57
[<ffffffff810eafd9>] do_vfs_ioctl+0x46b/0x4ab
[<ffffffff810eb06e>] sys_ioctl+0x55/0x77
[<ffffffff810112ba>] system_call_fastpath+0x16/0x1b
Still present in 2.6.29-0.64.rc3.fc11.x86_64. To clarify, the first trace I submitted was on a machine with a Radeon 9200 graphics chip; the one from Comment #3 is from a different machine with Intel X3100 graphics and can be provoked by running a GL app; Comment #2 appears to have a CLD in the sound driver. Are we all seeing the same bug here, or similar manifestations of separate bugs? I've not seen this in 2.6.29-0.20.rc3.git12.fc10.x86_64, anyone want to chime in or should I close this? same here as in #5 *** This bug has been marked as a duplicate of bug 481687 *** |
Created attachment 328034 [details] dmesg output Description of problem: Message "possible circular locking dependency detected" appeared during graphical boot with vga=791 cmdline option. See attached dmesg output for more. Version-Release number of selected component (if applicable): kernel-2.6.29-0.7.rc0.git3.fc11.i686 How reproducible: Always. Steps to Reproduce: 1. Boot with vga=791 rhgb cmdline options. Additional info: This is on ATi Mobility Radion 9200 hardware (M9+).