* Re: [PATCH v2] xfrm: Fix initialize repl field of struct xfrm_state
From: David Miller @ 2011-03-21 8:01 UTC (permalink / raw)
To: yjwei; +Cc: netdev, steffen.klassert
In-Reply-To: <20110321.010037.59680394.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 21 Mar 2011 01:00:37 -0700 (PDT)
> From: Wei Yongjun <yjwei@cn.fujitsu.com>
> Date: Mon, 21 Mar 2011 15:44:03 +0800
>
>> -int xfrm_init_state(struct xfrm_state *x)
>> +int __xfrm_init_state(struct xfrm_state *x, bool init_replay)
>
> Since it is referenced by modules, this new function symbol must
> be exported to them.
BTW, this is one of the reasons I explicitly mentioned to make
this an inline function. :-)
^ permalink raw reply
* Re: [PATCH v2] net: add Faraday FTGMAC100 Gigabit Ethernet driver
From: Eric Dumazet @ 2011-03-21 8:19 UTC (permalink / raw)
To: Po-Yu Chuang; +Cc: netdev, linux-kernel, ratbert
In-Reply-To: <AANLkTinibrF_bJBbYwCSnGv1iD_9Dn7uBn2cqgcTrKHi@mail.gmail.com>
Le lundi 21 mars 2011 à 15:54 +0800, Po-Yu Chuang a écrit :
> It seems to work fine so far at least the driver is not broken, but I did not
> see much difference in performance though. How do I know if GRO is
> working indeed?
maybe you receive one interrupt per incoming frame, and your cpu is fast
enough to handle the load.
tcpdump should show big incoming TCP frames (multi segment)
(GRO only helps TCP receivers)
Example here :
09:16:32.372949 IP 192.168.20.110.55446 > 192.168.20.108.ssh: .
2372863:2374311(1448) ack 3136 win 73 <nop,nop,timestamp 317934201
257881345>
09:16:32.372975 IP 192.168.20.110.55446 > 192.168.20.108.ssh: .
2374311:2377207(2896) ack 3136 win 73 <nop,nop,timestamp 317934201
257881345>
Here, you can see GRO work, since 2nd "frame" is the result of two MTU
sized frames.
^ permalink raw reply
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: Steffen Klassert @ 2011-03-21 8:25 UTC (permalink / raw)
To: David Miller; +Cc: yjwei, netdev
In-Reply-To: <20110320.234606.183056322.davem@davemloft.net>
On Sun, Mar 20, 2011 at 11:46:06PM -0700, David Miller wrote:
>
> Ok, thanks for the explanation.
>
> I think there is a simple way out of this:
>
> 1) Rename current xfrm_init_state to __xfrm_init_state, add
> "bool init_replay" argument. Add the xfrm_init_replay()
> call, as in your patch, but conditionalized on this boolean.
>
> 2) Implement xfrm_init_state as inline, which calls
> __xfrm_init_state(..., true)
>
> 3) Replace xfrm_init_state() call in xfrm_user.c with
> __xfrm_init_state(..., false)
>
> This seems to avoid all the problems. We don't need to touch every
> caller, and we avoid initializing the replay state twice in xfrm_user
>
Btw, looking a bit closer to this. I think it would look a bit cleaner
if we would add the xfrm_init_replay() call to xfrm_init_state() and
to move the xfrm_init_state() call in xfrm_state_construct() behind
the assign of the replay settings.
^ permalink raw reply
* [PATCH v3] xfrm: Fix initialize repl field of struct xfrm_state
From: Wei Yongjun @ 2011-03-21 8:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, steffen.klassert
In-Reply-To: <20110321.010037.59680394.davem@davemloft.net>
Commit 'xfrm: Move IPsec replay detection functions to a separate file'
(9fdc4883d92d20842c5acea77a4a21bb1574b495)
introduce repl field to struct xfrm_state, and only initialize it
under SA's netlink create path, the other path, such as pf_key,
ipcomp/ipcomp6 etc, the repl field remaining uninitialize. So if
the SA is created by pf_key, any input packet with SA's encryption
algorithm will cause panic.
int xfrm_input()
{
...
x->repl->advance(x, seq);
...
}
This patch fixed it by introduce new function __xfrm_init_state().
Pid: 0, comm: swapper Not tainted 2.6.38-next+ #14 Bochs Bochs
EIP: 0060:[<c078e5d5>] EFLAGS: 00010206 CPU: 0
EIP is at xfrm_input+0x31c/0x4cc
EAX: dd839c00 EBX: 00000084 ECX: 00000000 EDX: 01000000
ESI: dd839c00 EDI: de3a0780 EBP: dec1de88 ESP: dec1de64
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper (pid: 0, ti=dec1c000 task=c09c0f20 task.ti=c0992000)
Stack:
00000000 00000000 00000002 c0ba27c0 00100000 01000000 de3a0798 c0ba27c0
00000033 dec1de98 c0786848 00000000 de3a0780 dec1dea4 c0786868 00000000
dec1debc c074ee56 e1da6b8c de3a0780 c074ed44 de3a07a8 dec1decc c074ef32
Call Trace:
[<c0786848>] xfrm4_rcv_encap+0x22/0x27
[<c0786868>] xfrm4_rcv+0x1b/0x1d
[<c074ee56>] ip_local_deliver_finish+0x112/0x1b1
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074ef77>] ip_local_deliver+0x3e/0x44
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ec03>] ip_rcv_finish+0x30a/0x332
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074f188>] ip_rcv+0x20b/0x247
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c072797d>] __netif_receive_skb+0x373/0x399
[<c0727bc1>] netif_receive_skb+0x4b/0x51
[<e0817e2a>] cp_rx_poll+0x210/0x2c4 [8139cp]
[<c072818f>] net_rx_action+0x9a/0x17d
[<c0445b5c>] __do_softirq+0xa1/0x149
[<c0445abb>] ? __do_softirq+0x0/0x149
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
Changelog:
v2 -> v3 export __xfrm_init_state().
---
include/net/xfrm.h | 1 +
net/xfrm/xfrm_state.c | 15 ++++++++++++++-
net/xfrm/xfrm_user.c | 2 +-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 42a8c32..cffa5dc 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1430,6 +1430,7 @@ extern void xfrm_spd_getinfo(struct net *net, struct xfrmk_spdinfo *si);
extern u32 xfrm_replay_seqhi(struct xfrm_state *x, __be32 net_seq);
extern int xfrm_init_replay(struct xfrm_state *x);
extern int xfrm_state_mtu(struct xfrm_state *x, int mtu);
+extern int __xfrm_init_state(struct xfrm_state *x, bool init_replay);
extern int xfrm_init_state(struct xfrm_state *x);
extern int xfrm_prepare_input(struct xfrm_state *x, struct sk_buff *skb);
extern int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi,
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index d575f05..f83a3d1 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1907,7 +1907,7 @@ int xfrm_state_mtu(struct xfrm_state *x, int mtu)
return res;
}
-int xfrm_init_state(struct xfrm_state *x)
+int __xfrm_init_state(struct xfrm_state *x, bool init_replay)
{
struct xfrm_state_afinfo *afinfo;
struct xfrm_mode *inner_mode;
@@ -1980,12 +1980,25 @@ int xfrm_init_state(struct xfrm_state *x)
if (x->outer_mode == NULL)
goto error;
+ if (init_replay) {
+ err = xfrm_init_replay(x);
+ if (err)
+ goto error;
+ }
+
x->km.state = XFRM_STATE_VALID;
error:
return err;
}
+EXPORT_SYMBOL(__xfrm_init_state);
+
+int xfrm_init_state(struct xfrm_state *x)
+{
+ return __xfrm_init_state(x, true);
+}
+
EXPORT_SYMBOL(xfrm_init_state);
int __net_init xfrm_state_init(struct net *net)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 706385a..fc152d2 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -511,7 +511,7 @@ static struct xfrm_state *xfrm_state_construct(struct net *net,
xfrm_mark_get(attrs, &x->mark);
- err = xfrm_init_state(x);
+ err = __xfrm_init_state(x, false);
if (err)
goto error;
--
1.6.5.2
^ permalink raw reply related
* RE: [PATCH] Fix "possible circular locking dependency" in rfcomm
From: Ferraton, Jean RegisX @ 2011-03-21 8:43 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: marcel@holtmann.org, davem@davemloft.net, eric.dumazet@gmail.com,
xiaosuo@gmail.com, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <6E42A1B4DD2F7B4D80A1F26BB498BF9F8C9F8C1539@irsmsx501.ger.corp.intel.com>
Any comment?
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Ferraton, Jean RegisX
> Sent: Monday, March 14, 2011 3:56 PM
> To: Gustavo F. Padovan
> Cc: marcel@holtmann.org; davem@davemloft.net; eric.dumazet@gmail.com;
> xiaosuo@gmail.com; linux-bluetooth@vger.kernel.org; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org
> Subject: [PATCH] Fix "possible circular locking dependency" in rfcomm
>
> No response from original post, submit again, more details below:
>
> Changes in sock.c in function __rfcomm_sock_close, to release sock before
> calling rfcomm_dlc_close to avoid possible deadlock when calling
> rfcomm_lock (in rfcomm_dlc_close).
>
> Signed-off-by: Jean Regis Ferraton <jrferraton@gmail.com>
>
> ---
> net/bluetooth/rfcomm/sock.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> index 66cc1f0..3b5ec09 100644
> --- a/net/bluetooth/rfcomm/sock.c
> +++ b/net/bluetooth/rfcomm/sock.c
> @@ -234,7 +234,10 @@ static void __rfcomm_sock_close(struct sock *sk)
> case BT_CONNECT2:
> case BT_CONFIG:
> case BT_CONNECTED:
> + /* release_sock to avoid deadlock when calling rfcomm_lock()
> */
> + release_sock(sk);
> rfcomm_dlc_close(d, 0);
> + lock_sock(sk);
>
> default:
> sock_set_flag(sk, SOCK_ZAPPED);
> --
> 1.6.2.5
>
>
>
> This patch solves a problem of "possible circular locking dependency"
> related to rfcomm. Problem seen on kernel 2.6.37. Maybe it's not a bug,
> just a warning, see the trace below.
>
> This problem occurs in 2 cases:
> 1- When initiating a connection from the remote device
> 2- When browsing my BT device from my PC
>
> My analysis is the following:
> 1- We call the function rfcomm_sock_shutdown() which locks a socket, an
> after calls __rfcomm_sock_close()
> lock_sock(sk);
> if (!sk->sk_shutdown) {
> sk->sk_shutdown = SHUTDOWN_MASK;
> __rfcomm_sock_close(sk);
> 2- In the function __rfcomm_sock_close(), we call rfcomm_dlc_close()
> case BT_CONNECTED:
> rfcomm_dlc_close(d, 0);
> 3- In the function rfcomm_dlc_close(), we call rfcomm_lock() which locks a
> mutex on rfcomm, and this second lock causes the problem.
> rfcomm_lock();
> r = __rfcomm_dlc_close(d, err);
>
> My message trace is the following (for remote connect):
> [ 113.995511] =======================================================
> [ 114.001897] [ INFO: possible circular locking dependency detected ]
> [ 114.008157] 2.6.37.3jrf_fix #1
> [ 114.011196] -------------------------------------------------------
> [ 114.017457] bluetoothd/511 is trying to acquire lock:
> [ 114.022499] (rfcomm_mutex){+.+.+.}, at: [<c14f281a>]
> rfcomm_dlc_close+0x15/0x30
> [ 114.029887]
> [ 114.029892] but task is already holding lock:
> [ 114.035713] (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c14f4cfe>]
> rfcomm_sock_shutdown+0x17/0x5d
> [ 114.044147]
> [ 114.044152] which lock already depends on the new lock.
> [ 114.044158]
> [ 114.052319]
> [ 114.052324] the existing dependency chain (in reverse order) is:
> [ 114.059796]
> [ 114.059801] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
> [ 114.065967] [<c105d660>] lock_acquire+0xf9/0x135
> [ 114.071184] [<c1445cf3>] lock_sock_nested+0x55/0x65
> [ 114.076662] [<c14ed17d>] l2cap_sock_sendmsg+0x3f/0x606
> [ 114.082400] [<c1443775>] sock_sendmsg+0xc9/0xe0
> [ 114.087530] [<c14437b4>] kernel_sendmsg+0x28/0x37
> [ 114.092833] [<c14f2278>] rfcomm_send_frame+0x2f/0x37
> [ 114.098398] [<c14f232c>] rfcomm_send_ua+0x57/0x59
> [ 114.103701] [<c14f3884>] rfcomm_run+0x431/0xb06
> [ 114.108830] [<c104bc8f>] kthread+0x5f/0x64
> [ 114.113525] [<c1002b7a>] kernel_thread_helper+0x6/0x1a
> [ 114.119265]
> [ 114.119270] -> #0 (rfcomm_mutex){+.+.+.}:
> [ 114.124739] [<c105cff1>] __lock_acquire+0xe03/0x1379
> [ 114.130304] [<c105d660>] lock_acquire+0xf9/0x135
> [ 114.135522] [<c1522bf3>] mutex_lock_nested+0x45/0x286
> [ 114.141171] [<c14f281a>] rfcomm_dlc_close+0x15/0x30
> [ 114.146650] [<c14f4cdb>] __rfcomm_sock_close+0x5e/0x6a
> [ 114.152388] [<c14f4d12>] rfcomm_sock_shutdown+0x2b/0x5d
> [ 114.158212] [<c14f4d5d>] rfcomm_sock_release+0x19/0x60
> [ 114.163951] [<c14445da>] sock_release+0x14/0x5b
> [ 114.169080] [<c144463d>] sock_close+0x1c/0x20
> [ 114.174037] [<c10bdd19>] fput+0xfa/0x19e
> [ 114.178557] [<c10bb3c5>] filp_close+0x51/0x5b
> [ 114.183512] [<c10bb488>] sys_close+0xb9/0xee
> [ 114.188381] [<c1002650>] sysenter_do_call+0x12/0x36
> [ 114.193858]
> [ 114.193863] other info that might help us debug this:
> [ 114.193870]
> [ 114.201860] 1 lock held by bluetoothd/511:
> [ 114.205945] #0: (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c14f4cfe>]
> rfcomm_sock_shutdown+0x17/0x5d
> [ 114.214811]
> [ 114.214816] stack backtrace:
> [ 114.219167] Pid: 511, comm: bluetoothd Tainted: G WC
> 2.6.37.3jrf_fix #1
> [ 114.226463] Call Trace:
> [ 114.228913] [<c152108a>] ? printk+0xf/0x11
> [ 114.233086] [<c105bc3b>] print_circular_bug+0x90/0x9c
> [ 114.238211] [<c105cff1>] __lock_acquire+0xe03/0x1379
> [ 114.243260] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
> [ 114.248382] [<c105d660>] lock_acquire+0xf9/0x135
> [ 114.253079] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
> [ 114.258208] [<c1522bf3>] mutex_lock_nested+0x45/0x286
> [ 114.263338] [<c14f281a>] ? rfcomm_dlc_close+0x15/0x30
> [ 114.268469] [<c105b68d>] ? trace_hardirqs_on_caller+0x100/0x121
> [ 114.274467] [<c1445cf8>] ? lock_sock_nested+0x5a/0x65
> [ 114.279597] [<c105b6b9>] ? trace_hardirqs_on+0xb/0xd
> [ 114.284639] [<c14f281a>] rfcomm_dlc_close+0x15/0x30
> [ 114.289594] [<c14f4cdb>] __rfcomm_sock_close+0x5e/0x6a
> [ 114.294811] [<c14f4d12>] rfcomm_sock_shutdown+0x2b/0x5d
> [ 114.300115] [<c14f4d5d>] rfcomm_sock_release+0x19/0x60
> [ 114.305331] [<c14445da>] sock_release+0x14/0x5b
> [ 114.309937] [<c144463d>] sock_close+0x1c/0x20
> [ 114.314373] [<c10bdd19>] fput+0xfa/0x19e
> [ 114.318371] [<c10bb3c5>] filp_close+0x51/0x5b
> [ 114.322804] [<c10bb488>] sys_close+0xb9/0xee
> [ 114.327151] [<c1002650>] sysenter_do_call+0x12/0x36
> ---------------------------------------------------------------------
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris,
> 92196 Meudon Cedex, France
> Registration Number: 302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: Wei Yongjun @ 2011-03-21 9:10 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <20110321082512.GB27581@secunet.com>
> On Sun, Mar 20, 2011 at 11:46:06PM -0700, David Miller wrote:
>> Ok, thanks for the explanation.
>>
>> I think there is a simple way out of this:
>>
>> 1) Rename current xfrm_init_state to __xfrm_init_state, add
>> "bool init_replay" argument. Add the xfrm_init_replay()
>> call, as in your patch, but conditionalized on this boolean.
>>
>> 2) Implement xfrm_init_state as inline, which calls
>> __xfrm_init_state(..., true)
>>
>> 3) Replace xfrm_init_state() call in xfrm_user.c with
>> __xfrm_init_state(..., false)
>>
>> This seems to avoid all the problems. We don't need to touch every
>> caller, and we avoid initializing the replay state twice in xfrm_user
>>
> Btw, looking a bit closer to this. I think it would look a bit cleaner
> if we would add the xfrm_init_replay() call to xfrm_init_state() and
> to move the xfrm_init_state() call in xfrm_state_construct() behind
> the assign of the replay settings.
The xfrm_init_replay() should be call after the call to
xfrm_update_ae_params(x, attrs);
since xfrm_update_ae_params() may update the replay_esn.
So we need move the xfrm_init_state() call just before return x.
The other issue:
static void xfrm_update_ae_params()
{
...
memcpy(x->replay_esn, replay_esn,
xfrm_replay_state_esn_len(replay_esn));
...
}
the memcpy() may cause memory overlap if we build a special
nl_data, we should free it and then do kmemdup()?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: Wei Yongjun @ 2011-03-21 9:18 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David Miller, netdev
In-Reply-To: <4D871607.6090508@cn.fujitsu.com>
>> On Sun, Mar 20, 2011 at 11:46:06PM -0700, David Miller wrote:
>>> Ok, thanks for the explanation.
>>>
>>> I think there is a simple way out of this:
>>>
>>> 1) Rename current xfrm_init_state to __xfrm_init_state, add
>>> "bool init_replay" argument. Add the xfrm_init_replay()
>>> call, as in your patch, but conditionalized on this boolean.
>>>
>>> 2) Implement xfrm_init_state as inline, which calls
>>> __xfrm_init_state(..., true)
>>>
>>> 3) Replace xfrm_init_state() call in xfrm_user.c with
>>> __xfrm_init_state(..., false)
>>>
>>> This seems to avoid all the problems. We don't need to touch every
>>> caller, and we avoid initializing the replay state twice in xfrm_user
>>>
>> Btw, looking a bit closer to this. I think it would look a bit cleaner
>> if we would add the xfrm_init_replay() call to xfrm_init_state() and
>> to move the xfrm_init_state() call in xfrm_state_construct() behind
>> the assign of the replay settings.
> The xfrm_init_replay() should be call after the call to
> xfrm_update_ae_params(x, attrs);
> since xfrm_update_ae_params() may update the replay_esn.
>
> So we need move the xfrm_init_state() call just before return x.
Oh, sorry, the memcpy looks like dup code since we used
kmemdup. It is the same attr XFRMA_REPLAY_ESN_VAL.
> The other issue:
> static void xfrm_update_ae_params()
> {
> ...
> memcpy(x->replay_esn, replay_esn,
> xfrm_replay_state_esn_len(replay_esn));
> ...
> }
>
> the memcpy() may cause memory overlap if we build a special
> nl_data, we should free it and then do kmemdup()?
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: LRO disable warnings on kernel 2.6.38
From: Jesper Dangaard Brouer @ 2011-03-21 9:21 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, Eric Dumazet, Neil Horman
In-Reply-To: <4D8385CE.1060205@intel.com>
On Fri, 2011-03-18 at 09:18 -0700, Alexander Duyck wrote:
> On 3/18/2011 4:12 AM, Jesper Dangaard Brouer wrote:
> > Hi
> >
> > I'm seeing the LRO disable warnings using kernel 2.6.38:
[...]
> >
> The error doesn't make any sense for igb to be triggering since it
> doesn't support setting the NETIF_F_LRO flag in the 2.6.38 kernel.
>
> By any chance are there any ixgbe or other interfaces in the system? I
> would suspect the error to come from a driver that at least contains the
> NETIF_F_LRO flag.
The servers actually also have a four port semi-build in NIC (its a PCIe
slot with an extra connector, most likely for controlling the LEDs). I
don't use that NIC as it (1) caused kernel panics on 2.6.35, (2) needs a
firmware blob, (3) reading through the driver code (at some point in
time) they didn't implement multiqueue support correctly.
So lets blame that driver ;-)
lspci-info:
Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42)
driver info via ethtool:
# ethtool -i eth01
driver: netxen_nic
version: 4.0.75
firmware-version: 4.0.530
bus-info: 0000:06:00.3
The strange part is that my pre-prod server also have a netxen_nic, but
it does not result in a WARN being tricked...
The pre-prod server do have a different firmware version.
# ethtool -i eth01
driver: netxen_nic
version: 4.0.75
firmware-version: 4.0.406
bus-info: 0000:06:00.0
(I have pulled the NIC out of some of the prod server, due to the risk
of a kernel panic on the old kernel. As operations have taken over the
deployment process, these NICs are still in. Guess I'll ask them to
blacklist the driver, so they don't see the warn stacktrace, they get so
nervous when they see stuff like that ;-))
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] l2tp: fix possible oops on l2tp_eth module unload
From: James Chapman @ 2011-03-21 9:26 UTC (permalink / raw)
To: netdev
A struct used in the l2tp_eth driver for registering network namespace
ops was incorrectly marked as __net_initdata, leading to oops when
module unloaded.
BUG: unable to handle kernel paging request at ffffffffa00ec098
IP: [<ffffffff8123dbd8>] ops_exit_list+0x7/0x4b
PGD 142d067 PUD 1431063 PMD 195da8067 PTE 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/module/l2tp_eth/refcnt
Call Trace:
[<ffffffff8123dc94>] ? unregister_pernet_operations+0x32/0x93
[<ffffffff8123dd20>] ? unregister_pernet_device+0x2b/0x38
[<ffffffff81068b6e>] ? sys_delete_module+0x1b8/0x222
[<ffffffff810c7300>] ? do_munmap+0x254/0x318
[<ffffffff812c64e5>] ? page_fault+0x25/0x30
[<ffffffff812c6952>] ? system_call_fastpath+0x16/0x1b
Signed-off-by: James Chapman <jchapman@katalix.com>
---
Push to stable trees too?
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 8d9ce0a..a8193f5 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -283,7 +283,7 @@ static __net_init int l2tp_eth_init_net(struct net *net)
return 0;
}
-static __net_initdata struct pernet_operations l2tp_eth_net_ops = {
+static struct pernet_operations l2tp_eth_net_ops = {
.init = l2tp_eth_init_net,
.id = &l2tp_eth_net_id,
.size = sizeof(struct l2tp_eth_net),
^ permalink raw reply related
* Re: LRO disable warnings on kernel 2.6.38
From: Eric Dumazet @ 2011-03-21 9:45 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexander Duyck, netdev, Neil Horman, Stanislaw Gruszka
In-Reply-To: <1300699294.10934.63.camel@firesoul.comx.local>
Le lundi 21 mars 2011 à 10:21 +0100, Jesper Dangaard Brouer a écrit :
> On Fri, 2011-03-18 at 09:18 -0700, Alexander Duyck wrote:
> > On 3/18/2011 4:12 AM, Jesper Dangaard Brouer wrote:
> > > Hi
> > >
> > > I'm seeing the LRO disable warnings using kernel 2.6.38:
> [...]
> > >
> > The error doesn't make any sense for igb to be triggering since it
> > doesn't support setting the NETIF_F_LRO flag in the 2.6.38 kernel.
> >
> > By any chance are there any ixgbe or other interfaces in the system? I
> > would suspect the error to come from a driver that at least contains the
> > NETIF_F_LRO flag.
>
> The servers actually also have a four port semi-build in NIC (its a PCIe
> slot with an extra connector, most likely for controlling the LEDs). I
> don't use that NIC as it (1) caused kernel panics on 2.6.35, (2) needs a
> firmware blob, (3) reading through the driver code (at some point in
> time) they didn't implement multiqueue support correctly.
>
> So lets blame that driver ;-)
>
> lspci-info:
> Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42)
>
> driver info via ethtool:
> # ethtool -i eth01
> driver: netxen_nic
> version: 4.0.75
> firmware-version: 4.0.530
> bus-info: 0000:06:00.3
>
> The strange part is that my pre-prod server also have a netxen_nic, but
> it does not result in a WARN being tricked...
>
> The pre-prod server do have a different firmware version.
> # ethtool -i eth01
> driver: netxen_nic
> version: 4.0.75
> firmware-version: 4.0.406
> bus-info: 0000:06:00.0
>
> (I have pulled the NIC out of some of the prod server, due to the risk
> of a kernel panic on the old kernel. As operations have taken over the
> deployment process, these NICs are still in. Guess I'll ask them to
> blacklist the driver, so they don't see the warn stacktrace, they get so
> nervous when they see stuff like that ;-))
>
Well, this warning can be ignored since these NIC dont receive packets
to be forwarded in your setup.
I would say netxen_nic_set_flags() is buggy : It rejects data if other
flag than ETH_FLAG_LRO is set.
if (data & ~ETH_FLAG_LRO)
return -EINVAL;
Brought by commit ef2519b1dd39940 (netxen: fail when try to setup
unsupported features) later corrected by commit 97d1935a61b7fe7a65f98f
(Make ethtool_ops::set_flags() return -EINVAL for unsupported flags)
Since this drivers asserts NETIF_F_HW_VLAN_TX (mirroring
ETH_FLAG_TXVLAN), ethtool_op_get_flags() can return more than
ETH_FLAG_LRO.
dev_disable_lro() then calls netxen_nic_set_flags() with ETH_FLAG_TXVLAN
-> -EINVAL, and ETH_FLAG_LRO stay ORed in dev->features -> WARNING
^ permalink raw reply
* Re: LRO disable warnings on kernel 2.6.38
From: Eric Dumazet @ 2011-03-21 9:53 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexander Duyck, netdev, Neil Horman, Stanislaw Gruszka
In-Reply-To: <1300700708.2884.10.camel@edumazet-laptop>
Le lundi 21 mars 2011 à 10:45 +0100, Eric Dumazet a écrit :
> Le lundi 21 mars 2011 à 10:21 +0100, Jesper Dangaard Brouer a écrit :
> > On Fri, 2011-03-18 at 09:18 -0700, Alexander Duyck wrote:
> > > On 3/18/2011 4:12 AM, Jesper Dangaard Brouer wrote:
> > > > Hi
> > > >
> > > > I'm seeing the LRO disable warnings using kernel 2.6.38:
> > [...]
> > > >
> > > The error doesn't make any sense for igb to be triggering since it
> > > doesn't support setting the NETIF_F_LRO flag in the 2.6.38 kernel.
> > >
> > > By any chance are there any ixgbe or other interfaces in the system? I
> > > would suspect the error to come from a driver that at least contains the
> > > NETIF_F_LRO flag.
> >
> > The servers actually also have a four port semi-build in NIC (its a PCIe
> > slot with an extra connector, most likely for controlling the LEDs). I
> > don't use that NIC as it (1) caused kernel panics on 2.6.35, (2) needs a
> > firmware blob, (3) reading through the driver code (at some point in
> > time) they didn't implement multiqueue support correctly.
> >
> > So lets blame that driver ;-)
> >
> > lspci-info:
> > Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42)
> >
> > driver info via ethtool:
> > # ethtool -i eth01
> > driver: netxen_nic
> > version: 4.0.75
> > firmware-version: 4.0.530
> > bus-info: 0000:06:00.3
> >
> > The strange part is that my pre-prod server also have a netxen_nic, but
> > it does not result in a WARN being tricked...
> >
> > The pre-prod server do have a different firmware version.
> > # ethtool -i eth01
> > driver: netxen_nic
> > version: 4.0.75
> > firmware-version: 4.0.406
> > bus-info: 0000:06:00.0
> >
> > (I have pulled the NIC out of some of the prod server, due to the risk
> > of a kernel panic on the old kernel. As operations have taken over the
> > deployment process, these NICs are still in. Guess I'll ask them to
> > blacklist the driver, so they don't see the warn stacktrace, they get so
> > nervous when they see stuff like that ;-))
> >
>
> Well, this warning can be ignored since these NIC dont receive packets
> to be forwarded in your setup.
>
> I would say netxen_nic_set_flags() is buggy : It rejects data if other
> flag than ETH_FLAG_LRO is set.
>
> if (data & ~ETH_FLAG_LRO)
> return -EINVAL;
>
> Brought by commit ef2519b1dd39940 (netxen: fail when try to setup
> unsupported features) later corrected by commit 97d1935a61b7fe7a65f98f
> (Make ethtool_ops::set_flags() return -EINVAL for unsupported flags)
>
> Since this drivers asserts NETIF_F_HW_VLAN_TX (mirroring
> ETH_FLAG_TXVLAN), ethtool_op_get_flags() can return more than
> ETH_FLAG_LRO.
>
> dev_disable_lro() then calls netxen_nic_set_flags() with ETH_FLAG_TXVLAN
> -> -EINVAL, and ETH_FLAG_LRO stay ORed in dev->features -> WARNING
>
>
>
>
Couly you please send us the result of "ethtool -k eth01" to make sure
its the problem ?
Make sure your ethtool version includes these bits :
# ethtool -k eth0
Offload parameters for eth0:
...
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off
Thanks
^ permalink raw reply
* RE: LRO disable warnings on kernel 2.6.38
From: Amit Salecha @ 2011-03-21 10:00 UTC (permalink / raw)
To: Eric Dumazet, Jesper Dangaard Brouer
Cc: Alexander Duyck, netdev, Neil Horman, Stanislaw Gruszka
In-Reply-To: <1300700708.2884.10.camel@edumazet-laptop>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Eric Dumazet
> Sent: Monday, March 21, 2011 3:15 PM
> To: Jesper Dangaard Brouer
> Cc: Alexander Duyck; netdev; Neil Horman; Stanislaw Gruszka
> Subject: Re: LRO disable warnings on kernel 2.6.38
>
> Le lundi 21 mars 2011 à 10:21 +0100, Jesper Dangaard Brouer a écrit :
> > On Fri, 2011-03-18 at 09:18 -0700, Alexander Duyck wrote:
> > > On 3/18/2011 4:12 AM, Jesper Dangaard Brouer wrote:
> > > > Hi
> > > >
> > > > I'm seeing the LRO disable warnings using kernel 2.6.38:
> > [...]
> > > >
> > > The error doesn't make any sense for igb to be triggering since it
> > > doesn't support setting the NETIF_F_LRO flag in the 2.6.38 kernel.
> > >
> > > By any chance are there any ixgbe or other interfaces in the
> system? I
> > > would suspect the error to come from a driver that at least
> contains the
> > > NETIF_F_LRO flag.
> >
> > The servers actually also have a four port semi-build in NIC (its a
> PCIe
> > slot with an extra connector, most likely for controlling the LEDs).
> I
> > don't use that NIC as it (1) caused kernel panics on 2.6.35, (2)
> needs a
> > firmware blob, (3) reading through the driver code (at some point in
> > time) they didn't implement multiqueue support correctly.
> >
> > So lets blame that driver ;-)
> >
> > lspci-info:
> > Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-
> Gigabit Server Adapter (rev 42)
> >
> > driver info via ethtool:
> > # ethtool -i eth01
> > driver: netxen_nic
> > version: 4.0.75
> > firmware-version: 4.0.530
> > bus-info: 0000:06:00.3
> >
> > The strange part is that my pre-prod server also have a netxen_nic,
> but
> > it does not result in a WARN being tricked...
> >
> > The pre-prod server do have a different firmware version.
> > # ethtool -i eth01
> > driver: netxen_nic
> > version: 4.0.75
> > firmware-version: 4.0.406
> > bus-info: 0000:06:00.0
> >
> > (I have pulled the NIC out of some of the prod server, due to the
> risk
> > of a kernel panic on the old kernel. As operations have taken over
> the
> > deployment process, these NICs are still in. Guess I'll ask them to
> > blacklist the driver, so they don't see the warn stacktrace, they get
> so
> > nervous when they see stuff like that ;-))
> >
>
> Well, this warning can be ignored since these NIC dont receive packets
> to be forwarded in your setup.
>
> I would say netxen_nic_set_flags() is buggy : It rejects data if other
> flag than ETH_FLAG_LRO is set.
>
> if (data & ~ETH_FLAG_LRO)
> return -EINVAL;
>
> Brought by commit ef2519b1dd39940 (netxen: fail when try to setup
> unsupported features) later corrected by commit 97d1935a61b7fe7a65f98f
> (Make ethtool_ops::set_flags() return -EINVAL for unsupported flags)
>
> Since this drivers asserts NETIF_F_HW_VLAN_TX (mirroring
> ETH_FLAG_TXVLAN), ethtool_op_get_flags() can return more than
> ETH_FLAG_LRO.
>
> dev_disable_lro() then calls netxen_nic_set_flags() with
> ETH_FLAG_TXVLAN
> -> -EINVAL, and ETH_FLAG_LRO stay ORed in dev->features -> WARNING
>
>
Thanks Eric.
Instead of
if (data & ~ETH_FLAG_LRO)
return -EINVAL;
check should be like this:
+ if ((ethtool_op_get_flags(netdev) & ~ETH_FLAG_LRO) !=
+ (data & ~ETH_FLAG_LRO))
return -EINVAL;
Will provide patch soon.
-Amit
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* Re: LRO disable warnings on kernel 2.6.38
From: Jesper Dangaard Brouer @ 2011-03-21 10:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexander Duyck, netdev, Neil Horman, Stanislaw Gruszka
In-Reply-To: <1300701232.2884.12.camel@edumazet-laptop>
On Mon, 2011-03-21 at 10:53 +0100, Eric Dumazet wrote:
> Couly you please send us the result of "ethtool -k eth01" to make sure
> its the problem ?
prod server:
albpd4:~# ethtool -k eth01
Offload parameters for eth01:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
ntuple-filters: off
receive-hashing: off
pre-prod server:
albpd1:~# ethtool -k eth01
Offload parameters for eth01:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
ntuple-filters: off
receive-hashing: off
Hmm... notice how the large-receive-offload (LRO) is different on the
two machines.
I cannot disable LRO with userspace ethtool:
albpd4:~# ethtool -K eth01 lro off
Cannot set large receive offload settings: Invalid argument
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: LRO disable warnings on kernel 2.6.38
From: Eric Dumazet @ 2011-03-21 10:11 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexander Duyck, netdev, Neil Horman, Stanislaw Gruszka
In-Reply-To: <1300701852.10934.67.camel@firesoul.comx.local>
Le lundi 21 mars 2011 à 11:04 +0100, Jesper Dangaard Brouer a écrit :
> On Mon, 2011-03-21 at 10:53 +0100, Eric Dumazet wrote:
> > Couly you please send us the result of "ethtool -k eth01" to make sure
> > its the problem ?
>
> prod server:
>
> albpd4:~# ethtool -k eth01
> Offload parameters for eth01:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: on
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: on
> ntuple-filters: off
> receive-hashing: off
>
> pre-prod server:
>
> albpd1:~# ethtool -k eth01
> Offload parameters for eth01:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: on
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off
> ntuple-filters: off
> receive-hashing: off
>
> Hmm... notice how the large-receive-offload (LRO) is different on the
> two machines.
>
> I cannot disable LRO with userspace ethtool:
>
> albpd4:~# ethtool -K eth01 lro off
> Cannot set large receive offload settings: Invalid argument
>
Sure, this is the problem. Still your ethtool dont give us the needed
info ;)
I suspect it is :
rx-vlan-offload: off
tx-vlan-offload: on
But would like a confirmation of this ;)
# ethtool -V | head -n 1
ethtool version 2.6.37
# ethtool --version
ethtool version 2.6.37
^ permalink raw reply
* Re: LRO disable warnings on kernel 2.6.38
From: Jesper Dangaard Brouer @ 2011-03-21 10:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Alexander Duyck, netdev, Neil Horman, Stanislaw Gruszka
In-Reply-To: <1300702282.2884.23.camel@edumazet-laptop>
On Mon, 2011-03-21 at 11:11 +0100, Eric Dumazet wrote:
> Sure, this is the problem. Still your ethtool dont give us the needed
> info ;)
>
> I suspect it is :
>
> rx-vlan-offload: off
> tx-vlan-offload: on
albpd4:~# ~/ethtool-2.6.38 -k eth01
Offload parameters for eth01:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: on
rx-vlan-offload: off
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off
> But would like a confirmation of this ;)
Bonus! - with a newer version of ethtool ;-0
> # ethtool -V | head -n 1
> ethtool version 2.6.37
albpd4:~# ethtool -V | head -1
ethtool version 2.6.34
> # ethtool --version
> ethtool version 2.6.37
albpd4:~# ~/ethtool-2.6.38 --version
ethtool version 2.6.38
(actually latest git tree, 423c656b22ec which is a release by Ben)
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH] netxen: fix LRO disable warning
From: Amit Kumar Salecha @ 2011-03-21 10:37 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman, Rajesh Borundia
netxen_nic_set_flags() rejects data if other flag than ETH_FLAG_LRO is set.
Driver also supports NETIF_F_HW_VLAN_TX.
Now compare data with ethtool_op_get_flags(), to get all supported features.
Reported-by: Jesper Dangaard Brouer <jdb@comx.dk>
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_ethtool.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_ethtool.c b/drivers/net/netxen/netxen_nic_ethtool.c
index 653d308..31c41d6 100644
--- a/drivers/net/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/netxen/netxen_nic_ethtool.c
@@ -871,7 +871,8 @@ static int netxen_nic_set_flags(struct net_device *netdev, u32 data)
struct netxen_adapter *adapter = netdev_priv(netdev);
int hw_lro;
- if (data & ~ETH_FLAG_LRO)
+ if ((ethtool_op_get_flags(netdev) & ~ETH_FLAG_LRO) !=
+ (data & ~ETH_FLAG_LRO))
return -EINVAL;
if (!(adapter->capabilities & NX_FW_CAPABILITY_HW_LRO))
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH] netxen: fix LRO disable warning
From: Eric Dumazet @ 2011-03-21 10:47 UTC (permalink / raw)
To: Amit Kumar Salecha; +Cc: davem, netdev, ameen.rahman, Rajesh Borundia
In-Reply-To: <1300703828-6291-1-git-send-email-amit.salecha@qlogic.com>
Le lundi 21 mars 2011 à 03:37 -0700, Amit Kumar Salecha a écrit :
> netxen_nic_set_flags() rejects data if other flag than ETH_FLAG_LRO is set.
> Driver also supports NETIF_F_HW_VLAN_TX.
> Now compare data with ethtool_op_get_flags(), to get all supported features.
>
> Reported-by: Jesper Dangaard Brouer <jdb@comx.dk>
> Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
> ---
Hmm, it would be really nice you provide more information for stable
teams.
If I am not mistaken, bug was introduced in 2.6.36 ?
^ permalink raw reply
* RE: [PATCH] netxen: fix LRO disable warning
From: Amit Salecha @ 2011-03-21 11:13 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem@davemloft.net, netdev@vger.kernel.org, Ameen Rahman,
Rajesh Borundia
In-Reply-To: <1300704474.2884.66.camel@edumazet-laptop>
> Le lundi 21 mars 2011 à 03:37 -0700, Amit Kumar Salecha a écrit :
> > netxen_nic_set_flags() rejects data if other flag than ETH_FLAG_LRO
> is set.
> > Driver also supports NETIF_F_HW_VLAN_TX.
> > Now compare data with ethtool_op_get_flags(), to get all supported
> features.
> >
> > Reported-by: Jesper Dangaard Brouer <jdb@comx.dk>
> > Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
> > Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
> > ---
>
> Hmm, it would be really nice you provide more information for stable
> teams.
>
> If I am not mistaken, bug was introduced in 2.6.36 ?
>
No, It was introduced in 2.6.37, when ETH_FLAG_TXVLAN and ETH_FLAG_RXVLAN introduced.
Yes it should also make into 2.6.37.4 stable kernel.
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
^ permalink raw reply
* Re: [PATCHv2 0/9] macb: add support for Cadence GEM
From: Jamie Iles @ 2011-03-21 11:18 UTC (permalink / raw)
To: Nicolas Ferre
Cc: David Miller, jamie, Russell King - ARM Linux, netdev,
linux-arm-kernel, plagnioj, Andrew Victor, Peter Korsgaard
In-Reply-To: <4D86F25A.7060405@atmel.com>
On Mon, Mar 21, 2011 at 02:38:18PM +0800, Nicolas Ferre wrote:
> On 3/17/2011 4:17 AM, David Miller :
> > From: Jamie Iles <jamie@jamieiles.com>
> > Date: Tue, 15 Mar 2011 10:14:47 +0000
> >
> >> This patch series extends the Atmel MACB driver to support the Cadence
> >> GEM (Gigabit Ethernet MAC) to support 10/100 operation. The GEM is
> >> based on the MACB block but has a few moved registers and bitfields.
> >> This patch series attempts to use the MACB accessors where block
> >> functionallity is identical and only overrides to GEM specific
> >> acccessors when needed.
> >>
> >> This has been runtested on a board with a Cadence GEM and compile tested
> >> for all at91 configurations and a number of avr32 configurations.
> >>
> >> Changes since v1:
> >> - AT91 now provides a fake "hclk" and "macb_clk" has been
> >> renamed to "pclk" to be consistent with AVR32.
> >> - Configurable GEM receive buffer size support has been added.
> >> - pr_foo() and dev_foo() have been converted to netdev_foo()
> >> where appropriate.
> >> - New conditional accessors (macb_or_gem_{read,write}l) have
> >> been introduced that do the conditional accesses dependent on
> >> macb/gem type.
> >> - GEM is now dynamically detected from the module ID rather than
> >> platform device name.
> >>
> >> Jean-Christophe, I haven't based this on your conditional clock patch as
> >> I wasn't sure what decision had been made on that and whether the
> >> at91/avr32 detection is reliable.
> >
> > I'm happy to ACK this so you guys can merge this via one of the
> > ARM trees:
> >
> > Acked-by: David S. Miller <davem@davemloft.net>
>
> I add my:
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Now, tell me if we need to setup a git tree with this and make it
> handled by linux-next (we do not have for at91 yet)?
> or Russell can take the series in a "devel" branch?
Thanks for testing Nicolas!
I have an existing tree for this at
git://github.com/jamieiles/linux-2.6-ji.git macb-gem
based off of 2.6.38 (with your ACK's now added) and I'd be happy with
either route.
Jamie
^ permalink raw reply
* [PATCH] snmp: SNMP_UPD_PO_STATS_BH() always called from softirq
From: Eric Dumazet @ 2011-03-21 11:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev
We dont need to test if we run from softirq context, we definitely are.
This saves few instructions in ip_rcv() & ip_rcv_finish()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/include/net/snmp.h b/include/net/snmp.h
index 762e2ab..27461d6 100644
--- a/include/net/snmp.h
+++ b/include/net/snmp.h
@@ -150,7 +150,7 @@ struct linux_xfrm_mib {
#define SNMP_UPD_PO_STATS_BH(mib, basefield, addend) \
do { \
__typeof__(*mib[0]) *ptr = \
- __this_cpu_ptr((mib)[!in_softirq()]); \
+ __this_cpu_ptr((mib)[0]); \
ptr->mibs[basefield##PKTS]++; \
ptr->mibs[basefield##OCTETS] += addend;\
} while (0)
@@ -202,7 +202,7 @@ struct linux_xfrm_mib {
#define SNMP_UPD_PO_STATS64_BH(mib, basefield, addend) \
do { \
__typeof__(*mib[0]) *ptr; \
- ptr = __this_cpu_ptr((mib)[!in_softirq()]); \
+ ptr = __this_cpu_ptr((mib)[0]); \
u64_stats_update_begin(&ptr->syncp); \
ptr->mibs[basefield##PKTS]++; \
ptr->mibs[basefield##OCTETS] += addend; \
^ permalink raw reply related
* Re: [PATCH] irda: validate peer name and attribute lengths
From: Dan Rosenberg @ 2011-03-21 11:32 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: David S. Miller, netdev, security
In-Reply-To: <1300671126.9043.8.camel@dan>
On Sun, 2011-03-20 at 21:32 -0400, Dan Rosenberg wrote:
> Length fields provided by a peer for names and attributes may be longer
> than the destination array sizes. Validate lengths to prevent stack
> buffer overflows.
>
While this is the most serious bug I see, this function also seems to
lack any validation against skb->len. If someone wants to take care of
this, by all means...if not, I'll post a follow-up patch in the next day
or so.
-Dan
> Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
> Cc: stable@kernel.org
> ---
> net/irda/iriap.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/net/irda/iriap.c b/net/irda/iriap.c
> index 5b743bd..3647753 100644
> --- a/net/irda/iriap.c
> +++ b/net/irda/iriap.c
> @@ -656,10 +656,16 @@ static void iriap_getvaluebyclass_indication(struct iriap_cb *self,
> n = 1;
>
> name_len = fp[n++];
> +
> + IRDA_ASSERT(name_len < IAS_MAX_CLASSNAME + 1, return;);
> +
> memcpy(name, fp+n, name_len); n+=name_len;
> name[name_len] = '\0';
>
> attr_len = fp[n++];
> +
> + IRDA_ASSERT(attr_len < IAS_MAX_ATTRIBNAME + 1, return;);
> +
> memcpy(attr, fp+n, attr_len); n+=attr_len;
> attr[attr_len] = '\0';
>
>
^ permalink raw reply
* [PATCH net-next 2/3] net/r8169: add a new chip for RTL8168DP
From: Hayes Wang @ 2011-03-21 11:50 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1300708230-1934-1-git-send-email-hayeswang@realtek.com>
Add a new chip for RTL8168DP.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 98 +++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 76 insertions(+), 22 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 0111a14..5c48075 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -127,6 +127,7 @@ enum mac_version {
RTL_GIGA_MAC_VER_28 = 0x1c, // 8168DP
RTL_GIGA_MAC_VER_29 = 0x1d, // 8105E
RTL_GIGA_MAC_VER_30 = 0x1e, // 8105E
+ RTL_GIGA_MAC_VER_31 = 0x1f, // 8168DP
};
#define _R(NAME,MAC,MASK) \
@@ -166,7 +167,8 @@ static const struct {
_R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_27, 0xff7e1880), // PCI-E
_R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, 0xff7e1880), // PCI-E
_R("RTL8105e", RTL_GIGA_MAC_VER_29, 0xff7e1880), // PCI-E
- _R("RTL8105e", RTL_GIGA_MAC_VER_30, 0xff7e1880) // PCI-E
+ _R("RTL8105e", RTL_GIGA_MAC_VER_30, 0xff7e1880), // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_31, 0xff7e1880) // PCI-E
};
#undef _R
@@ -651,12 +653,18 @@ static void rtl8168_oob_notify(struct rtl8169_private *tp, u8 cmd)
static void rtl8168_driver_start(struct rtl8169_private *tp)
{
int i;
+ u32 reg;
rtl8168_oob_notify(tp, OOB_CMD_DRIVER_START);
+ if (tp->mac_version == RTL_GIGA_MAC_VER_31)
+ reg = 0xb8;
+ else
+ reg = 0x10;
+
for (i = 0; i < 10; i++) {
msleep(10);
- if (ocp_read(tp, 0x0f, 0x0010) & 0x00000800)
+ if (ocp_read(tp, 0x0f, reg) & 0x00000800)
break;
}
}
@@ -664,16 +672,36 @@ static void rtl8168_driver_start(struct rtl8169_private *tp)
static void rtl8168_driver_stop(struct rtl8169_private *tp)
{
int i;
+ u32 reg;
rtl8168_oob_notify(tp, OOB_CMD_DRIVER_STOP);
+ if (tp->mac_version == RTL_GIGA_MAC_VER_31)
+ reg = 0xb8;
+ else
+ reg = 0x10;
+
for (i = 0; i < 10; i++) {
msleep(10);
- if ((ocp_read(tp, 0x0f, 0x0010) & 0x00000800) == 0)
+ if ((ocp_read(tp, 0x0f, reg) & 0x00000800) == 0)
break;
}
}
+static int r8168dp_check_dash(struct rtl8169_private *tp)
+{
+ u32 reg;
+
+ if (tp->mac_version == RTL_GIGA_MAC_VER_31)
+ reg = 0xb8;
+ else
+ reg = 0x10;
+
+ if (ocp_read(tp, 0xF, reg) & 0x00008000)
+ return 1;
+ else
+ return 0;
+}
static void r8169_mdio_write(void __iomem *ioaddr, int reg_addr, int value)
{
@@ -1555,6 +1583,7 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
/* 8168DP family. */
{ 0x7cf00000, 0x28800000, RTL_GIGA_MAC_VER_27 },
{ 0x7cf00000, 0x28a00000, RTL_GIGA_MAC_VER_28 },
+ { 0x7cf00000, 0x28b00000, RTL_GIGA_MAC_VER_31 },
/* 8168C family. */
{ 0x7cf00000, 0x3cb00000, RTL_GIGA_MAC_VER_24 },
@@ -2860,6 +2889,7 @@ static void __devinit rtl_init_mdio_ops(struct rtl8169_private *tp)
ops->read = r8168dp_1_mdio_read;
break;
case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
ops->write = r8168dp_2_mdio_write;
ops->read = r8168dp_2_mdio_read;
break;
@@ -2917,8 +2947,9 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
void __iomem *ioaddr = tp->mmio_addr;
if (((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
- (tp->mac_version == RTL_GIGA_MAC_VER_28)) &&
- (ocp_read(tp, 0x0f, 0x0010) & 0x00008000)) {
+ (tp->mac_version == RTL_GIGA_MAC_VER_28) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_31)) &&
+ r8168dp_check_dash(tp)) {
return;
}
@@ -2944,6 +2975,7 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_26:
case RTL_GIGA_MAC_VER_27:
case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
break;
}
@@ -2954,8 +2986,9 @@ static void r8168_pll_power_up(struct rtl8169_private *tp)
void __iomem *ioaddr = tp->mmio_addr;
if (((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
- (tp->mac_version == RTL_GIGA_MAC_VER_28)) &&
- (ocp_read(tp, 0x0f, 0x0010) & 0x00008000)) {
+ (tp->mac_version == RTL_GIGA_MAC_VER_28) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_31)) &&
+ r8168dp_check_dash(tp)) {
return;
}
@@ -2964,6 +2997,7 @@ static void r8168_pll_power_up(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_26:
case RTL_GIGA_MAC_VER_27:
case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
RTL_W8(PMCH, RTL_R8(PMCH) | 0x80);
break;
}
@@ -3018,6 +3052,7 @@ static void __devinit rtl_init_pll_power_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_26:
case RTL_GIGA_MAC_VER_27:
case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
ops->down = r8168_pll_power_down;
ops->up = r8168_pll_power_up;
break;
@@ -3250,7 +3285,8 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
(u32)(RTL_R32(TxConfig) & 0x9cf0f8ff), dev->irq);
if ((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
- (tp->mac_version == RTL_GIGA_MAC_VER_28)) {
+ (tp->mac_version == RTL_GIGA_MAC_VER_28) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_31)) {
rtl8168_driver_start(tp);
}
@@ -3283,7 +3319,8 @@ static void __devexit rtl8169_remove_one(struct pci_dev *pdev)
struct rtl8169_private *tp = netdev_priv(dev);
if ((tp->mac_version == RTL_GIGA_MAC_VER_27) ||
- (tp->mac_version == RTL_GIGA_MAC_VER_28)) {
+ (tp->mac_version == RTL_GIGA_MAC_VER_28) ||
+ (tp->mac_version == RTL_GIGA_MAC_VER_31)) {
rtl8168_driver_stop(tp);
}
@@ -3383,7 +3420,8 @@ static void rtl8169_hw_reset(struct rtl8169_private *tp)
rtl8169_irq_mask_and_ack(ioaddr);
if (tp->mac_version == RTL_GIGA_MAC_VER_27 ||
- tp->mac_version == RTL_GIGA_MAC_VER_28) {
+ tp->mac_version == RTL_GIGA_MAC_VER_28 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_31) {
while (RTL_R8(TxPoll) & NPQ)
udelay(20);
@@ -3780,6 +3818,17 @@ static void rtl_hw_start_8168d(void __iomem *ioaddr, struct pci_dev *pdev)
RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R8168_CPCMD_QUIRK_MASK);
}
+static void rtl_hw_start_8168dp(void __iomem *ioaddr, struct pci_dev *pdev)
+{
+ rtl_csi_access_enable_1(ioaddr);
+
+ rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
+
+ RTL_W8(MaxTxPacketSize, TxPacketMax);
+
+ rtl_disable_clock_request(pdev);
+}
+
static void rtl_hw_start_8168d_4(void __iomem *ioaddr, struct pci_dev *pdev)
{
static const struct ephy_info e_info_8168d_4[] = {
@@ -3843,55 +3892,59 @@ static void rtl_hw_start_8168(struct net_device *dev)
switch (tp->mac_version) {
case RTL_GIGA_MAC_VER_11:
rtl_hw_start_8168bb(ioaddr, pdev);
- break;
+ break;
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_17:
rtl_hw_start_8168bef(ioaddr, pdev);
- break;
+ break;
case RTL_GIGA_MAC_VER_18:
rtl_hw_start_8168cp_1(ioaddr, pdev);
- break;
+ break;
case RTL_GIGA_MAC_VER_19:
rtl_hw_start_8168c_1(ioaddr, pdev);
- break;
+ break;
case RTL_GIGA_MAC_VER_20:
rtl_hw_start_8168c_2(ioaddr, pdev);
- break;
+ break;
case RTL_GIGA_MAC_VER_21:
rtl_hw_start_8168c_3(ioaddr, pdev);
- break;
+ break;
case RTL_GIGA_MAC_VER_22:
rtl_hw_start_8168c_4(ioaddr, pdev);
- break;
+ break;
case RTL_GIGA_MAC_VER_23:
rtl_hw_start_8168cp_2(ioaddr, pdev);
- break;
+ break;
case RTL_GIGA_MAC_VER_24:
rtl_hw_start_8168cp_3(ioaddr, pdev);
- break;
+ break;
case RTL_GIGA_MAC_VER_25:
case RTL_GIGA_MAC_VER_26:
case RTL_GIGA_MAC_VER_27:
rtl_hw_start_8168d(ioaddr, pdev);
- break;
+ break;
case RTL_GIGA_MAC_VER_28:
rtl_hw_start_8168d_4(ioaddr, pdev);
- break;
+ break;
+ case RTL_GIGA_MAC_VER_31:
+ rtl_hw_start_8168dp(ioaddr, pdev);
+ break;
+
default:
printk(KERN_ERR PFX "%s: unknown chipset (mac_version = %d).\n",
dev->name, tp->mac_version);
- break;
+ break;
}
RTL_W8(ChipCmd, CmdTxEnb | CmdRxEnb);
@@ -4756,6 +4809,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_27:
case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
/* Experimental science. Pktgen proof. */
case RTL_GIGA_MAC_VER_12:
case RTL_GIGA_MAC_VER_25:
--
1.7.3.2
^ permalink raw reply related
* [PATCH net-next 1/3] net/r8169: add a new chip for RTL8105
From: Hayes Wang @ 2011-03-21 11:50 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
In-Reply-To: <1300708230-1934-1-git-send-email-hayeswang@realtek.com>
Add a new chip for RTL8105 whose settings are the same with RTL_GIGA_MAC_VER_30.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 493b0de..0111a14 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1574,6 +1574,7 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
{ 0x7c800000, 0x30000000, RTL_GIGA_MAC_VER_11 },
/* 8101 family. */
+ { 0x7cf00000, 0x40b00000, RTL_GIGA_MAC_VER_30 },
{ 0x7cf00000, 0x40a00000, RTL_GIGA_MAC_VER_30 },
{ 0x7cf00000, 0x40900000, RTL_GIGA_MAC_VER_29 },
{ 0x7c800000, 0x40800000, RTL_GIGA_MAC_VER_30 },
--
1.7.3.2
^ permalink raw reply related
* [PATCH net-next 3/3] net/r8169: support RTL8168E
From: Hayes Wang @ 2011-03-21 11:50 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
Support RTL8168E/RTL8111E.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 212 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 207 insertions(+), 5 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 5c48075..caa99cd 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -37,6 +37,8 @@
#define FIRMWARE_8168D_1 "rtl_nic/rtl8168d-1.fw"
#define FIRMWARE_8168D_2 "rtl_nic/rtl8168d-2.fw"
+#define FIRMWARE_8168E_1 "rtl_nic/rtl8168e-1.fw"
+#define FIRMWARE_8168E_2 "rtl_nic/rtl8168e-2.fw"
#define FIRMWARE_8105E_1 "rtl_nic/rtl8105e-1.fw"
#ifdef RTL8169_DEBUG
@@ -128,6 +130,8 @@ enum mac_version {
RTL_GIGA_MAC_VER_29 = 0x1d, // 8105E
RTL_GIGA_MAC_VER_30 = 0x1e, // 8105E
RTL_GIGA_MAC_VER_31 = 0x1f, // 8168DP
+ RTL_GIGA_MAC_VER_32 = 0x20, // 8168E
+ RTL_GIGA_MAC_VER_33 = 0x21, // 8168E
};
#define _R(NAME,MAC,MASK) \
@@ -168,7 +172,9 @@ static const struct {
_R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_28, 0xff7e1880), // PCI-E
_R("RTL8105e", RTL_GIGA_MAC_VER_29, 0xff7e1880), // PCI-E
_R("RTL8105e", RTL_GIGA_MAC_VER_30, 0xff7e1880), // PCI-E
- _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_31, 0xff7e1880) // PCI-E
+ _R("RTL8168dp/8111dp", RTL_GIGA_MAC_VER_31, 0xff7e1880), // PCI-E
+ _R("RTL8168e/8111e", RTL_GIGA_MAC_VER_32, 0xff7e1880), // PCI-E
+ _R("RTL8168e/8111e", RTL_GIGA_MAC_VER_33, 0xff7e1880) // PCI-E
};
#undef _R
@@ -317,7 +323,9 @@ enum rtl8168_registers {
#define OCPAR_FLAG 0x80000000
#define OCPAR_GPHY_WRITE_CMD 0x8000f060
#define OCPAR_GPHY_READ_CMD 0x0000f060
- RDSAR1 = 0xd0 /* 8168c only. Undocumented on 8168dp */
+ RDSAR1 = 0xd0, /* 8168c only. Undocumented on 8168dp */
+ MISC = 0xf0, /* 8168e only. */
+ txpla_rst = (1 << 29)
};
enum rtl_register_content {
@@ -395,6 +403,7 @@ enum rtl_register_content {
BWF = (1 << 6), /* Accept Broadcast wakeup frame */
MWF = (1 << 5), /* Accept Multicast wakeup frame */
UWF = (1 << 4), /* Accept Unicast wakeup frame */
+ spi_en = (1 << 3),
LanWake = (1 << 1), /* LanWake enable/disable */
PMEStatus = (1 << 0), /* PME status can be reset by PCI RST# */
@@ -579,6 +588,8 @@ MODULE_LICENSE("GPL");
MODULE_VERSION(RTL8169_VERSION);
MODULE_FIRMWARE(FIRMWARE_8168D_1);
MODULE_FIRMWARE(FIRMWARE_8168D_2);
+MODULE_FIRMWARE(FIRMWARE_8168E_1);
+MODULE_FIRMWARE(FIRMWARE_8168E_2);
MODULE_FIRMWARE(FIRMWARE_8105E_1);
static int rtl8169_open(struct net_device *dev);
@@ -1575,6 +1586,11 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
u32 val;
int mac_version;
} mac_info[] = {
+ /* 8168E family. */
+ { 0x7cf00000, 0x2c200000, RTL_GIGA_MAC_VER_33 },
+ { 0x7cf00000, 0x2c100000, RTL_GIGA_MAC_VER_32 },
+ { 0x7c800000, 0x2c000000, RTL_GIGA_MAC_VER_33 },
+
/* 8168D family. */
{ 0x7cf00000, 0x28300000, RTL_GIGA_MAC_VER_26 },
{ 0x7cf00000, 0x28100000, RTL_GIGA_MAC_VER_25 },
@@ -2466,6 +2482,93 @@ static void rtl8168d_4_hw_phy_config(struct rtl8169_private *tp)
rtl_patchphy(tp, 0x0d, 1 << 5);
}
+static void rtl8168e_hw_phy_config(struct rtl8169_private *tp)
+{
+ static const struct phy_reg phy_reg_init[] = {
+ /* Enable Delay cap */
+ { 0x1f, 0x0005 },
+ { 0x05, 0x8b80 },
+ { 0x06, 0xc896 },
+ { 0x1f, 0x0000 },
+
+ /* Channel estimation fine tune */
+ { 0x1f, 0x0001 },
+ { 0x0b, 0x6c20 },
+ { 0x07, 0x2872 },
+ { 0x1c, 0xefff },
+ { 0x1f, 0x0003 },
+ { 0x14, 0x6420 },
+ { 0x1f, 0x0000 },
+
+ /* Update PFM & 10M TX idle timer */
+ { 0x1f, 0x0007 },
+ { 0x1e, 0x002f },
+ { 0x15, 0x1919 },
+ { 0x1f, 0x0000 },
+
+ { 0x1f, 0x0007 },
+ { 0x1e, 0x00ac },
+ { 0x18, 0x0006 },
+ { 0x1f, 0x0000 }
+ };
+
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+
+ /* DCO enable for 10M IDLE Power */
+ rtl_writephy(tp, 0x1f, 0x0007);
+ rtl_writephy(tp, 0x1e, 0x0023);
+ rtl_w1w0_phy(tp, 0x17, 0x0006, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ /* For impedance matching */
+ rtl_writephy(tp, 0x1f, 0x0002);
+ rtl_w1w0_phy(tp, 0x08, 0x8000, 0x7f00);
+ rtl_writephy(tp, 0x1F, 0x0000);
+
+ /* PHY auto speed down */
+ rtl_writephy(tp, 0x1f, 0x0007);
+ rtl_writephy(tp, 0x1e, 0x002d);
+ rtl_w1w0_phy(tp, 0x18, 0x0050, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_w1w0_phy(tp, 0x14, 0x8000, 0x0000);
+
+ rtl_writephy(tp, 0x1f, 0x0005);
+ rtl_writephy(tp, 0x05, 0x8b86);
+ rtl_w1w0_phy(tp, 0x06, 0x0001, 0x0000);
+ rtl_writephy(tp, 0x1f, 0x0000);
+
+ rtl_writephy(tp, 0x1f, 0x0005);
+ rtl_writephy(tp, 0x05, 0x8b85);
+ rtl_w1w0_phy(tp, 0x06, 0x0000, 0x2000);
+ rtl_writephy(tp, 0x1f, 0x0007);
+ rtl_writephy(tp, 0x1e, 0x0020);
+ rtl_w1w0_phy(tp, 0x15, 0x0000, 0x1100);
+ rtl_writephy(tp, 0x1f, 0x0006);
+ rtl_writephy(tp, 0x00, 0x5a00);
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_writephy(tp, 0x0d, 0x0007);
+ rtl_writephy(tp, 0x0e, 0x003c);
+ rtl_writephy(tp, 0x0d, 0x4007);
+ rtl_writephy(tp, 0x0e, 0x0000);
+ rtl_writephy(tp, 0x0d, 0x0000);
+}
+
+static void rtl8168e_1_hw_phy_config(struct rtl8169_private *tp)
+{
+ if (rtl_apply_firmware(tp, FIRMWARE_8168E_1) < 0)
+ netif_warn(tp, probe, tp->dev, "unable to apply firmware patch\n");
+
+ rtl8168e_hw_phy_config(tp);
+}
+
+static void rtl8168e_2_hw_phy_config(struct rtl8169_private *tp)
+{
+ if (rtl_apply_firmware(tp, FIRMWARE_8168E_2) < 0)
+ netif_warn(tp, probe, tp->dev, "unable to apply firmware patch\n");
+
+ rtl8168e_hw_phy_config(tp);
+}
+
static void rtl8102e_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init[] = {
@@ -2581,6 +2684,12 @@ static void rtl_hw_phy_config(struct net_device *dev)
case RTL_GIGA_MAC_VER_30:
rtl8105e_hw_phy_config(tp);
break;
+ case RTL_GIGA_MAC_VER_32:
+ rtl8168e_1_hw_phy_config(tp);
+ break;
+ case RTL_GIGA_MAC_VER_33:
+ rtl8168e_2_hw_phy_config(tp);
+ break;
default:
break;
@@ -2931,15 +3040,59 @@ static void r810x_pll_power_up(struct rtl8169_private *tp)
static void r8168_phy_power_up(struct rtl8169_private *tp)
{
rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x0e, 0x0000);
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_11:
+ case RTL_GIGA_MAC_VER_12:
+ case RTL_GIGA_MAC_VER_17:
+ case RTL_GIGA_MAC_VER_18:
+ case RTL_GIGA_MAC_VER_19:
+ case RTL_GIGA_MAC_VER_20:
+ case RTL_GIGA_MAC_VER_21:
+ case RTL_GIGA_MAC_VER_22:
+ case RTL_GIGA_MAC_VER_23:
+ case RTL_GIGA_MAC_VER_24:
+ case RTL_GIGA_MAC_VER_25:
+ case RTL_GIGA_MAC_VER_26:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
+ rtl_writephy(tp, 0x0e, 0x0000);
+ break;
+ default:
+ break;
+ }
rtl_writephy(tp, MII_BMCR, BMCR_ANENABLE);
}
static void r8168_phy_power_down(struct rtl8169_private *tp)
{
rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x0e, 0x0200);
- rtl_writephy(tp, MII_BMCR, BMCR_PDOWN);
+ switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_32:
+ case RTL_GIGA_MAC_VER_33:
+ rtl_writephy(tp, MII_BMCR, BMCR_ANENABLE | BMCR_PDOWN);
+ break;
+
+ case RTL_GIGA_MAC_VER_11:
+ case RTL_GIGA_MAC_VER_12:
+ case RTL_GIGA_MAC_VER_17:
+ case RTL_GIGA_MAC_VER_18:
+ case RTL_GIGA_MAC_VER_19:
+ case RTL_GIGA_MAC_VER_20:
+ case RTL_GIGA_MAC_VER_21:
+ case RTL_GIGA_MAC_VER_22:
+ case RTL_GIGA_MAC_VER_23:
+ case RTL_GIGA_MAC_VER_24:
+ case RTL_GIGA_MAC_VER_25:
+ case RTL_GIGA_MAC_VER_26:
+ case RTL_GIGA_MAC_VER_27:
+ case RTL_GIGA_MAC_VER_28:
+ case RTL_GIGA_MAC_VER_31:
+ rtl_writephy(tp, 0x0e, 0x0200);
+ default:
+ rtl_writephy(tp, MII_BMCR, BMCR_PDOWN);
+ break;
+ }
}
static void r8168_pll_power_down(struct rtl8169_private *tp)
@@ -2959,6 +3112,10 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
return;
}
+ if (tp->mac_version == RTL_GIGA_MAC_VER_32 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_33)
+ rtl_ephy_write(ioaddr, 0x19, 0xff64);
+
if (__rtl8169_get_wol(tp) & WAKE_ANY) {
rtl_writephy(tp, 0x1f, 0x0000);
rtl_writephy(tp, MII_BMCR, 0x0000);
@@ -2976,6 +3133,8 @@ static void r8168_pll_power_down(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_27:
case RTL_GIGA_MAC_VER_28:
case RTL_GIGA_MAC_VER_31:
+ case RTL_GIGA_MAC_VER_32:
+ case RTL_GIGA_MAC_VER_33:
RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
break;
}
@@ -2998,6 +3157,8 @@ static void r8168_pll_power_up(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_27:
case RTL_GIGA_MAC_VER_28:
case RTL_GIGA_MAC_VER_31:
+ case RTL_GIGA_MAC_VER_32:
+ case RTL_GIGA_MAC_VER_33:
RTL_W8(PMCH, RTL_R8(PMCH) | 0x80);
break;
}
@@ -3053,6 +3214,8 @@ static void __devinit rtl_init_pll_power_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_27:
case RTL_GIGA_MAC_VER_28:
case RTL_GIGA_MAC_VER_31:
+ case RTL_GIGA_MAC_VER_32:
+ case RTL_GIGA_MAC_VER_33:
ops->down = r8168_pll_power_down;
ops->up = r8168_pll_power_up;
break;
@@ -3855,6 +4018,41 @@ static void rtl_hw_start_8168d_4(void __iomem *ioaddr, struct pci_dev *pdev)
rtl_enable_clock_request(pdev);
}
+static void rtl_hw_start_8168e(void __iomem *ioaddr, struct pci_dev *pdev)
+{
+ static const struct ephy_info e_info_8168e[] = {
+ { 0x00, 0x0200, 0x0100 },
+ { 0x00, 0x0000, 0x0004 },
+ { 0x06, 0x0002, 0x0001 },
+ { 0x06, 0x0000, 0x0030 },
+ { 0x07, 0x0000, 0x2000 },
+ { 0x00, 0x0000, 0x0020 },
+ { 0x03, 0x5800, 0x2000 },
+ { 0x03, 0x0000, 0x0001 },
+ { 0x01, 0x0800, 0x1000 },
+ { 0x07, 0x0000, 0x4000 },
+ { 0x1e, 0x0000, 0x2000 },
+ { 0x19, 0xffff, 0xfe6c },
+ { 0x0a, 0x0000, 0x0040 }
+ };
+
+ rtl_csi_access_enable_2(ioaddr);
+
+ rtl_ephy_init(ioaddr, e_info_8168e, ARRAY_SIZE(e_info_8168e));
+
+ rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
+
+ RTL_W8(MaxTxPacketSize, TxPacketMax);
+
+ rtl_disable_clock_request(pdev);
+
+ /* Reset tx FIFO pointer */
+ RTL_W32(MISC, RTL_R32(MISC) | txpla_rst);
+ RTL_W32(MISC, RTL_R32(MISC) & ~txpla_rst);
+
+ RTL_W8(Config5, RTL_R8(Config5) & ~spi_en);
+}
+
static void rtl_hw_start_8168(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -3940,6 +4138,10 @@ static void rtl_hw_start_8168(struct net_device *dev)
rtl_hw_start_8168dp(ioaddr, pdev);
break;
+ case RTL_GIGA_MAC_VER_32:
+ case RTL_GIGA_MAC_VER_33:
+ rtl_hw_start_8168e(ioaddr, pdev);
+ break;
default:
printk(KERN_ERR PFX "%s: unknown chipset (mac_version = %d).\n",
--
1.7.3.2
^ permalink raw reply related
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: Steffen Klassert @ 2011-03-21 12:06 UTC (permalink / raw)
To: Wei Yongjun; +Cc: David Miller, netdev
In-Reply-To: <4D8717DA.2010901@cn.fujitsu.com>
On Mon, Mar 21, 2011 at 05:18:18PM +0800, Wei Yongjun wrote:
>
> >> Btw, looking a bit closer to this. I think it would look a bit cleaner
> >> if we would add the xfrm_init_replay() call to xfrm_init_state() and
> >> to move the xfrm_init_state() call in xfrm_state_construct() behind
> >> the assign of the replay settings.
> > The xfrm_init_replay() should be call after the call to
> > xfrm_update_ae_params(x, attrs);
> > since xfrm_update_ae_params() may update the replay_esn.
> >
> > So we need move the xfrm_init_state() call just before return x.
>
>
> Oh, sorry, the memcpy looks like dup code since we used
> kmemdup. It is the same attr XFRMA_REPLAY_ESN_VAL.
>
Indeed, we don't need the memcpy here because we do a kmemdup when we
allocate repay_esn/preplay_esn. But we need to memcpy if we call
xfrm_update_ae_params() from xfrm_new_ae().
So we could just replace the kmemdup by kmalloc when we allocate
repay_esn/preplay_esn and move xfrm_init_state() at the end of the
function, as you suggested. xfrm_update_ae_params() would initialize
x->replay_esn and x->preplay_esn properly then.
> > The other issue:
> > static void xfrm_update_ae_params()
> > {
> > ...
> > memcpy(x->replay_esn, replay_esn,
> > xfrm_replay_state_esn_len(replay_esn));
> > ...
> > }
> >
> > the memcpy() may cause memory overlap if we build a special
> > nl_data, we should free it and then do kmemdup()?
> >
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox