Re: New CC modules not loading after Kernel recompilation

2015-05-21 Thread Karlis Laivins 
Hi,

Yes, the module builds fine and the variable is needed.

BR,
KL

On Thu, May 21, 2015 at 7:30 AM, hiren panchasara <
hi...@strugglingcoder.info> wrote:

> On 05/21/15 at 05:41P, Karlis Laivins wrote:
> > Good Morning,
> >
> > I have a following issue, maybe someone has encountered this and can
> > provide me with a quick solution to a following issue.
> >
> > I have compiled a module, which is a modified version of the NewReno
> > congestion control algorithm. I tried to load it into Kernel successfully
> > before I recompiled Kernel with a following config file, so I can use
> > Imunes and test the new module:
> >
> > include GENERIC
> > nooptions FLOWTABLE
> > options VIMAGE
> > options VNET_DEBUG
> > options MROUTING
> >
> > options IPSEC
> > device crypto
> > options IPSEC_DEBUG
> >
> > options DDB
> > options KDB
> >
> > The problem is - after the Kernel has been reompiled, I can no longer
> load
> > the module with kldload. The error I get is:
> >
> > link_elf: symbol tcp_do_rfc3465 undefined
> Does the module itself build fine? Do you need V_tcp_do_rfc3465 instead?
> It's a VNETified variable:  tcp_var.h:VNET_DECLARE(int, tcp_do_rfc3465);
>
> Just a guess.
>
> Cheers,
> Hiren
> > kldload: can't load cc_changedreno.ko: No such file or directory
> >
> > And this is despite the fact the cc_changedreno.ko module is in
> > /boot/kernel/.
> >
> > Thank you in advance!
> >
> > BR,
> > Karlis
> > ___
> > 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"
>
___
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"

Re: New CC modules not loading after Kernel recompilation

2015-05-21 Thread Karlis Laivins 
Hello,

Tried both, still the same issue...

BR,
KL

On Thu, May 21, 2015 at 7:30 AM, Adrian Chadd  wrote:

> Hi,
>
> Try kldxref /boot/kernel
>
> If it doesn't help, try recompiling the module.
>
>
> -a
>
>
> On 20 May 2015 at 19:41, Karlis Laivins  wrote:
> > Good Morning,
> >
> > I have a following issue, maybe someone has encountered this and can
> > provide me with a quick solution to a following issue.
> >
> > I have compiled a module, which is a modified version of the NewReno
> > congestion control algorithm. I tried to load it into Kernel successfully
> > before I recompiled Kernel with a following config file, so I can use
> > Imunes and test the new module:
> >
> > include GENERIC
> > nooptions FLOWTABLE
> > options VIMAGE
> > options VNET_DEBUG
> > options MROUTING
> >
> > options IPSEC
> > device crypto
> > options IPSEC_DEBUG
> >
> > options DDB
> > options KDB
> >
> > The problem is - after the Kernel has been reompiled, I can no longer
> load
> > the module with kldload. The error I get is:
> >
> > link_elf: symbol tcp_do_rfc3465 undefined
> > kldload: can't load cc_changedreno.ko: No such file or directory
> >
> > And this is despite the fact the cc_changedreno.ko module is in
> > /boot/kernel/.
> >
> > Thank you in advance!
> >
> > BR,
> > Karlis
> > ___
> > 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"
>
___
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"

[Differential] [Commented On] D1944: PF and VIMAGE fixes

2015-05-21 Thread nvass-gmx.com (Nikos Vassiliadis) 
nvass-gmx.com added a comment.

In https://reviews.freebsd.org/D1944#47915, @glebius wrote:

> Thanks a lot, Nikos.
>
> I've fixed the problem of sleeping in UMA on kldunload. It was out the scope 
> of the patch. I also committed the first part of the patch - mutexes 
> initialization.
>
> Nikos, can you please svn update and then arc update, so that updated patch 
> is posted here?


Sure, I am currently on vacation. I think I will make some time soon to update 
it.


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

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

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

Re: New CC modules not loading after Kernel recompilation

2015-05-21 Thread Karlis Laivins 
Hello again,

A little update - the problem occurs only when trying to load a modified
NewReno algorithm module. When I create a dummy module from, for example,
Vegas implementation (with some trivial changes made besides the function
and module names), the module can be loaded successfully.

Is there a way (if no other way can be found to fix this right away), to
trick the system into using my NewReno module instead of the one hard coded
in the system? (I know, sounds silly - change the hard coded settings, but,
maybe there is a way...)

Thank you in advance!

BR,
Karlis

On Thu, May 21, 2015 at 10:54 AM, Karlis Laivins 
wrote:

> Hello,
>
> Tried both, still the same issue...
>
> BR,
> KL
>
> On Thu, May 21, 2015 at 7:30 AM, Adrian Chadd  wrote:
>
>> Hi,
>>
>> Try kldxref /boot/kernel
>>
>> If it doesn't help, try recompiling the module.
>>
>>
>> -a
>>
>>
>> On 20 May 2015 at 19:41, Karlis Laivins  wrote:
>> > Good Morning,
>> >
>> > I have a following issue, maybe someone has encountered this and can
>> > provide me with a quick solution to a following issue.
>> >
>> > I have compiled a module, which is a modified version of the NewReno
>> > congestion control algorithm. I tried to load it into Kernel
>> successfully
>> > before I recompiled Kernel with a following config file, so I can use
>> > Imunes and test the new module:
>> >
>> > include GENERIC
>> > nooptions FLOWTABLE
>> > options VIMAGE
>> > options VNET_DEBUG
>> > options MROUTING
>> >
>> > options IPSEC
>> > device crypto
>> > options IPSEC_DEBUG
>> >
>> > options DDB
>> > options KDB
>> >
>> > The problem is - after the Kernel has been reompiled, I can no longer
>> load
>> > the module with kldload. The error I get is:
>> >
>> > link_elf: symbol tcp_do_rfc3465 undefined
>> > kldload: can't load cc_changedreno.ko: No such file or directory
>> >
>> > And this is despite the fact the cc_changedreno.ko module is in
>> > /boot/kernel/.
>> >
>> > Thank you in advance!
>> >
>> > BR,
>> > Karlis
>> > ___
>> > 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"
>>
>
>
___
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"

FreeBSD 9.3 - Intel X520-SR2 stops passing packets

2015-05-21 Thread Guy Helmer 
I’ve noticed that there have been reports of problems with Intel X520-SR2 
network interfaces stopping working. I think I’m seeing a similar issue where 
the 10Gb interfaces stop receiving traffic (they’re being used in promiscuous 
mode to sniff traffic from a tap). ifconfig shows the interfaces are still 
active and the links are OK. ifconfig down/up restores activity. I’ve changed 
hw.intr_storm_threshold=8000 but I couldn’t tell if the interrupt storm 
threshold had been triggered at the time the interfaces stopped passing traffic.

Output from sysctl:

# sysctl dev.ix.0
dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.5.15
dev.ix.0.%driver: ix
dev.ix.0.%location: slot=0 function=0
dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086 
subdevice=0x0003 class=0x02
dev.ix.0.%parent: pci4
dev.ix.0.fc: 0
dev.ix.0.enable_aim: 1
dev.ix.0.advertise_speed: 0
dev.ix.0.dropped: 0
dev.ix.0.mbuf_defrag_failed: 0
dev.ix.0.watchdog_events: 0
dev.ix.0.link_irq: 3
dev.ix.0.queue0.interrupt_rate: 50
dev.ix.0.queue0.irqs: 454449470
dev.ix.0.queue0.txd_head: 0
dev.ix.0.queue0.txd_tail: 0
dev.ix.0.queue0.tso_tx: 0
dev.ix.0.queue0.no_tx_dma_setup: 0
dev.ix.0.queue0.no_desc_avail: 0
dev.ix.0.queue0.tx_packets: 0
dev.ix.0.queue0.rxd_head: 1437
dev.ix.0.queue0.rxd_tail: 1436
dev.ix.0.queue0.rx_packets: 547499168
dev.ix.0.queue0.rx_bytes: 87201112584
dev.ix.0.queue0.rx_copies: 7934870
dev.ix.0.queue0.lro_queued: 0
dev.ix.0.queue0.lro_flushed: 0
dev.ix.0.queue1.interrupt_rate: 50
dev.ix.0.queue1.irqs: 466235043
dev.ix.0.queue1.txd_head: 0
dev.ix.0.queue1.txd_tail: 0
dev.ix.0.queue1.tso_tx: 0
dev.ix.0.queue1.no_tx_dma_setup: 0
dev.ix.0.queue1.no_desc_avail: 0
dev.ix.0.queue1.tx_packets: 0
dev.ix.0.queue1.rxd_head: 277
dev.ix.0.queue1.rxd_tail: 276
dev.ix.0.queue1.rx_packets: 547668680
dev.ix.0.queue1.rx_bytes: 86205679601
dev.ix.0.queue1.rx_copies: 7846653
dev.ix.0.queue1.lro_queued: 0
dev.ix.0.queue1.lro_flushed: 0
dev.ix.0.queue2.interrupt_rate: 50
dev.ix.0.queue2.irqs: 473958473
dev.ix.0.queue2.txd_head: 0
dev.ix.0.queue2.txd_tail: 0
dev.ix.0.queue2.tso_tx: 0
dev.ix.0.queue2.no_tx_dma_setup: 0
dev.ix.0.queue2.no_desc_avail: 0
dev.ix.0.queue2.tx_packets: 0
dev.ix.0.queue2.rxd_head: 576
dev.ix.0.queue2.rxd_tail: 575
dev.ix.0.queue2.rx_packets: 555704840
dev.ix.0.queue2.rx_bytes: 87294164455
dev.ix.0.queue2.rx_copies: 8297211
dev.ix.0.queue2.lro_queued: 0
dev.ix.0.queue2.lro_flushed: 0
dev.ix.0.queue3.interrupt_rate: 50
dev.ix.0.queue3.irqs: 477587504
dev.ix.0.queue3.txd_head: 0
dev.ix.0.queue3.txd_tail: 0
dev.ix.0.queue3.tso_tx: 0
dev.ix.0.queue3.no_tx_dma_setup: 0
dev.ix.0.queue3.no_desc_avail: 0
dev.ix.0.queue3.tx_packets: 0
dev.ix.0.queue3.rxd_head: 267
dev.ix.0.queue3.rxd_tail: 266
dev.ix.0.queue3.rx_packets: 559921557
dev.ix.0.queue3.rx_bytes: 86832161258
dev.ix.0.queue3.rx_copies: 7918011
dev.ix.0.queue3.lro_queued: 0
dev.ix.0.queue3.lro_flushed: 0
dev.ix.0.queue4.interrupt_rate: 50
dev.ix.0.queue4.irqs: 558339677
dev.ix.0.queue4.txd_head: 0
dev.ix.0.queue4.txd_tail: 0
dev.ix.0.queue4.tso_tx: 0
dev.ix.0.queue4.no_tx_dma_setup: 0
dev.ix.0.queue4.no_desc_avail: 0
dev.ix.0.queue4.tx_packets: 0
dev.ix.0.queue4.rxd_head: 1240
dev.ix.0.queue4.rxd_tail: 1239
dev.ix.0.queue4.rx_packets: 646909190
dev.ix.0.queue4.rx_bytes: 87117307815
dev.ix.0.queue4.rx_copies: 7944848
dev.ix.0.queue4.lro_queued: 0
dev.ix.0.queue4.lro_flushed: 0
dev.ix.0.queue5.interrupt_rate: 50
dev.ix.0.queue5.irqs: 467836647
dev.ix.0.queue5.txd_head: 0
dev.ix.0.queue5.txd_tail: 0
dev.ix.0.queue5.tso_tx: 0
dev.ix.0.queue5.no_tx_dma_setup: 0
dev.ix.0.queue5.no_desc_avail: 0
dev.ix.0.queue5.tx_packets: 0
dev.ix.0.queue5.rxd_head: 1411
dev.ix.0.queue5.rxd_tail: 1410
dev.ix.0.queue5.rx_packets: 549666835
dev.ix.0.queue5.rx_bytes: 84671540121
dev.ix.0.queue5.rx_copies: 8258025
dev.ix.0.queue5.lro_queued: 0
dev.ix.0.queue5.lro_flushed: 0
dev.ix.0.queue6.interrupt_rate: 50
dev.ix.0.queue6.irqs: 490798561
dev.ix.0.queue6.txd_head: 0
dev.ix.0.queue6.txd_tail: 0
dev.ix.0.queue6.tso_tx: 0
dev.ix.0.queue6.no_tx_dma_setup: 0
dev.ix.0.queue6.no_desc_avail: 0
dev.ix.0.queue6.tx_packets: 0
dev.ix.0.queue6.rxd_head: 160
dev.ix.0.queue6.rxd_tail: 159
dev.ix.0.queue6.rx_packets: 590187606
dev.ix.0.queue6.rx_bytes: 92115960421
dev.ix.0.queue6.rx_copies: 8262802
dev.ix.0.queue6.lro_queued: 0
dev.ix.0.queue6.lro_flushed: 0
dev.ix.0.queue7.interrupt_rate: 50
dev.ix.0.queue7.irqs: 471051540
dev.ix.0.queue7.txd_head: 0
dev.ix.0.queue7.txd_tail: 0
dev.ix.0.queue7.tso_tx: 0
dev.ix.0.queue7.no_tx_dma_setup: 0
dev.ix.0.queue7.no_desc_avail: 0
dev.ix.0.queue7.tx_packets: 0
dev.ix.0.queue7.rxd_head: 640
dev.ix.0.queue7.rxd_tail: 639
dev.ix.0.queue7.rx_packets: 553362982
dev.ix.0.queue7.rx_bytes: 84470102891
dev.ix.0.queue7.rx_copies: 7954102
dev.ix.0.queue7.lro_queued: 0
dev.ix.0.queue7.lro_flushed: 0
dev.ix.0.mac_stats.crc_errs: 2091
dev.ix.0.mac_stats.ill_errs: 26
dev.ix.0.mac_stats.byte_errs: 140
dev.ix.0.mac_stats.sho

Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets

2015-05-21 Thread Christopher Forgeron 
A few things:

1) How long before you have this behaviour?

2) What's the output of 'netstat -m' when you have the problem?

3) What is your MTU set to, and do you have TSO on or off?

On Thu, May 21, 2015 at 10:33 AM, Guy Helmer  wrote:

> I’ve noticed that there have been reports of problems with Intel X520-SR2
> network interfaces stopping working. I think I’m seeing a similar issue
> where the 10Gb interfaces stop receiving traffic (they’re being used in
> promiscuous mode to sniff traffic from a tap). ifconfig shows the
> interfaces are still active and the links are OK. ifconfig down/up restores
> activity. I’ve changed hw.intr_storm_threshold=8000 but I couldn’t tell if
> the interrupt storm threshold had been triggered at the time the interfaces
> stopped passing traffic.
>
> Output from sysctl:
>
> # sysctl dev.ix.0
> dev.ix.0.%desc: Intel(R) PRO/10GbE PCI-Express Network Driver, Version -
> 2.5.15
> dev.ix.0.%driver: ix
> dev.ix.0.%location: slot=0 function=0
> dev.ix.0.%pnpinfo: vendor=0x8086 device=0x10fb subvendor=0x8086
> subdevice=0x0003 class=0x02
> dev.ix.0.%parent: pci4
> dev.ix.0.fc: 0
> dev.ix.0.enable_aim: 1
> dev.ix.0.advertise_speed: 0
> dev.ix.0.dropped: 0
> dev.ix.0.mbuf_defrag_failed: 0
> dev.ix.0.watchdog_events: 0
> dev.ix.0.link_irq: 3
> dev.ix.0.queue0.interrupt_rate: 50
> dev.ix.0.queue0.irqs: 454449470
> dev.ix.0.queue0.txd_head: 0
> dev.ix.0.queue0.txd_tail: 0
> dev.ix.0.queue0.tso_tx: 0
> dev.ix.0.queue0.no_tx_dma_setup: 0
> dev.ix.0.queue0.no_desc_avail: 0
> dev.ix.0.queue0.tx_packets: 0
> dev.ix.0.queue0.rxd_head: 1437
> dev.ix.0.queue0.rxd_tail: 1436
> dev.ix.0.queue0.rx_packets: 547499168
> dev.ix.0.queue0.rx_bytes: 87201112584
> dev.ix.0.queue0.rx_copies: 7934870
> dev.ix.0.queue0.lro_queued: 0
> dev.ix.0.queue0.lro_flushed: 0
> dev.ix.0.queue1.interrupt_rate: 50
> dev.ix.0.queue1.irqs: 466235043
> dev.ix.0.queue1.txd_head: 0
> dev.ix.0.queue1.txd_tail: 0
> dev.ix.0.queue1.tso_tx: 0
> dev.ix.0.queue1.no_tx_dma_setup: 0
> dev.ix.0.queue1.no_desc_avail: 0
> dev.ix.0.queue1.tx_packets: 0
> dev.ix.0.queue1.rxd_head: 277
> dev.ix.0.queue1.rxd_tail: 276
> dev.ix.0.queue1.rx_packets: 547668680
> dev.ix.0.queue1.rx_bytes: 86205679601
> dev.ix.0.queue1.rx_copies: 7846653
> dev.ix.0.queue1.lro_queued: 0
> dev.ix.0.queue1.lro_flushed: 0
> dev.ix.0.queue2.interrupt_rate: 50
> dev.ix.0.queue2.irqs: 473958473
> dev.ix.0.queue2.txd_head: 0
> dev.ix.0.queue2.txd_tail: 0
> dev.ix.0.queue2.tso_tx: 0
> dev.ix.0.queue2.no_tx_dma_setup: 0
> dev.ix.0.queue2.no_desc_avail: 0
> dev.ix.0.queue2.tx_packets: 0
> dev.ix.0.queue2.rxd_head: 576
> dev.ix.0.queue2.rxd_tail: 575
> dev.ix.0.queue2.rx_packets: 555704840
> dev.ix.0.queue2.rx_bytes: 87294164455
> dev.ix.0.queue2.rx_copies: 8297211
> dev.ix.0.queue2.lro_queued: 0
> dev.ix.0.queue2.lro_flushed: 0
> dev.ix.0.queue3.interrupt_rate: 50
> dev.ix.0.queue3.irqs: 477587504
> dev.ix.0.queue3.txd_head: 0
> dev.ix.0.queue3.txd_tail: 0
> dev.ix.0.queue3.tso_tx: 0
> dev.ix.0.queue3.no_tx_dma_setup: 0
> dev.ix.0.queue3.no_desc_avail: 0
> dev.ix.0.queue3.tx_packets: 0
> dev.ix.0.queue3.rxd_head: 267
> dev.ix.0.queue3.rxd_tail: 266
> dev.ix.0.queue3.rx_packets: 559921557
> dev.ix.0.queue3.rx_bytes: 86832161258
> dev.ix.0.queue3.rx_copies: 7918011
> dev.ix.0.queue3.lro_queued: 0
> dev.ix.0.queue3.lro_flushed: 0
> dev.ix.0.queue4.interrupt_rate: 50
> dev.ix.0.queue4.irqs: 558339677
> dev.ix.0.queue4.txd_head: 0
> dev.ix.0.queue4.txd_tail: 0
> dev.ix.0.queue4.tso_tx: 0
> dev.ix.0.queue4.no_tx_dma_setup: 0
> dev.ix.0.queue4.no_desc_avail: 0
> dev.ix.0.queue4.tx_packets: 0
> dev.ix.0.queue4.rxd_head: 1240
> dev.ix.0.queue4.rxd_tail: 1239
> dev.ix.0.queue4.rx_packets: 646909190
> dev.ix.0.queue4.rx_bytes: 87117307815
> dev.ix.0.queue4.rx_copies: 7944848
> dev.ix.0.queue4.lro_queued: 0
> dev.ix.0.queue4.lro_flushed: 0
> dev.ix.0.queue5.interrupt_rate: 50
> dev.ix.0.queue5.irqs: 467836647
> dev.ix.0.queue5.txd_head: 0
> dev.ix.0.queue5.txd_tail: 0
> dev.ix.0.queue5.tso_tx: 0
> dev.ix.0.queue5.no_tx_dma_setup: 0
> dev.ix.0.queue5.no_desc_avail: 0
> dev.ix.0.queue5.tx_packets: 0
> dev.ix.0.queue5.rxd_head: 1411
> dev.ix.0.queue5.rxd_tail: 1410
> dev.ix.0.queue5.rx_packets: 549666835
> dev.ix.0.queue5.rx_bytes: 84671540121
> dev.ix.0.queue5.rx_copies: 8258025
> dev.ix.0.queue5.lro_queued: 0
> dev.ix.0.queue5.lro_flushed: 0
> dev.ix.0.queue6.interrupt_rate: 50
> dev.ix.0.queue6.irqs: 490798561
> dev.ix.0.queue6.txd_head: 0
> dev.ix.0.queue6.txd_tail: 0
> dev.ix.0.queue6.tso_tx: 0
> dev.ix.0.queue6.no_tx_dma_setup: 0
> dev.ix.0.queue6.no_desc_avail: 0
> dev.ix.0.queue6.tx_packets: 0
> dev.ix.0.queue6.rxd_head: 160
> dev.ix.0.queue6.rxd_tail: 159
> dev.ix.0.queue6.rx_packets: 590187606
> dev.ix.0.queue6.rx_bytes: 92115960421
> dev.ix.0.queue6.rx_copies: 8262802
> dev.ix.0.queue6.lro_queued: 0
> dev.ix.0.queue6.lro_flushed: 0
> dev.ix.0.queue7.interrupt_rate: 50
> dev.ix.0.queue7.irqs: 471051540
> dev.ix.0.queue7.txd_head: 0
> dev.ix

Re: New CC modules not loading after Kernel recompilation

2015-05-21 Thread K. Macy 
Your module references a variable that the kernel doesn't define. As soon
as you either define it or figure out what you should really be referencing
it as your module will load.
On May 21, 2015 3:53 AM, "Karlis Laivins"  wrote:

> Hello again,
>
> A little update - the problem occurs only when trying to load a modified
> NewReno algorithm module. When I create a dummy module from, for example,
> Vegas implementation (with some trivial changes made besides the function
> and module names), the module can be loaded successfully.
>
> Is there a way (if no other way can be found to fix this right away), to
> trick the system into using my NewReno module instead of the one hard coded
> in the system? (I know, sounds silly - change the hard coded settings, but,
> maybe there is a way...)
>
> Thank you in advance!
>
> BR,
> Karlis
>
> On Thu, May 21, 2015 at 10:54 AM, Karlis Laivins  >
> wrote:
>
> > Hello,
> >
> > Tried both, still the same issue...
> >
> > BR,
> > KL
> >
> > On Thu, May 21, 2015 at 7:30 AM, Adrian Chadd 
> wrote:
> >
> >> Hi,
> >>
> >> Try kldxref /boot/kernel
> >>
> >> If it doesn't help, try recompiling the module.
> >>
> >>
> >> -a
> >>
> >>
> >> On 20 May 2015 at 19:41, Karlis Laivins 
> wrote:
> >> > Good Morning,
> >> >
> >> > I have a following issue, maybe someone has encountered this and can
> >> > provide me with a quick solution to a following issue.
> >> >
> >> > I have compiled a module, which is a modified version of the NewReno
> >> > congestion control algorithm. I tried to load it into Kernel
> >> successfully
> >> > before I recompiled Kernel with a following config file, so I can use
> >> > Imunes and test the new module:
> >> >
> >> > include GENERIC
> >> > nooptions FLOWTABLE
> >> > options VIMAGE
> >> > options VNET_DEBUG
> >> > options MROUTING
> >> >
> >> > options IPSEC
> >> > device crypto
> >> > options IPSEC_DEBUG
> >> >
> >> > options DDB
> >> > options KDB
> >> >
> >> > The problem is - after the Kernel has been reompiled, I can no longer
> >> load
> >> > the module with kldload. The error I get is:
> >> >
> >> > link_elf: symbol tcp_do_rfc3465 undefined
> >> > kldload: can't load cc_changedreno.ko: No such file or directory
> >> >
> >> > And this is despite the fact the cc_changedreno.ko module is in
> >> > /boot/kernel/.
> >> >
> >> > Thank you in advance!
> >> >
> >> > BR,
> >> > Karlis
> >> > ___
> >> > 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
> "
> >>
> >
> >
> ___
> 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"
>
___
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"

heads up: netmap code update next week.

2015-05-21 Thread Luigi Rizzo 
Hi,
some time next week we will push to head (and hopefully, to stable/10
before the code slush) an update to the netmap code.  There will
be no API changes, and the changes are mostly internal restructuring
of the netmap kernel code and simplification of device drivers (we
will ll handle most of them ourselves and talk to Navdeep for the
chelsio bits).

These changes are needed to ease upcoming work on separate memory
allocators, and the passthrough code which we are working on.

If anyone has local diffs that would like to submit, please let us know
so we can merge them as well if appropriate

cheers
luigi

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

sys/netinet/ip_var.h: enum value exceeding 2^31-1

2015-05-21 Thread Luigi Rizzo 
in pedantic mode the compiler complains about
an enum value out of range (in sys/netinet/ip_var.h)

Would people object to the following change ?
It seems to be used internally only in a handful of places


​+​
/* ISO C restricts enumerator values to range of 'int'
​+​
 * so we need
​IPFW_INFO_​
IN to have a smaller value
​+​
 */
​ ​
enum {
IPFW_INFO_MASK  = 0x,
IPFW_INFO_OUT   = 0x,   /* outgoing, just for convenience */
​-   ​
IPFW_INFO_IN= 0x8
​00​
0,   /* incoming, overloads dir */
​+​
   IPFW_INFO_IN= 0x0080,   /* incoming, overloads dir */
IPFW_ONEPASS= 0x4000,   /* One-pass, do not reinject */

head/sys/netpfil/ipfw/ip_fw2.c: cmd->arg1 & ((i
& IPFW_INFO_IN) ? 1 : 2);
head/sys/netgraph/ng_ipfw.c:if (r->info & IPFW_INFO_IN) {
head/sys/netgraph/ng_ipfw.c:r->info |= dir ? IPFW_INFO_IN :
IPFW_INFO_OUT;
head/sys/netinet/ip_var.h:  IPFW_INFO_IN= 0x8000,   /*
incoming, overloads dir */
head/sys/netinet/ip_divert.c:   dt->info |= IPFW_IS_DIVERT |
IPFW_INFO_IN;

​cheers
luigi
___
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"

Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets

2015-05-21 Thread Guy Helmer 

> On May 21, 2015, at 8:52 AM, Christopher Forgeron  
> wrote:
> 
> A few things:
> 
> 1) How long before you have this behaviour?
> 
> 2) What's the output of 'netstat -m' when you have the problem?
> 
> 3) What is your MTU set to, and do you have TSO on or off?
> 
> On Thu, May 21, 2015 at 10:33 AM, Guy Helmer  > wrote:
> I’ve noticed that there have been reports of problems with Intel X520-SR2 
> network interfaces stopping working. I think I’m seeing a similar issue where 
> the 10Gb interfaces stop receiving traffic (they’re being used in promiscuous 
> mode to sniff traffic from a tap). ifconfig shows the interfaces are still 
> active and the links are OK. ifconfig down/up restores activity. I’ve changed 
> hw.intr_storm_threshold=8000 but I couldn’t tell if the interrupt storm 
> threshold had been triggered at the time the interfaces stopped passing 
> traffic.

It seems to run from hours to days without problems.

I don’t have the output of “netstat -m” available, but it did not indicate any 
mbuf or cluster allocation failures. No jumbo clusters (4k, 9k, or 16k) were 
allocated.

MTU is 1500. TSO is “on” but would seem to be irrelevant — no packets are 
transmitted out of these interfaces (verified using “netstat -i”).

Thanks,
Guy
___
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"

Re: New CC modules not loading after Kernel recompilation

2015-05-21 Thread Karlis Laivins 
Hi,

The source of the module has netinet/tcp_var.h included, in which the
variable is defined. Why it still gives me the aforementioned error? And
more importantly, why did it work without problems before I recompiled the
Kernel?

BR,
KL

On Thu, May 21, 2015 at 6:45 PM, K. Macy  wrote:

> Your module references a variable that the kernel doesn't define. As soon
> as you either define it or figure out what you should really be referencing
> it as your module will load.
> On May 21, 2015 3:53 AM, "Karlis Laivins" 
> wrote:
>
>> Hello again,
>>
>> A little update - the problem occurs only when trying to load a modified
>> NewReno algorithm module. When I create a dummy module from, for example,
>> Vegas implementation (with some trivial changes made besides the function
>> and module names), the module can be loaded successfully.
>>
>> Is there a way (if no other way can be found to fix this right away), to
>> trick the system into using my NewReno module instead of the one hard
>> coded
>> in the system? (I know, sounds silly - change the hard coded settings,
>> but,
>> maybe there is a way...)
>>
>> Thank you in advance!
>>
>> BR,
>> Karlis
>>
>> On Thu, May 21, 2015 at 10:54 AM, Karlis Laivins <
>> karlis.laiv...@gmail.com>
>> wrote:
>>
>> > Hello,
>> >
>> > Tried both, still the same issue...
>> >
>> > BR,
>> > KL
>> >
>> > On Thu, May 21, 2015 at 7:30 AM, Adrian Chadd 
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> Try kldxref /boot/kernel
>> >>
>> >> If it doesn't help, try recompiling the module.
>> >>
>> >>
>> >> -a
>> >>
>> >>
>> >> On 20 May 2015 at 19:41, Karlis Laivins 
>> wrote:
>> >> > Good Morning,
>> >> >
>> >> > I have a following issue, maybe someone has encountered this and can
>> >> > provide me with a quick solution to a following issue.
>> >> >
>> >> > I have compiled a module, which is a modified version of the NewReno
>> >> > congestion control algorithm. I tried to load it into Kernel
>> >> successfully
>> >> > before I recompiled Kernel with a following config file, so I can use
>> >> > Imunes and test the new module:
>> >> >
>> >> > include GENERIC
>> >> > nooptions FLOWTABLE
>> >> > options VIMAGE
>> >> > options VNET_DEBUG
>> >> > options MROUTING
>> >> >
>> >> > options IPSEC
>> >> > device crypto
>> >> > options IPSEC_DEBUG
>> >> >
>> >> > options DDB
>> >> > options KDB
>> >> >
>> >> > The problem is - after the Kernel has been reompiled, I can no longer
>> >> load
>> >> > the module with kldload. The error I get is:
>> >> >
>> >> > link_elf: symbol tcp_do_rfc3465 undefined
>> >> > kldload: can't load cc_changedreno.ko: No such file or directory
>> >> >
>> >> > And this is despite the fact the cc_changedreno.ko module is in
>> >> > /boot/kernel/.
>> >> >
>> >> > Thank you in advance!
>> >> >
>> >> > BR,
>> >> > Karlis
>> >> > ___
>> >> > 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"
>> >>
>> >
>> >
>> ___
>> 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"
>>
>
___
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"

Re: New CC modules not loading after Kernel recompilation

2015-05-21 Thread K. Macy 
On May 21, 2015 9:34 AM, "Karlis Laivins"  wrote:
>
> Hi,
>
> The source of the module has netinet/tcp_var.h included, in which the
variable is defined. Why it still gives me the aforementioned error? And
more importantly, why did it work without problems before I recompiled the
Kernel?
>

Headers declare variables. The variable is defined in the actual source. I
can't tell what's different with the kernel before and after without more
context than I'm prepared to sift through. 'nm' on the unstripped kernel
will list all the symbols. So you can grep for if it's a substring of
something actually defined.


> BR,
> KL
>
> On Thu, May 21, 2015 at 6:45 PM, K. Macy  wrote:
>>
>> Your module references a variable that the kernel doesn't define. As
soon as you either define it or figure out what you should really be
referencing it as your module will load.
>>
>> On May 21, 2015 3:53 AM, "Karlis Laivins" 
wrote:
>>>
>>> Hello again,
>>>
>>> A little update - the problem occurs only when trying to load a modified
>>> NewReno algorithm module. When I create a dummy module from, for
example,
>>> Vegas implementation (with some trivial changes made besides the
function
>>> and module names), the module can be loaded successfully.
>>>
>>> Is there a way (if no other way can be found to fix this right away), to
>>> trick the system into using my NewReno module instead of the one hard
coded
>>> in the system? (I know, sounds silly - change the hard coded settings,
but,
>>> maybe there is a way...)
>>>
>>> Thank you in advance!
>>>
>>> BR,
>>> Karlis
>>>
>>> On Thu, May 21, 2015 at 10:54 AM, Karlis Laivins <
karlis.laiv...@gmail.com>
>>> wrote:
>>>
>>> > Hello,
>>> >
>>> > Tried both, still the same issue...
>>> >
>>> > BR,
>>> > KL
>>> >
>>> > On Thu, May 21, 2015 at 7:30 AM, Adrian Chadd 
wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> Try kldxref /boot/kernel
>>> >>
>>> >> If it doesn't help, try recompiling the module.
>>> >>
>>> >>
>>> >> -a
>>> >>
>>> >>
>>> >> On 20 May 2015 at 19:41, Karlis Laivins 
wrote:
>>> >> > Good Morning,
>>> >> >
>>> >> > I have a following issue, maybe someone has encountered this and
can
>>> >> > provide me with a quick solution to a following issue.
>>> >> >
>>> >> > I have compiled a module, which is a modified version of the
NewReno
>>> >> > congestion control algorithm. I tried to load it into Kernel
>>> >> successfully
>>> >> > before I recompiled Kernel with a following config file, so I can
use
>>> >> > Imunes and test the new module:
>>> >> >
>>> >> > include GENERIC
>>> >> > nooptions FLOWTABLE
>>> >> > options VIMAGE
>>> >> > options VNET_DEBUG
>>> >> > options MROUTING
>>> >> >
>>> >> > options IPSEC
>>> >> > device crypto
>>> >> > options IPSEC_DEBUG
>>> >> >
>>> >> > options DDB
>>> >> > options KDB
>>> >> >
>>> >> > The problem is - after the Kernel has been reompiled, I can no
longer
>>> >> load
>>> >> > the module with kldload. The error I get is:
>>> >> >
>>> >> > link_elf: symbol tcp_do_rfc3465 undefined
>>> >> > kldload: can't load cc_changedreno.ko: No such file or directory
>>> >> >
>>> >> > And this is despite the fact the cc_changedreno.ko module is in
>>> >> > /boot/kernel/.
>>> >> >
>>> >> > Thank you in advance!
>>> >> >
>>> >> > BR,
>>> >> > Karlis
>>> >> > ___
>>> >> > 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"
>>> >>
>>> >
>>> >
>>> ___
>>> 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"
>
>
___
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"

Re: FCIP

2015-05-21 Thread Joe Nosay 
I'm not sure. We would need someone who has the time and is willing to work
on this protocol.

On Mon, May 18, 2015 at 1:40 PM,  wrote:

>
> Does FreeBSD support IP over FiberChannel?
>
> thanks,
> ron.
>
> ___
> 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"
>
___
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"

[Differential] [Commented On] D1881: Allow Illumos code to co-exist with nv(9)

2015-05-21 Thread avg (Andriy Gapon) 
avg added a subscriber: avg.
avg added a comment.

This has already been committed, so I've missed the train, but I still would 
like to comment. And I hope that my comment won't be just a rant.
So, I don't like this change for several reasons.

For one, given that nv(9) is a new thing while libnvpair already existed it 
would have been wise to select non-conflicting names for the new interfaces. 
And I think that it's still not too late to do that.
Then, it seems that this change has solved a theoretical problem as I don't 
think that currently there is any executable that links to both 
libraries.Perhaps I am wrong.
Also, libnvpair.so was treated like a "private" library: its ABI was wildly 
changed but its version hasn't been bumped.
Finally, from ABI point of view libnvpair now appears very inconsistent: many 
of its interfaces are prefixed with "illumos_" while quite a few don't have 
that prefix.

Now, why am I interested in libnvpair?
At work we have a Python module that interfaces libzfs_core and by necessity 
libnvpair through CFFI.
The module used to work perfectly well across FreeBSD, illumos and Linux 
because the library interfaces on ABI level are the same (from CFFI's point of 
view) across platforms.
After this change FreeBSD is an odd platform. I have to add a workaround to 
keep the module working. And even the workaround is not trivial because of the 
mix of prefixed and non-prefixed names.
Hope you sympathize.


REPOSITORY
  rS FreeBSD src repository

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

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

To: rstone, jfv, will
Cc: avg, will, emaste, pjd, freebsd-net
___
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"

[Differential] [Commented On] D1881: Allow Illumos code to co-exist with nv(9)

2015-05-21 Thread avg (Andriy Gapon) 
avg added a comment.

Another thought.

Or was the intention only to make nv(9) and hrm.. nvpair compatible only within 
the kernel? Section 9 seems like a big hint here, but I am not sure.
If the intention was such, then my previous comment is to inform that that 
change affected the userland as well.


REPOSITORY
  rS FreeBSD src repository

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

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

To: rstone, jfv, will
Cc: avg, will, emaste, pjd, freebsd-net
___
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"

Re: FreeBSD 9.3 - Intel X520-SR2 stops passing packets

2015-05-21 Thread Eric Joyner 
Are there any log messages printed out by the driver? The sysctls don't
really look out of the ordinary, other than the number of sub-64 byte
packets.

On Thu, May 21, 2015 at 9:10 AM Guy Helmer  wrote:

>
> > On May 21, 2015, at 8:52 AM, Christopher Forgeron 
> wrote:
> >
> > A few things:
> >
> > 1) How long before you have this behaviour?
> >
> > 2) What's the output of 'netstat -m' when you have the problem?
> >
> > 3) What is your MTU set to, and do you have TSO on or off?
> >
> > On Thu, May 21, 2015 at 10:33 AM, Guy Helmer  > wrote:
> > I’ve noticed that there have been reports of problems with Intel
> X520-SR2 network interfaces stopping working. I think I’m seeing a similar
> issue where the 10Gb interfaces stop receiving traffic (they’re being used
> in promiscuous mode to sniff traffic from a tap). ifconfig shows the
> interfaces are still active and the links are OK. ifconfig down/up restores
> activity. I’ve changed hw.intr_storm_threshold=8000 but I couldn’t tell if
> the interrupt storm threshold had been triggered at the time the interfaces
> stopped passing traffic.
>
> It seems to run from hours to days without problems.
>
> I don’t have the output of “netstat -m” available, but it did not indicate
> any mbuf or cluster allocation failures. No jumbo clusters (4k, 9k, or 16k)
> were allocated.
>
> MTU is 1500. TSO is “on” but would seem to be irrelevant — no packets are
> transmitted out of these interfaces (verified using “netstat -i”).
>
> Thanks,
> Guy
> ___
> 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"
___
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"

[Bug 200379] SCTP stack is not FIB aware

2015-05-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379

Craig Rodrigues  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|tue...@freebsd.org
 CC||freebsd-net@FreeBSD.org,
   ||r...@freebsd.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 200379] SCTP stack is not FIB aware

2015-05-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379

--- Comment #1 from Craig Rodrigues  ---
Created attachment 157024
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157024&action=edit
server.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 200379] SCTP stack is not FIB aware

2015-05-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379

--- Comment #2 from Craig Rodrigues  ---
Created attachment 157025
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157025&action=edit
client.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 200379] SCTP stack is not FIB aware

2015-05-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200379

--- Comment #3 from Craig Rodrigues  ---
In sys/netinet/sctp_os_bsd.h , 
the SCTP_RTALLOC macro calls the rtalloc_ign() function which ignores fibs.

It should probably be changed to call rtalloc_ign_fib()

In addition, it may be necessary to store the fib_num in the
inp and inherit it when accepting/peelingoff.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

[Bug 200382] Loading netgraph via bsnmpd, etc can cause domain to be registered after domain_finalize has been called

2015-05-21 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200382

Garrett Cooper,425-314-3911  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|n...@freebsd.org

--- Comment #1 from Garrett Cooper,425-314-3911  ---
I'm not entirely sure if bsnmpd will load netgraph automatically, BUT if you
load netgraph before you start bsnmpd, it might also repro this issue...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"