https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711
--- Comment #5 from eu...@grosbein.net ---
(In reply to Hiren Panchasara from comment #4)
This PR is probably duplicate of my later PR 149513 that contains more details.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711
--- Comment #6 from eu...@grosbein.net ---
(In reply to Hiren Panchasara from comment #4)
This PR is probably duplicate of my later PR *195102* that contains more
details.
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711
Andrey V. Elsukov changed:
What|Removed |Added
CC||a...@freebsd.org
--- Comment #
On 03/27/15 at 10:33P, hiren panchasara wrote:
> + jfv, erj from Intel.
>
> On 03/26/15 at 01:08P, hiren panchasara wrote:
> > This is what we are seeing on em(4) 82574L chipset running stable/10:
> >
> > dev.em.0.mac_stats.missed_packets: 1441927
> > dev.em.0.interrupts.rx_overrun: 153
> >
> >
nvass-gmx.com added a comment.
>>! In D1944#11, @kristof wrote:
> Don't we still need to do all of this somewhere?
>>! In D1944#11, @kristof wrote:
> Don't we still need to do all of this somewhere?
INLINE COMMENTS
sys/netpfil/pf/pf_ioctl.c:325 pf_unload is called before pf_vnet_unit, this
Currently tap(4) device gets to 'down' state when the last process
closes it, regardless of the original 'up/down' state.
Will it be reasonable to modify this behavior and keep this bit
'was_up_before_open', and leave it 'up' if it was 'up' when it was first
opened?
Practically speaking, I set
Yeah, I think the right thing to do is:
* If the descriptor says it's RSS, then use the flowid + rss type
* else, set it to queue id and set the type to opaque.
-a
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freeb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711
--- Comment #4 from Hiren Panchasara ---
(In reply to dblais from comment #2)
I cannot look into this right now but noticed that what you are reporting looks
different than the original post. That seems double free and what you are
seeing i
On 03/30/15 at 10:53P, Adrian Chadd wrote:
> No, you're absolutely right. However, you (a) get flowid for L3/L4
> V4/v6 but not other things, and (b) I was worried about changing the
> default behaviour of the driver, and who knows what other weird crap
> people may have done to their local driver.
Hi!
Could someone take a look at this please?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711
We have the same bug and it's clearly more important and serious than
previously tought.
___
freebsd-net@freebsd.org mailing list
http://li
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711
--- Comment #3 from dbl...@interplex.ca ---
Sorry, some errors in my previous post:
"Don't know how it scales exactly (linear, quadratic or exponential) nor if it
scales with traffic or the amount of pppoe clients but it sure if one of the
I have a problem with carp too on FreeBSD 10.1 servers and posted a
question but it seems to be more related to firmware network card.
However your problem seems simplier as I had the same :
If tcpdump reveals vrrp packets between servers and they are stuck in
INIT state, try this workaround :
Si
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=171711
dbl...@interplex.ca changed:
What|Removed |Added
CC||dbl...@interplex.ca
--- Comme
Hi,
I have CARP set up on two pairs of firewalls running OpenBSD directly
on metal. It works like a charm for almost 3 years now. Failover is
almost instant when shutting down master node.
I am trying to implement CARP on a pair of FreeBSD 10.1 servers running
on top of VMWare ESXi 5.5U2, but so
14 matches
Mail list logo
