and BMCR_PDOWN as well.
Signed-off-by: Weidong Wang <wangweido...@huawei.com>
---
the patch is evoluted from "phy: keep the BCMR_LOOPBACK bit
while setup forced mode".
---
drivers/net/phy/phy_device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ph
On 2016/4/14 2:41, Florian Fainelli wrote:
> On 13/04/16 04:59, Weidong Wang wrote:
>> When tested the PHY SGMII Loopback,:
>> 1.set the LOOPBACK bit,
>> 2.set the autoneg to AUTONEG_DISABLE, it calls the
>> genphy_setup_forced which will clear the bit.
>>
>&
On 2016/4/13 22:19, Sergei Shtylyov wrote:
> Hello.
>
> On 4/13/2016 2:59 PM, Weidong Wang wrote:
>
>> When tested the PHY SGMII Loopback,:
>> 1.set the LOOPBACK bit,
>> 2.set the autoneg to AUTONEG_DISABLE, it calls the
>> genphy_setup_forced which wi
When tested the PHY SGMII Loopback,:
1.set the LOOPBACK bit,
2.set the autoneg to AUTONEG_DISABLE, it calls the
genphy_setup_forced which will clear the bit.
So just keep the LOOPBACK bit while setup forced mode.
Signed-off-by: Weidong Wang <wangweido...@huawei.com>
---
drivers/n
When tested the PHY SGMII Loopback,:
1.set the LOOPBACK bit,
2.set the autoneg to AUTONEG_DISABLE, it calls the
genphy_setup_forced which will clear the bit.
So just keep the LOOPBACK bit while setup forced mode.
Signed-off-by: Weidong Wang <wangweido...@huawei.com>
---
drivers/n
In the 'for(...) {}', the *bucket alwasy < net->ct.htable_size,
so remove the check
Signed-off-by: Weidong Wang <wangweido...@huawei.com>
---
net/netfilter/nf_conntrack_core.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/net/netfilter/nf_conntra
On 2016/1/31 5:30, Florian Westphal wrote:
> Weidong Wang <wangweido...@huawei.com> wrote:
>> In the 'for(...) {}', the *bucket alwasy < net->ct.htable_size,
>> so remove the check
>> @@ -1383,14 +1383,12 @@ get_next_corpse(struct net *net, int (*iter)(
In bnx2_init_board, missing free temp_stats_blk on error path when
some operations do failed. Just add the 'kfree' operation.
Signed-off-by: Wang Weidong <wangweido...@huawei.com>
---
drivers/net/ethernet/broadcom/bnx2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/et
)
bnx2_free_mem
->bp->stats_blk = NULL
GET_64BIT_NET_STATS
then it will cause 'NULL Pointer' Problem.
it is as well with 'ethtool -S ethx'.
Allocate the statistics block at probe time so that this problem is
impossible
Signed-off-by: Wang Weidong <
we have two processes to do:
P1#: ifconfig eth0 down; which will call bnx2_close, then will
, and set Null to stats_blk
P2#: ifconfig eth0; which will call bnx2_get_stats64, it will
use stats_blk.
In one case:
--P1#-- --P2#--
stats_blk(no null)
)
bnx2_free_mem
->bp->stats_blk = NULL
GET_64BIT_NET_STATS
then it will cause 'NULL Pointer' Problem.
it is as well with 'ethtool -S ethx'.
Allocate the statistics block at probe time so that this problem is
impossible
Signed-off-by: Weidong Wang <
On 2015/9/28 15:01, Weidong Wang wrote:
> we have two processes to do:
> P1#: ifconfig eth0 down; which will call bnx2_close, then will
> , and set Null to stats_blk
> P2#: ifconfig eth0; which will call bnx2_get_stats64, it will
> use stats_blk.
> In one case:
> --P1#--
On 2015/9/24 13:34, David Miller wrote:
> From: Weidong Wang <wangweido...@huawei.com>
> Date: Thu, 24 Sep 2015 10:00:45 +0800
>
>> It does affect the intention. Although, the problem exists then makes the
>> system panic within some case.
>>
>> Do yo
On 2015/9/24 6:31, David Miller wrote:
> From: Weidong Wang <wangweido...@huawei.com>
> Date: Tue, 22 Sep 2015 20:42:40 +0800
>
>> @@ -880,6 +882,7 @@ bnx2_alloc_mem(struct bnx2 *bp)
>> }
>> }
>>
>> +spin_lock(>s
)
bnx2_free_mem
->bp->stats_blk = NULL
GET_64BIT_NET_STATS
then it will cause 'NULL Pointer' Problem.
it is as well with 'ethtool -S ethx'.
BTW, the other branch has this problem as well.
So we add a spin_lock to protect stats_blk.
Signed-off-by: Wang W
Mr David
Sorry to trouble many times, I will attention to this next time.
I have made this patch again, and I tried, it can be patched to the recently
kernel of linux-2.6.21.3. following is the patch, and I also attach this
patch to the attachment.
Signed-off-by: Wei Dong [EMAIL
Hi Mr. David
I have modified my patch according to you advice. I think -
EHOSTUNREACH
is only for input path. In output path, we can just simply check
-ENETUNREACH (^_^), the patch is shown in the end of this mail.
BTW: my E-mail has been changed to [EMAIL PROTECTED]
Function need to
Hi Mr. David
I have modified my patch according to you advice. I think -
EHOSTUNREACH is only for input path. In output path, we can just
simply check-ENETUNREACH (^_^), the patch is shown in the end of this mail.
BTW: my E-mail has been changed to [EMAIL PROTECTED]
Function need to
Hi Mr. David
I have modified my patch according to you advice. I think -
EHOSTUNREACH
is only for input path. In output path, we can just simply check
-ENETUNREACH (^_^), the patch is shown in the end of this mail.
BTW: my E-mail has been changed to [EMAIL PROTECTED]
Function need to
Hi, All
when I use linux TCP socket, and find there is a bug in function
sk_acceptq_is_full().
When a new SYN comes, TCP module first checks its validation. If valid,
send SYN,ACK to the client and add the sock to the syn hash table. Next
time if received the valid ACK for
Hi, All
When I tested Linux-2.6.20 and found that counter ipOutNoRoutes can
not increase correctly.
The criteria is RFC2011
ipOutNoRoutes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
The number of IP datagrams discarded
Hello, Mr yoshfuji:
Thanks for your reply.
The following is the figure.
||
||
| Router |
|||---|
| |--|
-0500), weidong [EMAIL PROTECTED] says:
The following is the figure.
:
Host eth0: fe80::200:ff:fe00:100
Router eth0: fe80::20c:29ff:fe24:fa0a
Router eth1: fe80::20c:29ff:fe24:fa14
Other network
|
| eth1
+++
| Router |
+++
| eth0
Hi, all
When I tested linux-2.6.19.2, and found maybe there're some packet
routing bugs in linux kernel. My test topology is shown as the
following:
eth0: fe80::20c:29ff:fe24:fa0a
| eth1: fe80::20c:29ff:fe24:fa14
|
Hi, all
When I tested linux-2.6.19.2, and found maybe there're a packet routing
bug in linux kernel. My test topology is shown as the following:
eth0: fe80::20c:29ff:fe24:fa0a
| eth1: fe80::20c:29ff:fe24:fa14
| |
Hi All:
When I tested linux kernel 2.6.18.3, and find that kernel statistics
about IPSTATS_MIB_OUTNOROUTES which exsits in file /proc/net/snmp
doesn't increase correctly. The criteria conform to RFC2011:
ipOutNoRoutes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
Hi, All
When I tested Linux kernel 2.6.17.7 about statistics
ipFragFails,found that this counter couldn't increase correctly. The
criteria is RFC2011:
RFC2011
ipFragFails OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
The
Hi, All
When I tested Linux kernel 2.6.17.7 about statistics
ipv6IfStatsInHdrErrors, found that this counter couldn't increase
correctly. The criteria is RFC2465:
ipv6IfStatsInHdrErrors OBJECT-TYPE
SYNTAX Counter3
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Hi, All
When I tested linux kernel 2.6.71.7 about statistics
ipv6IfStatsOutFragCreates, and found that it couldn't increase
correctly. The criteria is RFC 2465:
ipv6IfStatsOutFragCreates OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
29 matches
Mail list logo
