Yinghai Lu | 1 Jul 2009 06:18
Picon

pci_stub and kvm

[ 1966.343286]
[ 1966.343288] =======================================================
[ 1966.356756] [ INFO: possible circular locking dependency detected ]
[ 1966.356759] 2.6.31-rc1-tip-00978-g99123e5-dirty #438
[ 1966.356761] -------------------------------------------------------
[ 1966.356764] events/0/387 is trying to acquire lock:
[ 1966.356766]  (&kvm->lock){+.+.+.}, at: [<ffffffff8100af27>]
kvm_assigned_dev_interrupt_work_handler+0x42/0x13a
[ 1966.356786]
[ 1966.356787] but task is already holding lock:
[ 1966.356789]  (&match->interrupt_work){+.+...}, at:
[<ffffffff810986e9>] worker_thread+0x175/0x2f6
[ 1966.356797]
[ 1966.356798] which lock already depends on the new lock.
[ 1966.356799]
[ 1966.356800]
[ 1966.356801] the existing dependency chain (in reverse order) is:
[ 1966.356803]
[ 1966.356803] -> #1 (&match->interrupt_work){+.+...}:
[ 1966.356809]        [<ffffffff810b3bf6>] __lock_acquire+0x1396/0x1710
[ 1966.356817]        [<ffffffff810b403c>] lock_acquire+0xcc/0x104
[ 1966.356821]        [<ffffffff810994a8>] __cancel_work_timer+0x121/0x247
[ 1966.356825]        [<ffffffff8109962c>] cancel_work_sync+0x23/0x39
[ 1966.356828]        [<ffffffff8100b280>] kvm_deassign_irq+0xf1/0x183
[ 1966.356832]        [<ffffffff8100db6c>] kvm_vm_ioctl+0x8c8/0xc1a
[ 1966.356837]        [<ffffffff81156e56>] vfs_ioctl+0x3e/0xa3
[ 1966.356846]        [<ffffffff8115741c>] do_vfs_ioctl+0x4be/0x511
[ 1966.356850]        [<ffffffff811574c5>] sys_ioctl+0x56/0x8d
[ 1966.356854]        [<ffffffff81034fdb>] system_call_fastpath+0x16/0x1b
[ 1966.356860]        [<ffffffffffffffff>] 0xffffffffffffffff
(Continue reading)

Avi Kivity | 1 Jul 2009 09:49
Picon
Favicon

Re: pci_stub and kvm

On 07/01/2009 07:18 AM, Yinghai Lu wrote:
> [ 1966.343286]
> [ 1966.343288] =======================================================
> [ 1966.356756] [ INFO: possible circular locking dependency detected ]
> [ 1966.356759] 2.6.31-rc1-tip-00978-g99123e5-dirty #438
> [ 1966.356761] -------------------------------------------------------
> [ 1966.356764] events/0/387 is trying to acquire lock:
> [ 1966.356766]  (&kvm->lock){+.+.+.}, at: [<ffffffff8100af27>]
> kvm_assigned_dev_interrupt_work_handler+0x42/0x13a
> [ 1966.356786]
> [ 1966.356787] but task is already holding lock:
> [ 1966.356789]  (&match->interrupt_work){+.+...}, at:
> [<ffffffff810986e9>] worker_thread+0x175/0x2f6
> [ 1966.356797]
> [ 1966.356798] which lock already depends on the new lock.
> [ 1966.356799]
> [ 1966.356800]
> [ 1966.356801] the existing dependency chain (in reverse order) is:
> [ 1966.356803]
> [ 1966.356803] ->  #1 (&match->interrupt_work){+.+...}:
> [ 1966.356809]        [<ffffffff810b3bf6>] __lock_acquire+0x1396/0x1710
> [ 1966.356817]        [<ffffffff810b403c>] lock_acquire+0xcc/0x104
> [ 1966.356821]        [<ffffffff810994a8>] __cancel_work_timer+0x121/0x247
> [ 1966.356825]        [<ffffffff8109962c>] cancel_work_sync+0x23/0x39
> [ 1966.356828]        [<ffffffff8100b280>] kvm_deassign_irq+0xf1/0x183
> [ 1966.356832]        [<ffffffff8100db6c>] kvm_vm_ioctl+0x8c8/0xc1a
> [ 1966.356837]        [<ffffffff81156e56>] vfs_ioctl+0x3e/0xa3
> [ 1966.356846]        [<ffffffff8115741c>] do_vfs_ioctl+0x4be/0x511
> [ 1966.356850]        [<ffffffff811574c5>] sys_ioctl+0x56/0x8d
> [ 1966.356854]        [<ffffffff81034fdb>] system_call_fastpath+0x16/0x1b
(Continue reading)

Yinghai Lu | 2 Jul 2009 01:58
Picon

Re: pci_stub and kvm

On Wed, Jul 1, 2009 at 12:49 AM, Avi Kivity<avi <at> redhat.com> wrote:
> On 07/01/2009 07:18 AM, Yinghai Lu wrote:
>>
>> [ 1966.343286]
>> [ 1966.343288] =======================================================
>> [ 1966.356756] [ INFO: possible circular locking dependency detected ]
>> [ 1966.356759] 2.6.31-rc1-tip-00978-g99123e5-dirty #438
>> [ 1966.356761] -------------------------------------------------------
>> [ 1966.356764] events/0/387 is trying to acquire lock:
>> [ 1966.356766]  (&kvm->lock){+.+.+.}, at: [<ffffffff8100af27>]
>> kvm_assigned_dev_interrupt_work_handler+0x42/0x13a
>> [ 1966.356786]
>> [ 1966.356787] but task is already holding lock:
>> [ 1966.356789]  (&match->interrupt_work){+.+...}, at:
>> [<ffffffff810986e9>] worker_thread+0x175/0x2f6
>> [ 1966.356797]
>> [ 1966.356798] which lock already depends on the new lock.
>> [ 1966.356799]
>> [ 1966.356800]
>> [ 1966.356801] the existing dependency chain (in reverse order) is:
>> [ 1966.356803]
>> [ 1966.356803] ->  #1 (&match->interrupt_work){+.+...}:
>> [ 1966.356809]        [<ffffffff810b3bf6>] __lock_acquire+0x1396/0x1710
>> [ 1966.356817]        [<ffffffff810b403c>] lock_acquire+0xcc/0x104
>> [ 1966.356821]        [<ffffffff810994a8>] __cancel_work_timer+0x121/0x247
>> [ 1966.356825]        [<ffffffff8109962c>] cancel_work_sync+0x23/0x39
>> [ 1966.356828]        [<ffffffff8100b280>] kvm_deassign_irq+0xf1/0x183
>> [ 1966.356832]        [<ffffffff8100db6c>] kvm_vm_ioctl+0x8c8/0xc1a
>> [ 1966.356837]        [<ffffffff81156e56>] vfs_ioctl+0x3e/0xa3
>> [ 1966.356846]        [<ffffffff8115741c>] do_vfs_ioctl+0x4be/0x511
(Continue reading)


Gmane