kvm-85 sometimes not starting on 2.6.30-rc5
Hi,
sometimes trying to start kvm on 2.6.30-rc5 (with kvm module v85, userspace v85) fails with:kvm_create_vm: Interrupted system call
Could not create KVM context
and following backtrace appears in dmesg:
[ 309.546138] BUG: MAX_LOCK_DEPTH too low! [ 309.549964] turning off the locking correctness validator. [ 309.549964] Pid: 2833, comm: qemu-kvm Not tainted 2.6.30lb.00_01_PRE08 #1 [ 309.549964] Call Trace: [ 309.549964] [<ffffffff80269aa9>] __lock_acquire+0x4a9/0xb70 [ 309.549964] [<ffffffff802c54ef>] ? mm_take_all_locks+0x2f/0x130 [ 309.549964] [<ffffffff8026b825>] lock_acquire+0xa5/0x150 [ 309.549964] [<ffffffff802c55ac>] ? mm_take_all_locks+0xec/0x130 [ 309.549964] [<ffffffff80505c96>] _spin_lock_nest_lock+0x36/0x50 [ 309.549964] [<ffffffff802c55ac>] ? mm_take_all_locks+0xec/0x130 [ 309.549964] [<ffffffff802c55ac>] mm_take_all_locks+0xec/0x130 [ 309.549964] [<ffffffff802d43ab>] do_mmu_notifier_register+0x7b/0x1d0 [ 309.549964] [<ffffffff802d451e>] mmu_notifier_register+0xe/0x10 [ 309.549964] [<ffffffffa02a8dd9>] kvm_dev_ioctl+0x189/0x2f0 [kvm] [ 309.549964] [<ffffffff802f0171>] vfs_ioctl+0x31/0x90 [ 309.549964] [<ffffffff802f03fb>] do_vfs_ioctl+0x22b/0x550 [ 309.549964] [<ffffffff802f07a2>] sys_ioctl+0x82/0xa0 [ 309.549964] [<ffffffff8020b442>] system_call_fastpath+0x16/0x1b
It happened to me when I didn't have storage with kernel mounted. Further attempts are usually successfull.
BR
nik
Signature · 14 lines
------------------------------------- Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax: +420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: [email protected] -------------------------------------
Andrea, looks like the mother of all locks below.
Quoted 32 lines · Nikola Ciprich
Hi,
sometimes trying to start kvm on 2.6.30-rc5 (with kvm module v85, userspace v85) fails with:kvm_create_vm: Interrupted system call
Could not create KVM contextand following backtrace appears in dmesg:
[ 309.546138] BUG: MAX_LOCK_DEPTH too low! [ 309.549964] turning off the locking correctness validator. [ 309.549964] Pid: 2833, comm: qemu-kvm Not tainted 2.6.30lb.00_01_PRE08 #1 [ 309.549964] Call Trace: [ 309.549964] [<ffffffff80269aa9>] __lock_acquire+0x4a9/0xb70 [ 309.549964] [<ffffffff802c54ef>] ? mm_take_all_locks+0x2f/0x130 [ 309.549964] [<ffffffff8026b825>] lock_acquire+0xa5/0x150 [ 309.549964] [<ffffffff802c55ac>] ? mm_take_all_locks+0xec/0x130 [ 309.549964] [<ffffffff80505c96>] _spin_lock_nest_lock+0x36/0x50 [ 309.549964] [<ffffffff802c55ac>] ? mm_take_all_locks+0xec/0x130 [ 309.549964] [<ffffffff802c55ac>] mm_take_all_locks+0xec/0x130 [ 309.549964] [<ffffffff802d43ab>] do_mmu_notifier_register+0x7b/0x1d0 [ 309.549964] [<ffffffff802d451e>] mmu_notifier_register+0xe/0x10 [ 309.549964] [<ffffffffa02a8dd9>] kvm_dev_ioctl+0x189/0x2f0 [kvm] [ 309.549964] [<ffffffff802f0171>] vfs_ioctl+0x31/0x90 [ 309.549964] [<ffffffff802f03fb>] do_vfs_ioctl+0x22b/0x550 [ 309.549964] [<ffffffff802f07a2>] sys_ioctl+0x82/0xa0 [ 309.549964] [<ffffffff8020b442>] system_call_fastpath+0x16/0x1bIt happened to me when I didn't have storage with kernel mounted. Further attempts are usually successfull.
BR
nik
Signature · 1 line
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Quoted 1 line · Avi Kivity
Andrea, looks like the mother of all locks below.
eheh yes that really is the mother of all locks ;).
So the thing is, like BUG says MAX_LOCK_DEPTH is too low, to fix you should rebuild after increasing it in include/linux/sched.h to say 96.
Likely somebody changed qemu-kvm over time in a way that allocates more vmas than before.
Quoted 5 lines · Andrea Arcangeli
Quoted 2 lines · Avi Kivity
Andrea, looks like the mother of all locks below.
Quoted 8 lines
eheh yes that really is the mother of all locks ;).
So the thing is, like BUG says
MAX_LOCK_DEPTHis too low, to fix you should rebuild after increasing it ininclude/linux/sched.hto say 96.Likely somebody changed qemu-kvm over time in a way that allocates more vmas than before.
It does, we now have a vma for each discontiguous memory region (640K, vga bios, bios, 1M+ memory, framebuffer, 4G+ memory).
Still, we have a lot more vmas in qemu for the various dynamic libraries, etc. I'm surprised it made such a difference.
Signature · 1 line
error compiling committee.c: too many arguments to function
Hi,
somehow this thread ended without any conclusion. Today I noticed that
BUG: MAX_LOCK_DEPTH too low!
still shows up when starting kvm on 2.6.31-rc8
So is increasing MAX_LOCK_DEPTH to say 96 good way to go? If yes, shouldn't we set this for upstream kernel? thanks
nik
Quoted 29 lines · Avi Kivity
Quoted 5 lines · Andrea Arcangeli
Quoted 2 lines · Avi Kivity
Andrea, looks like the mother of all locks below.
Quoted 8 lines
eheh yes that really is the mother of all locks ;).
So the thing is, like BUG says
MAX_LOCK_DEPTHis too low, to fix you should rebuild after increasing it ininclude/linux/sched.hto say 96.Likely somebody changed qemu-kvm over time in a way that allocates more vmas than before.
It does, we now have a vma for each discontiguous memory region (640K, vga bios, bios, 1M+ memory, framebuffer, 4G+ memory).
Still, we have a lot more vmas in qemu for the various dynamic libraries, etc. I'm surprised it made such a difference.
Signature · 6 lines
error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 13 lines
------------------------------------- Nikola CIPRICH LinuxBox.cz, s.r.o. 28. rijna 168, 709 01 Ostrava tel.: +420 596 603 142 fax: +420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: [email protected] -------------------------------------