00% CPU, I
strongly suggest to switch to mpd5 (which use < 1% CPU on the same
hardware)
> I have also found some mentions of net/mpd5, is this a better
> implementation?
>
yes! mpd5 is almost mandatory nowadays for PPPOE
>
>
> Thanks
>
> Dries
>
--
Julien Cig
On Mon, Nov 09, 2020 at 05:55:05PM -0800, John-Mark Gurney wrote:
> Julien Cigar wrote this message on Mon, Nov 09, 2020 at 15:33 +0100:
> > Hello,
> >
> > I've setup a VNET jail (with epair and bridge) with a floating ip (vhid)
> > on the "b" side of t
with epair?
Thanks,
Julien
--
Julien Cigar
Belgian Biodiversity Platform (http://www.biodiversity.be)
PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0
No trees were killed in the creation of this message.
However, many electrons were ter
On Tue, Sep 01, 2020 at 10:13:23AM +0200, Julien Cigar wrote:
> On Mon, Aug 31, 2020 at 01:55:52PM +0200, Michael Gmelin wrote:
> >
> >
> > > On 31. Aug 2020, at 10:37, Julien Cigar wrote:
> > >
> > > On Fri, Aug 28, 2020 at 04:52:01PM +0200, Julien C
On Mon, Aug 31, 2020 at 01:55:52PM +0200, Michael Gmelin wrote:
>
>
> > On 31. Aug 2020, at 10:37, Julien Cigar wrote:
> >
> > On Fri, Aug 28, 2020 at 04:52:01PM +0200, Julien Cigar wrote:
> >> Hello,
> >>
> >> I have a "highly availabl
On Fri, Aug 28, 2020 at 04:52:01PM +0200, Julien Cigar wrote:
> Hello,
>
> I have a "highly available" router/firewall with the following
> configuration (1). Those are plugged in two 2930F (with VSF) using LACP.
> It works well, except that I have some weird issues
g a slower master)
I guess this is because it takes some time for lagg/lacp to converge and
thus carp thinks that there is a problematic condition as it experiences
problems with sending announcements..
What it the best way to handle this?
Thanks,
Julien
(1) https://gis
On Wed, Oct 09, 2019 at 12:50:49PM -0700, Julian Elischer wrote:
> On 10/9/19 2:34 AM, Julien Cigar wrote:
> > On Tue, Oct 08, 2019 at 01:05:37PM -0700, Julian Elischer wrote:
> >> On 10/8/19 8:58 AM, Julien Cigar wrote:
> >>> On Tue, Oct 08, 2019 at 10:20:34
On Wed, Oct 09, 2019 at 01:41:40PM -0500, Matthew Grooms wrote:
> On 10/9/2019 4:10 AM, Julien Cigar wrote:
> > On Tue, Oct 08, 2019 at 11:22:51AM -0500, Matthew Grooms wrote:
> >> On 10/8/2019 10:58 AM, Julien Cigar wrote:
> >>> On Tue, Oct 08, 2019 at 10:20:34
On Tue, Oct 08, 2019 at 01:05:37PM -0700, Julian Elischer wrote:
> On 10/8/19 8:58 AM, Julien Cigar wrote:
> > On Tue, Oct 08, 2019 at 10:20:34AM -0500, Matthew Grooms wrote:
> >> Hi Julien,
> > Hi Matthew,
> >
> >> It's not clear why you are trying to
On Tue, Oct 08, 2019 at 11:22:51AM -0500, Matthew Grooms wrote:
> On 10/8/2019 10:58 AM, Julien Cigar wrote:
> > On Tue, Oct 08, 2019 at 10:20:34AM -0500, Matthew Grooms wrote:
> >> Hi Julien,
> > Hi Matthew,
> >
> >> It's not clear why you are trying to
On Tue, Oct 08, 2019 at 10:20:34AM -0500, Matthew Grooms wrote:
> Hi Julien,
Hi Matthew,
>
> It's not clear why you are trying to assign multiple carp IP address to
> two different interfaces from within the same IP subnet. Are you trying
> to fail over a 2nd carp address
h the following: (1) which works well, but all traffic
goes through the same interface.
So I'd like to switch to something like (2), which will not work (lines
5 and 13 are not valid) and I'm wondering if I could use something like
(3) ..?
Thank you!
Julien
(1) https://gist.gith
Hi Ben,
On 8/31/17 12:04 PM, Ben RUBSON wrote:
>> On 28 Aug 2017, at 11:27, Julien Charbon wrote:
>>
>> On 8/28/17 10:25 AM, Ben RUBSON wrote:
>>>> On 16 Aug 2017, at 11:02, Ben RUBSON wrote:
>>>>
>>>>> On 15 Aug 2017, at 23:33, Ju
Hi Ben,
On 8/28/17 10:25 AM, Ben RUBSON wrote:
>> On 16 Aug 2017, at 11:02, Ben RUBSON wrote:
>>
>>> On 15 Aug 2017, at 23:33, Julien Charbon wrote:
>>>
>>> On 8/11/17 11:32 AM, Ben RUBSON wrote:
>>>>> On 08 Aug 2017, at 13:33, Julie
Hi Ben,
On 8/11/17 11:32 AM, Ben RUBSON wrote:
>> On 08 Aug 2017, at 13:33, Julien Charbon wrote:
>>
>> On 8/8/17 10:31 AM, Hans Petter Selasky wrote:
>>>
>>> Suggested fix attached.
>>
>> I agree we your conclusion. Just for the record, more
or 1) still helding extra reference
on it.
The thread tries to do smth with a disconnected pcb and crashes.
Submitted by: emeric.pou...@stormshield.eu
Reviewed by:gleb@
MFC after: 1 week
Sponsored by: Stormshield
Tested by: Cassiano Peixoto, Stormshield
Notes:
M, running 10.3. Problem usually happens
within 30 days with 9k jumbo clusters allocation failure.
>
> --
> WBR, Andrey V. Elsukov
>
--
Julien Cigar
Belgian Biodiversity Platform (http://www.biodiversity.be)
PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23
On Mon, Feb 27, 2017 at 03:37:14PM -0800, Freddie Cash wrote:
> On Mon, Feb 27, 2017 at 3:16 PM, Julien Cigar wrote:
>
>
> > I wondered if it is possible to use CARP with VLAN interfaces?
> >
>
> Yes, CARP-over-vLAN works well. Used just such a setup at work for a
8.1.253/24"
ifconfig_em0_netb="inet 10.209.1.253/24"
ifconfig_em0_neta_alias0="inet vhid 3 advskew 10 pass xx alias 192.168.2.254/32"
ifconfig_em0_netb_alias0="inet vhid 4 advskew 10 pass xx alias 10.209.1.254/32"
===
Thanks!
Julien
--
Julie
s/FreeBSD/commit/3a52df429889ea9c6e61013f6913aad95939f159
>
> The current 'solisten' branch at https://github.com/glebius/FreeBSD has
> been running successfully for 48 hours at Netflix. But as mentioned before,
> our connection rate is pretty low.
>
> So, testi
On Tue, Feb 14, 2017 at 09:03:00AM -0800, Freddie Cash wrote:
> On Tue, Feb 14, 2017 at 7:41 AM, Julien Cigar wrote:
>
> > Hello,
> >
> > I have a redundant router/firewall with CARP and PF/PFSync with the
> > following configuration (simplified for ex
):
ifconfig_em3="inet 192.168.88.2 netmask 255.255.255.0 -tso"
ifconfig_em3_alias0="vhid 53 advskew 100 pass xx alias 1.2.208.90/32"
(assuming that the switch is configured properly)
- as the state table is synced between FW1 and FW2, is it possible to
do some load-balancing on the
to look at potential race conditions related to
ACCEPT_LOCK and SO_ACCEPTFILTER usage (even if I am more used to
INP_INFO lock), but I can certainly provide performance numbers and lock
contention metrics using our setup.
Do you think it is the right time to start performance testing with
your change? Or it is a bit premature?
--
Julien
signature.asc
Description: OpenPGP digital signature
goto fail;
> >
> > -Meny
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
--
Julien Cigar
Belgian Biodiversity Platform (http://www.biodiversity.be)
PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0
No trees were killed in the creation of this message.
However, many electrons were terribly inconvenienced.
signature.asc
Description: PGP signature
Hi,
On 7/14/16 7:38 PM, Julien Charbon wrote:
> On 6/28/16 12:06 PM, Julien Charbon wrote:
>> On 12/7/15 4:36 PM, Julien Charbon wrote:
>>> On 30/05/14 06:12, k simon wrote:
>>>> Does any plan commit and MFC to the 10-stable ?
>>>
>>> I
Hi,
On 7/14/16 11:02 PM, Larry Rosenman wrote:
> On 2016-07-14 12:01, Julien Charbon wrote:
>> On 6/20/16 11:55 AM, Julien Charbon wrote:
>>> On 6/20/16 9:39 AM, Gleb Smirnoff wrote:
>>>> On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
>>>
Hi,
On 6/20/16 11:55 AM, Julien Charbon wrote:
> On 6/20/16 9:39 AM, Gleb Smirnoff wrote:
>> On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
>> J> > Comparing stable/10 and head, I see two changes that could
>> J> > affect that:
>> J
Hi,
On 6/28/16 12:06 PM, Julien Charbon wrote:
> On 12/7/15 4:36 PM, Julien Charbon wrote:
>> On 30/05/14 06:12, k simon wrote:
>>> Does any plan commit and MFC to the 10-stable ?
>>
>> I got a bit of interest of having the performance improvements for
>&g
Hi -net,
On 12/7/15 4:36 PM, Julien Charbon wrote:
> On 30/05/14 06:12, k simon wrote:
>> Does any plan commit and MFC to the 10-stable ?
>
> I got a bit of interest of having the performance improvements for
> short-lived TCP connections in 10-stable. Just to share the c
his solution is also step backward in modernization of TCP
timers/callout...
https://svnweb.freebsd.org/base/stable/10/sys/netinet/tcp_timer.c?r1=284261&r2=284260&pathrev=284261
Hopefully my description is clear enough...
--
Julien
signature.asc
Description: OpenPGP digital signature
Hi,
On 6/20/16 11:58 AM, Gleb Smirnoff wrote:
> On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote:
> J> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
> J> > J> > Comparing stable/10 and head, I see two changes that could
> J> >
ed list. As soon as RCU (or anything
equivalent like lwref) are supported in kernel, we will implement this
change.
Just history here, as I already did a presentation on this exact topic
at BSDCan 2015:
https://wiki.freebsd.org/201506DevSummit#line-83
It was recorded but I never saw the footage/presentation actually
published. :)
--
Julien
signature.asc
Description: OpenPGP digital signature
Hi,
On 6/20/16 9:39 AM, Gleb Smirnoff wrote:
> On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
> J> > Comparing stable/10 and head, I see two changes that could
> J> > affect that:
> J> >
> J> > - callout_async_drain
> J> > - sw
a use after free, which conflicts with new allocation.
>
> Comparing stable/10 and head, I see two changes that could
> affect that:
>
> - callout_async_drain
> - switch to READ lock for inp info in tcp timers
>
> That's why you are in To, Julien and Hans :)
>
&g
ese changes also improve
performances (in top of our specific DNS over TCP traffic) before
starting to MFC in 10-stable.
- Currently all (few) concerned users I am aware of are happily using
11-CURRENT.
Of course, all these improvements will be available by default in
11.0.0 anyway.
--
Jul
Hi Hiren,
On 26/09/15 00:46, hiren panchasara wrote:
> On 09/25/15 at 09:42P, John Baldwin wrote:
>> On Thursday, September 24, 2015 02:13:24 PM Julien Charbon wrote:
>>> So the issue is:
>>>
>>> - tcp_close() is called for some reasons with an inp in
Hi John,
On 25/09/15 18:42, John Baldwin wrote:
> On Thursday, September 24, 2015 02:13:24 PM Julien Charbon wrote:
>> So the issue is:
>>
>> - tcp_close() is called for some reasons with an inp in INP_TIMEWAIT
>> state and sets the INP_DROPPED flag,
>> - tcp
tely impossible but unlikely. That said you can add your own
information to this old (July 2010) but still relevant bug report:
[panic] 8.1-RELEASE/10.1-STABLE "panic: sbdrop" and "panic: sbsndptr:
sockbuf _ and mbuf _ clashing"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807
My 2 cents.
--
Julien
signature.asc
Description: OpenPGP digital signature
Hi Palle,
On 25/09/15 16:14, Palle Girgensohn wrote:
>> 24 sep 2015 kl. 11:39 skrev Palle Girgensohn :
>>> 24 sep 2015 kl. 09:57 skrev Julien Charbon : On
>>> 24/09/15 09:03, Julien Charbon wrote:
>>>> On 24/09/15 08:55, Palle Girgensohn wrote:
>
Hi -net,
On 23/09/15 16:47, Julien Charbon wrote:
> Thanks to Palle, I got access to the kernel dump. And the results is
> more interesting than expected: Thus somehow the kernel reaches a state
> in tcp_detach() where:
>
> INP_TIMEWAIT && INP_DROPPED &&a
Hi -net,
On 24/09/15 09:03, Julien Charbon wrote:
> On 24/09/15 08:55, Palle Girgensohn wrote:
>>> 24 sep 2015 kl. 07:51 skrev Palle Girgensohn
>>> :
>>>> 24 sep 2015 kl. 00:05 skrev Palle Girgensohn
>>>> :
>>>>> 23 sep 2015 kl.
Hi Palle,
On 24/09/15 08:55, Palle Girgensohn wrote:
>> 24 sep 2015 kl. 07:51 skrev Palle Girgensohn
>> :
>>> 24 sep 2015 kl. 00:05 skrev Palle Girgensohn
>>> :
>>>> 23 sep 2015 kl. 20:32 skrev Julien Charbon :
>>>> On 23/09/15 20:26, Palle
Hi,
On 23/09/15 20:26, Palle Girgensohn wrote:
>> 23 sep. 2015 kl. 20:01 skrev Julien Charbon :
>> On 23/09/15 16:36, Palle Girgensohn wrote:
>>>> 22 sep 2015 kl. 23:59 skrev Julien Charbon : On
>>>> 22/09/15 22:58, Palle Girgensohn wrote:
>>>&
Hi Palle, Hi George,
On 23/09/15 16:36, Palle Girgensohn wrote:
>> 22 sep 2015 kl. 23:59 skrev Julien Charbon : On
>> 22/09/15 22:58, Palle Girgensohn wrote:
>>>> 22 sep 2015 kl. 20:16 skrev Julien Charbon :
>>>> On 22/09/15 18:49, Palle Girgensohn wrote
Hi -net,
On 22/09/15 23:59, Julien Charbon wrote:
> On 22/09/15 22:58, Palle Girgensohn wrote:
>>> 22 sep 2015 kl. 20:16 skrev Julien Charbon :
>>> On 22/09/15 18:49, Palle Girgensohn wrote:
>>>>> 22 sep 2015 kl. 18:46 skrev Palle Girgensohn
>>>
Hi Palle,
On 22/09/15 22:58, Palle Girgensohn wrote:
>> 22 sep 2015 kl. 20:16 skrev Julien Charbon :
>> On 22/09/15 18:49, Palle Girgensohn wrote:
>>>> 22 sep 2015 kl. 18:46 skrev Palle Girgensohn
>>>> :
>>>>> 21 sep 2015 kl. 15:53 skrev Pal
Hi Palle,
On 22/09/15 18:49, Palle Girgensohn wrote:
>> 22 sep 2015 kl. 18:46 skrev Palle Girgensohn
>> :
>>> 21 sep 2015 kl. 15:53 skrev Palle Girgensohn
>>> :
>>>> 21 sep 2015 kl. 10:21 skrev Julien Charbon
>>>> : On 18/09/15 18:06, Kons
Hi Palle,
On 18/09/15 22:42, Palle Girgensohn wrote:
>> 18 sep 2015 kl. 18:06 skrev Konstantin Belousov
>> :
>>
>>> On Fri, Sep 18, 2015 at 03:56:25PM +0200, Julien Charbon wrote:
>>> Hi Palle,
>>>
>>>> On 18/09/15 11:12, Palle Gir
Hi Konstantin, Hi Palle,
On 18/09/15 18:06, Konstantin Belousov wrote:
> On Fri, Sep 18, 2015 at 03:56:25PM +0200, Julien Charbon wrote:
>> Hi Palle,
>>
>> On 18/09/15 11:12, Palle Girgensohn wrote:
>>> We see daily panics on our production systems (web server
I won't go to far here as I am not expert enough in VIMAGE, but one
question anyway:
- Can you correlate this kernel panic to a particular event? Like for
example a VIMAGE/VNET jail destruction.
I will test that on my side on a 10.2 machine.
--
Julien
signature.asc
Description: OpenPGP digital signature
On 20/05/15 16:57, Adrian Chadd wrote:
> On 20 May 2015 at 06:27, Julien Charbon wrote:
>> On 26/05/14 15:36, Julien Charbon wrote:
>> [...]
>>
>> For people interested about this short-lived TCP connection scalability
>> effort, you can subscribe to the rev
Hi,
On 26/05/14 15:36, Julien Charbon wrote:
> On 23/05/14 23:37, Navdeep Parhar wrote:
>> On 05/23/14 13:52, Julien Charbon wrote:
>>> On 23/05/14 14:06, Julien Charbon wrote:
>>>> On 27/02/14 11:32, Julien Charbon wrote:
>>>>> On 07/11/13 14:55
Hi,
On 05/05/15 18:15, Julien Charbon wrote:
> I was asked if it is possible to MFC r281599 in FreeBSD 10:
>
> ---
> Fix an old and well-documented use-after-free race condition in
> TCP timers:
> - Add a reference from tcpcb to its inpcb
> - Defer tcpcb deletion
ease scream.
Without nice yelps I plan to "MFC after: 1 month" (around May 16th).
Thanks.
--
Julien
signature.asc
Description: OpenPGP digital signature
" (around May 16th).
Thanks.
--
Julien
signature.asc
Description: OpenPGP digital signature
jch added a subscriber: jch.
REVISION DETAIL
https://reviews.freebsd.org/D1438
To: hselasky, jhb, adrian, markj, emaste, sbruno, imp, lstewart, rwatson, gnn,
rrs, kostikbel, delphij, neel, erj, mat, remkolodder, bcr, brueffer, brd,
allanjude, wblock
Cc: jch, wblock, freebsd-net
__
did manage to reproduce it at one stage, and
>>> left the counter in to see if we could spot it in production, and
>>> I have had (multiple) reports of it in deployed systems. I'm not
>>> sure it's worth trying to reproduce them, given that knowledge --
>>&g
jch accepted this revision.
This revision is now accepted and ready to land.
REVISION DETAIL
https://reviews.freebsd.org/D1982
To: harrison.grundy-astrodoggroup.com, gnn, adrian, glebius, jch
Cc: glebius, freebsd-net
___
freebsd-net@freebsd.org mailin
jch accepted this revision.
This revision is now accepted and ready to land.
REVISION DETAIL
https://reviews.freebsd.org/D1982
To: harrison.grundy-astrodoggroup.com, gnn, adrian, jch
Cc: freebsd-net
___
freebsd-net@freebsd.org mailing list
http://list
Hi,
On 03/11/14 14:29, Julien Charbon wrote:
> On 03/10/14 15:16, Julien Charbon wrote:
>> On 23/05/14 14:06, Julien Charbon wrote:
>>> On 27/02/14 11:32, Julien Charbon wrote:
>>>> On 07/11/13 14:55, Julien Charbon wrote:
>>>>> On Mon, 04 Nov 201
Hi,
On 03/10/14 15:16, Julien Charbon wrote:
> On 23/05/14 14:06, Julien Charbon wrote:
>> On 27/02/14 11:32, Julien Charbon wrote:
>>> On 07/11/13 14:55, Julien Charbon wrote:
>>>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
>>>> wrote:
&g
bes
^C
CPU IDFUNCTION:NAME
3 2 :END
sendit ENOBUFS:
ixgbe_mq_start ENOBUFS:
ip_output Errors:
Thus 0 ENOBUFS errors. I will let Marc review this fix further to
check his full wrap case.
Thanks.
--
Julien
signature.asc
Description: OpenPGP digital signature
On Fri, Oct 03, 2014 at 10:31:56AM -0700, hiren panchasara wrote:
> On Fri, Oct 3, 2014 at 1:01 AM, Julien Cigar wrote:
> > On Thu, Oct 02, 2014 at 04:36:49PM -0700, hiren panchasara wrote:
> >> On Thu, Oct 2, 2014 at 11:19 AM, Julien Cigar wrote:
> >> > On Thu, Oc
Hi,
On 23/05/14 14:06, Julien Charbon wrote:
> On 27/02/14 11:32, Julien Charbon wrote:
>> On 07/11/13 14:55, Julien Charbon wrote:
>>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
>>> wrote:
>>>> I have put technical and how-to-repeat details
On Thu, Oct 02, 2014 at 04:36:49PM -0700, hiren panchasara wrote:
> On Thu, Oct 2, 2014 at 11:19 AM, Julien Cigar wrote:
> > On Thu, Oct 02, 2014 at 10:24:13AM -0700, hiren panchasara wrote:
> >> On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wrote:
> >> > sorry for
On Thu, Oct 02, 2014 at 01:21:32PM -0400, Brandon Allbery wrote:
> On Thu, Oct 2, 2014 at 12:42 PM, Julien Cigar wrote:
>
> > sonewconn: pcb 0xf8010e561310: Listen queue overflow: 8 already in
> > queue awaiting acceptance
> >
>
> My immediate reaction i
On Thu, Oct 02, 2014 at 10:24:13AM -0700, hiren panchasara wrote:
> On Thu, Oct 2, 2014 at 9:42 AM, Julien Cigar wrote:
> > sorry for cross-posting, I'm forwarding this as it seems that part of
> > the problem is also related to:
> > https://lists.freebsd.org/pipermail/
scribed on freebsd-net@ an
freebsd-stable@)
--
Julien Cigar
Belgian Biodiversity Platform (http://www.biodiversity.be)
PGP fingerprint: EEF9 F697 4B68 D275 7B11 6A25 B2BB 3710 A204 23C0
No trees were killed in the creation of this message.
However, many electrons were terribly inconvenienced.
--- Beg
oth INP_INFO_WLOCK and INP_WLOCK from race
conditions, I am currently checking if something could inadvertently
overwrite tw_cred in struct tcptw.
My 2 cents.
--
Julien
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fr
accelerate the commit process.
--
Julien
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Hi,
On 23/05/14 22:52, Julien Charbon wrote:
On 23/05/14 14:06, Julien Charbon wrote:
On 27/02/14 11:32, Julien Charbon wrote:
On 07/11/13 14:55, Julien Charbon wrote:
On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
wrote:
I have put technical and how-to-repeat details in below PR
Hi Navdeep
On 23/05/14 23:37, Navdeep Parhar wrote:
On 05/23/14 13:52, Julien Charbon wrote:
On 23/05/14 14:06, Julien Charbon wrote:
On 27/02/14 11:32, Julien Charbon wrote:
On 07/11/13 14:55, Julien Charbon wrote:
On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
wrote:
I have put
Hi,
On 27/02/14 11:32, Julien Charbon wrote:
On 07/11/13 14:55, Julien Charbon wrote:
On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
wrote:
I have put technical and how-to-repeat details in below PR:
kern/183659: TCP stack lock contention with short-lived connections
http
case that just drives the same stacktrace than
the race condition we found.
--
Julien
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
t
addresses and calling:
if_detach() -> if_detach_internal() -> if_purgemaddrs() -> if_delmulti_locked()
-> if_freemulti()
However, we did not find a way to fix it without unwanted side effects and we
asked for comments/ideas.
--
Julien
___
The following reply was made to PR kern/183659; it has been noted by GNATS.
From: "Charbon, Julien"
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/183659: [tcp] ]TCP stack lock contention with short-lived
connections
Date: Mon, 17 Mar 2014 17:39:19 +0100
Just a follow-up th
The following reply was made to PR kern/183659; it has been noted by GNATS.
From: "Charbon, Julien"
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/183659: [tcp] TCP stack lock contention with short-lived
connections
Date: Mon, 17 Mar 2014 15:54:03 +0100
Just a follow-up th
Hi John,
On 07/03/14 13:43, Julien Charbon wrote:
On 06/03/14 22:57, John-Mark Gurney wrote:
Julien Charbon wrote this message on Thu, Feb 27, 2014 at 11:32 +0100:
[...]
Any thoughts on this particular behavior?
One thing that I noticed is that you now lock/unlock the tw and inp
lock a
Hi John,
On 06/03/14 22:57, John-Mark Gurney wrote:
Julien Charbon wrote this message on Thu, Feb 27, 2014 at 11:32 +0100:
[...]
Any thoughts on this particular behavior?
One thing that I noticed is that you now lock/unlock the tw and inp lock a
lot... Have you thought about grabing the
The following reply was made to PR kern/176446; it has been noted by GNATS.
From: "Charbon, Julien"
To: bug-follo...@freebsd.org, jchar...@verisign.com
Cc: John Baldwin
Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving
out-of-order
packet process and spuriou
The following reply was made to PR kern/176446; it has been noted by GNATS.
From: "Charbon, Julien"
To: Cc: bug-follo...@freebsd.org,
"De La Gueronniere, Marc"
Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving
out-of-order
packet process a
The following reply was made to PR kern/176446; it has been noted by GNATS.
From: "Charbon, Julien"
To: John Baldwin
Cc: bug-follo...@freebsd.org,
"De La Gueronniere, Marc"
Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving
out-of-order
The following reply was made to PR kern/176446; it has been noted by GNATS.
From: "Charbon, Julien"
To: John Baldwin
Cc: bug-follo...@freebsd.org,
"De La Gueronniere, Marc" ,
j...@freebsd.org
Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe d
The following reply was made to PR kern/176446; it has been noted by GNATS.
From: "Charbon, Julien"
To: freebsd-gnats-sub...@freebsd.org, freebsd-b...@freebsd.org
Cc: j...@freebsd.org, "De La Gueronniere, Marc"
Subject: Re: kern/176446: Concurrency in ixgbe driving out-of-o
The following reply was made to PR kern/122058; it has been noted by GNATS.
From: Julien <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:
Subject: Re: kern/122058: [em] [panic] Panic on em1: taskq
Date: Tue, 25 Mar 2008 18:33:18 +0100
Hello,
FYI, I filled a PR today
the routing table.
I hope it works for you and you have the MAC address of the destination but
still I find the behavior of the route command in this case strange.
Best regards,
Julien
- Message d'origine
De : John Hay <[EMAIL PROTECTED]>
À : freebsd-net@freebsd.org
Hi Asha,
you have many traffic generators in the benchmark ports directory
(http://www.freebsd.org/ports/benchmarks.html).
I do not know what you are looking for exactly, I was and am sometimes using
Iperf, which is a simple tcp/udp traffic generator supporting IPv4/6.
Best regards,
Julien
- Message transféré
De : Julien Abeillé <[EMAIL PROTECTED]>
À : [EMAIL PROTECTED]
Envoyé le : Lundi, 21 Août 2006, 12h05mn 49s
Objet : Re : Re : ipv6 in ipv6 tunnel with FreeBSD 4.11
Hi George, all,
I finally found the problem. net.inet6.ip6.gifhlim is set to 0 by default.
Ma
used for.
the problem is: when i ping or send any traffic from a::2 to c::1,
the FreeBSD machine adds an ipv6 header with b::1 as source, b::2 as
destination, but with hop count limit=0
Is my configuration ok?
Thanks a lot,
Julien
___
freebsd
I filled one a year ago, for the very same problem (encountered for two
years now). See Problem Report kern/80005 for more information. I
think that another user (Emmanuel Duros) tried to speak with Realtek on
that point, not sure if there is feedback on it though...
Sorr
>> I filled one a year ago, for the very same problem (encountered for two
>> years now). See Problem Report kern/80005 for more information. I
>> think that another user (Emmanuel Duros) tried to speak with Realtek on
>> that point, not sure if there is feedback on it though...
>>
>> Sorry not t
Hello Hans,
> I have a problem with my RTL8169 Gigabit NIC built into my (apparently
> very uncommon) Clevo D41EV laptop. At boot, when netif tries to set up the
> interface, I get a lot of these messages:
>
> > re0: 2 link states coalesced
> > re0: link state changed to DOWN
> > re0: 2 link st
On Sat, Jan 15, 2005 at 09:46:54PM -0500, Chuck Swiger wrote:
> Julien Lesaint wrote:
> >Quick reminder: in the case the route to the packet's source is not the
> >interface this packet arrived on, do we have a way to source ICMP errors
> >(ttl-exceeded) with the origi
roubleshooting, rather than for some cosmetic purposes.
Regards,
--
Julien Lesaint.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hi,
i have some questions regarding an ipsec tunnel
which i want to setup between to hosts (A, B),
but I want A and B to be in the same subnet.
what are the possiblilities?
also, i might meet the following situation:
a)
A 10.0.0.10 <==> ipsec_gw <==> routers <==> ipsec_gw <===> B 10.0.0.1
b)
A 1
96 matches
Mail list logo