Re: Crash with GRE und IPFW fwd

On 29.05.2015 04:13, Julian Kornberger wrote: > Am 29.05.2015 um 01:35 schrieb Andrey V. Elsukov: >> The actual panic occurs when ip_output() does RO_RTFREE() to cached >> route owned by gre(4). >> >> #7 0x80a58105 in ip_output (m=0xf800054bb000, >> opt=, flags=, >> imo=, inp

Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?"

On Thu, May 28, 2015 at 10:26:18AM -0700, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 05/28/15 10:21, Patrick Kelsey wrote: > > Yes, I'll give it a go. I haven't yet done a dry-run to see how > > hairy it might be, so no predictions there. > > Great! Please feel fre

Re: Crash with GRE und IPFW fwd

Am 29.05.2015 um 01:35 schrieb Andrey V. Elsukov: The actual panic occurs when ip_output() does RO_RTFREE() to cached route owned by gre(4). #7 0x80a58105 in ip_output (m=0xf800054bb000, opt=, flags=, imo=, inp=0x0) at /usr/src/sys/netinet/ip_output.c:218 #8 0xff

Re: Crash with GRE und IPFW fwd

On 28.05.2015 17:22, Julian Kornberger wrote: > Am 28.05.2015 um 15:59 schrieb Andrey V. Elsukov:> Can you enable > dumpon(8) in your rc.conf, then get the crash dump and >> show content of your /var/crash/core.txt.N file? >> >> Also can you try this module instead of one from your base system? >>

No RTM_NEWADDR message generated when adding IPv6 addresses to a tun interface

Dear all, I'm using a tun interface with the IFF_BROADCAST | IFF_MULTICAST mode. I can use ifconfig to add an IPv4 or IPv6 address. So far so good. I'm running a program which gets all messages from a routing socket. When I'm adding an IPv4 address to the tun interfaces, I receive a RTM_NEWADDR r

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

If you are having high interrupt rate, it will be same on latest 10-STABLE. Are you using an unsupported SFP? > Guy Helmer > May 28, 2015 at 6:24 PM >> On May 23, 2015, at 1:14 PM, Babak Farrokhi wrote: >> >> Look at the interrupts per queue. 500,000 is the maximum a

Re: Performance issues with Intel Fortville (XL710/ixl(4))

Hi, I've no plans to MFC the RSS stuff to stable/10 - there's still RSS work that needs to happen in -HEAD and it will likely change the ioctls and kernel API a little. I'd really appreciate help on developing the RSS stuff in -HEAD so we can call it done and merge it back. Thanks, -adrian __

Re: Performance issues with Intel Fortville (XL710/ixl(4))

Hi Adrian, It is my understanding that you are maintaining the RSS code. The Panasas folks have this question for you. We are doing our testing w/ 11-CURRENT, but we will initially ship Intel XL710 40G NIC (Fortville) running on 10.1-RELEASE or 10.2-RELEASE. The presence of RSS - even though it i

Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/28/15 10:21, Patrick Kelsey wrote: > Yes, I'll give it a go. I haven't yet done a dry-run to see how > hairy it might be, so no predictions there. Great! Please feel free to ask if you need any help from my side. Cheers, > Thanks, Patrick

Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?"

Yes, I'll give it a go. I haven't yet done a dry-run to see how hairy it might be, so no predictions there. Thanks, Patrick On Thu, May 28, 2015 at 1:18 PM, hiren panchasara < hi...@strugglingcoder.info> wrote: > On 05/28/15 at 10:12P, Xin Li wrote: > > -BEGIN PGP SIGNED MESSAGE- > > H

Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?"

On 05/28/15 at 10:12P, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi, Hiren, > > On 05/27/15 21:55, hiren panchasara wrote: > > On 05/28/15 at 12:40P, Patrick Kelsey wrote: > >> Hi, > >> > >> I've had a patch for a capsicum-related issue in tcpdump sitting > >> around

Re: Looking for input on "locally patch tcpdump or merge in latest release from upstream?"

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Hiren, On 05/27/15 21:55, hiren panchasara wrote: > On 05/28/15 at 12:40P, Patrick Kelsey wrote: >> Hi, >> >> I've had a patch for a capsicum-related issue in tcpdump sitting >> around since last September ( >> https://lists.freebsd.org/piperm

Re: Crash with GRE und IPFW fwd

Am 28.05.2015 um 16:07 schrieb Andrey V. Elsukov: Just noticed, you use ip_divert(4). gre(4) uses mbuf_tag to prevent infinity loop and stack exhausting. When packet goes through ip_divert, it loses this tag. You need to check your rules and avoid applying divert rules to GRE packets. Also you ca

Re: Crash with GRE und IPFW fwd

Am 28.05.2015 um 15:59 schrieb Andrey V. Elsukov:> Can you enable dumpon(8) in your rc.conf, then get the crash dump and > show content of your /var/crash/core.txt.N file? > > Also can you try this module instead of one from your base system? > https://people.freebsd.org/~ae/gre-10.tgz > > This i

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

> On May 26, 2015, at 9:37 AM, Marcelo Gondim wrote: > > On 23-05-2015 15:14, Babak Farrokhi wrote: >> Look at the interrupts per queue. 500,000 is the maximum and it is the >> reason your interface is not accepting new packets. >> >>> Guy Helmer >>> May 21, 2015 a

Re: Crash with GRE und IPFW fwd

On 28.05.2015 02:42, Julian Kornberger wrote: > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x7c > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80a58105 > stack pointer

Re: Crash with GRE und IPFW fwd

On 28.05.2015 02:42, Julian Kornberger wrote: > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x7c > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80a58105 > stack pointer

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

> On May 23, 2015, at 1:14 PM, Babak Farrokhi wrote: > > Look at the interrupts per queue. 500,000 is the maximum and it is the reason > your interface is not accepting new packets. Thanks for the insight. Is there any possible mitigation for this issue? Regards, Guy > >> Guy Helmer

Re: Netmap problem with e1000e driver

Thanks for your report! :) Cheers, Stefano 2015-05-28 15:43 GMT+02:00 Oleg Prozorov : > Hello Stefano, > > You make my day :) It works. Greate job. > > Ths a lot, > Oleg. > > 2015-05-28 16:26 GMT+03:00 Stefano Garzarella >: > >> Hi Oleg, >> can you try to apply this patch in this way: >> >> 1)

Re: Netmap problem with e1000e driver

Hello Stefano, You make my day :) It works. Greate job. Ths a lot, Oleg. 2015-05-28 16:26 GMT+03:00 Stefano Garzarella : > Hi Oleg, > can you try to apply this patch in this way: > > 1) untar netmap achive > 2) dowonload linux source > 3) in netmap-32e06f9d18bf/LINUX directory > 3.1) ./configu

Re: Netmap problem with e1000e driver

Hi Oleg, can you try to apply this patch in this way: 1) untar netmap achive 2) dowonload linux source 3) in netmap-32e06f9d18bf/LINUX directory 3.1) ./configure --kernel-sources=/usr/src/linux-source-3.16/ --drivers=e1000e 3.2) make clean all 3.3) patch -p2 < path/to/e1000e_fix.patch 3.4) m

Re: Netmap problem with e1000e driver

Hello Stefano, I am working on Debian 8 jessy: kernel version: 3.16.0-4-amd64 i used netmap from link : https://netmap.googlecode.com/archive/32e06f9d18bf82e40a7c5b6e769c0ca7607913fc.tar.gz I did the next steps: 1) untar netmap achive 2) dowonload linux source 3) in netmap-32e06f9d18bf/LINUX di

Re: Crash with GRE und IPFW fwd

Am 28.05.2015 um 05:29 schrieb Julian Elischer: Julian, I am guessing (with no actual information) that something in gre processing is assuming that the packet id going where it normally would go. (and not where fwd is sending it). you really need to use objdump or gdb to look at the gre modul

Re: Netmap problem with e1000e driver

Hi Oleg, I'm working on netmap with Luigi and Giuseppe (in cc). I tried to do the same steps, but I can not produce the crash. Can you you send us your kernel and netmap version? When you put down and up the interface, are you in tx or rx? Cheers, Stefano 2015-05-27 17:26 GMT+02:00 Oleg Prozoro