Re: [RFC 2/4] bpf, security: Add Checmate

Sure. Why are preempt_disable and rcu_read_lock used here? is there a great benefit of dong this? On Fri, Aug 5, 2016 at 3:05 PM, Sargun Dhillon <sar...@sargun.me> wrote: > On Thu, Aug 04, 2016 at 05:34:32PM +0800, zhuyj wrote: >> Sure. >> Is it better to add >>

Re: [RFC 2/4] bpf, security: Add Checmate

Sure. Why are preempt_disable and rcu_read_lock used here? is there a great benefit of dong this? On Fri, Aug 5, 2016 at 3:05 PM, Sargun Dhillon wrote: > On Thu, Aug 04, 2016 at 05:34:32PM +0800, zhuyj wrote: >> Sure. >> Is it better to add >> #ifndef CONFIG_PREEMPT_RCU

Re: [RFC PATCH v3 2/2] net: phy: Add gmiitorgmii converter support

+ switch (phydev->speed) { + case SPEED_1000: + val |= BMCR_SPEED1000; + case SPEED_100: + val |= BMCR_SPEED100; + } Are there only 2 kinds of speed? On Thu, Aug 4, 2016 at 8:13 PM, Kedareswara rao Appana wrote: >

Re: [RFC PATCH v3 2/2] net: phy: Add gmiitorgmii converter support

+ switch (phydev->speed) { + case SPEED_1000: + val |= BMCR_SPEED1000; + case SPEED_100: + val |= BMCR_SPEED100; + } Are there only 2 kinds of speed? On Thu, Aug 4, 2016 at 8:13 PM, Kedareswara rao Appana wrote: > This patch adds support for

Re: [RFC 2/4] bpf, security: Add Checmate

Sure. Is it better to add #ifndef CONFIG_PREEMPT_RCU ? On Thu, Aug 4, 2016 at 4:28 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > Please do not top post > > On Thu, 2016-08-04 at 16:08 +0800, zhuyj wrote: >> +void register_checmate_prog_ops(void); >&

Re: [RFC 2/4] bpf, security: Add Checmate

Sure. Is it better to add #ifndef CONFIG_PREEMPT_RCU ? On Thu, Aug 4, 2016 at 4:28 PM, Eric Dumazet wrote: > Please do not top post > > On Thu, 2016-08-04 at 16:08 +0800, zhuyj wrote: >> +void register_checmate_prog_ops(void); >> maybe it is extern void register_c

Re: [RFC 2/4] bpf, security: Add Checmate

+void register_checmate_prog_ops(void); maybe it is extern void register_checmate_prog_ops(void);? + preempt_disable(); + rcu_read_lock(); IMHO, it is not necessary to use the above 2 since rcu_read_lock will call preempt_disable. Zhu Yanjun On Thu, Aug 4, 2016 at 3:11 PM, Sargun

Re: [RFC 2/4] bpf, security: Add Checmate

+void register_checmate_prog_ops(void); maybe it is extern void register_checmate_prog_ops(void);? + preempt_disable(); + rcu_read_lock(); IMHO, it is not necessary to use the above 2 since rcu_read_lock will call preempt_disable. Zhu Yanjun On Thu, Aug 4, 2016 at 3:11 PM, Sargun

Re: [PATCH 1/1] net: qlcnic: avoid superfluous assignement

Sorry. An inline function will be inserted into the calling function. Why "Assigning NULL to parmeter dcb has no effect outside of the inlined function." ? On Sun, Jul 31, 2016 at 6:07 PM, Heinrich Schuchardt wrote: > Assigning NULL to parmeter dcb has no effect outside of

Re: [PATCH 1/1] net: qlcnic: avoid superfluous assignement

Sorry. An inline function will be inserted into the calling function. Why "Assigning NULL to parmeter dcb has no effect outside of the inlined function." ? On Sun, Jul 31, 2016 at 6:07 PM, Heinrich Schuchardt wrote: > Assigning NULL to parmeter dcb has no effect outside of the > inlined

Re: OOPS in nf_ct_unlink_expect_report using Polycom RealPresence Mobile

Please check the number of iptables rule. Maybe it results from the big number of iptables rules. Best Regards! Zhu Yanjun On 01/31/2014 09:17 PM, Mike Galbraith wrote: (CC netdev) On Fri, 2014-01-31 at 12:05 +0100, astx wrote: Using Polycom video conferencing software my homebrew linux NAT

Re: OOPS in nf_ct_unlink_expect_report using Polycom RealPresence Mobile

Please check the number of iptables rule. Maybe it results from the big number of iptables rules. Best Regards! Zhu Yanjun On 01/31/2014 09:17 PM, Mike Galbraith wrote: (CC netdev) On Fri, 2014-01-31 at 12:05 +0100, astx wrote: Using Polycom video conferencing software my homebrew linux NAT

Re: [PATCH] gianfar: disable vlan tag insertion by default on 2.6.x

On 10/15/2014 06:15 PM, yzhu1 wrote: On 10/15/2014 06:09 PM, Willy Tarreau wrote: Hi Zhu, On Wed, Oct 15, 2014 at 06:00:33PM +0800, Zhu Yanjun wrote: In commit f43c75d4b6[gianfar: disable TX vlan based on kernel 2.6.x], gianfar nic disables TX vlan. But gianfar nic enables vlan tag insertion

Re: [PATCH] gianfar: disable vlan tag insertion by default on 2.6.x

On 10/15/2014 06:15 PM, yzhu1 wrote: On 10/15/2014 06:09 PM, Willy Tarreau wrote: Hi Zhu, On Wed, Oct 15, 2014 at 06:00:33PM +0800, Zhu Yanjun wrote: In commit f43c75d4b6[gianfar: disable TX vlan based on kernel 2.6.x], gianfar nic disables TX vlan. But gianfar nic enables vlan tag insertion

Re: ipv4: net namespace does not inherit network configurations

01:48 AM, Cong Wang wrote: On Tue, Jul 29, 2014 at 2:29 AM, zhuyj wrote: Hi,all I did a test on kernel3.16 rc6: root@qemu1:~# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding root@qemu1:~# echo 1 > /proc/sys/net/ipv4/conf/all/forwarding root@qemu1:~# ip netns list root@qemu1:~# ip netns

Re: ipv4: net namespace does not inherit network configurations

, Cong Wang wrote: On Tue, Jul 29, 2014 at 2:29 AM, zhuyj zyjzyj2...@gmail.com wrote: Hi,all I did a test on kernel3.16 rc6: root@qemu1:~# echo 1 /proc/sys/net/ipv6/conf/all/forwarding root@qemu1:~# echo 1 /proc/sys/net/ipv4/conf/all/forwarding root@qemu1:~# ip netns list root@qemu1:~# ip netns

Re: access nand flash and mmc card at the same time on xlp board, there will be many io errors and system will hung

The root cause is that: sometimes device can not respond quickly to the request, the timeout mechanism will handle this. Solution: enlarge the device respond timeout to avoid kernel crash. Zhu Yanjun On 09/19/2014 05:06 PM, yzhu1 wrote: Hi, Chris I run a tests on a xlp208 board. This kernel

Re: access nand flash and mmc card at the same time on xlp board, there will be many io errors and system will hung

The root cause is that: sometimes device can not respond quickly to the request, the timeout mechanism will handle this. Solution: enlarge the device respond timeout to avoid kernel crash. Zhu Yanjun On 09/19/2014 05:06 PM, yzhu1 wrote: Hi, Chris I run a tests on a xlp208 board. This kernel

Re: SCTP_PEER_ADDR_CHANGE Notification over UNCONFIRMED path

Sorry. I used attachment to send patch. Maybe it is not convenient. Now I resend it again. Please ignore this mail. Best Regards! Zhu Yanjun On 08/15/2014 04:49 PM, zhuyj wrote: Hi, Vlad && DEEPAK && Michael && David From Michael && DEEPAK " lxr SCTP imp

SCTP_PEER_ADDR_CHANGE Notification over UNCONFIRMED path

Hi, Vlad && DEEPAK && Michael && David From Michael && DEEPAK " lxr SCTP implementation, doesn't transit the path state to INACTIVE, if it was never confirmed. this leads to SCTP_PEER_ADDRESS_CHANGE notification after each failed probe from this time. Is there any specific reason to have

SCTP_PEER_ADDR_CHANGE Notification over UNCONFIRMED path

Hi, Vlad DEEPAK Michael David From Michael DEEPAK lxr SCTP implementation, doesn't transit the path state to INACTIVE, if it was never confirmed. this leads to SCTP_PEER_ADDRESS_CHANGE notification after each failed probe from this time. Is there any specific reason to have same

Re: SCTP_PEER_ADDR_CHANGE Notification over UNCONFIRMED path

Sorry. I used attachment to send patch. Maybe it is not convenient. Now I resend it again. Please ignore this mail. Best Regards! Zhu Yanjun On 08/15/2014 04:49 PM, zhuyj wrote: Hi, Vlad DEEPAK Michael David From Michael DEEPAK lxr SCTP implementation, doesn't transit the path state

Re: ipv4: net namespace does not inherit network configurations

On 07/30/2014 01:48 AM, Cong Wang wrote: On Tue, Jul 29, 2014 at 2:29 AM, zhuyj wrote: Hi,all I did a test on kernel3.16 rc6: root@qemu1:~# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding root@qemu1:~# echo 1 > /proc/sys/net/ipv4/conf/all/forwarding root@qemu1:~# ip netns list root

Re: ipv4: net namespace does not inherit network configurations

On 07/30/2014 01:48 AM, Cong Wang wrote: On Tue, Jul 29, 2014 at 2:29 AM, zhuyj zyjzyj2...@gmail.com wrote: Hi,all I did a test on kernel3.16 rc6: root@qemu1:~# echo 1 /proc/sys/net/ipv6/conf/all/forwarding root@qemu1:~# echo 1 /proc/sys/net/ipv4/conf/all/forwarding root@qemu1:~# ip netns

ipv4: net namespace does not inherit network configurations

Hi,all I did a test on kernel3.16 rc6: root@qemu1:~# echo 1 > /proc/sys/net/ipv6/conf/all/forwarding root@qemu1:~# echo 1 > /proc/sys/net/ipv4/conf/all/forwarding root@qemu1:~# ip netns list root@qemu1:~# ip netns add fib1 root@qemu1:~# ip netns exec fib1 bash root@qemu1:~# cat

ipv4: net namespace does not inherit network configurations

Hi,all I did a test on kernel3.16 rc6: root@qemu1:~# echo 1 /proc/sys/net/ipv6/conf/all/forwarding root@qemu1:~# echo 1 /proc/sys/net/ipv4/conf/all/forwarding root@qemu1:~# ip netns list root@qemu1:~# ip netns add fib1 root@qemu1:~# ip netns exec fib1 bash root@qemu1:~# cat

Re: [PATCH 08/24] net, diet: Make TCP metrics optional

On 05/07/2014 02:33 AM, Cong Wang wrote: On Tue, May 6, 2014 at 10:55 AM, wrote: On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: From: j...@joshtriplett.org Date: Tue, 6 May 2014 09:41:08 -0700 Every KB of RAM costs real money and SoC die area (for eDRAM/eSRAM). Another

Re: [PATCH 08/24] net, diet: Make TCP metrics optional

On 05/07/2014 02:33 AM, Cong Wang wrote: On Tue, May 6, 2014 at 10:55 AM, j...@joshtriplett.org wrote: On Tue, May 06, 2014 at 01:16:43PM -0400, David Miller wrote: From: j...@joshtriplett.org Date: Tue, 6 May 2014 09:41:08 -0700 Every KB of RAM costs real money and SoC die area (for

Re: icmp: account for ICMP out errors because of socket limit

p6/* /proc/net/dev_snmp6/eth0:Icmp6OutErrors 0 /proc/net/dev_snmp6/lo:Icmp6OutErrors 0 Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Best Regards! Zhu Yanjun On 05/12/2014 11:19 AM, zhu

icmp: account for ICMP out errors because of socket limit

Hi, Eric && David __ || | | | PC |<--->| MIPS 32 core | || |__| When ping from a PC to a board (MIPS 32 core), because of socket limit, ping echo will fail. But ICMP_MIB_OUTERRORS counter is not incremented. In

icmp: account for ICMP out errors because of socket limit

Hi, Eric David __ || | | | PC |---| MIPS 32 core | || |__| When ping from a PC to a board (MIPS 32 core), because of socket limit, ping echo will fail. But ICMP_MIB_OUTERRORS counter is not incremented. In this

Re: icmp: account for ICMP out errors because of socket limit

/net/dev_snmp6/eth0:Icmp6OutErrors 0 /proc/net/dev_snmp6/lo:Icmp6OutErrors 0 Signed-off-by: Eric Dumazet eric.duma...@gmail.com Signed-off-by: David S. Miller da...@davemloft.net Best Regards! Zhu Yanjun On 05/12/2014 11:19 AM, zhuyj wrote

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On 04/24/2014 01:24 PM, Willy Tarreau wrote: On Thu, Apr 24, 2014 at 10:10:08AM +0800, zhuyj wrote: On 04/23/2014 07:41 PM, Ben Hutchings wrote: On Wed, 2014-04-23 at 15:48 +0800, zhuyj wrote: On 04/23/2014 01:53 AM, Ben Hutchings wrote: [...] For what it's worth, I would recommend against

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On 04/24/2014 01:24 PM, Willy Tarreau wrote: On Thu, Apr 24, 2014 at 10:10:08AM +0800, zhuyj wrote: On 04/23/2014 07:41 PM, Ben Hutchings wrote: On Wed, 2014-04-23 at 15:48 +0800, zhuyj wrote: On 04/23/2014 01:53 AM, Ben Hutchings wrote: [...] For what it's worth, I would recommend against

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On 04/23/2014 07:41 PM, Ben Hutchings wrote: On Wed, 2014-04-23 at 15:48 +0800, zhuyj wrote: On 04/23/2014 01:53 AM, Ben Hutchings wrote: [...] For what it's worth, I would recommend against applying this. I don't think even Red Hat has backported the VLAN changes, and they have been quite

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On 04/23/2014 01:53 AM, Ben Hutchings wrote: On Thu, 2014-04-17 at 07:02 +0200, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 17, 2014 at 11:35:58AM +0800, zhuyj wrote: Hi, all In kernel 2.6.x, linux depends on nic vlan hardware acceleration to insert/extract vlan tag. Hi, Ben Thanks for your

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On 04/23/2014 07:41 PM, Ben Hutchings wrote: On Wed, 2014-04-23 at 15:48 +0800, zhuyj wrote: On 04/23/2014 01:53 AM, Ben Hutchings wrote: [...] For what it's worth, I would recommend against applying this. I don't think even Red Hat has backported the VLAN changes, and they have been quite

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On 04/23/2014 01:53 AM, Ben Hutchings wrote: On Thu, 2014-04-17 at 07:02 +0200, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 17, 2014 at 11:35:58AM +0800, zhuyj wrote: Hi, all In kernel 2.6.x, linux depends on nic vlan hardware acceleration to insert/extract vlan tag. Hi, Ben Thanks for your

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On 04/17/2014 01:02 PM, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 17, 2014 at 11:35:58AM +0800, zhuyj wrote: Hi, all In kernel 2.6.x, linux depends on nic vlan hardware acceleration to insert/extract vlan tag. In this scene, in kernel 2.6.x

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On 04/17/2014 01:02 PM, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 17, 2014 at 11:35:58AM +0800, zhuyj wrote: Hi, all In kernel 2.6.x, linux depends on nic vlan hardware acceleration to insert/extract vlan tag. In this scene, in kernel 2.6.x

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

Although the maintainer will not merge these 2 patches, I still fix the mistakes in these 2 patches. Now the latest patches are in attachment. Maybe these patches can help others. The latest patches fix mistakes in rx stats. Best Regards! Zhu Yanjun On 04/17/2014 11:35 AM, zhuyj wrote: Hi

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

Hi, Jaso Would you like to code review these 2 patches? Thanks a lot. Zhu Yanjun On 04/17/2014 11:35 AM, zhuyj wrote: Hi, all In kernel 2.6.x, linux depends on nic vlan hardware acceleration to insert/extract vlan tag. In this scene, in kernel 2.6.x

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

Hi, Jaso Would you like to code review these 2 patches? Thanks a lot. Zhu Yanjun On 04/17/2014 11:35 AM, zhuyj wrote: Hi, all In kernel 2.6.x, linux depends on nic vlan hardware acceleration to insert/extract vlan tag. In this scene, in kernel 2.6.x

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

Although the maintainer will not merge these 2 patches, I still fix the mistakes in these 2 patches. Now the latest patches are in attachment. Maybe these patches can help others. The latest patches fix mistakes in rx stats. Best Regards! Zhu Yanjun On 04/17/2014 11:35 AM, zhuyj wrote: Hi

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On 04/17/2014 01:02 PM, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 17, 2014 at 11:35:58AM +0800, zhuyj wrote: Hi, all In kernel 2.6.x, linux depends on nic vlan hardware acceleration to insert/extract vlan tag. In this scene, in kernel 2.6.x

in kernel 2.6.x, tun/tap nic supports vlan packets

e: + kfree_skb(skb); + return NULL; +} + +static struct vlan_group *g_vlgrp = NULL; +static void tap_vlan_rx_register(struct net_device *dev, + struct vlan_group *grp) +{ + unsigned long flags; + local_irq_save(flags); + + printk(KERN_DEBUG "zhuyj func:%s,line:%d\n", __FUNCTION__, __LINE__

in kernel 2.6.x, tun/tap nic supports vlan packets

: + kfree_skb(skb); + return NULL; +} + +static struct vlan_group *g_vlgrp = NULL; +static void tap_vlan_rx_register(struct net_device *dev, + struct vlan_group *grp) +{ + unsigned long flags; + local_irq_save(flags); + + printk(KERN_DEBUG zhuyj func:%s,line:%d\n, __FUNCTION__, __LINE__); + g_vlgrp

Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On 04/17/2014 01:02 PM, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 17, 2014 at 11:35:58AM +0800, zhuyj wrote: Hi, all In kernel 2.6.x, linux depends on nic vlan hardware acceleration to insert/extract vlan tag. In this scene, in kernel 2.6.x

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

On 04/03/2014 06:01 PM, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote: I reference the following 2 mainline commits. These 2 commits are based on the current kernel 3.x and ethtool. If we only backport these 2 commits on kernel 2.6.x, this problem

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

On 04/03/2014 05:27 PM, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote: Hi, Claudiu Please help to review this patch. This patch is for kernel 2.6.x. Thanks a lot. Hi, Willy Please help to merge this patch to longterm: 2.6.32.61 since this problem also

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

On 04/03/2014 05:27 PM, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote: Hi, Claudiu Please help to review this patch. This patch is for kernel 2.6.x. Thanks a lot. Hi, Willy Please help to merge this patch to longterm: 2.6.32.61 since this problem also

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

able From 192.168.1.196 icmp_seq=3 Destination Host Unreachable Best Regards! Zhu Yanjun On 03/25/2014 01:08 PM, zhuyj wrote: Hi, Sandeep Gopalpet I am a developer. Now I confronted an interesting phenomena. When I used linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw and vla

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

192.168.1.196 icmp_seq=3 Destination Host Unreachable Best Regards! Zhu Yanjun On 03/25/2014 01:08 PM, zhuyj wrote: Hi, Sandeep Gopalpet I am a developer. Now I confronted an interesting phenomena. When I used linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw and vlan packets on gfar

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

On 04/03/2014 05:27 PM, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote: Hi, Claudiu Please help to review this patch. This patch is for kernel 2.6.x. Thanks a lot. Hi, Willy Please help to merge this patch to longterm: 2.6.32.61 since this problem also

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

On 04/03/2014 05:27 PM, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote: Hi, Claudiu Please help to review this patch. This patch is for kernel 2.6.x. Thanks a lot. Hi, Willy Please help to merge this patch to longterm: 2.6.32.61 since this problem also

Re: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

On 04/03/2014 06:01 PM, Willy Tarreau wrote: Hi Zhu, On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote: I reference the following 2 mainline commits. These 2 commits are based on the current kernel 3.x and ethtool. If we only backport these 2 commits on kernel 2.6.x, this problem

Re: ipv6:remove ipv6 global address after the interface is down

On 04/01/2014 05:35 PM, Hannes Frederic Sowa wrote: On Tue, Apr 01, 2014 at 05:30:31PM +0800, zhuyj wrote: Hi, Paul With kernel 2.6.34.x, the following problem will appear. TargetA - TargetB 3000::1/64 3000::2/64 TargetA - bring the interface down by doing

ipv6:remove ipv6 global address after the interface is down

Hi, Paul With kernel 2.6.34.x, the following problem will appear. TargetA - TargetB 3000::1/64 3000::2/64 TargetA - bring the interface down by doing an "ifconfig eth1 down" - bring the interface back up by doing an "ifconfig eth1 up" TargetB - ping6 3000::1

ipv6:remove ipv6 global address after the interface is down

Hi, Paul With kernel 2.6.34.x, the following problem will appear. TargetA - TargetB 3000::1/64 3000::2/64 TargetA - bring the interface down by doing an ifconfig eth1 down - bring the interface back up by doing an ifconfig eth1 up TargetB - ping6 3000::1

Re: ipv6:remove ipv6 global address after the interface is down

On 04/01/2014 05:35 PM, Hannes Frederic Sowa wrote: On Tue, Apr 01, 2014 at 05:30:31PM +0800, zhuyj wrote: Hi, Paul With kernel 2.6.34.x, the following problem will appear. TargetA - TargetB 3000::1/64 3000::2/64 TargetA - bring the interface down by doing

on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

Hi, Sandeep Gopalpet I am a developer. Now I confronted an interesting phenomena. When I used linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw and vlan packets on gfar-enet nic. But with e1000e nic, we can make vlan and raw packets work well. I looked into the source code and

on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

Hi, Sandeep Gopalpet I am a developer. Now I confronted an interesting phenomena. When I used linux kernel 2.6.34.15 on freescale-p2020, I can not receive raw and vlan packets on gfar-enet nic. But with e1000e nic, we can make vlan and raw packets work well. I looked into the source code and

Re: Suspend-resume tracing

On 02/21/2014 03:21 AM, Ryan wrote: Is there a way to trace suspend-resume without using ftrace and printk. Thanks. ryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: Suspend-resume tracing

On 02/21/2014 03:21 AM, Ryan wrote: Is there a way to trace suspend-resume without using ftrace and printk. Thanks. ryan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: How to identify 6to4 and 6in4 tunnels

On 01/28/2014 03:39 PM, zhuyj wrote: On 01/28/2014 03:32 PM, zhuyj wrote: On 01/27/2014 08:59 PM, Nicolas Dichtel wrote: Le 27/01/2014 11:39, zhuyj a écrit : Hi, Maintainers In our scene, we will create the 6in4/6to4 tunnel firstly and need to check the tunnel type, secondly, we

Re: How to identify 6to4 and 6in4 tunnels

On 01/28/2014 03:39 PM, zhuyj wrote: On 01/28/2014 03:32 PM, zhuyj wrote: On 01/27/2014 08:59 PM, Nicolas Dichtel wrote: Le 27/01/2014 11:39, zhuyj a écrit : Hi, Maintainers In our scene, we will create the 6in4/6to4 tunnel firstly and need to check the tunnel type, secondly, we

Re: How to identify 6to4 and 6in4 tunnels

On 01/28/2014 03:32 PM, zhuyj wrote: On 01/27/2014 08:59 PM, Nicolas Dichtel wrote: Le 27/01/2014 11:39, zhuyj a écrit : Hi, Maintainers In our scene, we will create the 6in4/6to4 tunnel firstly and need to check the tunnel type, secondly, we will configure the ip address on it. So, Could

Re: How to identify 6to4 and 6in4 tunnels

On 01/27/2014 08:59 PM, Nicolas Dichtel wrote: Le 27/01/2014 11:39, zhuyj a écrit : Hi, Maintainers In our scene, we will create the 6in4/6to4 tunnel firstly and need to check the tunnel type, secondly, we will configure the ip address on it. So, Could we have any way to get the actual

How to identify 6to4 and 6in4 tunnels

Hi, Maintainers In our scene, we will create the 6in4/6to4 tunnel firstly and need to check the tunnel type, secondly, we will configure the ip address on it. So, Could we have any way to get the actual tunnel for 6in4 and 6to4 from current linux version? Both 6in4 and 6to4 have the same

How to identify 6to4 and 6in4 tunnels

Hi, Maintainers In our scene, we will create the 6in4/6to4 tunnel firstly and need to check the tunnel type, secondly, we will configure the ip address on it. So, Could we have any way to get the actual tunnel for 6in4 and 6to4 from current linux version? Both 6in4 and 6to4 have the same

Re: How to identify 6to4 and 6in4 tunnels

On 01/27/2014 08:59 PM, Nicolas Dichtel wrote: Le 27/01/2014 11:39, zhuyj a écrit : Hi, Maintainers In our scene, we will create the 6in4/6to4 tunnel firstly and need to check the tunnel type, secondly, we will configure the ip address on it. So, Could we have any way to get the actual

Re: How to identify 6to4 and 6in4 tunnels

On 01/28/2014 03:32 PM, zhuyj wrote: On 01/27/2014 08:59 PM, Nicolas Dichtel wrote: Le 27/01/2014 11:39, zhuyj a écrit : Hi, Maintainers In our scene, we will create the 6in4/6to4 tunnel firstly and need to check the tunnel type, secondly, we will configure the ip address on it. So, Could

Re: How to identify different ip tunnels

The version of the kernel is 3.4.43. Any reply is appreciated. Best Regards! Zhu Yanjun On 01/23/2014 03:33 PM, zhuyj wrote: Hi, Maintainers We want to identify different ip tunnels. For example, we use “ip tunnel add xxx” command in linux to create an ipv4/6 tunnel interface,then,we can

Re: How to identify different ip tunnels

The version of the kernel is 3.4.43. Any reply is appreciated. Best Regards! Zhu Yanjun On 01/23/2014 03:33 PM, zhuyj wrote: Hi, Maintainers We want to identify different ip tunnels. For example, we use “ip tunnel add xxx” command in linux to create an ipv4/6 tunnel interface,then,we can

How to identify different ip tunnels

Hi, Maintainers We want to identify different ip tunnels. For example, we use “ip tunnel add xxx” command in linux to create an ipv4/6 tunnel interface,then,we can receive a RTM_NEWLINK message from linux for the new tunnel interface. We will parse the struct ifinfomsg message and get the

How to identify different ip tunnels

Hi, Maintainers We want to identify different ip tunnels. For example, we use “ip tunnel add xxx” command in linux to create an ipv4/6 tunnel interface,then,we can receive a RTM_NEWLINK message from linux for the new tunnel interface. We will parse the struct ifinfomsg message and get the

Re: [ 163/171 ] ipv6: fix bad free of addrconf_init_net

On 04/12/2013 04:27 AM, Steven Rostedt wrote: On linux with stable kernel v3.4.39, when this patch (ipv6: fix bad free of addrconf_init_net) is applied. Then I run the following commands: 1. the default value of ipv6 forwarding is 0 2. we change it to 1 firstly via: # vi /etc/sysctl.conf

Re: [ 163/171 ] ipv6: fix bad free of addrconf_init_net

On 04/12/2013 04:27 AM, Steven Rostedt wrote: On linux with stable kernel v3.4.39, when this patch (ipv6: fix bad free of addrconf_init_net) is applied. Then I run the following commands: 1. the default value of ipv6 forwarding is 0 2. we change it to 1 firstly via: # vi /etc/sysctl.conf

[PATCH 1/1] ipv6:remove ipv6 global address after the interface is down

int event, struct inet6_ifaddr *ifp) addrconf_leave_solict(ifp->idev, >addr); dst_hold(>rt->u.dst); - if (ifp->state == INET6_IFADDR_STATE_DEAD && - ip6_del_rt(ifp->rt)) + if (ip6_del_rt(ifp->rt))

ipv6 global address remains while route item disappears after this interface is restared in 2.6.34.x

"ping6 3000::1" can not succeed. Compared with 3.4.x, ipv6 address and ipv6 route item are removed when an interface is restarted in the. Best Regards! zhuyj -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger

ipv6 global address remains while route item disappears after this interface is restared in 2.6.34.x

. Compared with 3.4.x, ipv6 address and ipv6 route item are removed when an interface is restarted in the. Best Regards! zhuyj -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

[PATCH 1/1] ipv6:remove ipv6 global address after the interface is down

); dst_hold(ifp-rt-u.dst); - if (ifp-state == INET6_IFADDR_STATE_DEAD - ip6_del_rt(ifp-rt)) + if (ip6_del_rt(ifp-rt)) dst_free(ifp-rt-u.dst); break; } On 08/26/2013 10:28 AM, zhuyj wrote: With two

Re: listing drivers

On 01/22/2013 10:27 PM, Arend van Spriel wrote: On 01/22/2013 02:46 PM, Thiago Farina wrote: Hi folks, Is there a way to list the drivers installed/used in my desktop and map them (the path) to their source code in the linux kernel tree? This might work for you (if using bash): for m in

Re: listing drivers

On 01/22/2013 10:27 PM, Arend van Spriel wrote: On 01/22/2013 02:46 PM, Thiago Farina wrote: Hi folks, Is there a way to list the drivers installed/used in my desktop and map them (the path) to their source code in the linux kernel tree? This might work for you (if using bash): for m in