[ovs-discuss] Problems in OVS kernel debugging with printk() and dump_stack()

Joe Stringer joe at ovn.org
Tue Dec 15 20:44:22 UTC 2015


On 14 December 2015 at 20:34, Allan Lue <ALue at federatedwireless.com> wrote:
> Hi,
>
> I have been trying to debug OVS kernel module with printk and stack_dump().
> Although Wireshark detects the tap
> interface (vnet0) receives ICMP packets I was never able to use printk or
> dump_stack() to trace the execution
> path. Ultimately I would like to track rx packets through all involved
> kernel and user functions, same for tx packets.
>
>
> It’s a Unubtu 14.04 system with OVS 2.4.0
>
>     allan at allan-i7A:~/openvswitch-2.4.0$ uname -a
>     Linux allan-i7A 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24
> 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>     allan at allan-i7A:~/openvswitch-2.4.0$
>
> I put printk() and dump_stack() in the following functions:
>
>     netdev_frame_hook()    vport-netdev.c
>     netdev_port_receive()   vport-netdev.c
>     ovs_vport_receive()      vport.c
>     ovs_vport_send()         vport.c
>     ovs_dp_process_packet     datapath.c
>
> the setup is very simple:
> A VirtualBox VM pings an OVS bridge (br100) device via vnet0,
>
>     Bridge "br100"
>         Port "vnet0"
>             Interface "vnet0"
>         Port "br100"
>             Interface "br100"
>                 type: internal
>
> vnet0 is added like this:
>     $ sudo ovs-vsctl add-br br100
>     $ sudo ip tuntap add mode tap vnet0
>     $ sudo ip link set vnet0 up
>     $ sudo ovs-vsctl add-port br100 vnet0
>
>
> Both "ovs-appctl dpctl/show –s" and “ifconfig” show br0 receives packets but
> vnet0 doesn’t, the inconsistent part
> is Wireshark show vnet0 receives packets.
>
>     sudo ovs-appctl dpctl/show -s
>         port 20: vnet0
>             RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>             TX packets:0 errors:0 dropped:5880 aborted:0 carrier:0
>             collisions:0
>             RX bytes:0  TX bytes:0
>         port 21: br100 (internal)
>             RX packets:143 errors:0 dropped:0 overruns:0 frame:0
>             TX packets:683 errors:0 dropped:29 aborted:0 carrier:0
>             collisions:0
>             RX bytes:16618 (16.2 KiB)  TX bytes:121064 (118.2 KiB)
>
>     allan at allan-i7A:~/openvswitch-2.4.0$ ifconfig
>     br100     Link encap:Ethernet  HWaddr 26:1a:55:0f:b6:47
>               inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
>               inet6 addr: fe80::241a:55ff:fe0f:b647/64 Scope:Link
>               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>               RX packets:561 errors:0 dropped:29 overruns:0 frame:0
>               TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
>               collisions:0 txqueuelen:0
>               RX bytes:100861 (100.8 KB)  TX bytes:14280 (14.2 KB)
>
>     vnet0     Link encap:Ethernet  HWaddr 16:59:1e:05:f8:e4
>                inet6 addr: fe80::1459:1eff:fe05:f8e4/64 Scope:Link
>               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>               RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>               TX packets:0 errors:0 dropped:5758 overruns:0 carrier:0
>               collisions:0 txqueuelen:500
>               RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>
> dmesg shows the VM is attached to vnet0 as expected,
>
>     allan at allan-i7A:~/openvswitch-2.4.0$ dmesg
>     [22035.615107] cfg80211:   (57240000 KHz - 63720000 KHz @ 2160000 KHz),
> (N/A, 4000 mBm), (N/A)
>     [23407.097108] vboxdrv: ffffffffc011b020 VMMR0.r0
>     [23407.195612] vboxdrv: ffffffffc0214020 VBoxDDR0.r0
>     [23407.196406] vboxdrv: ffffffffc0232020 VBoxDD2R0.r0
>     [23407.208611] VBoxNetFlt: attached to 'vnet0' / 16:59:1e:05:f8:e4
>     allan at allan-i7A:~/openvswitch-2.4.0$
>
>
> The questions are:
>
> Am I looking at the right codes for OVS receiving data path?
> Any issues with using printk() and dumo_stack() this way? Or what should I
> do?
> Any instructions to ensure or check packets from VM are processed by the
> kernel module will be appreciated

Are you sure that you have compiled and loaded the module that you
changed, rather than simply modprobing the version that was already
present in your distribution?

Using "insmod <path/to/openvswitch.ko>" is a good way to guarantee this.



More information about the discuss mailing list