Re: fix-slab-corruption-running-ip6sic.patch
On Thu, Apr 26, 2007 at 02:11:33PM -0700, Andrew Morton wrote: > > I have this floating about in my tree. Is it of any interest? > > > > From: Jarek Poplawski <[EMAIL PROTECTED]> I know you've more interesting problems, but I'd like to straighten something: this is not my patch! Please, change this to: From: Eric Sesterhenn <[EMAIL PROTECTED]> > > * Herbert Xu ([EMAIL PROTECTED]) wrote: > > Jarek Poplawski <[EMAIL PROTECTED]> wrote: > > > > > > My proposal is: maybe Eric could change this in > > > xfrm6_tunnel_rcv() from xfrm6_tunnel.c e.g. like this: > > > > > > return xfrm6_rcv_spi(skb, spi) > 0 ? : 0; > > > > > > and, if no errors in testing, he could resubmit this patch? > > > > I agree, this is the right fix. > > The fix proposed by Jarek indeed fixes the problem, tested on two boxes, > with an -rc5 kernel and a yesterdays git > > Acked-by: Eric Sesterhenn <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > --- Thanks, Jarek P. PS: And this one time it's not a joke... I really mean it. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexcepted latency (order of 100-200 ms) with TCP (packet receive)
On Thu, 26 Apr 2007, Ilpo Järvinen wrote: > On Thu, 26 Apr 2007, Chuck Ebbert wrote: > > > Ilpo Järvinen wrote: > > > ...I'm unsure how to continue the investigation from this point onward > > > and asking for ideas/suggestions or how to rule out more possibilities... > > > Or is there some knob which I don't know of that should be toggled or > > > something, is 2.6 network stack expected to behave this way? > > > > > > > Try a different network adapter. > > Hmm, I thought I had already done this but I just noticed that it is so > that the adapter was still the same as the other host has two adapter (now > that I look again). I'll give it a try tomorrow to see if using the > another adapter makes any difference. > > > Try turning off hardware TSO offload: > > ethtool -K ethX tso off > > # ethtool -K eth0 tso off > Cannot set device tcp segmentation offload settings: Operation not > supported Could the delays be caused by Ethernet PAUSE frames (which might not be rquired at the slower 10FD but might at 100)? TX and RX pause control settings (check with "ethtool -a") might be different between the 2.4 and 2.6 kernels. Also check things like net.core.netdev_max_backlog and ifconfig txqueuelen settings. And check "ethtool -S", "netstat -s", and ifconfig error counters. -Bill - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] [IPV4] SNMP: Display new statistics at /proc/net/snmp
On Tue, 17 Apr 2007 20:14:36 +0900 Mitsuru Chinen <[EMAIL PROTECTED]> wrote: > This displays the statistics specified in the updated IP-MIB RFC > (RFC4293) at /proc/net/snmp. As new statistics are placed as the > last elements, this change wouldn't affect netstat, net-snmp, etc. I'm sorry. I found adding new entries to /proc/net/snmp affects net-snmp. I'm ashamed of my inadequate investigation. However the other patches to support new statistics will be useful. Could you pick up 1st to 5th patches? Thank you, Mitsuru Chinen <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
netdev file size restrictions??? Was: Re: [PATCH 04/14] AF_RXRPC: Provide secure RxRPC sockets for ...
On Thu, 26 Apr 2007 20:54:36 +0100, David Howells wrote: > Provide AF_RXRPC sockets that can be used to talk to AFS servers, or serve > answers to AFS clients. KerberosIV security is fully supported. The patches > and some example test programs can be found in: > > http://people.redhat.com/~dhowells/rxrpc/ > > This will eventually replace the old implementation of kernel-only RxRPC > currently resident in net/rxrpc/. > > The following documentation is from Documentation/networking/rxrpc.txt: > > == > RxRPC NETWORK PROTOCOL > == ... Did the file size restrictions for netdev somehow get lifted? I just received this e-mail that my mail client says is 339.3KB (and a few others that are over 100KB (some well over)). -Bill - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netdev file size restrictions??? Was: Re: [PATCH 04/14] AF_RXRPC: Provide secure RxRPC sockets for ...
From: Bill Fink <[EMAIL PROTECTED]> Date: Fri, 27 Apr 2007 03:52:20 -0400 > Did the file size restrictions for netdev somehow get lifted? > I just received this e-mail that my mail client says is 339.3KB > (and a few others that are over 100KB (some well over)). Yes, I bumped it up slightly on a few lists where I've been seeing large patches rejected that were rather legitimate postings. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] SMC on pxa3xx (was: pxa3xx base patch [5/5] - net)
This patch is to support network adapter on pxa3xx-based boards Signed-off-by: dmitry pervushin <[EMAIL PROTECTED]> KernelVersion: 2.6.21 Index: linux-2.6.21/drivers/net/smc91x.h === --- linux-2.6.21.orig/drivers/net/smc91x.h +++ linux-2.6.21/drivers/net/smc91x.h @@ -175,6 +175,20 @@ SMC_outw(u16 val, void __iomem *ioaddr, } } +#elif defined(CONFIG_PXA3xx) +#define SMC_CAN_USE_8BIT 1 +#define SMC_CAN_USE_16BIT 1 +#define SMC_CAN_USE_32BIT 0 +#define SMC_IO_SHIFT 0 +#define SMC_NOWAIT 1 +#define SMC_USE_PXA_DMA1 +#define SMC_inb(a, r) readb((a) + (r)) +#define SMC_outb(v, a, r) writeb(v, (a) + (r)) +#define SMC_inw(a, r) readw((a) + (r)) +#define SMC_outw(v, a, r) writew(v, (a) + (r)) +#define SMC_insw(a, r, p, l) insw((a) + (r), p, l) +#define SMC_outsw(a, r, p, l) outsw((a) + (r), p, l) + #elif defined(CONFIG_ARCH_OMAP) /* We can only do 16-bit reads and writes in the static memory space. */ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IPV6 source routing patch is still broken?
From: Chuck Ebbert <[EMAIL PROTECTED]> Date: Thu, 26 Apr 2007 18:57:06 -0400 > David Miller wrote: > >> + case IPV6_SRCRT_TYPE_2: > >> + if (accept_source_route >= 0) > >> + break; > >> + kfree_skb(skb); > >> + return -1; > >> + case IPV6_SRCRT_TYPE_0: > >> + if (accept_source_route > 0) > >> + break; > >> + kfree_skb(skb); > >> + return -1; > > > > Yes, that looks like it matches the sysctl documentation more closely: > > > > accept_source_route - INTEGER > > Accept source routing (routing extension header). > > > > > 0: Accept routing header. > > = 0: Accept only routing header type 2. > > < 0: Do not accept routing header. > > > > Type 2 packets should get through as long as the value of the sysctl > > is not negative. > > It was Sergey Vlasov who first found this. I had tried to find his original > message but I was searching the wrong place. Actually, earlier in the function accept_source_route is verified, and if it is negative ipv6_rthdr_rcv() returns immediately. This is done by the initial code which reads: if (accept_source_route < 0 || ((idev = in6_dev_get(skb->dev)) == NULL)) { kfree_skb(skb); return -1; } if (idev->cnf.accept_source_route < 0) { in6_dev_put(idev); kfree_skb(skb); return -1; } then the function proceeds to use the largest of 'accept_source_route' and 'idev->cnf.accept_source_route' for further checks. So when we get to the switch statement in question, we know it will be a positive value, so none of the purely negative cases need to be considered. So with Yoshifuji-sans small fix, the switch statement covers all the cases properly: switch (hdr->type) { #ifdef CONFIG_IPV6_MIP6 case IPV6_SRCRT_TYPE_2: break; #endif case IPV6_SRCRT_TYPE_0: if (accept_source_route > 0) break; kfree_skb(skb); return -1; default: IP6_INC_STATS_BH(ip6_dst_idev(skb->dst), IPSTATS_MIB_INHDRERRORS); icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, (&hdr->type) - skb->nh.raw); return -1; } - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SMC on pxa3xx (was: pxa3xx base patch [5/5] - net)
On Fri, Apr 27, 2007 at 12:52:08PM +0400, dmitry pervushin wrote: > +#elif defined(CONFIG_PXA3xx) > +#define SMC_CAN_USE_8BIT 1 > +#define SMC_CAN_USE_16BIT1 > +#define SMC_CAN_USE_32BIT0 > +#define SMC_IO_SHIFT 0 > +#define SMC_NOWAIT 1 > +#define SMC_USE_PXA_DMA 1 > +#define SMC_inb(a, r)readb((a) + (r)) > +#define SMC_outb(v, a, r)writeb(v, (a) + (r)) > +#define SMC_inw(a, r)readw((a) + (r)) > +#define SMC_outw(v, a, r)writew(v, (a) + (r)) > +#define SMC_insw(a, r, p, l) insw((a) + (r), p, l) > +#define SMC_outsw(a, r, p, l)outsw((a) + (r), p, l) This is bogus, please don't apply. The fact that the SMC might be hooked up in a certain way on one certain PXA3xx board doesn't mean that it will be hooked up in that way on every PXA3xx board. Everything I've seen of the PXA3xx patch set so far is a disaster. MontaVista is flooding every corner of the internet with these crap patches. This idiocy has got to stop. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IPV6 source routing patch is still broken?
In article <[EMAIL PROTECTED]> (at Fri, 27 Apr 2007 02:08:05 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > then the function proceeds to use the largest of > 'accept_source_route' and 'idev->cnf.accept_source_route' > for further checks. Smallest: if (accept_source_route > idev->cnf.accept_source_route) accept_source_route = idev->cnf.accept_source_route; --yoshufji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IPV6 source routing patch is still broken?
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> Date: Fri, 27 Apr 2007 18:36:35 +0900 (JST) > In article <[EMAIL PROTECTED]> (at Fri, 27 Apr 2007 02:08:05 -0700 (PDT)), > David Miller <[EMAIL PROTECTED]> says: > > > then the function proceeds to use the largest of > > 'accept_source_route' and 'idev->cnf.accept_source_route' > > for further checks. > > Smallest: > if (accept_source_route > idev->cnf.accept_source_route) > accept_source_route = idev->cnf.accept_source_route; Correct, my mistake. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[TCP]: Update references in two old comments
[TCP]: Update references in two old comments This updates references to drafts in comments which must be about 10 years old. Internet draft draft-ietf-tcpimpl-prob-03.txt expired in 1998 and was replaced by RFC 2525 in March 1999. Section 3.10 of the draft maps almost identically into section 2.17 of RFC 2525: both are entitled "Failure to RST on close with data pending", the differences in text body amount to a typo and minor sentence change. Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]> --- net/ipv4/tcp.c| 14 ++ net/ipv4/tcp_output.c |2 +- 2 files changed, 7 insertions(+), 9 deletions(-) --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -1573,14 +1573,12 @@ void tcp_close(struct sock *sk, long tim sk_stream_mem_reclaim(sk); - /* As outlined in draft-ietf-tcpimpl-prob-03.txt, section -* 3.10, we send a RST here because data was lost. To -* witness the awful effects of the old behavior of always -* doing a FIN, run an older 2.1.x kernel or 2.0.x, start -* a bulk GET in an FTP client, suspend the process, wait -* for the client to advertise a zero window, then kill -9 -* the FTP client, wheee... Note: timeout is always zero -* in such a case. + /* As outlined in RFC 2525, section 2.17, we send a RST here because +* data was lost. To witness the awful effects of the old behavior of +* always doing a FIN, run an older 2.1.x kernel or 2.0.x, start a bulk +* GET in an FTP client, suspend the process, wait for the client to +* advertise a zero window, then kill -9 the FTP client, wheee... +* Note: timeout is always zero in such a case. */ if (data_was_unread) { /* Unread data was tossed, zap the connection. */ --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -2035,7 +2035,7 @@ void tcp_send_fin(struct sock *sk) /* We get here when a process closes a file descriptor (either due to * an explicit close() or as a byproduct of exit()'ing) and there * was unread data in the receive queue. This behavior is recommended - * by draft-ietf-tcpimpl-prob-03.txt section 3.10. -DaveM + * by RFC 2525, section 2.17. -DaveM */ void tcp_send_active_reset(struct sock *sk, gfp_t priority) { - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] smc911x: fix compilation breakage wjen debug is on
Hello Jeff, the patch below fixes compilation breakage of smc911x driver when ENABLE_SMC_DEBUG_PKTS equals to 1. smc911x.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Signed-off-by: Vitaly Wool <[EMAIL PROTECTED]> Index: linux-2.6/drivers/net/smc911x.c === --- linux-2.6.orig/drivers/net/smc911x.c +++ linux-2.6/drivers/net/smc911x.c @@ -499,7 +499,7 @@ static inline void smc911x_rcv(struct n SMC_SET_RX_CFG(RX_CFG_RX_END_ALGN4_ | ((2<<8) & RX_CFG_RXDOFF_)); SMC_PULL_DATA(data, pkt_len+2+3); - DBG(SMC_DEBUG_PKTS, "%s: Received packet\n", dev->name,); + DBG(SMC_DEBUG_PKTS, "%s: Received packet\n", dev->name); PRINT_PKT(data, ((pkt_len - 4) <= 64) ? pkt_len - 4 : 64); dev->last_rx = jiffies; skb->dev = dev; - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fix smc911x compilation breakage
Hi Jeff, currently (with 2.6.21) compilation of smc911x driver fails in the following way: CC drivers/net/smc911x.o /sandbox/vital/opensource/linux-2.6/drivers/net/smc911x.c: In function `smc911x_probe': /sandbox/vital/opensource/linux-2.6/drivers/net/smc911x.c:2125: warning: implicit declaration of function `set_irq_type' /sandbox/vital/opensource/linux-2.6/drivers/net/smc911x.c:2125: error: `IRQ_TYPE_EDGE_FALLING' undeclared (first use in this function) /sandbox/vital/opensource/linux-2.6/drivers/net/smc911x.c:2125: error: (Each undeclared identifier is reported only once /sandbox/vital/opensource/linux-2.6/drivers/net/smc911x.c:2125: error: for each function it appears in.) make[3]: *** [drivers/net/smc911x.o] Error 1 make[2]: *** [drivers/net] Error 2 make[1]: *** [drivers] Error 2 make: *** [zImage] Error 2 The patch inlined below fixes the problem. smc911x.c |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Signed-off-by: Vitaly Wool <[EMAIL PROTECTED]> Index: linux-2.6/drivers/net/smc911x.c === --- linux-2.6.orig/drivers/net/smc911x.c +++ linux-2.6/drivers/net/smc911x.c @@ -75,9 +75,9 @@ static const char version[] = #include #include #include +#include #include -#include #include "smc911x.h" - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Fwd: [PATCH] [TIPC]: Enhancements to msg_set_bits() routine]
Hi Jon, Jon Paul Maloy schrieb: > Ingo Oeser wrote: > > static inlinevoid msg_set_bits(struct tipc_msg *m, u32 w, > > u32 pos, __be32 mask, __be32 val) > > > > > > Care to resubmit? > I don't mind at all, but I would first like to understand better > what this means. > If I understand it correctly __be32 literally means "big-endian > 32-bit integer", but the way it is used doesn't seem to imply this, > since both input and output to htonl() often is of that type. Yes, you are right! I mixed up htonl and ntohl :-) Sorry for the confusion! Best Regards Ingo Oeser - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] AF_RXRPC socket family and AFS rewrite [net-2.6]
David Miller <[EMAIL PROTECTED]> wrote: > Ok, I applied it all and added a compiler warning fix for 64-bit > at the end. What compiler and arch is that with? Acked-By: David Howells <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Generic HDLC sparse annotations
Sparse annotations, including two minor bugfixes. Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]> diff --git a/drivers/net/wan/hdlc_cisco.c b/drivers/net/wan/hdlc_cisco.c index c9664fd..a7a12d6 100644 --- a/drivers/net/wan/hdlc_cisco.c +++ b/drivers/net/wan/hdlc_cisco.c @@ -37,16 +37,16 @@ struct hdlc_header { u8 address; u8 control; - u16 protocol; + __be16 protocol; }__attribute__ ((packed)); struct cisco_packet { - u32 type; /* code */ - u32 par1; - u32 par2; - u16 rel;/* reliability */ - u32 time; + __be32 type;/* code */ + __be32 par1; + __be32 par2; + __be16 rel; /* reliability */ + __be32 time; }__attribute__ ((packed)); #defineCISCO_PACKET_LEN18 #defineCISCO_BIG_PACKET_LEN20 @@ -97,7 +97,7 @@ static int cisco_hard_header(struct sk_buff *skb, struct net_device *dev, static void cisco_keepalive_send(struct net_device *dev, u32 type, -u32 par1, u32 par2) +__be32 par1, __be32 par2) { struct sk_buff *skb; struct cisco_packet *data; @@ -115,9 +115,9 @@ static void cisco_keepalive_send(struct net_device *dev, u32 type, data = (struct cisco_packet*)(skb->data + 4); data->type = htonl(type); - data->par1 = htonl(par1); - data->par2 = htonl(par2); - data->rel = 0x; + data->par1 = par1; + data->par2 = par2; + data->rel = __constant_htons(0x); /* we will need do_div here if 1000 % HZ != 0 */ data->time = htonl((jiffies - INITIAL_JIFFIES) * (1000 / HZ)); @@ -193,7 +193,7 @@ static int cisco_rx(struct sk_buff *skb) case CISCO_ADDR_REQ: /* Stolen from syncppp.c :-) */ in_dev = dev->ip_ptr; addr = 0; - mask = ~0; /* is the mask correct? */ + mask = __constant_htonl(~0); /* is the mask correct? */ if (in_dev != NULL) { struct in_ifaddr **ifap = &in_dev->ifa_list; @@ -245,7 +245,7 @@ static int cisco_rx(struct sk_buff *skb) } /* switch(protocol) */ printk(KERN_INFO "%s: Unsupported protocol %x\n", dev->name, - data->protocol); + ntohs(data->protocol)); dev_kfree_skb_any(skb); return NET_RX_DROP; @@ -270,8 +270,9 @@ static void cisco_timer(unsigned long arg) netif_dormant_on(dev); } - cisco_keepalive_send(dev, CISCO_KEEPALIVE_REQ, ++state(hdlc)->txseq, -state(hdlc)->rxseq); + cisco_keepalive_send(dev, CISCO_KEEPALIVE_REQ, +htonl(++state(hdlc)->txseq), +htonl(state(hdlc)->rxseq)); state(hdlc)->request_sent = 1; state(hdlc)->timer.expires = jiffies + state(hdlc)->settings.interval * HZ; diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c index c6c3c75..24fe2d3 100644 --- a/drivers/net/wan/hdlc_fr.c +++ b/drivers/net/wan/hdlc_fr.c @@ -288,31 +288,31 @@ static int fr_hard_header(struct sk_buff **skb_p, u16 dlci) struct sk_buff *skb = *skb_p; switch (skb->protocol) { - case __constant_ntohs(NLPID_CCITT_ANSI_LMI): + case __constant_htons(NLPID_CCITT_ANSI_LMI): head_len = 4; skb_push(skb, head_len); skb->data[3] = NLPID_CCITT_ANSI_LMI; break; - case __constant_ntohs(NLPID_CISCO_LMI): + case __constant_htons(NLPID_CISCO_LMI): head_len = 4; skb_push(skb, head_len); skb->data[3] = NLPID_CISCO_LMI; break; - case __constant_ntohs(ETH_P_IP): + case __constant_htons(ETH_P_IP): head_len = 4; skb_push(skb, head_len); skb->data[3] = NLPID_IP; break; - case __constant_ntohs(ETH_P_IPV6): + case __constant_htons(ETH_P_IPV6): head_len = 4; skb_push(skb, head_len); skb->data[3] = NLPID_IPV6; break; - case __constant_ntohs(ETH_P_802_3): + case __constant_htons(ETH_P_802_3): head_len = 10; if (skb_headroom(skb) < head_len) { struct sk_buff *skb2 = skb_realloc_headroom(skb, @@ -340,7 +340,7 @@ static int fr_hard_header(struct sk_buff **skb_p, u16 dlci) skb->data[5] = FR_PAD; skb->data[6] = FR_PAD; skb->data[7] = FR_PAD; - *(u16*)(skb->data + 8) = skb->protocol; + *(__be16*)(skb->data + 8) = skb->protocol; } dlci_to_q922(skb->data, dlci); @@ -974,8 +974,8 @@ static int fr_rx(struct sk_buff *skb) } else if (skb->l
Re: [PATCH 00/14] AF_RXRPC socket family and AFS rewrite [net-2.6]
David Miller <[EMAIL PROTECTED]> wrote: > I'm fixing this as follows, if you want this debugging code > back do it properly, thanks. Fine by me. Acked-By: David Howells <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] AF_RXRPC socket family and AFS rewrite [net-2.6]
David Miller <[EMAIL PROTECTED]> wrote: > net/rxrpc/ar-input.c:171: warning: passing argument 2 of > $,1rx(B__test_and_set_bit$,1ry(B from incompatible pointer type > net/rxrpc/ar-input.c:180: warning: passing argument 2 of > $,1rx(B__clear_bit$,1ry(B from incompatible pointer type > net/rxrpc/ar-input.c:218: warning: passing argument 2 of > $,1rx(B__clear_bit$,1ry(B from incompatible pointer type Acked-By: David Howells <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 09/11] forcedeth: improve NAPI logic
Ayaz Abdulla wrote: Jeff Garzik wrote: Ayaz Abdulla wrote: I don't see why the NAPI handler needs to process tx packets. The ISR will handle all tx processing. It is a design choice, not a requirement. Moving non-RX interrupt processing to the NAPI handler can help as loads increase. The basic idea is to do as much work as possible in the NAPI handler with NIC interrupts masked. That mitigates global system per-interrupt overhead even more than an only-RX NAPI scheme. Several net drivers do TX completion handling in the NAPI handler. Ok. In that case, the patch needs to be improved. The following needs to be done when NAPI is enabled: - remove the tx handling within the ISRs - mask off the tx interrupts within the ISRs that handle tx processing - re-enable tx interrupts within the NAPI handler - add tx handling within the NAPI handler (this patch covers it) Agreed. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22 5/5] iw_cxgb3: Update required firmware revision to 4.0.0.
On Thu, 2007-04-26 at 20:12 -0700, Roland Dreier wrote: > > Update required firmware revision to 4.0.0. > > Hmm... should we fold this into the earlier patch, which actually > needs this new FW? Or at least merge this patch first? > I separated it only because cxgb3 is maintained by Jeff. Feel free to make it one commit. That is the proper way IMO. But I didn't know what SOP was for changes that hit different maintainers but are prerequisites of each other... > Also, is it cool with everyone to require a new FW, even for users who > might not be using (or even building) the RDMA driver? I'm not sure > what a good solution would be really, so maybe the pain of forcing > everyone to update FW is the least bad thing to do. > - R. I was asked to package the firmware version change along with my rdma changes by Divy since they didn't have any other cxgb3 changes right now. I believe Chelsio wants folks on this new firmware asap. Steve. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][XFRM] export SPD info
Here's the SPD version against net-2.6. cheers, jamal [XFRM] Export SPD info With this patch you can use iproute2 in user space to efficiently see how many policies exist in different directions. Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]> --- commit d3db0b0580d7aa519aabc898656bd5ef0345cf49 tree 14b595f1f616403cdcaf30799dea8b13db765fb0 parent 912a41a4ab935ce8c4308428ec13fc7f8b1f18f4 author Jamal Hadi Salim <[EMAIL PROTECTED]> Fri, 27 Apr 2007 08:05:05 -0400 committer Jamal Hadi Salim <[EMAIL PROTECTED]> Fri, 27 Apr 2007 08:05:05 -0400 include/linux/xfrm.h | 35 ++ include/net/xfrm.h | 13 net/xfrm/xfrm_policy.c | 16 +- net/xfrm/xfrm_user.c | 77 4 files changed, 140 insertions(+), 1 deletions(-) diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h index 9c656a5..a5d53e0 100644 --- a/include/linux/xfrm.h +++ b/include/linux/xfrm.h @@ -185,6 +185,11 @@ enum { #define XFRM_MSG_NEWSADINFO XFRM_MSG_NEWSADINFO XFRM_MSG_GETSADINFO, #define XFRM_MSG_GETSADINFO XFRM_MSG_GETSADINFO + + XFRM_MSG_NEWSPDINFO, +#define XFRM_MSG_NEWSPDINFO XFRM_MSG_NEWSPDINFO + XFRM_MSG_GETSPDINFO, +#define XFRM_MSG_GETSPDINFO XFRM_MSG_GETSPDINFO __XFRM_MSG_MAX }; #define XFRM_MSG_MAX (__XFRM_MSG_MAX - 1) @@ -290,6 +295,36 @@ enum xfrm_sadattr_type_t { #define XFRMA_SAD_MAX (__XFRMA_SAD_MAX - 1) }; +/* SPD Table filter flags */ +enum xfrm_spd_ftype_t { + XFRM_SPD_UNSPEC, + XFRM_SPD_HMASK=1, + XFRM_SPD_HMAX=2, + XFRM_SPD_ICNT=4, + XFRM_SPD_OCNT=8, + XFRM_SPD_FCNT=16, + XFRM_SPD_ISCNT=32, + XFRM_SPD_OSCNT=64, + XFRM_SPD_FSCNT=128, + __XFRM_SPD_MAX + +#define XFRM_SPD_MAX (__XFRM_SPD_MAX - 1) +}; +enum xfrm_spdattr_type_t { + XFRMA_SPD_UNSPEC, + XFRMA_SPDHMASK, + XFRMA_SPDHMAX, + XFRMA_SPDICNT, + XFRMA_SPDOCNT, + XFRMA_SPDFCNT, + XFRMA_SPDISCNT, + XFRMA_SPDOSCNT, + XFRMA_SPDFSCNT, + __XFRMA_SPD_MAX + +#define XFRMA_SPD_MAX (__XFRMA_SPD_MAX - 1) +}; + struct xfrm_usersa_info { struct xfrm_selectorsel; struct xfrm_id id; diff --git a/include/net/xfrm.h b/include/net/xfrm.h index 8287081..9561bf8 100644 --- a/include/net/xfrm.h +++ b/include/net/xfrm.h @@ -423,6 +423,18 @@ struct xfrm_sadinfo u32 sadhmcnt; /* max allowed hash bkts */ u32 sadcnt; /* current running count */ }; + +struct xfrm_spdinfo +{ + u32 incnt; + u32 outcnt; + u32 fwdcnt; + u32 inscnt; + u32 outscnt; + u32 fwdscnt; + u32 spdhcnt; + u32 spdhmcnt; +}; #ifdef CONFIG_AUDITSYSCALL extern void xfrm_audit_log(uid_t auid, u32 secid, int type, int result, struct xfrm_policy *xp, struct xfrm_state *x); @@ -946,6 +958,7 @@ extern struct xfrm_state *xfrm_find_acq_byseq(u32 seq); extern int xfrm_state_delete(struct xfrm_state *x); extern void xfrm_state_flush(u8 proto, struct xfrm_audit *audit_info); extern void xfrm_sad_getinfo(struct xfrm_sadinfo *si); +extern void xfrm_spd_getinfo(struct xfrm_spdinfo *si); extern int xfrm_replay_check(struct xfrm_state *x, __be32 seq); extern void xfrm_replay_advance(struct xfrm_state *x, __be32 seq); extern void xfrm_replay_notify(struct xfrm_state *x, int event); diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c index 7629260..dbf9d96 100644 --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -579,8 +579,22 @@ static inline int xfrm_byidx_should_resize(int total) return 0; } -static DEFINE_MUTEX(hash_resize_mutex); +void xfrm_spd_getinfo(struct xfrm_spdinfo *si) +{ + read_lock_bh(&xfrm_policy_lock); + si->incnt = xfrm_policy_count[XFRM_POLICY_IN]; + si->outcnt = xfrm_policy_count[XFRM_POLICY_OUT]; + si->fwdcnt = xfrm_policy_count[XFRM_POLICY_FWD]; + si->inscnt = xfrm_policy_count[XFRM_POLICY_IN+XFRM_POLICY_MAX]; + si->outscnt = xfrm_policy_count[XFRM_POLICY_OUT+XFRM_POLICY_MAX]; + si->fwdscnt = xfrm_policy_count[XFRM_POLICY_FWD+XFRM_POLICY_MAX]; + si->spdhcnt = xfrm_idx_hmask; + si->spdhmcnt = xfrm_policy_hashmax; + read_unlock_bh(&xfrm_policy_lock); +} +EXPORT_SYMBOL(xfrm_spd_getinfo); +static DEFINE_MUTEX(hash_resize_mutex); static void xfrm_hash_resize(struct work_struct *__unused) { int dir, total; diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index 69110fe..4210d91 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -672,6 +672,81 @@ static struct sk_buff *xfrm_state_netlink(struct sk_buff *in_skb, return skb; } +static int build_spdinfo(struct sk_buff *skb, u32 pid, u32 seq, u32 flags) +{ + struct xfrm_spdinfo si; + struct nlmsghdr *nlh; + u32 *f; + + nlh = nlmsg_put(skb, pid, seq, XFRM_MSG_NEWSPDINFO, sizeof(u32), 0); + if (nlh == NULL) /* shouldnt really happen ...
Re: [PATCH][XFRM] export SPD info
jamal wrote: > +static int build_spdinfo(struct sk_buff *skb, u32 pid, u32 seq, u32 flags) > +{ > + struct xfrm_spdinfo si; > + struct nlmsghdr *nlh; > + u32 *f; > + > + nlh = nlmsg_put(skb, pid, seq, XFRM_MSG_NEWSPDINFO, sizeof(u32), 0); > + if (nlh == NULL) /* shouldnt really happen ... */ > + return -EMSGSIZE; > + > + f = nlmsg_data(nlh); > + *f = flags; > + xfrm_spd_getinfo(&si); > + > + if (flags & XFRM_SPD_HMASK) > + NLA_PUT_U32(skb, XFRMA_SPDHMASK, si.spdhcnt); > + if (flags & XFRM_SPD_HMAX) > + NLA_PUT_U32(skb, XFRMA_SPDHMAX, si.spdhmcnt); > + if (flags & XFRM_SPD_ICNT) > + NLA_PUT_U32(skb, XFRMA_SPDICNT, si.incnt); > + if (flags & XFRM_SPD_OCNT) > + NLA_PUT_U32(skb, XFRMA_SPDOCNT, si.outcnt); > + if (flags & XFRM_SPD_FCNT) > + NLA_PUT_U32(skb, XFRMA_SPDFCNT, si.fwdcnt); > + if (flags & XFRM_SPD_ISCNT) > + NLA_PUT_U32(skb, XFRMA_SPDISCNT, si.inscnt); > + if (flags & XFRM_SPD_OSCNT) > + NLA_PUT_U32(skb, XFRMA_SPDOSCNT, si.inscnt); > + if (flags & XFRM_SPD_FSCNT) > + NLA_PUT_U32(skb, XFRMA_SPDFSCNT, si.inscnt); It it really worth the extra code for dumping them conditionally? The attributes are neither large nor will they be sent very often. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][XFRM] export SAD info
On Thu, 2007-26-04 at 14:18 -0700, David Miller wrote: > I wouldn't mind if it actually helped anything. > > The SMP cache line transactions are more expensive than the > execution of the code blocks they are protecting. rwlock's > rarely help, and when they do (the execution path is more > expensive than the SMP atomic operations) then you're holding > the lock too long :-) > Ok ;-> So if i was to make any change, it would be for consistency with SPD. If this is sufficiently compelling i will send a patch. > I would prefer a dynamic algorithm that reacts to system memory > pressure and yet-another-knob that people will get wrong and > there is no sane default for. > This would certainly be a better approach if doable. > I plan to do away with all the GC threshold madness in the > routing cache, for example, and just let the MM layer call > back into us when there is memory pressure to trigger GC. > > See set_shrinker() and friends. The MM calls into these > handlers in response to memory pressure. There is no > reason the networking can't hook into this and do things > properly instead of the ad-hoc manner we currently use. Scanning the kernel ... I wasnt aware of this, neat; not many areas in the kernel seem to use it. I find this stuff interesting, so i may get too verbose ;-> One approach i tried was to write an oom_handler - but it seemed to get invoked a little too late, i.e when shit has already hit the fan. If only i could get notified just before swap kicks in or just when some preconfigured (by me) memmory threshold is hit This may do it? I will experiment. Actually for it to work well, I will need to know when the memory threshold is crossed as it goes down and when it is going up as more memory gets freed. I can see the shrinker working well with dynamically createable entries (route cache, arp cache, contrack etc); shrinking a SAD, SPD, FIB etc that was created by some user space app without user space consent or at least notification may be unacceptable (imagine Quagga/BGP adding FIB entries and the kernel deciding its gonna run out of mem and starting to delete entries; worse deleting SAD entries may be a security risk etc etc). My problem is more related to these sorts of user controlled tables. One approach that may work to address the above is to send a signal to user space when the low mem threshold is approaching.. User space then uses that info to slow down its abuse of memory. I think that signaling maybe achievable by a genlmsg being sent to a multicast group which a user space app will have to subscribe to. Another approach is to use the shrinker callback to set a lowmem condition to start rejecting any new table additions. A timer to retry would take it back; a callback from the VM to say "you can go ahead and alloc more now" would be better of course - i couldnt see this anywhere in the VM code, but it is one of those subsystem i dont pay attention to, it may be there. Thoughts? ;-> cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] AF_RXRPC socket family and AFS rewrite [net-2.6]
David Miller <[EMAIL PROTECTED]> wrote: > Here is how I'm fixing this for now to get the tree into > a buildable state. Okay, that looks mostly reasonable, but it needs to go a little bit further. > If you have a better fix, please send it to me relative > to what's in net-2.6, thanks. I'm about to dispatch three patches to you: (1) Extend your fixes to the VL update manager. The state changing to AFS_VL_VALID isn't the only place a wakeup is missing. (2) I compiled against all of these arches in addition to x86_64: i386, frv, frv (nommu), pa-risc, s390, powerpc (16 & 32), sparc64, mips, alpha, ia64. And came up with a few more problems, notably wrt to compiling the modules in. Due to general arch problems, I tried and failed to build for: m68k, cris, arm, h8300, sh, v850, sparc. Due to lack of a suitable compiler, I couldn't build for: sh64, xtensa (3) I also came across some other networking compilation bugs. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][XFRM] export SPD info
On Fri, 2007-27-04 at 15:55 +0200, Patrick McHardy wrote: > > It it really worth the extra code for dumping them conditionally? > The attributes are neither large nor will they be sent very often. > That thought did cross my mind when i was coding this;-> I hate the way netlink filters are done in user space with iproute2 - dumping 50 objects just so i can get to one. So i used that as my guiding principle; i have no qualms with the few extra lines. Actually, I was hoping it would provide motivation for someone else to do a better filtering scheme (which sits in the kernel). cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] AFS: Fix VLocation record update wakeup
Fix the wakeup transitions after a VLocation record update completes one way or another. This builds on Dave Miller's partial fix. Also move wakeups outside the spinlocked sections. Signed-Off-By: David Howells <[EMAIL PROTECTED]> --- fs/afs/vlocation.c | 17 - 1 files changed, 8 insertions(+), 9 deletions(-) diff --git a/fs/afs/vlocation.c b/fs/afs/vlocation.c index 74cce17..6c8e95a 100644 --- a/fs/afs/vlocation.c +++ b/fs/afs/vlocation.c @@ -416,8 +416,8 @@ fill_in_record: goto error_abandon; spin_lock(&vl->lock); vl->state = AFS_VL_VALID; - wake_up(&vl->waitq); spin_unlock(&vl->lock); + wake_up(&vl->waitq); /* schedule for regular updates */ afs_vlocation_queue_for_updates(vl); @@ -442,7 +442,7 @@ found_in_memory: _debug("invalid [state %d]", state); - if ((state == AFS_VL_NEW || state == AFS_VL_NO_VOLUME)) { + if (state == AFS_VL_NEW || state == AFS_VL_NO_VOLUME) { vl->state = AFS_VL_CREATING; spin_unlock(&vl->lock); goto fill_in_record; @@ -453,11 +453,10 @@ found_in_memory: _debug("wait"); spin_unlock(&vl->lock); - ret = wait_event_interruptible( - vl->waitq, - vl->state == AFS_VL_NEW || - vl->state == AFS_VL_VALID || - vl->state == AFS_VL_NO_VOLUME); + ret = wait_event_interruptible(vl->waitq, + vl->state == AFS_VL_NEW || + vl->state == AFS_VL_VALID || + vl->state == AFS_VL_NO_VOLUME); if (ret < 0) goto error; spin_lock(&vl->lock); @@ -471,8 +470,8 @@ success: error_abandon: spin_lock(&vl->lock); vl->state = AFS_VL_NEW; - wake_up(&vl->waitq); spin_unlock(&vl->lock); + wake_up(&vl->waitq); error: ASSERT(vl != NULL); afs_put_vlocation(vl); @@ -675,7 +674,6 @@ static void afs_vlocation_updater(struct work_struct *work) case 0: afs_vlocation_apply_update(vl, &vldb); vl->state = AFS_VL_VALID; - wake_up(&vl->waitq); break; case -ENOMEDIUM: vl->state = AFS_VL_VOLUME_DELETED; @@ -685,6 +683,7 @@ static void afs_vlocation_updater(struct work_struct *work) break; } spin_unlock(&vl->lock); + wake_up(&vl->waitq); /* and then reschedule */ _debug("reschedule"); - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] NET: Fix networking compilation errors
Fix miscellaneous networking compilation errors. (*) Export ktime_add_ns() for modules. (*) wext_proc_init() should have an ANSI declaration. Signed-Off-By: David Howells <[EMAIL PROTECTED]> --- include/net/wext.h |2 +- kernel/hrtimer.c |2 ++ 2 files changed, 3 insertions(+), 1 deletions(-) diff --git a/include/net/wext.h b/include/net/wext.h index 5574183..c02b8de 100644 --- a/include/net/wext.h +++ b/include/net/wext.h @@ -10,7 +10,7 @@ extern int wext_proc_init(void); extern int wext_handle_ioctl(struct ifreq *ifr, unsigned int cmd, void __user *arg); #else -static inline int wext_proc_init() +static inline int wext_proc_init(void) { return 0; } diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index f5cfde8..1b30331 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -279,6 +279,8 @@ ktime_t ktime_add_ns(const ktime_t kt, u64 nsec) return ktime_add(kt, tmp); } + +EXPORT_SYMBOL_GPL(ktime_add_ns); # endif /* !CONFIG_KTIME_SCALAR */ /* - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] AF_RXRPC/AFS: Arch-specific fixes
Fixes for various arch compilation problems: (*) Missing module exports. (*) Variable name collision when rxkad and af_rxrpc both built in (rxrpc_debug). (*) Large constant representation problem (AFS_UUID_TO_UNIX_TIME). (*) Configuration dependencies. (*) printk() format warnings. Signed-Off-By: David Howells <[EMAIL PROTECTED]> --- arch/ia64/lib/csum_partial_copy.c |2 ++ fs/Kconfig|1 + fs/afs/internal.h |2 +- fs/afs/rxrpc.c|2 +- fs/afs/use-rtnetlink.c|2 +- net/rxrpc/Kconfig |5 + net/rxrpc/rxkad.c |1 + 7 files changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/ia64/lib/csum_partial_copy.c b/arch/ia64/lib/csum_partial_copy.c index 503dfe6..118daf5 100644 --- a/arch/ia64/lib/csum_partial_copy.c +++ b/arch/ia64/lib/csum_partial_copy.c @@ -128,6 +128,8 @@ csum_partial_copy_from_user(const void __user *src, void *dst, return (__force __wsum)result; } +EXPORT_SYMBOL(csum_partial_copy_from_user); + __wsum csum_partial_copy_nocheck(const void *src, void *dst, int len, __wsum sum) { diff --git a/fs/Kconfig b/fs/Kconfig index e33c089..a42f767 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -2020,6 +2020,7 @@ config AFS_FS tristate "Andrew File System support (AFS) (EXPERIMENTAL)" depends on INET && EXPERIMENTAL select AF_RXRPC + select KEYS help If you say Y here, you will get an experimental Andrew File System driver. It currently only supports unsecured read-only AFS access. diff --git a/fs/afs/internal.h b/fs/afs/internal.h index 6dd3197..34665f7 100644 --- a/fs/afs/internal.h +++ b/fs/afs/internal.h @@ -367,7 +367,7 @@ struct afs_uuid { u32 time_low; /* low part of timestamp */ u16 time_mid; /* mid part of timestamp */ u16 time_hi_and_version;/* high part of timestamp and version */ -#define AFS_UUID_TO_UNIX_TIME 0x01b21dd213814000 +#define AFS_UUID_TO_UNIX_TIME 0x01b21dd213814000ULL #define AFS_UUID_TIMEHI_MASK 0x0fff #define AFS_UUID_VERSION_TIME 0x1000 /* time-based UUID */ #define AFS_UUID_VERSION_NAME 0x3000 /* name-based UUID */ diff --git a/fs/afs/rxrpc.c b/fs/afs/rxrpc.c index e7b0473..222c1a3 100644 --- a/fs/afs/rxrpc.c +++ b/fs/afs/rxrpc.c @@ -772,7 +772,7 @@ int afs_extract_data(struct afs_call *call, struct sk_buff *skb, if (call->offset < count) { if (last) { - _leave(" = -EBADMSG [%d < %lu]", call->offset, count); + _leave(" = -EBADMSG [%d < %zu]", call->offset, count); return -EBADMSG; } _leave(" = -EAGAIN"); diff --git a/fs/afs/use-rtnetlink.c b/fs/afs/use-rtnetlink.c index 82f0daa..f8991c7 100644 --- a/fs/afs/use-rtnetlink.c +++ b/fs/afs/use-rtnetlink.c @@ -243,7 +243,7 @@ static int afs_read_rtm(struct afs_rtm_desc *desc) desc->datalen = kernel_recvmsg(desc->nlsock, &msg, iov, 1, desc->datamax, 0); if (desc->datalen < 0) { - _leave(" = %ld [recv]", desc->datalen); + _leave(" = %zd [recv]", desc->datalen); return desc->datalen; } diff --git a/net/rxrpc/Kconfig b/net/rxrpc/Kconfig index d72380e..8750f6d 100644 --- a/net/rxrpc/Kconfig +++ b/net/rxrpc/Kconfig @@ -30,6 +30,11 @@ config AF_RXRPC_DEBUG config RXKAD tristate "RxRPC Kerberos security" depends on AF_RXRPC && KEYS + select CRYPTO + select CRYPTO_MANAGER + select CRYPTO_BLKCIPHER + select CRYPTO_PCBC + select CRYPTO_FCRYPT help Provide kerberos 4 and AFS kaserver security handling for AF_RXRPC through the use of the key retention service. diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 1eaf529..5ec7051 100644 --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c @@ -18,6 +18,7 @@ #include #include #include +#define rxrpc_debug rxkad_debug #include "ar-internal.h" #define RXKAD_VERSION 2 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior
On Thu, 2007-26-04 at 17:57 +0200, Patrick McHardy wrote: > The reason for suggesting to add a TC option was that these patches > move (parts of) the scheduling policy into the driver since it can > start and stop individual subqueues, which in turn cause single > bands of prio not to be dequeued anymore. I see. > To avoid surprising users > by this it should be explicitly enabled. Another reason is that > prio below a classful qdisc should most likely not care about > multiqueue. Heres the way i see it from a user perspective: If a NIC has 3 hardware queues; if that NIC supports strict priority (i.e the prio qdisc) which we already support, there should be no need for the user to really explicitly enable that support. It should be transparent to them - because by configuring a multi queue prio qdisc (3 bands/queues default), they are already doing multiqueues. i.e when i say "tc qdisc add root prio bands 4" on eth0, i am already asking explicitly for 4 strict priority queues on eth0. This in my opinion is separate from enabling the hardware to do 4 queues - which is a separate abstraction layer (and ethtool would do fine there). > We need to change the qdisc layer as well so it knows about the state > of subqueues and can dequeue individual (active) subqueues. The alternative approach is to change the drivers tx state machine netif_XX to act as well on a per hardware queue level. This is what i have in mind working with Ashwin. > The > alternative to adding it to prio (or a completely new qdisc) is to add > something very similar to qdisc_restart and have it pass the subqueue > it wishes to dequeue to ->dequeue, but that would be less flexible > and doesn't seem to offer any advantages. > Another approach is to add between the qdisc restart and driver tx a think layer. You pass the skb->prio and use that as a "classification key" to select the correct hardware ring and dont have to change any qdisc since that layer is between the driver and qdisc. The challenge then becomes how to throttle/unthrottle a software queue. But you leave that brunt work to the driver. > I wouldn't object to putting this into a completely new scheduler > (sch_multiqueue) though since the scheduling policy might be something > completely different than strict priority. I think the wireless work is already in the kernel? The way i see it is the software scheduler should match the hardware scheduler. The majority of these hardware scheduling approaches I have seen match precisely to prio qdisc. i.e there is no need to write a new scheduler ( for that matter touch an existing scheduler that matches). Others I have seen may require some work conserving schedulers that dont have a precise match in Linux today; i think those may have to be written from scratch. > The wireless multiqueue scheduler is pratically identical to this one, > modulo the wireless classifier that should be a seperate module anyway. The wireless folks seemed to have created an extra netdev to provide the hierachy. I think that is a sane interim approach, just a little dirty. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexcepted latency (order of 100-200 ms) with TCP (packet receive)
On Fri, 27 Apr 2007, Bill Fink wrote: > On Thu, 26 Apr 2007, Ilpo Järvinen wrote: > > > On Thu, 26 Apr 2007, Chuck Ebbert wrote: > > > > > Ilpo Järvinen wrote: > > > > ...I'm unsure how to continue the investigation from this point onward > > > > and asking for ideas/suggestions or how to rule out more > > > > possibilities... > > > > Or is there some knob which I don't know of that should be toggled or > > > > something, is 2.6 network stack expected to behave this way? > > > > > > > > > > Try a different network adapter. > > > > Hmm, I thought I had already done this but I just noticed that it is so > > that the adapter was still the same as the other host has two adapter (now > > that I look again). I'll give it a try tomorrow to see if using the > > another adapter makes any difference. ...Much more promising result this time. I noticed that there was another eth hw on mainboard, thus my previous test with different hw was not valid as I assumed "wrong" (didn't even notice the other) one to be eth0: 02:05.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74) 02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (LOM) Ethernet Controller (rev 82) With 3c905 I have the problem, with Intel one it does not show up (tested today). > > > Try turning off hardware TSO offload: > > > ethtool -K ethX tso off > > > > # ethtool -K eth0 tso off > > Cannot set device tcp segmentation offload settings: Operation not > > supported > > Could the delays be caused by Ethernet PAUSE frames (which might not > be rquired at the slower 10FD but might at 100)? TX and RX pause > control settings (check with "ethtool -a") might be different between > the 2.4 and 2.6 kernels. # ethtool -a eth0 Pause parameters for eth0: Cannot get device pause settings: Operation not supported > Also check things like net.core.netdev_max_backlog and ifconfig > txqueuelen settings. # cat /proc/sys/net/core/netdev_max_backlog 1000 ...and... txqueuelen:1000 > And check "ethtool -S", "netstat -s", and ifconfig error counters. Nothigh really alarming was found, errors were all zero, only thing that could be even remotely interesting is this: 5 delayed acks further delayed because of locked socket -- i.
RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior
On Thu, 2007-26-04 at 09:30 -0700, Waskiewicz Jr, Peter P wrote: > > jamal wrote: > > > On Wed, 2007-25-04 at 10:45 -0700, Waskiewicz Jr, Peter P wrote: > We have plans to write a new qdisc that has no priority given to any > skb's being sent to the driver. The reasoning for providing a > multiqueue mode for PRIO is it's a well-known qdisc, so the hope was > people could quickly associate with what's going on. The other > reasoning is we wanted to provide a way to prioritize various network > flows (ala PRIO), and since hardware doesn't currently exist that > provides flow prioritization, we decided to allow it to continue > happening in software. > Reading the above validates my fears that we have some strong differences (refer to my email to Patrick). To be fair to you, i would have to look at your patches. Now i am actually thinking not to look at them at all incase they influence me;-> I think the thing for me to do is provide alternative patches and then we can have smoother discussion. The way i see it is you dont touch any qdisc code. qdiscs that are provided by Linux cover a majority of those provided by hardware (Heck, I have was involved on an ethernet switch chip from your company that provided strict prion multiqueues in hardware and didnt need to touch the qdisc code) > > > > > The driver should be configurable to be X num of queues via > > probably > > > ethtool. It should default to single ring to maintain old behavior. > > > > > > That would probably make sense in either case. > > This shouldn't be something enforced by the OS, rather, an > implementation detail for the driver you write. If you want this to be > something to be configured at run-time, on the fly, then the OS would > need to support it. However, I'd rather see people try the multiqueue > support as-is first to make sure the simple things work as expected, > then we can get into run-time reconfiguration issues (like queue > draining if you shrink available queues, etc.). This will also require > some heavy lifting by the driver to tear down queues, etc. > It could be probably a module insertion/boot time operation. > > > > > Ok, i see; none of those other intel people put you through > > the hazing > > > yet? ;-> This is a netdev matter - so i have taken off lkml > > > > > I appreciate the desire to lower clutter from mailing lists, but I see > 'tc' as a kernel configuration utility, and as such, people should know > what we're doing outside of netdev, IMO. But I'm fine with keeping this > off lkml if that's what people think. > All of netdev has to do with the kernel - that doesnt justify cross posting. People interested in network related subsystem development will subscribe to netdev. Interest in scsi =. subscribe to scsi mailing lists etc. cheers, - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior
jamal wrote: Heres the way i see it from a user perspective: If a NIC has 3 hardware queues; if that NIC supports strict priority (i.e the prio qdisc) which we already support, there should be no need for the user to really explicitly enable that support. It should be transparent to them - because by configuring a multi queue prio qdisc (3 bands/queues default), they are already doing multiqueues. Agreed. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior
> On Thu, 2007-26-04 at 09:30 -0700, Waskiewicz Jr, Peter P wrote: > > > jamal wrote: > > > > On Wed, 2007-25-04 at 10:45 -0700, Waskiewicz Jr, Peter P wrote: > > > We have plans to write a new qdisc that has no priority > given to any > > skb's being sent to the driver. The reasoning for providing a > > multiqueue mode for PRIO is it's a well-known qdisc, so the > hope was > > people could quickly associate with what's going on. The other > > reasoning is we wanted to provide a way to prioritize > various network > > flows (ala PRIO), and since hardware doesn't currently exist that > > provides flow prioritization, we decided to allow it to continue > > happening in software. > > > > Reading the above validates my fears that we have some strong > differences (refer to my email to Patrick). To be fair to > you, i would have to look at your patches. Now i am actually > thinking not to look at them at all incase they influence > me;-> I think the thing for me to do is provide alternative > patches and then we can have smoother discussion. > The way i see it is you dont touch any qdisc code. qdiscs > that are provided by Linux cover a majority of those provided > by hardware (Heck, I have was involved on an ethernet switch > chip from your company that provided strict prion multiqueues > in hardware and didnt need to touch the qdisc code) I agree, that to be fair for discussing the code that you should look at the patches before drawing conclusions. I appreciate the fact you have a different idea for your approach for multiqueue, but without having specific things to discuss in terms of implementation, I'm at a loss for what you want to see done. These patches have been released in the community for a few months now, and the general approach has been accepted for the most part. That being said, my approach was to provide an API for drivers to implement multiqueue support. We originally went with an idea to do the multiqueue support in the driver. However, many questions came up that were answered by pulling things into the qdisc / netdev layer. Specifically, if all the multiqueue code is in the driver, how would you ensure one flow of traffic (say on queue 0) doesn't interfere with another flow (say on queue 1)? If queue 1 on your NIC ran out of descriptors, the driver will set dev->queue_lock to __LINK_STATE_XOFF, which will cause all entry points into the scheduler to stop (i.e. - no more packets going to the NIC). That will also shut down queue 0. As soon as that happens, that is not multiqueue network support. The other question was how to classify traffic. We're proposing to use tc filters to do it, since the user has control over that; having flexibility to meet different network needs is a plus. We had tried doing queue selection in the driver, and it killed performance. Hence why we pulled it into the qdisc layer. > > > > > > > > The driver should be configurable to be X num of queues via > > > probably > > > > ethtool. It should default to single ring to maintain > old behavior. > > > > > > > > > That would probably make sense in either case. > > > > This shouldn't be something enforced by the OS, rather, an > > implementation detail for the driver you write. If you > want this to > > be something to be configured at run-time, on the fly, then the OS > > would need to support it. However, I'd rather see people try the > > multiqueue support as-is first to make sure the simple > things work as > > expected, then we can get into run-time reconfiguration > issues (like > > queue draining if you shrink available queues, etc.). This > will also > > require some heavy lifting by the driver to tear down queues, etc. > > > > It could be probably a module insertion/boot time operation. This is how the API that I am proposing works. > > > > > > > > Ok, i see; none of those other intel people put you through > > > the hazing > > > > yet? ;-> This is a netdev matter - so i have taken off lkml > > > > > > > > I appreciate the desire to lower clutter from mailing > lists, but I see > > 'tc' as a kernel configuration utility, and as such, people should > > know what we're doing outside of netdev, IMO. But I'm fine with > > keeping this off lkml if that's what people think. > > > > All of netdev has to do with the kernel - that doesnt justify > cross posting. > People interested in network related subsystem development > will subscribe to netdev. Interest in scsi =. subscribe to > scsi mailing lists etc. > > > cheers, > > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior
> jamal wrote: > > Heres the way i see it from a user perspective: > > If a NIC has 3 hardware queues; if that NIC supports strict > priority > > (i.e the prio qdisc) which we already support, there should > be no need > > for the user to really explicitly enable that support. > > It should be transparent to them - because by configuring a multi > > queue prio qdisc (3 bands/queues default), they are already > doing multiqueues. > > Agreed. > > Jeff > Then for clarification, are you asking that I remove the "multiqueue" option to TC and sch_prio, and have it behave the way it did a few patches ago? Thanks, -PJ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
e100 and eepro100
Hello. I heard that there is a plan to remove eepro100 driver from kernel, but from the IPv6 point of view, there are still some issues with e100 driver, which does not exist in eepro100. We are using some e100/eepro100 devices, and we have found that we cannot pass the Conformance Test with e100 but with eepro100. We have been having no chance to debug this issue so far, but I guess there are some bugs in link detection code in e100. Regards, -- YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]> GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100 and eepro100
YOSHIFUJI Hideaki / [EMAIL PROTECTED] wrote: Hello. I heard that there is a plan to remove eepro100 driver from kernel, but from the IPv6 point of view, there are still some issues with e100 driver, which does not exist in eepro100. We are using some e100/eepro100 devices, and we have found that we cannot pass the Conformance Test with e100 but with eepro100. We have been having no chance to debug this issue so far, but I guess there are some bugs in link detection code in e100. please, read the discussion we had yesterday on netdev. Also, without knowing *what* your problems are with e100, we can't help you solving them too. If you bring your bugreport in detail to us at [EMAIL PROTECTED] we can take it up and dig into it. The conclusion is that the s-bit patch will be in 2.6.22, as well as an option to run the driver in IO register access mode. this seems to be sufficient for most of the people that had issues. Auke - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22 5/5] iw_cxgb3: Update required firmware revision to 4.0.0.
Roland Dreier wrote: > Update required firmware revision to 4.0.0. Hmm... should we fold this into the earlier patch, which actually needs this new FW? Or at least merge this patch first? Also, is it cool with everyone to require a new FW, even for users who might not be using (or even building) the RDMA driver? I'm not sure what a good solution would be really, so maybe the pain of forcing everyone to update FW is the least bad thing to do. Hi Roland, The FW update required code changes in the RDMA driver, so Steve took care of submitting the update patch. The new FW is required for the NIC driver too. Cheers, Divy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[git patches] e1000 fixes
Please pull from 'e1000-fixes' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git e1000-fixes to receive the following updates: drivers/net/e1000/e1000_main.c | 104 ++-- 1 files changed, 58 insertions(+), 46 deletions(-) Auke Kok (1): e1000: FIX: be ready for incoming irq at pci_request_irq Bruce Allan (1): e1000: FIX: firmware handover bits Mark Huth (1): e1000: FIX: Stop raw interrupts disabled nag from RT diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index b28a915..eb3ff1f 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -409,25 +409,21 @@ e1000_release_hw_control(struct e1000_adapter *adapter) { uint32_t ctrl_ext; uint32_t swsm; - uint32_t extcnf; /* Let firmware taken over control of h/w */ switch (adapter->hw.mac_type) { - case e1000_82571: - case e1000_82572: - case e1000_80003es2lan: - ctrl_ext = E1000_READ_REG(&adapter->hw, CTRL_EXT); - E1000_WRITE_REG(&adapter->hw, CTRL_EXT, - ctrl_ext & ~E1000_CTRL_EXT_DRV_LOAD); - break; case e1000_82573: swsm = E1000_READ_REG(&adapter->hw, SWSM); E1000_WRITE_REG(&adapter->hw, SWSM, swsm & ~E1000_SWSM_DRV_LOAD); + break; + case e1000_82571: + case e1000_82572: + case e1000_80003es2lan: case e1000_ich8lan: - extcnf = E1000_READ_REG(&adapter->hw, CTRL_EXT); + ctrl_ext = E1000_READ_REG(&adapter->hw, CTRL_EXT); E1000_WRITE_REG(&adapter->hw, CTRL_EXT, - extcnf & ~E1000_CTRL_EXT_DRV_LOAD); + ctrl_ext & ~E1000_CTRL_EXT_DRV_LOAD); break; default: break; @@ -450,26 +446,21 @@ e1000_get_hw_control(struct e1000_adapter *adapter) { uint32_t ctrl_ext; uint32_t swsm; - uint32_t extcnf; /* Let firmware know the driver has taken over */ switch (adapter->hw.mac_type) { - case e1000_82571: - case e1000_82572: - case e1000_80003es2lan: - ctrl_ext = E1000_READ_REG(&adapter->hw, CTRL_EXT); - E1000_WRITE_REG(&adapter->hw, CTRL_EXT, - ctrl_ext | E1000_CTRL_EXT_DRV_LOAD); - break; case e1000_82573: swsm = E1000_READ_REG(&adapter->hw, SWSM); E1000_WRITE_REG(&adapter->hw, SWSM, swsm | E1000_SWSM_DRV_LOAD); break; + case e1000_82571: + case e1000_82572: + case e1000_80003es2lan: case e1000_ich8lan: - extcnf = E1000_READ_REG(&adapter->hw, EXTCNF_CTRL); - E1000_WRITE_REG(&adapter->hw, EXTCNF_CTRL, - extcnf | E1000_EXTCNF_CTRL_SWFLAG); + ctrl_ext = E1000_READ_REG(&adapter->hw, CTRL_EXT); + E1000_WRITE_REG(&adapter->hw, CTRL_EXT, + ctrl_ext | E1000_CTRL_EXT_DRV_LOAD); break; default: break; @@ -522,14 +513,15 @@ e1000_release_manageability(struct e1000_adapter *adapter) } } -int -e1000_up(struct e1000_adapter *adapter) +/** + * e1000_configure - configure the hardware for RX and TX + * @adapter = private board structure + **/ +static void e1000_configure(struct e1000_adapter *adapter) { struct net_device *netdev = adapter->netdev; int i; - /* hardware has been reset, we need to reload some things */ - e1000_set_multi(netdev); e1000_restore_vlan(adapter); @@ -548,14 +540,20 @@ e1000_up(struct e1000_adapter *adapter) } adapter->tx_queue_len = netdev->tx_queue_len; +} + +int e1000_up(struct e1000_adapter *adapter) +{ + /* hardware has been reset, we need to reload some things */ + e1000_configure(adapter); + + clear_bit(__E1000_DOWN, &adapter->flags); #ifdef CONFIG_E1000_NAPI - netif_poll_enable(netdev); + netif_poll_enable(adapter->netdev); #endif e1000_irq_enable(adapter); - clear_bit(__E1000_DOWN, &adapter->flags); - /* fire a link change interrupt to start the watchdog */ E1000_WRITE_REG(&adapter->hw, ICS, E1000_ICS_LSC); return 0; @@ -640,15 +638,15 @@ e1000_down(struct e1000_adapter *adapter) * reschedule our watchdog timer */ set_bit(__E1000_DOWN, &adapter->flags); +#ifdef CONFIG_E1000_NAPI + netif_poll_disable(netdev); +#endif e1000_irq_disable(adapter); del_timer_sync(&adapter->tx_fifo_stall_timer); del_timer_sync(&adapter->watchdog_timer); del_timer_sync(&adapter->phy_info_timer); -#ifdef CONFIG_E1000_NAPI - netif_poll_disable(netdev); -#endif
Re: wrong destination MAC in ethernet packets from sky2 ?
On Fri, 27 Apr 2007 11:33:18 +0200 "Csillag Kristof" <[EMAIL PROTECTED]> wrote: > Hi all! > > I have encountered a strange error, and I believe that > the culprit might be the sky2 driver, so I hope you can help. > > The symptom is that sometimes the connection between my server box > (which is based on a Foxconn g9657ma motherboard > (which contains a "Yukon-EC Ultra (0xb4) rev 2" gigabit network adapter > - 11ab:4364)) and the rest of the network gets ... screwed up. That is the chip on Gigabyte motherboard that was so busted, I ended up blacklisting it for 2.6.21. Please send full lspci -vvx for the motherboard > Some things work, and some don't. > Server can ping the client, but the client can not ping the server. > An other client can not get a DHCP address. > > From the logs, I can see that the server _thinks_ that it has sent back > some DHCP offers, but the client never received any. > The 88e8056 is sensitive to PCI timing issues. Not sure what is going on yet, but for some reason it works on Asus, but on Gigabyte it shows all the signs of not reading memory correctly, or doing out of order stuff. Since I don't work for a hardware company and don't have all the bus analyzer hooks to see what really is going on, it probably won't get fixed fast. That is why the 88e8056 is marked 'ifdef broken' until this is figured out. > > Since I ruled out any other software obstacles, I have done a network > traffic capture (with wireshark) on both ends, and here is what I have found: > > - On the client end, it seems that the DHCP OFFER package was addressed to a > different MAC address, not the one the DHCP DISCOVER originated from. > More precisely, the first two bytes of the six-byte MAX address is > different, > and the last four byte matches. > > - Looking at the same traffic on the server side, it seems that the > destination > MAC address is OK. > > - To decide which side is right, I have done a capture on a third machine. > (I can do this, thanks to a dump hub and promiscuous mode.) > It verified that the MAC address in the DHCP OFFER is indeed different. > > So, it looks like sometimes the first two bytes of the destination MAC address > is screwed up in the ethernet packets coming out from my server. > >* * * > > I am using debian 2.6.20-2 kernel, which is based on 2.6.20.7. > The version of the sky2 driver is 1.10. > > Since I suspected that this might be a driver error, I took the 1.13 version > from 2.6.21-rc7, and "backported" it to my current kernel. > (I had to comment out some vlan-specific parts, but I do not care for that > now.) > > So now I am running sky2 v1.13, but the same error is still present. > > It is important to note that this error does not always occur. > Sometime everything is all right, sometime messages just stop > getting through. > > Unloading and reloading the sky2 module sometimes help. > * * * > > Do you have any idea what can the root cause for this possibly be, > or (more importantly) how can I fix this? > This box is mission-critical to me. > > Thank you for your help: > > Kristof Csillag Are you using jumbo frames? probably not. The driver in 2.6.21 enables store/forward on transmit and earlier drivers did not. Store/forward should help performance and eliminate any possible bus latency issues. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH] ipv6: track device renames in snmp6
That patch I sent was against 2.6.21, but both 2.6.20 and 2.6.21 have the problem. Here is a version for 2.6.20. = When network device's are renamed, the IPV6 snmp6 code gets confused. It doesn't track name changes so it will OOPS when network device's are removed. The fix is trivial, just unregister/re-register in notify handler. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- net/ipv6/addrconf.c |6 -- net/ipv6/proc.c |1 + 2 files changed, 5 insertions(+), 2 deletions(-) --- linux-2.6.20.y.orig/net/ipv6/addrconf.c 2007-04-27 11:14:51.0 -0700 +++ linux-2.6.20.y/net/ipv6/addrconf.c 2007-04-27 11:16:26.0 -0700 @@ -2338,8 +2338,9 @@ static int addrconf_notify(struct notifi break; case NETDEV_CHANGENAME: -#ifdef CONFIG_SYSCTL if (idev) { + snmp6_unregister_dev(idev); +#ifdef CONFIG_SYSCTL addrconf_sysctl_unregister(&idev->cnf); neigh_sysctl_unregister(idev->nd_parms); neigh_sysctl_register(dev, idev->nd_parms, @@ -2347,8 +2348,9 @@ static int addrconf_notify(struct notifi &ndisc_ifinfo_sysctl_change, NULL); addrconf_sysctl_register(idev, &idev->cnf); - } #endif + snmp6_register_dev(idev); + } break; }; --- linux-2.6.20.y.orig/net/ipv6/proc.c 2007-02-23 15:34:07.0 -0800 +++ linux-2.6.20.y/net/ipv6/proc.c 2007-04-27 11:16:26.0 -0700 @@ -237,6 +237,7 @@ int snmp6_unregister_dev(struct inet6_de return -EINVAL; remove_proc_entry(idev->stats.proc_dir_entry->name, proc_net_devsnmp6); + idev->stats.proc_dir_entry = NULL; return 0; } - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 28/46] PHY: remove rwsem use from phy core
The subsystem rwsem is not used by the driver core at all, so the use of it in the phy code doesn't make any sense. They might possibly want to use a local lock, but I am unsure about that. Cc: netdev Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- drivers/net/phy/fixed.c |6 -- drivers/net/phy/phy_device.c |9 + 2 files changed, 1 insertions(+), 14 deletions(-) diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c index 66da91b..68c99b4 100644 --- a/drivers/net/phy/fixed.c +++ b/drivers/net/phy/fixed.c @@ -276,21 +276,15 @@ static int fixed_mdio_register_device(int number, int speed, int duplex) artificially, we are binding the driver here by hand; it will be the same for all the fixed phys anyway. */ - down_write(&phydev->dev.bus->subsys.rwsem); - phydev->dev.driver = &fixed_mdio_driver.driver; err = phydev->dev.driver->probe(&phydev->dev); if(err < 0) { printk(KERN_ERR "Phy %s: problems with fixed driver\n",phydev->dev.bus_id); - up_write(&phydev->dev.bus->subsys.rwsem); goto probe_fail; } err = device_bind_driver(&phydev->dev); - - up_write(&phydev->dev.bus->subsys.rwsem); - if (err) goto probe_fail; diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 7d5b6d1..8f01952 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -208,16 +208,12 @@ struct phy_device *phy_attach(struct net_device *dev, * exist, and we should use the genphy driver. */ if (NULL == d->driver) { int err; - down_write(&d->bus->subsys.rwsem); d->driver = &genphy_driver.driver; err = d->driver->probe(d); - if (err >= 0) err = device_bind_driver(d); - up_write(&d->bus->subsys.rwsem); - if (err) return ERR_PTR(err); } @@ -258,11 +254,8 @@ void phy_detach(struct phy_device *phydev) * was using the generic driver), we unbind the device * from the generic driver so that there's a chance a * real driver could be loaded */ - if (phydev->dev.driver == &genphy_driver.driver) { - down_write(&phydev->dev.bus->subsys.rwsem); + if (phydev->dev.driver == &genphy_driver.driver) device_release_driver(&phydev->dev); - up_write(&phydev->dev.bus->subsys.rwsem); - } } EXPORT_SYMBOL(phy_detach); -- 1.5.1.2 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] e100 driver on ARM
On Thu, Apr 26, 2007 at 09:19:34AM -0700, H. Peter Anvin wrote: > Why wouldn't that be permitted? It, in fact, happens all the time (the > host bridge withdraws the GNT# line and raises STOP#, which does a > Termination With Data of the bus transfer.) This is a normal event and > if you can't handle it you won't work with many host bridges at all. Well there must have been something else wrong then. Certainly I saw data corruption on a rtl8139. No problems with the same hardware using a geode SC1200, so I have no idea. I liked the speed of the PXA255 a lot better than the slow poke SC1200. -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 09/11] forcedeth: improve NAPI logic
On Thu, Apr 26, 2007 at 10:53:04AM -0400, Ayaz Abdulla wrote: > Ok. In that case, the patch needs to be improved. > > The following needs to be done when NAPI is enabled: > - remove the tx handling within the ISRs > - mask off the tx interrupts within the ISRs that handle tx processing > - re-enable tx interrupts within the NAPI handler > - add tx handling within the NAPI handler (this patch covers it) I thought a number of drivers handled tx from napi while receives were happening, but went to plain interrupts if no receives were happening. Maybe I misread the code (I have mainly dealt with pcnet32 so far). Certainly for gigabit I would think napi all the time would be much more efficient. -- Len Sorensen - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1
On Fri, 27 Apr 2007 11:25:46 +0200 "VE \(HOME\)" <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]> > > wrote: > > > > > > This was due to locking bustage in the net tree. It should be fixed > > in 2.6.21-rc7-mm2. > > I have tried this version. Same problem ( see > http://mail1.vetienne.net/linux/dmesg-2.6.21-rc7-mm2.log ) That file has disappeared. > But also a new problem with USB keyboard/mouse > USB problem - let's handle that separately. > > And also a strange problem : dhcp server and dns server was started before > bond0 was completly up ( eth0 and eth1 was declared down at this time and > up a few times later : was not the case with later 2.6.21-rc6-mm1 ) > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH repost] netpoll: trapping fix/cleanup
CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely bypassed in the netpoll's "trapped" mode which easily causes overflows in the drivers with short TX queues (most notably, in 8139too with its 4-deep queue). Make this option more sensible by only bypassing TX softirq wakeup and remove CONFIG_NETPOLL_RX option completely since there is *no* code depending on it. Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> --- I wonder can I expect any motion with this patch (at least denial :-)? drivers/net/Kconfig |5 - include/linux/netdevice.h |8 +++- 2 files changed, 3 insertions(+), 10 deletions(-) Index: linux-2.6/include/linux/netdevice.h === --- linux-2.6.orig/include/linux/netdevice.h +++ linux-2.6/include/linux/netdevice.h @@ -647,8 +647,10 @@ static inline void netif_start_queue(str static inline void netif_wake_queue(struct net_device *dev) { #ifdef CONFIG_NETPOLL_TRAP - if (netpoll_trap()) + if (netpoll_trap()) { + clear_bit(__LINK_STATE_XOFF, &dev->state); return; + } #endif if (test_and_clear_bit(__LINK_STATE_XOFF, &dev->state)) __netif_schedule(dev); @@ -656,10 +658,6 @@ static inline void netif_wake_queue(stru static inline void netif_stop_queue(struct net_device *dev) { -#ifdef CONFIG_NETPOLL_TRAP - if (netpoll_trap()) - return; -#endif set_bit(__LINK_STATE_XOFF, &dev->state); } Index: linux-2.6/drivers/net/Kconfig === --- linux-2.6.orig/drivers/net/Kconfig +++ linux-2.6/drivers/net/Kconfig @@ -2928,11 +2928,6 @@ endif #NETDEVICES config NETPOLL def_bool NETCONSOLE -config NETPOLL_RX - bool "Netpoll support for trapping incoming packets" - default n - depends on NETPOLL - config NETPOLL_TRAP bool "Netpoll traffic trapping" default n - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: IPoIB forwarding
Bryan Lawver wrote: Your right about the ipoib module not combining packets (I believed you without checking) but I did never the less. The ipoib_start_xmit routine is definitely handed a "double packet" which means that the IP NIC driver or the kernel is combining two packets into a single super jumbo packet. This issue is irrespective of the IP MTU setting because I have set all interfaces to 9000k yet ipoib accepts and forwards this 17964 packet to the next IB node and onto the TCP stack where it is never acknowledged. This may not have come up in prior testing because I am using some of the fastest IP NICs which have no trouble keeping up with or exceeding the bandwidth of the IB side. This issue arises exactly every 8 packets...(ring buffer overrun??) I will be at Sonoma for the next few days as many on this list will be. Some NICs (esp 10G) support large receive offload - they coalesce TCP segments from the wire/fiber into larger ones they pass up the stack. Perhaps that is happening here? I'm going to go out a bit on a limb, cross the streams, and include netdev, because I suspect that if a system is acting as an IP router, one doesn't want large receive offload enabled. That may need some discussion in netdev - it may then require some changes to default settings or some documentation enhancements. That or I'll learn that the stack is already dealing with the issue... rick jones bryan At 11:06 AM 4/26/2007, Michael S. Tsirkin wrote: > Quoting Bryan Lawver <[EMAIL PROTECTED]>: > Subject: Re: IPoIB forwarding > > Here's a tcpdump of the same sequence. The TCP MSS is 8960 and it appears > that two payloads are queued at ipoib which combines them into a single > 17920 payload with assumingly correct IP header (40) and IB header > (4). The application or TCP stack does not acknowledge this double packet > ie. it does not ACK until each of the 8960 packets are resent > individually. Being an IB newbie, I am guessing this combining is > allowable but may violate TCP protocol. IPoIB does nothing like this - it's just a network device so it sends all packets out as is. -- MST ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH repost] netpoll: trapping fix/cleanup
On Fri, Apr 27, 2007 at 11:44:00PM +0400, Sergei Shtylyov wrote: > CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely bypassed in > the netpoll's "trapped" mode which easily causes overflows in the drivers with > short TX queues (most notably, in 8139too with its 4-deep queue). > Make this option more sensible by only bypassing TX softirq wakeup and remove > CONFIG_NETPOLL_RX option completely since there is *no* code depending on it. You've got two unrelated patches here, so that's an automatic NAK. I suppose we can kill the config option. What did you test the NETPOLL_TRAP test with? -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] e1000: ROUND_UP macro cleanup in drivers/net/e1000
From: Milind Arun Choudhary <[EMAIL PROTECTED]> E1000_ROUNDUP macro cleanup, use ALIGN Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000/e1000.h |3 --- drivers/net/e1000/e1000_ethtool.c |6 +++--- drivers/net/e1000/e1000_main.c| 10 +- drivers/net/e1000/e1000_param.c |4 ++-- 4 files changed, 10 insertions(+), 13 deletions(-) diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h index dd4b728..a9ea67e 100644 --- a/drivers/net/e1000/e1000.h +++ b/drivers/net/e1000/e1000.h @@ -155,9 +155,6 @@ struct e1000_adapter; /* Number of packet split data buffers (not including the header buffer) */ #define PS_PAGE_BUFFERS MAX_PS_BUFFERS-1 -/* only works for sizes that are powers of 2 */ -#define E1000_ROUNDUP(i, size) ((i) = (((i) + (size) - 1) & ~((size) - 1))) - /* wrapper around a pointer to a socket buffer, * so a DMA handle can be stored along with the buffer */ struct e1000_buffer { diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c index 6777887..0fbd873 100644 --- a/drivers/net/e1000/e1000_ethtool.c +++ b/drivers/net/e1000/e1000_ethtool.c @@ -686,12 +686,12 @@ e1000_set_ringparam(struct net_device *netdev, rxdr->count = max(ring->rx_pending,(uint32_t)E1000_MIN_RXD); rxdr->count = min(rxdr->count,(uint32_t)(mac_type < e1000_82544 ? E1000_MAX_RXD : E1000_MAX_82544_RXD)); - E1000_ROUNDUP(rxdr->count, REQ_RX_DESCRIPTOR_MULTIPLE); + rxdr->count = ALIGN(rxdr->count, REQ_RX_DESCRIPTOR_MULTIPLE); txdr->count = max(ring->tx_pending,(uint32_t)E1000_MIN_TXD); txdr->count = min(txdr->count,(uint32_t)(mac_type < e1000_82544 ? E1000_MAX_TXD : E1000_MAX_82544_TXD)); - E1000_ROUNDUP(txdr->count, REQ_TX_DESCRIPTOR_MULTIPLE); + txdr->count = ALIGN(txdr->count, REQ_TX_DESCRIPTOR_MULTIPLE); for (i = 0; i < adapter->num_tx_queues; i++) txdr[i].count = txdr->count; @@ -1068,7 +1068,7 @@ e1000_setup_desc_rings(struct e1000_adapter *adapter) memset(txdr->buffer_info, 0, size); txdr->size = txdr->count * sizeof(struct e1000_tx_desc); - E1000_ROUNDUP(txdr->size, 4096); + txdr->size = ALIGN(txdr->size, 4096); if (!(txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma))) { ret_val = 2; goto err_nomem; diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index 9267f16..b9ff21f 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -748,9 +748,9 @@ e1000_reset(struct e1000_adapter *adapter) VLAN_TAG_SIZE; min_tx_space = min_rx_space; min_tx_space *= 2; - E1000_ROUNDUP(min_tx_space, 1024); + min_tx_space = ALIGN(min_tx_space, 1024); min_tx_space >>= 10; - E1000_ROUNDUP(min_rx_space, 1024); + min_rx_space = ALIGN(min_rx_space, 1024); min_rx_space >>= 10; /* If current Tx allocation is less than the min Tx FIFO size, @@ -1560,7 +1560,7 @@ e1000_setup_tx_resources(struct e1000_adapter *adapter, /* round up to nearest 4K */ txdr->size = txdr->count * sizeof(struct e1000_tx_desc); - E1000_ROUNDUP(txdr->size, 4096); + txdr->size = ALIGN(txdr->size, 4096); txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if (!txdr->desc) { @@ -1803,7 +1803,7 @@ e1000_setup_rx_resources(struct e1000_adapter *adapter, /* Round up to nearest 4K */ rxdr->size = rxdr->count * desc_len; - E1000_ROUNDUP(rxdr->size, 4096); + rxdr->size = ALIGN(rxdr->size, 4096); rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); @@ -3175,7 +3175,7 @@ e1000_82547_fifo_workaround(struct e1000_adapter *adapter, struct sk_buff *skb) uint32_t fifo_space = adapter->tx_fifo_size - adapter->tx_fifo_head; uint32_t skb_fifo_len = skb->len + E1000_FIFO_HDR; - E1000_ROUNDUP(skb_fifo_len, E1000_FIFO_HDR); + skb_fifo_len = ALIGN(skb_fifo_len, E1000_FIFO_HDR); if (adapter->link_duplex != HALF_DUPLEX) goto no_fifo_stall_required; diff --git a/drivers/net/e1000/e1000_param.c b/drivers/net/e1000/e1000_param.c index f8862e2..f485874 100644 --- a/drivers/net/e1000/e1000_param.c +++ b/drivers/net/e1000/e1000_param.c @@ -305,7 +305,7 @@ e1000_check_options(struct e1000_adapter *adapter) if (num_TxDescriptors > bd) { tx_ring->count = TxDescriptors[bd]; e1000_validate_option(&tx_ring->count, &opt, adapter); - E1000_ROUNDUP(tx_ring->count, + tx_ring->count = ALIGN(tx_ring->count, REQ_TX_DESCRIPTOR_MULTIPLE);
[PATCH 2/2] ixgb: ROUND_UP macro cleanup in drivers/net/ixgb
From: Milind Arun Choudhary <[EMAIL PROTECTED]> IXGB_ROUNDUP macro cleanup ,use ALIGN Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/ixgb/ixgb.h |3 --- drivers/net/ixgb/ixgb_ethtool.c |4 ++-- drivers/net/ixgb/ixgb_main.c|4 ++-- drivers/net/ixgb/ixgb_param.c |4 ++-- 4 files changed, 6 insertions(+), 9 deletions(-) diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h index cf30a10..c8e9086 100644 --- a/drivers/net/ixgb/ixgb.h +++ b/drivers/net/ixgb/ixgb.h @@ -111,9 +111,6 @@ struct ixgb_adapter; /* How many Rx Buffers do we bundle into one write to the hardware ? */ #define IXGB_RX_BUFFER_WRITE 8 /* Must be power of 2 */ -/* only works for sizes that are powers of 2 */ -#define IXGB_ROUNDUP(i, size) ((i) = (((i) + (size) - 1) & ~((size) - 1))) - /* wrapper around a pointer to a socket buffer, * so a DMA handle can be stored along with the buffer */ struct ixgb_buffer { diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c index d6628bd..afde848 100644 --- a/drivers/net/ixgb/ixgb_ethtool.c +++ b/drivers/net/ixgb/ixgb_ethtool.c @@ -577,11 +577,11 @@ ixgb_set_ringparam(struct net_device *netdev, rxdr->count = max(ring->rx_pending,(uint32_t)MIN_RXD); rxdr->count = min(rxdr->count,(uint32_t)MAX_RXD); - IXGB_ROUNDUP(rxdr->count, IXGB_REQ_RX_DESCRIPTOR_MULTIPLE); + rxdr->count = ALIGN(rxdr->count, IXGB_REQ_RX_DESCRIPTOR_MULTIPLE); txdr->count = max(ring->tx_pending,(uint32_t)MIN_TXD); txdr->count = min(txdr->count,(uint32_t)MAX_TXD); - IXGB_ROUNDUP(txdr->count, IXGB_REQ_TX_DESCRIPTOR_MULTIPLE); + txdr->count = ALIGN(txdr->count, IXGB_REQ_TX_DESCRIPTOR_MULTIPLE); if(netif_running(adapter->netdev)) { /* Try to get new resources before deleting old */ diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c index dfde80e..6d2b059 100644 --- a/drivers/net/ixgb/ixgb_main.c +++ b/drivers/net/ixgb/ixgb_main.c @@ -685,7 +685,7 @@ ixgb_setup_tx_resources(struct ixgb_adapter *adapter) /* round up to nearest 4K */ txdr->size = txdr->count * sizeof(struct ixgb_tx_desc); - IXGB_ROUNDUP(txdr->size, 4096); + txdr->size = ALIGN(txdr->size, 4096); txdr->desc = pci_alloc_consistent(pdev, txdr->size, &txdr->dma); if(!txdr->desc) { @@ -774,7 +774,7 @@ ixgb_setup_rx_resources(struct ixgb_adapter *adapter) /* Round up to nearest 4K */ rxdr->size = rxdr->count * sizeof(struct ixgb_rx_desc); - IXGB_ROUNDUP(rxdr->size, 4096); + rxdr->size = ALIGN(rxdr->size, 4096); rxdr->desc = pci_alloc_consistent(pdev, rxdr->size, &rxdr->dma); diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c index b27442a..ee8cc67 100644 --- a/drivers/net/ixgb/ixgb_param.c +++ b/drivers/net/ixgb/ixgb_param.c @@ -284,7 +284,7 @@ ixgb_check_options(struct ixgb_adapter *adapter) } else { tx_ring->count = opt.def; } - IXGB_ROUNDUP(tx_ring->count, IXGB_REQ_TX_DESCRIPTOR_MULTIPLE); + tx_ring->count = ALIGN(tx_ring->count, IXGB_REQ_TX_DESCRIPTOR_MULTIPLE); } { /* Receive Descriptor Count */ struct ixgb_option opt = { @@ -303,7 +303,7 @@ ixgb_check_options(struct ixgb_adapter *adapter) } else { rx_ring->count = opt.def; } - IXGB_ROUNDUP(rx_ring->count, IXGB_REQ_RX_DESCRIPTOR_MULTIPLE); + rx_ring->count = ALIGN(rx_ring->count, IXGB_REQ_RX_DESCRIPTOR_MULTIPLE); } { /* Receive Checksum Offload Enable */ struct ixgb_option opt = { - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 ethernet bonding problems
See: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21-rc7/ Please Cc: netdev on success/failure. Applied suggested patchset to vanilla 2.6.21. Compiled using .config from linux-image-2.6.21-rc7 pulled down from http://kernel-archive.buildserver.net/debian-kernel Compiles, boots. Bonding does not work reliably. Simple config: #auto bond0 iface bond0 inet manual up ip link set dev $IFACE up up echo +eth1 > /sys/class/net/$IFACE/bonding/slaves up echo +eth2 > /sys/class/net/$IFACE/bonding/slaves up ip link set dev eth1 up up ip link set dev eth2 up up ip addr add 172.21.255.5/29 dev $IFACE down ip addr del 172.21.255.5/29 dev $IFACE down ip link set dev eth2 down down ip link set dev eth1 down down echo -eth2 > /sys/class/net/$IFACE/bonding/slaves down echo -eth1 > /sys/class/net/$IFACE/bonding/slaves down ip link set dev $IFACE down Bond comes up, cannot ping unless I manually force promisc on both member links: ip link set dev eth1 promisc on ip link set dev eth2 promisc off Link failover does not work reliably. Carrier-detect appears to be working, so I don't think that is an issue. A disturbing problem is mac corruption after "modprobe -r r8169; modprobe r8169" ip link sh: 2: eth5: mtu 1500 qdisc noop qlen 1000 link/ether 00:00:00:00:68:93 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:18:ab:68:94 brd ff:ff:ff:ff:ff:ff 4: eth2: mtu 1500 qdisc noop qlen 1000 link/ether 00:30:18:ab:68:95 brd ff:ff:ff:ff:ff:ff eth5 mac was 00:30:18:ab:68:93 before the modprobe. Not sure what's going on here, but I'm starting to think these interfaces aren't the best in the world... Tim:> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 28/46] PHY: remove rwsem use from phy core
On Apr 27, 2007, at 13:53, Greg Kroah-Hartman wrote: The subsystem rwsem is not used by the driver core at all, so the use of it in the phy code doesn't make any sense. They might possibly want to use a local lock, but I am unsure about that. Cc: netdev Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> Acked-by: Andy Fleming <[EMAIL PROTECTED]> --- I think I copied that code from elsewhere without truly understanding it. *bows head in shame* As such, I have no objection to this patch unless someone says it breaks their board. :) drivers/net/phy/fixed.c |6 -- drivers/net/phy/phy_device.c |9 + 2 files changed, 1 insertions(+), 14 deletions(-) diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c index 66da91b..68c99b4 100644 --- a/drivers/net/phy/fixed.c +++ b/drivers/net/phy/fixed.c @@ -276,21 +276,15 @@ static int fixed_mdio_register_device(int number, int speed, int duplex) artificially, we are binding the driver here by hand; it will be the same for all the fixed phys anyway. */ - down_write(&phydev->dev.bus->subsys.rwsem); - phydev->dev.driver = &fixed_mdio_driver.driver; err = phydev->dev.driver->probe(&phydev->dev); if(err < 0) { printk(KERN_ERR "Phy %s: problems with fixed driver\n",phydev- >dev.bus_id); - up_write(&phydev->dev.bus->subsys.rwsem); goto probe_fail; } err = device_bind_driver(&phydev->dev); - - up_write(&phydev->dev.bus->subsys.rwsem); - if (err) goto probe_fail; diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/ phy_device.c index 7d5b6d1..8f01952 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -208,16 +208,12 @@ struct phy_device *phy_attach(struct net_device *dev, * exist, and we should use the genphy driver. */ if (NULL == d->driver) { int err; - down_write(&d->bus->subsys.rwsem); d->driver = &genphy_driver.driver; err = d->driver->probe(d); - if (err >= 0) err = device_bind_driver(d); - up_write(&d->bus->subsys.rwsem); - if (err) return ERR_PTR(err); } @@ -258,11 +254,8 @@ void phy_detach(struct phy_device *phydev) * was using the generic driver), we unbind the device * from the generic driver so that there's a chance a * real driver could be loaded */ - if (phydev->dev.driver == &genphy_driver.driver) { - down_write(&phydev->dev.bus->subsys.rwsem); + if (phydev->dev.driver == &genphy_driver.driver) device_release_driver(&phydev->dev); - up_write(&phydev->dev.bus->subsys.rwsem); - } } EXPORT_SYMBOL(phy_detach); -- 1.5.1.2 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 ethernet bonding problems
Tim Durack <[EMAIL PROTECTED]> wrote: [...] >Bond comes up, cannot ping unless I manually force promisc on both member >links: > >ip link set dev eth1 promisc on >ip link set dev eth2 promisc off From looking at the source code for r8169, but it appears that the r8169 driver only reads the device MAC address at probe time, and doesn't propogate changes to the MAC out to the device. That might explain the "promisc" problem if the device also does MAC filtering. Am I missing something in the driver? I don't actually have one of these to test with, I'm just looking at the source and observing that dev_addr is only ever referenced in the probe function, and that's only to read in the MAC from the device. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 ethernet bonding problems
>ip link set dev eth1 promisc on >ip link set dev eth2 promisc off typo, "ip link set dev eth2 promisc on" of course From looking at the source code for r8169, but it appears that the r8169 driver only reads the device MAC address at probe time, and doesn't propogate changes to the MAC out to the device. That might explain the "promisc" problem if the device also does MAC filtering. Am I missing something in the driver? I have applied all patches from the set, including: 0012-r8169-mac-address-change-support.patch which I assume adds the ability to reprogram MAC filtering. Behaviour indicates the MAC filter doesn't get reprogrammed though. I don't actually have one of these to test with, I'm just looking at the source and observing that dev_addr is only ever referenced in the probe function, and that's only to read in the MAC from the device. You're not missing much, believe me :-| Tim:> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 ethernet bonding problems
Tim Durack <[EMAIL PROTECTED]> : [...] > Link failover does not work reliably. Carrier-detect appears to be > working, so I don't think that is an issue. > > > A disturbing problem is mac corruption after "modprobe -r r8169; modprobe > r8169" > > ip link sh: > > 2: eth5: mtu 1500 qdisc noop qlen 1000 >link/ether 00:00:00:00:68:93 brd ff:ff:ff:ff:ff:ff > 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 >link/ether 00:30:18:ab:68:94 brd ff:ff:ff:ff:ff:ff > 4: eth2: mtu 1500 qdisc noop qlen 1000 >link/ether 00:30:18:ab:68:95 brd ff:ff:ff:ff:ff:ff > > eth5 mac was 00:30:18:ab:68:93 before the modprobe. Can you revert patch #0012 and see if it changes this part of the problem ? A tcpdump trace 1) before promiscuous mode 2) after promiscuous mode 3) after link failure (i.e. failover does not work) would be welcome. > Not sure what's going on here, but I'm starting to think these > interfaces aren't the best in the world... The maintainer/driver/hardware combination is a bit quirky at times but it does not work too bad. :o) -- Ueimor Anybody got a battery for my Ultra 10 ? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] AFS: Fix VLocation record update wakeup
From: David Howells <[EMAIL PROTECTED]> Date: Fri, 27 Apr 2007 15:31:35 +0100 > Fix the wakeup transitions after a VLocation record update completes one way > or another. This builds on Dave Miller's partial fix. > > Also move wakeups outside the spinlocked sections. Applied, thanks David, although a minor nit. > Signed-Off-By: David Howells <[EMAIL PROTECTED]> The canonical signoff line does not capitalize Off and By, I keep fixing this up in your submissions so I figured I should let you know about it to save me some typing in the future :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] AF_RXRPC/AFS: Arch-specific fixes
From: David Howells <[EMAIL PROTECTED]> Date: Fri, 27 Apr 2007 15:31:40 +0100 > Fixes for various arch compilation problems: > > (*) Missing module exports. > > (*) Variable name collision when rxkad and af_rxrpc both built in > (rxrpc_debug). > > (*) Large constant representation problem (AFS_UUID_TO_UNIX_TIME). > > (*) Configuration dependencies. > > (*) printk() format warnings. > > Signed-Off-By: David Howells <[EMAIL PROTECTED]> Applied to fix the build failures, but you have to do some of this better, for example: > diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c > index 1eaf529..5ec7051 100644 > --- a/net/rxrpc/rxkad.c > +++ b/net/rxrpc/rxkad.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#define rxrpc_debug rxkad_debug > #include "ar-internal.h" Please stop with this CPP macro stuff, it's really crap'ifying your otherwise quite nice code. Just use rxkad_debug in all the uses, splitting out things properly. THanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] NET: Fix networking compilation errors
From: David Howells <[EMAIL PROTECTED]> Date: Fri, 27 Apr 2007 15:31:45 +0100 > Fix miscellaneous networking compilation errors. > > (*) Export ktime_add_ns() for modules. > > (*) wext_proc_init() should have an ANSI declaration. > > Signed-Off-By: David Howells <[EMAIL PROTECTED]> Also applied, thanks David. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: IPoIB forwarding
Bryan Lawver wrote: I hit the IP NIC over the head with a hammer and turned off all offload features and I no longer get the super jumbo packet and I have symmetric performance. This NIC supported "ethtool -K ethx tso/tx/rx/sg on/off" and I am not sure at this time which one I needed to whack but all off solved the problem. Yeah, that does seem like a rather broad remedy, but I guess if it works... :) And I suppose most of those offloads don't matter for a NIC being used in a router. Only problem is we don't know if it worked because it slowed-down the 10G side or because it had LRO disabling as a side-effect. If I were to guess, of those things listed, I'd guess that receive cko would have that as a side effect. Just what sort of 10G NIC was this anyway? With that knowledge we could probably narrow things down to a more specific modprobe setting, or maybe even an ethtool command, for some suitable revision of ethtool. rick jones Thanks for listening and re enforcing my search process. bryan At 01:32 PM 4/27/2007, Rick Jones wrote: Bryan Lawver wrote: Your right about the ipoib module not combining packets (I believed you without checking) but I did never the less. The ipoib_start_xmit routine is definitely handed a "double packet" which means that the IP NIC driver or the kernel is combining two packets into a single super jumbo packet. This issue is irrespective of the IP MTU setting because I have set all interfaces to 9000k yet ipoib accepts and forwards this 17964 packet to the next IB node and onto the TCP stack where it is never acknowledged. This may not have come up in prior testing because I am using some of the fastest IP NICs which have no trouble keeping up with or exceeding the bandwidth of the IB side. This issue arises exactly every 8 packets...(ring buffer overrun??) I will be at Sonoma for the next few days as many on this list will be. Some NICs (esp 10G) support large receive offload - they coalesce TCP segments from the wire/fiber into larger ones they pass up the stack. Perhaps that is happening here? I'm going to go out a bit on a limb, cross the streams, and include netdev, because I suspect that if a system is acting as an IP router, one doesn't want large receive offload enabled. That may need some discussion in netdev - it may then require some changes to default settings or some documentation enhancements. That or I'll learn that the stack is already dealing with the issue... rick jones bryan At 11:06 AM 4/26/2007, Michael S. Tsirkin wrote: > Quoting Bryan Lawver <[EMAIL PROTECTED]>: > Subject: Re: IPoIB forwarding > > Here's a tcpdump of the same sequence. The TCP MSS is 8960 and it appears > that two payloads are queued at ipoib which combines them into a single > 17920 payload with assumingly correct IP header (40) and IB header > (4). The application or TCP stack does not acknowledge this double packet > ie. it does not ACK until each of the 8960 packets are resent > individually. Being an IB newbie, I am guessing this combining is > allowable but may violate TCP protocol. IPoIB does nothing like this - it's just a network device so it sends all packets out as is. -- MST ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1
On Fri, 27 Apr 2007 22:05:28 +0200 Vincent ETIENNE <[EMAIL PROTECTED]> wrote: > Le Friday 27 April 2007 21:20:39, vous avez __crit__: > > On Fri, 27 Apr 2007 11:25:46 +0200 "VE \(HOME\)" <[EMAIL PROTECTED]> wrote: > > > Andrew Morton wrote: > > > > On Thu, 26 Apr 2007 20:58:32 +0200 Vincent ETIENNE <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > > This was due to locking bustage in the net tree. It should be fixed > > > > in 2.6.21-rc7-mm2. > > > > > > I have tried this version. Same problem ( see > > > http://mail1.vetienne.net/linux/dmesg-2.6.21-rc7-mm2.log ) > > > > That file has disappeared. > > Sorry wrong right on the file. Should be ok now Please don't go off-list. Now the people who work on this code don't know that the log is available. I've reestablished a few cc's. The troublesome part is here: e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX e1000: eth0: e1000_watchdog_task: 10/100 speed: disabling TSO bonding: bond0: link status definitely up for interface eth0. bonding: bond0: making interface eth0 the new active one. RTNL: assertion failed at net/ipv4/devinet.c (1055) Call Trace: [] inetdev_event+0x48/0x283 [] _spin_lock_bh+0x9/0x19 [] rt_run_flush+0x7e/0xaf [] notifier_call_chain+0x29/0x56 [] dev_set_mac_address+0x53/0x59 [] :bonding:alb_set_slave_mac_addr+0x41/0x6c [] :bonding:alb_swap_mac_addr+0x91/0x165 [] :bonding:bond_change_active_slave+0x227/0x382 [] :bonding:bond_select_active_slave+0xb7/0xe5 [] :bonding:bond_mii_monitor+0x3cd/0x41e [] :bonding:bond_mii_monitor+0x0/0x41e [] run_timer_softirq+0x130/0x19f [] __do_softirq+0x55/0xc4 [] call_softirq+0x1c/0x28 [] do_softirq+0x2c/0x7d [] smp_apic_timer_interrupt+0x49/0x5e [] mwait_idle+0x0/0x47 [] apic_timer_interrupt+0x66/0x70 [] mwait_idle+0x42/0x47 [] cpu_idle+0x7f/0xa2 [] start_kernel+0x242/0x24e [] _sinittext+0x146/0x14a because we thought we'd fixed the rtnl_lock() problems in 2.6.21-rc7-mm2. Are you sure that log is from 2.6.21-rc7-mm2? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: IPoIB forwarding
I hit the IP NIC over the head with a hammer and turned off all offload features and I no longer get the super jumbo packet and I have symmetric performance. This NIC supported "ethtool -K ethx tso/tx/rx/sg on/off" and I am not sure at this time which one I needed to whack but all off solved the problem. Thanks for listening and re enforcing my search process. bryan At 01:32 PM 4/27/2007, Rick Jones wrote: Bryan Lawver wrote: Your right about the ipoib module not combining packets (I believed you without checking) but I did never the less. The ipoib_start_xmit routine is definitely handed a "double packet" which means that the IP NIC driver or the kernel is combining two packets into a single super jumbo packet. This issue is irrespective of the IP MTU setting because I have set all interfaces to 9000k yet ipoib accepts and forwards this 17964 packet to the next IB node and onto the TCP stack where it is never acknowledged. This may not have come up in prior testing because I am using some of the fastest IP NICs which have no trouble keeping up with or exceeding the bandwidth of the IB side. This issue arises exactly every 8 packets...(ring buffer overrun??) I will be at Sonoma for the next few days as many on this list will be. Some NICs (esp 10G) support large receive offload - they coalesce TCP segments from the wire/fiber into larger ones they pass up the stack. Perhaps that is happening here? I'm going to go out a bit on a limb, cross the streams, and include netdev, because I suspect that if a system is acting as an IP router, one doesn't want large receive offload enabled. That may need some discussion in netdev - it may then require some changes to default settings or some documentation enhancements. That or I'll learn that the stack is already dealing with the issue... rick jones bryan At 11:06 AM 4/26/2007, Michael S. Tsirkin wrote: > Quoting Bryan Lawver <[EMAIL PROTECTED]>: > Subject: Re: IPoIB forwarding > > Here's a tcpdump of the same sequence. The TCP MSS is 8960 and it appears > that two payloads are queued at ipoib which combines them into a single > 17920 payload with assumingly correct IP header (40) and IB header > (4). The application or TCP stack does not acknowledge this double packet > ie. it does not ACK until each of the 8960 packets are resent > individually. Being an IB newbie, I am guessing this combining is > allowable but may violate TCP protocol. IPoIB does nothing like this - it's just a network device so it sends all packets out as is. -- MST ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: IPoIB forwarding
I had so much debugging turned on that it was not the "slowing of the traffic" but the "non-coelescencing" that was the remedy. The NIC is a MyriCom NIC and these are easy options to set. At 03:32 PM 4/27/2007, Rick Jones wrote: Bryan Lawver wrote: I hit the IP NIC over the head with a hammer and turned off all offload features and I no longer get the super jumbo packet and I have symmetric performance. This NIC supported "ethtool -K ethx tso/tx/rx/sg on/off" and I am not sure at this time which one I needed to whack but all off solved the problem. Yeah, that does seem like a rather broad remedy, but I guess if it works... :) And I suppose most of those offloads don't matter for a NIC being used in a router. Only problem is we don't know if it worked because it slowed-down the 10G side or because it had LRO disabling as a side-effect. If I were to guess, of those things listed, I'd guess that receive cko would have that as a side effect. Just what sort of 10G NIC was this anyway? With that knowledge we could probably narrow things down to a more specific modprobe setting, or maybe even an ethtool command, for some suitable revision of ethtool. rick jones Thanks for listening and re enforcing my search process. bryan At 01:32 PM 4/27/2007, Rick Jones wrote: Bryan Lawver wrote: Your right about the ipoib module not combining packets (I believed you without checking) but I did never the less. The ipoib_start_xmit routine is definitely handed a "double packet" which means that the IP NIC driver or the kernel is combining two packets into a single super jumbo packet. This issue is irrespective of the IP MTU setting because I have set all interfaces to 9000k yet ipoib accepts and forwards this 17964 packet to the next IB node and onto the TCP stack where it is never acknowledged. This may not have come up in prior testing because I am using some of the fastest IP NICs which have no trouble keeping up with or exceeding the bandwidth of the IB side. This issue arises exactly every 8 packets...(ring buffer overrun??) I will be at Sonoma for the next few days as many on this list will be. Some NICs (esp 10G) support large receive offload - they coalesce TCP segments from the wire/fiber into larger ones they pass up the stack. Perhaps that is happening here? I'm going to go out a bit on a limb, cross the streams, and include netdev, because I suspect that if a system is acting as an IP router, one doesn't want large receive offload enabled. That may need some discussion in netdev - it may then require some changes to default settings or some documentation enhancements. That or I'll learn that the stack is already dealing with the issue... rick jones bryan At 11:06 AM 4/26/2007, Michael S. Tsirkin wrote: > Quoting Bryan Lawver <[EMAIL PROTECTED]>: > Subject: Re: IPoIB forwarding > > Here's a tcpdump of the same sequence. The TCP MSS is 8960 and it appears > that two payloads are queued at ipoib which combines them into a single > 17920 payload with assumingly correct IP header (40) and IB header > (4). The application or TCP stack does not acknowledge this double packet > ie. it does not ACK until each of the 8960 packets are resent > individually. Being an IB newbie, I am guessing this combining is > allowable but may violate TCP protocol. IPoIB does nothing like this - it's just a network device so it sends all packets out as is. -- MST ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 ethernet bonding problems
Francois Romieu <[EMAIL PROTECTED]> : [...] > A tcpdump trace 1) before promiscuous mode 2) after promiscuous mode 3) > after link failure (i.e. failover does not work) would be welcome. A 'lspci -vx' will be needed too. There are different kinds of 8169. -- Ueimor Anybody got a battery for my Ultra 10 ? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8382] New: 2.6.20 cannot route packets outside tunnel
,On Fri, 27 Apr 2007 16:01:04 -0700 [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8382 > >Summary: 2.6.20 cannot route packets outside tunnel > Kernel Version: 2.6.20.9 > Status: NEW > Severity: high > Owner: [EMAIL PROTECTED] > Submitter: [EMAIL PROTECTED] > > > Most recent kernel where this bug did *NOT* occur: 2.6.19.7 > Distribution: Debian Etch 4.0 > Hardware Environment: i386 VIA Samuel 2 700mhz > Software Environment: Debian Etch > Problem Description: > > I am using an IPv6 tunnel broker (SixXs) which is using aiccu (dynamic IPv4 > address using heartbeat to get in sync with IPv6 tunnel to SixXS). When using > 2.6.20.x it doesn't route packets outside the tunnel anymore. This means that > from my gateway, i can ping my local interface and my remote one but not a > single other IPv6 address. > > When trying to traceroute or send IPv6 packets from any other machine on my > network to an outside IPv6 address, i keep getting a network unreachable > message. > > This was tested against 2.6.20.{5,7,8,9} and also 2.6.19.6/7. It works > perfectly > on any 2.6.19.x kernel or previous but fails under 2.6.20.x > > I made a diff in the IPv6 stack between 19 and 20 but my programming skills > are > clearly lacking :( > > Steps to reproduce: > > Compile with IPv6 settings that I am including with this bug report, 2.6.19 > works, 2.6.20 doesn't. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-2.6.21-ga205752d build #249 failed in net/rxrpc/rxkad.o:(.bss+0x0): multiple definition of `rxrpc_debug'
Toralf Förster <[EMAIL PROTECTED]> wrote: > net/rxrpc/rxkad.o:(.bss+0x0): multiple definition of `rxrpc_debug' > net/rxrpc/af-rxrpc.o:(.bss+0x10): first defined here I've submitted a patch that fixes that already. Subject: [PATCH 2/3] AF_RXRPC/AFS: Arch-specific fixes Though DaveM isn't keen on the way I did it, so there'll be another patch to change it. What I intend to do, I think, is to drop the #define of rxrpc_debug -> rxkad_debug and also to drop the definition of rxrpc_debug in rxkad.c. The rxrpc_debug in af_rxrpc.c can then be EXPORT_SYMBOL'd and shared between the two related modules. Unfortunately, it'll have to wait till later today to give me a chance to test it. David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: IPoIB forwarding
Bryan Lawver wrote: I had so much debugging turned on that it was not the "slowing of the traffic" but the "non-coelescencing" that was the remedy. The NIC is a MyriCom NIC and these are easy options to set. As chance would have it, I've played with some Myricom myri10ge NICs recently, and even disabled large receive offload during some netperf tests :) It is a modprobe option. Going back now to the driver source and the README I see :-) Troubleshooting === Large Receive Offload (LRO) is enabled by default. This will interfere with forwarding TCP traffic. If you plan to forward TCP traffic (using the host with the Myri10GE NIC as a router or bridge), you must disable LRO. To disable LRO, load the myri10ge driver with myri10ge_lro set to 0: # modprobe myri10ge myri10ge_lro=0 Alternatively, you can disable LRO at runtime by disabling receive checksum offloading via ethtool: # ethtool -K eth2 rx off rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: IPoIB forwarding
From: Rick Jones <[EMAIL PROTECTED]> Date: Fri, 27 Apr 2007 16:37:49 -0700 > Large Receive Offload (LRO) is enabled by default. This will > interfere with forwarding TCP traffic. If you plan to forward TCP > traffic (using the host with the Myri10GE NIC as a router or bridge), > you must disable LRO. To disable LRO, load the myri10ge driver > with myri10ge_lro set to 0: LRO should be disabled by default if the driver does this. This is a major and unacceptable bug. Thanks for pointing this out Rick. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: IPoIB forwarding
David Miller wrote: From: Rick Jones <[EMAIL PROTECTED]> Date: Fri, 27 Apr 2007 16:37:49 -0700 Large Receive Offload (LRO) is enabled by default. This will interfere with forwarding TCP traffic. If you plan to forward TCP traffic (using the host with the Myri10GE NIC as a router or bridge), you must disable LRO. To disable LRO, load the myri10ge driver with myri10ge_lro set to 0: LRO should be disabled by default if the driver does this. This is a major and unacceptable bug. Thanks for pointing this out Rick. No problem - just to play whatif/devil's advocate for a bit though... is there any way to tie that in with the setting of net.ipv4.ip_forward (and/or its IPv6 counterpart)? rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: IPoIB forwarding
From: Rick Jones <[EMAIL PROTECTED]> Date: Fri, 27 Apr 2007 16:48:00 -0700 > No problem - just to play whatif/devil's advocate for a bit > though... is there any way to tie that in with the setting of > net.ipv4.ip_forward (and/or its IPv6 counterpart)? Even ignoring that, consider the potential issues this kind of problem could be causing netfilter. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 09/11] forcedeth: improve NAPI logic
[EMAIL PROTECTED] wrote: From: Ingo Molnar <[EMAIL PROTECTED]> Another forcedeth.c thing: i noticed that its NAPI handler does not do tx-ring processing. The patch below implements this - tested on DESC_VER_2 hardware, with CONFIG_FORCEDETH_NAPI=y. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Cc: Ayaz Abdulla <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/forcedeth.c |8 1 file changed, 8 insertions(+) See thread comments -- this patch should be expanded. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] NetXen: Use multiple PCI functions
Mithlesh Thukral wrote: NetXen: Make driver use multiple PCI functions. This patch will make NetXen driver work with multiple PCI functions. This will make the usage of memory resources as well as interrupts more independent among different functions which results in better throughput. This change has been done after the multiport support is added in firmware. Signed-off by: Mithlesh Thukral <[EMAIL PROTECTED]> --- drivers/net/netxen/netxen_nic.h | 125 ++-- drivers/net/netxen/netxen_nic_ethtool.c | 83 +-- drivers/net/netxen/netxen_nic_hdr.h |8 drivers/net/netxen/netxen_nic_hw.c | 221 ++-- drivers/net/netxen/netxen_nic_hw.h | 18 drivers/net/netxen/netxen_nic_init.c | 117 +--- drivers/net/netxen/netxen_nic_isr.c | 87 +-- drivers/net/netxen/netxen_nic_main.c | 526 ++--- drivers/net/netxen/netxen_nic_niu.c | 27 - drivers/net/netxen/netxen_nic_phan_reg.h | 125 10 files changed, 646 insertions(+), 691 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 11/11] 3C509: Remove unnecessary include of
[EMAIL PROTECTED] wrote: From: "Robert P. J. Day" <[EMAIL PROTECTED]> Remove the apparently redundant include of . Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/3c509.c |1 - 1 file changed, 1 deletion(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ehea: fix for sysfs entries
Thomas Klein wrote: Create symbolic link from each logical port to ehea driver Signed-off-by: Thomas Klein <[EMAIL PROTECTED]> --- This patch applies on top of the netdev upstream branch for 2.6.22 applied 1-2 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sis900: Allocate rx replacement buffer before rx operation
Neil Horman wrote: On Tue, Apr 24, 2007 at 12:43:20PM -0400, Jeff Garzik wrote: Neil Horman wrote: Hey there- The sis900 driver appears to have a bug in which the receive routine passes the skbuff holding the received frame to the network stack before refilling the buffer in the rx ring. If a new skbuff cannot be allocated, the driver simply leaves a hole in the rx ring, which causes the driver to stop receiving frames and become non-recoverable without an rmmod/insmod according to reporters. This patch reverses that order, attempting to allocate a replacement buffer first, and receiving the new frame only if one can be allocated. If no skbuff can be allocated, the current skbuf in the rx ring is recycled, dropping the current frame, but keeping the NIC operational. Thanks & Regards Neil Just found a hole in my last patch. It was reported to me that shortly after we integrated this patch. The report was of an oops that took place inside of netif_rx when using the sis900 driver. Looking at my origional patch I noted that there was a spot between the new skb_alloc and the refill_rx_ring label where skb got reassigned to the pointer currently held in the rx_ring for the purposes of receiveing the frame. The result of this is however that the buffer that gets passed to netif_rx (if it is called), then gets placed right back into the rx_ring. So if you receive frames fast enough the skb being processed by the network stack can get corrupted. The reporter is testing out the fix I've written for this below (I'm not near my hardware at the moment to test myself), but I wanted to post it for review ASAP. I'll post test results when I hear them, but I think this is a pretty straightforward fix. It just uses a separate pointer to do the rx operation, so that we don't improperly reassign the pointer that we use to refill the rx ring. Thanks & Regards Neil Signed-off-by: Neil Horman <[EMAIL PROTECTED]> sis900.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/net/sis900.c b/drivers/net/sis900.c index a6a0f09..7e44939 100644 --- a/drivers/net/sis900.c +++ b/drivers/net/sis900.c @@ -1754,6 +1754,7 @@ static int sis900_rx(struct net_device *net_dev) sis_priv->rx_ring[entry].cmdsts = RX_BUF_SIZE; } else { struct sk_buff * skb; + struct sk_buff * rx_skb; pci_unmap_single(sis_priv->pci_dev, sis_priv->rx_ring[entry].bufptr, RX_BUF_SIZE, @@ -1787,10 +1788,10 @@ static int sis900_rx(struct net_device *net_dev) } /* give the socket buffer to upper layers */ - skb = sis_priv->rx_skbuff[entry]; - skb_put(skb, rx_size); - skb->protocol = eth_type_trans(skb, net_dev); - netif_rx(skb); + rx_skb = sis_priv->rx_skbuff[entry]; + skb_put(rx_skb, rx_size); + skb->protocol = eth_type_trans(rx_skb, net_dev); applied this, and the one-line fix to this - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb-net/pegasus: simplify carrier detection
Dan Williams wrote: Simplify pegasus carrier detection; rely only on the periodic MII polling. Reverts pieces of c43c49bd61fdb9bb085ddafcaadb17d06f95ec43. Signed-off-by: Dan Williams <[EMAIL PROTECTED]> --- a/drivers/usb/net/pegasus.h 2007-04-25 21:21:00.0 -0400 +++ b/drivers/usb/net/pegasus.h 2007-04-25 21:21:13.0 -0400 @@ -11,7 +11,6 @@ #define PEGASUS_II 0x8000 #defineHAS_HOME_PNA0x4000 -#defineTRUST_LINK_STATUS 0x2000 #define PEGASUS_MTU 1536 #defineRX_SKBS 4 @@ -204,7 +203,7 @@ PEGASUS_DEV( "Allied Telesyn Int. AT-USB100", VENDOR_ALLIEDTEL, 0xb100, DEFAULT_GPIO_RESET | PEGASUS_II ) PEGASUS_DEV( "Belkin F5D5050 USB Ethernet", VENDOR_BELKIN, 0x0121, - DEFAULT_GPIO_RESET | PEGASUS_II | TRUST_LINK_STATUS ) + DEFAULT_GPIO_RESET | PEGASUS_II ) PEGASUS_DEV( "Billionton USB-100", VENDOR_BILLIONTON, 0x0986, DEFAULT_GPIO_RESET ) PEGASUS_DEV( "Billionton USBLP-100", VENDOR_BILLIONTON, 0x0987, --- a/drivers/usb/net/pegasus.c 2007-04-25 21:20:32.0 -0400 +++ b/drivers/usb/net/pegasus.c 2007-04-25 21:22:15.0 -0400 @@ -848,16 +848,6 @@ * d[0].NO_CARRIER kicks in only with failed TX. * ... so monitoring with MII may be safest. */ - if (pegasus->features & TRUST_LINK_STATUS) { - if (d[5] & LINK_STATUS) - netif_carrier_on(net); - else - netif_carrier_off(net); - } else { - /* Never set carrier _on_ based on ! NO_CARRIER */ - if (d[0] & NO_CARRIER) - netif_carrier_off(net); - } /* bytes 3-4 == rx_lostpkt, reg 2E/2F */ pegasus->stats.rx_missed_errors += ((d[3] & 0x7f) << 8) | d[4]; applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 09/11] forcedeth: improve NAPI logic
On Fri, 27 Apr 2007 20:10:54 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > From: Ingo Molnar <[EMAIL PROTECTED]> > > > > Another forcedeth.c thing: i noticed that its NAPI handler does not do > > tx-ring processing. The patch below implements this - tested on DESC_VER_2 > > hardware, with CONFIG_FORCEDETH_NAPI=y. > > > > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> > > Cc: Ayaz Abdulla <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > --- > > > > drivers/net/forcedeth.c |8 > > 1 file changed, 8 insertions(+) > > See thread comments -- this patch should be expanded. > yeah, I added the comments to the changelog for you all to read next time I send it ;) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 02/11] vioc-warning-fix
[EMAIL PROTECTED] wrote: From: Andrew Morton <[EMAIL PROTECTED]> Fix this, on i386: drivers/net/vioc/vioc_transmit.c: In function 'vioc_tx_interrupt': drivers/net/vioc/vioc_transmit.c:387: warning: cast from pointer to integer of different size I dunno what the driver is trying to do here, but it looks unpleasant. Cc: Sriram Chidambaram <[EMAIL PROTECTED]> Cc: Fabric7 Driver-Support <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/vioc/vioc_vnic.h |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) applied these three vioc patches - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 08/11] add NAPI support to sb1250-mac.c
[EMAIL PROTECTED] wrote: From: Mark Mason <[EMAIL PROTECTED]> Patch to add NAPI support to sb1250-mac.c (rev 2). This patch differs from the last in that the NAPI support isn't marked as experimental, nor is it configurable (ie. once applied - NAPI is enabled all the time). This was based on feedback from Ralf and others. Signed-off-by: Mark Mason <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/sb1250-mac.c | 273 - 1 file changed, 180 insertions(+), 93 deletions(-) applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic HDLC sparse annotations
Krzysztof Halasa wrote: Sparse annotations, including two minor bugfixes. Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] e1000: ROUND_UP macro cleanup in drivers/net/e1000
Auke Kok wrote: From: Milind Arun Choudhary <[EMAIL PROTECTED]> E1000_ROUNDUP macro cleanup, use ALIGN Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]> Signed-off-by: Auke Kok <[EMAIL PROTECTED]> --- drivers/net/e1000/e1000.h |3 --- drivers/net/e1000/e1000_ethtool.c |6 +++--- drivers/net/e1000/e1000_main.c| 10 +- drivers/net/e1000/e1000_param.c |4 ++-- 4 files changed, 10 insertions(+), 13 deletions(-) applied this and the ixgb one - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[git patches] net driver fixes
As mentioned previously, the big batch queued for 2.6.22 is coming after the dust settles. [EMAIL PROTECTED] folks: the sis900 patch should be in 2.6.21.x Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus to receive the following updates: drivers/net/sis900.c |9 + drivers/usb/net/pegasus.c | 10 -- drivers/usb/net/pegasus.h |3 +-- 3 files changed, 6 insertions(+), 16 deletions(-) Dan Williams (1): usb-net/pegasus: simplify carrier detection Neil Horman (1): sis900: Allocate rx replacement buffer before rx operation diff --git a/drivers/net/sis900.c b/drivers/net/sis900.c index dea0126..2cb2e15 100644 --- a/drivers/net/sis900.c +++ b/drivers/net/sis900.c @@ -1753,6 +1753,7 @@ static int sis900_rx(struct net_device *net_dev) sis_priv->rx_ring[entry].cmdsts = RX_BUF_SIZE; } else { struct sk_buff * skb; + struct sk_buff * rx_skb; pci_unmap_single(sis_priv->pci_dev, sis_priv->rx_ring[entry].bufptr, RX_BUF_SIZE, @@ -1786,10 +1787,10 @@ static int sis900_rx(struct net_device *net_dev) } /* give the socket buffer to upper layers */ - skb = sis_priv->rx_skbuff[entry]; - skb_put(skb, rx_size); - skb->protocol = eth_type_trans(skb, net_dev); - netif_rx(skb); + rx_skb = sis_priv->rx_skbuff[entry]; + skb_put(rx_skb, rx_size); + rx_skb->protocol = eth_type_trans(rx_skb, net_dev); + netif_rx(rx_skb); /* some network statistics */ if ((rx_status & BCAST) == MCAST) diff --git a/drivers/usb/net/pegasus.c b/drivers/usb/net/pegasus.c index 1ad4ee5..a05fd97 100644 --- a/drivers/usb/net/pegasus.c +++ b/drivers/usb/net/pegasus.c @@ -847,16 +847,6 @@ static void intr_callback(struct urb *urb) * d[0].NO_CARRIER kicks in only with failed TX. * ... so monitoring with MII may be safest. */ - if (pegasus->features & TRUST_LINK_STATUS) { - if (d[5] & LINK_STATUS) - netif_carrier_on(net); - else - netif_carrier_off(net); - } else { - /* Never set carrier _on_ based on ! NO_CARRIER */ - if (d[0] & NO_CARRIER) - netif_carrier_off(net); - } /* bytes 3-4 == rx_lostpkt, reg 2E/2F */ pegasus->stats.rx_missed_errors += ((d[3] & 0x7f) << 8) | d[4]; diff --git a/drivers/usb/net/pegasus.h b/drivers/usb/net/pegasus.h index c7aadb4..c746782 100644 --- a/drivers/usb/net/pegasus.h +++ b/drivers/usb/net/pegasus.h @@ -11,7 +11,6 @@ #definePEGASUS_II 0x8000 #defineHAS_HOME_PNA0x4000 -#defineTRUST_LINK_STATUS 0x2000 #definePEGASUS_MTU 1536 #defineRX_SKBS 4 @@ -204,7 +203,7 @@ PEGASUS_DEV( "AEI USB Fast Ethernet Adapter", VENDOR_AEILAB, 0x1701, PEGASUS_DEV( "Allied Telesyn Int. AT-USB100", VENDOR_ALLIEDTEL, 0xb100, DEFAULT_GPIO_RESET | PEGASUS_II ) PEGASUS_DEV( "Belkin F5D5050 USB Ethernet", VENDOR_BELKIN, 0x0121, - DEFAULT_GPIO_RESET | PEGASUS_II | TRUST_LINK_STATUS ) + DEFAULT_GPIO_RESET | PEGASUS_II ) PEGASUS_DEV( "Billionton USB-100", VENDOR_BILLIONTON, 0x0986, DEFAULT_GPIO_RESET ) PEGASUS_DEV( "Billionton USBLP-100", VENDOR_BILLIONTON, 0x0987, - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fabric7 VIOC driver going away
It looks like Fabric7 has gone out of business, and the maintainer works elsewhere, so I'm no longer inclined to merge it into the upstream kernel. Yell now, if there is a contigent of Fabric7 users that still want this. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Slow tcp handshakes rate of 2.6.20 and 2.6.19
Hi, In these days I met a strange situation, tcp handshake rate is slow after 2.6.18.8. The case is, server accepts connections, and records number of successful tcp handshakes during last 10 seconds. Client tries to connect to server's listen port as fast as possible and as many as possible, or in simple words, client use connect() to flood the server. In both cases, there are a log of syn re-send. Server's performances varied much, depending on which kernel it was running. On 2.6.18.8, 1 successful connections take about 30-40 seconds, while on 2.6.20 or 2.6.19, it will cost about more than 5 minutes. It seems there is some a mechanism which prevents connect() flood. My problem is, is the mechanism exist, or there is some other reason(s) for why 2.6.18 varies from 2.6.19/2.6.20? All these config files are all the same, tcp related options are, CONFIG_INET_TCP_DIAG=m CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_CUBIC=m CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m CONFIG_IP_VS_PROTO_TCP=y CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_IP_NF_TARGET_TCPMSS=m -- Quan Sun - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Slow tcp handshakes rate of 2.6.20 and 2.6.19
On 4/28/07, Quan Sun <[EMAIL PROTECTED]> wrote: Hi, In these days I met a strange situation, tcp handshake rate is slow after 2.6.18.8. The case is, server accepts connections, and records number of successful tcp handshakes during last 10 seconds. Client tries to connect to server's listen port as fast as possible and as many as possible, or in simple words, client use connect() to flood the server. In both cases, there are a log of syn re-send. Server's performances varied much, depending on which kernel it was running. On 2.6.18.8, 1 successful connections take about 30-40 seconds, while on 2.6.20 or 2.6.19, it will cost about more than 5 minutes. Please, look at this by pressing next_in_thread: http://marc.info/?l=linux-netdev&m=117664202416020&w=2 What are the #cat /proc/sys/net/ipv4/tcp_mem values for your kernels? Do you see tcp memory pressure by #netstat -s ? Sincerely, Robert Iakobashvili, coroberti %x40 gmail %x2e com ... Navigare necesse est, vivere non est necesse ... http://curl-loader.sourceforge.net An open-source HTTP/S, FTP/S traffic generating, and web testing tool. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET]: Get rid of NETIF_F_INTERNAL_STATS
On Wed, 2007-04-11 at 22:23 +1000, Herbert Xu wrote: > On Wed, Apr 11, 2007 at 10:15:51PM +1000, Rusty Russell wrote: > > > > Actually, I did this precisely because I really didn't want to start > > exposing bogus stats in /proc/net/dev. An audit might clarify if this > > is an actual issue. > > Fair enough. Still returning zeros when get_stats isn't available > would seem safe enough. I wasn't able to find any drivers which > didn't have get_stats. OK, I did a quick check, and the only one I could find was br_if.c which calls register_netdevice() and doesn't set get_stats. I don't think that zeroes in this case matters. So here's a patch inspired by Herbert's patch, but also gets all those places which I modified previously to check for get_stats returning NULL. == Remove NETIF_F_INTERNAL_STATS: default to internal stats. Herbert Xu conviced me that a new flag was overkill; every driver currently overrides get_stats, so we might as well make the internal one the default. If someone did fail to set get_stats, they would now get all 0 stats instead of "No statistics available". Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> diff -r ceab3c131ee5 arch/s390/appldata/appldata_net_sum.c --- a/arch/s390/appldata/appldata_net_sum.c Sat Apr 28 14:39:41 2007 +1000 +++ b/arch/s390/appldata/appldata_net_sum.c Sat Apr 28 15:09:46 2007 +1000 @@ -109,9 +109,6 @@ static void appldata_get_net_sum_data(vo read_lock(&dev_base_lock); for (dev = dev_base; dev != NULL; dev = dev->next) { stats = dev->get_stats(dev); - if (stats == NULL) { - continue; - } rx_packets += stats->rx_packets; tx_packets += stats->tx_packets; rx_bytes += stats->rx_bytes; diff -r ceab3c131ee5 drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Sat Apr 28 14:39:41 2007 +1000 +++ b/drivers/net/bonding/bond_main.c Sat Apr 28 15:10:24 2007 +1000 @@ -1360,13 +1360,6 @@ int bond_enslave(struct net_device *bond goto err_undo_flags; } - if (slave_dev->get_stats == NULL) { - printk(KERN_NOTICE DRV_NAME - ": %s: the driver for slave device %s does not provide " - "get_stats function, network statistics will be " - "inaccurate.\n", bond_dev->name, slave_dev->name); - } - new_slave = kzalloc(sizeof(struct slave), GFP_KERNEL); if (!new_slave) { res = -ENOMEM; @@ -3641,33 +3634,31 @@ static struct net_device_stats *bond_get bond_for_each_slave(bond, slave, i) { sstats = slave->dev->get_stats(slave->dev); - if (sstats) { - stats->rx_packets += sstats->rx_packets; - stats->rx_bytes += sstats->rx_bytes; - stats->rx_errors += sstats->rx_errors; - stats->rx_dropped += sstats->rx_dropped; - - stats->tx_packets += sstats->tx_packets; - stats->tx_bytes += sstats->tx_bytes; - stats->tx_errors += sstats->tx_errors; - stats->tx_dropped += sstats->tx_dropped; - - stats->multicast += sstats->multicast; - stats->collisions += sstats->collisions; - - stats->rx_length_errors += sstats->rx_length_errors; - stats->rx_over_errors += sstats->rx_over_errors; - stats->rx_crc_errors += sstats->rx_crc_errors; - stats->rx_frame_errors += sstats->rx_frame_errors; - stats->rx_fifo_errors += sstats->rx_fifo_errors; - stats->rx_missed_errors += sstats->rx_missed_errors; - - stats->tx_aborted_errors += sstats->tx_aborted_errors; - stats->tx_carrier_errors += sstats->tx_carrier_errors; - stats->tx_fifo_errors += sstats->tx_fifo_errors; - stats->tx_heartbeat_errors += sstats->tx_heartbeat_errors; - stats->tx_window_errors += sstats->tx_window_errors; - } + stats->rx_packets += sstats->rx_packets; + stats->rx_bytes += sstats->rx_bytes; + stats->rx_errors += sstats->rx_errors; + stats->rx_dropped += sstats->rx_dropped; + + stats->tx_packets += sstats->tx_packets; + stats->tx_bytes += sstats->tx_bytes; + stats->tx_errors += sstats->tx_errors; + stats->tx_dropped += sstats->tx_dropped; + + stats->multicast += sstats->multicast; + stats->collisions += sstats->collisions; + + stats->rx_length_errors += sstats->rx_length_errors; + stats->rx_over_errors += sstats->rx_over_errors; + stats->rx_crc_erro
[RESEND] [PATCH v2] [0/5] pasemi_mac: fixes and enhancements
Hi, The five following patches contain a number of fixes and improvements of the pasemi_mac driver: 1/5: A couple of minor bugfixes. 2/5: Move the IRQ mapping from the PCI layer under our platform, to the driver. 3/5: A rather large patch with various NAPI/performance-related fixes and enhancements. 4/5: phy support 5/5: use local-mac-address instead of mac-address if available. (Changes from last time: Added 5/5, changes to 2/5 to use virq_to_hw()). -Olof - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] [PATCH v2] [1/5] pasemi_mac: minor bugfixes
Ethernet bugfixes: * Move the was_full/wake_queue logic from tx_intr to clean_tx * Fix polarity in checks in pasemi_mac_close Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Index: linux-2.6/drivers/net/pasemi_mac.c === --- linux-2.6.orig/drivers/net/pasemi_mac.c +++ linux-2.6/drivers/net/pasemi_mac.c @@ -451,9 +451,12 @@ static int pasemi_mac_clean_tx(struct pa struct pas_dma_xct_descr *dp; int start, count; int flags; + int was_full; spin_lock_irqsave(&mac->tx->lock, flags); + was_full = mac->tx->next_to_clean - mac->tx->next_to_use == TX_RING_SIZE; + start = mac->tx->next_to_clean; count = 0; @@ -478,6 +481,9 @@ static int pasemi_mac_clean_tx(struct pa mac->tx->next_to_clean += count; spin_unlock_irqrestore(&mac->tx->lock, flags); + if (was_full) + netif_wake_queue(mac->netdev); + return count; } @@ -512,9 +518,6 @@ static irqreturn_t pasemi_mac_tx_intr(in struct net_device *dev = data; struct pasemi_mac *mac = netdev_priv(dev); unsigned int reg; - int was_full; - - was_full = mac->tx->next_to_clean - mac->tx->next_to_use == TX_RING_SIZE; if (!(*mac->tx_status & PAS_STATUS_INT)) return IRQ_NONE; @@ -528,9 +531,6 @@ static irqreturn_t pasemi_mac_tx_intr(in pci_write_config_dword(mac->iob_pdev, PAS_IOB_DMA_TXCH_RESET(mac->dma_txch), reg); - if (was_full) - netif_wake_queue(dev); - return IRQ_HANDLED; } @@ -662,40 +665,37 @@ static int pasemi_mac_close(struct net_d pci_read_config_dword(mac->dma_pdev, PAS_DMA_TXCHAN_TCMDSTA(mac->dma_txch), &stat); - if (stat & PAS_DMA_TXCHAN_TCMDSTA_ACT) + if (!(stat & PAS_DMA_TXCHAN_TCMDSTA_ACT)) break; cond_resched(); } - if (!(stat & PAS_DMA_TXCHAN_TCMDSTA_ACT)) { + if (stat & PAS_DMA_TXCHAN_TCMDSTA_ACT) dev_err(&mac->dma_pdev->dev, "Failed to stop tx channel\n"); - } for (retries = 0; retries < MAX_RETRIES; retries++) { pci_read_config_dword(mac->dma_pdev, PAS_DMA_RXCHAN_CCMDSTA(mac->dma_rxch), &stat); - if (stat & PAS_DMA_RXCHAN_CCMDSTA_ACT) + if (!(stat & PAS_DMA_RXCHAN_CCMDSTA_ACT)) break; cond_resched(); } - if (!(stat & PAS_DMA_RXCHAN_CCMDSTA_ACT)) { + if (stat & PAS_DMA_RXCHAN_CCMDSTA_ACT) dev_err(&mac->dma_pdev->dev, "Failed to stop rx channel\n"); - } for (retries = 0; retries < MAX_RETRIES; retries++) { pci_read_config_dword(mac->dma_pdev, PAS_DMA_RXINT_RCMDSTA(mac->dma_if), &stat); - if (stat & PAS_DMA_RXINT_RCMDSTA_ACT) + if (!(stat & PAS_DMA_RXINT_RCMDSTA_ACT)) break; cond_resched(); } - if (!(stat & PAS_DMA_RXINT_RCMDSTA_ACT)) { + if (stat & PAS_DMA_RXINT_RCMDSTA_ACT) dev_err(&mac->dma_pdev->dev, "Failed to stop rx interface\n"); - } /* Then, disable the channel. This must be done separately from * stopping, since you can't disable when active. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] [PATCH v2] [2/5] pasemi_mac: irq mapping changes
Fixes for ethernet IRQ mapping, to be done in the driver instead of in the platform setup code. Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Index: powerpc/arch/powerpc/platforms/pasemi/pci.c === --- powerpc.orig/arch/powerpc/platforms/pasemi/pci.c +++ powerpc/arch/powerpc/platforms/pasemi/pci.c @@ -163,19 +163,6 @@ static void __init pas_fixup_phb_resourc } -void __devinit pas_pci_irq_fixup(struct pci_dev *dev) -{ - /* DMA is special, 84 interrupts (128 -> 211), all but 128 -* need to be mapped by hand here. -*/ - if (dev->vendor == 0x1959 && dev->device == 0xa007) { - int i; - for (i = 129; i < 212; i++) - irq_create_mapping(NULL, i); - } -} - - void __init pas_pci_init(void) { struct device_node *np, *root; Index: powerpc/arch/powerpc/platforms/pasemi/setup.c === --- powerpc.orig/arch/powerpc/platforms/pasemi/setup.c +++ powerpc/arch/powerpc/platforms/pasemi/setup.c @@ -240,5 +240,4 @@ define_machine(pas) { .check_legacy_ioport= pas_check_legacy_ioport, .progress = pas_progress, .machine_check_exception = pas_machine_check_handler, - .pci_irq_fixup = pas_pci_irq_fixup, }; Index: powerpc/drivers/net/pasemi_mac.c === --- powerpc.orig/drivers/net/pasemi_mac.c +++ powerpc/drivers/net/pasemi_mac.c @@ -33,6 +33,8 @@ #include #include +#include + #include "pasemi_mac.h" @@ -537,6 +539,7 @@ static irqreturn_t pasemi_mac_tx_intr(in static int pasemi_mac_open(struct net_device *dev) { struct pasemi_mac *mac = netdev_priv(dev); + int base_irq; unsigned int flags; int ret; @@ -600,28 +603,37 @@ static int pasemi_mac_open(struct net_de netif_start_queue(dev); netif_poll_enable(dev); - ret = request_irq(mac->dma_pdev->irq + mac->dma_txch, - &pasemi_mac_tx_intr, IRQF_DISABLED, + /* Interrupts are a bit different for our DMA controller: While +* it's got one a regular PCI device header, the interrupt there +* is really the base of the range it's using. Each tx and rx +* channel has it's own interrupt source. +*/ + + base_irq = virq_to_hw(mac->dma_pdev->irq); + + mac->tx_irq = irq_create_mapping(NULL, base_irq + mac->dma_txch); + mac->rx_irq = irq_create_mapping(NULL, base_irq + 20 + mac->dma_txch); + + ret = request_irq(mac->tx_irq, &pasemi_mac_tx_intr, IRQF_DISABLED, mac->tx->irq_name, dev); if (ret) { dev_err(&mac->pdev->dev, "request_irq of irq %d failed: %d\n", - mac->dma_pdev->irq + mac->dma_txch, ret); + base_irq + mac->dma_txch, ret); goto out_tx_int; } - ret = request_irq(mac->dma_pdev->irq + 20 + mac->dma_rxch, - &pasemi_mac_rx_intr, IRQF_DISABLED, + ret = request_irq(mac->rx_irq, &pasemi_mac_rx_intr, IRQF_DISABLED, mac->rx->irq_name, dev); if (ret) { dev_err(&mac->pdev->dev, "request_irq of irq %d failed: %d\n", - mac->dma_pdev->irq + 20 + mac->dma_rxch, ret); + base_irq + 20 + mac->dma_rxch, ret); goto out_rx_int; } return 0; out_rx_int: - free_irq(mac->dma_pdev->irq + mac->dma_txch, dev); + free_irq(mac->tx_irq, dev); out_tx_int: netif_poll_disable(dev); netif_stop_queue(dev); @@ -705,8 +717,8 @@ static int pasemi_mac_close(struct net_d pci_write_config_dword(mac->dma_pdev, PAS_DMA_RXINT_RCMDSTA(mac->dma_if), 0); - free_irq(mac->dma_pdev->irq + mac->dma_txch, dev); - free_irq(mac->dma_pdev->irq + 20 + mac->dma_rxch, dev); + free_irq(mac->tx_irq, dev); + free_irq(mac->rx_irq, dev); /* Free resources */ pasemi_mac_free_rx_resources(dev); Index: powerpc/drivers/net/pasemi_mac.h === --- powerpc.orig/drivers/net/pasemi_mac.h +++ powerpc/drivers/net/pasemi_mac.h @@ -73,6 +73,8 @@ struct pasemi_mac { struct pasemi_mac_txring *tx; struct pasemi_mac_rxring *rx; + unsigned long tx_irq; + unsigned long rx_irq; }; /* Software status descriptor (desc_info) */ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] [PATCH v2] [3/5] pasemi_mac: cleanups and rx performance improvements
NAPI fixes and cleanups for pasemi_mac: * Timer changes/fixes * Abstract out the rx intr restart to a separate function * Similar function for tx intr to reset to a known clear state even if firmware used the same interface * Add a copy-break and recycle the SKB in the driver for small packets * Other minor changes to rx path Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Index: powerpc/drivers/net/pasemi_mac.c === --- powerpc.orig/drivers/net/pasemi_mac.c +++ powerpc/drivers/net/pasemi_mac.c @@ -61,12 +61,6 @@ #define BUF_SIZE 1646 /* 1500 MTU + ETH_HLEN + VLAN_HLEN + 2 64B cachelines */ -/* XXXOJN these should come out of the device tree some day */ -#define PAS_DMA_CAP_BASE 0xe00d0040 -#define PAS_DMA_CAP_SIZE 0x100 -#define PAS_DMA_COM_BASE 0xe00d0100 -#define PAS_DMA_COM_SIZE 0x100 - static struct pasdma_status *dma_status; static int pasemi_get_mac_addr(struct pasemi_mac *mac) @@ -279,8 +273,8 @@ static void pasemi_mac_free_rx_resources for (i = 0; i < RX_RING_SIZE; i++) { info = &RX_DESC_INFO(mac, i); dp = &RX_DESC(mac, i); - if (info->dma) { - if (info->skb) { + if (info->skb) { + if (info->dma) { pci_unmap_single(mac->dma_pdev, info->dma, info->skb->len, @@ -311,84 +305,122 @@ static void pasemi_mac_replenish_rx_ring struct pasemi_mac *mac = netdev_priv(dev); unsigned int i; int start = mac->rx->next_to_fill; - unsigned int count; + unsigned int limit, count; - count = (mac->rx->next_to_clean + RX_RING_SIZE - + limit = (mac->rx->next_to_clean + RX_RING_SIZE - mac->rx->next_to_fill) & (RX_RING_SIZE - 1); /* Check to see if we're doing first-time setup */ if (unlikely(mac->rx->next_to_clean == 0 && mac->rx->next_to_fill == 0)) - count = RX_RING_SIZE; + limit = RX_RING_SIZE; - if (count <= 0) + if (limit <= 0) return; - for (i = start; i < start + count; i++) { + i = start; + + for (count = limit; count; count--) { struct pasemi_mac_buffer *info = &RX_DESC_INFO(mac, i); u64 *buff = &RX_BUFF(mac, i); struct sk_buff *skb; dma_addr_t dma; - skb = dev_alloc_skb(BUF_SIZE); + /* skb might still be in there for recycle on short receives */ + if (info->skb) + skb = info->skb; + else + skb = dev_alloc_skb(BUF_SIZE); - if (!skb) { - count = i - start; + if (unlikely(!skb)) break; - } skb->dev = dev; dma = pci_map_single(mac->dma_pdev, skb->data, skb->len, PCI_DMA_FROMDEVICE); - if (dma_mapping_error(dma)) { + if (unlikely(dma_mapping_error(dma))) { dev_kfree_skb_irq(info->skb); - count = i - start; break; } info->skb = skb; info->dma = dma; *buff = XCT_RXB_LEN(BUF_SIZE) | XCT_RXB_ADDR(dma); + i++; } wmb(); pci_write_config_dword(mac->dma_pdev, PAS_DMA_RXCHAN_INCR(mac->dma_rxch), - count); + limit - count); pci_write_config_dword(mac->dma_pdev, PAS_DMA_RXINT_INCR(mac->dma_if), - count); + limit - count); + + mac->rx->next_to_fill += limit - count; +} + +static void pasemi_mac_restart_rx_intr(struct pasemi_mac *mac) +{ + unsigned int reg, stat; + /* Re-enable packet count interrupts: finally +* ack the packet count interrupt we got in rx_intr. +*/ + + pci_read_config_dword(mac->iob_pdev, + PAS_IOB_DMA_RXCH_STAT(mac->dma_rxch), + &stat); + + reg = PAS_IOB_DMA_RXCH_RESET_PCNT(stat & PAS_IOB_DMA_RXCH_STAT_CNTDEL_M) | + PAS_IOB_DMA_RXCH_RESET_PINTC; + + pci_write_config_dword(mac->iob_pdev, + PAS_IOB_DMA_RXCH_RESET(mac->dma_rxch), + reg); +} + +static void pasemi_mac_restart_tx_intr(struct pasemi_mac *mac) +{ + unsigned int reg, stat; - mac->rx->next_to_fill += count; + /* Re-enable packet count interrupts */ + pci_read_config_dword(mac->iob_pdev, + PAS_IOB_DMA_TXCH_STAT(mac->dma_txch), &stat
[RESEND] [PATCH v2] [4/5] pasemi_mac: phy support
PHY support for pasemi_mac. Also add msg_enable flags for future disablement of the link messages. Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Index: powerpc/drivers/net/pasemi_mac.c === --- powerpc.orig/drivers/net/pasemi_mac.c +++ powerpc/drivers/net/pasemi_mac.c @@ -594,6 +592,110 @@ static irqreturn_t pasemi_mac_tx_intr(in return IRQ_HANDLED; } +static void pasemi_adjust_link(struct net_device *dev) +{ + struct pasemi_mac *mac = netdev_priv(dev); + int msg; + unsigned int flags; + unsigned int new_flags; + + if (!mac->phydev->link) { + /* If no link, MAC speed settings don't matter. Just report +* link down and return. +*/ + if (mac->link && netif_msg_link(mac)) + printk(KERN_INFO "%s: Link is down.\n", dev->name); + + netif_carrier_off(dev); + mac->link = 0; + + return; + } else + netif_carrier_on(dev); + + pci_read_config_dword(mac->pdev, PAS_MAC_CFG_PCFG, &flags); + new_flags = flags & ~(PAS_MAC_CFG_PCFG_HD | PAS_MAC_CFG_PCFG_SPD_M); + + if (!mac->phydev->duplex) + new_flags |= PAS_MAC_CFG_PCFG_HD; + + switch (mac->phydev->speed) { + case 1000: + new_flags |= PAS_MAC_CFG_PCFG_SPD_1G; + break; + case 100: + new_flags |= PAS_MAC_CFG_PCFG_SPD_100M; + break; + case 10: + new_flags |= PAS_MAC_CFG_PCFG_SPD_10M; + break; + default: + printk("Unsupported speed %d\n", mac->phydev->speed); + } + + /* Print on link or speed/duplex change */ + msg = mac->link != mac->phydev->link || flags != new_flags; + + mac->duplex = mac->phydev->duplex; + mac->speed = mac->phydev->speed; + mac->link = mac->phydev->link; + + if (new_flags != flags) + pci_write_config_dword(mac->pdev, PAS_MAC_CFG_PCFG, new_flags); + + if (msg && netif_msg_link(mac)) + printk(KERN_INFO "%s: Link is up at %d Mbps, %s duplex.\n", + dev->name, mac->speed, mac->duplex ? "full" : "half"); +} + +static int pasemi_mac_phy_init(struct net_device *dev) +{ + struct pasemi_mac *mac = netdev_priv(dev); + struct device_node *dn, *phy_dn; + struct phy_device *phydev; + unsigned int phy_id; + const phandle *ph; + const unsigned int *prop; + struct resource r; + int ret; + + dn = pci_device_to_OF_node(mac->pdev); + ph = get_property(dn, "phy-handle", NULL); + if (!ph) + return -ENODEV; + phy_dn = of_find_node_by_phandle(*ph); + + prop = get_property(phy_dn, "reg", NULL); + ret = of_address_to_resource(phy_dn->parent, 0, &r); + if (ret) + goto err; + + phy_id = *prop; + snprintf(mac->phy_id, BUS_ID_SIZE, PHY_ID_FMT, (int)r.start, phy_id); + + of_node_put(phy_dn); + + mac->link = 0; + mac->speed = 0; + mac->duplex = -1; + + phydev = phy_connect(dev, mac->phy_id, &pasemi_adjust_link, 0, PHY_INTERFACE_MODE_SGMII); + + if (IS_ERR(phydev)) { + printk(KERN_ERR "%s: Could not attach to phy\n", dev->name); + return PTR_ERR(phydev); + } + + mac->phydev = phydev; + + return 0; + +err: + of_node_put(phy_dn); + return -ENODEV; +} + + static int pasemi_mac_open(struct net_device *dev) { struct pasemi_mac *mac = netdev_priv(dev); @@ -667,6 +769,13 @@ static int pasemi_mac_open(struct net_de pasemi_mac_replenish_rx_ring(dev); + ret = pasemi_mac_phy_init(dev); + /* Some configs don't have PHYs (XAUI etc), so don't complain about +* failed init due to -ENODEV. +*/ + if (ret && ret != -ENODEV) + dev_warn(&mac->pdev->dev, "phy init failed: %d\n", ret); + netif_start_queue(dev); netif_poll_enable(dev); @@ -697,6 +806,9 @@ static int pasemi_mac_open(struct net_de goto out_rx_int; } + if (mac->phydev) + phy_start(mac->phydev); + return 0; out_rx_int: @@ -720,6 +832,11 @@ static int pasemi_mac_close(struct net_d unsigned int stat; int retries; + if (mac->phydev) { + phy_stop(mac->phydev); + phy_disconnect(mac->phydev); + } + netif_stop_queue(dev); /* Clean out any pending buffers */ @@ -1013,6 +1130,9 @@ pasemi_mac_probe(struct pci_dev *pdev, c mac->rx_status = &dma_status->rx_sta[mac->dma_rxch]; mac->tx_status = &dma_status->tx_sta[mac->dma_txch]; + /* Enable most messages by default */ + mac->msg_enable = (NETIF_MSG_IFUP << 1 ) - 1; + err = register_netdev(dev); if (err) { Index: powerpc/dri
[RESEND] [PATCH v2] [5/5] pasemi_mac: use local-mac-address
Use local-mac-address in the device tree instead. Fall back to mac-address for older firmware. Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> Index: powerpc/drivers/net/pasemi_mac.c === --- powerpc.orig/drivers/net/pasemi_mac.c +++ powerpc/drivers/net/pasemi_mac.c @@ -74,7 +74,12 @@ static int pasemi_get_mac_addr(struct pa return -ENOENT; } - maddr = get_property(dn, "mac-address", NULL); + maddr = get_property(dn, "local-mac-address", NULL); + + /* Fall back to mac-address for older firmware */ + if (maddr == NULL) + maddr = get_property(dn, "mac-address", NULL); + if (maddr == NULL) { dev_warn(&pdev->dev, "no mac address in device tree, not configuring\n"); - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET]: Get rid of NETIF_F_INTERNAL_STATS
On Sat, Apr 28, 2007 at 03:46:01PM +1000, Rusty Russell wrote: > > OK, I did a quick check, and the only one I could find was br_if.c which > calls register_netdevice() and doesn't set get_stats. I don't think > that zeroes in this case matters. Thanks for following up on this Rusty! Actually I just had a look at br_if.c and it seems that it does set get_stats through br_dev_setup to br_dev_get_stats. > == > Remove NETIF_F_INTERNAL_STATS: default to internal stats. > > Herbert Xu conviced me that a new flag was overkill; every driver > currently overrides get_stats, so we might as well make the internal > one the default. If someone did fail to set get_stats, they would now > get all 0 stats instead of "No statistics available". > > Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> Looks good to me. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: IPoIB forwarding
On Fri, 27 Apr 2007, Rick Jones wrote: > Bryan Lawver wrote: > > I had so much debugging turned on that it was not the "slowing of the > > traffic" but the "non-coelescencing" that was the remedy. The NIC is a > > MyriCom NIC and these are easy options to set. > > As chance would have it, I've played with some Myricom myri10ge NICs > recently, > and even disabled large receive offload during some netperf tests :) It is a > modprobe option. Going back now to the driver source and the README I see :-) > > > > Troubleshooting > === > > Large Receive Offload (LRO) is enabled by default. This will > interfere with forwarding TCP traffic. If you plan to forward TCP > traffic (using the host with the Myri10GE NIC as a router or bridge), > you must disable LRO. To disable LRO, load the myri10ge driver > with myri10ge_lro set to 0: > > # modprobe myri10ge myri10ge_lro=0 > > Alternatively, you can disable LRO at runtime by disabling > receive checksum offloading via ethtool: > > # ethtool -K eth2 rx off > > > > rick jones What version of the myri10ge driver is this? With the 1.2.0 version that comes with the 2.6.20.7 kernel, there is no myri10ge_lro module parameter. [EMAIL PROTECTED] ~]# modinfo myri10ge | grep -i lro [EMAIL PROTECTED] ~]# And I've been testing IP forwarding using two Myricom 10-GigE NICs without setting any special modprobe parameters. -Bill - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html