Mailing List Archive: pf_ring zc init scripts on Ubuntu 16.04

I've previously installed pf_ring using DNA/Libzero from source and was
used to loading using a load_driver.sh type script. I'm building some
new systems on Ubuntu 16.04 and trying to install from the ntop stable
repo, but ran into a kernel panic with the ixgbe zc driver that hard
locked the system after a kernel update and dkms rebuild of the modules.
As I followed the instructions at
https://github.com/ntop/PF_RING/blob/dev/doc/README.apt_rpm_packages.md
I had setup .conf files in /etc/pf_ring/ and used the init script to
start pf_ring. This meant that the system booted into a hard-locked
state and I needed to boot into recovery mode to prevent pf_ring from
starting at boot.

The issue seemed to be fixed already in dev branch (for kernel 4.4.0-59
on Ubuntu anyways, haven't tested the latest Ubuntu patch yet), but my
concern is that loading pf_ring and the zc driver at boot could be
problematic again in the future if a kernel update breaks either kernel
module or dkms goes wrong. I saw on the mailing list that using the old
load_driver scripts is not really supported anymore, so I'm wondering
what options I have for either manually loading these safely with all
the command line options, or perhaps doing a delayed start at boot.

Also, outside of RSS, MTU, and hugepages, I couldn't find what options
the .conf files take. For instance is it still necessary to tweak values
such as which interfaces to enable (in the case of multiple ixgbe
cards), set hugepages per numa node, set numa_cpu_affinity per NIC, set
min_num_slots, disable tx capture etc?

~Gary

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

Hi Gary
said that if there is a problem with dkms it’s likely there is something wrong with the package and we have to fix it,
please note you prevent from pf_ring from loading at system boot by removing the .start file. In this case you have
to call the init.d script using forcestart instead of start as parameter for loading the driver.
In order to fix your current installation, please remove all packages and .ko files in your system (both for pf_ring and
the drivers and reinstall the package)

Alfredo

> On 8 Feb 2017, at 22:52, Gary Faulkner <gfaulkner.nsm@gmail.com> wrote:
>
> I've previously installed pf_ring using DNA/Libzero from source and was used to loading using a load_driver.sh type script. I'm building some new systems on Ubuntu 16.04 and trying to install from the ntop stable repo, but ran into a kernel panic with the ixgbe zc driver that hard locked the system after a kernel update and dkms rebuild of the modules. As I followed the instructions at https://github.com/ntop/PF_RING/blob/dev/doc/README.apt_rpm_packages.md I had setup .conf files in /etc/pf_ring/ and used the init script to start pf_ring. This meant that the system booted into a hard-locked state and I needed to boot into recovery mode to prevent pf_ring from starting at boot.
>
> The issue seemed to be fixed already in dev branch (for kernel 4.4.0-59 on Ubuntu anyways, haven't tested the latest Ubuntu patch yet), but my concern is that loading pf_ring and the zc driver at boot could be problematic again in the future if a kernel update breaks either kernel module or dkms goes wrong. I saw on the mailing list that using the old load_driver scripts is not really supported anymore, so I'm wondering what options I have for either manually loading these safely with all the command line options, or perhaps doing a delayed start at boot.
>
> Also, outside of RSS, MTU, and hugepages, I couldn't find what options the .conf files take. For instance is it still necessary to tweak values such as which interfaces to enable (in the case of multiple ixgbe cards), set hugepages per numa node, set numa_cpu_affinity per NIC, set min_num_slots, disable tx capture etc?
>
> ~Gary
>
> _______________________________________________
> Ntop-misc mailing list
> Ntop-misc@listgateway.unipi.it
> http://listgateway.unipi.it/mailman/listinfo/ntop-misc

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