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.
