Re: [patch] VirtualBox-4.0.14 + FreeBSD/CURRENT + VIMAGE: crash on vm shutdown

2012-03-30 Thread Bernhard Froehlich

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

2011-03-17 Thread Bernhard Froehlich
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

2011-03-02 Thread Bernhard Froehlich
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

2011-01-26 Thread Bernhard Froehlich
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