how to determine IP address within network device driver?

[Nic Gyrovague]

(apologies for the repost, I thought people may have missed this
question since it was not phrased as such)

I have a hw network device that can benefit from knowing what its
associated IP addresses (if any) are... Is there a correct way to
determine the IP address(es) from within the driver code?

Its obviously possible to snoop into ARP
and IP traffic to try to guess, but this is not always 100% reliable
(e.g. with bridging) and also only gives you the IP address once packets
have started flowing...

In other words, if userspace sets/changes or adds (e.g. IP alias) an
IP address to the device (e.g. ifconfig eth0  192.168.1.5), I'd like
to somehow be informed of that within my driver, or failing that, be
able to somehow poll a kernel structure or API to determine said
information...

--
gyrovague
-
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: fix-slab-corruption-running-ip6sic.patch

[Jarek Poplawski]

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: [PATCH 6/6] [IPV4] SNMP: Display new statistics at /proc/net/snmp

[Mitsuru Chinen]

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 ...

[Bill Fink]

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

[PATCH] SMC on pxa3xx (was: pxa3xx base patch [5/5] - net)

[dmitry pervushin]

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?

[David Miller]

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)

[Lennert Buytenhek]

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?

[YOSHIFUJI Hideaki / 吉藤英明]

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?

[David Miller]

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

[Gerrit Renker]

[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

[Vitaly Wool]

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_ | ((28)  
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

[Vitaly Wool]

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 linux/netdevice.h
 #include linux/etherdevice.h
 #include linux/skbuff.h
+#include linux/irq.h
 
 #include asm/io.h
-#include asm/irq.h
 
 #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]

[Ingo Oeser]

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 Howells]

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

[Krzysztof Halasa]

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-len  10  data[3] == FR_PAD 
  

Re: [PATCH 00/14] AF_RXRPC socket family and AFS rewrite [net-2.6]

[David Howells]

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 Howells]

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

[PATCH][XFRM] export SPD info

[jamal]

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

[Patrick McHardy]

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

[jamal]

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 Howells]

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

[jamal]

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 3/3] NET: Fix networking compilation errors

[David Howells]

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

Re: [PATCH] IPROUTE: Modify tc for new PRIO multiqueue behavior

[jamal]

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)

[Ilpo Järvinen]

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

[jamal]

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

[Waskiewicz Jr, Peter P]

 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

Re: e100 and eepro100

[Kok, Auke]

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.

[Divy Le Ray]

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

[Jeff Garzik]

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
netdev-tx_queue_len = adapter-tx_queue_len;

Re: wrong destination MAC in ethernet packets from sky2 ?

[Stephen Hemminger]

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

[Stephen Hemminger]

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

[Greg Kroah-Hartman]

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 netdev@vger.kernel.org
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

[Lennart Sorensen]

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

[Lennart Sorensen]

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

[Andrew Morton]

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

[Sergei Shtylyov]

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

[Rick Jones]

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

[Matt Mackall]

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

[Auke Kok]

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);
} else {
tx_ring-count = 

[PATCH 2/2] ixgb: ROUND_UP macro cleanup in drivers/net/ixgb

[Auke Kok]

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

[Tim Durack]

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: BROADCAST,MULTICAST mtu 1500 qdisc noop qlen 1000
   link/ether 00:00:00:00:68:93 brd ff:ff:ff:ff:ff:ff
3: eth1: BROADCAST,MULTICAST mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:30:18:ab:68:94 brd ff:ff:ff:ff:ff:ff
4: eth2: BROADCAST,MULTICAST 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

[Andy Fleming]

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 netdev@vger.kernel.org
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

[Jay Vosburgh]

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

[Tim Durack]

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

[Francois Romieu]

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: BROADCAST,MULTICAST mtu 1500 qdisc noop qlen 1000
link/ether 00:00:00:00:68:93 brd ff:ff:ff:ff:ff:ff
 3: eth1: BROADCAST,MULTICAST mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:18:ab:68:94 brd ff:ff:ff:ff:ff:ff
 4: eth2: BROADCAST,MULTICAST 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

[David Miller]

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

[David Miller]

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 linux/ctype.h
  #include net/sock.h
  #include net/af_rxrpc.h
 +#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

[David Miller]

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

[Rick Jones]

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

[Andrew Morton]

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:
 IRQ  [8049b9a1] inetdev_event+0x48/0x283
 [804c85d1] _spin_lock_bh+0x9/0x19
 [804753d7] rt_run_flush+0x7e/0xaf
 [8022d388] notifier_call_chain+0x29/0x56
 [80457994] dev_set_mac_address+0x53/0x59
 [88006d6d] :bonding:alb_set_slave_mac_addr+0x41/0x6c
 [880071e9] :bonding:alb_swap_mac_addr+0x91/0x165
 [88002022] :bonding:bond_change_active_slave+0x227/0x382
 [880024c2] :bonding:bond_select_active_slave+0xb7/0xe5
 [88004172] :bonding:bond_mii_monitor+0x3cd/0x41e
 [88003da5] :bonding:bond_mii_monitor+0x0/0x41e
 [802299a0] run_timer_softirq+0x130/0x19f
 [80226b64] __do_softirq+0x55/0xc4
 [8020a6ac] call_softirq+0x1c/0x28
 [8020bfb9] do_softirq+0x2c/0x7d
 [802145a7] smp_apic_timer_interrupt+0x49/0x5e
 [80208989] mwait_idle+0x0/0x47
 [8020a156] apic_timer_interrupt+0x66/0x70
 EOI  [802089cb] mwait_idle+0x42/0x47
 [80208921] cpu_idle+0x7f/0xa2
 [806349bd] start_kernel+0x242/0x24e
 [80634146] _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

[Bryan Lawver]

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

[Bryan Lawver]

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]

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

[Andrew Morton]

,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'

[David Howells]

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

[Rick Jones]

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 :-)



excerpt
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

/excerpt

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

[David Miller]

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

[Rick Jones]

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

[David Miller]

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

[Jeff Garzik]

[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

[Jeff Garzik]

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 linux/pm_legacy.h

[Jeff Garzik]

[EMAIL PROTECTED] wrote:

From: Robert P. J. Day [EMAIL PROTECTED]

Remove the apparently redundant include of linux/pm_legacy.h.

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

[Jeff Garzik]

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

[Jeff Garzik]

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

[Jeff Garzik]

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

[Andrew Morton]

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 08/11] add NAPI support to sb1250-mac.c

[Jeff Garzik]

[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

[Jeff Garzik]

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

[Jeff Garzik]

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

[Jeff Garzik]

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

[Jeff Garzik]

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

[Quan Sun]

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

[RESEND] [PATCH v2] [0/5] pasemi_mac: fixes and enhancements

[Olof Johansson]

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

[Olof Johansson]

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] [3/5] pasemi_mac: cleanups and rx performance improvements

[Olof Johansson]

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);
+
+   reg = PAS_IOB_DMA_TXCH_RESET_PCNT(stat  

[RESEND] [PATCH v2] [4/5] pasemi_mac: phy support

[Olof Johansson]

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/drivers/net/pasemi_mac.h

[RESEND] [PATCH v2] [5/5] pasemi_mac: use local-mac-address

[Olof Johansson]

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

[Herbert Xu]

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 ~{PmVHI~} [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