Re: [patch] VirtualBox-4.0.14 + FreeBSD/CURRENT + VIMAGE: crash on vm shutdown
On 19.03.2012 20:48, Mikolaj Golub wrote: Hi, Here is a patch that fixes the issue I have been observing recently: running on VIMAGE enabled kernel VirtualBox causes the kernel crash when vm is powered off: ng_unref_node(8b156880,0,1,101,0,...) at ng_unref_node+0x74 ng_snd_item(8d060d40,0,8b0e18f0,0,0,...) at ng_snd_item+0x2a5 ng_send_fn(8b156880,0,8b0e18f0,0,0,...) at ng_send_fn+0x35 ng_rmnode_self(8b156880,89f840e0,8b0dbcc0,deec88cc,8b0d9ffa,...) at ng_rmnode_self+0x4a vboxNetFltOsDeleteInstance(89f84010,89f84014,89f84010,deec88ec,8b0da0f4,...) at vboxNetFltOsDeleteInstance+0x63 vboxNetFltRelease(89f84010,0,0,0,89f84014,...) at vboxNetFltRelease+0x6a vboxNetFltPortDisconnectAndRelease(89f84014,2710,87748bd4,87748bd4,deec8930,...) at vboxNetFltPortDisconnectAndRelease+0x64 _end(8b15ed10,89f84210,877456b0,0,deec8990,...) at 0x8cffe057 SUPR0ObjRelease(8b15ed10,89f4b810,deec89c8,deec89a0,0,...) at SUPR0ObjRelease+0x133 _end(8b15eb90,898a0e10,877456b0,0,89f4b810,...) at 0x8cffe4bb supdrvCleanupSession(8162bac0,89f4b810,89f4b810,deec89f4,8160e52f,...) at supdrvCleanupSession+0xef supdrvCloseSession(8162bac0,89f4b810,8ceecb18,deec8a18,8ceecaa0,...) at supdrvCloseSession+0x19 VBoxDrvFreeBSDClose(89ee6c00,3,2000,8adcc5c0,8adcc5c0,...) at VBoxDrvFreeBSDClose+0x2f devfs_close(deec8a78,8ceecaa0,80400,80f8caac,133,...) at devfs_close+0x2ca VOP_CLOSE_APV(81095960,deec8a78,80f8caac,133,2,...) at VOP_CLOSE_APV+0xda vn_close(8ceecaa0,3,8b24b380,8adcc5c0,80f792e0,...) at vn_close+0x190 vn_closefile(89f8cd58,8adcc5c0,0,89f8cd58,0,...) at vn_closefile+0xe4 devfs_close_f(89f8cd58,8adcc5c0,0,0,89f8cd58,...) at devfs_close_f+0x35 _fdrop(89f8cd58,8adcc5c0,0,deec8b80,0,8adcc670,81273398,810a7620,89e50c2c,79d,80f7401d,deec8b90,80a2f81e,89e50c2c,8,80f7401d,79d,0,89f8cd58) at _fdrop+0x43 closef(89f8cd58,8adcc5c0,79d,79a,8adcc670,...) at closef+0x2b0 fdfree(8adcc5c0,0,80f74dc6,107,deec8c18,...) at fdfree+0x3ea exit1(8adcc5c0,0,deec8d1c,80db7aee,8adcc5c0,...) at exit1+0x57a sys_sys_exit(8adcc5c0,deec8cec,80fd0bf8,80f53607,8adbf5c0,...) at sys_sys_exit+0x1d syscall(deec8d28) at syscall+0x2de Xint0x80_syscall() at Xint0x80_syscall+0x21 Sorry for the late response and thanks for the patch. Is this patch still required for 4.1.8? My guess is yes but it would be great if you could confirm that with the latest port. Do you aggree that this patch is under MIT License so that I can push it upstream? -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Wed, 2 Mar 2011 15:09:21 -0600, Brandon Gooch wrote: On Wed, Mar 2, 2011 at 2:52 PM, Bernhard Froehlich de...@bluelife.at wrote: On Wed, 02 Mar 2011 21:31:45 +0100, Bernhard Froehlich wrote: On Wed, 2 Mar 2011 08:30:01 -0600, Brandon Gooch wrote: On Wed, Jan 26, 2011 at 5:19 PM, Bernhard Froehlich de...@freebsd.org wrote: On Wed, 26 Jan 2011 16:25:28 +0200, Mikolaj Golub wrote: On Wed, 26 Jan 2011 10:22:40 +0100 Bernhard Froehlich wrote: BF Sounds like it's my turn now. Which FreeBSD version is required to be BF able to use it? As Bjoern noted it is for __FreeBSD_version = 800500. BF Is VIMAGE enabled per default and what happens if VIMAGE is disabled - BF does it at least build fine with that patch? We have VIMAGE disabled by default. I have added to src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile: .if defined(VIMAGE) CFLAGS += -DVIMAGE .endif So to build the driver for VIMAGE enabled kernel one should run VIMAGE=1 make If VIMAGE variable is not defined the module for VIMAGE disabled kernel will be built. http://home.bluelife.at/patches/virtualbox-ose-kmod-devel-VIMAGE.diff I've integrated it a bit better into the VirtualBox build system, added the ports stuff and updated the patch for VirtualBox 4.0.2. It is currently unclear to me why you add VIMAGE to CFLAGS but nowhere check for VIMAGE in VBoxNetFlt-freebsd.c. Shouldn't we add a check for VIMAGE in the #if defined line or is this already done somewhere deep in the included headers? -- Bernhard Froehlich http://www.bluelife.at/ I managed to completely miss your patch posted this thread, so I just gave it a try on bluelife's virtualbox-ose-kmod svn r1239; it's working well. I've started each of my guests with bridged networking to be sure, and I see no panic (or any other anomaly) during boot or normal operation. Do you have plans on merging the patch soon? It's not committed because it doesn't work. What i have tested so far is with stock 8.2-REL so without VIMAGE. enabled VIMAGE option on stock 8.2-REL: bridging works fine disabled VIMAGE option on stock 8.2-REL: crashes vm with an assert Expression: !pPatchToGuestRec Location : /usr/home/decke/blueports/emulators/virtualbox-ose/work/VirtualBox-4.0.4_OSE/src/VBox/VMM/VMMR3/PATM.cpp(116 6) void patmr3AddP2GLookupRecord(VM*, _PATCHINFO*, uint8_t*, RTRCPTR, PATM_LOOKUP_TYPE, bool) It looks like that assert is not related to the VIMAGE patch. Works fine now since half an hour. Could someone with an VIMAGE kernel please test the patch? Just configure a VM with bridging and let it transfer a few bytes. Once with the option enabled and once disabled. I've had a machine running a linux guest for almost a day, bridging with a VIMAGE kernel, while capturing traffic on the virtual interface (and performing a few other tasks) -- so far, so good. No panics, and no anomalies. I surely don't know what the above mentioned assert is about; I haven't seen such a panic myself. Thanks to everyone involved! I have committed it now to our blueports repository and the patch will come together with the next major VirtualBox update to 4.0.x. http://svn.bluelife.at/index.cgi/blueports/revision/?rev=1264 It got also reviewed from upstream and it looks fine so far. Will hopefully be committed soon. -- Bernhard Fröhlich http://www.bluelife.at/ ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Wed, 2 Mar 2011 08:30:01 -0600, Brandon Gooch wrote: On Wed, Jan 26, 2011 at 5:19 PM, Bernhard Froehlich de...@freebsd.org wrote: On Wed, 26 Jan 2011 16:25:28 +0200, Mikolaj Golub wrote: On Wed, 26 Jan 2011 10:22:40 +0100 Bernhard Froehlich wrote: BF Sounds like it's my turn now. Which FreeBSD version is required to be BF able to use it? As Bjoern noted it is for __FreeBSD_version = 800500. BF Is VIMAGE enabled per default and what happens if VIMAGE is disabled - BF does it at least build fine with that patch? We have VIMAGE disabled by default. I have added to src/VBox/HostDrivers/VBoxNetFlt/freebsd/Makefile: .if defined(VIMAGE) CFLAGS += -DVIMAGE .endif So to build the driver for VIMAGE enabled kernel one should run VIMAGE=1 make If VIMAGE variable is not defined the module for VIMAGE disabled kernel will be built. http://home.bluelife.at/patches/virtualbox-ose-kmod-devel-VIMAGE.diff I've integrated it a bit better into the VirtualBox build system, added the ports stuff and updated the patch for VirtualBox 4.0.2. It is currently unclear to me why you add VIMAGE to CFLAGS but nowhere check for VIMAGE in VBoxNetFlt-freebsd.c. Shouldn't we add a check for VIMAGE in the #if defined line or is this already done somewhere deep in the included headers? -- Bernhard Froehlich http://www.bluelife.at/ I managed to completely miss your patch posted this thread, so I just gave it a try on bluelife's virtualbox-ose-kmod svn r1239; it's working well. I've started each of my guests with bridged networking to be sure, and I see no panic (or any other anomaly) during boot or normal operation. Do you have plans on merging the patch soon? It's not committed because it doesn't work. What i have tested so far is with stock 8.2-REL so without VIMAGE. enabled VIMAGE option on stock 8.2-REL: bridging works fine disabled VIMAGE option on stock 8.2-REL: crashes vm with an assert Expression: !pPatchToGuestRec Location : /usr/home/decke/blueports/emulators/virtualbox-ose/work/VirtualBox-4.0.4_OSE/src/VBox/VMM/VMMR3/PATM.cpp(116 6) void patmr3AddP2GLookupRecord(VM*, _PATCHINFO*, uint8_t*, RTRCPTR, PATM_LOOKUP_TYPE, bool) Could someone with an VIMAGE kernel please test the patch? Just configure a VM with bridging and let it transfer a few bytes. Once with the option enabled and once disabled. -- Bernhard Fröhlich http://www.bluelife.at/ ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: VirtualBox + VIMAGE
On Tue, 25 Jan 2011 18:13:43 -0800, Julian Elischer wrote: On 1/25/11 1:06 PM, Mikolaj Golub wrote: On Sun, 23 Jan 2011 23:44:41 -0800 Julian Elischer wrote: JE On 1/23/11 6:33 AM, Mikolaj Golub wrote: As a quick fix I added in VBoxNetFlt-freebsd.c in all problem functions CURVNET_SET_QUIET(vnet0) macro, which sets td-td_vnet to default vnet (see the attached patch). This has fixed the issue for me and now I am happily running both VNET jails and VirtualBox machines on my desktop. But the way I fixed the issue looks hackish for me. Could someone suggest a better solution? JE this is probably at east partially the correct solution. JE Usually you should also set the value back to its previous value when JE you leave that code as well. Thank you for the comments. Actually the patch contained CURVNET_RESTORE() too. I just did not mentioned it :-). So if it looks like right solution here is an improved version of the patch: vnet to switch is taken from thread's ucred (on interface initialization) or from ifp-if_vnet. yes I like it.. Now you just need a port person to patch the port :-) Sounds like it's my turn now. Which FreeBSD version is required to be able to use it? Is VIMAGE enabled per default and what happens if VIMAGE is disabled - does it at least build fine with that patch? For Mikolaj Golub to get this patch upstream we need that you either agree that his patch is under the MIT License or sign a Sun Contributors Agreement. Then we can submit that patch upstream or you can do it yourself if you prefer. Read here: http://www.virtualbox.org/wiki/Contributor_information -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org