Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: NTop: Misc

Announce: PF_RING 4.0 (no kernel patching required)

  

 
NTop misc RSS feed   Index | Next | Previous | View Threaded


deri at ntop

Oct 18, 2009, 1:00 PM

Post #1 of 18 (2139 views)
Permalink
Announce: PF_RING 4.0 (no kernel patching required)
Dear all
this is to announce the release of PF_RING 4.0. Due to popular demand
I have finally managed to build a new release of PF_RING that can be
built on top of a vanilla kernel (please remember to download kernel
source, that in general are available as package from your favorite
Linux distribution) without patching the kernel as with PF_RING 3.0.

This I think is a big improvement as those of you who have not yet
adopted PF_RING due to kernel patching, can now finally use and enjoy
it.

As this is the first 4.x release, I believe there are still some
issues that need to be addressed. Please report any problem you might
experience.

IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is not a
good idea as you will receive packets twice. Please use 4.0 with a
vanilla kernel and not with a patched kernel.

Enjoy Luca
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc


bcronje at gmail

Oct 18, 2009, 2:02 PM

Post #2 of 18 (2100 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Thank you Luca,

Out of interest sake, how/where does PF_RING now hook into the kernel? Is
non-transparent mode still provided?

Kind regards

Beyers Cronje

On Sun, Oct 18, 2009 at 10:00 PM, Luca Deri <deri [at] ntop> wrote:

> Dear all
> this is to announce the release of PF_RING 4.0. Due to popular demand I
> have finally managed to build a new release of PF_RING that can be built on
> top of a vanilla kernel (please remember to download kernel source, that in
> general are available as package from your favorite Linux distribution)
> without patching the kernel as with PF_RING 3.0.
>
> This I think is a big improvement as those of you who have not yet adopted
> PF_RING due to kernel patching, can now finally use and enjoy it.
>
> As this is the first 4.x release, I believe there are still some issues
> that need to be addressed. Please report any problem you might experience.
>
> IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is not a good
> idea as you will receive packets twice. Please use 4.0 with a vanilla kernel
> and not with a patched kernel.
>
> Enjoy Luca
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>


deri at ntop

Oct 19, 2009, 12:26 AM

Post #3 of 18 (2096 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Beyers Cronje wrote:
Thank you Luca,

Out of interest sake, how/where does PF_RING now hook into the kernel? Is non-transparent mode still provided?

I basically had to use a trick. I hook like PF_PACKET does and then I use a trick in order to maintain per-device pointer to PF_RING. I'm aware that this is not a perfect solution but this is all I can do for avoiding kernel patch. If you look at the code and have specific questions please let me know.

Luca


Kind regards

Beyers Cronje

On Sun, Oct 18, 2009 at 10:00 PM, Luca Deri <deri [at] ntop> wrote:
Dear all
this is to announce the release of PF_RING 4.0. Due to popular demand I have finally managed to build a new release of PF_RING that can be built on top of a vanilla kernel (please remember to download kernel source, that in general are available as package from your favorite Linux distribution) without patching the kernel as with PF_RING 3.0.

This I think is a big improvement as those of you who have not yet adopted PF_RING due to kernel patching, can now finally use and enjoy it.

As this is the first 4.x release, I believe there are still some issues that need to be addressed. Please report any problem you might experience.

IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is not a good idea as you will receive packets twice. Please use 4.0 with a vanilla kernel and not with a patched kernel.

Enjoy Luca
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc"]http://listgateway.unipi.it/mailman/listinfo/ntop-misc

_______________________________________________ Ntop-misc mailing list Ntop-misc [at] listgateway http://listgateway.unipi.it/mailman/listinfo/ntop-misc"]http://listgateway.unipi.it/mailman/listinfo/ntop-misc


deri at ntop

Oct 19, 2009, 12:31 AM

Post #4 of 18 (2088 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Beyers,
I still owe you an answer. Non-transparent mode is something I still need to implement in v4. I have some ideas on how to do this, but I had no time yet to work at this

Luca

Luca Deri wrote:
Beyers Cronje wrote:
Thank you Luca,

Out of interest sake, how/where does PF_RING now hook into the kernel? Is non-transparent mode still provided?

I basically had to use a trick. I hook like PF_PACKET does and then I use a trick in order to maintain per-device pointer to PF_RING. I'm aware that this is not a perfect solution but this is all I can do for avoiding kernel patch. If you look at the code and have specific questions please let me know.

Luca


Kind regards

Beyers Cronje

On Sun, Oct 18, 2009 at 10:00 PM, Luca Deri <deri [at] ntop> wrote:
Dear all
this is to announce the release of PF_RING 4.0. Due to popular demand I have finally managed to build a new release of PF_RING that can be built on top of a vanilla kernel (please remember to download kernel source, that in general are available as package from your favorite Linux distribution) without patching the kernel as with PF_RING 3.0.

This I think is a big improvement as those of you who have not yet adopted PF_RING due to kernel patching, can now finally use and enjoy it.

As this is the first 4.x release, I believe there are still some issues that need to be addressed. Please report any problem you might experience.

IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is not a good idea as you will receive packets twice. Please use 4.0 with a vanilla kernel and not with a patched kernel.

Enjoy Luca
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc"]http://listgateway.unipi.it/mailman/listinfo/ntop-misc

_______________________________________________ Ntop-misc mailing list Ntop-misc [at] listgateway http://listgateway.unipi.it/mailman/listinfo/ntop-misc"]http://listgateway.unipi.it/mailman/listinfo/ntop-misc

_______________________________________________ Ntop-misc mailing list Ntop-misc [at] listgateway http://listgateway.unipi.it/mailman/listinfo/ntop-misc"]http://listgateway.unipi.it/mailman/listinfo/ntop-misc


bcronje at gmail

Oct 19, 2009, 12:36 AM

Post #5 of 18 (2090 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Thank you Luca.

I'm still new to PF_RING, so hopefully once I get more familiar with the
code I'd be contributing a bit more.

Beyers

On Mon, Oct 19, 2009 at 9:31 AM, Luca Deri <deri [at] ntop> wrote:

> Beyers,
> I still owe you an answer. Non-transparent mode is something I still need
> to implement in v4. I have some ideas on how to do this, but I had no time
> yet to work at this
>
> Luca
>
> Luca Deri wrote:
>
> Beyers Cronje wrote:
>
> Thank you Luca,
>
> Out of interest sake, how/where does PF_RING now hook into the kernel? Is
> non-transparent mode still provided?
>
>
> I basically had to use a trick. I hook like PF_PACKET does and then I use a
> trick in order to maintain per-device pointer to PF_RING. I'm aware that
> this is not a perfect solution but this is all I can do for avoiding kernel
> patch. If you look at the code and have specific questions please let me
> know.
>
> Luca
>
>
> Kind regards
>
> Beyers Cronje
>
> On Sun, Oct 18, 2009 at 10:00 PM, Luca Deri <deri [at] ntop> wrote:
>
>> Dear all
>> this is to announce the release of PF_RING 4.0. Due to popular demand I
>> have finally managed to build a new release of PF_RING that can be built on
>> top of a vanilla kernel (please remember to download kernel source, that in
>> general are available as package from your favorite Linux distribution)
>> without patching the kernel as with PF_RING 3.0.
>>
>> This I think is a big improvement as those of you who have not yet adopted
>> PF_RING due to kernel patching, can now finally use and enjoy it.
>>
>> As this is the first 4.x release, I believe there are still some issues
>> that need to be addressed. Please report any problem you might experience.
>>
>> IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is not a good
>> idea as you will receive packets twice. Please use 4.0 with a vanilla kernel
>> and not with a patched kernel.
>>
>> Enjoy Luca
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>
> ------------------------------
>
> _______________________________________________
> Ntop-misc mailing listNtop-misc [at] listgatewayhttp://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
> ------------------------------
>
> _______________________________________________
> Ntop-misc mailing listNtop-misc [at] listgatewayhttp://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>


didebuli at net

Oct 21, 2009, 9:24 AM

Post #6 of 18 (2050 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Hello Luca,

I'm testing PF_RING on old dual Xeon machine...

PF_RING compiles well with 2.6.31.4 and 2.6.32-rc5 and i can load module
without problems... but when i send traffic to this interface i get
kernel panic.

Generator: pktgen , 64 byte , 1070910 PPS ~ 500 Mbit/s

1. without pf_ring , "tcpdump -i eth2 -w /dev/null": OK
2. insmod pf_ring.ko, "pfcount -i eth2" : Kernel Panic

after several seconds after starting traffic generator server stoped
replying to ping. after remote reset/reboot i found this in syslog:

http://pastebin.com/m3273c030

this happens to 2.6.32-rc5 and 2.6.31.4 .

in other test with pcount i got similar error :

604.063391] [PF_RING] successfully allocated 1388544 bytes at
0xf8fe2000
[ 604.063398] [PF_RING] allocated 4107 slots
[slot_len=338][tot_mem=1388544]
[ 604.064160] device eth2 entered promiscuous mode
[ 604.804323] pcount: page allocation failure. order:0, mode:0x20
[ 604.804331] Pid: 4616, comm: pcount Not tainted 2.6.31.4 #1
[ 604.804334] Call Trace:
[ 604.804348] [<c03b1ecc>] ? printk+0x18/0x1c
[ 604.804358] [<c01a74ab>] __alloc_pages_nodemask+0x46b/0x530
[ 604.804367] [<c01cda76>] __slab_alloc+0x4c6/0x560
[ 604.804376] [<c0324f99>] ? __alloc_skb+0x29/0x120
[ 604.804380] [<c01cdc21>] kmem_cache_alloc+0x111/0x120
[ 604.804385] [<c0324f99>] ? __alloc_skb+0x29/0x120
[ 604.804389] [<c0324f99>] ? __alloc_skb+0x29/0x120
[ 604.804393] [<c0324f99>] __alloc_skb+0x29/0x120
[ 604.804398] [<c03252e3>] __netdev_alloc_skb+0x23/0x50
[ 604.804430] [<f8f57a2d>] e1000_clean_rx_irq+0x33d/0x4c0 [e1000]
[ 604.804446] [<f8f598f0>] e1000_clean+0x1d0/0x530 [e1000]
[ 604.804453] [<c0157e16>] ? getnstimeofday+0x56/0x110
[ 604.804459] [<c01136b6>] ? lapic_next_event+0x16/0x20
[ 604.804464] [<c015b778>] ? clockevents_program_event+0x98/0x150
[ 604.804471] [<c032fb5c>] net_rx_action+0xdc/0x1b0
[ 604.804478] [<c013dc1a>] __do_softirq+0xba/0x180
[ 604.804483] [<c0181c78>] ? handle_IRQ_event+0x58/0x140
[ 604.804489] [<c0116e0e>] ? ack_apic_level+0x7e/0x270
[ 604.804494] [<c013dd0d>] do_softirq+0x2d/0x40
[ 604.804498] [<c013de65>] irq_exit+0x65/0x90
[ 604.804503] [<c010478f>] do_IRQ+0x4f/0xc0
[ 604.804508] [<c013de34>] ? irq_exit+0x34/0x90
[ 604.804512] [<c0113d87>] ? smp_apic_timer_interrupt+0x57/0x90
[ 604.804517] [<c01036a9>] common_interrupt+0x29/0x30
[ 604.804520] Mem-Info:
[ 604.804523] DMA per-cpu:
[ 604.804526] CPU 0: hi: 0, btch: 1 usd: 0
[ 604.804529] CPU 1: hi: 0, btch: 1 usd: 0
[ 604.804531] CPU 2: hi: 0, btch: 1 usd: 0
[ 604.804534] CPU 3: hi: 0, btch: 1 usd: 0
[ 604.804536] Normal per-cpu:
[ 604.804539] CPU 0: hi: 186, btch: 31 usd: 49
[ 604.804542] CPU 1: hi: 186, btch: 31 usd: 78
[ 604.804544] CPU 2: hi: 186, btch: 31 usd: 35
[ 604.804547] CPU 3: hi: 186, btch: 31 usd: 118
[ 604.804549] HighMem per-cpu:
[ 604.804552] CPU 0: hi: 42, btch: 7 usd: 8
[ 604.804555] CPU 1: hi: 42, btch: 7 usd: 28
[ 604.804557] CPU 2: hi: 42, btch: 7 usd: 7
[ 604.804560] CPU 3: hi: 42, btch: 7 usd: 16
...

The problem seems to occur sooner with 500 mbit/s than with 200 mbit/s.

Can other users confirm this problem with pf_ring 4.0?


Kind regards,
Alexander



On Sun, 2009-10-18 at 22:00 +0200, Luca Deri wrote:
> Dear all
> this is to announce the release of PF_RING 4.0. Due to popular demand
> I have finally managed to build a new release of PF_RING that can be
> built on top of a vanilla kernel (please remember to download kernel
> source, that in general are available as package from your favorite
> Linux distribution) without patching the kernel as with PF_RING 3.0.
>
> This I think is a big improvement as those of you who have not yet
> adopted PF_RING due to kernel patching, can now finally use and enjoy
> it.
>
> As this is the first 4.x release, I believe there are still some
> issues that need to be addressed. Please report any problem you might
> experience.
>
> IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is not a
> good idea as you will receive packets twice. Please use 4.0 with a
> vanilla kernel and not with a patched kernel.
>
> Enjoy Luca
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc



_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc


deri at ntop

Oct 21, 2009, 10:07 AM

Post #7 of 18 (2053 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Alexander
I use .26 or .30 kernels so I can't say much about newer kernels. Can
you please check if with older kernel it works for you? If this is the
problem I need to get a newer kernel

Luca

On Oct 21, 2009, at 6:24 PM, Alexander Didebulidze wrote:

> Hello Luca,
>
> I'm testing PF_RING on old dual Xeon machine...
>
> PF_RING compiles well with 2.6.31.4 and 2.6.32-rc5 and i can load
> module
> without problems... but when i send traffic to this interface i get
> kernel panic.
>
> Generator: pktgen , 64 byte , 1070910 PPS ~ 500 Mbit/s
>
> 1. without pf_ring , "tcpdump -i eth2 -w /dev/null": OK
> 2. insmod pf_ring.ko, "pfcount -i eth2" : Kernel Panic
>
> after several seconds after starting traffic generator server stoped
> replying to ping. after remote reset/reboot i found this in syslog:
>
> http://pastebin.com/m3273c030
>
> this happens to 2.6.32-rc5 and 2.6.31.4 .
>
> in other test with pcount i got similar error :
>
> 604.063391] [PF_RING] successfully allocated 1388544 bytes at
> 0xf8fe2000
> [ 604.063398] [PF_RING] allocated 4107 slots
> [slot_len=338][tot_mem=1388544]
> [ 604.064160] device eth2 entered promiscuous mode
> [ 604.804323] pcount: page allocation failure. order:0, mode:0x20
> [ 604.804331] Pid: 4616, comm: pcount Not tainted 2.6.31.4 #1
> [ 604.804334] Call Trace:
> [ 604.804348] [<c03b1ecc>] ? printk+0x18/0x1c
> [ 604.804358] [<c01a74ab>] __alloc_pages_nodemask+0x46b/0x530
> [ 604.804367] [<c01cda76>] __slab_alloc+0x4c6/0x560
> [ 604.804376] [<c0324f99>] ? __alloc_skb+0x29/0x120
> [ 604.804380] [<c01cdc21>] kmem_cache_alloc+0x111/0x120
> [ 604.804385] [<c0324f99>] ? __alloc_skb+0x29/0x120
> [ 604.804389] [<c0324f99>] ? __alloc_skb+0x29/0x120
> [ 604.804393] [<c0324f99>] __alloc_skb+0x29/0x120
> [ 604.804398] [<c03252e3>] __netdev_alloc_skb+0x23/0x50
> [ 604.804430] [<f8f57a2d>] e1000_clean_rx_irq+0x33d/0x4c0 [e1000]
> [ 604.804446] [<f8f598f0>] e1000_clean+0x1d0/0x530 [e1000]
> [ 604.804453] [<c0157e16>] ? getnstimeofday+0x56/0x110
> [ 604.804459] [<c01136b6>] ? lapic_next_event+0x16/0x20
> [ 604.804464] [<c015b778>] ? clockevents_program_event+0x98/0x150
> [ 604.804471] [<c032fb5c>] net_rx_action+0xdc/0x1b0
> [ 604.804478] [<c013dc1a>] __do_softirq+0xba/0x180
> [ 604.804483] [<c0181c78>] ? handle_IRQ_event+0x58/0x140
> [ 604.804489] [<c0116e0e>] ? ack_apic_level+0x7e/0x270
> [ 604.804494] [<c013dd0d>] do_softirq+0x2d/0x40
> [ 604.804498] [<c013de65>] irq_exit+0x65/0x90
> [ 604.804503] [<c010478f>] do_IRQ+0x4f/0xc0
> [ 604.804508] [<c013de34>] ? irq_exit+0x34/0x90
> [ 604.804512] [<c0113d87>] ? smp_apic_timer_interrupt+0x57/0x90
> [ 604.804517] [<c01036a9>] common_interrupt+0x29/0x30
> [ 604.804520] Mem-Info:
> [ 604.804523] DMA per-cpu:
> [ 604.804526] CPU 0: hi: 0, btch: 1 usd: 0
> [ 604.804529] CPU 1: hi: 0, btch: 1 usd: 0
> [ 604.804531] CPU 2: hi: 0, btch: 1 usd: 0
> [ 604.804534] CPU 3: hi: 0, btch: 1 usd: 0
> [ 604.804536] Normal per-cpu:
> [ 604.804539] CPU 0: hi: 186, btch: 31 usd: 49
> [ 604.804542] CPU 1: hi: 186, btch: 31 usd: 78
> [ 604.804544] CPU 2: hi: 186, btch: 31 usd: 35
> [ 604.804547] CPU 3: hi: 186, btch: 31 usd: 118
> [ 604.804549] HighMem per-cpu:
> [ 604.804552] CPU 0: hi: 42, btch: 7 usd: 8
> [ 604.804555] CPU 1: hi: 42, btch: 7 usd: 28
> [ 604.804557] CPU 2: hi: 42, btch: 7 usd: 7
> [ 604.804560] CPU 3: hi: 42, btch: 7 usd: 16
> ...
>
> The problem seems to occur sooner with 500 mbit/s than with 200 mbit/
> s.
>
> Can other users confirm this problem with pf_ring 4.0?
>
>
> Kind regards,
> Alexander
>
>
>
> On Sun, 2009-10-18 at 22:00 +0200, Luca Deri wrote:
>> Dear all
>> this is to announce the release of PF_RING 4.0. Due to popular demand
>> I have finally managed to build a new release of PF_RING that can be
>> built on top of a vanilla kernel (please remember to download kernel
>> source, that in general are available as package from your favorite
>> Linux distribution) without patching the kernel as with PF_RING 3.0.
>>
>> This I think is a big improvement as those of you who have not yet
>> adopted PF_RING due to kernel patching, can now finally use and enjoy
>> it.
>>
>> As this is the first 4.x release, I believe there are still some
>> issues that need to be addressed. Please report any problem you might
>> experience.
>>
>> IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is not a
>> good idea as you will receive packets twice. Please use 4.0 with a
>> vanilla kernel and not with a patched kernel.
>>
>> Enjoy Luca
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc


didebuli at net

Oct 21, 2009, 4:17 PM

Post #8 of 18 (2054 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Hi Luca,

i just tried PF_RING 4.0 with 2.6.30.9(32 Bit, SMP) and i got similar
panic:

http://pastebin.com/m2afd9268

For testing I used ~200 mbit/s of 128 byte packets...

Regards,
Alexander


On Wed, 2009-10-21 at 19:07 +0200, Luca Deri wrote:
> Alexander
> I use .26 or .30 kernels so I can't say much about newer kernels. Can
> you please check if with older kernel it works for you? If this is the
> problem I need to get a newer kernel
>
> Luca
>
> On Oct 21, 2009, at 6:24 PM, Alexander Didebulidze wrote:
>
> > Hello Luca,
> >
> > I'm testing PF_RING on old dual Xeon machine...
> >
> > PF_RING compiles well with 2.6.31.4 and 2.6.32-rc5 and i can load
> > module
> > without problems... but when i send traffic to this interface i get
> > kernel panic.
> >
> > Generator: pktgen , 64 byte , 1070910 PPS ~ 500 Mbit/s
> >
> > 1. without pf_ring , "tcpdump -i eth2 -w /dev/null": OK
> > 2. insmod pf_ring.ko, "pfcount -i eth2" : Kernel Panic
> >
> > after several seconds after starting traffic generator server stoped
> > replying to ping. after remote reset/reboot i found this in syslog:
> >
> > http://pastebin.com/m3273c030
> >
> > this happens to 2.6.32-rc5 and 2.6.31.4 .
> >
> > in other test with pcount i got similar error :
> >
> > 604.063391] [PF_RING] successfully allocated 1388544 bytes at
> > 0xf8fe2000
> > [ 604.063398] [PF_RING] allocated 4107 slots
> > [slot_len=338][tot_mem=1388544]
> > [ 604.064160] device eth2 entered promiscuous mode
> > [ 604.804323] pcount: page allocation failure. order:0, mode:0x20
> > [ 604.804331] Pid: 4616, comm: pcount Not tainted 2.6.31.4 #1
> > [ 604.804334] Call Trace:
> > [ 604.804348] [<c03b1ecc>] ? printk+0x18/0x1c
> > [ 604.804358] [<c01a74ab>] __alloc_pages_nodemask+0x46b/0x530
> > [ 604.804367] [<c01cda76>] __slab_alloc+0x4c6/0x560
> > [ 604.804376] [<c0324f99>] ? __alloc_skb+0x29/0x120
> > [ 604.804380] [<c01cdc21>] kmem_cache_alloc+0x111/0x120
> > [ 604.804385] [<c0324f99>] ? __alloc_skb+0x29/0x120
> > [ 604.804389] [<c0324f99>] ? __alloc_skb+0x29/0x120
> > [ 604.804393] [<c0324f99>] __alloc_skb+0x29/0x120
> > [ 604.804398] [<c03252e3>] __netdev_alloc_skb+0x23/0x50
> > [ 604.804430] [<f8f57a2d>] e1000_clean_rx_irq+0x33d/0x4c0 [e1000]
> > [ 604.804446] [<f8f598f0>] e1000_clean+0x1d0/0x530 [e1000]
> > [ 604.804453] [<c0157e16>] ? getnstimeofday+0x56/0x110
> > [ 604.804459] [<c01136b6>] ? lapic_next_event+0x16/0x20
> > [ 604.804464] [<c015b778>] ? clockevents_program_event+0x98/0x150
> > [ 604.804471] [<c032fb5c>] net_rx_action+0xdc/0x1b0
> > [ 604.804478] [<c013dc1a>] __do_softirq+0xba/0x180
> > [ 604.804483] [<c0181c78>] ? handle_IRQ_event+0x58/0x140
> > [ 604.804489] [<c0116e0e>] ? ack_apic_level+0x7e/0x270
> > [ 604.804494] [<c013dd0d>] do_softirq+0x2d/0x40
> > [ 604.804498] [<c013de65>] irq_exit+0x65/0x90
> > [ 604.804503] [<c010478f>] do_IRQ+0x4f/0xc0
> > [ 604.804508] [<c013de34>] ? irq_exit+0x34/0x90
> > [ 604.804512] [<c0113d87>] ? smp_apic_timer_interrupt+0x57/0x90
> > [ 604.804517] [<c01036a9>] common_interrupt+0x29/0x30
> > [ 604.804520] Mem-Info:
> > [ 604.804523] DMA per-cpu:
> > [ 604.804526] CPU 0: hi: 0, btch: 1 usd: 0
> > [ 604.804529] CPU 1: hi: 0, btch: 1 usd: 0
> > [ 604.804531] CPU 2: hi: 0, btch: 1 usd: 0
> > [ 604.804534] CPU 3: hi: 0, btch: 1 usd: 0
> > [ 604.804536] Normal per-cpu:
> > [ 604.804539] CPU 0: hi: 186, btch: 31 usd: 49
> > [ 604.804542] CPU 1: hi: 186, btch: 31 usd: 78
> > [ 604.804544] CPU 2: hi: 186, btch: 31 usd: 35
> > [ 604.804547] CPU 3: hi: 186, btch: 31 usd: 118
> > [ 604.804549] HighMem per-cpu:
> > [ 604.804552] CPU 0: hi: 42, btch: 7 usd: 8
> > [ 604.804555] CPU 1: hi: 42, btch: 7 usd: 28
> > [ 604.804557] CPU 2: hi: 42, btch: 7 usd: 7
> > [ 604.804560] CPU 3: hi: 42, btch: 7 usd: 16
> > ...
> >
> > The problem seems to occur sooner with 500 mbit/s than with 200 mbit/
> > s.
> >
> > Can other users confirm this problem with pf_ring 4.0?
> >
> >
> > Kind regards,
> > Alexander
> >
> >
> >
> > On Sun, 2009-10-18 at 22:00 +0200, Luca Deri wrote:
> >> Dear all
> >> this is to announce the release of PF_RING 4.0. Due to popular demand
> >> I have finally managed to build a new release of PF_RING that can be
> >> built on top of a vanilla kernel (please remember to download kernel
> >> source, that in general are available as package from your favorite
> >> Linux distribution) without patching the kernel as with PF_RING 3.0.
> >>
> >> This I think is a big improvement as those of you who have not yet
> >> adopted PF_RING due to kernel patching, can now finally use and enjoy
> >> it.
> >>
> >> As this is the first 4.x release, I believe there are still some
> >> issues that need to be addressed. Please report any problem you might
> >> experience.
> >>
> >> IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is not a
> >> good idea as you will receive packets twice. Please use 4.0 with a
> >> vanilla kernel and not with a patched kernel.
> >>
> >> Enjoy Luca
> >> _______________________________________________
> >> Ntop-misc mailing list
> >> Ntop-misc [at] listgateway
> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
> >
> >
> >
> > _______________________________________________
> > Ntop-misc mailing list
> > Ntop-misc [at] listgateway
> > http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc


_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc


ferdigy at gmail

Oct 22, 2009, 7:08 AM

Post #9 of 18 (2037 views)
Permalink
Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Luca,

I have a similar problem with Alexander. I'm using PF_RING 4.0 on
kernel 2.6.26.8 Dual Xeon CentOS 5.3 (32bit) when I ran pfcount -i eth2.
After several seconds the machine will become unresponsive.

Oct 22 13:15:57 snortmachine kernel: [PF_RING] Welcome to PF_RING 4.0.0
Oct 22 13:15:57 snortmachine kernel: (C) 2004-09 L.Deri <deri [at] ntop>
Oct 22 13:15:57 snortmachine kernel: NET: Registered protocol family 27
Oct 22 13:15:57 snortmachine kernel: [PF_RING] Ring slots 4096
Oct 22 13:15:57 snortmachine kernel: [PF_RING] Slot version 10
Oct 22 13:15:57 snortmachine kernel: [PF_RING] Capture TX Yes [RX+TX]
Oct 22 13:15:57 snortmachine kernel: [PF_RING] IP Defragment No
Oct 22 13:15:57 snortmachine kernel: [PF_RING] Initialized correctly
Oct 22 13:15:57 snortmachine kernel: [PF_RING] registered /proc/net/pf_ring/
Oct 22 13:15:57 snortmachine kernel: [PF_RING] successfully allocated 864256
bytes at 0xf8df6000
Oct 22 13:15:57 snortmachine kernel: [PF_RING] allocated 4114 slots
[slot_len=210][tot_mem=864256]
Oct 22 13:15:57 snortmachine kernel: device eth2 entered promiscuous mode
Oct 22 13:15:59 snortmachine kernel: swapper: page allocation failure.
order:0, mode:0x20
Oct 22 13:15:59 snortmachine kernel: Pid: 0, comm: swapper Not tainted
2.6.26.8-1 #1
Oct 22 13:15:59 snortmachine kernel: [<c0452350>]
__alloc_pages_internal+0x338/0x34c
Oct 22 13:15:59 snortmachine kernel: [<c0452370>] __alloc_pages+0x7/0x9
Oct 22 13:15:59 snortmachine kernel: [<c0468715>]
cache_alloc_refill+0x245/0x43e
Oct 22 13:15:59 snortmachine kernel: [<c046897d>] __kmalloc+0x6f/0xa5
Oct 22 13:15:59 snortmachine kernel: [<c05a5f4e>] __alloc_skb+0x49/0xf7
Oct 22 13:15:59 snortmachine kernel: [<c05a6cca>]
__netdev_alloc_skb+0x14/0x2d
Oct 22 13:15:59 snortmachine kernel: [<f8946e08>]
e1000_alloc_rx_buffers+0x65/0x260 [e1000]
Oct 22 13:15:59 snortmachine kernel: [<f89473ee>]
e1000_clean_rx_irq+0x3eb/0x48d [e1000]
Oct 22 13:15:59 snortmachine kernel: [<f8947750>] e1000_clean+0x51/0x1d1
[e1000]
Oct 22 13:15:59 snortmachine kernel: [<c040420b>]
common_interrupt+0x23/0x28
Oct 22 13:15:59 snortmachine kernel: [<c05abb1d>] net_rx_action+0x8a/0x141
Oct 22 13:15:59 snortmachine kernel: [<c04267e9>] __do_softirq+0x5d/0xc1
Oct 22 13:15:59 snortmachine kernel: [<c0405728>] do_softirq+0x52/0x84
Oct 22 13:15:59 snortmachine kernel: [<c0449456>] handle_edge_irq+0x0/0xf8
Oct 22 13:15:59 snortmachine kernel: [<c040580c>] do_IRQ+0xb2/0xc6
Oct 22 13:15:59 snortmachine kernel: [<c040420b>]
common_interrupt+0x23/0x28
Oct 22 13:15:59 snortmachine kernel: [<c05217a5>] acpi_safe_halt+0x18/0x25
Oct 22 13:15:59 snortmachine kernel: [<c052184a>]
acpi_idle_enter_c1+0x98/0xee
Oct 22 13:16:00 snortmachine kernel: [<c0592744>]
cpuidle_idle_call+0x52/0x7e
Oct 22 13:16:00 snortmachine kernel: [<c05926f2>]
cpuidle_idle_call+0x0/0x7e
Oct 22 13:16:00 snortmachine kernel: [<c0402534>] cpu_idle+0x88/0x9c
Oct 22 13:16:00 snortmachine kernel: =======================
<snip>
Oct 22 13:16:00 snortmachine kernel: Active:102707 inactive:34244 dirty:179
writeback:0 unstable:0
Oct 22 13:16:00 snortmachine kernel: free:1746670 slab:185960 mapped:1524
pagetables:186 bounce:0
Oct 22 13:16:00 snortmachine kernel: DMA free:3488kB min:68kB low:84kB
high:100kB active:0kB inactive:0kB present:16256kB p
ages_scanned:0 all_unreclaimable? yes
Oct 22 13:16:00 snortmachine kernel: lowmem_reserve[]: 0 873 8874 8874
Oct 22 13:16:00 snortmachine kernel: Normal free:1620kB min:3744kB
low:4680kB high:5616kB active:56972kB inactive:16344kB p
resent:894080kB pages_scanned:49 all_unreclaimable? no
Oct 22 13:16:00 snortmachine kernel: lowmem_reserve[]: 0 0 64008 64008
Oct 22 13:16:00 snortmachine kernel: HighMem free:6981572kB min:512kB
low:9096kB high:17684kB active:353856kB inactive:1206
32kB present:8193024kB pages_scanned:0 all_unreclaimable? no
Oct 22 13:16:00 snortmachine kernel: lowmem_reserve[]: 0 0 0 0
Oct 22 13:16:00 snortmachine kernel: DMA: 2*4kB 3*8kB 2*16kB 3*32kB 0*64kB
2*128kB 2*256kB 1*512kB 0*1024kB 1*2048kB 0*4096
kB = 3488kB
Oct 22 13:16:00 snortmachine kernel: Normal: 27*4kB 7*8kB 7*16kB 3*32kB
0*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*
4096kB = 1652kB
Oct 22 13:16:00 snortmachine kernel: HighMem: 201*4kB 3098*8kB 3375*16kB
2643*32kB 1322*64kB 196*128kB 20*256kB 7*512kB 4*1
024kB 3*2048kB 1633*4096kB = 6981572kB
Oct 22 13:16:00 snortmachine kernel: 132492 total pagecache pages
Oct 22 13:16:00 snortmachine kernel: Swap cache: add 0, delete 0, find 0/0
Oct 22 13:16:00 snortmachine kernel: Free swap = 5406712kB
Oct 22 13:16:00 snortmachine kernel: Total swap = 5406712kB
Oct 22 13:16:00 snortmachine kernel: 2293760 pages of RAM
Oct 22 13:16:00 snortmachine kernel: 2064384 pages of HIGHMEM
Oct 22 13:16:00 snortmachine kernel: 217322 reserved pages
Oct 22 13:16:00 snortmachine kernel: 27776 pages shared
Oct 22 13:16:00 snortmachine kernel: 0 pages swap cached
Oct 22 13:16:00 snortmachine kernel: 179 pages dirty
Oct 22 13:16:00 snortmachine kernel: 0 pages writeback
Oct 22 13:16:00 snortmachine kernel: 1524 pages mapped
Oct 22 13:16:00 snortmachine kernel: 185960 pages slab
Oct 22 13:16:00 snortmachine kernel: 186 pages pagetables
Oct 22 13:16:00 snortmachine kernel: swapper: page allocation failure.
order:0, mode:0x20
Oct 22 13:16:00 snortmachine kernel: Pid: 0, comm: swapper Not tainted
2.6.26.8-1 #1
Oct 22 13:16:00 snortmachine kernel: [<c0452350>]
__alloc_pages_internal+0x338/0x34c
Oct 22 13:16:00 snortmachine kernel: [<c0452370>] __alloc_pages+0x7/0x9
Oct 22 13:16:00 snortmachine kernel: [<c0468715>]
cache_alloc_refill+0x245/0x43e
Oct 22 13:16:00 snortmachine kernel: [<c046897d>] __kmalloc+0x6f/0xa5
Oct 22 13:16:00 snortmachine kernel: [<c05a5f4e>] __alloc_skb+0x49/0xf7
Oct 22 13:16:00 snortmachine kernel: [<c05a6cca>]
__netdev_alloc_skb+0x14/0x2d
Oct 22 13:16:00 snortmachine kernel: [<f8946e08>]
e1000_alloc_rx_buffers+0x65/0x260 [e1000]
Oct 22 13:16:00 snortmachine kernel: [<f89473ee>]
e1000_clean_rx_irq+0x3eb/0x48d [e1000]
Oct 22 13:16:00 snortmachine kernel: [<f8947750>] e1000_clean+0x51/0x1d1
[e1000]
Oct 22 13:16:00 snortmachine kernel: [<c05abb1d>] net_rx_action+0x8a/0x141
Oct 22 13:16:00 snortmachine kernel: [<c04267e9>] __do_softirq+0x5d/0xc1
Oct 22 13:16:00 snortmachine kernel: [<c0405728>] do_softirq+0x52/0x84
Oct 22 13:16:00 snortmachine kernel: [<c0449456>] handle_edge_irq+0x0/0xf8
Oct 22 13:16:00 snortmachine kernel: [<c040580c>] do_IRQ+0xb2/0xc6
Oct 22 13:16:00 snortmachine kernel: [<c040420b>]
common_interrupt+0x23/0x28
Oct 22 13:16:00 snortmachine kernel: [<c05217a5>] acpi_safe_halt+0x18/0x25
Oct 22 13:16:00 snortmachine kernel: [<c052184a>]
acpi_idle_enter_c1+0x98/0xee
Oct 22 13:16:00 snortmachine kernel: [<c0592744>]
cpuidle_idle_call+0x52/0x7e
Oct 22 13:16:00 snortmachine kernel: [<c05926f2>]
cpuidle_idle_call+0x0/0x7e
Oct 22 13:16:00 snortmachine kernel: [<c0402534>] cpu_idle+0x88/0x9c
Oct 22 13:16:00 snortmachine kernel: =======================

-Ferdy


mickrussom at yahoo

Oct 22, 2009, 9:40 AM

Post #10 of 18 (2028 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
I know this may be presumptuous, but from what I've been seeing in terms of trends is that CentOS is pretty much everywhere, and it would be good to target PF_RING 4.0 to say, CentOS 5.3 / 5.4 rather than trying to target the upstream kernel because they change fundamental things quite often and your code will end up with quite a number of ifdefs for the various kernel versions.
 
CentOS/RHEL is KABI stable, and I'm guessing if you told everyone the primary target would be CentOS, no one would complain. Far less people than in the past like running kernel.org kernels because they dumped the 2.7->2.8 development versions and made 2.6 a permanent wild west development mess so the only places to get a stable KABI is Redhat these days.
 
If you look into this mailing list there is nearly a perpetual background set of requests to get PF_RING working on CentOS/RHEL.
 
I would also say that for those not using Linux as a Desktop, CentOS is nearly ubiquitous. I rarely see anything else.
 

 

>
>From: Ferdy
>To: ntop-misc [at] listgateway
>Sent: Thu, October 22, 2009 7:08:12 AM
>Subject: [Ntop-misc] Announce: PF_RING 4.0 (no kernel patching required)
>
>
>Luca,
>I have a similar problem with Alexander. I'm using PF_RING 4.0 on kernel 2.6.26.8 Dual Xeon CentOS 5.3 (32bit) when I ran pfcount -i eth2. After several seconds the machine will become unresponsive.
> 
> 
> 


eoin.miller at trojanedbinaries

Oct 22, 2009, 11:10 AM

Post #11 of 18 (2034 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Ubuntu 8.04 LTS is pretty stable as well. They have been sticking to
kernel v2.6.24 for quite some time.

-- Eoin

Mick Russom wrote:
>
> I know this may be presumptuous, but from what I've been seeing in
> terms of trends is that CentOS is pretty much everywhere, and it would
> be good to target PF_RING 4.0 to say, CentOS 5.3 / 5.4 rather than
> trying to target the upstream kernel because they change fundamental
> things quite often and your code will end up with quite a number of
> ifdefs for the various kernel versions.
>
>
>
> CentOS/RHEL is KABI stable, and I'm guessing if you told everyone the
> primary target would be CentOS, no one would complain. Far less people
> than in the past like running kernel.org kernels because they dumped
> the 2.7->2.8 development versions and made 2.6 a permanent wild west
> development mess so the only places to get a stable KABI is Redhat
> these days.
>
>
>
> If you look into this mailing list there is nearly a perpetual
> background set of requests to get PF_RING working on CentOS/RHEL.
>
>
>
> I would also say that for those not using Linux as a Desktop, CentOS
> is nearly ubiquitous. I rarely see anything else.
>
>
>
>
>
>
> *From:* Ferdy
> *To:* ntop-misc [at] listgateway
> *Sent:* Thu, October 22, 2009 7:08:12 AM
> *Subject:* [Ntop-misc] Announce: PF_RING 4.0 (no kernel patching
> required)
>
> Luca,
>
> I have a similar problem with Alexander. I'm using PF_RING 4.0 on
> kernel 2.6.26.8 Dual Xeon CentOS 5.3 (32bit) when I ran pfcount -i
> eth2. After several seconds the machine will become unresponsive.
>
>
>

_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc


bcronje at gmail

Oct 22, 2009, 12:30 PM

Post #12 of 18 (2021 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Since I'm new on this list and PF_RING in general, I'm sure my opinion
counts little, but here goes in any case.

I strongly hope that development carries on with vanilla kernel.org code. My
experience has been that in corporate environments it is much easier to
suggest implementing vanilla kernel code on corporate standard distribution
X, than suggest to change to distribution Y. Targeting a specific
distribution will alienate many users or at the least make adoption of
PF_RING more difficult.

Another thing worth considering is that should newer kernel features emerge
that PF_RING/TNAPI could make use of, it would take a while until those
features trickle down to mainstream distribution kernels, which might not be
ideal.

Not to mention the inevitable fanboy debates over which distribution would
be best.


On Thu, Oct 22, 2009 at 6:40 PM, Mick Russom <mickrussom [at] yahoo> wrote:

> I know this may be presumptuous, but from what I've been seeing in terms of
> trends is that CentOS is pretty much everywhere, and it would be good to
> target PF_RING 4.0 to say, CentOS 5.3 / 5.4 rather than trying to target the
> upstream kernel because they change fundamental things quite often and your
> code will end up with quite a number of ifdefs for the various kernel
> versions.
>
>
>
> CentOS/RHEL is KABI stable, and I'm guessing if you told everyone the
> primary target would be CentOS, no one would complain. Far less people than
> in the past like running kernel.org kernels because they dumped the
> 2.7->2.8 development versions and made 2.6 a permanent wild west development
> mess so the only places to get a stable KABI is Redhat these days.
>
>
>
> If you look into this mailing list there is nearly a perpetual background
> set of requests to get PF_RING working on CentOS/RHEL.
>
>
>
> I would also say that for those not using Linux as a Desktop, CentOS is
> nearly ubiquitous. I rarely see anything else.
>
>
>
>
>
> *From:* Ferdy
> *To:* ntop-misc [at] listgateway
> *Sent:* Thu, October 22, 2009 7:08:12 AM
> *Subject:* [Ntop-misc] Announce: PF_RING 4.0 (no kernel patching required)
>
> Luca,
>
> I have a similar problem with Alexander. I'm using PF_RING 4.0 on
> kernel 2.6.26.8 Dual Xeon CentOS 5.3 (32bit) when I ran pfcount -i eth2.
> After several seconds the machine will become unresponsive.
>
>
>
>
>
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
>


mickrussom at yahoo

Oct 22, 2009, 4:07 PM

Post #13 of 18 (2018 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
I think you underestimate making PF_RING work for any number of kernels.

How would you like to get it working on 2.6.29.6, say, and then to get a bugfix you *must* go to 2.6.31.4. Then when you upgrade, something else breaks.

A stable KABI is way more conducive to making something that actually works.


 

>
>From: Beyers Cronje <bcronje [at] gmail>
>To: ntop-misc [at] listgateway
>Sent: Thu, October 22, 2009 12:30:10 PM
>Subject: Re: [Ntop-misc] Announce: PF_RING 4.0 (no kernel patching required)
>
>Since I'm new on this list and PF_RING in general, I'm sure my opinion counts little, but here goes in any case.
>
>I strongly hope that development carries on with vanilla kernel.org code. My experience has been that in corporate environments it is much easier to suggest implementing vanilla kernel code on corporate standard distribution X, than suggest to change to distribution Y. Targeting a specific distribution will alienate many users or at the least make adoption of PF_RING more difficult.
>
>Another thing worth considering is that should newer kernel features emerge that PF_RING/TNAPI could make use of, it would take a while until those features trickle down to mainstream distribution kernels, which might not be ideal.
>
>Not to mention the inevitable fanboy debates over which distribution would be best.
>
>
>
>On Thu, Oct 22, 2009 at 6:40 PM, Mick Russom <mickrussom [at] yahoo> wrote:
>
>I know this may be presumptuous, but from what I've been seeing in terms of trends is that CentOS is pretty much everywhere, and it would be good to target PF_RING 4.0 to say, CentOS 5.3 / 5.4 rather than trying to target the upstream kernel because they change fundamental things quite often and your code will end up with quite a number of ifdefs for the various kernel versions.
>> 
>>CentOS/RHEL is KABI stable, and I'm guessing if you told everyone the primary target would be CentOS, no one would complain. Far less people than in the past like running kernel.org kernels because they dumped the 2.7->2.8 development versions and made 2.6 a permanent wild west development mess so the only places to get a stable KABI is Redhat these days.
>> 
>>If you look into this mailing list there is nearly a perpetual background set of requests to get PF_RING working on CentOS/RHEL.
>> 
>>I would also say that for those not using Linux as a Desktop, CentOS is nearly ubiquitous. I rarely see anything else.
>> 
>>
>> 
>>
>>>
>>>From: Ferdy
>>>To: ntop-misc [at] listgateway
>>>Sent: Thu, October 22, 2009 7:08:12 AM
>>>Subject: [Ntop-misc] Announce: PF_RING 4.0 (no kernel patching required)
>>>
>>>
>>>Luca,
>>>I have a similar problem with Alexander. I'm using PF_RING 4.0 on kernel 2.6.26.8 Dual Xeon CentOS 5.3 (32bit) when I ran pfcount -i eth2. After several seconds the machine will become unresponsive.
>>> 
>>> 
>>> 
>>
>>_______________________________________________
>>Ntop-misc mailing list
>>Ntop-misc [at] listgateway
>>http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>>
>


bmengel at gmail

Oct 23, 2009, 10:56 AM

Post #14 of 18 (2002 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Trying to compile on a fresh CentOS 5.4 install results in make
errors. Is there a preferred kernel version/linux distribution for
running the latest pf_ring and tnapi code?

[root [at] prob kernel]# uname -a
Linux probe 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64
x86_64 x86_64 GNU/Linux


[root [at] prob kernel]# make
make -C /lib/modules/2.6.18-164.el5/build
SUBDIRS=/usr/src/PF_RING/PF_RING/kernel modules
make[1]: Entering directory `/usr/src/kernels/2.6.18-164.el5-x86_64'
CC [M] /usr/src/PF_RING/PF_RING/kernel/pf_ring.o
In file included from /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:48:
include/linux/config.h:6:2: warning: #warning Including config.h is deprecated.
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:223: error: redefinition of âip_hdrâ
include/linux/ip.h:109: error: previous definition of âip_hdrâ was here
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:228: error: redefinition of
âskb_set_network_headerâ
include/linux/skbuff.h:1020: error: previous definition of
âskb_set_network_headerâ was here
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:233: error: redefinition of
âskb_reset_network_headerâ
include/linux/skbuff.h:1015: error: previous definition of
âskb_reset_network_headerâ was here
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:238: error: redefinition of
âskb_reset_transport_headerâ
include/linux/skbuff.h:994: error: previous definition of
âskb_reset_transport_headerâ was here
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_createâ:
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2437: error: ânetâ
undeclared (first use in this function)
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2437: error: (Each
undeclared identifier is reported only once
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2437: error: for each
function it appears in.)
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_releaseâ:
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2483: error: implicit
declaration of function âsock_netâ
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2483: warning:
initialization makes pointer from integer without a cast
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2499: error: dereferencing
pointer to incomplete type
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2501: error: dereferencing
pointer to incomplete type
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_notifierâ:
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4328: error: âstruct
net_deviceâ has no member named âml_privâ
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4329: error: âstruct
net_deviceâ has no member named âml_privâ
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4338: error: âstruct
net_deviceâ has no member named âml_privâ
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4341: error: âstruct
net_deviceâ has no member named âml_privâ
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4346: error: âstruct
net_deviceâ has no member named âml_privâ
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_exitâ:
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4377: error: âstruct
net_deviceâ has no member named âml_privâ
/usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4380: error: âstruct
net_deviceâ has no member named âml_privâ
make[2]: *** [/usr/src/PF_RING/PF_RING/kernel/pf_ring.o] Error 1
make[1]: *** [_module_/usr/src/PF_RING/PF_RING/kernel] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.18-164.el5-x86_64'
make: *** [all] Error 2


On Wed, Oct 21, 2009 at 1:07 PM, Luca Deri <deri [at] ntop> wrote:
> Alexander
> I use .26 or .30 kernels so I can't say much about newer kernels. Can you
> please check if with older kernel it works for you? If this is the problem I
> need to get a newer kernel
>
> Luca
>
> On Oct 21, 2009, at 6:24 PM, Alexander Didebulidze wrote:
>
>> Hello Luca,
>>
>> I'm testing PF_RING on old dual Xeon machine...
>>
>> PF_RING compiles well with 2.6.31.4 and 2.6.32-rc5 and i can load module
>> without problems... but when i send traffic to this interface i get
>> kernel panic.
>>
>> Generator: pktgen , 64 byte , 1070910 PPS ~ 500 Mbit/s
>>
>> 1. without pf_ring , "tcpdump -i eth2 -w /dev/null": OK
>> 2. insmod pf_ring.ko, "pfcount -i eth2"            : Kernel Panic
>>
>> after several seconds after starting traffic generator server stoped
>> replying to ping. after remote reset/reboot i found this in syslog:
>>
>> http://pastebin.com/m3273c030
>>
>> this happens to 2.6.32-rc5 and 2.6.31.4 .
>>
>> in other test with pcount i got similar error :
>>
>> 604.063391] [PF_RING] successfully allocated 1388544 bytes at
>> 0xf8fe2000
>> [  604.063398] [PF_RING] allocated 4107 slots
>> [slot_len=338][tot_mem=1388544]
>> [  604.064160] device eth2 entered promiscuous mode
>> [  604.804323] pcount: page allocation failure. order:0, mode:0x20
>> [  604.804331] Pid: 4616, comm: pcount Not tainted 2.6.31.4 #1
>> [  604.804334] Call Trace:
>> [  604.804348]  [<c03b1ecc>] ? printk+0x18/0x1c
>> [  604.804358]  [<c01a74ab>] __alloc_pages_nodemask+0x46b/0x530
>> [  604.804367]  [<c01cda76>] __slab_alloc+0x4c6/0x560
>> [  604.804376]  [<c0324f99>] ? __alloc_skb+0x29/0x120
>> [  604.804380]  [<c01cdc21>] kmem_cache_alloc+0x111/0x120
>> [  604.804385]  [<c0324f99>] ? __alloc_skb+0x29/0x120
>> [  604.804389]  [<c0324f99>] ? __alloc_skb+0x29/0x120
>> [  604.804393]  [<c0324f99>] __alloc_skb+0x29/0x120
>> [  604.804398]  [<c03252e3>] __netdev_alloc_skb+0x23/0x50
>> [  604.804430]  [<f8f57a2d>] e1000_clean_rx_irq+0x33d/0x4c0 [e1000]
>> [  604.804446]  [<f8f598f0>] e1000_clean+0x1d0/0x530 [e1000]
>> [  604.804453]  [<c0157e16>] ? getnstimeofday+0x56/0x110
>> [  604.804459]  [<c01136b6>] ? lapic_next_event+0x16/0x20
>> [  604.804464]  [<c015b778>] ? clockevents_program_event+0x98/0x150
>> [  604.804471]  [<c032fb5c>] net_rx_action+0xdc/0x1b0
>> [  604.804478]  [<c013dc1a>] __do_softirq+0xba/0x180
>> [  604.804483]  [<c0181c78>] ? handle_IRQ_event+0x58/0x140
>> [  604.804489]  [<c0116e0e>] ? ack_apic_level+0x7e/0x270
>> [  604.804494]  [<c013dd0d>] do_softirq+0x2d/0x40
>> [  604.804498]  [<c013de65>] irq_exit+0x65/0x90
>> [  604.804503]  [<c010478f>] do_IRQ+0x4f/0xc0
>> [  604.804508]  [<c013de34>] ? irq_exit+0x34/0x90
>> [  604.804512]  [<c0113d87>] ? smp_apic_timer_interrupt+0x57/0x90
>> [  604.804517]  [<c01036a9>] common_interrupt+0x29/0x30
>> [  604.804520] Mem-Info:
>> [  604.804523] DMA per-cpu:
>> [  604.804526] CPU    0: hi:    0, btch:   1 usd:   0
>> [  604.804529] CPU    1: hi:    0, btch:   1 usd:   0
>> [  604.804531] CPU    2: hi:    0, btch:   1 usd:   0
>> [  604.804534] CPU    3: hi:    0, btch:   1 usd:   0
>> [  604.804536] Normal per-cpu:
>> [  604.804539] CPU    0: hi:  186, btch:  31 usd:  49
>> [  604.804542] CPU    1: hi:  186, btch:  31 usd:  78
>> [  604.804544] CPU    2: hi:  186, btch:  31 usd:  35
>> [  604.804547] CPU    3: hi:  186, btch:  31 usd: 118
>> [  604.804549] HighMem per-cpu:
>> [  604.804552] CPU    0: hi:   42, btch:   7 usd:   8
>> [  604.804555] CPU    1: hi:   42, btch:   7 usd:  28
>> [  604.804557] CPU    2: hi:   42, btch:   7 usd:   7
>> [  604.804560] CPU    3: hi:   42, btch:   7 usd:  16
>> ...
>>
>> The problem seems to occur sooner with 500 mbit/s than with 200 mbit/s.
>>
>> Can other users confirm this problem with pf_ring 4.0?
>>
>>
>> Kind regards,
>> Alexander
>>
>>
>>
>> On Sun, 2009-10-18 at 22:00 +0200, Luca Deri wrote:
>>>
>>> Dear all
>>> this is to announce the release of PF_RING 4.0. Due to popular demand
>>> I have finally managed to build a new release of PF_RING that can be
>>> built on top of a vanilla kernel (please remember to download kernel
>>> source, that in general are available as package from your favorite
>>> Linux distribution) without patching the kernel as with PF_RING 3.0.
>>>
>>> This I think is a big improvement as those of you who have not yet
>>> adopted PF_RING due to kernel patching, can now finally use and enjoy
>>> it.
>>>
>>> As this is the first 4.x release, I believe there are still some
>>> issues that need to be addressed. Please report any problem you might
>>> experience.
>>>
>>> IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is not a
>>> good idea as you will receive packets twice. Please use 4.0 with a
>>> vanilla kernel and not with a patched kernel.
>>>
>>> Enjoy Luca
>>> _______________________________________________
>>> Ntop-misc mailing list
>>> Ntop-misc [at] listgateway
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>>
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc


deri at ntop

Oct 24, 2009, 10:16 AM

Post #15 of 18 (1980 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Ferdy/Alexander
i think i have fixed the bug. Please confirm

Luca

On Oct 22, 2009, at 4:08 PM, Ferdy wrote:

> Luca,
>
> I have a similar problem with Alexander. I'm using PF_RING 4.0 on
> kernel 2.6.26.8 Dual Xeon CentOS 5.3 (32bit) when I ran pfcount -i
> eth2. After several seconds the machine will become unresponsive.
>
> Oct 22 13:15:57 snortmachine kernel: [PF_RING] Welcome to PF_RING
> 4.0.0
> Oct 22 13:15:57 snortmachine kernel: (C) 2004-09 L.Deri
> <deri [at] ntop>
> Oct 22 13:15:57 snortmachine kernel: NET: Registered protocol family
> 27
> Oct 22 13:15:57 snortmachine kernel: [PF_RING] Ring slots 4096
> Oct 22 13:15:57 snortmachine kernel: [PF_RING] Slot version 10
> Oct 22 13:15:57 snortmachine kernel: [PF_RING] Capture TX Yes
> [RX+TX]
> Oct 22 13:15:57 snortmachine kernel: [PF_RING] IP Defragment No
> Oct 22 13:15:57 snortmachine kernel: [PF_RING] Initialized correctly
> Oct 22 13:15:57 snortmachine kernel: [PF_RING] registered /proc/net/
> pf_ring/
> Oct 22 13:15:57 snortmachine kernel: [PF_RING] successfully
> allocated 864256 bytes at 0xf8df6000
> Oct 22 13:15:57 snortmachine kernel: [PF_RING] allocated 4114 slots
> [slot_len=210][tot_mem=864256]
> Oct 22 13:15:57 snortmachine kernel: device eth2 entered promiscuous
> mode
> Oct 22 13:15:59 snortmachine kernel: swapper: page allocation
> failure. order:0, mode:0x20
> Oct 22 13:15:59 snortmachine kernel: Pid: 0, comm: swapper Not
> tainted 2.6.26.8-1 #1
> Oct 22 13:15:59 snortmachine kernel: [<c0452350>]
> __alloc_pages_internal+0x338/0x34c
> Oct 22 13:15:59 snortmachine kernel: [<c0452370>] __alloc_pages
> +0x7/0x9
> Oct 22 13:15:59 snortmachine kernel: [<c0468715>] cache_alloc_refill
> +0x245/0x43e
> Oct 22 13:15:59 snortmachine kernel: [<c046897d>] __kmalloc+0x6f/0xa5
> Oct 22 13:15:59 snortmachine kernel: [<c05a5f4e>] __alloc_skb
> +0x49/0xf7
> Oct 22 13:15:59 snortmachine kernel: [<c05a6cca>] __netdev_alloc_skb
> +0x14/0x2d
> Oct 22 13:15:59 snortmachine kernel: [<f8946e08>]
> e1000_alloc_rx_buffers+0x65/0x260 [e1000]
> Oct 22 13:15:59 snortmachine kernel: [<f89473ee>] e1000_clean_rx_irq
> +0x3eb/0x48d [e1000]
> Oct 22 13:15:59 snortmachine kernel: [<f8947750>] e1000_clean
> +0x51/0x1d1 [e1000]
> Oct 22 13:15:59 snortmachine kernel: [<c040420b>] common_interrupt
> +0x23/0x28
> Oct 22 13:15:59 snortmachine kernel: [<c05abb1d>] net_rx_action
> +0x8a/0x141
> Oct 22 13:15:59 snortmachine kernel: [<c04267e9>] __do_softirq+0x5d/
> 0xc1
> Oct 22 13:15:59 snortmachine kernel: [<c0405728>] do_softirq
> +0x52/0x84
> Oct 22 13:15:59 snortmachine kernel: [<c0449456>] handle_edge_irq
> +0x0/0xf8
> Oct 22 13:15:59 snortmachine kernel: [<c040580c>] do_IRQ+0xb2/0xc6
> Oct 22 13:15:59 snortmachine kernel: [<c040420b>] common_interrupt
> +0x23/0x28
> Oct 22 13:15:59 snortmachine kernel: [<c05217a5>] acpi_safe_halt
> +0x18/0x25
> Oct 22 13:15:59 snortmachine kernel: [<c052184a>]
> acpi_idle_enter_c1+0x98/0xee
> Oct 22 13:16:00 snortmachine kernel: [<c0592744>] cpuidle_idle_call
> +0x52/0x7e
> Oct 22 13:16:00 snortmachine kernel: [<c05926f2>] cpuidle_idle_call
> +0x0/0x7e
> Oct 22 13:16:00 snortmachine kernel: [<c0402534>] cpu_idle+0x88/0x9c
> Oct 22 13:16:00 snortmachine kernel: =======================
> <snip>
> Oct 22 13:16:00 snortmachine kernel: Active:102707 inactive:34244
> dirty:179 writeback:0 unstable:0
> Oct 22 13:16:00 snortmachine kernel: free:1746670 slab:185960
> mapped:1524 pagetables:186 bounce:0
> Oct 22 13:16:00 snortmachine kernel: DMA free:3488kB min:68kB low:
> 84kB high:100kB active:0kB inactive:0kB present:16256kB p
> ages_scanned:0 all_unreclaimable? yes
> Oct 22 13:16:00 snortmachine kernel: lowmem_reserve[]: 0 873 8874 8874
> Oct 22 13:16:00 snortmachine kernel: Normal free:1620kB min:3744kB
> low:4680kB high:5616kB active:56972kB inactive:16344kB p
> resent:894080kB pages_scanned:49 all_unreclaimable? no
> Oct 22 13:16:00 snortmachine kernel: lowmem_reserve[]: 0 0 64008 64008
> Oct 22 13:16:00 snortmachine kernel: HighMem free:6981572kB min:
> 512kB low:9096kB high:17684kB active:353856kB inactive:1206
> 32kB present:8193024kB pages_scanned:0 all_unreclaimable? no
> Oct 22 13:16:00 snortmachine kernel: lowmem_reserve[]: 0 0 0 0
> Oct 22 13:16:00 snortmachine kernel: DMA: 2*4kB 3*8kB 2*16kB 3*32kB
> 0*64kB 2*128kB 2*256kB 1*512kB 0*1024kB 1*2048kB 0*4096
> kB = 3488kB
> Oct 22 13:16:00 snortmachine kernel: Normal: 27*4kB 7*8kB 7*16kB
> 3*32kB 0*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*
> 4096kB = 1652kB
> Oct 22 13:16:00 snortmachine kernel: HighMem: 201*4kB 3098*8kB
> 3375*16kB 2643*32kB 1322*64kB 196*128kB 20*256kB 7*512kB 4*1
> 024kB 3*2048kB 1633*4096kB = 6981572kB
> Oct 22 13:16:00 snortmachine kernel: 132492 total pagecache pages
> Oct 22 13:16:00 snortmachine kernel: Swap cache: add 0, delete 0,
> find 0/0
> Oct 22 13:16:00 snortmachine kernel: Free swap = 5406712kB
> Oct 22 13:16:00 snortmachine kernel: Total swap = 5406712kB
> Oct 22 13:16:00 snortmachine kernel: 2293760 pages of RAM
> Oct 22 13:16:00 snortmachine kernel: 2064384 pages of HIGHMEM
> Oct 22 13:16:00 snortmachine kernel: 217322 reserved pages
> Oct 22 13:16:00 snortmachine kernel: 27776 pages shared
> Oct 22 13:16:00 snortmachine kernel: 0 pages swap cached
> Oct 22 13:16:00 snortmachine kernel: 179 pages dirty
> Oct 22 13:16:00 snortmachine kernel: 0 pages writeback
> Oct 22 13:16:00 snortmachine kernel: 1524 pages mapped
> Oct 22 13:16:00 snortmachine kernel: 185960 pages slab
> Oct 22 13:16:00 snortmachine kernel: 186 pages pagetables
> Oct 22 13:16:00 snortmachine kernel: swapper: page allocation
> failure. order:0, mode:0x20
> Oct 22 13:16:00 snortmachine kernel: Pid: 0, comm: swapper Not
> tainted 2.6.26.8-1 #1
> Oct 22 13:16:00 snortmachine kernel: [<c0452350>]
> __alloc_pages_internal+0x338/0x34c
> Oct 22 13:16:00 snortmachine kernel: [<c0452370>] __alloc_pages
> +0x7/0x9
> Oct 22 13:16:00 snortmachine kernel: [<c0468715>] cache_alloc_refill
> +0x245/0x43e
> Oct 22 13:16:00 snortmachine kernel: [<c046897d>] __kmalloc+0x6f/0xa5
> Oct 22 13:16:00 snortmachine kernel: [<c05a5f4e>] __alloc_skb
> +0x49/0xf7
> Oct 22 13:16:00 snortmachine kernel: [<c05a6cca>] __netdev_alloc_skb
> +0x14/0x2d
> Oct 22 13:16:00 snortmachine kernel: [<f8946e08>]
> e1000_alloc_rx_buffers+0x65/0x260 [e1000]
> Oct 22 13:16:00 snortmachine kernel: [<f89473ee>] e1000_clean_rx_irq
> +0x3eb/0x48d [e1000]
> Oct 22 13:16:00 snortmachine kernel: [<f8947750>] e1000_clean
> +0x51/0x1d1 [e1000]
> Oct 22 13:16:00 snortmachine kernel: [<c05abb1d>] net_rx_action
> +0x8a/0x141
> Oct 22 13:16:00 snortmachine kernel: [<c04267e9>] __do_softirq+0x5d/
> 0xc1
> Oct 22 13:16:00 snortmachine kernel: [<c0405728>] do_softirq
> +0x52/0x84
> Oct 22 13:16:00 snortmachine kernel: [<c0449456>] handle_edge_irq
> +0x0/0xf8
> Oct 22 13:16:00 snortmachine kernel: [<c040580c>] do_IRQ+0xb2/0xc6
> Oct 22 13:16:00 snortmachine kernel: [<c040420b>] common_interrupt
> +0x23/0x28
> Oct 22 13:16:00 snortmachine kernel: [<c05217a5>] acpi_safe_halt
> +0x18/0x25
> Oct 22 13:16:00 snortmachine kernel: [<c052184a>]
> acpi_idle_enter_c1+0x98/0xee
> Oct 22 13:16:00 snortmachine kernel: [<c0592744>] cpuidle_idle_call
> +0x52/0x7e
> Oct 22 13:16:00 snortmachine kernel: [<c05926f2>] cpuidle_idle_call
> +0x0/0x7e
> Oct 22 13:16:00 snortmachine kernel: [<c0402534>] cpu_idle+0x88/0x9c
> Oct 22 13:16:00 snortmachine kernel: =======================
>
> -Ferdy
>
>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc


deri at ntop

Oct 24, 2009, 11:46 AM

Post #16 of 18 (1978 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Hi all
I have made some patches to PF_RING so that it can compile on .18
kernel too. As side comment, I acknowledge that PF_RING should
compiler more or less on every 2.6 kernel, but at the same time I
think that a kernel 2/3 years old is a bit outdated.

Enjoy PF_RING, Luca

As comment
On Oct 23, 2009, at 7:56 PM, Brian Mengel wrote:

> Trying to compile on a fresh CentOS 5.4 install results in make
> errors. Is there a preferred kernel version/linux distribution for
> running the latest pf_ring and tnapi code?
>
> [root [at] prob kernel]# uname -a
> Linux probe 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64
> x86_64 x86_64 GNU/Linux
>
>
> [root [at] prob kernel]# make
> make -C /lib/modules/2.6.18-164.el5/build
> SUBDIRS=/usr/src/PF_RING/PF_RING/kernel modules
> make[1]: Entering directory `/usr/src/kernels/2.6.18-164.el5-x86_64'
> CC [M] /usr/src/PF_RING/PF_RING/kernel/pf_ring.o
> In file included from /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:48:
> include/linux/config.h:6:2: warning: #warning Including config.h is
> deprecated.
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:223: error: redefinition
> of âip_hdrâ
> include/linux/ip.h:109: error: previous definition of âip_hdrâ was
> here
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:228: error: redefinition of
> âskb_set_network_headerâ
> include/linux/skbuff.h:1020: error: previous definition of
> âskb_set_network_headerâ was here
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:233: error: redefinition of
> âskb_reset_network_headerâ
> include/linux/skbuff.h:1015: error: previous definition of
> âskb_reset_network_headerâ was here
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:238: error: redefinition of
> âskb_reset_transport_headerâ
> include/linux/skbuff.h:994: error: previous definition of
> âskb_reset_transport_headerâ was here
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_createâ:
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2437: error: ânetâ
> undeclared (first use in this function)
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2437: error: (Each
> undeclared identifier is reported only once
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2437: error: for each
> function it appears in.)
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_releaseâ:
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2483: error: implicit
> declaration of function âsock_netâ
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2483: warning:
> initialization makes pointer from integer without a cast
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2499: error: dereferencing
> pointer to incomplete type
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2501: error: dereferencing
> pointer to incomplete type
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function
> âring_notifierâ:
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4328: error: âstruct
> net_deviceâ has no member named âml_privâ
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4329: error: âstruct
> net_deviceâ has no member named âml_privâ
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4338: error: âstruct
> net_deviceâ has no member named âml_privâ
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4341: error: âstruct
> net_deviceâ has no member named âml_privâ
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4346: error: âstruct
> net_deviceâ has no member named âml_privâ
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_exitâ:
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4377: error: âstruct
> net_deviceâ has no member named âml_privâ
> /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4380: error: âstruct
> net_deviceâ has no member named âml_privâ
> make[2]: *** [/usr/src/PF_RING/PF_RING/kernel/pf_ring.o] Error 1
> make[1]: *** [_module_/usr/src/PF_RING/PF_RING/kernel] Error 2
> make[1]: Leaving directory `/usr/src/kernels/2.6.18-164.el5-x86_64'
> make: *** [all] Error 2
>
>
> On Wed, Oct 21, 2009 at 1:07 PM, Luca Deri <deri [at] ntop> wrote:
>> Alexander
>> I use .26 or .30 kernels so I can't say much about newer kernels.
>> Can you
>> please check if with older kernel it works for you? If this is the
>> problem I
>> need to get a newer kernel
>>
>> Luca
>>
>> On Oct 21, 2009, at 6:24 PM, Alexander Didebulidze wrote:
>>
>>> Hello Luca,
>>>
>>> I'm testing PF_RING on old dual Xeon machine...
>>>
>>> PF_RING compiles well with 2.6.31.4 and 2.6.32-rc5 and i can load
>>> module
>>> without problems... but when i send traffic to this interface i get
>>> kernel panic.
>>>
>>> Generator: pktgen , 64 byte , 1070910 PPS ~ 500 Mbit/s
>>>
>>> 1. without pf_ring , "tcpdump -i eth2 -w /dev/null": OK
>>> 2. insmod pf_ring.ko, "pfcount -i eth2" : Kernel Panic
>>>
>>> after several seconds after starting traffic generator server stoped
>>> replying to ping. after remote reset/reboot i found this in syslog:
>>>
>>> http://pastebin.com/m3273c030
>>>
>>> this happens to 2.6.32-rc5 and 2.6.31.4 .
>>>
>>> in other test with pcount i got similar error :
>>>
>>> 604.063391] [PF_RING] successfully allocated 1388544 bytes at
>>> 0xf8fe2000
>>> [ 604.063398] [PF_RING] allocated 4107 slots
>>> [slot_len=338][tot_mem=1388544]
>>> [ 604.064160] device eth2 entered promiscuous mode
>>> [ 604.804323] pcount: page allocation failure. order:0, mode:0x20
>>> [ 604.804331] Pid: 4616, comm: pcount Not tainted 2.6.31.4 #1
>>> [ 604.804334] Call Trace:
>>> [ 604.804348] [<c03b1ecc>] ? printk+0x18/0x1c
>>> [ 604.804358] [<c01a74ab>] __alloc_pages_nodemask+0x46b/0x530
>>> [ 604.804367] [<c01cda76>] __slab_alloc+0x4c6/0x560
>>> [ 604.804376] [<c0324f99>] ? __alloc_skb+0x29/0x120
>>> [ 604.804380] [<c01cdc21>] kmem_cache_alloc+0x111/0x120
>>> [ 604.804385] [<c0324f99>] ? __alloc_skb+0x29/0x120
>>> [ 604.804389] [<c0324f99>] ? __alloc_skb+0x29/0x120
>>> [ 604.804393] [<c0324f99>] __alloc_skb+0x29/0x120
>>> [ 604.804398] [<c03252e3>] __netdev_alloc_skb+0x23/0x50
>>> [ 604.804430] [<f8f57a2d>] e1000_clean_rx_irq+0x33d/0x4c0 [e1000]
>>> [ 604.804446] [<f8f598f0>] e1000_clean+0x1d0/0x530 [e1000]
>>> [ 604.804453] [<c0157e16>] ? getnstimeofday+0x56/0x110
>>> [ 604.804459] [<c01136b6>] ? lapic_next_event+0x16/0x20
>>> [ 604.804464] [<c015b778>] ? clockevents_program_event+0x98/0x150
>>> [ 604.804471] [<c032fb5c>] net_rx_action+0xdc/0x1b0
>>> [ 604.804478] [<c013dc1a>] __do_softirq+0xba/0x180
>>> [ 604.804483] [<c0181c78>] ? handle_IRQ_event+0x58/0x140
>>> [ 604.804489] [<c0116e0e>] ? ack_apic_level+0x7e/0x270
>>> [ 604.804494] [<c013dd0d>] do_softirq+0x2d/0x40
>>> [ 604.804498] [<c013de65>] irq_exit+0x65/0x90
>>> [ 604.804503] [<c010478f>] do_IRQ+0x4f/0xc0
>>> [ 604.804508] [<c013de34>] ? irq_exit+0x34/0x90
>>> [ 604.804512] [<c0113d87>] ? smp_apic_timer_interrupt+0x57/0x90
>>> [ 604.804517] [<c01036a9>] common_interrupt+0x29/0x30
>>> [ 604.804520] Mem-Info:
>>> [ 604.804523] DMA per-cpu:
>>> [ 604.804526] CPU 0: hi: 0, btch: 1 usd: 0
>>> [ 604.804529] CPU 1: hi: 0, btch: 1 usd: 0
>>> [ 604.804531] CPU 2: hi: 0, btch: 1 usd: 0
>>> [ 604.804534] CPU 3: hi: 0, btch: 1 usd: 0
>>> [ 604.804536] Normal per-cpu:
>>> [ 604.804539] CPU 0: hi: 186, btch: 31 usd: 49
>>> [ 604.804542] CPU 1: hi: 186, btch: 31 usd: 78
>>> [ 604.804544] CPU 2: hi: 186, btch: 31 usd: 35
>>> [ 604.804547] CPU 3: hi: 186, btch: 31 usd: 118
>>> [ 604.804549] HighMem per-cpu:
>>> [ 604.804552] CPU 0: hi: 42, btch: 7 usd: 8
>>> [ 604.804555] CPU 1: hi: 42, btch: 7 usd: 28
>>> [ 604.804557] CPU 2: hi: 42, btch: 7 usd: 7
>>> [ 604.804560] CPU 3: hi: 42, btch: 7 usd: 16
>>> ...
>>>
>>> The problem seems to occur sooner with 500 mbit/s than with 200
>>> mbit/s.
>>>
>>> Can other users confirm this problem with pf_ring 4.0?
>>>
>>>
>>> Kind regards,
>>> Alexander
>>>
>>>
>>>
>>> On Sun, 2009-10-18 at 22:00 +0200, Luca Deri wrote:
>>>>
>>>> Dear all
>>>> this is to announce the release of PF_RING 4.0. Due to popular
>>>> demand
>>>> I have finally managed to build a new release of PF_RING that can
>>>> be
>>>> built on top of a vanilla kernel (please remember to download
>>>> kernel
>>>> source, that in general are available as package from your favorite
>>>> Linux distribution) without patching the kernel as with PF_RING
>>>> 3.0.
>>>>
>>>> This I think is a big improvement as those of you who have not yet
>>>> adopted PF_RING due to kernel patching, can now finally use and
>>>> enjoy
>>>> it.
>>>>
>>>> As this is the first 4.x release, I believe there are still some
>>>> issues that need to be addressed. Please report any problem you
>>>> might
>>>> experience.
>>>>
>>>> IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is
>>>> not a
>>>> good idea as you will receive packets twice. Please use 4.0 with a
>>>> vanilla kernel and not with a patched kernel.
>>>>
>>>> Enjoy Luca
>>>> _______________________________________________
>>>> Ntop-misc mailing list
>>>> Ntop-misc [at] listgateway
>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>>
>>>
>>>
>>> _______________________________________________
>>> Ntop-misc mailing list
>>> Ntop-misc [at] listgateway
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc


mickrussom at yahoo

Oct 24, 2009, 1:38 PM

Post #17 of 18 (1967 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
 2.6.18-164.el5 is not 3 years old. Its brand new. Redhat constantly improves and back ports things to this kernel.

The kernel is only old in that the KABI is stable. This is what most people who use Linux are looking for it they don't use it as a desktop (appliance, server, VM guest, VM host).

In fact, I believe  2.6.18-164.el5 is the only kernel with KVM and Xen that is actually supported.

Thank you for fix this; but realize that a lot of the changes from say, 2.6.18 until 2.6.31 - besides KVM and a few others, were done "just because" and most of us want the driver support from the newer kernels but not the wild-west/bazaar style development that causes a lot of breakage.

Also realize that Redhat can fix horrible injustice that goes on in kernel development, like the injustice we saw with Con Kolivas and the BFS scheduler, which Google picked over Ingo's CFS for Andriod. Stable vendor kernels take the politics out of Linux and put the best of breed back in.

I strongly recommend using RHEL/CentOS as the gold standard for PF_RING, I've seen quite literally thousands of these machines perform as servers and appliances for many years and find this distribution to be the most headache free.


----- Original Message ----
> From: Luca Deri <deri [at] ntop>
> To: ntop-misc [at] listgateway
> Sent: Sat, October 24, 2009 11:46:23 AM
> Subject: Re: [Ntop-misc] Announce: PF_RING 4.0 (no kernel patching required)
>
> Hi all
> I have made some patches to PF_RING so that it can compile on .18 kernel too. As
> side comment, I acknowledge that PF_RING should compiler more or less on every
> 2.6 kernel, but at the same time I think that a kernel 2/3 years old is a bit
> outdated.
>
> Enjoy PF_RING, Luca
>
> As comment
> On Oct 23, 2009, at 7:56 PM, Brian Mengel wrote:
>
> > Trying to compile on a fresh CentOS 5.4 install results in make
> > errors.  Is there a preferred kernel version/linux distribution for
> > running the latest pf_ring and tnapi code?
> >
> > [root [at] prob kernel]# uname -a
> > Linux probe 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64
> > x86_64 x86_64 GNU/Linux
> >
> >
> > [root [at] prob kernel]# make
> > make -C /lib/modules/2.6.18-164.el5/build
> > SUBDIRS=/usr/src/PF_RING/PF_RING/kernel modules
> > make[1]: Entering directory `/usr/src/kernels/2.6.18-164.el5-x86_64'
> >  CC [M]  /usr/src/PF_RING/PF_RING/kernel/pf_ring.o
> > In file included from /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:48:
> > include/linux/config.h:6:2: warning: #warning Including config.h is
> deprecated.
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:223: error: redefinition of âip_hdrâ
> > include/linux/ip.h:109: error: previous definition of âip_hdrâ was here
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:228: error: redefinition of
> > âskb_set_network_headerâ
> > include/linux/skbuff.h:1020: error: previous definition of
> > âskb_set_network_headerâ was here
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:233: error: redefinition of
> > âskb_reset_network_headerâ
> > include/linux/skbuff.h:1015: error: previous definition of
> > âskb_reset_network_headerâ was here
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:238: error: redefinition of
> > âskb_reset_transport_headerâ
> > include/linux/skbuff.h:994: error: previous definition of
> > âskb_reset_transport_headerâ was here
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_createâ:
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2437: error: ânetâ
> > undeclared (first use in this function)
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2437: error: (Each
> > undeclared identifier is reported only once
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2437: error: for each
> > function it appears in.)
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_releaseâ:
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2483: error: implicit
> > declaration of function âsock_netâ
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2483: warning:
> > initialization makes pointer from integer without a cast
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2499: error: dereferencing
> > pointer to incomplete type
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:2501: error: dereferencing
> > pointer to incomplete type
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_notifierâ:
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4328: error: âstruct
> > net_deviceâ has no member named âml_privâ
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4329: error: âstruct
> > net_deviceâ has no member named âml_privâ
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4338: error: âstruct
> > net_deviceâ has no member named âml_privâ
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4341: error: âstruct
> > net_deviceâ has no member named âml_privâ
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4346: error: âstruct
> > net_deviceâ has no member named âml_privâ
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c: In function âring_exitâ:
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4377: error: âstruct
> > net_deviceâ has no member named âml_privâ
> > /usr/src/PF_RING/PF_RING/kernel/pf_ring.c:4380: error: âstruct
> > net_deviceâ has no member named âml_privâ
> > make[2]: *** [/usr/src/PF_RING/PF_RING/kernel/pf_ring.o] Error 1
> > make[1]: *** [_module_/usr/src/PF_RING/PF_RING/kernel] Error 2
> > make[1]: Leaving directory `/usr/src/kernels/2.6.18-164.el5-x86_64'
> > make: *** [all] Error 2
> >
> >
> > On Wed, Oct 21, 2009 at 1:07 PM, Luca Deri wrote:
> >> Alexander
> >> I use .26 or .30 kernels so I can't say much about newer kernels. Can you
> >> please check if with older kernel it works for you? If this is the problem I
> >> need to get a newer kernel
> >>
> >> Luca
> >>
> >> On Oct 21, 2009, at 6:24 PM, Alexander Didebulidze wrote:
> >>
> >>> Hello Luca,
> >>>
> >>> I'm testing PF_RING on old dual Xeon machine...
> >>>
> >>> PF_RING compiles well with 2.6.31.4 and 2.6.32-rc5 and i can load module
> >>> without problems... but when i send traffic to this interface i get
> >>> kernel panic.
> >>>
> >>> Generator: pktgen , 64 byte , 1070910 PPS ~ 500 Mbit/s
> >>>
> >>> 1. without pf_ring , "tcpdump -i eth2 -w /dev/null": OK
> >>> 2. insmod pf_ring.ko, "pfcount -i eth2"            : Kernel Panic
> >>>
> >>> after several seconds after starting traffic generator server stoped
> >>> replying to ping. after remote reset/reboot i found this in syslog:
> >>>
> >>> http://pastebin.com/m3273c030
> >>>
> >>> this happens to 2.6.32-rc5 and 2.6.31.4 .
> >>>
> >>> in other test with pcount i got similar error :
> >>>
> >>> 604.063391] [PF_RING] successfully allocated 1388544 bytes at
> >>> 0xf8fe2000
> >>> [  604.063398] [PF_RING] allocated 4107 slots
> >>> [slot_len=338][tot_mem=1388544]
> >>> [  604.064160] device eth2 entered promiscuous mode
> >>> [  604.804323] pcount: page allocation failure. order:0, mode:0x20
> >>> [  604.804331] Pid: 4616, comm: pcount Not tainted 2.6.31.4 #1
> >>> [  604.804334] Call Trace:
> >>> [  604.804348]  [] ? printk+0x18/0x1c
> >>> [  604.804358]  [] __alloc_pages_nodemask+0x46b/0x530
> >>> [  604.804367]  [] __slab_alloc+0x4c6/0x560
> >>> [  604.804376]  [] ? __alloc_skb+0x29/0x120
> >>> [  604.804380]  [] kmem_cache_alloc+0x111/0x120
> >>> [  604.804385]  [] ? __alloc_skb+0x29/0x120
> >>> [  604.804389]  [] ? __alloc_skb+0x29/0x120
> >>> [  604.804393]  [] __alloc_skb+0x29/0x120
> >>> [  604.804398]  [] __netdev_alloc_skb+0x23/0x50
> >>> [  604.804430]  [] e1000_clean_rx_irq+0x33d/0x4c0 [e1000]
> >>> [  604.804446]  [] e1000_clean+0x1d0/0x530 [e1000]
> >>> [  604.804453]  [] ? getnstimeofday+0x56/0x110
> >>> [  604.804459]  [] ? lapic_next_event+0x16/0x20
> >>> [  604.804464]  [] ? clockevents_program_event+0x98/0x150
> >>> [  604.804471]  [] net_rx_action+0xdc/0x1b0
> >>> [  604.804478]  [] __do_softirq+0xba/0x180
> >>> [  604.804483]  [] ? handle_IRQ_event+0x58/0x140
> >>> [  604.804489]  [] ? ack_apic_level+0x7e/0x270
> >>> [  604.804494]  [] do_softirq+0x2d/0x40
> >>> [  604.804498]  [] irq_exit+0x65/0x90
> >>> [  604.804503]  [] do_IRQ+0x4f/0xc0
> >>> [  604.804508]  [] ? irq_exit+0x34/0x90
> >>> [  604.804512]  [] ? smp_apic_timer_interrupt+0x57/0x90
> >>> [  604.804517]  [] common_interrupt+0x29/0x30
> >>> [  604.804520] Mem-Info:
> >>> [  604.804523] DMA per-cpu:
> >>> [  604.804526] CPU    0: hi:    0, btch:  1 usd:  0
> >>> [  604.804529] CPU    1: hi:    0, btch:  1 usd:  0
> >>> [  604.804531] CPU    2: hi:    0, btch:  1 usd:  0
> >>> [  604.804534] CPU    3: hi:    0, btch:  1 usd:  0
> >>> [  604.804536] Normal per-cpu:
> >>> [  604.804539] CPU    0: hi:  186, btch:  31 usd:  49
> >>> [  604.804542] CPU    1: hi:  186, btch:  31 usd:  78
> >>> [  604.804544] CPU    2: hi:  186, btch:  31 usd:  35
> >>> [  604.804547] CPU    3: hi:  186, btch:  31 usd: 118
> >>> [  604.804549] HighMem per-cpu:
> >>> [  604.804552] CPU    0: hi:  42, btch:  7 usd:  8
> >>> [  604.804555] CPU    1: hi:  42, btch:  7 usd:  28
> >>> [  604.804557] CPU    2: hi:  42, btch:  7 usd:  7
> >>> [  604.804560] CPU    3: hi:  42, btch:  7 usd:  16
> >>> ...
> >>>
> >>> The problem seems to occur sooner with 500 mbit/s than with 200 mbit/s.
> >>>
> >>> Can other users confirm this problem with pf_ring 4.0?
> >>>
> >>>
> >>> Kind regards,
> >>> Alexander
> >>>
> >>>
> >>>
> >>> On Sun, 2009-10-18 at 22:00 +0200, Luca Deri wrote:
> >>>>
> >>>> Dear all
> >>>> this is to announce the release of PF_RING 4.0. Due to popular demand
> >>>> I have finally managed to build a new release of PF_RING that can be
> >>>> built on top of a vanilla kernel (please remember to download kernel
> >>>> source, that in general are available as package from your favorite
> >>>> Linux distribution) without patching the kernel as with PF_RING 3.0.
> >>>>
> >>>> This I think is a big improvement as those of you who have not yet
> >>>> adopted PF_RING due to kernel patching, can now finally use and enjoy
> >>>> it.
> >>>>
> >>>> As this is the first 4.x release, I believe there are still some
> >>>> issues that need to be addressed. Please report any problem you might
> >>>> experience.
> >>>>
> >>>> IMPORTANT: if you plan to use 4.0 on a *patched kernel* this is not a
> >>>> good idea as you will receive packets twice. Please use 4.0 with a
> >>>> vanilla kernel and not with a patched kernel.
> >>>>
> >>>> Enjoy Luca
> >>>> _______________________________________________
> >>>> Ntop-misc mailing list
> >>>> Ntop-misc [at] listgateway
> >>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Ntop-misc mailing list
> >>> Ntop-misc [at] listgateway
> >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
> >>
> >> _______________________________________________
> >> Ntop-misc mailing list
> >> Ntop-misc [at] listgateway
> >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
> >>
> > _______________________________________________
> > Ntop-misc mailing list
> > Ntop-misc [at] listgateway
> > http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc




_______________________________________________
Ntop-misc mailing list
Ntop-misc [at] listgateway
http://listgateway.unipi.it/mailman/listinfo/ntop-misc


ferdigy at gmail

Oct 25, 2009, 11:20 PM

Post #18 of 18 (1941 views)
Permalink
Re: Announce: PF_RING 4.0 (no kernel patching required) [In reply to]
Hi, Luca

Confirmed. The problem was fixed. Thanks!

On Sun, Oct 25, 2009 at 1:16 AM, Luca Deri <deri [at] ntop> wrote:

> Ferdy/Alexander
> i think i have fixed the bug. Please confirm
>
> Luca
>
>
> On Oct 22, 2009, at 4:08 PM, Ferdy wrote:
>
> Luca,
>>
>> I have a similar problem with Alexander. I'm using PF_RING 4.0 on kernel
>> 2.6.26.8 Dual Xeon CentOS 5.3 (32bit) when I ran pfcount -i eth2. After
>> several seconds the machine will become unresponsive.
>>
>> Oct 22 13:15:57 snortmachine kernel: [PF_RING] Welcome to PF_RING 4.0.0
>> Oct 22 13:15:57 snortmachine kernel: (C) 2004-09 L.Deri <deri [at] ntop>
>> Oct 22 13:15:57 snortmachine kernel: NET: Registered protocol family 27
>> Oct 22 13:15:57 snortmachine kernel: [PF_RING] Ring slots 4096
>> Oct 22 13:15:57 snortmachine kernel: [PF_RING] Slot version 10
>> Oct 22 13:15:57 snortmachine kernel: [PF_RING] Capture TX Yes
>> [RX+TX]
>> Oct 22 13:15:57 snortmachine kernel: [PF_RING] IP Defragment No
>> Oct 22 13:15:57 snortmachine kernel: [PF_RING] Initialized correctly
>> Oct 22 13:15:57 snortmachine kernel: [PF_RING] registered
>> /proc/net/pf_ring/
>> Oct 22 13:15:57 snortmachine kernel: [PF_RING] successfully allocated
>> 864256 bytes at 0xf8df6000
>> Oct 22 13:15:57 snortmachine kernel: [PF_RING] allocated 4114 slots
>> [slot_len=210][tot_mem=864256]
>> Oct 22 13:15:57 snortmachine kernel: device eth2 entered promiscuous mode
>> Oct 22 13:15:59 snortmachine kernel: swapper: page allocation failure.
>> order:0, mode:0x20
>> Oct 22 13:15:59 snortmachine kernel: Pid: 0, comm: swapper Not tainted
>> 2.6.26.8-1 #1
>> Oct 22 13:15:59 snortmachine kernel: [<c0452350>]
>> __alloc_pages_internal+0x338/0x34c
>> Oct 22 13:15:59 snortmachine kernel: [<c0452370>] __alloc_pages+0x7/0x9
>> Oct 22 13:15:59 snortmachine kernel: [<c0468715>]
>> cache_alloc_refill+0x245/0x43e
>> Oct 22 13:15:59 snortmachine kernel: [<c046897d>] __kmalloc+0x6f/0xa5
>> Oct 22 13:15:59 snortmachine kernel: [<c05a5f4e>] __alloc_skb+0x49/0xf7
>> Oct 22 13:15:59 snortmachine kernel: [<c05a6cca>]
>> __netdev_alloc_skb+0x14/0x2d
>> Oct 22 13:15:59 snortmachine kernel: [<f8946e08>]
>> e1000_alloc_rx_buffers+0x65/0x260 [e1000]
>> Oct 22 13:15:59 snortmachine kernel: [<f89473ee>]
>> e1000_clean_rx_irq+0x3eb/0x48d [e1000]
>> Oct 22 13:15:59 snortmachine kernel: [<f8947750>] e1000_clean+0x51/0x1d1
>> [e1000]
>> Oct 22 13:15:59 snortmachine kernel: [<c040420b>]
>> common_interrupt+0x23/0x28
>> Oct 22 13:15:59 snortmachine kernel: [<c05abb1d>]
>> net_rx_action+0x8a/0x141
>> Oct 22 13:15:59 snortmachine kernel: [<c04267e9>] __do_softirq+0x5d/0xc1
>> Oct 22 13:15:59 snortmachine kernel: [<c0405728>] do_softirq+0x52/0x84
>> Oct 22 13:15:59 snortmachine kernel: [<c0449456>]
>> handle_edge_irq+0x0/0xf8
>> Oct 22 13:15:59 snortmachine kernel: [<c040580c>] do_IRQ+0xb2/0xc6
>> Oct 22 13:15:59 snortmachine kernel: [<c040420b>]
>> common_interrupt+0x23/0x28
>> Oct 22 13:15:59 snortmachine kernel: [<c05217a5>]
>> acpi_safe_halt+0x18/0x25
>> Oct 22 13:15:59 snortmachine kernel: [<c052184a>]
>> acpi_idle_enter_c1+0x98/0xee
>> Oct 22 13:16:00 snortmachine kernel: [<c0592744>]
>> cpuidle_idle_call+0x52/0x7e
>> Oct 22 13:16:00 snortmachine kernel: [<c05926f2>]
>> cpuidle_idle_call+0x0/0x7e
>> Oct 22 13:16:00 snortmachine kernel: [<c0402534>] cpu_idle+0x88/0x9c
>> Oct 22 13:16:00 snortmachine kernel: =======================
>> <snip>
>> Oct 22 13:16:00 snortmachine kernel: Active:102707 inactive:34244
>> dirty:179 writeback:0 unstable:0
>> Oct 22 13:16:00 snortmachine kernel: free:1746670 slab:185960 mapped:1524
>> pagetables:186 bounce:0
>> Oct 22 13:16:00 snortmachine kernel: DMA free:3488kB min:68kB low:84kB
>> high:100kB active:0kB inactive:0kB present:16256kB p
>> ages_scanned:0 all_unreclaimable? yes
>> Oct 22 13:16:00 snortmachine kernel: lowmem_reserve[]: 0 873 8874 8874
>> Oct 22 13:16:00 snortmachine kernel: Normal free:1620kB min:3744kB
>> low:4680kB high:5616kB active:56972kB inactive:16344kB p
>> resent:894080kB pages_scanned:49 all_unreclaimable? no
>> Oct 22 13:16:00 snortmachine kernel: lowmem_reserve[]: 0 0 64008 64008
>> Oct 22 13:16:00 snortmachine kernel: HighMem free:6981572kB min:512kB
>> low:9096kB high:17684kB active:353856kB inactive:1206
>> 32kB present:8193024kB pages_scanned:0 all_unreclaimable? no
>> Oct 22 13:16:00 snortmachine kernel: lowmem_reserve[]: 0 0 0 0
>> Oct 22 13:16:00 snortmachine kernel: DMA: 2*4kB 3*8kB 2*16kB 3*32kB 0*64kB
>> 2*128kB 2*256kB 1*512kB 0*1024kB 1*2048kB 0*4096
>> kB = 3488kB
>> Oct 22 13:16:00 snortmachine kernel: Normal: 27*4kB 7*8kB 7*16kB 3*32kB
>> 0*64kB 0*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*
>> 4096kB = 1652kB
>> Oct 22 13:16:00 snortmachine kernel: HighMem: 201*4kB 3098*8kB 3375*16kB
>> 2643*32kB 1322*64kB 196*128kB 20*256kB 7*512kB 4*1
>> 024kB 3*2048kB 1633*4096kB = 6981572kB
>> Oct 22 13:16:00 snortmachine kernel: 132492 total pagecache pages
>> Oct 22 13:16:00 snortmachine kernel: Swap cache: add 0, delete 0, find 0/0
>> Oct 22 13:16:00 snortmachine kernel: Free swap = 5406712kB
>> Oct 22 13:16:00 snortmachine kernel: Total swap = 5406712kB
>> Oct 22 13:16:00 snortmachine kernel: 2293760 pages of RAM
>> Oct 22 13:16:00 snortmachine kernel: 2064384 pages of HIGHMEM
>> Oct 22 13:16:00 snortmachine kernel: 217322 reserved pages
>> Oct 22 13:16:00 snortmachine kernel: 27776 pages shared
>> Oct 22 13:16:00 snortmachine kernel: 0 pages swap cached
>> Oct 22 13:16:00 snortmachine kernel: 179 pages dirty
>> Oct 22 13:16:00 snortmachine kernel: 0 pages writeback
>> Oct 22 13:16:00 snortmachine kernel: 1524 pages mapped
>> Oct 22 13:16:00 snortmachine kernel: 185960 pages slab
>> Oct 22 13:16:00 snortmachine kernel: 186 pages pagetables
>> Oct 22 13:16:00 snortmachine kernel: swapper: page allocation failure.
>> order:0, mode:0x20
>> Oct 22 13:16:00 snortmachine kernel: Pid: 0, comm: swapper Not tainted
>> 2.6.26.8-1 #1
>> Oct 22 13:16:00 snortmachine kernel: [<c0452350>]
>> __alloc_pages_internal+0x338/0x34c
>> Oct 22 13:16:00 snortmachine kernel: [<c0452370>] __alloc_pages+0x7/0x9
>> Oct 22 13:16:00 snortmachine kernel: [<c0468715>]
>> cache_alloc_refill+0x245/0x43e
>> Oct 22 13:16:00 snortmachine kernel: [<c046897d>] __kmalloc+0x6f/0xa5
>> Oct 22 13:16:00 snortmachine kernel: [<c05a5f4e>] __alloc_skb+0x49/0xf7
>> Oct 22 13:16:00 snortmachine kernel: [<c05a6cca>]
>> __netdev_alloc_skb+0x14/0x2d
>> Oct 22 13:16:00 snortmachine kernel: [<f8946e08>]
>> e1000_alloc_rx_buffers+0x65/0x260 [e1000]
>> Oct 22 13:16:00 snortmachine kernel: [<f89473ee>]
>> e1000_clean_rx_irq+0x3eb/0x48d [e1000]
>> Oct 22 13:16:00 snortmachine kernel: [<f8947750>] e1000_clean+0x51/0x1d1
>> [e1000]
>> Oct 22 13:16:00 snortmachine kernel: [<c05abb1d>]
>> net_rx_action+0x8a/0x141
>> Oct 22 13:16:00 snortmachine kernel: [<c04267e9>] __do_softirq+0x5d/0xc1
>> Oct 22 13:16:00 snortmachine kernel: [<c0405728>] do_softirq+0x52/0x84
>> Oct 22 13:16:00 snortmachine kernel: [<c0449456>]
>> handle_edge_irq+0x0/0xf8
>> Oct 22 13:16:00 snortmachine kernel: [<c040580c>] do_IRQ+0xb2/0xc6
>> Oct 22 13:16:00 snortmachine kernel: [<c040420b>]
>> common_interrupt+0x23/0x28
>> Oct 22 13:16:00 snortmachine kernel: [<c05217a5>]
>> acpi_safe_halt+0x18/0x25
>> Oct 22 13:16:00 snortmachine kernel: [<c052184a>]
>> acpi_idle_enter_c1+0x98/0xee
>> Oct 22 13:16:00 snortmachine kernel: [<c0592744>]
>> cpuidle_idle_call+0x52/0x7e
>> Oct 22 13:16:00 snortmachine kernel: [<c05926f2>]
>> cpuidle_idle_call+0x0/0x7e
>> Oct 22 13:16:00 snortmachine kernel: [<c0402534>] cpu_idle+0x88/0x9c
>> Oct 22 13:16:00 snortmachine kernel: =======================
>>
>> -Ferdy
>>
>>
>>
>> _______________________________________________
>> Ntop-misc mailing list
>> Ntop-misc [at] listgateway
>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc [at] listgateway
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>

NTop misc RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.