virtualbox 4.0 crashes - linux host - vboxnetflt => Fixed in SVN

[Mike]

Just upgraded to virtualbox 4.0 from 3.2.10. Tried to start my VM's and immediately got a kernel panic (attached)

Linux host, debian kernel 2.6.26-2-686

[Mike]

Kernel panic output

[Frank Mehnert]

Please could you attach your vboxnetflt.ko module to this ticket?

[Mike]

In order to get back to a working configuration, virtuablbox has to be downgraded and the driver recompiled, which destroys the file you asked for. Is there some specfic information you needed from this that I could supply instead? Im finding the later releases of virtualbox to be fail on this and another machine, while my home machine has no such troubles and everything seems fine. Slightly different hardware tho - the machines with trouble have intel e1000 nics.

[mgruys]

Panic occurs also here on Fedora 14.

uname -a: Linux 2.6.35.10-74.fc14.i686.PAE #1 SMP Thu Dec 23 16:10:47 UTC 2010 i686 i686 i386 GNU/Linux

[Eugene Paskevich]

Same for debian unstable: uname -a: Linux 2.6.32-5-686 #1 SMP Fri Dec 10 16:12:40 UTC 2010 i686 GNU/Linux. Disabling networking in the guest settings lets the guest boot. I'll try to capture the whole oops output and attach it with the .ko

[Eugene Paskevich]

Replying to previous message:

Same for debian unstable: uname -a: Linux 2.6.32-5-686 #1 SMP Fri Dec 10 16:12:40 UTC 2010 i686 GNU/Linux. Disabling networking in the guest settings lets the guest boot. I'll try to capture the whole oops output and attach it with the .ko

Unfortunately I failed to collect the full oops output. Guess there is no need for .ko then, but the last vbox related line in the call trace is vboxNetFltQdiscEnqueue for me too.

[mgruys]

I have indeed a e1000e networking adapter. I must also do some stuff to get this adapter work under my current kernel ​https://bugzilla.redhat.com/show_bug.cgi?id=649570#c62

[Aleksey Ilyushin]

Could you please paste the output of the following command?

tc qdisc

[mgruys]

qdisc pfifo_fast 0: dev eth0 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

[Eugene Paskevich]

As for me, this is:

qdisc tbf 1: dev eth0 root refcnt 2 rate 2970Kbit burst 5Kb lat 40.0ms 
qdisc prio 2: dev eth0 parent 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc sfq 8001: dev eth0 parent 2:1 limit 127p quantum 1514b perturb 30sec 
qdisc sfq 8002: dev eth0 parent 2:2 limit 127p quantum 1514b perturb 30sec 
qdisc sfq 8003: dev eth0 parent 2:3 limit 127p quantum 1514b perturb 30sec 
qdisc ingress ffff: dev eth0 parent ffff:fff1 ---------------- 
qdisc pfifo_fast 0: dev eth2 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev eth1 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Interface I'm trying to bridge VBox with is br0 which bridges eth1 and eth2.

[mgruys]

I'm still surprised a released version is not tested against such configurations.

[Aleksey Ilyushin]

Crazy_Hopper,

I've attached the patch that should solve the problem with bridging to devices with no TX queue. Please apply it in your vbox installation directory and rebuild the modules with:

sudo /etc/init.d/vboxdrv setup

[Eugene Paskevich]

Patch applied, will test as soon as I'm able to shut all the guests. In an hour, tops.

[Eugene Paskevich]

Everything seems to work as expected now, thank you Aleksey.

[Aleksey Ilyushin]

mgruys,

I'm uploading the patch that should prevent the kernel panic. It does not solve the problem though -- all outgoing traffic from the host will be dropped while VM is running. It also enables debug printouts that can help reveal the cause. Please apply the patch and rebuild the modules. The printouts will be logged to system log. Please attach the relevant part of the log to this ticket.

[mgruys]

I'm not a programmer. So I hope I can solve the problem howto apply the patch and (re)build the modules. But there's Google. I will supply you with the logs. I think the debug logs you mean are the VBlog.logs in the VirtualBox Log Viewer. It could take a while, so don't expect the answer soon. I will try.

[mgruys]

And by the way thanks for doing this ! I hope I can help

[mgruys]

It asks for the file to patch Flt-linux.c VBoxNetFlt-linux.debug.c Both files are not on my system (checked with locate). Where do I get these source files?

[Aleksey Ilyushin]

You need to change the current directory to the one where you installed VirtualBox. Also use -p0 option in patch:

patch -p0 -i <patch_file>

Rebuild the modules with:

sudo /etc/init.d/vboxdrv setup

[Aleksey Ilyushin]

If you installed VirtualBox-4.0-4.0.0_69151_fedora14-1.i686.rpm from our web site the directory should be /usr/share/virtualbox.

[mgruys]

I am in /usr/share/virtualbox This is indeed the folder I installed virtualbox. I have copied the patch of yours in this folder If I submit the patch command 'patch -p0 -i qdisc_debug.patch' it gives the following output:

[root@droef virtualbox]€ patch -p0 -i qdisc_debug.patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was:

---

src/vboxnetflt/linux/VBoxNetFlt-linux.c 2010-12-30 20:42:21.499906030 +0300

|+++ src/vboxnetflt/linux/VBoxNetFlt-linux.debug.c 2010-12-30 20:40:36.000219804 +0300

---

File to patch:

Both of this files VBoxNetFlt-linux.c and VBoxNetFlt-linux.debug.c are not on my system.

[Aleksey Ilyushin]

Right. My fault. Here is the updated patch. Btw to get the logs you'll need to look for them at /var/log. Look at the files with names system.log or kernel.log, I'm not sure about Fedora.

[Aleksey Ilyushin]

Updated debug patch

[mgruys]

great it works! just a moment....

[mgruys]

I started and shutdown successfully my Windows7 in VirtualBox :-) Without crash. Nice. Like you said no networking... I have supplied the log. In my /var/log the most recent changed log files are:

-rw-r--r--. 1 root root 2,4K dec 30 19:55 vbox-install.log -rw-r--r--. 1 root root 657K dec 30 19:58 messages -rw-rw-r--. 1 root utmp 711K dec 30 19:58 wtmp -rw-------. 1 root root 33K dec 30 19:58 secure

not any system or kernel. I give you my messages log file I see at the end some messages of vboxNetFltDequeu ...

Please let me know if this is the right one.

Good luck and thanks

[Aleksey Ilyushin]

Sorry for the trouble. I should have asked you in the very beginning if you bridged to br0 too. You can reverse the debug patch now with:

patch -p0 -R -i qdisc_debug.patch

Then download the updated qdisc_noqueue.patch attached to this ticket, apply it, rebuild the modules and the problem should be resolved.

[Aleksey Ilyushin]

Fix for kernel panic when bridging to device with no TX queue

[Aleksey Ilyushin]

mikevm,

Do you also use bridged networking with linux bridge device?

[mgruys]

After this patch all worked perfectly. Networking smooth ... very nice. I have included the messages. Maybe you want to see it.... Thanks for the hard work

[Eugene Paskevich]

Aleksey, is there anything I can help with in this ticket? Um, like testing more patches? :-)

[Mike]

Replying to aleksey:

mikevm,

Do you also use bridged networking with linux bridge device?

No I don't My network config is - two ethernets (eth0, eth1) are down, eth2 and eth3,

tc qdisc show qdisc pfifo_fast 0: dev eth2 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth3 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

I am not able to test the patch on this machine just yet but maybe later I will be able to.

[Aleksey Ilyushin]

Thank you guys for cooperation!

mikevm,

If the qdisc_noqueue.patch does not work for you, please, revert it, apply qdisc_debug.patch, rebuild the modules and attach the log (grep vbox will do). Thanks in advance!

[mgruys]

credits to you mr. aleksey. ​http://tinyurl.com/385l75u

[mar77i]

patch doesn't make things work on archlinux x86_64.
TX deque of my bridge0 device seems to stay empty.
Instead messages.log fills up with tons of this message (hex values stay constant, as well):

Jan  6 01:14:46 localhost kernel: vboxNetFltDequeue: Enter pThis=ffff880115b5a010 pChild=ffffffff8158d700

only removing the module brings my device back up...
wait a minute, I might just manage to modify the patch for my needs... bbl

[mar77i]

Replying to mar77i:

only removing the module brings my device back up...
wait a minute, I might just manage to modify the patch for my needs... bbl

dunno what's happened. Up and running now with the first patch only. sorry for the rubberducking.

[Frank Mehnert]

Fix contained in VBox 4.0.2.

[Mike]

Replying to frank:

Fix contained in VBox 4.0.2.

Confirmed as fixed, thanks!

[Aleksey Ilyushin]

Enable alternative egress packet filter.

[Aleksey Ilyushin]

Guys,

I've attached the patch for 4.0.2 that selects an alternative way to filter outgoing packets. Anyone brave enough to install 4.0.2 and apply the patch to see how well it works is very very welcome.

To apply the patch go to /usr/share/virtualbox/src/vboxhost/vboxnetflt/linux (you may need to change the path if you have installed VirtualBox at different location) and issue

sudo patch -p0 -i <path-to-netflt_start_xmit_enable.patch>

then rebuild the modules with

sudo /etc/init.d/vboxdrv setup

[rogeriov]

Replying to aleksey:

Guys,

I've attached the patch for 4.0.2 that selects an alternative way to filter outgoing packets. Anyone brave enough to install 4.0.2 and apply the patch to see how well it works is very very welcome.

To apply the patch go to /usr/share/virtualbox/src/vboxhost/vboxnetflt/linux (you may need to change the path if you have installed VirtualBox at different location) and issue

sudo patch -p0 -i <path-to-netflt_start_xmit_enable.patch>

then rebuild the modules with

sudo /etc/init.d/vboxdrv setup

I probably have the same issue but it is not solved neither in 4.0.2 nor with this patch.

I have set an environment that one VM should boot with network boot from the other VM using the host-only network. When I try to boot with PXE grub, the system completely locks out if Vt-x is enabled and locks only the VM if Vt-x is disabled. This patch made PXE Linux network boot work, but did nothing to PXE Grub.

I am also with Debian squeeze 32bit.

[Aleksey Ilyushin]

Replying to rogeriov:

I probably have the same issue but it is not solved neither in 4.0.2 nor with this patch.

I have set an environment that one VM should boot with network boot from the other VM using the host-only network. When I try to boot with PXE grub, the system completely locks out if Vt-x is enabled and locks only the VM if Vt-x is disabled. This patch made PXE Linux network boot work, but did nothing to PXE Grub.

I am also with Debian squeeze 32bit.

Please try to use internal network instead of host-only network. If your problem is related to vboxnetflt it should go away.