* Re: [PATCH 3/5] NET: IPV4: ARP: allow to invalidate specific ARP entries
From: Eric Dumazet @ 2011-01-07 12:57 UTC (permalink / raw)
To: Maxim Levitsky
Cc: netdev, Morris, Patrick McHardy, Stefan Richter, James,
Alexey Kuznetsov, linux1394-devel, David S. Miller
In-Reply-To: <1294404478.7674.0.camel@maxim-laptop>
Le vendredi 07 janvier 2011 à 14:47 +0200, Maxim Levitsky a écrit :
> On Mon, 2010-11-29 at 04:09 +0200, Maxim Levitsky wrote:
> > IPv4 over firewire needs to be able to remove ARP entries
> > from the ARP cache that belong to nodes that are removed, because
> > IPv4 over firewire uses ARP packets for private information
> > about nodes.
> >
> > This information becomes invalid as soon as node drops
> > off the bus and when it reconnects, its only possible
> > to start takling to is after it responded to an ARP packet.
> > But ARP cache prevents such packets from being sent.
> >
> > CC: netdev@vger.kernel.org
> > CC: "David S. Miller" <davem@davemloft.net>
> > CC: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> > CC: James Morris <jmorris@namei.org>
> > CC: Patrick McHardy <kaber@trash.net>
>
> Anybody?
>
> Best regards,
> Maxim Levitsky
>
> >
> >
> > Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> > ---
> > include/net/arp.h | 1 +
> > net/ipv4/arp.c | 29 ++++++++++++++++++-----------
> > 2 files changed, 19 insertions(+), 11 deletions(-)
> >
> > diff --git a/include/net/arp.h b/include/net/arp.h
> > index f4cf6ce..91f0568 100644
> > --- a/include/net/arp.h
> > +++ b/include/net/arp.h
> > @@ -25,5 +25,6 @@ extern struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip,
> > const unsigned char *src_hw,
> > const unsigned char *target_hw);
> > extern void arp_xmit(struct sk_buff *skb);
> > +int arp_invalidate(struct net_device *dev, __be32 ip);
> >
> > #endif /* _ARP_H */
> > diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
> > index d8e540c..35b1272 100644
> > --- a/net/ipv4/arp.c
> > +++ b/net/ipv4/arp.c
> > @@ -1142,6 +1142,23 @@ static int arp_req_get(struct arpreq *r, struct net_device *dev)
> > return err;
> > }
> >
> > +int arp_invalidate(struct net_device *dev, __be32 ip)
> > +{
> > + int err = -ENXIO;
> > + struct neighbour *neigh = neigh_lookup(&arp_tbl, &ip, dev);
> > +
> > + if (neigh) {
> > + if (neigh->nud_state & ~NUD_NOARP)
> > + err = neigh_update(neigh, NULL, NUD_FAILED,
> > + NEIGH_UPDATE_F_OVERRIDE|
> > + NEIGH_UPDATE_F_ADMIN);
> > + neigh_release(neigh);
> > + }
> > +
> > + return err;
> > +}
> > +EXPORT_SYMBOL(arp_invalidate);
> > +
> > static int arp_req_delete_public(struct net *net, struct arpreq *r,
> > struct net_device *dev)
> > {
> > @@ -1162,7 +1179,6 @@ static int arp_req_delete(struct net *net, struct arpreq *r,
> > {
> > int err;
> > __be32 ip;
> > - struct neighbour *neigh;
> >
> > if (r->arp_flags & ATF_PUBL)
> > return arp_req_delete_public(net, r, dev);
> > @@ -1180,16 +1196,7 @@ static int arp_req_delete(struct net *net, struct arpreq *r,
> > if (!dev)
> > return -EINVAL;
> > }
> > - err = -ENXIO;
> > - neigh = neigh_lookup(&arp_tbl, &ip, dev);
> > - if (neigh) {
> > - if (neigh->nud_state & ~NUD_NOARP)
> > - err = neigh_update(neigh, NULL, NUD_FAILED,
> > - NEIGH_UPDATE_F_OVERRIDE|
> > - NEIGH_UPDATE_F_ADMIN);
> > - neigh_release(neigh);
> > - }
> > - return err;
> > + return arp_invalidate(dev, ip);
> > }
> >
> > /*
>
Hi Maxim
You were supposed to respin your patch after my commit :
(941666c2e3e0f9f6a1 net: RCU conversion of dev_getbyhwaddr() and
arp_ioctl())
Thanks
------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
mailing list linux1394-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux1394-devel
^ permalink raw reply
* [PATCH] CAIF: Fix IPv6 support in receive path for GPRS/3G
From: Sjur Brændeland @ 2011-01-07 11:57 UTC (permalink / raw)
To: davem, netdev; +Cc: Kumar Sanghvi, Sjur Braendeland
From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
Checks version field of IP in the receive path for GPRS/3G data
and appropriately sets the value of skb->protocol.
Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>
---
net/caif/chnl_net.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c
index 84a422c..fa9dab3 100644
--- a/net/caif/chnl_net.c
+++ b/net/caif/chnl_net.c
@@ -76,6 +76,8 @@ static int chnl_recv_cb(struct cflayer *layr, struct cfpkt *pkt)
struct chnl_net *priv = container_of(layr, struct chnl_net, chnl);
int pktlen;
int err = 0;
+ const u8 *ip_version;
+ u8 buf;
priv = container_of(layr, struct chnl_net, chnl);
@@ -90,7 +92,21 @@ static int chnl_recv_cb(struct cflayer *layr, struct cfpkt *pkt)
* send the packet to the net stack.
*/
skb->dev = priv->netdev;
- skb->protocol = htons(ETH_P_IP);
+
+ /* check the version of IP */
+ ip_version = skb_header_pointer(skb, 0, 1, &buf);
+ if (!ip_version)
+ return -EINVAL;
+ switch (*ip_version >> 4) {
+ case 4:
+ skb->protocol = htons(ETH_P_IP);
+ break;
+ case 6:
+ skb->protocol = htons(ETH_P_IPV6);
+ break;
+ default:
+ return -EINVAL;
+ }
/* If we change the header in loop mode, the checksum is corrupted. */
if (priv->conn_req.protocol == CAIFPROTO_DATAGRAM_LOOP)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 3/5] NET: IPV4: ARP: allow to invalidate specific ARP entries
From: Maxim Levitsky @ 2011-01-07 12:47 UTC (permalink / raw)
To: linux1394-devel
Cc: Stefan Richter, netdev, David S. Miller, Alexey Kuznetsov,
James Morris, Patrick McHardy
In-Reply-To: <1290996593-32416-4-git-send-email-maximlevitsky@gmail.com>
On Mon, 2010-11-29 at 04:09 +0200, Maxim Levitsky wrote:
> IPv4 over firewire needs to be able to remove ARP entries
> from the ARP cache that belong to nodes that are removed, because
> IPv4 over firewire uses ARP packets for private information
> about nodes.
>
> This information becomes invalid as soon as node drops
> off the bus and when it reconnects, its only possible
> to start takling to is after it responded to an ARP packet.
> But ARP cache prevents such packets from being sent.
>
> CC: netdev@vger.kernel.org
> CC: "David S. Miller" <davem@davemloft.net>
> CC: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> CC: James Morris <jmorris@namei.org>
> CC: Patrick McHardy <kaber@trash.net>
Anybody?
Best regards,
Maxim Levitsky
>
>
> Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
> ---
> include/net/arp.h | 1 +
> net/ipv4/arp.c | 29 ++++++++++++++++++-----------
> 2 files changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/include/net/arp.h b/include/net/arp.h
> index f4cf6ce..91f0568 100644
> --- a/include/net/arp.h
> +++ b/include/net/arp.h
> @@ -25,5 +25,6 @@ extern struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip,
> const unsigned char *src_hw,
> const unsigned char *target_hw);
> extern void arp_xmit(struct sk_buff *skb);
> +int arp_invalidate(struct net_device *dev, __be32 ip);
>
> #endif /* _ARP_H */
> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
> index d8e540c..35b1272 100644
> --- a/net/ipv4/arp.c
> +++ b/net/ipv4/arp.c
> @@ -1142,6 +1142,23 @@ static int arp_req_get(struct arpreq *r, struct net_device *dev)
> return err;
> }
>
> +int arp_invalidate(struct net_device *dev, __be32 ip)
> +{
> + int err = -ENXIO;
> + struct neighbour *neigh = neigh_lookup(&arp_tbl, &ip, dev);
> +
> + if (neigh) {
> + if (neigh->nud_state & ~NUD_NOARP)
> + err = neigh_update(neigh, NULL, NUD_FAILED,
> + NEIGH_UPDATE_F_OVERRIDE|
> + NEIGH_UPDATE_F_ADMIN);
> + neigh_release(neigh);
> + }
> +
> + return err;
> +}
> +EXPORT_SYMBOL(arp_invalidate);
> +
> static int arp_req_delete_public(struct net *net, struct arpreq *r,
> struct net_device *dev)
> {
> @@ -1162,7 +1179,6 @@ static int arp_req_delete(struct net *net, struct arpreq *r,
> {
> int err;
> __be32 ip;
> - struct neighbour *neigh;
>
> if (r->arp_flags & ATF_PUBL)
> return arp_req_delete_public(net, r, dev);
> @@ -1180,16 +1196,7 @@ static int arp_req_delete(struct net *net, struct arpreq *r,
> if (!dev)
> return -EINVAL;
> }
> - err = -ENXIO;
> - neigh = neigh_lookup(&arp_tbl, &ip, dev);
> - if (neigh) {
> - if (neigh->nud_state & ~NUD_NOARP)
> - err = neigh_update(neigh, NULL, NUD_FAILED,
> - NEIGH_UPDATE_F_OVERRIDE|
> - NEIGH_UPDATE_F_ADMIN);
> - neigh_release(neigh);
> - }
> - return err;
> + return arp_invalidate(dev, ip);
> }
>
> /*
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2 1/2] can: add driver for Softing card
From: Kurt Van Dijck @ 2011-01-07 12:29 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4D25ED70.7000303-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Thu, Jan 06, 2011 at 05:27:28PM +0100, Wolfgang Grandegger wrote:
> >> - Please avoid alignment of expressions and structure members.
>
I agree with most of them.
The alignment of register offset macro's is 1 thing I intend to
keep as is ...
Maybe I put a comment in front to explain why it's aligned...
Kurt
>
^ permalink raw reply
* Re: [PATCH] ehea: Add some info messages and fix an issue
From: Breno Leitao @ 2011-01-07 12:14 UTC (permalink / raw)
To: Anton Blanchard; +Cc: joe, netdev, davem
In-Reply-To: <20110107142430.42fda498@kryten>
Hi Anton,
On 01/07/2011 01:24 AM, Anton Blanchard wrote:
> It looks like you are now only initialising half the ring, but still
> telling the hardware to use the whole ring. Once you get through the
> entire ring once the errors go away.
You are correct. The problem in the past ehea_init_fill_rq1() wasn't
respecting the nr_rq1a parameter. So, every time ehea_init_fill_rqX()
was trying to allocated the entire skb arrary, and assume that the
entire array was allocated, which wasn't correct.
My patch just allocate the requested number of skbs (described in
nr_rq1a) in skb array, and tell hea that only that amount of skb were
allocated (via doorbell).
On the other side, ehea_proc_rwqes() tries to maximize the array usage,
meaning that if the array is not completely used, it'd try to allocate
an skb "on-the-fly", and this is expected (For example, when you
initialize the system on memory pressure)
That is why I sent another patch that turns this message a netif_info()
instead of a netif_error() (as it was in the past). The commit id for
this patch is 782615aea84e57dc7f2f922cea823df3de635a78
So, although this behaviour is completely expected, this code path
should only being executed on memory pressure. But I am suspecting this
code path is execute more often than I'd expect. Let me investigate this.
Thanks
Breno
^ permalink raw reply
* Re: genetlink misinterprets NEW as GET
From: Pablo Neira Ayuso @ 2011-01-07 12:12 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Ben Pfaff, Netfilter Developer Mailing List,
Linux Networking Developer Mailing List
In-Reply-To: <alpine.LNX.2.01.1101071033400.25363@obet.zrqbmnf.qr>
On 07/01/11 10:38, Jan Engelhardt wrote:
>
> On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote:
>>>>> /* Modifiers to GET request */
>>>>> #define NLM_F_ROOT 0x100
>>>>> #define NLM_F_MATCH 0x200
>>>>> #define NLM_F_ATOMIC 0x400
>>>>> #define NLM_F_DUMP (NLM_F_ROOT|NLM_F_MATCH)
>>> [...]
>>>>> [N.B.: I am also wondering whether
>>>>> (nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
>>>>> may have been desired, because NLM_F_DUMP is composed of two bits.]
>>>>
>>>> Someone may include NLM_F_ATOMIC to a dump operation, in that case the
>>>> checking that you propose is not valid.
>>>
>>> Are you saying that NLM_F_MATCH and NLM_F_ATOMIC are mutually
>>> exclusive, and that NLM_F_ROOT|NLM_F_ATOMIC would also signal a
>>> dump operation? Otherwise the test that Jan proposes looks valid
>>> to me.
>>
>> Indeed, Jan's test is fine to fix this. Please, send a patch to Davem asap.
>
> But that would still mean that a user sending a
> NLM_F_REQUEST|NLM_F_REPLACE|NLM_F_EXCL message would be misinterpreted
> as NLM_F_DUMP.
That flag combination does not make sense to me. Valid combinations are:
NLM_F_REQUEST|NLM_F_CREATE : if it does not exist, create it, if it
exists, update it.
NLM_F_REQUEST|NLM_F_CREATE|NLM_F_EXCL: if it does not exist, create it,
if it exists, return -EEXIST.
NLM_F_REQUEST|NLM_F_REPLACE: if it does not exist, return -ENOENT, if it
exists, replace it.
^ permalink raw reply
* Re: [PATCH] net/r8169: Update the function of parsing firmware
From: Francois Romieu @ 2011-01-07 11:44 UTC (permalink / raw)
To: Hayes Wang; +Cc: netdev, linux-kernel
In-Reply-To: <1294393509-3492-1-git-send-email-hayeswang@realtek.com>
Hayes Wang <hayeswang@realtek.com> :
> Update rtl_phy_write_fw function. The new function could
> parse the complex firmware which is used by RTL8111E and later.
> The new firmware may read data and do some operations, not just
> do writing only.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> drivers/net/r8169.c | 112 ++++++++++++++++++++++++++++++++++++++++++++-------
> 1 files changed, 97 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 27a7c20..2115424 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -1632,39 +1632,121 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
> {
> __le32 *phytable = (__le32 *)fw->data;
> struct net_device *dev = tp->dev;
> - size_t i;
> + size_t index;
...
> + u32 predata, count;
>
> if (fw->size % sizeof(*phytable)) {
> - netif_err(tp, probe, dev, "odd sized firmware %zd\n", fw->size);
> + netif_err(tp, probe, dev, "odd sized firmware %zd\n",
> + fw->size);
It fits within 80 columns, please keep it as is.
> return;
> }
>
> - for (i = 0; i < fw->size / sizeof(*phytable); i++) {
> - u32 action = le32_to_cpu(phytable[i]);
> + for (index = 0; index < fw->size / sizeof(*phytable); index++) {
> + u32 action = le32_to_cpu(phytable[index]);
>
> - if (!action)
> + switch(action & 0xF0000000) {
Please don't add uppercase hex.
> + case PHY_READ:
> + case PHY_DATA_OR:
> + case PHY_DATA_AND:
> + case PHY_BJMPN:
> + case PHY_READ_EFUSE:
> + case PHY_CLEAR_READCOUNT:
> + case PHY_WRITE:
> + case PHY_READCOUNT_EQ_SKIP:
> + case PHY_COMP_EQ_SKIPN:
> + case PHY_COMP_NEQ_SKIPN:
> + case PHY_WRITE_PREVIOUS:
> + case PHY_SKIPN:
> + case PHY_DELAY_MS:
> break;
[...]
> + for (index = 0; index < fw->size / sizeof(*phytable); ) {
[...]
> +
> + if (index < 0)
> + BUG();
It could imho validate a bit harder.
--
Ueimor
^ permalink raw reply
* [PATCH 3/3] dccp: make upper bound for seq_window consistent on 32/64 bit
From: Gerrit Renker @ 2011-01-07 11:35 UTC (permalink / raw)
To: davem; +Cc: dccp, netdev, Gerrit Renker
In-Reply-To: <1294400130-5604-3-git-send-email-gerrit@erg.abdn.ac.uk>
The 'seq_window' sysctl sets the initial value for the DCCP Sequence Window,
which may range from 32..2^46-1 (RFC 4340, 7.5.2). The patch sets the upper
bound consistently to 2^32-1 on both 32 and 64 bit systems, which should be
sufficient - with a RTT of 1sec and 1-byte packets, a seq_window of 2^32-1
corresponds to a link speed of 34 Gbps.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
Documentation/networking/dccp.txt | 1 +
net/dccp/sysctl.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletions(-)
--- a/Documentation/networking/dccp.txt
+++ b/Documentation/networking/dccp.txt
@@ -167,6 +167,7 @@ rx_ccid = 2
seq_window = 100
The initial sequence window (sec. 7.5.2) of the sender. This influences
the local ackno validity and the remote seqno validity windows (7.5.1).
+ Values in the range Wmin = 32 (RFC 4340, 7.5.2) up to 2^32-1 can be set.
tx_qlen = 5
The size of the transmit buffer in packets. A value of 0 corresponds
--- a/net/dccp/sysctl.c
+++ b/net/dccp/sysctl.c
@@ -21,7 +21,8 @@
/* Boundary values */
static int zero = 0,
u8_max = 0xFF;
-static unsigned long seqw_min = 32;
+static unsigned long seqw_min = DCCPF_SEQ_WMIN,
+ seqw_max = 0xFFFFFFFF; /* maximum on 32 bit */
static struct ctl_table dccp_default_table[] = {
{
@@ -31,6 +32,7 @@ static struct ctl_table dccp_default_table[] = {
.mode = 0644,
.proc_handler = proc_doulongvec_minmax,
.extra1 = &seqw_min, /* RFC 4340, 7.5.2 */
+ .extra2 = &seqw_max,
},
{
.procname = "rx_ccid",
^ permalink raw reply
* [PATCH 2/3] dccp: fix bug in updating the GSR
From: Gerrit Renker @ 2011-01-07 11:35 UTC (permalink / raw)
To: davem; +Cc: dccp, netdev, Samuel Jero
In-Reply-To: <1294400130-5604-2-git-send-email-gerrit@erg.abdn.ac.uk>
From: Samuel Jero <sj323707@ohio.edu>
Currently dccp_check_seqno allows any valid packet to update the Greatest
Sequence Number Received, even if that packet's sequence number is less than
the current GSR. This patch adds a check to make sure that the new packet's
sequence number is greater than GSR.
Signed-off-by: Samuel Jero <sj323707@ohio.edu>
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/dccp.h | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
--- a/net/dccp/dccp.h
+++ b/net/dccp/dccp.h
@@ -426,7 +426,8 @@ static inline void dccp_update_gsr(struct sock *sk, u64 seq)
{
struct dccp_sock *dp = dccp_sk(sk);
- dp->dccps_gsr = seq;
+ if (after48(seq, dp->dccps_gsr))
+ dp->dccps_gsr = seq;
/* Sequence validity window depends on remote Sequence Window (7.5.1) */
dp->dccps_swl = SUB48(ADD48(dp->dccps_gsr, 1), dp->dccps_r_seq_win / 4);
/*
^ permalink raw reply
* [PATCH 1/3] dccp: fix return value for sequence-invalid packets
From: Gerrit Renker @ 2011-01-07 11:35 UTC (permalink / raw)
To: davem; +Cc: dccp, netdev, Samuel Jero
In-Reply-To: <1294400130-5604-1-git-send-email-gerrit@erg.abdn.ac.uk>
From: Samuel Jero <sj323707@ohio.edu>
Currently dccp_check_seqno returns 0 (indicating a valid packet) if the
acknowledgment number is out of bounds and the sync that RFC 4340 mandates at
this point is currently being rate-limited. This function should return -1,
indicating an invalid packet.
Signed-off-by: Samuel Jero <sj323707@ohio.edu>
Acked-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/input.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--- a/net/dccp/input.c
+++ b/net/dccp/input.c
@@ -260,7 +260,7 @@ static int dccp_check_seqno(struct sock *sk, struct sk_buff *skb)
*/
if (time_before(now, (dp->dccps_rate_last +
sysctl_dccp_sync_ratelimit)))
- return 0;
+ return -1;
DCCP_WARN("Step 6 failed for %s packet, "
"(LSWL(%llu) <= P.seqno(%llu) <= S.SWH(%llu)) and "
^ permalink raw reply
* net-next-2.6 [PATCH 0/3] dccp: several sequence-number validation fixes
From: Gerrit Renker @ 2011-01-07 11:35 UTC (permalink / raw)
To: davem; +Cc: dccp, netdev
In-Reply-To: <0110107112837.GA5315@gerrit.erg.abdn.ac.uk>
Hi Dave,
please find attached 3 bug fixes which recently came up on dccp@vger.
Patch #1: fixes a bug which wrongly classified sequence-invalid packets.
Patch #2: fixes a bug in updating the Greatest Sequence number Received (GSR).
Patch #3: fixes an inconsistency in setting the sequence window on 32/64 bit.
I have also placed this in into a fresh (today's) copy of net-next-2.6, on
git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp']
---
Documentation/networking/dccp.txt | 1 +
net/dccp/dccp.h | 3 ++-
net/dccp/input.c | 2 +-
net/dccp/sysctl.c | 4 +++-
4 files changed, 7 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: possible issue between bridge igmp/multicast handling & bnx2x on kernel 2.6.34 and >
From: Eric Dumazet @ 2011-01-07 11:28 UTC (permalink / raw)
To: Yann Dupont; +Cc: netdev
In-Reply-To: <4D26EDA4.7060502@univ-nantes.fr>
Le vendredi 07 janvier 2011 à 11:40 +0100, Yann Dupont a écrit :
> Le 04/01/2011 14:40, Yann Dupont a écrit :
> ...
> > We just added BCM57711 10G cards (bnx2x driver) on our blade servers
> > (connected to 10G Power Connect M8024).
> > Since then, we are experiencing random lost of packets.
> >
> > Symptom : packets are lost on some vlans for a few seconds, then
> > things go back to normal (and stops again a few minutes later)
> >
>
> As I didn't had answer so far , I digged a little more and captured more
> packets.
> I just noticed that an event trigger that problem : IPv6 neighbor
> discovery packet .
>
> This is , of course, a multicast packet.
>
> Just saw that 2.6.36.3 should include this fix :
>
> > From: David Stevens<dlstevens@us.ibm.com>
> >
> > [ Upstream commit 04bdf0c9a451863e50fff627713a900a2cabb998 ]
> >
> > This patch fixes a missing ntohs() for bridge IPv6 multicast snooping.
> But in fact , I just tested, and this doesn't cure the problem :(
>
> This bug
> - only occurs with bnx2x with tagged vlans, attached to bridges. Other
> interfaces (bnx2 , for exemple) works fine. bnx2x without bridges works
> fine.
> - only happens when bridge is compiled with CONFIG_BRIDGE_IGMP_SNOOPING
> (default setting)
> - is triggered by IPv6 neighbor discovery packet. Just after that
> packet, others packets are discarded for some time.
> - packets originating from same vlans are not affected, only packets
> previously routed are discarded. Examinating those packets, I don't
> undersand why, apart TTL (and mac address), they seems similar .
> - has origin circa 2.6.33 :
> fe2d7c70b747d5d968f4e8fa210676d49d40059 is the first bad commit
> commit 3fe2d7c70b747d5d968f4e8fa210676d49d40059
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sun Feb 28 00:49:38 2010 -0800
>
> bridge: Add multicast start/stop hooks
>
> This patch hooks up the bridge start/stop and add/delete/disable
> port functions to the new multicast module.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
>
> What can I do to help fixing this bug ?
> regards,
>
Please take a look at whole thread at
https://lkml.org/lkml/2010/8/13/200
I guess this is a similar problem.
^ permalink raw reply
* Re: rndis gadget: Inconsistent locking
From: David Brownell @ 2011-01-07 11:20 UTC (permalink / raw)
To: Neil Jones; +Cc: linux-usb, netdev
In-Reply-To: <AANLkTi=OS+jernOe8y1fbMbx5Rf+JRcvzqGY4Z2LKqsH@mail.gmail.com>
> Yes Michal Nazarewicz has seen this on a S3C UDC,
Good to confirm that. As I mentioned, other folk have seen much the same bug on other hardware; we
know it's neither a new nor a HW-specific issue.
Correction to an earlier comment of mine:
https://patchwork.kernel.org/patch/195562/
does correctly identify the commit which
caused this bug in multiple drivers.
However, that patch won't apply to the latest
tree from Linus.
Michal, can you update and resubmit, so I can
at least ack your fix and xpedite its merge?
It'd be good to have RNDIS work again, a fair
number of folk rely on it, and this seems to be
the main obstacle to continuing to do that.
- Dave
^ permalink raw reply
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Kirill A. Shutemov @ 2011-01-07 11:19 UTC (permalink / raw)
To: Al Viro
Cc: Trond Myklebust, J. Bruce Fields, Neil Brown, Pavel Emelyanov,
linux-nfs, David S. Miller, netdev, linux-kernel
In-Reply-To: <20110107111222.GA19395@shutemov.name>
On Fri, Jan 07, 2011 at 01:12:22PM +0200, Kirill A. Shutemov wrote:
> On Wed, Jan 05, 2011 at 11:41:55AM +0000, Al Viro wrote:
> > On Wed, Dec 29, 2010 at 03:14:18PM +0200, Kirill A. Shutemov wrote:
> > > Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
> >
> > Won't that make sunrpc impossible to rmmod once you've got it in?
> > Note that having a reference to vfsmount pins it down, which pins
> > the superblock down, which pins the file_system_type down, which
> > pins the damn module down. So cleanup_sunrpc() won't be ever called,
> > AFAICS...
>
> Hm.. rpc_pipe_fs_type.owner = NULL seems fix the problem.
> Is it valid solution in this case?
Please, ignore it. :)
--
Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v2 00/12] make rpc_pipefs be mountable multiple time
From: Kirill A. Shutemov @ 2011-01-07 11:12 UTC (permalink / raw)
To: Al Viro
Cc: Kirill A. Shutemov, Trond Myklebust, J. Bruce Fields, Neil Brown,
Pavel Emelyanov, linux-nfs, David S. Miller, netdev, linux-kernel
In-Reply-To: <20110105114155.GN19804@ZenIV.linux.org.uk>
On Wed, Jan 05, 2011 at 11:41:55AM +0000, Al Viro wrote:
> On Wed, Dec 29, 2010 at 03:14:18PM +0200, Kirill A. Shutemov wrote:
> > Prepare nfs/sunrpc stack to use multiple instances of rpc_pipefs.
>
> Won't that make sunrpc impossible to rmmod once you've got it in?
> Note that having a reference to vfsmount pins it down, which pins
> the superblock down, which pins the file_system_type down, which
> pins the damn module down. So cleanup_sunrpc() won't be ever called,
> AFAICS...
Hm.. rpc_pipe_fs_type.owner = NULL seems fix the problem.
Is it valid solution in this case?
--
Kirill A. Shutemov
^ permalink raw reply
* Re: possible issue between bridge igmp/multicast handling & bnx2x on kernel 2.6.34 and >
From: Yann Dupont @ 2011-01-07 10:40 UTC (permalink / raw)
To: netdev
In-Reply-To: <4D23234E.30709@univ-nantes.fr>
Le 04/01/2011 14:40, Yann Dupont a écrit :
...
> We just added BCM57711 10G cards (bnx2x driver) on our blade servers
> (connected to 10G Power Connect M8024).
> Since then, we are experiencing random lost of packets.
>
> Symptom : packets are lost on some vlans for a few seconds, then
> things go back to normal (and stops again a few minutes later)
>
As I didn't had answer so far , I digged a little more and captured more
packets.
I just noticed that an event trigger that problem : IPv6 neighbor
discovery packet .
This is , of course, a multicast packet.
Just saw that 2.6.36.3 should include this fix :
> From: David Stevens<dlstevens@us.ibm.com>
>
> [ Upstream commit 04bdf0c9a451863e50fff627713a900a2cabb998 ]
>
> This patch fixes a missing ntohs() for bridge IPv6 multicast snooping.
But in fact , I just tested, and this doesn't cure the problem :(
This bug
- only occurs with bnx2x with tagged vlans, attached to bridges. Other
interfaces (bnx2 , for exemple) works fine. bnx2x without bridges works
fine.
- only happens when bridge is compiled with CONFIG_BRIDGE_IGMP_SNOOPING
(default setting)
- is triggered by IPv6 neighbor discovery packet. Just after that
packet, others packets are discarded for some time.
- packets originating from same vlans are not affected, only packets
previously routed are discarded. Examinating those packets, I don't
undersand why, apart TTL (and mac address), they seems similar .
- has origin circa 2.6.33 :
fe2d7c70b747d5d968f4e8fa210676d49d40059 is the first bad commit
commit 3fe2d7c70b747d5d968f4e8fa210676d49d40059
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Sun Feb 28 00:49:38 2010 -0800
bridge: Add multicast start/stop hooks
This patch hooks up the bridge start/stop and add/delete/disable
port functions to the new multicast module.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
What can I do to help fixing this bug ?
regards,
--
Yann Dupont - Service IRTS, DSI Université de Nantes
Tel : 02.53.48.49.20 - Mail/Jabber : Yann.Dupont@univ-nantes.fr
^ permalink raw reply
* Re: About disabling congestion control
From: Eric Dumazet @ 2011-01-07 10:33 UTC (permalink / raw)
To: Syed Obaid Amin; +Cc: Stephen Hemminger, netdev, Michael Kerrisk
In-Reply-To: <AANLkTi=FLGM1z0VLH+WZXvF=7TZHtMhxLe+KRF3ojWR1@mail.gmail.com>
Le vendredi 07 janvier 2011 à 05:04 -0500, Syed Obaid Amin a écrit :
> Thanks for the reply. Yes I also thought to create a sort of NULL
> congestion control type that does nothing. But this way the changes
> would be system wide. BTW, would some one share the insight that why
> linux uses sysctl to select a congestion control algorithm instead of
> socket options.
Hmm, maybe "man 7 tcp" is not up2date.
It mentions TCP_CONGESTION once but doesnt describe it.
CC Michael Kerrisk <mtk.manpages@gmail.com> ;)
http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html
Lets say you have a kernel with support for two congestion controls :
# cat /proc/sys/net/ipv4/tcp_allowed_congestion_control
cubic reno
# cat /proc/sys/net/ipv4/tcp_congestion_control
cubic
Therefore, default is cubic, but you can change to reno if you want.
setsockopt(sock, SOL_TCP, TCP_CONGESTION, "reno", strlen("reno"));
^ permalink raw reply
* Re: About disabling congestion control
From: Syed Obaid Amin @ 2011-01-07 10:04 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110106173758.37bfef4d@nehalam>
Thanks for the reply. Yes I also thought to create a sort of NULL
congestion control type that does nothing. But this way the changes
would be system wide. BTW, would some one share the insight that why
linux uses sysctl to select a congestion control algorithm instead of
socket options.
Thanks again,
Obaid
On Thu, Jan 6, 2011 at 8:37 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Thu, 6 Jan 2011 20:25:18 -0500
> Syed Obaid Amin <obaidasyed@gmail.com> wrote:
>
>> Hey all,
>>
>> I am currently working on a socket option to disable the tcp
>> congestion control. I think the simplest approach to do this is to
>> ignore cwnd before sending out a packet.
>>
>> After going through tcp output engine it seems that tcp_cwnd_test is
>> the method that decides that how many segments can be sent out on a
>> wire. For testing it out, I changed this method so that if no-cc
>> option is ON, just return a big constant value. But, it didn't work
>> and I am unable to see a burst of pkts. It looks like that I am
>> missing something here.
>>
>> Any suggestions that what is the right place to look for disabling the
>> congestion control ?
>>
>> Thanks much!
>>
>> Obaid
>
> I assume this is just a local hack experiment; not something you
> want to actually submit for other users to use...
>
> The easiest/safest way to do this would be to build/define a new TCP congestion
> control type that does nothing.
>
>
^ permalink raw reply
* Re: [PATCH v3 05/10] net/fec: add dual fec support for mx28
From: Uwe Kleine-König @ 2011-01-07 9:44 UTC (permalink / raw)
To: Shawn Guo
Cc: davem, gerg, baruch, eric, bryan.wu, r64343, B32542, lw, w.sang,
s.hauer, netdev, linux-arm-kernel
In-Reply-To: <20110107070056.GA28358@freescale.com>
Hello,
On Fri, Jan 07, 2011 at 03:00:57PM +0800, Shawn Guo wrote:
> On Thu, Jan 06, 2011 at 08:10:47AM +0100, Uwe Kleine-König wrote:
> > Hello Shawn,
> >
> [...]
> > > > > + /*
> > > > > + * enet-mac reset will reset mac address registers too,
> > > > > + * so need to reconfigure it.
> > > > > + */
> > > > > + if (fec_is_enetmac) {
> > > > > + memcpy(&temp_mac, dev->dev_addr, ETH_ALEN);
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > + writel(cpu_to_be32(temp_mac[0]), fep->hwp + FEC_ADDR_LOW);
> > > > > + writel(cpu_to_be32(temp_mac[1]), fep->hwp + FEC_ADDR_HIGH);
> > > > where is the value saved to temp_mac[]? For me it looks you write
> > > > uninitialized data into the mac registers.
> > >
> > > memcpy above.
> > oops. right. I looked for something like
> >
> > temp_mac[0] = dev->dev_addr[0] << $shiftfor0 | ...
> >
> > which AFAIK is what you want here. memcpy is sensible to (at least)
> > endian issues. If you ask me factor out the setting of the mac address
> > in probe to a function and use that here, too.
> >
> The memcpy of mac address is being widely used in fec and other
> network drivers, and I do not prefer to change something so common
> in this patch set.
Hmm, fec_get_mac uses memcpy as does fec_set_mac_address.
fec_enet_init uses mask and shift. When writing my comment I only saw
the latter. Having that uniform and only in two places (one for setting
and for reading) would be great.
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] net/r8169: Update the function of parsing firmware
From: Hayes Wang @ 2011-01-07 9:45 UTC (permalink / raw)
To: romieu; +Cc: netdev, linux-kernel, Hayes Wang
Update rtl_phy_write_fw function. The new function could
parse the complex firmware which is used by RTL8111E and later.
The new firmware may read data and do some operations, not just
do writing only.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 112 ++++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 97 insertions(+), 15 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 27a7c20..2115424 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1632,39 +1632,121 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
{
__le32 *phytable = (__le32 *)fw->data;
struct net_device *dev = tp->dev;
- size_t i;
+ size_t index;
+ u32 predata, count;
if (fw->size % sizeof(*phytable)) {
- netif_err(tp, probe, dev, "odd sized firmware %zd\n", fw->size);
+ netif_err(tp, probe, dev, "odd sized firmware %zd\n",
+ fw->size);
return;
}
- for (i = 0; i < fw->size / sizeof(*phytable); i++) {
- u32 action = le32_to_cpu(phytable[i]);
+ for (index = 0; index < fw->size / sizeof(*phytable); index++) {
+ u32 action = le32_to_cpu(phytable[index]);
- if (!action)
+ switch(action & 0xF0000000) {
+ case PHY_READ:
+ case PHY_DATA_OR:
+ case PHY_DATA_AND:
+ case PHY_BJMPN:
+ case PHY_READ_EFUSE:
+ case PHY_CLEAR_READCOUNT:
+ case PHY_WRITE:
+ case PHY_READCOUNT_EQ_SKIP:
+ case PHY_COMP_EQ_SKIPN:
+ case PHY_COMP_NEQ_SKIPN:
+ case PHY_WRITE_PREVIOUS:
+ case PHY_SKIPN:
+ case PHY_DELAY_MS:
break;
- if ((action & 0xf0000000) != PHY_WRITE) {
- netif_err(tp, probe, dev,
- "unknown action 0x%08x\n", action);
+ case PHY_READ_MAC_BYTE:
+ case PHY_WRITE_MAC_BYTE:
+ case PHY_WRITE_ERI_WORD:
+ default:
+ netif_err(tp, probe, tp->dev,
+ "Invalid action 0x%08x\n", action);
return;
}
}
- while (i-- != 0) {
- u32 action = le32_to_cpu(*phytable);
- u32 data = action & 0x0000ffff;
- u32 reg = (action & 0x0fff0000) >> 16;
+ predata = 0;
+ count = 0;
+
+ for (index = 0; index < fw->size / sizeof(*phytable); ) {
+ u32 action = le32_to_cpu(phytable[index]);
+ u32 data = action & 0x0000FFFF;
+ u32 regno = (action & 0x0FFF0000) >> 16;
+
+ if (!action)
+ break;
- switch(action & 0xf0000000) {
+ switch(action & 0xF0000000) {
+ case PHY_READ:
+ predata = rtl_readphy(tp, regno);
+ count++;
+ index++;
+ break;
+ case PHY_DATA_OR:
+ predata |= data;
+ index++;
+ break;
+ case PHY_DATA_AND:
+ predata &= data;
+ index++;
+ break;
+ case PHY_BJMPN:
+ index -= regno;
+ break;
+ case PHY_READ_EFUSE:
+ predata = rtl8168d_efuse_read(tp->mmio_addr, regno);
+ index++;
+ break;
+ case PHY_CLEAR_READCOUNT:
+ count = 0;
+ index++;
+ break;
case PHY_WRITE:
- rtl_writephy(tp, reg, data);
- phytable++;
+ rtl_writephy(tp, regno, data);
+ index++;
+ break;
+ case PHY_READCOUNT_EQ_SKIP:
+ if (count == data)
+ index += 2;
+ else
+ index += 1;
+ break;
+ case PHY_COMP_EQ_SKIPN:
+ if (predata == data)
+ index += regno;
+ index++;
+ break;
+ case PHY_COMP_NEQ_SKIPN:
+ if (predata != data)
+ index += regno;
+ index++;
+ break;
+ case PHY_WRITE_PREVIOUS:
+ rtl_writephy(tp, regno, predata);
+ index++;
break;
+ case PHY_SKIPN:
+ index += regno + 1;
+ break;
+ case PHY_DELAY_MS:
+ mdelay(data);
+ index++;
+ break;
+
+ case PHY_READ_MAC_BYTE:
+ case PHY_WRITE_MAC_BYTE:
+ case PHY_WRITE_ERI_WORD:
default:
BUG();
}
+
+ if (index < 0)
+ BUG();
}
}
--
1.7.3.2
^ permalink raw reply related
* Re: genetlink misinterprets NEW as GET
From: Jan Engelhardt @ 2011-01-07 9:38 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Ben Pfaff, Netfilter Developer Mailing List,
Linux Networking Developer Mailing List
In-Reply-To: <4D266CE5.4000309@netfilter.org>
On Friday 2011-01-07 02:31, Pablo Neira Ayuso wrote:
>>>> /* Modifiers to GET request */
>>>> #define NLM_F_ROOT 0x100
>>>> #define NLM_F_MATCH 0x200
>>>> #define NLM_F_ATOMIC 0x400
>>>> #define NLM_F_DUMP (NLM_F_ROOT|NLM_F_MATCH)
>> [...]
>>>> [N.B.: I am also wondering whether
>>>> (nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP
>>>> may have been desired, because NLM_F_DUMP is composed of two bits.]
>>>
>>> Someone may include NLM_F_ATOMIC to a dump operation, in that case the
>>> checking that you propose is not valid.
>>
>> Are you saying that NLM_F_MATCH and NLM_F_ATOMIC are mutually
>> exclusive, and that NLM_F_ROOT|NLM_F_ATOMIC would also signal a
>> dump operation? Otherwise the test that Jan proposes looks valid
>> to me.
>
>Indeed, Jan's test is fine to fix this. Please, send a patch to Davem asap.
But that would still mean that a user sending a
NLM_F_REQUEST|NLM_F_REPLACE|NLM_F_EXCL message would be misinterpreted
as NLM_F_DUMP.
There just is no way for genl to figure out from an arbitrary nlmsghdr
whether it's a dump request or something else without breaking
something.
The overlapping of NLM_F_ is quite unfortunate.
^ permalink raw reply
* Re: rndis gadget: Inconsistent locking
From: Neil Jones @ 2011-01-07 9:30 UTC (permalink / raw)
To: David Brownell
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1293407341.2255.1038.camel@helium>
>Has this shown up with other USB device controller drivers, or just the
>DWC (DesignWare)? UDC driver?
Yes Michal Nazarewicz has seen this on a S3C UDC, heres his stack trace:
WARNING: at kernel/softirq.c:143 local_bh_enable_ip+0x44/0xc0()
[...]
[<c0049024>] (local_bh_enable_ip+0x44/0xc0) from [<c025ef18>]
(dev_txq_stats_fold+0xac/0x108)
[<c025ef18>] (dev_txq_stats_fold+0xac/0x108) from [<c025f018>]
(dev_get_stats+0xa4/0xac)
[<c025f018>] (dev_get_stats+0xa4/0xac) from [<c01f72bc>]
(gen_ndis_query_resp+0x4c/0x43c)
[<c01f72bc>] (gen_ndis_query_resp+0x4c/0x43c) from [<c01f784c>]
(rndis_msg_parser+0x1a0/0x32c)
[<c01f784c>] (rndis_msg_parser+0x1a0/0x32c) from [<c01f79f8>]
(rndis_command_complete+0x20/0x4c)
[<c01f79f8>] (rndis_command_complete+0x20/0x4c) from [<c01f3278>]
(done+0x5c/0x70)
[<c01f3278>] (done+0x5c/0x70) from [<c01f3c60>] (complete_tx+0xf0/0x1a8)
[<c01f3c60>] (complete_tx+0xf0/0x1a8) from [<c01f3d8c>]
(process_ep_in_intr+0x74/0x14c)
[<c01f3d8c>] (process_ep_in_intr+0x74/0x14c) from [<c01f470c>]
(s3c_udc_irq+0x2c8/0x3f4)
[<c01f470c>] (s3c_udc_irq+0x2c8/0x3f4) from [<c006dfd0>]
(handle_IRQ_event+0x24/0xe4)
[<c006dfd0>] (handle_IRQ_event+0x24/0xe4) from [<c006fe40>]
(handle_level_irq+0xb0/0x12c)
[<c006fe40>] (handle_level_irq+0xb0/0x12c) from [<c0027074>]
(asm_do_IRQ+0x74/0x98)
[<c0027074>] (asm_do_IRQ+0x74/0x98) from [<c0027ca4>] (__irq_usr+0x44/0xc0)
(taken from Michal's original patch here:
<https://patchwork.kernel.org/patch/195562/>)
Neil
On Sun, Dec 26, 2010 at 11:49 PM, David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> wrote:
> On Wed, 2010-12-08 at 15:11 +0000, Neil Jones wrote:
>>
>> Im getting another lockdep warning when using the RNDIS gadget:
>
>
>
> Probably this is either
>
>
> (a) a recent regression, maybe caused by a change ISTR in the network
> layer stats handling ... which broke another USB + NET driver in much
> the same way, wish I remembered details of which driver, the fix
> there was simple and maybe a good model for fixing this one.
>
> or (b) ... maybe a
> DWC-specific USB device controller driver oddity. (Seemed less likely
> to me when I glanced at the stackdumps below.
>
> Has this shown up with other USB device controller drivers, or just the
> DWC (DesignWare)? UDC driver?
>
> I'll say I'm not keen on adding a thread to the driver. It's worked
> fine without one for many years, even running lockdep. Whatever change
> (network stack or using DWC) caused the locking issue can be fixed
> without a new thread.
>
> - Dave
>
>
>
> The first thing I noticed was that very little of the dumped stack
> context was part of the RNDIS gadget ... often a sign that the issue
> is in the call down to the code dumping its stack (or its context).
>
> (Or if my recollection is right ... that there was an incompatible
> change in a network statistics call, and whoever changed that didn't
> update all affected callers. (ergo breakage here and in another driver.
>>
>> WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
>> Modules linked in: g_ether
>>
>> Call trace:
>> [<40003bf8>] _show_stack+0x68/0x7c
>> [<40003c20>] _dump_stack+0x14/0x28
>> [<40013c3c>] _warn_slowpath_common+0x5c/0x7c
>> [<40013c74>] _warn_slowpath_null+0x18/0x2c
>> [<4001b17c>] ___local_bh_disable+0xc0/0xd0
>> [<4001b1a0>] _local_bh_disable+0x14/0x28
>> [<402e57f8>] __raw_spin_lock_bh+0x18/0x54
>> [<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
>> [<402580c4>] _dev_get_stats+0xb8/0xc0
>> [<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
>> [<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
>> [<401d66fc>] _dwc_otg_request_done+0xd8/0x220
>> [<401d928c>] _ep0_complete_request+0x3f4/0x578
>> [<401d95bc>] _handle_ep0+0x1ac/0x146c
>> [<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
>> [<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
>> [<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
>> [<40054cf4>] _handle_IRQ_event+0x4c/0x184
>> [<40057b4c>] _handle_level_irq+0xac/0x15c
>> [<4000b204>] _metag_soc_irq_demux+0xac/0xb4
>> [<40002dd4>] _do_IRQ+0x4c/0x78
>> [<40004000>] _trigger_handler+0x38/0xac
>> [<40000b18>] ___TBIBoingVec+0xc/0x10
>> [<40003588>] _cpu_idle+0x54/0x78
>>
>> no locks held by swapper/0.
>> ---[ end trace 77ac3cfee0ae5b25 ]---
>>
>> It looks like we are calling spin_lock_bh in the completion function
>> which is running in hard_irq, I think the driver should defer handling
>> this msg (and maybe all requests) to a workqueue?
>>
>> Cheers
>>
>> Neil
>>
>>
>>
>> On Wed, Dec 8, 2010 at 3:03 PM, Neil Jones <neiljay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Hi,
>> >
>> > Im getting another lockdep warning when using the RNDIS gadget:
>> >
>> > WARNING: at kernel/softirq.c:98 ___local_bh_disable+0xc4/0xd0()
>> > Modules linked in: g_ether
>> >
>> > Call trace:
>> > [<40003bf8>] _show_stack+0x68/0x7c
>> > [<40003c20>] _dump_stack+0x14/0x28
>> > [<40013c3c>] _warn_slowpath_common+0x5c/0x7c
>> > [<40013c74>] _warn_slowpath_null+0x18/0x2c
>> > [<4001b17c>] ___local_bh_disable+0xc0/0xd0
>> > [<4001b1a0>] _local_bh_disable+0x14/0x28
>> > [<402e57f8>] __raw_spin_lock_bh+0x18/0x54
>> > [<40257f4c>] _dev_txq_stats_fold+0x7c/0x13c
>> > [<402580c4>] _dev_get_stats+0xb8/0xc0
>> > [<781d4e60>] _rndis_msg_parser+0x288/0xa04 [g_ether]
>> > [<781d5600>] _rndis_command_complete+0x24/0x70 [g_ether]
>> > [<401d66fc>] _dwc_otg_request_done+0xd8/0x220
>> > [<401d928c>] _ep0_complete_request+0x3f4/0x578
>> > [<401d95bc>] _handle_ep0+0x1ac/0x146c
>> > [<401daf7c>] _dwc_otg_pcd_handle_in_ep_intr+0x1c0/0x8bc
>> > [<401db8dc>] _dwc_otg_pcd_handle_intr+0x264/0x294
>> > [<401d6288>] _dwc_otg_pcd_irq+0x10/0x30
>> > [<40054cf4>] _handle_IRQ_event+0x4c/0x184
>> > [<40057b4c>] _handle_level_irq+0xac/0x15c
>> > [<4000b204>] _metag_soc_irq_demux+0xac/0xb4
>> > [<40002dd4>] _do_IRQ+0x4c/0x78
>> > [<40004000>] _trigger_handler+0x38/0xac
>> > [<40000b18>] ___TBIBoingVec+0xc/0x10
>> > [<40003588>] _cpu_idle+0x54/0x78
>> >
>> > no locks held by swapper/0.
>> > ---[ end trace 77ac3cfee0ae5b25 ]---
>> >
>> > It
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: 2.6.37 vlans on bnx2 not functional, panic with tcpdump
From: selsinork @ 2011-01-07 9:03 UTC (permalink / raw)
To: Michael Chan; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1294361206.21580.7.camel@HP1>
On Fri, Jan 7, 2011 at 12:46 AM, Michael Chan <mchan@broadcom.com> wrote:
> May be you have management firmware running on your devices that can
> change the behavior. Can you provide ethtool -i eth0 on both bnx2
> devices on your system?
This particular system has four onboard ports, a two port add-in card
and a single port fiber card all using bnx2, so I have some options to
try different devices if there's something different about them.
Details of all of them below.
Booting the same system back to 2.6.36 with the patch I mentioned
previously leaves me with a functioning network, so given it could be
management firmware related, why does it work on .36 but not .37 ?
The install is very stripped down, there's no udev or /sbin/hotplug
loading firmware behind my back as neither are installed. So firmware
is whatever comes with the kernel. Just having had a look, I see the
firmware provided with the kernel has changed in .37, but the output
of ethtool -i shows the same firmware being used with .36 and .37
Iain
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6
controllers (rev 01)
07:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
07:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709
Gigabit Ethernet (rev 20)
0a:00.0 PCI bridge: Broadcom EPB PCI-Express to PCI-X Bridge (rev c3)
0b:00.0 Ethernet controller: Broadcom Corporation NetXtreme II
BCM5708S Gigabit Ethernet (rev 12)
from 2.6.37:
root@64bit:~# ethtool -i eth0
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2 NCSI 2.0.6
bus-info: 0000:02:00.0
root@64bit:~# ethtool -i eth1
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2 NCSI 2.0.6
bus-info: 0000:02:00.1
root@64bit:~# ethtool -i eth2
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:03:00.0
root@64bit:~# ethtool -i eth3
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:03:00.1
root@64bit:~# ethtool -i eth4
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:07:00.0
root@64bit:~# ethtool -i eth5
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2
bus-info: 0000:07:00.1
root@64bit:~# ethtool -i eth6
driver: bnx2
version: 2.0.17
firmware-version: bc 1.9.6
bus-info: 0000:0b:00.0
from 2.6.36:
ethtool -i eth1
driver: bnx2
version: 2.0.17
firmware-version: bc 5.2.2 NCSI 2.0.6
bus-info: 0000:02:00.1
^ permalink raw reply
* Re: [RFC] sched: CHOKe packet scheduler (v0.2)
From: Eric Dumazet @ 2011-01-07 8:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110106205549.0de56de1@nehalam>
Le jeudi 06 janvier 2011 à 20:55 -0800, Stephen Hemminger a écrit :
> The problem is that large tables of pointers in kernel require either
> contiguous allocation or some indirect table algorithm.
>
By large table, how many slots do you envision ?
1024 ?
8192 ?
65536 ?
Even insane value like 65536 is OK most of the time.
if kmalloc(GFP_KERNEL) fails, try vmalloc().
We are in process context and are allowed to sleep when qdisc is
created.
Anyway, accessing a random skb in a list of 65536 skbs is just crazy.
^ permalink raw reply
* [PATCH] sh: sh_eth: Add support ethtool
From: Nobuhiro Iwamatsu @ 2011-01-07 7:25 UTC (permalink / raw)
To: netdev; +Cc: linux-sh, Nobuhiro Iwamatsu, Yoshihiro Shimoda
This commit supports following functions.
- get_drvinfo
- get_settings
- set_settings
- nway_reset
- get_msglevel
- set_msglevel
- get_link
- get_strings
- get_ethtool_stats
- get_sset_count
About other function, the device does not support.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
---
drivers/net/sh_eth.c | 190 ++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 176 insertions(+), 14 deletions(-)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index 819c175..10493e8 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -32,6 +32,7 @@
#include <linux/io.h>
#include <linux/pm_runtime.h>
#include <linux/slab.h>
+#include <linux/ethtool.h>
#include <asm/cacheflush.h>
#include "sh_eth.h"
@@ -573,7 +574,7 @@ static int sh_eth_ring_init(struct net_device *ndev)
}
/* Allocate all Rx descriptors. */
- rx_ringsize = sizeof(struct sh_eth_rxdesc) * RX_RING_SIZE;
+ rx_ringsize = sizeof(struct sh_eth_rxdesc) *RX_RING_SIZE;
mdp->rx_ring = dma_alloc_coherent(NULL, rx_ringsize, &mdp->rx_desc_dma,
GFP_KERNEL);
@@ -587,7 +588,7 @@ static int sh_eth_ring_init(struct net_device *ndev)
mdp->dirty_rx = 0;
/* Allocate all Tx descriptors. */
- tx_ringsize = sizeof(struct sh_eth_txdesc) * TX_RING_SIZE;
+ tx_ringsize = sizeof(struct sh_eth_txdesc) *TX_RING_SIZE;
mdp->tx_ring = dma_alloc_coherent(NULL, tx_ringsize, &mdp->tx_desc_dma,
GFP_KERNEL);
if (!mdp->tx_ring) {
@@ -817,6 +818,19 @@ static int sh_eth_rx(struct net_device *ndev)
return 0;
}
+static void sh_eth_linkdown(u32 ioaddr)
+{
+ /* Link Down : disable tx and rx */
+ ctrl_outl(ctrl_inl(ioaddr + ECMR) &
+ ~(ECMR_RE | ECMR_TE), ioaddr + ECMR);
+}
+
+static void sh_eth_linkup(u32 ioaddr)
+{
+ ctrl_outl(ctrl_inl(ioaddr + ECMR) |
+ (ECMR_RE | ECMR_TE), ioaddr + ECMR);
+}
+
/* error control function */
static void sh_eth_error(struct net_device *ndev, int intr_status)
{
@@ -843,11 +857,9 @@ static void sh_eth_error(struct net_device *ndev, int intr_status)
if (mdp->ether_link_active_low)
link_stat = ~link_stat;
}
- if (!(link_stat & PHY_ST_LINK)) {
- /* Link Down : disable tx and rx */
- writel(readl(ioaddr + ECMR) &
- ~(ECMR_RE | ECMR_TE), ioaddr + ECMR);
- } else {
+ if (!(link_stat & PHY_ST_LINK))
+ sh_eth_linkdown(ioaddr);
+ else {
/* Link Up */
writel(readl(ioaddr + EESIPR) &
~DMAC_M_ECI, ioaddr + EESIPR);
@@ -857,8 +869,7 @@ static void sh_eth_error(struct net_device *ndev, int intr_status)
writel(readl(ioaddr + EESIPR) |
DMAC_M_ECI, ioaddr + EESIPR);
/* enable tx and rx */
- writel(readl(ioaddr + ECMR) |
- (ECMR_RE | ECMR_TE), ioaddr + ECMR);
+ sh_eth_linkup(ioaddr);
}
}
}
@@ -1063,6 +1074,154 @@ static int sh_eth_phy_start(struct net_device *ndev)
return 0;
}
+static void sh_eth_get_drvinfo(struct net_device *ndev,
+ struct ethtool_drvinfo *info)
+{
+ strncpy(info->driver, "sh_eth", sizeof(info->driver) - 1);
+ strcpy(info->version, "N/A");
+ strcpy(info->fw_version, "N/A");
+ strlcpy(info->bus_info, dev_name(ndev->dev.parent),
+ sizeof(info->bus_info));
+}
+
+static int sh_eth_get_settings(struct net_device *ndev,
+ struct ethtool_cmd *ecmd)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(&mdp->lock, flags);
+ ret = phy_ethtool_gset(mdp->phydev, ecmd);
+ spin_unlock_irqrestore(&mdp->lock, flags);
+
+ return ret;
+}
+
+static int sh_eth_set_settings(struct net_device *ndev,
+ struct ethtool_cmd *ecmd)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ unsigned long flags;
+ int ret;
+ u32 ioaddr = ndev->base_addr;
+
+ spin_lock_irqsave(&mdp->lock, flags);
+
+ /* disable tx and rx */
+ sh_eth_linkdown(ioaddr);
+
+ ret = phy_ethtool_sset(mdp->phydev, ecmd);
+ if (ret)
+ goto error_exit;
+
+ if (ecmd->duplex == DUPLEX_FULL)
+ mdp->duplex = 1;
+ else
+ mdp->duplex = 0;
+
+ if (mdp->cd->set_duplex)
+ mdp->cd->set_duplex(ndev);
+
+error_exit:
+ mdelay(100);
+
+ /* enable tx and rx */
+ sh_eth_linkup(ioaddr);
+
+ spin_unlock_irqrestore(&mdp->lock, flags);
+
+ return ret;
+}
+
+static int sh_eth_nway_reset(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(&mdp->lock, flags);
+ ret = phy_start_aneg(mdp->phydev);
+ spin_unlock_irqrestore(&mdp->lock, flags);
+
+ return ret;
+}
+
+static u32 sh_eth_get_msglevel(struct net_device *ndev)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ return mdp->msg_enable;
+}
+
+static void sh_eth_set_msglevel(struct net_device *ndev, u32 value)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ mdp->msg_enable = value;
+}
+
+static const char sh_eth_gstrings_stats[][ETH_GSTRING_LEN] = {
+ "rx_packets", "tx_packets", "rx_bytes", "tx_bytes", "rx_errors",
+ "tx_errors", "rx_dropped", "tx_dropped", "multicast", "collisions",
+ "rx_length_errors", "rx_over_errors", "rx_crc_errors",
+ "rx_frame_errors", "rx_fifo_errors", "rx_missed_errors",
+ "tx_aborted_errors", "tx_carrier_errors", "tx_fifo_errors",
+ "tx_heartbeat_errors", "tx_window_errors",
+ /* device-specific stats */
+ "rx_current", "tx_current",
+ "rx_dirty", "tx_dirty",
+};
+#define SH_ETH_NET_STATS_LEN 21
+#define SH_ETH_STATS_LEN ARRAY_SIZE(sh_eth_gstrings_stats)
+
+static int sh_eth_get_sset_count(struct net_device *netdev, int sset)
+{
+ switch (sset) {
+ case ETH_SS_STATS:
+ return SH_ETH_STATS_LEN;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static void sh_eth_get_ethtool_stats(struct net_device *ndev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ struct sh_eth_private *mdp = netdev_priv(ndev);
+ int i;
+
+ for (i = 0; i < SH_ETH_NET_STATS_LEN; i++)
+ data[i] = ((unsigned long *)&ndev->stats)[i];
+
+ /* device-specific stats */
+ data[i++] = mdp->cur_rx;
+ data[i++] = mdp->cur_tx;
+ data[i++] = mdp->dirty_rx;
+ data[i++] = mdp->dirty_tx;
+}
+
+static void sh_eth_get_strings(struct net_device *ndev, u32 stringset, u8 *data)
+{
+ switch (stringset) {
+ case ETH_SS_STATS:
+ memcpy(data, *sh_eth_gstrings_stats,
+ sizeof(sh_eth_gstrings_stats));
+ break;
+ }
+}
+
+static struct ethtool_ops sh_eth_ethtool_ops = {
+ .get_drvinfo = sh_eth_get_drvinfo,
+ .get_settings = sh_eth_get_settings,
+ .set_settings = sh_eth_set_settings,
+ .nway_reset = sh_eth_nway_reset,
+ .get_msglevel = sh_eth_get_msglevel,
+ .set_msglevel = sh_eth_set_msglevel,
+ .get_link = ethtool_op_get_link,
+ .get_strings = sh_eth_get_strings,
+ .get_ethtool_stats = sh_eth_get_ethtool_stats,
+ .get_sset_count = sh_eth_get_sset_count,
+};
+
/* network device open function */
static int sh_eth_open(struct net_device *ndev)
{
@@ -1073,8 +1232,8 @@ static int sh_eth_open(struct net_device *ndev)
ret = request_irq(ndev->irq, sh_eth_interrupt,
#if defined(CONFIG_CPU_SUBTYPE_SH7763) || \
- defined(CONFIG_CPU_SUBTYPE_SH7764) || \
- defined(CONFIG_CPU_SUBTYPE_SH7757)
+ defined(CONFIG_CPU_SUBTYPE_SH7764) || \
+ defined(CONFIG_CPU_SUBTYPE_SH7757)
IRQF_SHARED,
#else
0,
@@ -1232,11 +1391,11 @@ static int sh_eth_close(struct net_device *ndev)
sh_eth_ring_free(ndev);
/* free DMA buffer */
- ringsize = sizeof(struct sh_eth_rxdesc) * RX_RING_SIZE;
+ ringsize = sizeof(struct sh_eth_rxdesc) *RX_RING_SIZE;
dma_free_coherent(NULL, ringsize, mdp->rx_ring, mdp->rx_desc_dma);
/* free DMA buffer */
- ringsize = sizeof(struct sh_eth_txdesc) * TX_RING_SIZE;
+ ringsize = sizeof(struct sh_eth_txdesc) *TX_RING_SIZE;
dma_free_coherent(NULL, ringsize, mdp->tx_ring, mdp->tx_desc_dma);
pm_runtime_put_sync(&mdp->pdev->dev);
@@ -1497,8 +1656,11 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
/* set function */
ndev->netdev_ops = &sh_eth_netdev_ops;
+ SET_ETHTOOL_OPS(ndev, &sh_eth_ethtool_ops);
ndev->watchdog_timeo = TX_TIMEOUT;
+ /* debug message level */
+ mdp->msg_enable = (1 << 3) - 1;
mdp->post_rx = POST_RX >> (devno << 1);
mdp->post_fw = POST_FW >> (devno << 1);
@@ -1572,7 +1734,7 @@ static int sh_eth_runtime_nop(struct device *dev)
return 0;
}
-static struct dev_pm_ops sh_eth_dev_pm_ops = {
+static const struct dev_pm_ops sh_eth_dev_pm_ops = {
.runtime_suspend = sh_eth_runtime_nop,
.runtime_resume = sh_eth_runtime_nop,
};
--
1.7.2.3
^ permalink raw reply related
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