All these natural aphrodisiacs are great fun and so on, but do they help to
improve potency?
All your problems with sexual activity and performance can be easily solved
if you are ready for it.
http://x.co/8JGqK
___
dev mailing list
On Thu, Apr 02, 2015 at 04:38:13PM +, Kavanagh, Mark B wrote:
On 04/01/15 at 07:45am, Kavanagh, Mark B wrote:
What's wrong with setting CFLAGS on the configure or make command
line? This is the standard way to do this with Automake and Autoconf.
Sure. However, setting CFLAGS on
Eitan,
I see what you mean. You are right. I will provide a v2 patch to address your
point.
Thanks,
Sorin
-Original Message-
From: Eitan Eliahu [mailto:elia...@vmware.com]
Sent: Friday, 3 April, 2015 02:11
To: Sorin Vinturis; dev@openvswitch.org
Subject: RE: [PATCH] datapath-windows:
America's best doctors have met to decide the problems of male impotence!
Are you satisfied with your penis size and thickness? If not it's time to
change it!
http://x.co/8JGnh
___
dev mailing list
dev@openvswitch.org
On Fri, Apr 03, 2015 at 10:02:16PM +0800, Kevin Lo wrote:
I'm attempting to install ovs 2.3.1 on FreeBSD and it appears to be broken
after the commit 666afb55e84e9118812de81a75655ec9567b7a5b.
Since FreeBSD uses two short integers to represent interface flags,
we have to apply mask 0x to
On Fri, Apr 03, 2015 at 08:16:18AM -0700, Ben Pfaff wrote:
On Fri, Apr 03, 2015 at 10:02:16PM +0800, Kevin Lo wrote:
I'm attempting to install ovs 2.3.1 on FreeBSD and it appears to be broken
after the commit 666afb55e84e9118812de81a75655ec9567b7a5b.
Since FreeBSD uses two short integers
On Sat, Apr 04, 2015 at 12:10:30AM +0800, Kevin Lo wrote:
On Fri, Apr 03, 2015 at 08:16:18AM -0700, Ben Pfaff wrote:
On Fri, Apr 03, 2015 at 10:02:16PM +0800, Kevin Lo wrote:
I'm attempting to install ovs 2.3.1 on FreeBSD and it appears to be broken
after the commit
On 3 April 2015 at 13:46, Ben Pfaff b...@nicira.com wrote:
Also, the commit you name was in 2013, and we've had other
contributions from FreeBSD contributors since then
(namely Ed Maste ema...@freebsd.org) and it seems like he
would have noticed if it were totally busted.
You mean this
The current gdb support launches gdb but doesn't start the daemon.
If you start ovsdb-server with gdb, ovs-sandbox produces an error as
it tries to run ovs-vsctl before ovsdb-server is running. Telling gdb
to start the daemon immediately avoids this error.
There are cases where it's useful to go
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
I tried everything to get in shape
Your overall health with improve once you have this.
http://x.co/8jbZ9
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
OVS userspace can work with the OVS kernel module distributed with the
kernel. This provides a straightforward workaround.
I don't understand the comment about updating the FAQ/NEWS version
matrix. It already states that 2.3 supports Linux 2.6.32 to 3.14, and
explicitly mentions that modified
On Fri, Apr 03, 2015 at 12:46:45PM -0700, Joe Stringer wrote:
OVS userspace can work with the OVS kernel module distributed with the
kernel. This provides a straightforward workaround.
I don't understand the comment about updating the FAQ/NEWS version
matrix. It already states that 2.3
Lately our internal build system has been seeing intermittent failures that
I can't explain. With old glibc versions, the configure time check will
pass, but the equivalent (almost identical) make check test will fail.
One possibility, I guess, is that occasionally address space randomization
On Wed, Apr 1, 2015 at 10:14 PM, Neil McKee neil.mc...@inmon.com wrote:
I've been looking at filling in the sFlow structures to report on tunnel
encap and other transformations. sFlow sampling is best done on ingress
only, so I can't use the egress-sampling action that the IPFIX
On Fri, Apr 03, 2015 at 02:46:11PM -0400, Ed Maste wrote:
On 3 April 2015 at 13:46, Ben Pfaff b...@nicira.com wrote:
Also, the commit you name was in 2013, and we've had other
contributions from FreeBSD contributors since then
(namely Ed Maste ema...@freebsd.org) and it seems like he
Makes popping each member of the list a bit easier.
Signed-off-by: Jarno Rajahalme jrajaha...@nicira.com
---
lib/dp-packet.c |5 ++---
lib/list.h |6 ++
lib/lldp/lldpd-structs.c |5 ++---
lib/lldp/lldpd.c |5 ++---
Thx for fixing this !!!~
Acked-by: Alex Wang al...@nicira.com
On Fri, Apr 3, 2015 at 3:11 PM, Ben Pfaff b...@nicira.com wrote:
Lately our internal build system has been seeing intermittent failures that
I can't explain. With old glibc versions, the configure time check will
pass, but the
Missed this the first time around for some reason. Minor comments inline.
On 1 April 2015 at 22:14, Neil McKee neil.mc...@inmon.com wrote:
1) We can use the concurrent hash-map of flows that the revalidator
threads are sharing. The upcall knows the 128-bit ufid for the flow, so
we can get
I'm really happy that you found a solution! (Even though we don't know
the root cause.) Thank you.
Please credit Alex as the reporter. He raised this issue with me, and I
just passed it along.
Acked-by: Ben Pfaff b...@nicira.com
Oink. This patch does not fix the problem, so I will not
On 04/03/2015 06:55 PM, Jarno Rajahalme wrote:
Makes popping each member of the list a bit easier.
Signed-off-by: Jarno Rajahalme jrajaha...@nicira.com
Nice improvement! The changes look good to me. I think one bonus
improvement would be to add a test case to tests/test-list.c.
Acked-by:
The message was undeliverable due to the following reason:
Your message was not delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there
Thanks, applied to master and branch-2.3.
On Fri, Apr 03, 2015 at 04:15:01PM -0700, Alex Wang wrote:
Thx for fixing this !!!~
Acked-by: Alex Wang al...@nicira.com
On Fri, Apr 3, 2015 at 3:11 PM, Ben Pfaff b...@nicira.com wrote:
Lately our internal build system has been seeing
On Fri, Apr 03, 2015 at 06:32:36PM -0700, Gurucharan Shetty wrote:
It has been seen recently that the unit tests hang sometimes
while run on Windows. This happens when the OVS daemons don't
get killed after the test finishes. In my reproduction case,
when we use the taskkill command to
Ben,
By certification I meant any pre-release testing that you must be doing
before releasing a new version of ovs, nothing beyond that.. Its fair to
assume that this would be the starting point for many who are using
this software. That is, go ahead and grab the latest released version. Its
Well, the last released version of ovs-2.3.1 was in Dec/03/2014 (per NEWS)
and there is no formal plan discussed about ovs-2.4 in any of the mailing
lists. I see there is ovs-2.3.2 documented in NEWS with xxx suggesting there
will be a release sometime in future. Unless there is a certified
I recommend building a kernel module from master.
New features, such as support for new kernels, are always added on
master first. Periodically we branch to a release branch, and then
release that branch after allowing some time to report and fix bugs.
We do not certify any version of OVS for
It has been seen recently that the unit tests hang sometimes
while run on Windows. This happens when the OVS daemons don't
get killed after the test finishes. In my reproduction case,
when we use the taskkill command to forcefully kill the
process, the following happens:
$ taskkill //f //PID 1728
Although the little blue pill has made many a man happy, there are new drugs
on the market.
American society proves the efficiency of our male enhancement products!
http://x.co/8JGZV
___
dev mailing list
dev@openvswitch.org
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Hi,
I'm attempting to install ovs 2.3.1 on FreeBSD and it appears to be broken
after the commit 666afb55e84e9118812de81a75655ec9567b7a5b.
Since FreeBSD uses two short integers to represent interface flags,
we have to apply mask 0x to flags.
Signed-off-by: Kevin Lo ke...@freebsd.org
---
The BSOD occurred because the FilterAttach routine released the switch
context, while there were IRPs in processing.
The solution was to add a reference count to prevent premature deallocation of
the
global switch context structure, gOvsSwitchContext.
Signed-off-by: Sorin Vinturis
32 matches
Mail list logo
