inconsistent lock state. (kvm) - Kernel

This is a discussion on inconsistent lock state. (kvm) - Kernel ; I just triggered this with just modprobe kvm_intel ; rmmod kvm kvm_intel Dave ================================= [ INFO: inconsistent lock state ] 2.6.26.3-29.fc9.x86_64.debug #1 --------------------------------- inconsistent {hardirq-on-W} -> {in-hardirq-W} usage. Xorg/2680 [HC1[1]:SC0[0]:HE0:SE1] takes: (kvm_lock){+-..}, at: [ ] decache_vcpus_on_cpu+0x20/0xbd [kvm] {hardirq-on-W} state was ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: inconsistent lock state. (kvm)

  1. inconsistent lock state. (kvm)

    I just triggered this with just modprobe kvm_intel ; rmmod kvm kvm_intel

    Dave

    =================================
    [ INFO: inconsistent lock state ]
    2.6.26.3-29.fc9.x86_64.debug #1
    ---------------------------------
    inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
    Xorg/2680 [HC1[1]:SC0[0]:HE0:SE1] takes:
    (kvm_lock){+-..}, at: [] decache_vcpus_on_cpu+0x20/0xbd [kvm]
    {hardirq-on-W} state was registered at:
    [] __lock_acquire+0x62f/0xd89
    [] lock_acquire+0x96/0xc3
    [] _spin_lock+0x26/0x53
    [] mmu_shrink+0x26/0x116 [kvm]
    [] shrink_slab+0x70/0x158
    [] try_to_free_pages+0x25c/0x365
    [] __alloc_pages_internal+0x2ef/0x49c
    [] __alloc_pages_nodemask+0x9/0xb
    [] alloc_pages_current+0xb9/0xc2
    [] __get_free_pages+0xe/0x4d
    [] proc_pid_attr_write+0x65/0xe4
    [] vfs_write+0xae/0x157
    [] sys_write+0x47/0x6f
    [] system_call_after_swapgs+0x8a/0x8f
    [] 0xffffffffffffffff
    irq event stamp: 1251057442
    hardirqs last enabled at (1251057441): [] trace_hardirqs_on_thunk+0x35/0x3a
    hardirqs last disabled at (1251057442): [] trace_hardirqs_off_thunk+0x35/0x37
    softirqs last enabled at (1251057438): [] __do_softirq+0xf2/0x101
    softirqs last disabled at (1251057433): [] call_softirq+0x1c/0x28

    other info that might help us debug this:
    no locks held by Xorg/2680.

    stack backtrace:
    Pid: 2680, comm: Xorg Not tainted 2.6.26.3-29.fc9.x86_64.debug #1

    Call Trace:
    [] print_usage_bug+0x15e/0x16f
    [] mark_lock+0x126/0x463
    [] __lock_acquire+0x5b1/0xd89
    [] ? lock_release_holdtime+0x1e/0x109
    [] ? _spin_unlock_irq+0x2b/0x37
    [] lock_acquire+0x96/0xc3
    [] ? :kvm:decache_vcpus_on_cpu+0x20/0xbd
    [] _spin_lock+0x26/0x53
    [] ? :kvm:hardware_disable+0x0/0x2f
    [] :kvm:decache_vcpus_on_cpu+0x20/0xbd
    [] ? :kvm:hardware_disable+0x0/0x2f
    [] :kvm:hardware_disable+0x26/0x2f
    [] smp_call_function_interrupt+0x45/0x6e
    [] call_function_interrupt+0x77/0x80



    --
    http://www.codemonkey.org.uk
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: inconsistent lock state. (kvm)

    Dave Jones wrote:
    > I just triggered this with just modprobe kvm_intel ; rmmod kvm kvm_intel
    >
    > Dave
    >
    > =================================
    > [ INFO: inconsistent lock state ]
    > 2.6.26.3-29.fc9.x86_64.debug #1
    > ---------------------------------
    > inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
    > Xorg/2680 [HC1[1]:SC0[0]:HE0:SE1] takes:
    > (kvm_lock){+-..}, at: [] decache_vcpus_on_cpu+0x20/0xbd [kvm]
    >


    This is sort of known, which is why decache_vcpus_on_cpu no longer exists.


    --
    I have a truly marvellous patch that fixes the bug which this
    signature is too narrow to contain.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread