Guest freezes, seems related to networ activity

[Georg]

This might be related to bug #3676. I chose to create a new anyway. Hope that's OK. Feel free to merge/close.

After upgrading to 2.2.0-45846_Debian_lenny I can quite easily reproduce a complete lock up of the guest. The freeze seems to be related to heavy network usage, for example "aptitude safe-upgrade".

Host is fully updated Debian lenny/stable. Guest is Debian sid.

When the freeze happens there is no noticeable CPU-activity from VirtualBox. I attached gdb to the running process and got:

(gdb) where
#0  0xb7f92424 in __kernel_vsyscall ()
#1  0xb7f6a025 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/cmov/libpthread.so.0
#2  0xb7a89c2c in VBoxNsprPR_WaitCondVar () from /usr/lib/virtualbox/VBoxXPCOM.so
#3  0xb7a89cf9 in VBoxNsprPR_Wait () from /usr/lib/virtualbox/VBoxXPCOM.so
#4  0xb7a78e46 in VBoxNsplPL_WaitForEvent () from /usr/lib/virtualbox/VBoxXPCOM.so
#5  0xb7a7725f in ?? () from /usr/lib/virtualbox/VBoxXPCOM.so
#6  0xb7f821ff in ?? () from /usr/lib/virtualbox/VBoxHeadless.so
#7  0xb7f7f28c in TrustedMain () from /usr/lib/virtualbox/VBoxHeadless.so
#8  0x08048dde in ?? ()
#9  0xb7d28455 in __libc_start_main () from /lib/i686/cmov/libc.so.6
#10 0x08048d01 in ?? ()
(gdb) info threads
  20 Thread 0xb7c3bb90 (LWP 19179)  0xb7f92424 in __kernel_vsyscall ()
  19 Thread 0xb7984b90 (LWP 19180)  0xb7f92424 in __kernel_vsyscall ()
  18 Thread 0xb7779b90 (LWP 19181)  0xb7f92424 in __kernel_vsyscall ()
  17 Thread 0xb73b4b90 (LWP 19183)  0xb7f92424 in __kernel_vsyscall ()
  16 Thread 0xb7373b90 (LWP 19184)  0xb7f92424 in __kernel_vsyscall ()
  15 Thread 0xb751eb90 (LWP 19185)  0xb7f92424 in __kernel_vsyscall ()
  14 Thread 0xb7306b90 (LWP 19186)  0xb7f92424 in __kernel_vsyscall ()
  13 Thread 0xb6fffb90 (LWP 19187)  0xb7f92424 in __kernel_vsyscall ()
  12 Thread 0xb6e3fb90 (LWP 19188)  0xb7f92424 in __kernel_vsyscall ()
  11 Thread 0xb6db6b90 (LWP 19189)  0xb7f92424 in __kernel_vsyscall ()
  10 Thread 0xb57ffb90 (LWP 19190)  0xb7f92424 in __kernel_vsyscall ()
  9 Thread 0xb4cb4b90 (LWP 19191)  0xb7f92424 in __kernel_vsyscall ()
  8 Thread 0xb3b38b90 (LWP 19192)  0xb7f92424 in __kernel_vsyscall ()
  7 Thread 0xb3b17b90 (LWP 19193)  0xb7f92424 in __kernel_vsyscall ()
  6 Thread 0xb3ad6b90 (LWP 19194)  0xb7f92424 in __kernel_vsyscall ()
  5 Thread 0xb3a55b90 (LWP 19195)  0xb7f92424 in __kernel_vsyscall ()
  4 Thread 0xb3a24b90 (LWP 19196)  0xb7f92424 in __kernel_vsyscall ()
  3 Thread 0xb3943b90 (LWP 19197)  0xb7f92424 in __kernel_vsyscall ()
  2 Thread 0xb3922b90 (LWP 19198)  0xb7f92424 in __kernel_vsyscall ()
  1 Thread 0xb7cdd6c0 (LWP 19165)  0xb7f92424 in __kernel_vsyscall ()

It seems strange to me that every thread seems to be waiting in the same place but, I'm really no thread hacker so it might be OK.

I can supple a core file but it's rather huge...

Attaching VBox.log.

Please let me know if I can provide any more information!

[Georg]

VBox.log

[Georg]

VBox.log

[Georg]

Replying to Ralfredo:

Attaching VBox.log.

It seems that I somehow managed to attach the same log twice. Sorry. Feel free to remove one. I don't think I can.

[Frank Mehnert]

Ralfredo, please try to switch the virtual ethernet device from PCnet to E1000 for that VM and check if the problem persists. There is a potential problem with the PCnet device which will be fixed with the next release.

[Georg]

Replying to frank:

Ralfredo, please try to switch the virtual ethernet device from PCnet to E1000 for that VM and check if the problem persists.

WOW, that was fast response! Thanks!

I switched to "Intel PRO/1000 T Server" and the problems seems to be gone! It's obviously a little early to draw any conclusions about long time stability but something is definitely much butter. I have now used the NIC for at least 1000 times the data transfer than I could before.

Any chance a NIC switch could have any effect on #3735 or am I hoping for to much?

Once again thanks! If ever I got this kind of support when I pay for it...

[Frank Mehnert]

Thanks for the feedback. I will close this bug as duplicate of #3676.