HEADS UP: initialization of kernel global variables (Fwd: svn commit: r185088)

[Marko Zec]

As a part of an effort to merge network stack virtualization 
infrastructure (also known as project virtnet / vimage) to head, 
initialization of global kernel variables which are scheduled to become 
virtualized should now adhere to a simple yet important new rule. 
Initialization of such variables should no longer be performed at 
instatiation point, but instead assignments of initial values should be 
done in initializer functions. This should have zero functional impact 
to existing code, but will allow us to switch between using global 
variables and their counterparts residing in virtualization containers 
with minimum code churn, and in the long run allow us to intialize 
multiple instances of such container structures.

Note that this change applies only to global variables related to the 
network stack, and only to the subset of those that have been selected 
for virtualization as in sys/net/vnet.h, sys/netinet/vinet.h, 
sys/netinet6/vinet6.h, sys/netipsec/vipsec.h etc. No other subsystems 
will be affected at this point in time. A MFC of this change to 
stable/7 or older branches is not planned.

Cheers,

Marko

--  Forwarded Message  --

Subject: svn commit: r185088 - in head/sys: dev/cxgb/ulp/tom net netinet 
netinet6 netipsec sys
Date: Wednesday 19 November 2008
From: Marko Zec <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED], 
[EMAIL PROTECTED]

Author: zec
Date: Wed Nov 19 09:39:34 2008
New Revision: 185088
URL: http://svn.freebsd.org/changeset/base/185088

Log:
  Change the initialization methodology for global variables scheduled
  for virtualization.
  
  Instead of initializing the affected global variables at instatiation,
  assign initial values to them in initializer functions.  As a rule,
  initialization at instatiation for such variables should never be
  introduced again from now on.  Furthermore, enclose all instantiations
  of such global variables in #ifdef VIMAGE_GLOBALS blocks.
  
  Essentialy, this change should have zero functional impact.  In the 
next
  phase of merging network stack virtualization infrastructure from
  p4/vimage branch, the new initialization methology will allow us to
  switch between using global variables and their counterparts residing 
in
  virtualization containers with minimum code churn, and in the long run
  allow us to intialize multiple instances of such container structures.
  
  Discussed at: devsummit Strassburg
  Reviewed by:  bz, julian
  Approved by:  julian (mentor)
  Obtained from://depot/projects/vimage-commit2/...
  X-MFC after:  never
  Sponsored by: NLnet Foundation, The FreeBSD Foundation

Modified:
  head/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c
  head/sys/net/if.c
  head/sys/net/if_ethersubr.c
  head/sys/net/if_gif.c
  head/sys/net/if_loop.c
  head/sys/net/raw_cb.c
  head/sys/net/route.c
  head/sys/netinet/if_ether.c
  head/sys/netinet/igmp.c
  head/sys/netinet/in.c
  head/sys/netinet/in_gif.c
  head/sys/netinet/in_mcast.c
  head/sys/netinet/in_pcb.c
  head/sys/netinet/in_pcb.h
  head/sys/netinet/in_proto.c
  head/sys/netinet/in_rmx.c
  head/sys/netinet/in_var.h
  head/sys/netinet/ip_divert.c
  head/sys/netinet/ip_fastfwd.c
  head/sys/netinet/ip_icmp.c
  head/sys/netinet/ip_icmp.h
  head/sys/netinet/ip_input.c
  head/sys/netinet/ip_output.c
  head/sys/netinet/raw_ip.c
  head/sys/netinet/tcp_hostcache.c
  head/sys/netinet/tcp_input.c
  head/sys/netinet/tcp_output.c
  head/sys/netinet/tcp_reass.c
  head/sys/netinet/tcp_sack.c
  head/sys/netinet/tcp_subr.c
  head/sys/netinet/tcp_syncache.c
  head/sys/netinet/tcp_timewait.c
  head/sys/netinet/tcp_var.h
  head/sys/netinet/udp_usrreq.c
  head/sys/netinet/vinet.h
  head/sys/netinet6/frag6.c
  head/sys/netinet6/icmp6.c
  head/sys/netinet6/in6_ifattach.c
  head/sys/netinet6/in6_proto.c
  head/sys/netinet6/in6_rmx.c
  head/sys/netinet6/in6_src.c
  head/sys/netinet6/ip6_forward.c
  head/sys/netinet6/ip6_input.c
  head/sys/netinet6/ip6_mroute.c
  head/sys/netinet6/mld6.c
  head/sys/netinet6/nd6.c
  head/sys/netinet6/nd6_nbr.c
  head/sys/netinet6/nd6_rtr.c
  head/sys/netinet6/raw_ip6.c
  head/sys/netinet6/scope6.c
  head/sys/netinet6/vinet6.h
  head/sys/netipsec/ipsec.c
  head/sys/netipsec/ipsec.h
  head/sys/netipsec/key.c
  head/sys/netipsec/keysock.c
  head/sys/netipsec/xform_ah.c
  head/sys/netipsec/xform_esp.c
  head/sys/netipsec/xform_ipcomp.c
  head/sys/netipsec/xform_ipip.c
  head/sys/sys/vimage.h

Modified: head/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c
==
--- head/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c Wed Nov 19 08:56:35 2008
(r185087)
+++ head/sys/dev/cxgb/ulp/tom/cxgb_cpl_io.c Wed Nov 19 09:39:34 2008
(r185088)
@@ -154,11 +154,6 @@ static unsigned int mbuf_wrs[TX_MAX_SEGS
 #define TCP_CLOSE  2
 #define TCP_DROP   3
 
-extern int tcp_do_autorcvbuf;
-extern int tcp_do_autosndbuf;
-extern int tcp_autorcvbuf_max;
-extern int tcp_autosndbuf_max;
-
 

Re: Howto setup virtualisation

[Marko Zec]

On Tuesday 09 December 2008 14:47:00 michael dürr wrote:
> Hallo list,
>
> I recently discovered the IMUNES toolkit and found me more than
> fascinated by its functionallity.
>
> Now I'd love to deploy the most recent version of vimage. I already
> came accross Marko's website (http://imunes.tel.fer.hr/virtnet/). As
> I don't want to use the VMware images, but install everything native,
> I set up a FreeBSD 7.0 system and tried to compile against the
> provided snapshots.
>
> As you can imagine, my build failed :-( . Although I'm not that
> familiar with FreeBSD, I tried hard to compile the snapshots (as well
> as the provided patch) against different tags... Without success.
>
> My question:
>
> Can you tell me a release/tag which I can download from the src tree
> which comliles and for which I can use the GUI tools? Or is there any
> other simple solution to get all this running?

Hi,

builing and running http://imunes.net/virtnet/vimage_7-20081015.tgz
on a 7.0-RELEASE or 7.1-PRERELEASE should be pretty straightforward: 
just unpack the vimage_7 src tree; cd src/sys/i386/conf; config VIMAGE; 
cd ../compile/VIMAGE; make depend; make; make install and you're done.
You'll also need to compile the vimage(8) utility -> cd 
src/usr.sbin/vimage; make; make install -> done.  You'll most probably 
want to upgrade your userland from 7.0-RELEASE to RELENG_7 or 
RELENG_7_1 in order for the utilities like sockstat and netstat to work 
properly - the simpler alternative would be doing the installation from 
a recent 7.x snapshot ISO...

For the GUI, the latest version can be fetched from anoncvs:

cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/src/cvsroot co 
imunes

cd imunes; ./install.sh -> done

Note that you need to have tk-8.4 installed for the GUI to work, and 
most probably you'll want quagga and or xorp as well (from ports).

Good luck,

Marko

___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: PERFORCE change 154309 for review (etc.)

[Marko Zec]

On Tuesday 09 December 2008 20:48:58 Julian Elischer wrote:
> Marko,
>
> I'm following along using p4 and the diff script. It looks good..

The code in vimage-commit2 passed through a make universe run, though a 
new panic just emerged in head related to kmacy's changes to routing 
tbale locking.  I feel somewhat reluctant to dump commit2 to svn while 
there's an unrelated but known panic that doesn't allow the system to 
boot, and furthermore bz and I wanted to double-check that all sysctls 
would still work exactly the same way before and after the change - a 
few days ago I noticed something strange but want to check it with the 
most recent head...

> If it all seems to be working we should commit what you have
> and then we should get Kris and Robert to try some of their
> benchmarks.. to confirm the numbers you saw earlier.

Yes it would be extremely usefull to have people doing unbiased tests of 
all kinds, though I think that the right time to commence testing would 
be in a week or two from now when we'll have all three different 
variable layout and referencing models in place in head, selectable as 
compile time option, as outlined at the bottom of bz's wiki page:

http://wiki.freebsd.org/Image/KernelOptions

Marko


> Kris, the change that is upcoming for the next vimage commit
> gathers the various networking globals in the system and
> aggregates them together into several functional structures.
>
> e.g. one for inet related vars and another for interface and basic
> networking infrastructure related vars.
>
> The thing we would like "independent" corroboration of is that
> the change to having these gathered together, and initialized by
> an explicit initialization routing does not give any significant
> performance difference for a representative set of networking
> tests.
>
> Kris and Robert, what tests would you suggest and is there a chance
> that we can get some "independent" testing done on this?


___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Problems starting routing software at virtual nodes

[Marko Zec]

On Monday 22 December 2008 09:53:58 michael dürr wrote:
> Hallo,
>
> I updated my FreeBSD RELEASE 7.0 to RELENG_7_1 and installed the
> VIMAGE capable kernel and the vimage(8) tool from the provided
> sources at http://imunes.net/virtnet/vimage_7-20081015.tgz
>
> I also installed tk-8.4, quagga and xorp from the ports repos.
>
> In order to deploy more complex networking setups I wanted to switch
> from static routing ripv2.
>
> Now my question: Are there certain settings I have to perform in
> order to get ripd working? So far, I always tried to start the daemon
> by executing
>
> vimage v1 zebra -d
> vimage v1 ripd -d
>
> but both commands immediately return and nothing else happens (no
> errors, no daemon processes started). In case I call these commands
> at the host
>
> zebra -d
> rip -d
>
> everything works as expected.
>
> I'm sorry for this question, but is it necessary to install a special
> configured version of the quagga routing software to get things
> working?

Hi Michael,

my wild guess is that you are attempting to run multiple instances of 
quagga (i.e. zebra, ripd etc.) and that they are clashing 
on /var/run/quagga/ PF_UNIX named sockets.  My suggestion would be to 
make a separate directory for each vimage in say /tmp, and then 
make /var/run/quagga a variant symlink to those dirs.  You can do the 
same for the Quagga.conf file for which the path is hardcoded in quagga 
as well:

ln -s /tmp/$vimage_name/@ /var/run/quagga
ln -s /tmp/$vimage_name/@/boot.conf /usr/local/etc/quagga/Quagga.conf

The @ sign will be substituted with the current vimage name when 
resolving the symlink.  And don't forget to issue "vtysh -b" after 
starting your daemons if you are using the unified Quagga.conf file.

Hope this helps,

Marko
___
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: Problems starting routing software at virtual nodes

[Marko Zec]

On Monday 22 December 2008 14:43:39 Marko Zec wrote:
> On Monday 22 December 2008 09:53:58 michael dürr wrote:
> > Hallo,
> >
> > I updated my FreeBSD RELEASE 7.0 to RELENG_7_1 and installed the
> > VIMAGE capable kernel and the vimage(8) tool from the provided
> > sources at http://imunes.net/virtnet/vimage_7-20081015.tgz
> >
> > I also installed tk-8.4, quagga and xorp from the ports repos.
> >
> > In order to deploy more complex networking setups I wanted to
> > switch from static routing ripv2.
> >
> > Now my question: Are there certain settings I have to perform in
> > order to get ripd working? So far, I always tried to start the
> > daemon by executing
> >
> > vimage v1 zebra -d
> > vimage v1 ripd -d
> >
> > but both commands immediately return and nothing else happens (no
> > errors, no daemon processes started). In case I call these commands
> > at the host
> >
> > zebra -d
> > rip -d
> >
> > everything works as expected.
> >
> > I'm sorry for this question, but is it necessary to install a
> > special configured version of the quagga routing software to get
> > things working?
>
> Hi Michael,
>
> my wild guess is that you are attempting to run multiple instances of
> quagga (i.e. zebra, ripd etc.) and that they are clashing
> on /var/run/quagga/ PF_UNIX named sockets.  My suggestion would be to
> make a separate directory for each vimage in say /tmp, and then
> make /var/run/quagga a variant symlink to those dirs.  You can do the
> same for the Quagga.conf file for which the path is hardcoded in
> quagga as well:
>
> ln -s /tmp/$vimage_name/@ /var/run/quagga
> ln -s /tmp/$vimage_name/@/boot.conf /usr/local/etc/quagga/Quagga.conf

Ooops... The above symlink hack wouldn't work, but the one bellow 
should:

ln -s /tmp/@ /var/run/quagga
ln -s /tmp/@/boot.conf /usr/local/etc/quagga/Quagga.conf

Good luck,

Marko

> The @ sign will be substituted with the current vimage name when
> resolving the symlink.  And don't forget to issue "vtysh -b" after
> starting your daemons if you are using the unified Quagga.conf file.
>
> Hope this helps,
>
> Marko
> ___
> 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"


___
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: Vimage next step

[Marko Zec]

On Friday 20 February 2009 00:26:21 Julian Elischer wrote:
> Julian Elischer wrote:
> > I've been doing performance testing on the 'non-vimage'
> > 'structified' case VS the original 'globals' case and have not been
> > able to see any really significant differences (though I have seen
> > very slight differences in the distribution of results).
> >
> > SO I think we are in the position of moving forward to the next
> > steps.
> >
> > I think that just means checking in the rest of the vimage tree
> > from what I have seen.
> >
> > Then  we can play with it a bit and then proceed to the
> > jail/vimage merge stuff that Jamie (and bz) are working on.
> >
> > One thing I'd like to do is make the following changes:
> >
> > 1/ evaluate the ordering of the items in the vimage structures to
> > see if there are items that should be clustered for cache reasons.
> >
> > 2/ remove all sub structures from the vimage structures
> > and replace them with pointers. This is because puting them in
> > directly in the vimage structures will make our lives harder due to
> > ABI issues. If they are independently allocated (*) then we don't
> > need to worry about them changing in size.
>
> for example, the ipsec struct starts with:
>
>  int _ipsec_debug;
>  struct  ipsecstat   _ipsec4stat;
>  struct  secpolicy   _ip4_def_policy;
>
>  int _ip4_esp_trans_deflev;
>  int _ip4_esp_net_deflev;
>
> This effectively fixes the size of the ipsecstat and secpolicy
> structures. I would like instead to have:
>  int _ipsec_debug;
>  struct  ipsecstat   *_ipsec4stat;
>  struct  secpolicy   *_ip4_def_policy;
>
>  int _ip4_esp_trans_deflev;
>  int _ip4_esp_net_deflev;
>
> and have the initializer function allocate those separately.
>
> > (*) actually they could still be allocated as a blob but we would
> > access them as if they are separate.
> >
> > comments?

I'm working on distilling the initializer functions from vimage to 
vimage-commit2 branch, and this will probably be a cause of enough 
controversy for itself, so that I'd propose to wait a few more days 
before engaging in other changes / optimizations.  With my pointy-hat 
for losing lots of time on, I still think that so far we have been more 
or less successfull in merging bits over to svn without causing major 
damage to other people, so perhaps it might sense to continue one step 
at the time.

Of course, I agree that reducing the impact of changes in random 
structures to the layout of vnet_* containers by using pointers instead 
of embedded structs would certainly be an improvement in ABI 
maintenance terms, but we shouldn't loose the performance perspective 
in mind, given that we've already introduced an additional level of 
indirection.

Ordering of items in vnet_ containers is definitely something that could 
and should be played with sooner than later, though I can't / won't 
promise to spend significant amount of time on that in the next few 
weeks :)

Marko
___
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: how to move physical interface into multiple vimage interfaces

[Marko Zec]

On Thursday 02 April 2009 18:43:57 subbsd wrote:
> Hello maillist
>
> i fetch and apply latest
> http://imunes.tel.fer.hr/virtnet/vimage-20081015.tgz patches for 7.2
> i386 for testing vimage.

Hi,

if you're running 7.2-PRERELASE or similar you'll probably have more 
luck trying out the latest sys tarball tracking 7-stable: 
http://imunes.tel.fer.hr/virtnet/vimage_7_20090401.tgz

> All according man page work done.
> Small bug: vimage -i with 1 arguments make core dumped:
>
> # vimage -i onearg
> Segmentation fault (core dumped)

You're right, this needs to be fixed...

> and bridge cannot worked:
> kldload if_bridge.ko
> link_elf: symbol ifnet undefined
> KLD if_bridge.ko: depends on bridgestp - not available

if_bridge is not virtualized yet, so as an alternative, I'd suggest you 
try out netgraph bridging which works quite well vith virtual stacks.  
There's a tutorial describing how to use netgraph with vimages - pls. 
take a look at this: 
http://imunes.tel.fer.hr/virtnet/eurobsdcon07_tutorial.pdf

> And i've want asking:
> may i using 1 physical or vlan interface as parent for multiple
> vimage interfaces? something like
> vimage -c sw1
> vimage -c sw2
> vimage -c sw3
>
> vimage -i sw1,sw2,sw3 em0

No it won't work that way - a single interface (physical, vlan, 
whatever) can be assigned to only one vimage at a time.  So to make 
multiple vimages visible via a single physical card you should create 
virtual interfaces for vimages and bridge them to the physical one.  
Here's an example:

tpx32# vimage -c sw1
tpx32# vimage -c sw2
tpx32# vimage -c sw3
tpx32# ngctl mkpeer eiface ether ether
tpx32# ngctl mkpeer eiface ether ether
tpx32# ngctl mkpeer eiface ether ether
tpx32# kldload ng_ether
tpx32# ngctl mkpeer em0: bridge lower link0
tpx32# ngctl name em0:lower b0
tpx32# ngctl connect em0: b0: upper link9
tpx32# ngctl connect ngeth0: b0: ether link1
tpx32# ngctl connect ngeth1: b0: ether link2
tpx32# ngctl connect ngeth2: b0: ether link3
tpx32# vimage -i sw1 ngeth0
e...@sw1
tpx32# vimage -i sw2 ngeth1
e...@sw2
tpx32# vimage -i sw3 ngeth2
e...@sw3
tpx32# 
tpx32# ifconfig
em0: flags=8843 metric 0 mtu 
1500
options=9b
ether 00:16:41:15:4d:3e
inet6 fe80::216:41ff:fe15:4d3e%em0 prefixlen 64 scopeid 0x3 
inet6 a:2::51 prefixlen 64 
inet 192.168.200.110 netmask 0xff00 broadcast 
192.168.200.255
media: Ethernet autoselect (100baseTX )
status: active
lo0: flags=8049 metric 0 mtu 16384
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
inet 127.0.0.1 netmask 0xff00 
tpx32# ping 192.168.200.1
PING 192.168.200.1 (192.168.200.1): 56 data bytes
64 bytes from 192.168.200.1: icmp_seq=0 ttl=255 time=4.668 ms
64 bytes from 192.168.200.1: icmp_seq=1 ttl=255 time=2.625 ms
^C
--- 192.168.200.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.625/3.647/4.668/1.022 ms
tpx32# ifconfig em0 promisc
tpx32# vimage sw1
Switched to vimage sw1
# ifconfig
lo0: flags=8008 metric 0 mtu 16384
eth0: flags=8802 metric 0 mtu 1500
ether 00:00:00:00:00:00
# ifconfig lo0 localhost
# ifconfig eth0 link 42:1:2:3:4:1
# dhclient eth0
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPNAK from 192.168.200.31
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPOFFER from 192.168.200.31
DHCPOFFER from 192.168.200.32
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.200.31
bound to 192.168.200.112 -- renewal in 1800 seconds.
# ifconfig
lo0: flags=8049 metric 0 mtu 16384
inet 127.0.0.1 netmask 0xff00 
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
eth0: flags=8843 metric 0 mtu 
1500
ether 42:01:02:03:04:01
inet6 fe80::d41d:8cd9:8f00:b204%eth0 prefixlen 64 scopeid 0x2 
inet 192.168.200.112 netmask 0xff00 broadcast 
192.168.200.255
# ping 192.168.200.1
PING 192.168.200.1 (192.168.200.1): 56 data bytes
64 bytes from 192.168.200.1: icmp_seq=0 ttl=255 time=4.833 ms
64 bytes from 192.168.200.1: icmp_seq=1 ttl=255 time=2.619 ms
64 bytes from 192.168.200.1: icmp_seq=2 ttl=255 time=2.544 ms
^C
--- 192.168.200.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.544/3.332/4.833/1.062 ms
# 
___
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: about vimage_7_20090401.tgz

[Marko Zec]

On Thursday 23 April 2009 06:52:45 Clarence Chu wrote:
> Hi All,
>
> Seems to me the vimage_7_20090401.tgz
> doesn't work, yet on FreeBSD-7.2-PRERELEASE/amd64
> as of Apr 22, 2009 for:
> a) IPFIREWALL
> b) device pf
> c) ZFS
> d) rpc.lockd

Basically three separate vimage-related efforts are underway, listed in order 
of priority:

1) merging vimage -> head
2) maintaining vimage branch (tracking head)
3) maintaining vimage_7 branch (tracking stable/7)

So you are mosltly right - in both vimage and vimage_7 branches many kernel 
susbsystems do not work (yet) with options VIMAGE enabled.  The current focus 
is on merging the base network stack infrastructure to head, and deal with 
those remaining subsystems later.

> about a year ago, vimage refused to work with PCCARD NICs,
> not to mention building a static kernel by:
> hints  "GENERIC.hints"
>
> How's your mileage? Does IMUNES require "most up-dated" version
> as a year ago?

IMUNES should work with both latest vimage and vimage_7 kernels from the 
imunes.net/virtnet page, though in general IMUNES mailing list would be a 
more appropriate place to discuss any IMUNES specific issues.

Cheers,

Marko
___
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: Kernel Compiled with options VIMAGE panics on boot

[Marko Zec]

On Sunday 10 May 2009 16:41:52 Sevan / Venture37 wrote:
> Hi
> I've installed a fresh copy of this months snapshot, updated src via
> cvsup, made a copy of the GENERIC config file, added 'options VIMAGE' &
> 'nooptions SCTP' & compiled & installed it, on boot the system panics
> with the error:
> panic: in /usr/src/sys/net/if.c:485 if_alloc()
>   vnet=0 curvnet=0
> cpuid = 0
>
> photo of panic:
> http://img18.imageshack.us/img18/3297/img1057e.jpg
>
> Any ideas??
>
> /usr/src/sys/net/if.c is v1.328 if that helps.

It seems that the USB code should set the curvnet context when attaching and 
detaching ifnets (rum0 in your case), which it currently does not.  I'll look 
into this in the next few days - thanks for the report!

Marko
___
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: PERFORCE change 161987 for review

[Marko Zec]

On Tuesday 12 May 2009 23:50:48 Julian Elischer wrote:
> Marko Zec wrote:
> > http://perforce.freebsd.org/chv.cgi?CH=161987
> >
> > Change 161987 by z...@zec_tpx32 on 2009/05/12 18:47:49
> >
> > Back out O(n**2) ad-hoc hack for searching for available
> > ifunits in cloning ifnets, and restore the standard O(n)
> > bitmapped searching / ifunit allocation method for both
> > default and options VIMAGE builds.
> >
> > HOWEVER, hereby we also introduce per-vnet if_clone driver
> > registration and ifunit allocation.  As a (necessary) example,
> > if_loop is modified to attach itself as an independent
> > cloner instance to each vnet.
> >
> > This approach has a neat byproduct: if_clone drivers that
> > do not explicitly declare themselves as multi-vnet, by
> > exporting an iattach() method and registering to the vnet
> > framework, continue to work with unmodified semantics in
> > the default vnet.  However, they will NOT be available
> > in other vnets.
>
> Ah I didn't read this right the first time..
> generally, good but...
>
> So we cannot have tun drivers in vimages?
>
> tun needs it's /dev  entres, so can not be 'renumbered' (in the
> base sense) until we somehow add vimage support to devfs.
> however having tun3 in one vimage and tun4 in another would still
> be pretty ok I think.

Hmm but how would such an approach help with say /dev/pf, which also has to be 
functional in all vnets?  Wouldn't it be useful if a single /dev entry could 
provide access to appropriate subsystem instances in different vnets, 
depending in which vnet the process which opens the special file operates?

I think this is how the virtualized pf did work, and there's anegdotal 
evidence that it did work well, at least until this got ripped off the vimage 
branch with the next pf import from OpenBSD :)

Marko


> So I think the modes wanted would be: 
>
> "Unvirtualised"appears in base vimage only
> "Scattered"one namespace, but in different vimages.
> "Virtualised"  separate namespaces.
>
> p.s excuse my unamerican way of spelling 'ised' (not ized)
> my fingers refuse to co-operate.
>
> > This brings us a step closer to being able to selectively
> > attach subsystems to particular vnets, instead of having
> > all subsystems unconditionally available to all vnets by
> > default.


___
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: Panic in netgraph with VIMAGE

[Marko Zec]

On Monday 25 May 2009 15:06:27 Milan Obuch wrote:
> Hi,
> there is some bug in (most probably) netgraph code. I did fresh csup and
> rebuild today. Whenever I try to turn bluetooth on (equivalent to plugging
> in the dongle), panic occurs:
>
> ubt0:  2.00/31.64, addr 2> on usbus3
> panic:
> in /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:634
> ng_make_node_common()
>  vnet=0 curvnet=0
> cpuid = 0
>
> This does not occur with kernel from sources three days old.

This is a known problem related to curvnet context not being set by the USB 
device attach code - I have to lurk / shop around for some cheap USB ethernet 
or bt devices to be able to reproduce & fix this locally, the alternative 
would be wild guessing and planting context setting macros at random places 
in the USB code, i.e. without testing, which I'm reluctant to do.

Marko


> Part from core.txt file:
>
> #0  doadump () at pcpu.h:246
> 246<--->pcpu.h: No such file or directory.
> <-->in pcpu.h
> (kgdb) #0  doadump () at pcpu.h:246
> #1  0xc0554e0e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420
> #2  0xc05550e2 in panic (fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:576
> #3  0xc0b947c1 in ng_make_node_common (type=0xc0b8f9a0, nodepp=0xc416b3a8)
> at
> /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:634 #4 
> 0xc0b8bcc4 in ubt_attach (dev=0xc4294280)
>
> at
> /usr/src/sys/modules/netgraph/bluetooth/ubt/../../../../dev/usb/bluetooth/n
>g_ubt.c:443 #5  0xc057dcbf in device_attach (dev=0xc4294280) at
> device_if.h:178 #6  0xc057e88e in device_probe_and_attach (dev=0xc4294280)
> at /usr/src/sys/kern/subr_bus.c:2473
> #7  0xc0b38240 in usb2_probe_and_attach_sub (udev=0xc41fd800,
> uaa=0xe4116c1c) at
> /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_device.c:1131 #8 
> 0xc0b3871a in usb2_probe_and_attach (udev=0xc41fd800, iface_index=255 'ÿ')
> at /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_device.c:1288 #9 
> 0xc0b40ff0 in uhub_explore (udev=0xc3f07000)
> at /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_hub.c:218
> #10 0xc0b31f29 in usb2_bus_explore (pm=0xc3ed0dd4)
>
> at
> /usr/src/sys/modules/usb/usb/../../../dev/usb/controller/usb_controller.c:2
>15 #11 0xc0b4343a in usb2_process (arg=0xc3ed0d74)
> at /usr/src/sys/modules/usb/usb/../../../dev/usb/usb_process.c:139
> #12 0xc0530008 in fork_exit (callout=0xc0b43360 ,.
> arg=0xc3ed0d74, frame=0xe4116d38) at /usr/src/sys/kern/kern_fork.c:830
> #13 0xc070b550 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:270
>
> At line 634 in ng_base.c, there is
>
> INIT_VNET_NETGRAPH(curvnet);
>
> I have options VIMAGE in my kernel config (actually this is first one
> succesfully compiled with mentioned option, but I did not try it too often,
> it just failed to compile before).
>
> Now I recompiled kernel again, this time without options VIMAGE in config,
> and panic does not occur.
>
> So the original problem is INIT_VNET_NETGRAPH implementation in presence of
> options VIMAGE in kernel config. If anyone has anything to test, please let
> me know.
>
> Regards,
> Milan
> ___
> 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"


___
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: Imunes and FreeBSD 8.0 RC2

[Marko Zec]

On Monday 09 November 2009 11:37:41 Huth, Hans-Peter wrote:
> > Hi,
> >
> > i have just installed FreeBSD 8.0 RC2 and wanted to play around
> > with imunes/vimage, but i couldn't find it in the installed version
> > (from DVD ISO). Did i just missed something, or what do i have to
> > install something in addition? If so, FTP URLS would be helpful as my
> > BSD machine is not in a network.
> >
> > Build a custom kernel with option VIMAGE. You can initialize a
>
> vimage-enabled
>
> >jail with:
> >
> >...
> >
> > The work on vnet is well done, and has been reliable through all of my
>
> load
>
> > testing.
>
> [in reply to remodeler]
>
> i have build the kernel now (from 8.0 RC2 DVD), but imunes and vimage
> are still not there.
> What is missing? Or am i stuck with Rel. 7 and patching? I want to play
> around with the
> Imunes network emulation features. Docu at
> http://imunes.tel.fer.hr/virtnet/ does not help either,
> directories under src are different.

Hi,

here's the procedure which should be sufficient to get IMUNES up and running 
on FreeBSD 8.0-RC3 (I've tested this on amd64, but i386 should work as well):

- Install 8.0-RC3, along with the full src tree and the following packages:
xorg-7.4_2
tk-8.4.19_2,2
quagga-0.99.15
xorp-1.6.tbz
wireshark-1.2.2
netperf-2.4.5

- Fetch a kernel patch required for IMUNES to work, and patch the kernel:
cd /tmp
fetch http://imunes.net/imunes-8.0-RC3.diff
cd /usr
patch < /tmp/imunes-8.0-RC3.diff

- Create a VIMAGE kernel config in /usr/src/sys/amd64/conf/VIMAGE:
include GENERIC
options VIMAGE
nooptions SCTP
options KDB
options DDB

- Build & install the VIMAGE kernel:
cd /sys/amd64/conf
config VIMAGE
cd ../compile/VIMAGE
make depend; make; make install

- Compile & install the vimage command:
cd /usr/src/tools/tools/vimage
make; make install

- Fetch & install the IMUNES GUI:
cvs -d :pserver:anonym...@cvs.imunes.net:/usr/local/src/cvsroot co \
imunes
cd imunes
./install.sh

Good luck,

Marko


___
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: IMUNES on FreeBSD 8.0-RELEASE...

[Marko Zec]

On Tuesday 05 January 2010 22:06:33 Michael Madigan wrote:
> Hello,
>
> Has anyone been successful in getting IMUNES to run on FreeBSD 8.0-RELEASE?
>  I have been trying and have had no luck.  I followed the directions from
> the following link exactly:
>
> http://www.mail-archive.com/freebsd-virtualization@freebsd.org/msg00156.htm
>l
>
> I have no problem starting up IMUNES or creating network topologies. 
> However, when I tried  to run a network topology, I would get the following
> error:

Hi Michael,

I'm not shure why and how, but you've triggered some experimental code in the 
IMUNES GUI which was not supposed to be in the tree for a while, possibly due 
to some environment variable you might have set.  Nevertheless, I've removed 
the offending code from the CVS - could you try refetching the GUI code from 
the anoncvs and let me know whether it fixes the issue for you?

Cheers,

Marko


>
> can't use empty string as operand of "&&"
> can't use empty string as operand of "&&"
> while executing
> "if { (![info exists mpid] || $mpid == "") && $ssh } {
>   set mpid [openFwrd [expr $rmPort + 10] $rmPort $usern...@$rhost]
> }"
> (procedure "remoteStart" line 33)
> invoked from within
> "remoteStart "
> (procedure "nexec" line 7)
> invoked from within
> "nexec id -u"
> (procedure "setOperMode" line 11)
> invoked from within
> "setOperMode exec"
> invoked from within
> ".#menubar.#menubar#experiment invoke active"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 [list $w invoke active]"
> (procedure "tk::MenuInvoke" line 50)
> invoked from within
> "tk::MenuInvoke .#menubar.#menubar#experiment 1"
> (command bound to event)
>
>
> After searching through some of the tcl files, I tried changing the
> following lines in exec.tcl under the remoteStart procedure from
>
>
> if { (![info exists mpid] || $mpid == "") && $ssh } {
> set mpid [openFwrd [expr $rmPort + 10] $rmPort $usern...@$rhost]
> }
> if { (![info exists epid] || $epid == "") && $ssh } {
> set epid [openFwrd [expr $rePort + 10] $rePort $usern...@$rhost]
> }
>
>
> to
>
>
> if { (![info exists mpid] || $mpid == "") && ($ssh != "") } {
> set mpid [openFwrd [expr $rmPort + 10] $rmPort $usern...@$rhost]
> }
> if { (![info exists epid] || $epid == "") && ($ssh != "") } {
> set epid [openFwrd [expr $rePort + 10] $rePort $usern...@$rhost]
> }
>
>
> I now get past the previous errors, but now I get the following error:
>
> "Cannot open sockets"
>
> I have never done any tcl programming, so I don't have a clue of where to
> start debugging a program like this.  Does anyone have any ideas on how to
> resolve this?  Maybe I'm missing something?  Any help would be greatly
> appreciated!! Thanks!!
>
> Regards,
> Mike___
> 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"


___
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: VIMAGE: Freed UMA keg was not empty

[Marko Zec]

On Wednesday 17 November 2010 06:57:53 Bjoern A. Zeeb wrote:
> On Wed, 17 Nov 2010, Thierry Herbelot wrote:
>
> Hi,
>
> first of all freebsd-virtualization@ is the better list for this; Cc:ed.
>
> > We are using FreeBSD + VIMAGE at work, and we have seen an annoying
> > problem : there seems to be a memory leak in the kernel, which eventually
> > causes a panic.
> >
> > (yes, we have seen the following message : "WARNING: VIMAGE (virtualized
> > network stack) is a highly experimental feature.")
> >
> > Configuring a network interface in a jail with vnet enabled, then
> > removing that jail causes these messages. In dmesg:
> >
> > [...]
> > Freed UMA keg was not empty (203 items).  Lost 1 pages of memory.
> > Freed UMA keg was not empty (36 items).  Lost 2 pages of memory.
> >
> > The issue happens in a GENERIC FreeBSD 8.1 kernel, with VIMAGE enabled
> > (with attached VIMAGE kernel config file).
> >
> > The following commands reproduce the bug:
> >
> > jail -l -u root -c path=/ name=foo persist vnet &&
> > jexec foo ifconfig lo0 127.0.0.1/8 &&
> > jail -r foo
> >
> > Running it too many times exhausts kernel memory and crashes the machine.
> >
> > The probleme is seen on 8.1-release kernel, 8-stable from SVN and SVN
> > -head.
>
> The problem has been present since day 1 and is still present up to
> HEAD.  This is about type stability and teardown.  So far we are no
> able to actually free TCP (and UDP in SVN) states as they might still
> be accesses after "free".  It's a general problem in the network stack
> and has been implemented as a measure to circumvent panics in those
> cases.

Actually, we never seriously discussed or revisited the issue with separate 
UMA pools for each vnet instance.

My original motivation when O introduced separate UMA pools was primarily in 
making it easier to spot resource leaks, and to prove the correctness of the 
whole VIMAGE / VNET thing.  Having more or less achieved those goals, perhaps 
the time has come to move on.  Having said that, and given that the current 
VIMAGE resource allocation model is far from being optimal (a lot of memory 
sits reserved but 99% unused, and cannot be reclaimed later on vnet 
teardown), perhaps it's time that we reconsider using unified UMA pools.

Note that the original VIMAGE prototype on FreeBSD 4.x from 2002 or 2003 used 
(mostly) unified memory zones, so there's no technical reason why this 
couldn't work again in FreeBSD current or 8-stable.

Cheers,

Marko


> I am not sure if that's actually what's biting you wrt to memory or
> if it's something else.  Unfortunately boot logs and kernel configs
> don't help much; enable ddb and get show uma and show malloc reports
> after the crash (or watch vmstat -z and vmstat -m) after every 50 jail
> restarts.  I might have some patches for a couple of things but cannot
> (yet) help with the additional (duplicate) UMA zones showing up at
> each iteration (for the -z case).
>
> /bz
___
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: if_bridge VIMAGE patch

[Marko Zec]

On Thursday 13 January 2011 13:42:30 Nikos Vassiliadis wrote:
> Hi,
>
> Please, review the attached patch. It is against yesterday's HEAD
> and it virtualizes if_bridge.
>
> You can use the bridgetest script to create quickly a topology
> with redundant links to test STP.

Looks good to me, though I'm wondering is there any particular reason why you 
prefer to create bridge instances in the "root" vnet first, and then move 
them to other vnets, instead of creating bridge instances directly in target 
vnets?

In other words:

ifconfig bridge1 create
ifconfig bridge1 vnet x

vs

jexec x ifconfig bridge1 create

In a near future, each vnet will have its own list of cloning ifnets 
(currently only lo and vlan cloners are per-vnet, while other cloning ifnet 
types use global cloners), so maybe it might be a good practice to attempt to 
avoid having ifnet with its cloner attached in one vnet while being loaned to 
another (though in some cases this is unavoidable, such as with epair 
ifnets).

Cheers,

Marko
___
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: vnet: acessing module's virtualized global variables from another module

[Marko Zec]

On Monday 09 May 2011 14:48:25 Mikolaj Golub wrote:
> Hi,
>
> Trying ipfw_nat under VIMAGE kernel I got this panic on the module load:

Hi,

I think the problem here is that curvnet context is not set properly on entry 
to ipfw_nat_modevent().  The canonical way to initialize VNET-enabled 
subsystems is to trigger them using VNET_SYSINIT() macros (instead of using 
modevent mechanisms), which in turn ensure that:

a) that the initializer function gets invoked for each existing vnet
b) curvnet context is set properly on entry to initializer functions and

Cheers,

Marko


> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address   = 0x4
> fault code  = supervisor read, page not present
> instruction pointer = 0x20:0xc09f098e
> stack pointer   = 0x28:0xf563b944
> frame pointer   = 0x28:0xf563b998
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 4264 (kldload)
>
> witness_checkorder(c6d5e91c,9,ca0ac2e3,223,0,...) at
> witness_checkorder+0x6e _rw_wlock(c6d5e91c,ca0ac2e3,223,0,c0e8f795,...) at
> _rw_wlock+0x82
> ipfw_nat_modevent(c98a48c0,0,0,75,0,...) at ipfw_nat_modevent+0x41
> module_register_init(ca0ad508,0,c0e8d834,e6,0,...) at
> module_register_init+0xa7
> linker_load_module(0,f563bc18,c0e8d834,3fc,f563bc28,...) at
> linker_load_module+0xa05
> kern_kldload(c86835c0,c72d3400,f563bc40,0,c8d0d000,...) at
> kern_kldload+0x133 kldload(c86835c0,f563bcec,c09e8940,c86835c0,0,...) at
> kldload+0x74 syscallenter(c86835c0,f563bce4,c0ce05dd,c1022150,0,...) at
> syscallenter+0x263 syscall(f563bd28) at syscall+0x34
> Xint0x80_syscall() at Xint0x80_syscall+0x21
> --- syscall (304, FreeBSD ELF32, kldload), eip = 0x280da00b, esp =
> 0xbfbfe79c, ebp = 0xbfbfec88 -
>
> It crashed on acessing data from virtualized global variable V_layer3_chain
> in ipfw_nat_modevent(). V_layer3_chain is defined in ipfw module and it
> turns out that &V_layer3_chain returns wrong location from anywhere but
> ipfw.ko.
>
> May be this is a known issue, but I have not found info about this, so
> below are details of investigation why this happens.
>
> Virtualized global variables are defined using the VNET_DEFINE() macro,
> which places them in the 'set_vnet' linker set (in the base kernel or in
> module). This is used to
>
> 1) copy these "default" values to each virtual network stack instance when
> created;
>
> 2) act as unique global names by which the variable can be referred to. The
> location of a per-virtual instance variable is calculated at run-time like
> in the example below for layer3_chain variable in the default vnet (vnet0):
>
> vnet0->vnet_data_base + (uintptr_t) & vnet_entry_layer3_chain (1)
>
> For modules the thing is more complicated. When a module is loaded its
> global variables from 'set_vnet' linker set are copied to the kernel
> 'set_vnet', and for module to be able to access them the linker reallocates
> all references accordingly (kern/link_elf.c:elf_relocaddr()):
>
>   if (x >= ef->vnet_start && x < ef->vnet_stop)
>   return ((x - ef->vnet_start) + ef->vnet_base);
>
> So from inside the module the access to its virtualized variables works,
> but from the outside we get wrong location using calculation like above
> (1), because &vnet_entry_layer3_chain returns address of the variable in
> the module's 'set_vnet'.
>
> The workaround is to compile such modules into the kernel or use a hack I
> have done for ipfw_nat -- add the function to ipfw module which returns the
> location of virtualized layer3_chain variable and use this location instead
> of V_layer3_chain macro (see the attached patch).
>
> But I suppose the problem is not a new and there might be better approach
> already invented to deal with this?


___
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: vnet: acessing module's virtualized global variables from another module

[Marko Zec]

On Monday 09 May 2011 19:05:28 Mikolaj Golub wrote:
> On Mon, 9 May 2011 16:21:15 +0200 Marko Zec wrote:
>
>  MZ> On Monday 09 May 2011 14:48:25 Mikolaj Golub wrote:
>  >> Hi,
>  >>
>  >> Trying ipfw_nat under VIMAGE kernel I got this panic on the module
>  >> load:
>
>  MZ> Hi,
>
>  MZ> I think the problem here is that curvnet context is not set properly
> on entry MZ> to ipfw_nat_modevent().  The canonical way to initialize
> VNET-enabled MZ> subsystems is to trigger them using VNET_SYSINIT() macros
> (instead of using MZ> modevent mechanisms), which in turn ensure that:
>
>  MZ> a) that the initializer function gets invoked for each existing vnet
>  MZ> b) curvnet context is set properly on entry to initializer functions
> and
>
> hm, sorry, but I don't see how curvnet context might help here.

You're getting a panic in a function, i.e. in ipfw_nat_modevent() which has 
ipfw_nat_init() inlined into it, where you attempt to access per-vnet data 
without having curvnet context set.  By definition that is not supposed to 
work on a VIMAGE kernel, so what you observe is not unexpected at all.  
Please set the curvnet context using VNET_SYSINIT() macros, or by hand using 
CURVNET_SET() / CURVNET_RESTORE(), before accesing any V_ data.

Marko


> For me this 
> does not look like curvnet context problem or my understanding how it works
> completely wrong.
>
> Below is kgdb session on live VIMAGE system with ipfw.ko loaded.
>
> Let's look at some kernel virtualized variable:
>
> (kgdb) p vnet_entry_ifnet
> $1 = {tqh_first = 0x0, tqh_last = 0x0}
> (kgdb) p &vnet_entry_ifnet
> $2 = (struct ifnethead *) 0x8102d488
>
> As expected the address is in kernel 'set_vnet':
>
> kopusha:/usr/src/sys% kldstat |grep kernel
>  1   69 0x8040 1092700  kernel
> kopusha:/usr/src/sys% nm /boot/kernel/kernel |grep  __start_set_vnet
> 8102d480 A __start_set_vnet
>
> default vnet:
>
> (kgdb) p vnet0
> $3 = (struct vnet *) 0x86d9b000
>
> Calculate ifnet location on vnet0 (a la VNET_VNET(vnet0, ifnet)):
>
> (kgdb) printf "0x%x\n", vnet0->vnet_data_base + (uintptr_t) &
> vnet_entry_ifnet 0x86d9c008
>
> Access it:
>
> (kgdb) p *((struct ifnethead *)0x86d9c008)
> $4 = {tqh_first = 0x86da5c00, tqh_last = 0x89489c0c}
> (kgdb) p (*((struct ifnethead *)0x86d9c008)).tqh_first->if_dname
> $7 = 0x80e8b480 "usbus"
> (kgdb) p (*((struct ifnethead *)0x86d9c008)).tqh_first->if_vnet
> $8 = (struct vnet *) 0x86d9b000
>
> Everything looks good. Now try the same with virtualized variable
> layer3_chain from ipfw module:
>
> (kgdb) p vnet_entry_layer3_chain
> $9 = {rules = 0x0, reap = 0x0, default_rule = 0x0, n_rules = 0, static_len
> = 0, map = 0x0, nat = {lh_first = 0x0}, tables = {0x0 },
> rwmtx = {lock_object = { lo_name = 0x0, lo_flags = 0, lo_data = 0,
> lo_witness = 0x0}, rw_lock = 0}, uh_lock = { lock_object = {lo_name = 0x0,
> lo_flags = 0, lo_data = 0, lo_witness = 0x0}, rw_lock = 0}, id = 0, gencnt
> = 0}
>
> "master" variable looks good (initialized to zeros), what about its
> address?
>
> (kgdb) p &vnet_entry_layer3_chain
> $10 = (struct ip_fw_chain *) 0x894a5c00
>
> It points to 'set_vnet' of the ipfw.ko:
>
> kopusha# kldstat |grep ipfw.ko
> 132 0x89495000 11000ipfw.ko
> kopusha:/usr/src/sys% nm /boot/kernel/ipfw.ko |grep  __start_set_vnet
> 00010be0 A __start_set_vnet
> kopusha:/usr/src/sys% printf "0x%x\n" $((0x89495000 + 0x00010be0))
> 0x894a5be0
>
> Calculate layer3_chain location on vnet0 (a la VNET_VNET(vnet0,
> layer3_chain)):
>
> (kgdb) printf "0x%x\n", vnet0->vnet_data_base + (uintptr_t) &
> vnet_entry_layer3_chain 0x8f214780
>
> Try to read it:
>
> (kgdb) p ((struct ip_fw_chain *)0x8f214780)->rwmtx
> $13 = {lock_object = {lo_name = 0x0, lo_flags = 0, lo_data = 0, lo_witness
> = 0x0}, rw_lock = 0} (kgdb) p ((struct ip_fw_chain *)0x8f214780)->rules
> $14 = (struct ip_fw *) 0x6
>
> Data looks wrong. But this is the way how this variable is acessed by
> ipfw_nat. I see the same in the crash image:
>
> (kgdb) where
> ...
> #11 0xc09a4882 in _rw_wlock (rw=0xc6d5e91c,
> file=0xca0ac2e3
> "/usr/src/sys/modules/ipfw_nat/../../netinet/ipfw/ip_fw_nat.c", line=547)
> at /usr/src/sys/kern/kern_rwlock.c:238
> #12 0xca0ab841 in ipfw_nat_modevent (mod=0xc98a48c0, type=0, unused=0x0)
> at /usr/src/sys/modules/ipfw_nat/../../netinet/ipfw/ip_fw_nat.c:547
>
> note, rw=0xc6d5e91c (it crashed on it). And I get the same address doing
> like I did above:
>
> (kgdb) VNET_VNET vnet0 vnet_entry_layer3_chain
> at 0xc6d5

Re: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Monday 05 March 2012 22:14:45 Monthadar Al Jaberi wrote:
> Hi,
>
> I am a very happy VIMAGE user. But lately I have been having problems
> using it, and its too complicated for me to dig in so I hope you can
> help me (and help Adrian too).
>
> I am using FreeBSD Current with a kernel config without wlan module
> and wireless devices  attach kernel config.
>
> uname -a shows:
> FreeBSD acke 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Mon Mar  5 20:02:38
> CET 2012 root@acke:/usr/obj/usr/src/sys/VNET_without_wlan  amd64
>
> I run the following commands:
> cd /usr/sys/module/wlan
> make load
> cd /usr/sys/modules/wtap
> make load
>
> then:
> /usr/src/ools/tools/wtap/wtap/wtap c 0
> ifconfig wlan create wlandev wtap0 wlanmode mesh
> wlandebug -i wlan0 hwmp+mesh+output+input+inact
> ifconfig wlan0 meshid mymesh
> ifconfig wlan0 inet 192.168.2.1
>
> and freebsd panics with:
> Mon Mar  5 21:17:46 CET 2012
> Mar  5 21:59:23 acke login: ROOT LOGIN (root) ON ttyv0
> Using visibility wtap plugin...
> Loaded wtap wireless simulator
> wtap0: ieee80211_radiotap_attach: no tx channel, radiotap 0x0wtap0:
> ieee80211_radiotap_attach: no rx channel, radiotap 0x0wlan0: Ethernet
> address: 00:98:9a:98:96:97
> wlan0: ieee80211_start: ignore queue, in SCAN state
> wlan0: [00:98:9a:98:96:97] ieee80211_alloc_node: inact_reload 2
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex wtap0_com_lock (wtap0_com_lock) r = 0
> (0xff8002395018) locked @
> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1937
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> kdb_backtrace() at kdb_backtrace+0x37
> _witness_debugger() at _witness_debugger+0x2c
> witness_warn() at witness_warn+0x2c4
> trap() at trap+0x2fe
> calltrap() at calltrap+0x8
> --- trap 0xc, rip = 0x80885d0c, rsp = 0xff80003e9a00, rbp
> = 0xff80003e9a20 ---
> rt_dispatch() at rt_dispatch+0x2c
> rt_ieee80211msg() at rt_ieee80211msg+0x7f
> scan_task() at scan_task+0x4cd
> taskqueue_run_locked() at taskqueue_run_locked+0x93
> taskqueue_thread_loop() at taskqueue_thread_loop+0x3e

It may be that scan_task() calls further down into the network stack without 
setting curvnet first.

Marko


> fork_exit() at fork_exit+0x135
> fork_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xff80003e9cf0, rbp = 0 ---
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x28
> fault code= supervisor read data, page not present
> instruction pointer   = 0x20:0x80885d0c
> stack pointer = 0x28:0xff80003e9a00
> frame pointer = 0x28:0xff80003e9a20
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 0 (wtap0 net80211 task)
>
> I am attaching dump file too.
>
> The weird thing is that I don't get this panic if I include wlan in
> kernel config while everything else is the same.
>
> Thank you for any help!


___
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: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 10:53:18 Monthadar Al Jaberi wrote:
> On Tue, Mar 6, 2012 at 12:52 AM, Marko Zec  wrote:
> > On Monday 05 March 2012 22:14:45 Monthadar Al Jaberi wrote:
> >> Hi,
> >>
> >> I am a very happy VIMAGE user. But lately I have been having problems
> >> using it, and its too complicated for me to dig in so I hope you can
> >> help me (and help Adrian too).
> >>
> >> I am using FreeBSD Current with a kernel config without wlan module
> >> and wireless devices  attach kernel config.
> >>
> >> uname -a shows:
> >> FreeBSD acke 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Mon Mar  5 20:02:38
> >> CET 2012     root@acke:/usr/obj/usr/src/sys/VNET_without_wlan  amd64
> >>
> >> I run the following commands:
> >> cd /usr/sys/module/wlan
> >> make load
> >> cd /usr/sys/modules/wtap
> >> make load
> >>
> >> then:
> >> /usr/src/ools/tools/wtap/wtap/wtap c 0
> >> ifconfig wlan create wlandev wtap0 wlanmode mesh
> >> wlandebug -i wlan0 hwmp+mesh+output+input+inact
> >> ifconfig wlan0 meshid mymesh
> >> ifconfig wlan0 inet 192.168.2.1
> >>
> >> and freebsd panics with:
> >> Mon Mar  5 21:17:46 CET 2012
> >> Mar  5 21:59:23 acke login: ROOT LOGIN (root) ON ttyv0
> >> Using visibility wtap plugin...
> >> Loaded wtap wireless simulator
> >> wtap0: ieee80211_radiotap_attach: no tx channel, radiotap 0x0wtap0:
> >> ieee80211_radiotap_attach: no rx channel, radiotap 0x0wlan0: Ethernet
> >> address: 00:98:9a:98:96:97
> >> wlan0: ieee80211_start: ignore queue, in SCAN state
> >> wlan0: [00:98:9a:98:96:97] ieee80211_alloc_node: inact_reload 2
> >> Kernel page fault with the following non-sleepable locks held:
> >> exclusive sleep mutex wtap0_com_lock (wtap0_com_lock) r = 0
> >> (0xff8002395018) locked @
> >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1937
> >> KDB: stack backtrace:
> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> >> kdb_backtrace() at kdb_backtrace+0x37
> >> _witness_debugger() at _witness_debugger+0x2c
> >> witness_warn() at witness_warn+0x2c4
> >> trap() at trap+0x2fe
> >> calltrap() at calltrap+0x8
> >> --- trap 0xc, rip = 0x80885d0c, rsp = 0xff80003e9a00, rbp
> >> = 0xff80003e9a20 ---
> >> rt_dispatch() at rt_dispatch+0x2c
> >> rt_ieee80211msg() at rt_ieee80211msg+0x7f
> >> scan_task() at scan_task+0x4cd
> >> taskqueue_run_locked() at taskqueue_run_locked+0x93
> >> taskqueue_thread_loop() at taskqueue_thread_loop+0x3e
> >
> > It may be that scan_task() calls further down into the network stack
> > without setting curvnet first.
>
> I added CURVNET_SET(TD_TO_VNET(curthread))/CURVNET_RESTORE() in
> scan_task but it didnt help

scan_task() is called from a taskqueue trampoline which doesn't have a valid 
TD_TO_VNET(curthread) context, so what you attempted to do can't work.  You 
need to set curvnet context to the one to which the network interface (or a 
packet) you're working with belongs to.  Perhaps you could use

(struct ieee80211_scan_state *) ss->ss_vap->iv_ifp->if_curvnet

in scan_task() to set curvnet, but having no clue on how the 80211 code works, 
I might be wrong...

And maybe you could consider rebuilding your kernel with options VNET_DEBUG 
turned on - that should more verbosely point to the problem at hand, while 
not introducing too big a performance penalty at runtime.

Good luck,

Marko
___
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: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 19:01:11 Adrian Chadd wrote:
> Hi,
>
> What do we need to do to get VNET working in net80211 and the network
> drivers?

In principle one shouldn't have to touch anything in the network drivers.

In order for networking code to properly resolve virtualized state, curvnet 
(which is a synonim for curthread->td_vnet) must be set to a proper context 
when calling into networking code, and restored to previous value on 
returned.  CURVNET_SET() and CURVNET_RESTORE() are macros which should be 
used to do this.

As far as I know there are three ways for a function call to end up in the 
networking code: A) system calls (socket related, or syctls); B) servicing 
inbound packets; and C) timers / periodic tasks.

Cases A) and B) should be mostly covered in generic socket handlers and in 
netisr dispatchers, except sysctls which need to access any state you may 
have decided to virtualize - those should converted to use SYSCTL_VNET_* 
macros.

Cases which fall into category C) are the ones which probably require most 
attention and in certain cases may require certain amount of code 
restructuring.  Handlers which are dispatched via timers are not bound to any 
of the network stack instances, so in those you have to follow one of the two 
possible strategies:

1) iterate over all existing VNETs and do your timer-driven stuff once in each 
of those - in that case take a look at how VNET_LIST_RLOCK(), 
VNET_ITERATOR_DECL() and VNET_FOREACH() family of macros are used elsewhere, 
or

2) if the timer-driven event is bound to an object which is associated with an 
ifnet interface, you should explicitly set the curvnet context to match the 
one the ifnet is associated with, using CURVNET_SET(ifp->if_vnet), as I 
pointed out earlier in this thread.

Buiding a VNET_DEBUG kernel may help you a bit to find out the critical spots 
when things go wrong, but don't expect miracles...

I think both Julian and Bjoern have already written pretty nice and extensive 
documents covering those topics, but I would't know the current status or 
whereabouts of those...

Hope this helps,

Marko



> Adrian
>
> On 6 March 2012 07:33, Marko Zec  wrote:
> > On Tuesday 06 March 2012 10:53:18 Monthadar Al Jaberi wrote:
> >> On Tue, Mar 6, 2012 at 12:52 AM, Marko Zec  wrote:
> >> > On Monday 05 March 2012 22:14:45 Monthadar Al Jaberi wrote:
> >> >> Hi,
> >> >>
> >> >> I am a very happy VIMAGE user. But lately I have been having problems
> >> >> using it, and its too complicated for me to dig in so I hope you can
> >> >> help me (and help Adrian too).
> >> >>
> >> >> I am using FreeBSD Current with a kernel config without wlan module
> >> >> and wireless devices  attach kernel config.
> >> >>
> >> >> uname -a shows:
> >> >> FreeBSD acke 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Mon Mar  5
> >> >> 20:02:38 CET 2012    
> >> >> root@acke:/usr/obj/usr/src/sys/VNET_without_wlan  amd64
> >> >>
> >> >> I run the following commands:
> >> >> cd /usr/sys/module/wlan
> >> >> make load
> >> >> cd /usr/sys/modules/wtap
> >> >> make load
> >> >>
> >> >> then:
> >> >> /usr/src/ools/tools/wtap/wtap/wtap c 0
> >> >> ifconfig wlan create wlandev wtap0 wlanmode mesh
> >> >> wlandebug -i wlan0 hwmp+mesh+output+input+inact
> >> >> ifconfig wlan0 meshid mymesh
> >> >> ifconfig wlan0 inet 192.168.2.1
> >> >>
> >> >> and freebsd panics with:
> >> >> Mon Mar  5 21:17:46 CET 2012
> >> >> Mar  5 21:59:23 acke login: ROOT LOGIN (root) ON ttyv0
> >> >> Using visibility wtap plugin...
> >> >> Loaded wtap wireless simulator
> >> >> wtap0: ieee80211_radiotap_attach: no tx channel, radiotap 0x0wtap0:
> >> >> ieee80211_radiotap_attach: no rx channel, radiotap 0x0wlan0: Ethernet
> >> >> address: 00:98:9a:98:96:97
> >> >> wlan0: ieee80211_start: ignore queue, in SCAN state
> >> >> wlan0: [00:98:9a:98:96:97] ieee80211_alloc_node: inact_reload 2
> >> >> Kernel page fault with the following non-sleepable locks held:
> >> >> exclusive sleep mutex wtap0_com_lock (wtap0_com_lock) r = 0
> >> >> (0xff8002395018) locked @
> >> >> /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c:1937
> >> >> KDB: stack backtrace:
> >> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> >> >> kdb_backtrace() at kdb_backtrace+0x37
> >> >&g

Re: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 20:49:38 Monthadar Al Jaberi wrote:
> I added VNET_DEBUG and noticed this warning (original scan_task code):
>
> CURVNET_SET() recursion in sosend() line 1350, prev in kern_kldload()
> 0xfe0002202c40 -> 0xfe0002202c40
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> kdb_backtrace() at kdb_backtrace+0x37
> sosend() at sosend+0xbd
> clnt_vc_call() at clnt_vc_call+0x3e6
> clnt_reconnect_call() at clnt_reconnect_call+0xf5
> newnfs_request() at newnfs_request+0x9fb
> nfscl_request() at nfscl_request+0x72
> nfsrpc_lookup() at nfsrpc_lookup+0x1be
> nfs_lookup() at nfs_lookup+0x297
> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x95
> lookup() at lookup+0x3b8
> namei() at namei+0x484
> vn_open_cred() at vn_open_cred+0x1e2
> link_elf_load_file() at link_elf_load_file+0xb3
> linker_load_module() at linker_load_module+0x794
> kern_kldload() at kern_kldload+0x145
> sys_kldload() at sys_kldload+0x84
> amd64_syscall() at amd64_syscall+0x39e
> Xfast_syscall() at Xfast_syscall+0xf7

You can safely ignore those.  Recursing on curvnet is harmless, but in certain 
cases can't be avoided.

When injecting new CURVNET_SET() / CURVNET_RESTORE() points in the existing 
code, those warnings are here to help us becoming aware that we are setting 
curvnet in a function which was invoked with an already valid curvnet 
context.

Marko
___
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: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 21:13:00 Monthadar Al Jaberi wrote:
> I am confused so whats the difference between having wlan in kernel
> config or not? Cuase that seems the reason why we panic... linker
> problems?

Its not impossible.

Have you tried to do CURVNET_SET(ss->ss_vap->iv_ifp->if_vnet) on entry to 
scan_task() as I suggested earlier in this thread?

Cheers,

Marko


> On Tue, Mar 6, 2012 at 9:06 PM, Adrian Chadd  wrote:
> > Hi,
> >
> > The trouble here is that net80211 has quite a few other contexts that
> > things are called from:
> >
> > * driver taskqueue;
> > * net80211 taskqueue;
> > * driver callouts;
> > * net80211 callouts;
> > * ioctls via net80211.
> >
> > That's in parallel with frame tx/rx and device ioctls.
> >
> > I don't personally have the time to go through net80211 and driver(s)
> > at the moment to figure out what's going on. Since ath(4) does a bunch
> > of frame processing in taskqueue context (and I'm trying to eliminate
> > frame processing in _callout_ context, ew..) things can potentially
> > get a bit hairy.
> >
> >
> > Adrian
> >
> > On 6 March 2012 11:59, Marko Zec  wrote:
> >> On Tuesday 06 March 2012 20:49:38 Monthadar Al Jaberi wrote:
> >>> I added VNET_DEBUG and noticed this warning (original scan_task code):
> >>>
> >>> CURVNET_SET() recursion in sosend() line 1350, prev in kern_kldload()
> >>>     0xfe0002202c40 -> 0xfe0002202c40
> >>> KDB: stack backtrace:
> >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> >>> kdb_backtrace() at kdb_backtrace+0x37
> >>> sosend() at sosend+0xbd
> >>> clnt_vc_call() at clnt_vc_call+0x3e6
> >>> clnt_reconnect_call() at clnt_reconnect_call+0xf5
> >>> newnfs_request() at newnfs_request+0x9fb
> >>> nfscl_request() at nfscl_request+0x72
> >>> nfsrpc_lookup() at nfsrpc_lookup+0x1be
> >>> nfs_lookup() at nfs_lookup+0x297
> >>> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x95
> >>> lookup() at lookup+0x3b8
> >>> namei() at namei+0x484
> >>> vn_open_cred() at vn_open_cred+0x1e2
> >>> link_elf_load_file() at link_elf_load_file+0xb3
> >>> linker_load_module() at linker_load_module+0x794
> >>> kern_kldload() at kern_kldload+0x145
> >>> sys_kldload() at sys_kldload+0x84
> >>> amd64_syscall() at amd64_syscall+0x39e
> >>> Xfast_syscall() at Xfast_syscall+0xf7
> >>
> >> You can safely ignore those.  Recursing on curvnet is harmless, but in
> >> certain cases can't be avoided.
> >>
> >> When injecting new CURVNET_SET() / CURVNET_RESTORE() points in the
> >> existing code, those warnings are here to help us becoming aware that we
> >> are setting curvnet in a function which was invoked with an already
> >> valid curvnet context.
> >>
> >> Marko


___
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: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 21:29:32 Monthadar Al Jaberi wrote:
> On Tue, Mar 6, 2012 at 9:22 PM, Marko Zec  wrote:
> > On Tuesday 06 March 2012 21:13:00 Monthadar Al Jaberi wrote:
> >> I am confused so whats the difference between having wlan in kernel
> >> config or not? Cuase that seems the reason why we panic... linker
> >> problems?
> >
> > Its not impossible.
> >
> > Have you tried to do CURVNET_SET(ss->ss_vap->iv_ifp->if_vnet) on entry to
> > scan_task() as I suggested earlier in this thread?
>
> this is the code I added:
> diff --git a/sys/net80211/ieee80211_scan.c b/sys/net80211/ieee80211_scan.c
> index 5c1e3d9..bd20653 100644
> --- a/sys/net80211/ieee80211_scan.c
> +++ b/sys/net80211/ieee80211_scan.c
> @@ -850,6 +850,7 @@ scan_task(void *arg, int pending)
> int scandone = 0;
>
> IEEE80211_LOCK(ic);
> +  CURVNET_SET((struct ieee80211_scan_state *)
> ss->ss_vap->iv_ifp->if_curvnet);

The explicit cast is redundant here, I only used it earlier to clarify the 
type of variable ss...

Anyhow, by looking again at the backtrace you posted at the begining of this 
thread, it's apparent that the code calls into rt_dispatch() and fails at 
line 1494:

#ifdef VIMAGE
if (V_loif)
m->m_pkthdr.rcvif = V_loif;
...

because curvnet is not set, or is pointing somewhere where it shouldn't.

Can you post the output of show pcpu and show vnets from ddb> prompt when you 
get the panic?

Have you actually booted a freshly built kernel?  I pretty sure it's 
impossible for CURVNET_SET() to succeed with a NULL or an incorrect vnet 
pointer as an argument when the kernel is buitl with VNET_DEBUG, so I don't 
see how it may be possible for a patched scan_task() to call into 
rt_dispatch() with wrong curvnet.

Cheers,

Marko

> if (vap == NULL || (ic->ic_flags & IEEE80211_F_SCAN) == 0 ||
> (SCAN_PRIVATE(ss)->ss_iflags & ISCAN_ABORT)) {
> /* Cancelled before we started */
> @@ -1004,6 +1005,7 @@ scan_task(void *arg, int pending)
> ss->ss_ops->scan_restart(ss, vap);  /* XXX? */
> ieee80211_runtask(ic, &SCAN_PRIVATE(ss)->ss_scan_task);
> IEEE80211_UNLOCK(ic);
> +   CURVNET_RESTORE();
> return;
> }
>
> @@ -1043,6 +1045,7 @@ done:
> SCAN_PRIVATE(ss)->ss_iflags &= ~(ISCAN_CANCEL|ISCAN_ABORT);
> ss->ss_flags &= ~(IEEE80211_SCAN_ONCE | IEEE80211_SCAN_PICK1ST);
> IEEE80211_UNLOCK(ic);
> +   CURVNET_RESTORE();
>  #undef ISCAN_REP
>  }
>
> same panic...
>
> > Cheers,
> >
> > Marko
> >
> >> On Tue, Mar 6, 2012 at 9:06 PM, Adrian Chadd  
wrote:
> >> > Hi,
> >> >
> >> > The trouble here is that net80211 has quite a few other contexts that
> >> > things are called from:
> >> >
> >> > * driver taskqueue;
> >> > * net80211 taskqueue;
> >> > * driver callouts;
> >> > * net80211 callouts;
> >> > * ioctls via net80211.
> >> >
> >> > That's in parallel with frame tx/rx and device ioctls.
> >> >
> >> > I don't personally have the time to go through net80211 and driver(s)
> >> > at the moment to figure out what's going on. Since ath(4) does a bunch
> >> > of frame processing in taskqueue context (and I'm trying to eliminate
> >> > frame processing in _callout_ context, ew..) things can potentially
> >> > get a bit hairy.
> >> >
> >> >
> >> > Adrian
> >> >
> >> > On 6 March 2012 11:59, Marko Zec  wrote:
> >> >> On Tuesday 06 March 2012 20:49:38 Monthadar Al Jaberi wrote:
> >> >>> I added VNET_DEBUG and noticed this warning (original scan_task
> >> >>> code):
> >> >>>
> >> >>> CURVNET_SET() recursion in sosend() line 1350, prev in
> >> >>> kern_kldload() 0xfe0002202c40 -> 0xfe0002202c40
> >> >>> KDB: stack backtrace:
> >> >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> >> >>> kdb_backtrace() at kdb_backtrace+0x37
> >> >>> sosend() at sosend+0xbd
> >> >>> clnt_vc_call() at clnt_vc_call+0x3e6
> >> >>> clnt_reconnect_call() at clnt_reconnect_call+0xf5
> >> >>> newnfs_request() at newnfs_request+0x9fb
> >> >>> nfscl_request() at nfscl_request+0x72
> >> >>> nfsrpc_lookup() at nfsrpc_lookup+0x1be
> >

Re: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 21:29:32 Monthadar Al Jaberi wrote:
> On Tue, Mar 6, 2012 at 9:22 PM, Marko Zec  wrote:
> > On Tuesday 06 March 2012 21:13:00 Monthadar Al Jaberi wrote:
> >> I am confused so whats the difference between having wlan in kernel
> >> config or not? Cuase that seems the reason why we panic... linker
> >> problems?
> >
> > Its not impossible.
> >
> > Have you tried to do CURVNET_SET(ss->ss_vap->iv_ifp->if_vnet) on entry to
 
> > scan_task() as I suggested earlier in this thread?
>
> this is the code I added:
> diff --git a/sys/net80211/ieee80211_scan.c b/sys/net80211/ieee80211_scan.c
> index 5c1e3d9..bd20653 100644
> --- a/sys/net80211/ieee80211_scan.c
> +++ b/sys/net80211/ieee80211_scan.c
> @@ -850,6 +850,7 @@ scan_task(void *arg, int pending)
> int scandone = 0;
>
> IEEE80211_LOCK(ic);
> +  CURVNET_SET((struct ieee80211_scan_state *)
> ss->ss_vap->iv_ifp->if_curvnet);
  ^^^

You couldn't have ever compiled this, so you must be booting an old kernel.  

Pls. make sure you have actually rebuilt and rebooted a new kernel, an let us 
know the outcome.

Thanks

Marko


> if (vap == NULL || (ic->ic_flags & IEEE80211_F_SCAN) == 0 ||
> (SCAN_PRIVATE(ss)->ss_iflags & ISCAN_ABORT)) {
> /* Cancelled before we started */
> @@ -1004,6 +1005,7 @@ scan_task(void *arg, int pending)
> ss->ss_ops->scan_restart(ss, vap);  /* XXX? */
> ieee80211_runtask(ic, &SCAN_PRIVATE(ss)->ss_scan_task);
> IEEE80211_UNLOCK(ic);
> +   CURVNET_RESTORE();
> return;
> }
>
> @@ -1043,6 +1045,7 @@ done:
> SCAN_PRIVATE(ss)->ss_iflags &= ~(ISCAN_CANCEL|ISCAN_ABORT);
> ss->ss_flags &= ~(IEEE80211_SCAN_ONCE | IEEE80211_SCAN_PICK1ST);
> IEEE80211_UNLOCK(ic);
> +   CURVNET_RESTORE();
>  #undef ISCAN_REP
>  }
>
> same panic...
>
> > Cheers,
> >
> > Marko
> >
> >> On Tue, Mar 6, 2012 at 9:06 PM, Adrian Chadd  
wrote:
> >> > Hi,
> >> >
> >> > The trouble here is that net80211 has quite a few other contexts that
> >> > things are called from:
> >> >
> >> > * driver taskqueue;
> >> > * net80211 taskqueue;
> >> > * driver callouts;
> >> > * net80211 callouts;
> >> > * ioctls via net80211.
> >> >
> >> > That's in parallel with frame tx/rx and device ioctls.
> >> >
> >> > I don't personally have the time to go through net80211 and driver(s)
> >> > at the moment to figure out what's going on. Since ath(4) does a bunch
> >> > of frame processing in taskqueue context (and I'm trying to eliminate
> >> > frame processing in _callout_ context, ew..) things can potentially
> >> > get a bit hairy.
> >> >
> >> >
> >> > Adrian
> >> >
> >> > On 6 March 2012 11:59, Marko Zec  wrote:
> >> >> On Tuesday 06 March 2012 20:49:38 Monthadar Al Jaberi wrote:
> >> >>> I added VNET_DEBUG and noticed this warning (original scan_task
> >> >>> code):
> >> >>>
> >> >>> CURVNET_SET() recursion in sosend() line 1350, prev in
> >> >>> kern_kldload() 0xfe0002202c40 -> 0xfe0002202c40
> >> >>> KDB: stack backtrace:
> >> >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> >> >>> kdb_backtrace() at kdb_backtrace+0x37
> >> >>> sosend() at sosend+0xbd
> >> >>> clnt_vc_call() at clnt_vc_call+0x3e6
> >> >>> clnt_reconnect_call() at clnt_reconnect_call+0xf5
> >> >>> newnfs_request() at newnfs_request+0x9fb
> >> >>> nfscl_request() at nfscl_request+0x72
> >> >>> nfsrpc_lookup() at nfsrpc_lookup+0x1be
> >> >>> nfs_lookup() at nfs_lookup+0x297
> >> >>> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x95
> >> >>> lookup() at lookup+0x3b8
> >> >>> namei() at namei+0x484
> >> >>> vn_open_cred() at vn_open_cred+0x1e2
> >> >>> link_elf_load_file() at link_elf_load_file+0xb3
> >> >>> linker_load_module() at linker_load_module+0x794
> >> >>> kern_kldload() at kern_kldload+0x145
> >> >>> sys_kldload() at sys_kldload+0x84
> >> >>> amd64_syscall() at amd64_syscall+0x39e
> >> >>> Xfast_syscall() at Xfast_syscall+0xf7
> >> >>
> >> >> You can safely ignore those.  Recursing on curvnet is harmless, but
> >> >> in certain cases can't be avoided.
> >> >>
> >> >> When injecting new CURVNET_SET() / CURVNET_RESTORE() points in the
> >> >> existing code, those warnings are here to help us becoming aware that
> >> >> we are setting curvnet in a function which was invoked with an
> >> >> already valid curvnet context.
> >> >>
> >> >> Marko


___
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: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 22:30:26 Monthadar Al Jaberi wrote:
> On Tue, Mar 6, 2012 at 9:57 PM, Marko Zec  wrote:
> > On Tuesday 06 March 2012 21:29:32 Monthadar Al Jaberi wrote:
> >> On Tue, Mar 6, 2012 at 9:22 PM, Marko Zec  wrote:
> >> > On Tuesday 06 March 2012 21:13:00 Monthadar Al Jaberi wrote:
> >> >> I am confused so whats the difference between having wlan in kernel
> >> >> config or not? Cuase that seems the reason why we panic... linker
> >> >> problems?
> >> >
> >> > Its not impossible.
> >> >
> >> > Have you tried to do CURVNET_SET(ss->ss_vap->iv_ifp->if_vnet) on entry
> >> > to
> >
> >                         
> >
> >> > scan_task() as I suggested earlier in this thread?
> >>
> >> this is the code I added:
> >> diff --git a/sys/net80211/ieee80211_scan.c
> >> b/sys/net80211/ieee80211_scan.c index 5c1e3d9..bd20653 100644
> >> --- a/sys/net80211/ieee80211_scan.c
> >> +++ b/sys/net80211/ieee80211_scan.c
> >> @@ -850,6 +850,7 @@ scan_task(void *arg, int pending)
> >>         int scandone = 0;
> >>
> >>         IEEE80211_LOCK(ic);
> >> +      CURVNET_SET((struct ieee80211_scan_state *)
> >> ss->ss_vap->iv_ifp->if_curvnet);
> >
> >  ^^^
> >
> > You couldn't have ever compiled this, so you must be booting an old
> > kernel.
>
> Whats wrong with this line, I am running new kernel remember I compile
> wlan afterward and kldload it

struct ifnet doesn't have a field named if_curvnet, but it does contain a 
field named if_vnet.

> it seems to compile fine if I type wrong names inside CURVNET_SET hmm...

No it does not compile.

Marko


> I cant copy/paste db output from VBox butI am attaching two pictures.
>
> > Pls. make sure you have actually rebuilt and rebooted a new kernel, an
> > let us know the outcome.
> >
> > Thanks
> >
> > Marko
> >
> >>         if (vap == NULL || (ic->ic_flags & IEEE80211_F_SCAN) == 0 ||
> >>             (SCAN_PRIVATE(ss)->ss_iflags & ISCAN_ABORT)) {
> >>                 /* Cancelled before we started */
> >> @@ -1004,6 +1005,7 @@ scan_task(void *arg, int pending)
> >>                 ss->ss_ops->scan_restart(ss, vap);      /* XXX? */
> >>                 ieee80211_runtask(ic, &SCAN_PRIVATE(ss)->ss_scan_task);
> >>                 IEEE80211_UNLOCK(ic);
> >> +               CURVNET_RESTORE();
> >>                 return;
> >>         }
> >>
> >> @@ -1043,6 +1045,7 @@ done:
> >>         SCAN_PRIVATE(ss)->ss_iflags &= ~(ISCAN_CANCEL|ISCAN_ABORT);
> >>         ss->ss_flags &= ~(IEEE80211_SCAN_ONCE | IEEE80211_SCAN_PICK1ST);
> >>         IEEE80211_UNLOCK(ic);
> >> +       CURVNET_RESTORE();
> >>  #undef ISCAN_REP
> >>  }
> >>
> >> same panic...
> >>
> >> > Cheers,
> >> >
> >> > Marko
> >> >
> >> >> On Tue, Mar 6, 2012 at 9:06 PM, Adrian Chadd 
> >
> > wrote:
> >> >> > Hi,
> >> >> >
> >> >> > The trouble here is that net80211 has quite a few other contexts
> >> >> > that things are called from:
> >> >> >
> >> >> > * driver taskqueue;
> >> >> > * net80211 taskqueue;
> >> >> > * driver callouts;
> >> >> > * net80211 callouts;
> >> >> > * ioctls via net80211.
> >> >> >
> >> >> > That's in parallel with frame tx/rx and device ioctls.
> >> >> >
> >> >> > I don't personally have the time to go through net80211 and
> >> >> > driver(s) at the moment to figure out what's going on. Since ath(4)
> >> >> > does a bunch of frame processing in taskqueue context (and I'm
> >> >> > trying to eliminate frame processing in _callout_ context, ew..)
> >> >> > things can potentially get a bit hairy.
> >> >> >
> >> >> >
> >> >> > Adrian
> >> >> >
> >> >> > On 6 March 2012 11:59, Marko Zec  wrote:
> >> >> >> On Tuesday 06 March 2012 20:49:38 Monthadar Al Jaberi wrote:
> >> >> >>> I added VNET_DEBUG and noticed this warning (original scan_task
> >> >> >>> code)

Re: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 22:45:40 Marko Zec wrote:
> On Tuesday 06 March 2012 22:30:26 Monthadar Al Jaberi wrote:
> > On Tue, Mar 6, 2012 at 9:57 PM, Marko Zec  wrote:
> > > On Tuesday 06 March 2012 21:29:32 Monthadar Al Jaberi wrote:
> > >> On Tue, Mar 6, 2012 at 9:22 PM, Marko Zec  wrote:
> > >> > On Tuesday 06 March 2012 21:13:00 Monthadar Al Jaberi wrote:
> > >> >> I am confused so whats the difference between having wlan in kernel
> > >> >> config or not? Cuase that seems the reason why we panic... linker
> > >> >> problems?
> > >> >
> > >> > Its not impossible.
> > >> >
> > >> > Have you tried to do CURVNET_SET(ss->ss_vap->iv_ifp->if_vnet) on
> > >> > entry to
> > >
> > >                         
> > >
> > >> > scan_task() as I suggested earlier in this thread?
> > >>
> > >> this is the code I added:
> > >> diff --git a/sys/net80211/ieee80211_scan.c
> > >> b/sys/net80211/ieee80211_scan.c index 5c1e3d9..bd20653 100644
> > >> --- a/sys/net80211/ieee80211_scan.c
> > >> +++ b/sys/net80211/ieee80211_scan.c
> > >> @@ -850,6 +850,7 @@ scan_task(void *arg, int pending)
> > >>         int scandone = 0;
> > >>
> > >>         IEEE80211_LOCK(ic);
> > >> +      CURVNET_SET((struct ieee80211_scan_state *)
> > >> ss->ss_vap->iv_ifp->if_curvnet);
> > >
> > >  ^^^
> > >
> > > You couldn't have ever compiled this, so you must be booting an old
> > > kernel.
> >
> > Whats wrong with this line, I am running new kernel remember I compile
> > wlan afterward and kldload it
>
> struct ifnet doesn't have a field named if_curvnet, but it does contain a
> field named if_vnet.
>
> > it seems to compile fine if I type wrong names inside CURVNET_SET hmm...
>
> No it does not compile.

Ohh now I see it where the problem most probably is - you've compiled your 
kernel with options VIMAGE, but not your modules!!!

Check your config / build environment to make sure BOTH kernel AND modules are 
configured and built the same way...

Cheers,

Marko

>
> > I cant copy/paste db output from VBox butI am attaching two pictures.
> >
> > > Pls. make sure you have actually rebuilt and rebooted a new kernel, an
> > > let us know the outcome.
> > >
> > > Thanks
> > >
> > > Marko
> > >
> > >>         if (vap == NULL || (ic->ic_flags & IEEE80211_F_SCAN) == 0 ||
> > >>             (SCAN_PRIVATE(ss)->ss_iflags & ISCAN_ABORT)) {
> > >>                 /* Cancelled before we started */
> > >> @@ -1004,6 +1005,7 @@ scan_task(void *arg, int pending)
> > >>                 ss->ss_ops->scan_restart(ss, vap);      /* XXX? */
> > >>                 ieee80211_runtask(ic,
> > >> &SCAN_PRIVATE(ss)->ss_scan_task); IEEE80211_UNLOCK(ic);
> > >> +               CURVNET_RESTORE();
> > >>                 return;
> > >>         }
> > >>
> > >> @@ -1043,6 +1045,7 @@ done:
> > >>         SCAN_PRIVATE(ss)->ss_iflags &= ~(ISCAN_CANCEL|ISCAN_ABORT);
> > >>         ss->ss_flags &= ~(IEEE80211_SCAN_ONCE |
> > >> IEEE80211_SCAN_PICK1ST); IEEE80211_UNLOCK(ic);
> > >> +       CURVNET_RESTORE();
> > >>  #undef ISCAN_REP
> > >>  }
> > >>
> > >> same panic...
> > >>
> > >> > Cheers,
> > >> >
> > >> > Marko
> > >> >
> > >> >> On Tue, Mar 6, 2012 at 9:06 PM, Adrian Chadd
> > >> >> 
> > >
> > > wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > The trouble here is that net80211 has quite a few other contexts
> > >> >> > that things are called from:
> > >> >> >
> > >> >> > * driver taskqueue;
> > >> >> > * net80211 taskqueue;
> > >> >> > * driver callouts;
> > >> >> > * net80211 callouts;
> > >> >> > * ioctls via net80211.
> > >> >> >
> > >> >> > That's in parallel with frame tx/rx and device ioctls.
> > >> >> >
> > >> >> > I don't personally have 

Re: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 22:49:56 Adrian Chadd wrote:
> Wait a sec. Is it possible that the macro is a no-op when we're
> building modules w/ VNET?

Yes that's it, the VNET stuff resolves (mostly) to whitespace when options 
VIMAGE is not on!

Marko
___
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: VIMAGE + kldload wlan + kldload wtap panic

[Marko Zec]

On Tuesday 06 March 2012 22:52:43 Adrian Chadd wrote:
> On 6 March 2012 13:51, Marko Zec  wrote:
> > On Tuesday 06 March 2012 22:49:56 Adrian Chadd wrote:
> >> Wait a sec. Is it possible that the macro is a no-op when we're
> >> building modules w/ VNET?
> >
> > Yes that's it, the VNET stuff resolves (mostly) to whitespace when
> > options VIMAGE is not on!
>
> So the question is - how the heck are the modules supposed to pull in
> the VNET config?
>
> is there a missing opt_.h somewhere?
>

No, you don't need any extra explicit #includes, but you should see this in 
opt_global.h if you've really configured the kernel with options VIMAGE:

#define VIMAGE 1

Marko
___
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: vimage tool crash when deleting a jail @netisr_process_workstream_proto

[Marko Zec]

On Wednesday 25 April 2012 14:08:48 Monthadar Al Jaberi wrote:
> Hi,
>
> Not sure if I should post this on virt or jail.
>
> I am not sure about this, but I thought it was an amd64 specific thing
> (had posted about it some time ago), but  now I also get a panic on
> i386. What is weird is that if I add options VNET_DEBUG to the kernel
> config I dont get the panic! Debug output after vimage -c jid=0:
> hhook_vnet_uninit: hhook_head type=1, id=1 cleanup required
> hhook_vnet_uninit: hhook_head type=1, id=0 cleanup required
>
>
> Also There seem to be a LOR after running vimage -c jid=0
> lock order reversal:
>  1st 0xc1037dac allprison (allprison) @ /usr/src/sys/kern/kern_jail.c:970
>  2nd 0xc11b23f4 vnet_sysinit_sxlock (vnet_sysinit_sxlock) @
> /usr/src/sys/net/vnet.c:615
> KDB: stack backtrace:
> db_trace_self_wrapper(c0e95cbb,6b636f6c,20402029,7273752f,6372732f,...)
> at db_trace_self_wrapper+0x26
> kdb_backtrace(c09e2ecb,c0e9974c,c1183ed0,267,e1b409f8,...) at
> kdb_backtrace+0x2a
> _witness_debugger(c0e9974c,c11b23f4,c0ea92c5,c7d64fc8,c0ea9418,...) at
> _witness_debugger+0x25
> witness_checkorder(c11b23f4,1,c0ea9418,267,0,...) at
> witness_checkorder+0x86f _sx_slock(c11b23f4,0,c0ea9418,267,cad672e0,...) at
> _sx_slock+0x9a
> vnet_sysinit(cad7f000,c0ff9700,5560,cad7e028,c0fb3588,...) at
> vnet_sysinit+0x2b vnet_alloc(cad7e028,c0e8c936,0,10,0,...) at
> vnet_alloc+0x168
> kern_jail_set(cad672e0,c9470d00,1,c9470d00,0,...) at kern_jail_set+0x1bb4
> sys_jail_set(cad672e0,e1b40cec,c0edada8,c0e9a9a6,c1047f40,...) at
> sys_jail_set+0x50
> syscall(e1b40d28) at syscall+0x2de
> Xint0x80_syscall() at Xint0x80_syscall+0x21
> --- syscall (507, FreeBSD ELF32, sys_jail_set), eip = 0x280bfd5b, esp
> = 0xbfbfe23c, ebp = 0xbfbfe328 ---
>
>
>
> This is my setup:
> Host PC: Ubuntu 11.04 (Linux bane 2.6.38-12-generic)
> VirtualBox: 4.1.6 r74713
> FreeBSD gues: i386 head@234636 (attaching kernel config)
>
> I compile and install /usr/src/tools/tools/vimage
>
> running:
> vimage -c jid=0
> vimage -d jid=0
>
> crashes the kernel (attaching core.txt.2)
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0xdeadc0e6
> fault code= supervisor read, page not present
> instruction pointer   = 0x20:0xc0a78d20
> stack pointer = 0x28:0xc7980c48
> frame pointer = 0x28:0xc7980c90
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, def32 1, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 12 (swi1: netisr 0)
>
> #0  doadump (textdump=0) at pcpu.h:244
> 244   pcpu.h: No such file or directory.
>   in pcpu.h
> (kgdb) #0  doadump (textdump=0) at pcpu.h:244
> #1  0xc05104b3 in db_dump (dummy=-1062761184, dummy2=0, dummy3=-1,
> dummy4=0xc798096c "") at /usr/src/sys/ddb/db_command.c:538
> #2  0xc050fbd1 in db_command (last_cmdp=0xc1dc, cmd_table=0x0,
> dopager=1) at /usr/src/sys/ddb/db_command.c:449
> #3  0xc050fd2a in db_command_loop () at /usr/src/sys/ddb/db_command.c:502
> #4  0xc0511d1d in db_trap (type=12, code=0) 
at /usr/src/sys/ddb/db_main.c:231
> #5  0xc09de976 in kdb_trap (type=12, code=0, 
> tf=0xc7980c08)
> at /usr/src/sys/kern/subr_kdb.c:654
> #6  0xc0cf2eff in trap_fatal (frame=0xc7980c08, eva=3735929062)
> at /usr/src/sys/i386/i386/trap.c:1013
> #7  0xc0cf32ee in trap_pfault (frame=0xc7980c08, usermode=0,
> eva=3735929062) at /usr/src/sys/i386/i386/trap.c:936
> #8  0xc0cf40b1 in trap (frame=0xc7980c08) at
> /usr/src/sys/i386/i386/trap.c:546 #9  0xc0cdd8ec in calltrap () at
> /usr/src/sys/i386/i386/exception.s:169 #10 0xc0a78d20 in swi_net
> (arg=0xc1825880) at /usr/src/sys/net/netisr.c:805

The backtrace says it's most probably this line in netisr.c:

805 CURVNET_SET(m->m_pkthdr.rcvif->if_vnet);

> #11 0xc0979d75 in 
> intr_event_execute_handlers (p=0xc7dc6598, ie=0xc7e95300) at
> /usr/src/sys/kern/kern_intr.c:1260
> #12 0xc097ac49 in ithread_loop (arg=0xc7e0f7a0)
> at /usr/src/sys/kern/kern_intr.c:1273
> #13 0xc0976fa8 in fork_exit (callout=0xc097aba0 ,
> arg=0xc7e0f7a0, frame=0xc7980d28) at /usr/src/sys/kern/kern_fork.c:992
> #14 0xc0cdd994 in fork_trampoline () at
> /usr/src/sys/i386/i386/exception.s:276 (kgdb)
>
>
> It seems that it crashes on netisr_process_workstream_proto, why are
> we even in this function? Is someone sending a packet?

When netisr_process_workstream_proto() processes queued mbufs, in options 
VIMAGE builds it expects all mbufs to have m->m_pkthdr.rcvif set to a valid 
interface, so that the curvnet context could be harvested from there.  

Perhaps you've created a new mbuf and queued it for netisr dispatching, but 
have left m->m_pkthdr.rcvif uninitialized?

Marko
___
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-un

Re: VIMAGE + PF crash in mbuf destructor

[Marko Zec]

On Monday 22 July 2013 08:57:43 Craig Rodrigues wrote:
> On Sun, Jul 21, 2013 at 11:38 PM, Adrian Chadd  wrote:
> > hm. There's lots of mbuf free calls in the net80211 TX and RX path; do
> > we have to have to set the vnet context during the whole tx/rx path?
>
> I'm not sure about that.
> In src/sys/netpfil/pf/pf.c, we have this in pf_initialize():
>
> 751 /* Mbuf tags */
> 752 V_pf_mtag_z = uma_zcreate("pf mtags", sizeof(struct
> m_tag) + 753 sizeof(struct pf_mtag), NULL, NULL,
> pf_mtag_init, NULL, 754 UMA_ALIGN_PTR, 0);
>
> and further down this:
>
> 812 static int
> 813 pf_mtag_init(void *mem, int size, int how)
> 814 {
> 815 struct m_tag *t;
> 816
> 817 t = (struct m_tag *)mem;
> 818 t->m_tag_cookie = MTAG_ABI_COMPAT;
> 819 t->m_tag_id = PACKET_TAG_PF;
> 820 t->m_tag_len = sizeof(struct pf_mtag);
> 821 t->m_tag_free = pf_mtag_free;
> 822
> 823 return (0);
> 824 }
> 825
> 826 static void
> 827 pf_mtag_free(struct m_tag *t)
> 828 {
> 829
> 830 uma_zfree(V_pf_mtag_z, t);
> 831 }
>
>
> Can we somehow modify pf_mtag_init() so that it passes the
> vnet into the pf_mtag?
> Then we can call CURVNET_SET/CURVNET_RESTORE in pf_mtag_free().

I'd say just de-virtualize V_pf_mtag_z, and you're done.

Marko


> --
> Craig
>
> > -adrian
> >
> > On 21 July 2013 23:32, Craig Rodrigues  wrote:
> > > Hi,
> > >
> > > I used a kernel config with the following lines:
> > >
> > > include GENERIC
> > > options VIMAGE
> > >
> > > and compiled a CURRENT kernel from svn://
> >
> > svn.freebsd.org/base/head@253346 .
> >
> > > I also have PF enabled on my system.
> > >
> > > Once in a while I have been getting kernel panics like these:
> > >
> > >
> > > 
> > > (kgdb) #0  doadump (textdump=1) at pcpu.h:236
> > > #1  0x808bc617 in kern_reboot (howto=260)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:447
> > > #2  0x808bcb25 in vpanic (fmt=,
> > > ap=)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:754
> > > #3  0x808bcb73 in panic (fmt=)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/kern_shutdown.c:683
> > > #4  0x8033dff7 in db_panic (addr=,
> > > have_addr=, count=,
> > > modif=)
> > > at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:482
> > > #5  0x8033dbcd in db_command (cmd_table= > > out>) at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:449 #6 
> > > 0x8033d944 in db_command_loop ()
> > > at /usr/home/rodrigc/freebsd/head/sys/ddb/db_command.c:502
> > > #7  0x803402f0 in db_trap (type=,
> > > code=0) at /usr/home/rodrigc/freebsd/head/sys/ddb/db_main.c:231
> > > #8  0x808f3623 in kdb_trap (type=12, code=0, tf= > > optimized out>)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/subr_kdb.c:654
> > > #9  0x80cda43a in trap_fatal (frame=0xff811dbab6b0,
> > > eva=)
> > > at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:868
> > > #10 0x80cda6f4 in trap_pfault (frame=0x0, usermode=0)
> > > at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:699
> > > #11 0x80cd9ef0 in trap (frame=0xff811dbab6b0)
> > > at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/trap.c:463
> > > #12 0x80cc31a2 in calltrap ()
> > > at /usr/home/rodrigc/freebsd/head/sys/amd64/amd64/exception.S:232
> > > #13 0x8208f7b7 in pf_mtag_free (t=0xfe00a8797870)
> > > at
> > > /usr/home/rodrigc/freebsd/head/sys/modules/pf/../../netpfil/pf/pf.c:8
> > >30 #14 0x808a51c9 in mb_dtor_mbuf (mem=0xfe000d0bc500,
> > > size=256, arg=0x0) at
> > > /usr/home/rodrigc/freebsd/head/sys/kern/kern_mbuf.c:499 #15
> > > 0x80b55d4d in uma_zfree_arg (zone=0xfe000b4ab900,
> > > item=0xfe000d0bc500, udata=0x0)
> > > at /usr/home/rodrigc/freebsd/head/sys/vm/uma_core.c:2560
> > > #16 0x8092d1f5 in m_freem (mb=) at
> > > uma.h:364 #17 0x8058ba72 in iwn_tx_done
> > > (sc=0xff8000974000, desc=, ackfailcnt=16,
> > > status=131 '\203') at
> > > /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:2817 #18
> > > 0x80583e60 in iwn_notif_intr (sc=0xff8000974000) at
> > > /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:3015 #19
> > > 0x80583684 in iwn_intr (arg=0xff8000974000)
> > > at /usr/home/rodrigc/freebsd/head/sys/dev/iwn/if_iwn.c:3306
> > > #20 0x8088daf3 in intr_event_execute_handlers (
> > > p=, ie=0xfe000b696600)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/kern_intr.c:1263
> > > #21 0x8088e4c6 in ithread_loop (arg=0xfe000b31b040)
> > > at /usr/home/rodrigc/freebsd/head/sys/kern/kern_intr.c:1276
> > > #22 0x8088b3f4 in fork_exit (
> > > callout=0x8088e420 ,
> > > 

Re: VIMAGE + PF crash in mbuf destructor

[Marko Zec]

On Monday 22 July 2013 21:01:31 Adrian Chadd wrote:
> Well I'm worried about _other_ stuff causing issues here.
>
> So - what's the "right" behaviour? Does vnet/vimage make the
> assumption that for all the mbuf processing/free operations, the vnet
> tag/state is set?

To the best of my knowledge, there's nothing vnet-specific in any of the 
mbuf-handling routines, i.e. they should all work fine on a VIMAGE kernel 
even if curvnet isn't set.

My original motivation behind keeping separate UMA zones for each vnet was 
solely to capture resource leaks between vnets in the early days of VIMAGE 
prototyping.  Nothing prevents a single UMA zone to be shared by multiple 
vnets, unless we want to enforce per-vnet limitations on the number of 
items in a zone.

Marko


>
> -adrian
>
> On 22 July 2013 11:59, Craig Rodrigues  wrote:
> > On Mon, Jul 22, 2013 at 10:11 AM, Adrian Chadd  
wrote:
> >> I don't think the default vnet context is the correct behaviour there.
> >> We'd need to figure out what the vnet context of the mbuf is and set
> >> that.
> >
> > What do you think about Marko's suggestion to de-virtualize
> > V_pf_mtag_z?  What would be the down side of that?
> >
> > I don't understand enough of the PF code to understand which variables
> > need to
> > be virtual and which don't.
> >
> > --
> > Craig
>
> ___
> 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"


___
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: De-virtualize V_pf_mtag_z to eliminate kernel panics.

[Marko Zec]

On Saturday 27 July 2013 08:31:48 Craig Rodrigues wrote:
> Gleb,
>
> Since you did a lot of work in GRN 240233
> to fix PF issues, especially for VIMAGE, I thought I would
> ask your opinion on the attached patch.
>
> In this post:
>
> http://lists.freebsd.org/pipermail/freebsd-virtualization/2013-July/00140
>5.html
>
> I reported multiple PF-related panics when VIMAGE was enabled
> in my kernel config.
>
> In these posts:
> http://lists.freebsd.org/pipermail/freebsd-virtualization/2013-July/00141
>3.html
> http://lists.freebsd.org/pipermail/freebsd-virtualization/2013-July/00142
>0.html
>
> Marko Zec seemed to think that de-virtualizing V_pf_mtag_z
> would be a valid solution to this problem, and that keeping
> V_pf_mtag_z as a per-vnet variable is not necessary.
>
> What do you think of Marko's comments, and this patch?

Hi Craig,

while in principle I agree with the intent to de-virtualize V_pf_mtag_z 
(after all, this was my suggestion in the first place), your proposed patch 
isn't the valid solution, since on each vnet creation you'll be clobbering 
(now global) variable pf_mtag_z, which would imminently cause double-free 
or similar issues later during runtime.  You should move

pf_mtag_z = uma_zcreate(...)

to some other function which isn't called for each vnet, or at least as a 
crude kludge, do this conditionally if (curvnet == vnet0).  The same goes 
for uma_zdestroy(pf_mtag_z)...

Cheers,

Marko
___
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: De-virtualize V_pf_mtag_z to eliminate kernel panics.

[Marko Zec]

On Saturday 27 July 2013 16:48:00 Adrian Chadd wrote:
> I'm happy keeping it virtual (it lets us do things like set per-vimage
> mbuf tag limits, and having per-vimage mbufs may be a useful long term
> stretch goal to have).. we just have to think about this stuff in more
> detail.

The V_pf_mtag_z zone apparently doesn't have any size limits, so it doesn't 
enforce mbuf tag limits in pf, and certainly it doesn't enforce any limits 
outside of PF?

And while otherwise I wouldn't terribly object to keep V_pf_mtag_z virtual, 
if we don't de-virtualize it, would you have an alternative proposal to 
resolve the panics in PF which Craig wants to have fixed?

Finally, while the idea about enforcing per-vnet mbuf (and tag) limits may 
look neat on the surface, the fact that mbufs may flow freely between vnets 
makes this idea less trivial to implement than it may appear at the first 
glance.  In any case, IMO that issue is entirely unrelated to the patch 
Craig proposed, and should be discussed separately.

Marko
___
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: RFC: ipfw nat VIMAGE improvements

[Marko Zec]

On Sunday 11 August 2013 22:01:12 Mikolaj Golub wrote:
> Hi,
>
> I would like to commit this patch that fixes some issues related to
> ipfw nat module load/unload on VIMAGE featured system.
>
> Any comments, objections?

Far from being an expert in ipfw, I'm worried that the proposed approach of 
simultaneously acquiring locks on _all_ ipfw instances might be calling for 
trouble:

+   VNET_LIST_RLOCK();
+   VNET_FOREACH(vnet_iter) {
+   CURVNET_SET(vnet_iter);
+   IPFW_WLOCK(&V_layer3_chain);
+   CURVNET_RESTORE();
+   }
ipfw_nat_ptr = ipfw_nat;
lookup_nat_ptr = lookup_nat;
ipfw_nat_cfg_ptr = ipfw_nat_cfg;
ipfw_nat_del_ptr = ipfw_nat_del;
ipfw_nat_get_cfg_ptr = ipfw_nat_get_cfg;
ipfw_nat_get_log_ptr = ipfw_nat_get_log;
-   IPFW_WUNLOCK(&V_layer3_chain);
-   V_ifaddr_event_tag = EVENTHANDLER_REGISTER(
+   VNET_FOREACH(vnet_iter) {
+   CURVNET_SET(vnet_iter);
+   IPFW_WUNLOCK(&V_layer3_chain);
+   CURVNET_RESTORE();
+   }
+   VNET_LIST_RUNLOCK();

Why couldn't we introduce a per-vnet flag, say V_ipfw_nat_ready, and use it 
as

#define IPFW_NAT_LOADED (V_ipfw_nat_ready)

instead of current version of that macro:

#define IPFW_NAT_LOADED (ipfw_nat_ptr != NULL)

I.e., perhaps in ipfw_nat_init() we could first set all the function 
pointers, and then iterate over all vnets and set V_ipfw_nat ready there.  
In ipfw_nat_destroy() we would first iterate over all vnets to clear the 
flag, before clearing function pointers?

Marko

___
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: RFC: ipfw nat VIMAGE improvements

[Marko Zec]

On Wednesday 14 August 2013 22:43:05 Mikolaj Golub wrote:
> On Wed, Aug 14, 2013 at 05:28:31PM +0200, Marko Zec wrote:
> > On Sunday 11 August 2013 22:01:12 Mikolaj Golub wrote:
> > > Hi,
> > >
> > > I would like to commit this patch that fixes some issues related to
> > > ipfw nat module load/unload on VIMAGE featured system.
> > >
> > > Any comments, objections?
> >
> > Far from being an expert in ipfw, I'm worried that the proposed
> > approach of simultaneously acquiring locks on _all_ ipfw instances
> > might be calling for trouble:
> >
> > +   VNET_LIST_RLOCK();
> > +   VNET_FOREACH(vnet_iter) {
> > +   CURVNET_SET(vnet_iter);
> > +   IPFW_WLOCK(&V_layer3_chain);
> > +   CURVNET_RESTORE();
> > +   }
> > ipfw_nat_ptr = ipfw_nat;
> > lookup_nat_ptr = lookup_nat;
> > ipfw_nat_cfg_ptr = ipfw_nat_cfg;
> > ipfw_nat_del_ptr = ipfw_nat_del;
> > ipfw_nat_get_cfg_ptr = ipfw_nat_get_cfg;
> > ipfw_nat_get_log_ptr = ipfw_nat_get_log;
> > -   IPFW_WUNLOCK(&V_layer3_chain);
> > -   V_ifaddr_event_tag = EVENTHANDLER_REGISTER(
> > +   VNET_FOREACH(vnet_iter) {
> > +   CURVNET_SET(vnet_iter);
> > +   IPFW_WUNLOCK(&V_layer3_chain);
> > +   CURVNET_RESTORE();
> > +   }
> > +   VNET_LIST_RUNLOCK();
> >
> > Why couldn't we introduce a per-vnet flag, say V_ipfw_nat_ready, and
> > use it as
> >
> > #define IPFW_NAT_LOADED (V_ipfw_nat_ready)
> >
> > instead of current version of that macro:
> >
> > #define IPFW_NAT_LOADED (ipfw_nat_ptr != NULL)
> >
> > I.e., perhaps in ipfw_nat_init() we could first set all the function
> > pointers, and then iterate over all vnets and set V_ipfw_nat ready
> > there. In ipfw_nat_destroy() we would first iterate over all vnets to
> > clear the flag, before clearing function pointers?
>
> I like you approach. Though insted of iterating vnets in
> ipfw_nat_init/destroy I think it is safe just to set/unset
> V_ipfw_nat_ready in vnet_ipfw_nat_init/uninit.

Yup that should be safe, provided you're 100% sure that 
vnet_ipfw_nat_uninit() fires before ipfw_nat_destroy() - admittedly my 
sysinit ordering insight got a bit rusty so I can't tell at the first 
glance...

Anyhow, this looks fine to me...

Marko
___
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: Enabling VIMAGE by default for FreeBSD 11?

[Marko Zec]

On Fri, 17 Oct 2014 13:37:37 +0200
Marius Strobl  wrote:

> On Wed, Oct 15, 2014 at 04:27:28PM -0700, Craig Rodrigues wrote:
> > On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore  wrote:
> > 
> > >
> > > It was for a while in 9.2, but we removed it from 10.0 and later
> > > due to stability issues we kept getting reports about. Haven't
> > > tried it since then, dont know if those issues are fixed.
> > >
> > 
> > I fixed some of the problems with VIMAGE that I encountered with
> > Bluetooth:
> > 
> > https://lists.freebsd.org/pipermail/svn-src-head/2013-July/049582.html
> 
> ... which still lacks a proper implementation that doesn't constitute
> a gross layering violation in generic bus code.

By all means please go ahead and propose a layering-clean alternative,
not as ugly and intrusive as this part which I assume bodes you eyes:

-   return (device_attach(dev));
+
+   CURVNET_SET_QUIET(vnet0);
+   error = device_attach(dev);
+   CURVNET_RESTORE();
+   return error;

Marko


> > 
> > Hiroo Onoo submitted this patch, which I committed to fix problems
> > with VIMAGE encountered with removable USB Ethernet:
> > 
> > https://lists.freebsd.org/pipermail/svn-src-all/2014-February/081025.html
> > 
> > Martin Matuska committed this fix for PF:
> > https://lists.freebsd.org/pipermail/svn-src-head/2014-April/057803.html
> > 
> > So a lot of the stability problems with VIMAGE which were in PC-BSD
> > 9.2 and FreeBSD 9.x have been slowly been fixed.
> 
> Marius
> 
> ___
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

___
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: RFC: Enabling VIMAGE in GENERIC

[Marko Zec]

On Wed, 19 Nov 2014 16:07:46 +0400
"Alexander V. Chernikov"  wrote:
...
> Can we have some wiki/man/docs on how particular subsystem should 
> interact with VNET first?
> This can probably help to make proper vnet fixes in less number of 
> attempts :)
>
> For example, even attach/detach is handled differently in different
> places:
> 
> tcp_subr.c:
>  /* Skip initialization of globals for non-default instances.
> */ if (!IS_DEFAULT_VNET(curvnet))
>  return;
> in6_rmx.c:
> /*
>   * Initialize our routing tree.
>   */
> static VNET_DEFINE(int, _in6_rt_was_here);
> #define V__in6_rt_was_here  VNET(_in6_rt_was_here)
> 
>  if (V__in6_rtwas_here == 0) {
>  callout_init(&V_rtq_mtutimer, CALLOUT_MPSAFE);
>  in6_mtutimo(curvnet);   /* kick off timeout first
> time */ V__in6_rt_was_here = 1;
>  }
> 
>  return (1);
> }
> 
> It would be great to get a bit more details on the following (at
> least from my point of view):
> * what is the proper procedure of handling non-default VNET 
> attach/detach (locking mostly)

In general, VNET_SYSINIT() / VNET_SYSUNINIT() macros should be used to
invoke per-subsystem ctors / dtors on per-vnet basis.

> * how can one properly cache needed VNET context (e.g. is it safe
> just to save "struct vnet *" pointer) and is this right thing to do
> at all?

Caching a VNET context should be avoided, as it yields similar problems
as queuing mbufs does (in dummynet or similar queues) pointing to rcvifs
which may disappear by the time the mbuf gets dequeued.

> * Is it safe to to CURVNET_SET without holding any VNET locks ?

Yes, if the VNET context is derived from some of the arguments in the
current call graph.

> P.S. I'm not against VIMAGE in any kind, I think we really should
> move forward towards making it stable.
> However, "just turn it on" concept with a bunch of known (and
> unresolved issues) is not the best thing IMO.
> >
> > We have about 1 year until 11-RELEASE, so I think it is OK to do
> > this.
> >
> > I would also add two items to my action plan.
> >
> >
> > (6)  Ask clusteradm to run one of the machines they use
> >for PF firewalls + IPv6 with a VIMAGE enabled kernel, and
> > provide feedback.
> >
> > (7)  Ask for help with testing from companies who have more
> > involvement with the network stack.  Two of the people in the CC:
> > line of this e-mail work for such places. :)
> >
> > --
> > Craig
> >
> >
> > --
> > Craig
> > ___
> > freebsd-...@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to
> > "freebsd-net-unsubscr...@freebsd.org"
> >
> 
> ___
> 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"

___
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"

[Differential] [Changed Subscribers] D1315: VIMAGE PF fixes #4

[zec (Marko Zec)]

zec added a subscriber: zec.

INLINE COMMENTS
  sys/netpfil/pf/pf.c:1384 *v could be marked as __unused
  sys/netpfil/pf/pf_ioctl.c:282 Passing curvnet as an argument here is 
redundant now.

REVISION DETAIL
  https://reviews.freebsd.org/D1315

To: rodrigc, bz, glebius, trociny, np, melifaro, hrs, wollman, bryanv, rpaulo, 
adrian, gnn, hiren, rwatson
Cc: zec, freebsd-virtualization, freebsd-pf, freebsd-net
___
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"

[Differential] [Commented On] D1309: VIMAGE PF fixes #1

[zec (Marko Zec)]

zec added inline comments.

INLINE COMMENTS
  sys/netpfil/pf/pf_ioctl.c:3804 Perhaps SI_ORDER_MIDDLE could work here 
instead of (SI_ORDER_ANY - 255)?

REVISION DETAIL
  https://reviews.freebsd.org/D1309

To: rodrigc, bz, glebius, np, melifaro, hrs, wollman, bryanv, rpaulo, adrian, 
gnn, hiren, rwatson, trociny, zec
Cc: freebsd-virtualization, freebsd-pf, freebsd-net
___
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"

[Differential] [Updated] D1944: PF and VIMAGE fixes

[zec (Marko Zec)]

zec added a comment.

In https://reviews.freebsd.org/D1944#62124, @robak wrote:

> I managed to crash freshly fetched and built 10-S today, with 
> GENERIC+VIMAGE+RACCT while stopping a jail, attaching console screenshots.
>
> F183647: Screen Shot 2015-07-19 at 17.48.26.png 
> 
>
> F183649: Screen Shot 2015-07-19 at 18.33.39.png 
> 


Those are just warning messages unrelated to the patchset discussed here, i.e. 
if your kernel really crashed, the attached screenshots do not reveal the 
culprit.


REVISION DETAIL
  https://reviews.freebsd.org/D1944

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: nvass-gmx.com, bz, trociny, kristof, gnn, glebius, rodrigc, zec
Cc: julian, robak, freebsd-virtualization-list, freebsd-pf-list, 
freebsd-net-list
___
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"