Hello, On Monday 09 January 2012 12:41:41 Philipp Hahn wrote: > one of our VMs regularly get stuck: the VM is completely unresponsive (no > ssh, no serial console, no VNC). Using "gdbserver" and a remote system to > debug the running VM, I see 3 CPUs (1,3,4) stuck in > pgd_alloc() → spin_lock_irqsave(pgd_lock) > while the 4th CPU (2) is waiting in > pgd_alloc() → pgd_prepopulate_pmb() →... → flush_tlb_others_ipi() > > 195 while > (!cpumask_empty(to_cpumask(f->flush_cpumask))) 196 > cpu_relax(); > (gdb) print f->flush_cpumask > $5 = {1} > > CPU 1 is duing a do_exec() syscall, will CPU 2-4 are doing a do_fork() > syscall according to "thread apply all backtrace". > > After a "set variable f->flush_cpumask 0" from gdb the kernel continued > dumping the trace-informations, which I attached. I repeatet the test today with current version: > Host: Debian linux-2.6.32-38-amd64 (=2.6.32.42), 8 Cores 3.3.0 doesn't hep either. > Kvm: 0.14.1+dfsg qemu-kvm-1.0-1587-ga0bc8c3 also not. > Guest: Debian linux-2.6.32-38-i686-bigmem, 4 CPUs I can reproduce the bug very reliable when building OpenOffice.org and/or samba4 with -j4. > Is this a known bug and/or is a fix available? > I can gather more information from the VM if needd. Any ideas where to look next? How can I check that the IPI-handling in KVM works? Sincerely Philipp -- Philipp Hahn Open Source Software Engineer hahn@xxxxxxxxxxxxx Univention GmbH be open. fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.