Re: [git patches] net driver fixes
Linus Torvalds wrote: Ok, here's an interesting one: my e1000 card no longer worked for a while. The green link-light blinks on/off once a second, and in time to that, my dmesg fills up with an endless supply of e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO and networking obviously doesn't actually work. Just out of curiosity, which e1000 chipset+motherboard are you running this on? there have been problems reported with AMT2 on several chipsets (AMT2 is not supported under linux, unlike AMT1), and having it enabled in the BIOS produces this phenomenon. I have to dig up which nic was affected, don't know by heart. Cheers, 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: [git patches] net driver fixes
On 3/1/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: Ok, here's an interesting one: my e1000 card no longer worked for a while. The green link-light blinks on/off once a second, and in time to that, my dmesg fills up with an endless supply of e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO and networking obviously doesn't actually work. I tried to do bisection, but my log made no sense, since it seemed to say that the problem was introduced between git commits 2442d310 and bff288c1, and there aren't even any commits to drivers/net/ in that range! SO... It seems to be that what actually happened is that my switch got confused (I ended up just power-cycling the switch when I hit the "impossible" situation, and that seems to be what made it start working again, rather than any kernel changes due to bisection ;) Regardless, the "spam the logs every second" is a *bad* idea. I'll try to see if I can re-create the problem (probably not), but I thought I'd report this message spamming regardless. If there really is some link problem, no way do I want to see a message about it every second for all eternity. Hmm? Does this "once a second link issue" ring any bells for anybody? Suggested fixes? I realize people do want to know about link problems, but that was a bit excessive and since it happened with a reboot, I thought it was a kernel bug (it may still be - I'll have to try to recreate it, but my suspicion right now is that the reboot just caused some noise and/or link renegotiation on the ethernet link that was what actually confused my switch). I have seen this occasionally with the e1000 on Xscale IOP development boards. The driver prints the up/down messages and makes no progress. I can also confirm that resetting the switch (SMC8505T) fixed things for me. It might be nice to just print "e1000 link can not be established try resetting your switch?" after some time. It's not clear what the steps are to reproduce this, and it doesn't happen frequently enough to be a show stopper in my environment. The IOP boards in the lab typically run an NFS root and are often power cycled without running shutdown. So at least an "I see it too" for what it's worth. Linus -- Dan - 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: ppp and routing table rules.
Ben Greear wrote: Hello! I have a suspicion (but no proof at this time) that a rule like this: 20: from all iif ppp400 lookup 10001 is not actually working for ppp interfaces. Before I go adding printk statements, are there any stats that would show if packets are hitting a particular rule or routing table? Ok, the rule is working and the routing table is being used. But, weirdness abounds. Here is my setup: I have ppp401 (11.1.1.3/32) connected to ppp400 (11.1.1.2/32), over a cross-over T1 NIC (ie, this is going to the same machine). Anything coming in on ppp400, uses a particular routing table, whose routes look like this: 10.1.1.3 via 172.1.2.2 dev rddVR4 11.1.1.2 via 11.1.1.2 dev ppp400 172.1.2.0/24 via 172.1.2.1 dev rddVR4 172.1.1.0/24 via 172.1.2.2 dev rddVR4 10.0.0.0/8 via 172.1.2.2 dev rddVR4 11.0.0.0/8 via 11.1.1.2 dev ppp400 default via 11.1.1.2 dev ppp400 If all worked as planned, the packets would traverse several other routing tables, the final which has another pair of ppp links in it (ppp200, 10.1.1.2/32 connected to ppp201, 10.1.1.3/23). I am sending udp packets through ppp400, and I see them appear on ppp401 as expected. The thing that is bothering me is that all I see on rddVR4 (172.1.2.1) is arps for 172.1.2.2, but the 'tell' IP is that of the originating ppp400 link, not the IP of rddVR4, as I expected: 21:47:16.119640 arp who-has 172.1.2.2 tell 11.1.1.3 21:47:17.119371 arp who-has 172.1.2.2 tell 11.1.1.3 21:47:18.119254 arp who-has 172.1.2.2 tell 11.1.1.3 21:47:19.273118 arp who-has 172.1.2.2 tell 11.1.1.3 Unless I'm missing something dumb, a similar setup with all ethernet-ish network devices works fine. I have also enabled arp filtering: # Only answer ARPs if it is for the IP on our own interface. echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore and for every device used in these routing tables: echo 1 > /proc/sys/net/ipv4/conf/[dev]/arp_filter Any idea what I need to do in order to make the source IP for the ARP packet correct? Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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: [git patches] net driver fixes
Ok, here's an interesting one: my e1000 card no longer worked for a while. The green link-light blinks on/off once a second, and in time to that, my dmesg fills up with an endless supply of e1000: eth0: e1000_watchdog: NIC Link is Down e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO and networking obviously doesn't actually work. I tried to do bisection, but my log made no sense, since it seemed to say that the problem was introduced between git commits 2442d310 and bff288c1, and there aren't even any commits to drivers/net/ in that range! SO... It seems to be that what actually happened is that my switch got confused (I ended up just power-cycling the switch when I hit the "impossible" situation, and that seems to be what made it start working again, rather than any kernel changes due to bisection ;) Regardless, the "spam the logs every second" is a *bad* idea. I'll try to see if I can re-create the problem (probably not), but I thought I'd report this message spamming regardless. If there really is some link problem, no way do I want to see a message about it every second for all eternity. Hmm? Does this "once a second link issue" ring any bells for anybody? Suggested fixes? I realize people do want to know about link problems, but that was a bit excessive and since it happened with a reboot, I thought it was a kernel bug (it may still be - I'll have to try to recreate it, but my suspicion right now is that the reboot just caused some noise and/or link renegotiation on the ethernet link that was what actually confused my switch). Linus - 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
ppp and routing table rules.
Hello! I have a suspicion (but no proof at this time) that a rule like this: 20: from all iif ppp400 lookup 10001 is not actually working for ppp interfaces. Before I go adding printk statements, are there any stats that would show if packets are hitting a particular rule or routing table? Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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 003 of 3] knfsd: Remove CONFIG_IPV6 ifdefs from sunrpc server code.
They don't really save that much, and aren't worth the hassle.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./include/linux/sunrpc/svc.h |2 --
./net/sunrpc/svcsock.c | 13 +++--
2 files changed, 3 insertions(+), 12 deletions(-)
diff .prev/include/linux/sunrpc/svc.h ./include/linux/sunrpc/svc.h
--- .prev/include/linux/sunrpc/svc.h2007-03-02 14:20:13.0 +1100
+++ ./include/linux/sunrpc/svc.h2007-03-02 15:14:11.0 +1100
@@ -194,9 +194,7 @@ static inline void svc_putu32(struct kve
union svc_addr_u {
struct in_addr addr;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
struct in6_addraddr6;
-#endif
};
/*
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-03-02 15:12:52.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-03-02 15:14:11.0 +1100
@@ -131,13 +131,13 @@ static char *__svc_print_addr(struct soc
NIPQUAD(((struct sockaddr_in *) addr)->sin_addr),
htons(((struct sockaddr_in *) addr)->sin_port));
break;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+
case AF_INET6:
snprintf(buf, len, "%x:%x:%x:%x:%x:%x:%x:%x, port=%u",
NIP6(((struct sockaddr_in6 *) addr)->sin6_addr),
htons(((struct sockaddr_in6 *) addr)->sin6_port));
break;
-#endif
+
default:
snprintf(buf, len, "unknown address type: %d", addr->sa_family);
break;
@@ -449,9 +449,7 @@ svc_wake_up(struct svc_serv *serv)
union svc_pktinfo_u {
struct in_pktinfo pkti;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
struct in6_pktinfo pkti6;
-#endif
};
static void svc_set_cmsg_data(struct svc_rqst *rqstp, struct cmsghdr *cmh)
@@ -467,7 +465,7 @@ static void svc_set_cmsg_data(struct svc
cmh->cmsg_len = CMSG_LEN(sizeof(*pki));
}
break;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+
case AF_INET6: {
struct in6_pktinfo *pki = CMSG_DATA(cmh);
@@ -479,7 +477,6 @@ static void svc_set_cmsg_data(struct svc
cmh->cmsg_len = CMSG_LEN(sizeof(*pki));
}
break;
-#endif
}
return;
}
@@ -730,13 +727,11 @@ static inline void svc_udp_get_dest_addr
rqstp->rq_daddr.addr.s_addr = pki->ipi_spec_dst.s_addr;
break;
}
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
case AF_INET6: {
struct in6_pktinfo *pki = CMSG_DATA(cmh);
ipv6_addr_copy(&rqstp->rq_daddr.addr6, &pki->ipi6_addr);
break;
}
-#endif
}
}
@@ -976,11 +971,9 @@ static inline int svc_port_is_privileged
case AF_INET:
return ntohs(((struct sockaddr_in *)sin)->sin_port)
< PROT_SOCK;
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
case AF_INET6:
return ntohs(((struct sockaddr_in6 *)sin)->sin6_port)
< PROT_SOCK;
-#endif
default:
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 002 of 3] knfsd: Avoid checksum checks when collecting metadata for a UDP packet.
When recv_msg is called with a size of 0 and MSG_PEEK (and sunrpc/svcsock.c does), it is clear that we only interested in metadata (from/to addresses) and not the data, so don't do any checksum checking at this point. Leave that until the data is requested. Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./net/ipv4/udp.c |3 +++ ./net/ipv6/udp.c |4 2 files changed, 7 insertions(+) diff .prev/net/ipv4/udp.c ./net/ipv4/udp.c --- .prev/net/ipv4/udp.c2007-03-02 14:20:13.0 +1100 +++ ./net/ipv4/udp.c2007-03-02 15:13:50.0 +1100 @@ -846,6 +846,9 @@ try_again: goto csum_copy_err; copy_only = 1; } + if (len == 0 && (flags & MSG_PEEK)) + /* avoid checksum concerns when just getting metadata */ + copy_only = 1; if (copy_only) err = skb_copy_datagram_iovec(skb, sizeof(struct udphdr), diff .prev/net/ipv6/udp.c ./net/ipv6/udp.c --- .prev/net/ipv6/udp.c2007-03-02 14:20:13.0 +1100 +++ ./net/ipv6/udp.c2007-03-02 15:13:50.0 +1100 @@ -151,6 +151,10 @@ try_again: copy_only = 1; } + if (len == 0 && (flags & MSG_PEEK)) + /* avoid checksum concerns when just getting metadata */ + copy_only = 1; + if (copy_only) err = skb_copy_datagram_iovec(skb, sizeof(struct udphdr), msg->msg_iov, copied ); - 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 001 of 3] knfsd: Use recv_msg to get peer address for NFSD instead of code-copying
The sunrpc server code needs to know the source and destination address
for UDP packets so it can reply properly.
It currently copies code out of the network stack to pick the pieces out
of the skb.
This is ugly and causes compile problems with the IPv6 stuff.
So, rip that out and use recv_msg instead. This is a much cleaner
interface, but has a slight cost in that the checksum is now checked
before the copy, so we don't benefit from doing both at the same time.
This can probably be fixed.
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./net/sunrpc/svcsock.c | 63 -
1 file changed, 31 insertions(+), 32 deletions(-)
diff .prev/net/sunrpc/svcsock.c ./net/sunrpc/svcsock.c
--- .prev/net/sunrpc/svcsock.c 2007-03-02 14:20:14.0 +1100
+++ ./net/sunrpc/svcsock.c 2007-03-02 15:12:52.0 +1100
@@ -721,45 +721,23 @@ svc_write_space(struct sock *sk)
}
}
-static void svc_udp_get_sender_address(struct svc_rqst *rqstp,
- struct sk_buff *skb)
+static inline void svc_udp_get_dest_address(struct svc_rqst *rqstp,
+ struct cmsghdr *cmh)
{
switch (rqstp->rq_sock->sk_sk->sk_family) {
case AF_INET: {
- /* this seems to come from net/ipv4/udp.c:udp_recvmsg */
- struct sockaddr_in *sin = svc_addr_in(rqstp);
-
- sin->sin_family = AF_INET;
- sin->sin_port = skb->h.uh->source;
- sin->sin_addr.s_addr = skb->nh.iph->saddr;
- rqstp->rq_addrlen = sizeof(struct sockaddr_in);
- /* Remember which interface received this request */
- rqstp->rq_daddr.addr.s_addr = skb->nh.iph->daddr;
- }
+ struct in_pktinfo *pki = CMSG_DATA(cmh);
+ rqstp->rq_daddr.addr.s_addr = pki->ipi_spec_dst.s_addr;
break;
+ }
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
case AF_INET6: {
- /* this is derived from net/ipv6/udp.c:udpv6_recvmesg */
- struct sockaddr_in6 *sin6 = svc_addr_in6(rqstp);
-
- sin6->sin6_family = AF_INET6;
- sin6->sin6_port = skb->h.uh->source;
- sin6->sin6_flowinfo = 0;
- sin6->sin6_scope_id = 0;
- if (ipv6_addr_type(&sin6->sin6_addr) &
- IPV6_ADDR_LINKLOCAL)
- sin6->sin6_scope_id = IP6CB(skb)->iif;
- ipv6_addr_copy(&sin6->sin6_addr,
- &skb->nh.ipv6h->saddr);
- rqstp->rq_addrlen = sizeof(struct sockaddr_in);
- /* Remember which interface received this request */
- ipv6_addr_copy(&rqstp->rq_daddr.addr6,
- &skb->nh.ipv6h->saddr);
- }
+ struct in6_pktinfo *pki = CMSG_DATA(cmh);
+ ipv6_addr_copy(&rqstp->rq_daddr.addr6, &pki->ipi6_addr);
break;
+ }
#endif
}
- return;
}
/*
@@ -771,7 +749,15 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
struct svc_sock *svsk = rqstp->rq_sock;
struct svc_serv *serv = svsk->sk_server;
struct sk_buff *skb;
+ charbuffer[CMSG_SPACE(sizeof(union svc_pktinfo_u))];
+ struct cmsghdr *cmh = (struct cmsghdr *)buffer;
int err, len;
+ struct msghdr msg = {
+ .msg_name = svc_addr(rqstp),
+ .msg_control = cmh,
+ .msg_controllen = sizeof(buffer),
+ .msg_flags = MSG_DONTWAIT,
+ };
if (test_and_clear_bit(SK_CHNGBUF, &svsk->sk_flags))
/* udp sockets need large rcvbuf as all pending
@@ -797,7 +783,9 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
}
clear_bit(SK_DATA, &svsk->sk_flags);
- while ((skb = skb_recv_datagram(svsk->sk_sk, 0, 1, &err)) == NULL) {
+ while ((err == kernel_recvmsg(svsk->sk_sock, &msg, NULL,
+ 0, 0, MSG_PEEK)) < 0 ||
+ (skb = skb_recv_datagram(svsk->sk_sk, 0, 1, &err)) == NULL) {
if (err == -EAGAIN) {
svc_sock_received(svsk);
return err;
@@ -805,6 +793,7 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
/* possibly an icmp error */
dprintk("svc: recvfrom returned error %d\n", -err);
}
+ rqstp->rq_addrlen = sizeof(rqstp->rq_addr);
if (skb->tstamp.off_sec == 0) {
struct timeval tv;
@@ -827,7 +816,7 @@ svc_udp_recvfrom(struct svc_rqst *rqstp)
rqstp->rq_prot = IPPROTO_UDP;
- svc_udp_get_se
[PATCH 000 of 3] knfsd: Resolve IPv6 related link error
Current mainline has a compile linkage problem if both CONFIG_IPV6=m CONFIG_SUNRPC=y because net/sunrpc/svcsock.c conditionally used a function defined in the IPv6 module. These three patches resolve the issue. The problem is caused because svcsock needs to get the source and destination address for a udp packet, but doesn't want to just use sock_recvmsg like userspace would as it wants to be able to use the data directly out of the skbuff rather than copying it (when practical). Currently it copies code from udp.c (both ipv4/ and ipv6/) and this causes the problem. This patch changes it to use kernel_recvmsg with a length of 0 and flags of MSG_PEEK to get the addresses but leave the data untouched. A small problem here is that kernel_recvmsg always checks the checksum, so in the case of a large packet we will check the checksum at a different time to when we copy it out into a buffer, which is not ideal. So the second patch of this series avoids the check when recv_msg is called with size==0 and flags==MSG_PEEK. This change should be acked by someone on netdev before going upsteam!!! The rest of the series is still appropriate without the patch, it is just a small optimisation. Finally the last patch removes all the #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) from sunrpc as it really isn't needed and just hides this sort of problem. Patches 1 and 3 are suitable for 2.6.21. Patch 2 needs confirmation. Thanks, NeilBrown [PATCH 001 of 3] knfsd: Use recv_msg to get peer address for NFSD instead of code-copying [PATCH 002 of 3] knfsd: Avoid checksum checks when collecting metadata for a UDP packet. [PATCH 003 of 3] knfsd: Remove CONFIG_IPV6 ifdefs from sunrpc server code. - 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 8107] New: dev->header_cache_update has a random value
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 1 Mar 2007 15:30:25 -0800 > Your right, but so far there is no ioctl to take it out of this mode. > So it is a one way door. You can keep attaching a different new protocol to an HDLC device until it is brought up. > This device never calls hdlc->detach?? The HDLC layer calls the protocol ->detach, but the Cisco HDLC code does not have a detach method. I'm starting to feel that this is the bug, because as it stands the Cisco HDLC code leaves stale pointers around and then if you unload the Cisco HDLC module things can explode. - 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 8107] New: dev->header_cache_update has a random value
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 1 Mar 2007 14:37:27 -0800 > Not necessary, since any network device must already allocated by > alloc_netdev() and it initializes the whole struct to 0 (NULL). It is in this case, unfortunately, HDLC protocols can be registers several times before the device is brought up and protocol changes become disallowed. So you can attach one, then a second one, and the second one has to explicitly initialize the pointers potentially set by the first one. On the other hand, you could say that it's the protocol ->detach() method's responsibility to NULL out these things instead of leaving references to function pointers of a module that's about the be unloaded. - 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
[RFC] Arp announce (for Xen)
What about implementing the unused arp_announce flag on the inetdevice? Something like the following. Totally untested... Looks like it either was there (and got removed) or was planned but never implemented. diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c index e10794d..cefc339 100644 --- a/net/ipv4/devinet.c +++ b/net/ipv4/devinet.c @@ -1089,6 +1089,16 @@ static int inetdev_event(struct notifier } } ip_mc_up(in_dev); + /* fallthru */ + + case NETDEV_CHANGEADDR: + /* Send gratuitous ARP in case of address change or new device */ + if (IN_DEV_ARP_ANNOUNCE(in_dev)) + arp_send(ARPOP_REQUEST, ETH_P_ARP, +in_dev->ifa_list->ifa_address, dev, +in_dev->ifa_list->ifa_address, NULL, +dev->dev_addr, NULL); + break; case NETDEV_DOWN: ip_mc_down(in_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
Re: [patch 26/26] Xen-paravirt_ops: Add the Xen virtual network device driver.
On Thu, Mar 01, 2007 at 04:42:14PM -0800, Stephen Hemminger wrote: > > + > > +/** Send a packet on a net device to encourage switches to learn the > > + * MAC. We send a fake ARP request. > > + * > > + * @param dev device > > + * @return 0 on success, error code otherwise > > + */ > Why the sudden urge to use docbook format on one internal function. And it's not even proper kerneldoc but looks more like javadoc. If you want to write kerneldoc comments please also verify them by running the tools over it. > This should probably be done in generic (non driver code). > It creates lots of dependencies here. Actually the right way to do it is in userspace, as all clustering solutions do. That's whay everyone told the Xen folks by the just refuse to rip this junk out. - 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 26/26] Xen-paravirt_ops: Add the Xen virtual network device driver.
Stephen Hemminger wrote:
> On Thu, 01 Mar 2007 15:25:09 -0800
> Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>
>> The network device frontend driver allows the kernel to access network
>> devices exported exported by a virtual machine containing a physical
>> network device driver.
>>
>> Signed-off-by: Ian Pratt <[EMAIL PROTECTED]>
>> Signed-off-by: Christian Limpach <[EMAIL PROTECTED]>
>> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
>> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>> Cc: netdev@vger.kernel.org
>> Cc: Jeff Garzik <[EMAIL PROTECTED]>
>>
>> ---
>> drivers/net/Kconfig| 12
>> drivers/net/Makefile |2
>> drivers/net/xen-netfront.c | 2066
>>
>> include/xen/events.h |2
>> 4 files changed, 2082 insertions(+)
>>
>> ===
>> --- a/drivers/net/Kconfig
>> +++ b/drivers/net/Kconfig
>> @@ -2525,6 +2525,18 @@ source "drivers/atm/Kconfig"
>>
>> source "drivers/s390/net/Kconfig"
>>
>> +config XEN_NETDEV_FRONTEND
>> +tristate "Xen network device frontend driver"
>> +depends on XEN
>> +default y
>> +help
>> + The network device frontend driver allows the kernel to
>> + access network devices exported exported by a virtual
>> + machine containing a physical network device driver. The
>> + frontend driver is intended for unprivileged guest domains;
>> + if you are compiling a kernel for a Xen guest, you almost
>> + certainly want to enable this.
>> +
>> config ISERIES_VETH
>> tristate "iSeries Virtual Ethernet driver support"
>> depends on PPC_ISERIES
>>
>
> Might make more sense earlier in list (near other virtual devices).
>
OK.
>
> Hey I thought this driver depended on CONFIG_XEN already?
>
You're right.
>> +static int MODPARM_rx_copy = 0;
>> +module_param_named(rx_copy, MODPARM_rx_copy, bool, 0);
>> +MODULE_PARM_DESC(rx_copy, "Copy packets from network card (rather than
>> flip)");
>> +static int MODPARM_rx_flip = 0;
>> +module_param_named(rx_flip, MODPARM_rx_flip, bool, 0);
>> +MODULE_PARM_DESC(rx_flip, "Flip packets from network card (rather than
>> copy)");
>> +#else
>> +static const int MODPARM_rx_copy = 1;
>> +static const int MODPARM_rx_flip = 0;
>> +#endif
>>
>
>
> No MIXED case variable names please.
>
OK.
> Why have two mutually exclusive values instead of just one value
> with three states: 0 = normal, 1 = copy, 2 = flip?
>
That does seem odd. I'll fix it up.
>> +#define DPRINTK(fmt, args...) \
>> +pr_debug("netfront (%s:%d) " fmt, \
>> + __FUNCTION__, __LINE__, ##args)
>> +#define IPRINTK(fmt, args...) \
>> +printk(KERN_INFO "netfront: " fmt, ##args)
>> +#define WPRINTK(fmt, args...) \
>> +printk(KERN_WARNING "netfront: " fmt, ##args)
>>
>
>
> Could you use dev_dbg, dev_info, dev_warn instead of these macros?
>
Yes. I'd done that conversion elsewhere, but overlooked it here.
>> +
>> +/** Send a packet on a net device to encourage switches to learn the
>> + * MAC. We send a fake ARP request.
>> + *
>> + * @param dev device
>> + * @return 0 on success, error code otherwise
>> + */
>>
> Why the sudden urge to use docbook format on one internal function.
>
It probably got copied from somewhere. I'll clean it up.
>> +static int send_fake_arp(struct net_device *dev)
>> +{
>> +struct sk_buff *skb;
>> +u32 src_ip, dst_ip;
>> +
>> +dst_ip = INADDR_BROADCAST;
>> +src_ip = inet_select_addr(dev, dst_ip, RT_SCOPE_LINK);
>> +
>> +/* No IP? Then nothing to do. */
>> +if (src_ip == 0)
>> +return 0;
>> +
>> +skb = arp_create(ARPOP_REPLY, ETH_P_ARP,
>> + dst_ip, dev, src_ip,
>> + /*dst_hw*/ NULL, /*src_hw*/ NULL,
>> + /*target_hw*/ dev->dev_addr);
>> +if (skb == NULL)
>> +return -ENOMEM;
>> +
>> +return dev_queue_xmit(skb);
>> +}
>>
>
> This should probably be done in generic (non driver code).
> It creates lots of dependencies here.
> [...]
> Shouldn't just be a global kernel option for gratuitous ARP.
> Doesn't seem to be unique to this driver.
> With sysctl to enable it.
>
I agree it would be nice to not have to do this in the driver. The
specific requirement here is to make it send a packet after resume
(which includes arriving after a migration) so that a switch can quickly
work that the machine is there. Is there a generic mechanism for doing
this?
J
-
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 26/26] Xen-paravirt_ops: Add the Xen virtual network device driver.
On Thu, 01 Mar 2007 15:25:09 -0800
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> The network device frontend driver allows the kernel to access network
> devices exported exported by a virtual machine containing a physical
> network device driver.
>
> Signed-off-by: Ian Pratt <[EMAIL PROTECTED]>
> Signed-off-by: Christian Limpach <[EMAIL PROTECTED]>
> Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> Cc: netdev@vger.kernel.org
> Cc: Jeff Garzik <[EMAIL PROTECTED]>
>
> ---
> drivers/net/Kconfig| 12
> drivers/net/Makefile |2
> drivers/net/xen-netfront.c | 2066
>
> include/xen/events.h |2
> 4 files changed, 2082 insertions(+)
>
> ===
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2525,6 +2525,18 @@ source "drivers/atm/Kconfig"
>
> source "drivers/s390/net/Kconfig"
>
> +config XEN_NETDEV_FRONTEND
> + tristate "Xen network device frontend driver"
> + depends on XEN
> + default y
> + help
> + The network device frontend driver allows the kernel to
> + access network devices exported exported by a virtual
> + machine containing a physical network device driver. The
> + frontend driver is intended for unprivileged guest domains;
> + if you are compiling a kernel for a Xen guest, you almost
> + certainly want to enable this.
> +
> config ISERIES_VETH
> tristate "iSeries Virtual Ethernet driver support"
> depends on PPC_ISERIES
Might make more sense earlier in list (near other virtual devices).
===
>
> +/*
> + * Mutually-exclusive module options to select receive data path:
> + * rx_copy : Packets are copied by network backend into local memory
> + * rx_flip : Page containing packet data is transferred to our ownership
> + * For fully-virtualised guests there is no option - copying must be used.
> + * For paravirtualised guests, flipping is the default.
> + */
> +#ifdef CONFIG_XEN
Hey I thought this driver depended on CONFIG_XEN already?
> +static int MODPARM_rx_copy = 0;
> +module_param_named(rx_copy, MODPARM_rx_copy, bool, 0);
> +MODULE_PARM_DESC(rx_copy, "Copy packets from network card (rather than
> flip)");
> +static int MODPARM_rx_flip = 0;
> +module_param_named(rx_flip, MODPARM_rx_flip, bool, 0);
> +MODULE_PARM_DESC(rx_flip, "Flip packets from network card (rather than
> copy)");
> +#else
> +static const int MODPARM_rx_copy = 1;
> +static const int MODPARM_rx_flip = 0;
> +#endif
No MIXED case variable names please.
Why have two mutually exclusive values instead of just one value
with three states: 0 = normal, 1 = copy, 2 = flip?
> +#define DPRINTK(fmt, args...)\
> + pr_debug("netfront (%s:%d) " fmt, \
> + __FUNCTION__, __LINE__, ##args)
> +#define IPRINTK(fmt, args...)\
> + printk(KERN_INFO "netfront: " fmt, ##args)
> +#define WPRINTK(fmt, args...)\
> + printk(KERN_WARNING "netfront: " fmt, ##args)
Could you use dev_dbg, dev_info, dev_warn instead of these macros?
> +
> +/** Send a packet on a net device to encourage switches to learn the
> + * MAC. We send a fake ARP request.
> + *
> + * @param dev device
> + * @return 0 on success, error code otherwise
> + */
Why the sudden urge to use docbook format on one internal function.
> +static int send_fake_arp(struct net_device *dev)
> +{
> + struct sk_buff *skb;
> + u32 src_ip, dst_ip;
> +
> + dst_ip = INADDR_BROADCAST;
> + src_ip = inet_select_addr(dev, dst_ip, RT_SCOPE_LINK);
> +
> + /* No IP? Then nothing to do. */
> + if (src_ip == 0)
> + return 0;
> +
> + skb = arp_create(ARPOP_REPLY, ETH_P_ARP,
> + dst_ip, dev, src_ip,
> + /*dst_hw*/ NULL, /*src_hw*/ NULL,
> + /*target_hw*/ dev->dev_addr);
> + if (skb == NULL)
> + return -ENOMEM;
> +
> + return dev_queue_xmit(skb);
> +}
This should probably be done in generic (non driver code).
It creates lots of dependencies here.
> +/*
> + * We use this notifier to send out a fake ARP reply to reset switches and
> + * router ARP caches when an IP interface is brought up on a VIF.
> + */
> +static int
> +inetdev_notify(struct notifier_block *this, unsigned long event, void *ptr)
> +{
> + struct in_ifaddr *ifa = (struct in_ifaddr *)ptr;
> + struct net_device *dev = ifa->ifa_dev->dev;
> +
> + /* UP event and is it one of our devices? */
> + if (event == NETDEV_UP && dev->open == network_open)
> + (void)send_fake_arp(dev);
> +
> + return NOTIFY_DONE;
> +}
Shouldn't just be a global kernel option for gratuitous ARP.
Doesn't seem to be unique to this driv
[patch 26/26] Xen-paravirt_ops: Add the Xen virtual network device driver.
The network device frontend driver allows the kernel to access network devices exported exported by a virtual machine containing a physical network device driver. Signed-off-by: Ian Pratt <[EMAIL PROTECTED]> Signed-off-by: Christian Limpach <[EMAIL PROTECTED]> Signed-off-by: Chris Wright <[EMAIL PROTECTED]> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Cc: netdev@vger.kernel.org Cc: Jeff Garzik <[EMAIL PROTECTED]> --- drivers/net/Kconfig| 12 drivers/net/Makefile |2 drivers/net/xen-netfront.c | 2066 include/xen/events.h |2 4 files changed, 2082 insertions(+) === --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2525,6 +2525,18 @@ source "drivers/atm/Kconfig" source "drivers/s390/net/Kconfig" +config XEN_NETDEV_FRONTEND + tristate "Xen network device frontend driver" + depends on XEN + default y + help + The network device frontend driver allows the kernel to + access network devices exported exported by a virtual + machine containing a physical network device driver. The + frontend driver is intended for unprivileged guest domains; + if you are compiling a kernel for a Xen guest, you almost + certainly want to enable this. + config ISERIES_VETH tristate "iSeries Virtual Ethernet driver support" depends on PPC_ISERIES === --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -218,3 +218,5 @@ obj-$(CONFIG_FS_ENET) += fs_enet/ obj-$(CONFIG_FS_ENET) += fs_enet/ obj-$(CONFIG_NETXEN_NIC) += netxen/ + +obj-$(CONFIG_XEN_NETDEV_FRONTEND) += xen-netfront.o === --- /dev/null +++ b/drivers/net/xen-netfront.c @@ -0,0 +1,2066 @@ +/** + * Virtual network driver for conversing with remote driver backends. + * + * Copyright (c) 2002-2005, K A Fraser + * Copyright (c) 2005, XenSource Ltd + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation; or, when distributed + * separately from the Linux kernel or incorporated into other + * software packages, subject to the following license: + * + * Permission is hereby granted, free of charge, to any person obtaining a copy + * of this source file (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, copy, modify, + * merge, publish, distribute, sublicense, and/or sell copies of the Software, + * and to permit persons to whom the Software is furnished to do so, subject to + * the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#ifdef CONFIG_XEN_BALLOON +#include +#endif +#include +#include + +#include +#include +#include + +/* + * Mutually-exclusive module options to select receive data path: + * rx_copy : Packets are copied by network backend into local memory + * rx_flip : Page containing packet data is transferred to our ownership + * For fully-virtualised guests there is no option - copying must be used. + * For paravirtualised guests, flipping is the default. + */ +#ifdef CONFIG_XEN +static int MODPARM_rx_copy = 0; +module_param_named(rx_copy, MODPARM_rx_copy, bool, 0); +MODULE_PARM_DESC(rx_copy, "Copy packets from network card (rather than flip)"); +static int MODPARM_rx_flip = 0; +module_param_named(rx_flip, MODPARM_rx_flip, bool, 0); +MODULE_PARM_DESC(rx_flip, "Flip packets from network card (rather than copy)"); +#else +static const int MODPARM_rx_copy = 1; +static const int MODPARM_rx_flip = 0; +#endif + +#define RX_COPY_THRESHOLD 256 + +#define GRANT_INVALID_REF 0 + +#define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE) +#define NET_RX_RING_SIZE __RING_SIZE((struct netif_rx_sring *)0, PAGE_SIZE) + +s
Re: Network access fails unless tcpdump is running?
Andy Gospodarek <[EMAIL PROTECTED]> writes: > On Thu, Mar 01, 2007 at 03:54:58PM -0500, Marc D Ronell wrote: >> Andy Gospodarek <[EMAIL PROTECTED]> writes: >> >> > On Thu, Mar 01, 2007 at 02:22:24PM -0500, Marc D Ronell wrote: >> >> >> >> Hi, >> >> >> >> I can not ping a remote host successfully unless I have "tcpdump -i >> >> eth0" running, in which case, my network access works fine. >> > >> > Interesting that when your interface is in promiscious mode it works >> > fine, but otherwise it doesn't. Do you have all of your iptables rules >> > cleared? >> > >> >> Thanks very much for your reply and interest. I find this an odd >> problem. The output of iptables -L looks like: >> >>caviar:/tmp# iptables -L >>Chain INPUT (policy ACCEPT) >>target prot opt source destination >> >>Chain FORWARD (policy ACCEPT) >>target prot opt source destination >> >>Chain OUTPUT (policy ACCEPT) >>target prot opt source destination >> >> The machine name is caviar on the prompt. There are no rules in >> place. AFAIK, there are no firewalls running. Changing the routing >> table did not help the situation. >> > > Looks good. > >> >> >> I am running Debian etch on a Dell Inspiron e1505 laptop. The eth0 >> >> address is static on my local LAN. Once tcpdump is running, the >> >> laptop can access the network with no problems. >> > >> > What networking hardware is on that laptop? Can you post the complete >> > output of `ethtool -i eth0` and the network device info from the output >> > of `lcpci -vvv`? >> >> lspci output is attached below. >> > > I presumed this is with the wired interface (not the wireless one). > That is a correct assumption, right? > Thats correct. Its the wired interface, eth0 which is having the problem. I have turned the wireless interface, eth2 off with both ifconfig and ifdown, and still, the connection to the outside only works when tcpdump is running. > Can you post the output from `ethtool -i ethX` (where ethX is the wired > interface). I ask because that tells me what version of the b44/ipw3945 > driver you are using. > > # ethtool -i eth0 driver: b44 version: 1.01 firmware-version: bus-info: :03:00.0 The system was working originally fine, but something changed. Perhaps through an Debian aptitude update. Thanks for your help and interest. marc - 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: CLOCK_MONOTONIC datagram timestamps by the kernel
On Fri, 02 Mar 2007 00:14:37 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote: > Stephen Hemminger a écrit : > > > > > You probably want to add a SO_TIMESTAMPNS setsockopt() value like existing > > SO_TIMESTAMP > > You mean an alias like this ? > > #define SO_TIMESTAMPNS SO_TIMESTAMP > > Or should we really use another value ? Another value since if someone turns on SO_TIMESTAMP they want usec (timeval) and SO_TIMESTAMPNS would be for nanosecond values. Trying to set both flags would be not allowed. - original - If the SO_TIMESTAMP option is enabled on a SOCK_DGRAM socket, the recvmsg(2) call will return a timestamp corresponding to when the data- gram was received. The msg_control field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by a struct timeval. The cmsghdr fields have the following values: cmsg_len = sizeof(struct timeval) cmsg_level = SOL_SOCKET cmsg_type = SCM_TIMESTAMP - add - If the SO_TIMESTAMPNS option is enabled on a SOCK_DGRAM socket, ... cmsg_len = sizeof(struct timespec) cmsg_level = SOL_SOCKET cmsg_type = SCM_TIMESTAMPNS -- 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: [PATCH] spidernet: Fix problem sending IP fragments
On Thu, Mar 01, 2007 at 04:52:54PM -0600, Chris Engel wrote: > I tried to apply this patch to 2.6.21-rc2 and CHECKSUM_HW appears to be > changed to CHECKSUM_COMPLETE The use of CHECKSUM_HW was replaced by CHECKSUM_PARTIAL and CHECKSUM_COMPLETE on a cae-by-case basis, in the patch series leading up to 2.6.19. In this case, I'm not sure which should have been used. Norbert, can you resubmit a patch that applies to a more recent kernel? p.s. your emailer replaced tabs by spaces ... --linas - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mv643xx_eth: Place explicit port number in mv643xx_eth_platform_data
We were using the platform_device.id field to identify which ethernet
port is used for mv643xx_eth device. This is not generally correct.
It will be incorrect, for example, if a hardware platform uses a single
port but not the first port. Here, we add an explicit port_number field
to struct mv643xx_eth_platform_data.
This makes the mv643xx_eth_platform_data structure required, but that
isn't an issue since all users currently provide it already.
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
---
arch/mips/momentum/jaguar_atx/platform.c |8 ++
arch/mips/momentum/ocelot_3/platform.c|8 ++
arch/mips/momentum/ocelot_c/platform.c|4 +
arch/powerpc/platforms/chrp/pegasos_eth.c |2
arch/ppc/syslib/mv64x60.c | 12 +++-
drivers/net/mv643xx_eth.c | 59 ++--
include/linux/mv643xx.h |1
7 files changed, 62 insertions(+), 32 deletions(-)
diff --git a/arch/mips/momentum/jaguar_atx/platform.c
b/arch/mips/momentum/jaguar_atx/platform.c
index 035ea51..003d3ee 100644
Index: b/arch/mips/momentum/jaguar_atx/platform.c
===
--- a/arch/mips/momentum/jaguar_atx/platform.c
+++ b/arch/mips/momentum/jaguar_atx/platform.c
@@ -48,6 +48,8 @@ static struct resource mv64x60_eth0_reso
};
static struct mv643xx_eth_platform_data eth0_pd = {
+ .port_number= 0,
+
.tx_sram_addr = MV_SRAM_BASE_ETH0,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -77,6 +79,8 @@ static struct resource mv64x60_eth1_reso
};
static struct mv643xx_eth_platform_data eth1_pd = {
+ .port_number= 1,
+
.tx_sram_addr = MV_SRAM_BASE_ETH1,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -105,7 +109,9 @@ static struct resource mv64x60_eth2_reso
},
};
-static struct mv643xx_eth_platform_data eth2_pd;
+static struct mv643xx_eth_platform_data eth2_pd = {
+ .port_number= 2,
+};
static struct platform_device eth2_device = {
.name = MV643XX_ETH_NAME,
Index: b/arch/mips/momentum/ocelot_3/platform.c
===
--- a/arch/mips/momentum/ocelot_3/platform.c
+++ b/arch/mips/momentum/ocelot_3/platform.c
@@ -48,6 +48,8 @@ static struct resource mv64x60_eth0_reso
};
static struct mv643xx_eth_platform_data eth0_pd = {
+ .port_number= 0,
+
.tx_sram_addr = MV_SRAM_BASE_ETH0,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -77,6 +79,8 @@ static struct resource mv64x60_eth1_reso
};
static struct mv643xx_eth_platform_data eth1_pd = {
+ .port_number= 1,
+
.tx_sram_addr = MV_SRAM_BASE_ETH1,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -105,7 +109,9 @@ static struct resource mv64x60_eth2_reso
},
};
-static struct mv643xx_eth_platform_data eth2_pd;
+static struct mv643xx_eth_platform_data eth2_pd = {
+ .port_number= 2,
+};
static struct platform_device eth2_device = {
.name = MV643XX_ETH_NAME,
Index: b/arch/mips/momentum/ocelot_c/platform.c
===
--- a/arch/mips/momentum/ocelot_c/platform.c
+++ b/arch/mips/momentum/ocelot_c/platform.c
@@ -47,6 +47,8 @@ static struct resource mv64x60_eth0_reso
};
static struct mv643xx_eth_platform_data eth0_pd = {
+ .port_number= 0,
+
.tx_sram_addr = MV_SRAM_BASE_ETH0,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -76,6 +78,8 @@ static struct resource mv64x60_eth1_reso
};
static struct mv643xx_eth_platform_data eth1_pd = {
+ .port_number= 1,
+
.tx_sram_addr = MV_SRAM_BASE_ETH1,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
Index: b/arch/powerpc/platforms/chrp/pegasos_eth.c
===
--- a/arch/powerpc/platforms/chrp/pegasos_eth.c
+++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
@@ -58,6 +58,7 @@ static struct resource mv643xx_eth0_reso
static struct mv643xx_eth_platform_data eth0_pd = {
+ .port_number= 0,
.tx_sram_addr = PEGASOS2_SRAM_BASE_ETH0,
.tx_sram_size = PEGASOS2_SRAM_TXRING_SIZE,
.tx_queue_size = PEGASOS2_SRAM_TXRING_SIZE/16,
@@ -87,6 +88,7 @@ static struct resource mv643xx_eth1_reso
};
static struct mv643xx_eth_platform_data eth1_pd = {
+ .port_number= 1,
.tx_sram_addr = PEGASOS2_SRAM_BASE_ETH1,
.tx_sram_size = PEGASOS2_SRAM_TXRING_SIZE,
.tx_queue_size = PEGASOS2_SRAM_TXRING_SIZE/16,
Index: b/arch/ppc/syslib/mv64x60.c
===
--- a
[PATCH 1/2] mv643xx_eth: move mac_addr inside mv643xx_eth_platform_data
The information contained within platform_data should be self-contained.
Replace the pointer to a MAC address with the actual MAC address in
struct mv643xx_eth_platform_data.
Signed-off-by: Dale Farnsworth <[EMAIL PROTECTED]>
---
Replaced explicit mac address comparison with a call to is_valid_ether_addr(),
as suggested by Stephen Hemminger <[EMAIL PROTECTED]>.
arch/mips/momentum/jaguar_atx/platform.c | 20
arch/mips/momentum/ocelot_3/platform.c | 20
arch/mips/momentum/ocelot_c/platform.c | 12 ++--
drivers/net/mv643xx_eth.c|2 +-
include/linux/mv643xx.h |2 +-
5 files changed, 12 insertions(+), 44 deletions(-)
Index: b/drivers/net/mv643xx_eth.c
===
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -1380,7 +1380,7 @@ static int mv643xx_eth_probe(struct plat
pd = pdev->dev.platform_data;
if (pd) {
- if (pd->mac_addr)
+ if (is_valid_ether_addr(pd->mac_addr))
memcpy(dev->dev_addr, pd->mac_addr, 6);
if (pd->phy_addr || pd->force_phy_addr)
Index: b/include/linux/mv643xx.h
===
--- a/include/linux/mv643xx.h
+++ b/include/linux/mv643xx.h
@@ -1289,7 +1289,6 @@ struct mv64xxx_i2c_pdata {
#define MV643XX_ETH_NAME "mv643xx_eth"
struct mv643xx_eth_platform_data {
- char*mac_addr; /* pointer to mac address */
u16 force_phy_addr; /* force override if phy_addr == 0 */
u16 phy_addr;
@@ -1304,6 +1303,7 @@ struct mv643xx_eth_platform_data {
u32 tx_sram_size;
u32 rx_sram_addr;
u32 rx_sram_size;
+ u8 mac_addr[6];/* mac address if non-zero*/
};
#endif /* __ASM_MV643XX_H */
Index: b/arch/mips/momentum/jaguar_atx/platform.c
===
--- a/arch/mips/momentum/jaguar_atx/platform.c
+++ b/arch/mips/momentum/jaguar_atx/platform.c
@@ -47,11 +47,7 @@ static struct resource mv64x60_eth0_reso
},
};
-static char eth0_mac_addr[ETH_ALEN];
-
static struct mv643xx_eth_platform_data eth0_pd = {
- .mac_addr = eth0_mac_addr,
-
.tx_sram_addr = MV_SRAM_BASE_ETH0,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -80,11 +76,7 @@ static struct resource mv64x60_eth1_reso
},
};
-static char eth1_mac_addr[ETH_ALEN];
-
static struct mv643xx_eth_platform_data eth1_pd = {
- .mac_addr = eth1_mac_addr,
-
.tx_sram_addr = MV_SRAM_BASE_ETH1,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -113,11 +105,7 @@ static struct resource mv64x60_eth2_reso
},
};
-static char eth2_mac_addr[ETH_ALEN];
-
-static struct mv643xx_eth_platform_data eth2_pd = {
- .mac_addr = eth2_mac_addr,
-};
+static struct mv643xx_eth_platform_data eth2_pd;
static struct platform_device eth2_device = {
.name = MV643XX_ETH_NAME,
@@ -200,9 +188,9 @@ static int __init mv643xx_eth_add_pds(vo
int ret;
get_mac(mac);
- eth_mac_add(eth0_mac_addr, mac, 0);
- eth_mac_add(eth1_mac_addr, mac, 1);
- eth_mac_add(eth2_mac_addr, mac, 2);
+ eth_mac_add(eth0_pd.mac_addr, mac, 0);
+ eth_mac_add(eth1_pd.mac_addr, mac, 1);
+ eth_mac_add(eth2_pd.mac_addr, mac, 2);
ret = platform_add_devices(mv643xx_eth_pd_devs,
ARRAY_SIZE(mv643xx_eth_pd_devs));
Index: b/arch/mips/momentum/ocelot_3/platform.c
===
--- a/arch/mips/momentum/ocelot_3/platform.c
+++ b/arch/mips/momentum/ocelot_3/platform.c
@@ -47,11 +47,7 @@ static struct resource mv64x60_eth0_reso
},
};
-static char eth0_mac_addr[ETH_ALEN];
-
static struct mv643xx_eth_platform_data eth0_pd = {
- .mac_addr = eth0_mac_addr,
-
.tx_sram_addr = MV_SRAM_BASE_ETH0,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -80,11 +76,7 @@ static struct resource mv64x60_eth1_reso
},
};
-static char eth1_mac_addr[ETH_ALEN];
-
static struct mv643xx_eth_platform_data eth1_pd = {
- .mac_addr = eth1_mac_addr,
-
.tx_sram_addr = MV_SRAM_BASE_ETH1,
.tx_sram_size = MV_SRAM_TXRING_SIZE,
.tx_queue_size = MV_SRAM_TXRING_SIZE / 16,
@@ -113,11 +105,7 @@ static struct resource mv64x60_eth2_reso
},
};
-static char eth2_mac_addr[ETH_ALEN];
-
-static struct mv643xx_eth_platform_data eth2_pd = {
- .mac_addr = eth2_mac_addr,
-};
+static struct mv643xx_eth_platform_data eth2_pd;
static struct platform_device eth2_device = {
Re: [Bugme-new] [Bug 8107] New: dev->header_cache_update has a random value
On Thu, 1 Mar 2007 14:54:23 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 1 Mar 2007 14:37:27 -0800 > Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > > On Thu, 1 Mar 2007 14:34:17 -0800 > > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > On Thu, 1 Mar 2007 11:33:05 -0800 > > > [EMAIL PROTECTED] wrote: > > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8107 > > > > > > > >Summary: dev->header_cache_update has a random value > > > > Kernel Version: 2.6.20 > > > > Status: NEW > > > > Severity: high > > > > Owner: [EMAIL PROTECTED] > > > > Submitter: [EMAIL PROTECTED] > > > > > > > > > > > > Distribution: Kernel 2.6.20 > > > > > > > > Problem Description: > > > > > > > > In struct net_device, there are two fields: hard_header_cache and > > > > header_cache_update, both of which are function pointers. The third > > > > field, > > > > hard_header, is also a function pointer. Whenever hard_header points to > > > > a valid > > > > function, both hard_header_cache and header_cache_update should have a > > > > known > > > > value, either NULL or a valid function pointer. However, in > > > > drivers/net/wan/hdlc_cisco.c, in function static int cisco_ioctl(struct > > > > net_device *dev, struct ifreq *ifr), where dev->hard_header is assigned > > > > a valid > > > > function, and dev->hard_header_cache is assigned a known value (NULL), > > > > dev- > > > > >header_cache_update is not set to a known value: > > > > > > > > dev->hard_start_xmit = hdlc->xmit; > > > > dev->hard_header = cisco_hard_header; > > > > dev->hard_header_cache = NULL; > > > > dev->type = ARPHRD_CISCO; > > > > dev->flags = IFF_POINTOPOINT | IFF_NOARP; > > > > dev->addr_len = 0; > > > > > > > > This may cause serious problems when dev->header_cache_update is > > > > invoked, > > > > because it has an uninitialized value. > > > > > > > > Steps to reproduce: > > > > > > > > I found this suspicious spot with the help of a code-checking tool. > > > > > > > > > > Like this? > > > > Not necessary, since any network device must already allocated by > > alloc_netdev() and it initializes the whole struct to 0 (NULL). > > But ioctl(IF_PROTO_CISCO) can be run multiple times across the lifetime of > a net_device? Your right, but so far there is no ioctl to take it out of this mode. So it is a one way door. This device never calls hdlc->detach?? -- 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: CLOCK_MONOTONIC datagram timestamps by the kernel
Stephen Hemminger a écrit : You probably want to add a SO_TIMESTAMPNS setsockopt() value like existing SO_TIMESTAMP You mean an alias like this ? #define SO_TIMESTAMPNS SO_TIMESTAMP Or should we really use another value ? Also use NSEC_PER_USEC rather than hardcoded 1000. Yes I will resubmit a patch including your suggestions (I discovered some missing bits after a make allyesconfig) Thank you - 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 8107] New: dev->header_cache_update has a random value
On Thu, 1 Mar 2007 14:37:27 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > On Thu, 1 Mar 2007 14:34:17 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Thu, 1 Mar 2007 11:33:05 -0800 > > [EMAIL PROTECTED] wrote: > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=8107 > > > > > >Summary: dev->header_cache_update has a random value > > > Kernel Version: 2.6.20 > > > Status: NEW > > > Severity: high > > > Owner: [EMAIL PROTECTED] > > > Submitter: [EMAIL PROTECTED] > > > > > > > > > Distribution: Kernel 2.6.20 > > > > > > Problem Description: > > > > > > In struct net_device, there are two fields: hard_header_cache and > > > header_cache_update, both of which are function pointers. The third > > > field, > > > hard_header, is also a function pointer. Whenever hard_header points to a > > > valid > > > function, both hard_header_cache and header_cache_update should have a > > > known > > > value, either NULL or a valid function pointer. However, in > > > drivers/net/wan/hdlc_cisco.c, in function static int cisco_ioctl(struct > > > net_device *dev, struct ifreq *ifr), where dev->hard_header is assigned a > > > valid > > > function, and dev->hard_header_cache is assigned a known value (NULL), > > > dev- > > > >header_cache_update is not set to a known value: > > > > > > dev->hard_start_xmit = hdlc->xmit; > > > dev->hard_header = cisco_hard_header; > > > dev->hard_header_cache = NULL; > > > dev->type = ARPHRD_CISCO; > > > dev->flags = IFF_POINTOPOINT | IFF_NOARP; > > > dev->addr_len = 0; > > > > > > This may cause serious problems when dev->header_cache_update is invoked, > > > because it has an uninitialized value. > > > > > > Steps to reproduce: > > > > > > I found this suspicious spot with the help of a code-checking tool. > > > > > > > Like this? > > Not necessary, since any network device must already allocated by > alloc_netdev() and it initializes the whole struct to 0 (NULL). But ioctl(IF_PROTO_CISCO) can be run multiple times across the lifetime of a net_device? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.21 4/6] iw_cxgb3: Squelch logging AE errors.
Squelch logging AE errors. Only post one AE error for a given connection in the kernel log. Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- drivers/infiniband/hw/cxgb3/iwch_ev.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/hw/cxgb3/iwch_ev.c b/drivers/infiniband/hw/cxgb3/iwch_ev.c index 54362af..b406766 100644 --- a/drivers/infiniband/hw/cxgb3/iwch_ev.c +++ b/drivers/infiniband/hw/cxgb3/iwch_ev.c @@ -47,12 +47,6 @@ static void post_qp_event(struct iwch_de struct iwch_qp_attributes attrs; struct iwch_qp *qhp; - printk(KERN_ERR "%s - AE qpid 0x%x opcode %d status 0x%x " - "type %d wrid.hi 0x%x wrid.lo 0x%x \n", __FUNCTION__, - CQE_QPID(rsp_msg->cqe), CQE_OPCODE(rsp_msg->cqe), - CQE_STATUS(rsp_msg->cqe), CQE_TYPE(rsp_msg->cqe), - CQE_WRID_HI(rsp_msg->cqe), CQE_WRID_LOW(rsp_msg->cqe)); - spin_lock(&rnicp->lock); qhp = get_qhp(rnicp, CQE_QPID(rsp_msg->cqe)); @@ -73,6 +67,12 @@ static void post_qp_event(struct iwch_de return; } + printk(KERN_ERR "%s - AE qpid 0x%x opcode %d status 0x%x " + "type %d wrid.hi 0x%x wrid.lo 0x%x \n", __FUNCTION__, + CQE_QPID(rsp_msg->cqe), CQE_OPCODE(rsp_msg->cqe), + CQE_STATUS(rsp_msg->cqe), CQE_TYPE(rsp_msg->cqe), + CQE_WRID_HI(rsp_msg->cqe), CQE_WRID_LOW(rsp_msg->cqe)); + atomic_inc(&qhp->refcnt); spin_unlock(&rnicp->lock); - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.21 2/6] iw_cxgb3: Move QP to error on destroy if the state is IDLE.
Move QP to error on destroy if the state is IDLE.
Change iwch_destroy_qp() to always move the QP to ERROR and let
iwch_modify_qp() decide what to do.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_provider.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c
b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index 9947a14..a56c902 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -736,10 +736,8 @@ static int iwch_destroy_qp(struct ib_qp
qhp = to_iwch_qp(ib_qp);
rhp = qhp->rhp;
- if (qhp->attr.state == IWCH_QP_STATE_RTS) {
- attrs.next_state = IWCH_QP_STATE_ERROR;
- iwch_modify_qp(rhp, qhp, IWCH_QP_ATTR_NEXT_STATE, &attrs, 0);
- }
+ attrs.next_state = IWCH_QP_STATE_ERROR;
+ iwch_modify_qp(rhp, qhp, IWCH_QP_ATTR_NEXT_STATE, &attrs, 0);
wait_event(qhp->wait, !qhp->ep);
remove_handle(rhp, &rhp->qpidr, qhp->wq.qpid);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.21 6/6] iw_cxgb3: Fix MR permission problems.
Fix MR permission problems.
- remove useless and redundant iwch_mem_perms enum.
- create ib_to_tpt_access_rights() for mapping ib access rights
to T3 TPT permissions.
- create ib_to_mwbind_access_rights() for mapping ib access rights
to T3 MWBIND WR permissions.
- fix up the mem reg code to utilize the new functions.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_provider.c | 24 +++-
drivers/infiniband/hw/cxgb3/iwch_provider.h | 33 +++
drivers/infiniband/hw/cxgb3/iwch_qp.c |2 +-
3 files changed, 18 insertions(+), 41 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.c
b/drivers/infiniband/hw/cxgb3/iwch_provider.c
index a56c902..4af1c0f 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.c
@@ -463,9 +463,6 @@ static struct ib_mr *iwch_register_phys_
php = to_iwch_pd(pd);
rhp = php->rhp;
- acc = iwch_convert_access(acc);
-
-
mhp = kzalloc(sizeof(*mhp), GFP_KERNEL);
if (!mhp)
return ERR_PTR(-ENOMEM);
@@ -491,12 +488,7 @@ static struct ib_mr *iwch_register_phys_
mhp->attr.pdid = php->pdid;
mhp->attr.zbva = 0;
- /* NOTE: TPT perms are backwards from BIND WR perms! */
- mhp->attr.perms = (acc & 0x1) << 3;
- mhp->attr.perms |= (acc & 0x2) << 1;
- mhp->attr.perms |= (acc & 0x4) >> 1;
- mhp->attr.perms |= (acc & 0x8) >> 3;
-
+ mhp->attr.perms = iwch_ib_to_tpt_access(acc);
mhp->attr.va_fbo = *iova_start;
mhp->attr.page_size = shift - 12;
@@ -525,7 +517,6 @@ static int iwch_reregister_phys_mem(stru
struct iwch_mr mh, *mhp;
struct iwch_pd *php;
struct iwch_dev *rhp;
- int new_acc;
__be64 *page_list = NULL;
int shift = 0;
u64 total_size;
@@ -546,14 +537,12 @@ static int iwch_reregister_phys_mem(stru
if (rhp != php->rhp)
return -EINVAL;
- new_acc = mhp->attr.perms;
-
memcpy(&mh, mhp, sizeof *mhp);
if (mr_rereg_mask & IB_MR_REREG_PD)
php = to_iwch_pd(pd);
if (mr_rereg_mask & IB_MR_REREG_ACCESS)
- mh.attr.perms = iwch_convert_access(acc);
+ mh.attr.perms = iwch_ib_to_tpt_access(acc);
if (mr_rereg_mask & IB_MR_REREG_TRANS)
ret = build_phys_page_list(buffer_list, num_phys_buf,
iova_start,
@@ -568,7 +557,7 @@ static int iwch_reregister_phys_mem(stru
if (mr_rereg_mask & IB_MR_REREG_PD)
mhp->attr.pdid = php->pdid;
if (mr_rereg_mask & IB_MR_REREG_ACCESS)
- mhp->attr.perms = acc;
+ mhp->attr.perms = iwch_ib_to_tpt_access(acc);
if (mr_rereg_mask & IB_MR_REREG_TRANS) {
mhp->attr.zbva = 0;
mhp->attr.va_fbo = *iova_start;
@@ -613,8 +602,6 @@ static struct ib_mr *iwch_reg_user_mr(st
goto err;
}
- acc = iwch_convert_access(acc);
-
i = n = 0;
list_for_each_entry(chunk, ®ion->chunk_list, list)
@@ -630,10 +617,7 @@ static struct ib_mr *iwch_reg_user_mr(st
mhp->rhp = rhp;
mhp->attr.pdid = php->pdid;
mhp->attr.zbva = 0;
- mhp->attr.perms = (acc & 0x1) << 3;
- mhp->attr.perms |= (acc & 0x2) << 1;
- mhp->attr.perms |= (acc & 0x4) >> 1;
- mhp->attr.perms |= (acc & 0x8) >> 3;
+ mhp->attr.perms = iwch_ib_to_tpt_access(acc);
mhp->attr.va_fbo = region->virt_base;
mhp->attr.page_size = shift - 12;
mhp->attr.len = (u32) region->length;
diff --git a/drivers/infiniband/hw/cxgb3/iwch_provider.h
b/drivers/infiniband/hw/cxgb3/iwch_provider.h
index de0fe1b..93bcc56 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_provider.h
+++ b/drivers/infiniband/hw/cxgb3/iwch_provider.h
@@ -286,27 +286,20 @@ static inline int iwch_convert_state(enu
}
}
-enum iwch_mem_perms {
- IWCH_MEM_ACCESS_LOCAL_READ = 1 << 0,
- IWCH_MEM_ACCESS_LOCAL_WRITE = 1 << 1,
- IWCH_MEM_ACCESS_REMOTE_READ = 1 << 2,
- IWCH_MEM_ACCESS_REMOTE_WRITE = 1 << 3,
- IWCH_MEM_ACCESS_ATOMICS = 1 << 4,
- IWCH_MEM_ACCESS_BINDING = 1 << 5,
- IWCH_MEM_ACCESS_LOCAL =
- (IWCH_MEM_ACCESS_LOCAL_READ | IWCH_MEM_ACCESS_LOCAL_WRITE),
- IWCH_MEM_ACCESS_REMOTE =
- (IWCH_MEM_ACCESS_REMOTE_WRITE | IWCH_MEM_ACCESS_REMOTE_READ)
- /* cannot go beyond 1 << 31 */
-} __attribute__ ((packed));
-
-static inline u32 iwch_convert_access(int acc)
+static inline u32 iwch_ib_to_tpt_access(int acc)
{
- return (acc & IB_ACCESS_REMOTE_WRITE ? IWCH_MEM_ACCESS_REMOTE_WRITE : 0)
- | (acc & IB_ACCESS_REMOTE_READ ? IWCH_MEM_ACCESS_REMOTE_READ : 0) |
- (acc & IB_ACCESS_LOCAL_WRITE ? IWCH_MEM_ACCESS_LOCAL_WRITE : 0) |
- (acc & IB_ACCESS_MW_BIND ? IWCH_MEM_ACCESS_BINDING : 0) |
[PATCH 2.6.21 3/6] iw_cxgb3: Stop the endpoint timer when the MPA exchange is aborted by the peer.
Stop the endpoint timer when the MPA exchange is aborted by the peer. Signed-off-by: Steve Wise <[EMAIL PROTECTED]> --- drivers/infiniband/hw/cxgb3/iwch_cm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c b/drivers/infiniband/hw/cxgb3/iwch_cm.c index 1dcfedc..8e6f6df 100644 --- a/drivers/infiniband/hw/cxgb3/iwch_cm.c +++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c @@ -1487,8 +1487,10 @@ static int peer_abort(struct t3cdev *tde case CONNECTING: break; case MPA_REQ_WAIT: + stop_ep_timer(ep); break; case MPA_REQ_SENT: + stop_ep_timer(ep); connect_reply_upcall(ep, -ECONNRESET); break; case MPA_REP_SENT: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.21 5/6] iw_cxgb3: Don't reuse skbuffs that are non-linear or cloned.
Don't reuse skbuffs that are non-linear or cloned.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_cm.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index 8e6f6df..fd2f3ca 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -305,8 +305,7 @@ static int status2errno(int status)
*/
static struct sk_buff *get_skb(struct sk_buff *skb, int len, gfp_t gfp)
{
- if (skb) {
- BUG_ON(skb_cloned(skb));
+ if (skb && !skb_is_nonlinear(skb) && !skb_cloned(skb)) {
skb_trim(skb, 0);
skb_get(skb);
} else {
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.21 1/6] iw_cxgb3: Fixes for "normal close" failures.
Fixes for "normal close" failures.
- Start normal close timer when moving to CLOSING state.
- Handle ABORTING state in close_con_rpl().
- Stop timer correctly on abort during a normal close.
Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/iwch_cm.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index b21fde8..1dcfedc 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -1415,6 +1415,7 @@ static int peer_close(struct t3cdev *tde
wake_up(&ep->com.waitq);
break;
case FPDU_MODE:
+ start_ep_timer(ep);
__state_set(&ep->com, CLOSING);
attrs.next_state = IWCH_QP_STATE_CLOSING;
iwch_modify_qp(ep->com.qp->rhp, ep->com.qp,
@@ -1425,7 +1426,6 @@ static int peer_close(struct t3cdev *tde
disconnect = 0;
break;
case CLOSING:
- start_ep_timer(ep);
__state_set(&ep->com, MORIBUND);
disconnect = 0;
break;
@@ -1507,9 +1507,10 @@ static int peer_abort(struct t3cdev *tde
get_ep(&ep->com);
break;
case MORIBUND:
+ case CLOSING:
stop_ep_timer(ep);
+ /*FALLTHROUGH*/
case FPDU_MODE:
- case CLOSING:
if (ep->com.cm_id && ep->com.qp) {
attrs.next_state = IWCH_QP_STATE_ERROR;
ret = iwch_modify_qp(ep->com.qp->rhp,
@@ -1570,7 +1571,6 @@ static int close_con_rpl(struct t3cdev *
spin_lock_irqsave(&ep->com.lock, flags);
switch (ep->com.state) {
case CLOSING:
- start_ep_timer(ep);
__state_set(&ep->com, MORIBUND);
break;
case MORIBUND:
@@ -1586,6 +1586,8 @@ static int close_con_rpl(struct t3cdev *
__state_set(&ep->com, DEAD);
release = 1;
break;
+ case ABORTING:
+ break;
case DEAD:
default:
BUG_ON(1);
@@ -1659,6 +1661,7 @@ static void ep_timeout(unsigned long arg
break;
case MPA_REQ_WAIT:
break;
+ case CLOSING:
case MORIBUND:
if (ep->com.cm_id && ep->com.qp) {
attrs.next_state = IWCH_QP_STATE_ERROR;
@@ -1957,11 +1960,11 @@ int iwch_ep_disconnect(struct iwch_ep *e
case MPA_REQ_RCVD:
case MPA_REP_SENT:
case FPDU_MODE:
+ start_ep_timer(ep);
ep->com.state = CLOSING;
close = 1;
break;
case CLOSING:
- start_ep_timer(ep);
ep->com.state = MORIBUND;
close = 1;
break;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.21 0/6] iw_cxgb3: Bug Fixes
Hey Roland, Here is a set of bug fixes for iw_cxgb3 that I'd like to roll into 2.6.21. Thanks, Steve. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8107] New: dev->header_cache_update has a random value
On Thu, 1 Mar 2007 14:34:17 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 1 Mar 2007 11:33:05 -0800 > [EMAIL PROTECTED] wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=8107 > > > >Summary: dev->header_cache_update has a random value > > Kernel Version: 2.6.20 > > Status: NEW > > Severity: high > > Owner: [EMAIL PROTECTED] > > Submitter: [EMAIL PROTECTED] > > > > > > Distribution: Kernel 2.6.20 > > > > Problem Description: > > > > In struct net_device, there are two fields: hard_header_cache and > > header_cache_update, both of which are function pointers. The third field, > > hard_header, is also a function pointer. Whenever hard_header points to a > > valid > > function, both hard_header_cache and header_cache_update should have a > > known > > value, either NULL or a valid function pointer. However, in > > drivers/net/wan/hdlc_cisco.c, in function static int cisco_ioctl(struct > > net_device *dev, struct ifreq *ifr), where dev->hard_header is assigned a > > valid > > function, and dev->hard_header_cache is assigned a known value (NULL), dev- > > >header_cache_update is not set to a known value: > > > > dev->hard_start_xmit = hdlc->xmit; > > dev->hard_header = cisco_hard_header; > > dev->hard_header_cache = NULL; > > dev->type = ARPHRD_CISCO; > > dev->flags = IFF_POINTOPOINT | IFF_NOARP; > > dev->addr_len = 0; > > > > This may cause serious problems when dev->header_cache_update is invoked, > > because it has an uninitialized value. > > > > Steps to reproduce: > > > > I found this suspicious spot with the help of a code-checking tool. > > > > Like this? Not necessary, since any network device must already allocated by alloc_netdev() and it initializes the whole struct to 0 (NULL). -- 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: [Bugme-new] [Bug 8107] New: dev->header_cache_update has a random value
On Thu, 1 Mar 2007 11:33:05 -0800 [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8107 > >Summary: dev->header_cache_update has a random value > Kernel Version: 2.6.20 > Status: NEW > Severity: high > Owner: [EMAIL PROTECTED] > Submitter: [EMAIL PROTECTED] > > > Distribution: Kernel 2.6.20 > > Problem Description: > > In struct net_device, there are two fields: hard_header_cache and > header_cache_update, both of which are function pointers. The third field, > hard_header, is also a function pointer. Whenever hard_header points to a > valid > function, both hard_header_cache and header_cache_update should have a known > value, either NULL or a valid function pointer. However, in > drivers/net/wan/hdlc_cisco.c, in function static int cisco_ioctl(struct > net_device *dev, struct ifreq *ifr), where dev->hard_header is assigned a > valid > function, and dev->hard_header_cache is assigned a known value (NULL), dev- > >header_cache_update is not set to a known value: > > dev->hard_start_xmit = hdlc->xmit; > dev->hard_header = cisco_hard_header; > dev->hard_header_cache = NULL; > dev->type = ARPHRD_CISCO; > dev->flags = IFF_POINTOPOINT | IFF_NOARP; > dev->addr_len = 0; > > This may cause serious problems when dev->header_cache_update is invoked, > because it has an uninitialized value. > > Steps to reproduce: > > I found this suspicious spot with the help of a code-checking tool. > Like this? From: Andrew Morton <[EMAIL PROTECTED]> Fix http://bugzilla.kernel.org/show_bug.cgi?id=8107: we weren't initialising the header_cache_update field. Cc: Krzysztof Halasa <[EMAIL PROTECTED]> Cc: "David S. Miller" <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/wan/hdlc_cisco.c |1 + 1 files changed, 1 insertion(+) diff -puN drivers/net/wan/hdlc_cisco.c~cisco_ioctl-initialise-header_cache_update drivers/net/wan/hdlc_cisco.c --- a/drivers/net/wan/hdlc_cisco.c~cisco_ioctl-initialise-header_cache_update +++ a/drivers/net/wan/hdlc_cisco.c @@ -366,6 +366,7 @@ static int cisco_ioctl(struct net_device dev->hard_start_xmit = hdlc->xmit; dev->hard_header = cisco_hard_header; dev->hard_header_cache = NULL; + dev->header_cache_update = NULL; dev->type = ARPHRD_CISCO; dev->flags = IFF_POINTOPOINT | IFF_NOARP; dev->addr_len = 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
Network activity LED trigger
Hi All, I have been talking a bit with Richard, who is the LED API maintainer, and a LED trigger based on network activity would be something great. There are somethings that concern the network stack : - should we specify if the network driver is allowed to contribute to the LED activity, just like it is done for random generation, at compile time - I would like to trigger the LED based on one or several network interfaces, maybe specify via sysfs which interface triggers which LED, and also maybe differentiate the layer-2 activity from the layer-3 activity for instance - A led driver could by default be bound to a network driver, or an interface name As it could be very intrusive in the network stack, you might want to specify a bit more how you imagine a network activity trigger. 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] bonding: Improve IGMP join processing
Andy Gospodarek <[EMAIL PROTECTED]> wrote: >On Thu, Mar 01, 2007 at 02:25:19PM -0500, Brian Haley wrote: [...] >> So forgive my naive question, but what would it take to make IPv6 work? >> I know DAD fails on a test setup I have, but I haven't dug-into why >> this is (I can guess), and I'd like to see it working. I'm willing to >> help, even if just to get it limping along. >> > >Brian, > >If we are easily able to differentiate between the multicast addresses >in the mc_list as to which are for ipv4 and which are for ipv6 then it >would be easy to call-out to something in the ipv6 mcast code when >needed instead of always calling out to ipv4 code. Which covers multicast (at least for the failover case; I think the regular support is already pretty address-independent). Additionally, the IP address tracking for the ARP monitor (bond_glean_dev_ip) needs IPv6 address support. I seem to recall that there's an issue with the slaves each getting separate link local addresses automatically assigned, but I haven't fooled with that in a while. There are likely other problems that would crop up during serious testing. A characterization of what the IPv6 related problems are would be a good place to start; I would expect that active-backup mode without arp_monitor shouldn't be too difficult to make operable. -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: [PATCH] e1000 stop raw interrupts disabled nag from RT
Michal Schmidt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kok, Auke wrote: Mark Huth wrote: Well, I'm not an expert on the realtime patches - but most any patch set from Ingo seems to set this off - we've run through a bunch all the way since 2.6.10. that's bizarre, and would imply that Ingo himself never spotted this in ages, not to mention never tell us about it? Ingo's -rt patches have contained this change to e1000 for some time. The code is perfectly fine as is for non-RT kernels, so maybe that's why noone felt like telling you about it. Michal -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFF5wlZabKV90ewf0QRAse3AJ979xur0u8X1DokSzaAMvLQCWPkXACfU9ss xC05DAbFNAaFMLnQrzBKit0= =I5mt -END PGP SIGNATURE- Ah, tis true indeed. This only shows up when one brings a newer driver forward after the RT patch has been applied. I guess you would need to coordinate this with Ingo. Thanks, Mark Huth - 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: Network access fails unless tcpdump is running?
On Thu, Mar 01, 2007 at 03:54:58PM -0500, Marc D Ronell wrote: > Andy Gospodarek <[EMAIL PROTECTED]> writes: > > > On Thu, Mar 01, 2007 at 02:22:24PM -0500, Marc D Ronell wrote: > >> > >> Hi, > >> > >> I can not ping a remote host successfully unless I have "tcpdump -i > >> eth0" running, in which case, my network access works fine. > > > > Interesting that when your interface is in promiscious mode it works > > fine, but otherwise it doesn't. Do you have all of your iptables rules > > cleared? > > > > Thanks very much for your reply and interest. I find this an odd > problem. The output of iptables -L looks like: > >caviar:/tmp# iptables -L >Chain INPUT (policy ACCEPT) >target prot opt source destination > >Chain FORWARD (policy ACCEPT) >target prot opt source destination > >Chain OUTPUT (policy ACCEPT) >target prot opt source destination > > The machine name is caviar on the prompt. There are no rules in > place. AFAIK, there are no firewalls running. Changing the routing > table did not help the situation. > Looks good. > > >> I am running Debian etch on a Dell Inspiron e1505 laptop. The eth0 > >> address is static on my local LAN. Once tcpdump is running, the > >> laptop can access the network with no problems. > > > > What networking hardware is on that laptop? Can you post the complete > > output of `ethtool -i eth0` and the network device info from the output > > of `lcpci -vvv`? > > lspci output is attached below. > I presumed this is with the wired interface (not the wireless one). That is a correct assumption, right? Can you post the output from `ethtool -i ethX` (where ethX is the wired interface). I ask because that tells me what version of the b44/ipw3945 driver you are using. > caviar:/tmp# lspci -vvv > 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT > Express Memory Controller Hub (rev 03) > Subsystem: Dell Unknown device 01bd > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Capabilities: [e0] Vendor Specific Information > > 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT > Express PCI Express Root Port (rev 03) (prog-if 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 64 bytes > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > I/O behind bridge: e000-efff > Memory behind bridge: dfd0-dfef > Prefetchable memory behind bridge: c000-cfff > Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- > BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B- > Capabilities: [88] Subsystem: Dell Unknown device 01bd > Capabilities: [80] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- > Queue=0/0 Enable+ > Address: fee0 Data: 40c1 > Capabilities: [a0] Express Root Port (Slot+) IRQ 0 > Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- > Device: Latency L0s <64ns, L1 <1us > Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- > Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- > Device: MaxPayload 128 bytes, MaxReadReq 128 bytes > Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 2 > Link: Latency L0s <256ns, L1 <4us > Link: ASPM L1 Enabled RCB 64 bytes CommClk+ ExtSynch- > Link: Speed 2.5Gb/s, Width x16 > Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- > Slot: Number 1, PowerLimit 75.00 > Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- > Slot: AttnInd Off, PwrInd On, Power- > Root: Correctable- Non-Fatal- Fatal- PME- > Capabilities: [100] Virtual Channel > Capabilities: [140] Unknown (5) > > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition > Audio Controller (rev 01) > Subsystem: Dell Unknown device 01bd > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Si
Application on MASQ node can hijack port used by application on gateway
When nodes on the LAN are masqueraded Linux on the gateway will attempt to use the same port that an app on the LAN used. This can only be done once after which Linux will arbitrarily assign ports. Using the example of VoIP phones which use a default port of 5060, the first phone to register with proxy server will be assigned port 5060 on the gateway and the second would be assigned port 1024. Keep-alive packets are used by the phones, the proxy or both to maintain the NAT bindings. The proxy makes note of the originating port. Incoming packets are routed correctly. Now consider the case of a application running on the gateway box. It would send and listen on port 5060. In this case we would not use keep-alive packets. We open port 5060 on the firewall so that we can receive calls from the public internet. I have observed that a phone on the LAN can bind to port 5060 even though the application had grabbed port 5060. The result is that packets intended for the application will be routed to the phone on the LAN. The phone on the LAN also gets packets intended for it. This was confirmed by /proc/net/ip_conntrack and also by capturing packets with a sniffer. The contents of the packets showed that some of the packets were clearly not intended for the phone that received them. The application listening on port 5060 received nothing. Rob Dyck - 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: Network access fails unless tcpdump is running?
Andy Gospodarek <[EMAIL PROTECTED]> writes: > On Thu, Mar 01, 2007 at 02:22:24PM -0500, Marc D Ronell wrote: >> >> Hi, >> >> I can not ping a remote host successfully unless I have "tcpdump -i >> eth0" running, in which case, my network access works fine. > > Interesting that when your interface is in promiscious mode it works > fine, but otherwise it doesn't. Do you have all of your iptables rules > cleared? > Thanks very much for your reply and interest. I find this an odd problem. The output of iptables -L looks like: caviar:/tmp# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination The machine name is caviar on the prompt. There are no rules in place. AFAIK, there are no firewalls running. Changing the routing table did not help the situation. >> I am running Debian etch on a Dell Inspiron e1505 laptop. The eth0 >> address is static on my local LAN. Once tcpdump is running, the >> laptop can access the network with no problems. > > What networking hardware is on that laptop? Can you post the complete > output of `ethtool -i eth0` and the network device info from the output > of `lcpci -vvv`? lspci output is attached below. caviar:/tmp# lspci -vvv 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Dell Unknown device 01bd Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [88] Subsystem: Dell Unknown device 01bd Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0 Data: 40c1 Capabilities: [a0] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 2 Link: Latency L0s <256ns, L1 <4us Link: ASPM L1 Enabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x16 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 1, PowerLimit 75.00 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [100] Virtual Channel Capabilities: [140] Unknown (5) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Subsystem: Dell Unknown device 01bd Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable- Non-Fatal- Fatal+ Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <256ns, L1 <4us Link: ASPM L1 Enabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 2, PowerLimit 6.50 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet+ CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+ Address: fee0 Data: 40c9 Capabilities: [90] Subsystem: Dell Unknown device 01bd Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Re: [RFC PATCH] [TCP]: Move clearing of the prior_ssthresh due to ECE earlier
On Thu, 1 Mar 2007, Ilpo Järvinen wrote: > Previously the prior_ssthresh was only used in the undo functions > that were called by fastretrans_alert. FRTO processing, however, > happens before that and one of the responses is doing undo too. > > I think that after this patch, FRTO should be ECN-safe; only the > undo_cwr response is a suspect anyway. The possible cases: > [...snip...] > > This problem could be solved locally in the undo_cwr response of > FRTO by falling back to ratehalving response when FLAG_ECE is > enabled. I think that doing it in the response is better that this approach, since it knows that the ssthresh has been halved already within that round-trip, so there is no need to do that again... I'll submit the patch tomorrow... With this prior_ssthresh clearing move alone, the ssthresh ends up being halved twice if I tought it right (first in tcp_enter_frto and then again in tcp_enter_cwr that is called from fastretrans_alert)... So please, drop this patch. -- i.
Re: Network access fails unless tcpdump is running?
On Thu, Mar 01, 2007 at 02:22:24PM -0500, Marc D Ronell wrote: > > Hi, > > I can not ping a remote host successfully unless I have "tcpdump -i > eth0" running, in which case, my network access works fine. Interesting that when your interface is in promiscious mode it works fine, but otherwise it doesn't. Do you have all of your iptables rules cleared? > I am running Debian etch on a Dell Inspiron e1505 laptop. The eth0 > address is static on my local LAN. Once tcpdump is running, the > laptop can access the network with no problems. What networking hardware is on that laptop? Can you post the complete output of `ethtool -i eth0` and the network device info from the output of `lcpci -vvv`? - 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] bonding: Improve IGMP join processing
On Thu, Mar 01, 2007 at 02:25:19PM -0500, Brian Haley wrote: > Jay Vosburgh wrote: > >>My only concern is that this code assumes all mcast addresses stored in > >>dev->mc-list list are for ipv4 igmp mcast addresses and nothing was done > >>for ipv6. > >> > >>But this is much better than what we have now, so... > > > > Agreed, but there's no IPv6 support anywhere in bonding at > >present (for unicast or multicast), so this isn't really a loss. > > So forgive my naive question, but what would it take to make IPv6 work? > I know DAD fails on a test setup I have, but I haven't dug-into why > this is (I can guess), and I'd like to see it working. I'm willing to > help, even if just to get it limping along. > Brian, If we are easily able to differentiate between the multicast addresses in the mc_list as to which are for ipv4 and which are for ipv6 then it would be easy to call-out to something in the ipv6 mcast code when needed instead of always calling out to ipv4 code. -andy - 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
Network access fails unless tcpdump is running?
Hi, I can not ping a remote host successfully unless I have "tcpdump -i eth0" running, in which case, my network access works fine. I am running Debian etch on a Dell Inspiron e1505 laptop. The eth0 address is static on my local LAN. Once tcpdump is running, the laptop can access the network with no problems. Any help or suggestions to solving this concern are really appreciated. Thanks, Marc -- - 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.20] kobject net ifindex + rename
On Thu, Mar 01, 2007 at 08:42:09AM +0100, Jarek Poplawski wrote: > On Wed, Feb 28, 2007 at 10:45:41AM -0800, Jean Tourrilhes wrote: > > > > + > > > > + if ((size <= 0) || (i >= num_envp)) > > > > > > Btw.: > > > 1. if size == 10 and snprintf returns 9 (without NULL) > > >then n == 10 (with NULL), so isn't it enough (here and above): > > > > > > if ((size < 0) || (i >= num_envp)) > > > > I just cut'n'pasted the code a few line above. If the original > > code is incorrect, it need fixing. And it will need fixing in probably > > a lot of places. > > I think you're kind of responsible for your part, at least. I personally don't go fixing stuff without having a full undersunding of the context and why it was done this way. To me it look this test was intentionally done this way, so there may be something I don't know about. I guess I would need to double check more closely what weid calculation the caller does with the buffer size. That's why I would prefer a separate patch about those issues that give the opportunity for the stakeholder to really talk about this, rather than slipping it under the carpet. In the worse case, this is not a bug, this just means that we may not use the last char of the buffer. > > > 2. shouldn't there be (here and above): > > > > > > envp[--i] = NULL; > > > > > > > No, envp is local, so who cares. > > But envp[i] isn't (at least here). So, I guess, a caller > of this function could care. Check the full source code of the caller, and you will see that the caller does not care (and it's local to the caller). > > > > + if ((size <= 0) || (i >= num_envp)) > > > > + return -ENOMEM; > > And one more thing (not necessarily for you): > ENOBUFS is probably more adequate here. This error should never happen. If it happens, the caller need to be fixed. > Cheers, > Jarek P. Note that there are various other things that are puzzling in this function. The internal object name and the symlinks are changed even if the kcore rename returns an error. That does not seem right. But, this is separate from this patch... Have fun... Jean - 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] bonding: Improve IGMP join processing
Jay Vosburgh wrote: My only concern is that this code assumes all mcast addresses stored in dev->mc-list list are for ipv4 igmp mcast addresses and nothing was done for ipv6. But this is much better than what we have now, so... Agreed, but there's no IPv6 support anywhere in bonding at present (for unicast or multicast), so this isn't really a loss. So forgive my naive question, but what would it take to make IPv6 work? I know DAD fails on a test setup I have, but I haven't dug-into why this is (I can guess), and I'd like to see it working. I'm willing to help, even if just to get it limping along. -Brian - 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: CLOCK_MONOTONIC datagram timestamps by the kernel
On Thu, 1 Mar 2007 12:30:50 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote: > On Wednesday 28 February 2007 17:07, John wrote: > > > > > Consider an idle Linux 2.6.20-rt8 system, equipped with a single PCI-E > > gigabit Ethernet NIC, running on a modern CPU (e.g. Core 2 Duo E6700). > > All this system does is time stamp 1000 packets per second. > > > > Are you claiming that this platform *cannot* handle most packets within > > less than 1 microsecond of their arrival? > > Yes I claim it. > > You expect too much of this platform, unless "most" means 10 % for > you ;) > > If you replace "1 us" by "50 us", then yes, it probably can do it, if "most" > means 99%, (not 99.999 %) > > Anyway, if you want to play, you can apply this patch on top of > linux-2.6.21-rc2 (nanosecond resolution infrastruture needs 2.6.21) > I let you do the adjustments for rt kernel. > > I compiled it on my i386 machine, and tested it with a patched libpcap/tcpdump > > [PATCH] NET : introduce nanosecond time infrastructure and SIOCGSTAMPNS > > It appears some machines are *really* fast and that micro second resolution > is > a limiting factor. > > This patch converts sk_buff timestamp to use new nanosecond infra (added in > 2.6.21), and introduces a new ioctl SIOCGSTAMPNS to let applications access > nanosecond resolution (ie a timespec instead of timeval) > > > Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> > You probably want to add a SO_TIMESTAMPNS setsockopt() value like existing SO_TIMESTAMP Also use NSEC_PER_USEC rather than hardcoded 1000. -- 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: [PATCH -mm 3/5] Blackfin: on-chip ethernet MAC controller driver
On Thu 1 Mar 2007 10:52, Stephen Hemminger pondered: > Wu, Bryan wrote: > > Hi folks, > > > > Here is the blackfin on-chip ethernet MAC controller driver for Linux. > > > > Index: linux-2.6/drivers/net/Kconfig > > === > > --- linux-2.6.orig/drivers/net/Kconfig 2007-03-01 11:39:14.0 > > +0800 +++ linux-2.6/drivers/net/Kconfig 2007-03-01 11:39:19.0 > > +0800 @@ -836,6 +836,50 @@ > > module, say M here and read as well > > as . > > > > +config BFIN_MAC > > + tristate "Blackfin 536/537 on-chip mac support" > > + depends on NET_ETHERNET && (BF537 || BF536) && (!BF537_PORT_H) > > + select CRC32 > > + select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE > > + help > > + This is the driver for blackfin on-chip mac device. Say Y if you want > > it + compiled into the kernel. This driver is also available as a > > module + ( = code which can be inserted in and removed from the running > > kernel + whenever you want). The module will be called bfin_mac. > > + > > +config BFIN_MAC_USE_L1 > > + bool "Use L1 memory for rx/tx packets" > > + depends on BFIN_MAC && BF537 > > + default y > > + help > > + To get maximum network performace, you should use L1 memory as rx/tx > > buffers. +Say N here if you want to reserve L1 memory for other uses. > > + > > +config BFIN_TX_DESC_NUM > > + int "Number of transmit buffer packets" > > + depends on BFIN_MAC > > + range 6 10 if BFIN_MAC_USE_L1 > > + range 10 100 > > + default "10" > > + help > > + Set the number of buffer packets used in driver. > > + > > +config BFIN_RX_DESC_NUM > > + int "Number of receive buffer packets" > > + depends on BFIN_MAC > > + range 20 100 if BFIN_MAC_USE_L1 > > + range 20 800 > > + default "20" > > + help > > + Set the number of buffer packets used in driver > > The regular practice is to put these in a device include file, and not > make them kernel configurable. > Why would you want to make it tuneable at compile time? It is to attempt to make it easier for our end users to configure&use. Most people who use it, want to make some tweaks to the configuration based on their embedded platform. Rather than forcing everyone to make changes to a .c or .h file, we let them manage it in the .config (which is platforms specific anyway). -Robin - 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 -mm 3/5] Blackfin: on-chip ethernet MAC controller driver
On 3/1/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote: Wu, Bryan wrote: > +config BFIN_MAC > + tristate "Blackfin 536/537 on-chip mac support" > + depends on NET_ETHERNET && (BF537 || BF536) && (!BF537_PORT_H) > + select CRC32 > + select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE > + help > + This is the driver for blackfin on-chip mac device. Say Y if you want it > + compiled into the kernel. This driver is also available as a module > + ( = code which can be inserted in and removed from the running kernel > + whenever you want). The module will be called bfin_mac. > + > +config BFIN_MAC_USE_L1 > + bool "Use L1 memory for rx/tx packets" > + depends on BFIN_MAC && BF537 > + default y > + help > + To get maximum network performace, you should use L1 memory as rx/tx buffers. > + Say N here if you want to reserve L1 memory for other uses. > + > +config BFIN_TX_DESC_NUM > + int "Number of transmit buffer packets" > + depends on BFIN_MAC > + range 6 10 if BFIN_MAC_USE_L1 > + range 10 100 > + default "10" > + help > + Set the number of buffer packets used in driver. > + > +config BFIN_RX_DESC_NUM > + int "Number of receive buffer packets" > + depends on BFIN_MAC > + range 20 100 if BFIN_MAC_USE_L1 > + range 20 800 > + default "20" > + help > + Set the number of buffer packets used in driver > The regular practice is to put these in a device include file, and not make them kernel configurable. we're working on moving some of this stuff into the board files rather than Kconfig Why would you want to make it tuneable at compile time? because it was easier to implement and deploy the first time around ;) -mike - 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 4/4]: Kill fastpath_{skb,cnt}_hint.
* David Miller <[EMAIL PROTECTED]> [070228 21:49]:
>
> commit 71b270d966cd42e29eabcd39434c4ad4d33aa2be
> Author: David S. Miller <[EMAIL PROTECTED]>
> Date: Tue Feb 27 19:28:07 2007 -0800
>
> [TCP]: Kill fastpath_{skb,cnt}_hint.
>
> Now that we have per-skb fack_counts and an interval
> search mechanism for the retransmit queue, we don't
> need these things any more.
>
> Instead, as we traverse the SACK blocks to tag the
> queue, we use the RB tree to lookup the first SKB
> covering the SACK block by sequence number.
>
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
If you take this approach it makes sense to also remove the sorting of
SACKs, the traversal of the SACK blocks will not start from the
beginning anyway which was the reason for this sorting in the first
place.
One drawback for this approach is that you now walk the entire sack
block when you advance one packet. If you consider a 10,000 packet queue
which had several losses at the beginning and a large sack block that
advances from the middle to the end you'll walk a lot of packets for
that one last stretch of a sack block.
One way to handle that is to use the still existing sack fast path to
detect this case and calculate what is the sequence number to search
for. Since you know what was the end_seq that was handled last, you can
search for it as the start_seq and go on from there. Does it make sense?
Baruch
-
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
[RFC PATCH] [TCP]: Move clearing of the prior_ssthresh due to ECE earlier
Previously the prior_ssthresh was only used in the undo functions
that were called by fastretrans_alert. FRTO processing, however,
happens before that and one of the responses is doing undo too.
I think that after this patch, FRTO should be ECN-safe; only the
undo_cwr response is a suspect anyway. The possible cases:
1) Pre-RTO ECE: FRTO is not setting prior_ssthresh in
CA_CWR at all, therefore it correctly remains cleared
and ssthresh is the already reduced one
2a) Post-RTO ECE, before deciding ACK: prior_ssthresh is
cleared, so no undoing for ssthresh will occur
2b) Post-RTO ECE, deciding ACK: this patch changes this case
equal to 2a
3) Between two RTOs: prior_ssthresh is cleared like in 2a
or the reduced value is used like in 1
Deciding ACK is the one after which FRTO declared RTO as
spurious.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
This problem could be solved locally in the undo_cwr response of
FRTO by falling back to ratehalving response when FLAG_ECE is
enabled. If it's more preferrable way, just ping me to get a
patch. I'm not absolutely sure that this does not break anything
even though I couldn't find any using prior_ssthresh between
the new and the old place (seen more than once already within
years that things are not always as simple as they seem).
net/ipv4/tcp_input.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index dc221a3..b0c9dfb 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2080,15 +2080,11 @@ tcp_fastretrans_alert(struct sock *sk, u
tp->fackets_out = 0;
/* Now state machine starts.
-* A. ECE, hence prohibit cwnd undoing, the reduction is required. */
- if (flag&FLAG_ECE)
- tp->prior_ssthresh = 0;
-
- /* B. In all the states check for reneging SACKs. */
+* A. In all the states check for reneging SACKs. */
if (tp->sacked_out && tcp_check_sack_reneging(sk))
return;
- /* C. Process data loss notification, provided it is valid. */
+ /* B. Process data loss notification, provided it is valid. */
if ((flag&FLAG_DATA_LOST) &&
before(tp->snd_una, tp->high_seq) &&
icsk->icsk_ca_state != TCP_CA_Open &&
@@ -2097,10 +2093,10 @@ tcp_fastretrans_alert(struct sock *sk, u
NET_INC_STATS_BH(LINUX_MIB_TCPLOSS);
}
- /* D. Synchronize left_out to current state. */
+ /* C. Synchronize left_out to current state. */
tcp_sync_left_out(tp);
- /* E. Check state exit conditions. State can be terminated
+ /* D. Check state exit conditions. State can be terminated
*when high_seq is ACKed. */
if (icsk->icsk_ca_state == TCP_CA_Open) {
BUG_TRAP(tp->retrans_out == 0);
@@ -2143,7 +2139,7 @@ tcp_fastretrans_alert(struct sock *sk, u
}
}
- /* F. Process state. */
+ /* E. Process state. */
switch (icsk->icsk_ca_state) {
case TCP_CA_Recovery:
if (prior_snd_una == tp->snd_una) {
@@ -2742,8 +2738,11 @@ static int tcp_ack(struct sock *sk, stru
if (TCP_SKB_CB(skb)->sacked)
flag |= tcp_sacktag_write_queue(sk, skb, prior_snd_una);
- if (TCP_ECN_rcv_ecn_echo(tp, skb->h.th))
+ if (TCP_ECN_rcv_ecn_echo(tp, skb->h.th)) {
flag |= FLAG_ECE;
+ /* ECE, prohibit cwnd undoing, reduction is required */
+ tp->prior_ssthresh = 0;
+ }
tcp_ca_event(sk, CA_EVENT_SLOW_ACK);
}
--
1.4.2
Re: [PATCH] e1000 stop raw interrupts disabled nag from RT
Kok, Auke wrote: > uhh, sure... while we are at it then, are there any more patches like this? > perhaps for e100? ixgb? A quick grep through the current RT patch shows there are no other changes to e100, e1000, ixgb. Michal - 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] e1000 stop raw interrupts disabled nag from RT
Michal Schmidt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kok, Auke wrote: Mark Huth wrote: Well, I'm not an expert on the realtime patches - but most any patch set from Ingo seems to set this off - we've run through a bunch all the way since 2.6.10. that's bizarre, and would imply that Ingo himself never spotted this in ages, not to mention never tell us about it? Ingo's -rt patches have contained this change to e1000 for some time. The code is perfectly fine as is for non-RT kernels, so maybe that's why noone felt like telling you about it. uhh, sure... while we are at it then, are there any more patches like this? perhaps for e100? ixgb? Cheers, 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] e1000 stop raw interrupts disabled nag from RT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kok, Auke wrote: > Mark Huth wrote: >> Well, I'm not an expert on the realtime patches - but most any patch set >> from Ingo seems to set this off - we've run through a bunch all the way >> since 2.6.10. > > that's bizarre, and would imply that Ingo himself never spotted this in ages, > not to mention never tell us about it? Ingo's -rt patches have contained this change to e1000 for some time. The code is perfectly fine as is for non-RT kernels, so maybe that's why noone felt like telling you about it. Michal -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFF5wlZabKV90ewf0QRAse3AJ979xur0u8X1DokSzaAMvLQCWPkXACfU9ss xC05DAbFNAaFMLnQrzBKit0= =I5mt -END PGP SIGNATURE- - 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] bonding: Improve IGMP join processing
Andy Gospodarek <[EMAIL PROTECTED]> wrote: >On Wed, Feb 28, 2007 at 05:03:37PM -0800, Jay Vosburgh wrote: [...] >My only concern is that this code assumes all mcast addresses stored in >dev->mc-list list are for ipv4 igmp mcast addresses and nothing was done >for ipv6. > >But this is much better than what we have now, so... Agreed, but there's no IPv6 support anywhere in bonding at present (for unicast or multicast), so this isn't really a loss. -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: [PATCH] bonding: replace system timer with work queue
Andrew Morton <[EMAIL PROTECTED]> wrote: >On Wed, 28 Feb 2007 10:12:01 +0100 (CET) Jaroslav Kysela <[EMAIL PROTECTED]> >wrote: >> == >> bonding: replace system timer with work queue >> >> This patch replaces system timer with work queue in monitor functions. >> The reason for this change is that bonding handlers calls various >> sleeping functions from the timer handler which is not allowed. > >Which sleeping functions? I'd have expected the kernel to spew runtime >warnings when this happens, but I don't recall any such reports. This affects one specific mode (balance-alb) in one specific case (moving MAC addresses around, which happens during failover or initialization), and a full fix is more complicated than just a switch to work queues, although that is part of the full fix. There are three things going on: calls to sleeping functions with locks held, the same calls from the timer context, and rtnl hold issues. The actual functions affected are various things called by notifier NETDEV_CHANGEADDR callbacks started by dev_set_mac_address() as well as some of the driver level set_mac_address functions that may sleep. Andy Gospodarek <[EMAIL PROTECTED]> and I have been working jointly on a two phased fix for these problems: he's working up the short term fix, which includes the changeover to workqueues, and I've been working on the long term fix, which involves refactoring the bonding link monitoring and failover system. Jaroslav's patch looks to be a subset of the patch Andy is working on. -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: [PATCH] e1000 stop raw interrupts disabled nag from RT
Mark Huth wrote: Kok, Auke wrote: Mark Huth wrote: Current e1000_xmit_frame spews raw interrupt disabled nag messages when used with RT kernel patches. This patch uses spin_trylock_irqsave, which allows RT patches to properly manage the irq semantics. Looks OK with me on first sight, I'll keep it on my stack and push it upstream after Jesse looks it over. Which -RT paches make this pop up btw? I'd like to repro it. Well, I'm not an expert on the realtime patches - but most any patch set from Ingo seems to set this off - we've run through a bunch all the way since 2.6.10. that's bizarre, and would imply that Ingo himself never spotted this in ages, not to mention never tell us about it? Ingo? - 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] bonding: Improve IGMP join processing
On Wed, Feb 28, 2007 at 05:03:37PM -0800, Jay Vosburgh wrote:
>
> In active-backup mode, the current bonding code duplicates IGMP
> traffic to all slaves, so that switches are up to date in case of a
> failover from an active to a backup interface. If bonding then fails
> back to the original active interface, it is likely that the "active
> slave" switch's IGMP forwarding for the port will be out of date until
> some event occurs to refresh the switch (e.g., a membership query).
>
> This patch alters the behavior of bonding to no longer flood
> IGMP to all ports, and to issue IGMP JOINs to the newly active port at
> the time of a failover. This insures that switches are kept up to date
> for all cases.
>
> "GOELLESCH Niels" <[EMAIL PROTECTED]> originally
> reported this problem, and included a patch. His original patch was
> modified by Jay Vosburgh to additionally remove the existing IGMP flood
> behavior, use RCU, streamline code paths, fix trailing white space, and
> adjust for style.
>
> Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
>
My only concern is that this code assumes all mcast addresses stored in
dev->mc-list list are for ipv4 igmp mcast addresses and nothing was done
for ipv6.
But this is much better than what we have now, so...
Acked-by: Andy Gospodarek <[EMAIL PROTECTED]>
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 7ec6121..338d452 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -60,6 +60,7 @@ #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -861,6 +862,28 @@ static void bond_mc_delete(struct bondin
> }
> }
>
> +
> +/*
> + * Retrieve the list of registered multicast addresses for the bonding
> + * device and retransmit an IGMP JOIN request to the current active
> + * slave.
> + */
> +static void bond_resend_igmp_join_requests(struct bonding *bond)
> +{
> + struct in_device *in_dev;
> + struct ip_mc_list *im;
> +
> + rcu_read_lock();
> + in_dev = __in_dev_get_rcu(bond->dev);
> + if (in_dev) {
> + for (im = in_dev->mc_list; im; im = im->next) {
> + ip_mc_rejoin_group(im);
> + }
> + }
> +
> + rcu_read_unlock();
> +}
> +
> /*
> * Totally destroys the mc_list in bond
> */
> @@ -874,6 +897,7 @@ static void bond_mc_list_destroy(struct
> kfree(dmi);
> dmi = bond->mc_list;
> }
> +bond->mc_list = NULL;
> }
>
> /*
> @@ -967,6 +991,7 @@ static void bond_mc_swap(struct bonding
> for (dmi = bond->dev->mc_list; dmi; dmi = dmi->next) {
> dev_mc_add(new_active->dev, dmi->dmi_addr,
> dmi->dmi_addrlen, 0);
> }
> + bond_resend_igmp_join_requests(bond);
> }
> }
>
> @@ -4017,42 +4042,6 @@ out:
> return 0;
> }
>
> -static void bond_activebackup_xmit_copy(struct sk_buff *skb,
> -struct bonding *bond,
> -struct slave *slave)
> -{
> - struct sk_buff *skb2 = skb_copy(skb, GFP_ATOMIC);
> - struct ethhdr *eth_data;
> - u8 *hwaddr;
> - int res;
> -
> - if (!skb2) {
> - printk(KERN_ERR DRV_NAME ": Error: "
> -"bond_activebackup_xmit_copy(): skb_copy() failed\n");
> - return;
> - }
> -
> - skb2->mac.raw = (unsigned char *)skb2->data;
> - eth_data = eth_hdr(skb2);
> -
> - /* Pick an appropriate source MAC address
> - * -- use slave's perm MAC addr, unless used by bond
> - * -- otherwise, borrow active slave's perm MAC addr
> - * since that will not be used
> - */
> - hwaddr = slave->perm_hwaddr;
> - if (!memcmp(eth_data->h_source, hwaddr, ETH_ALEN))
> - hwaddr = bond->curr_active_slave->perm_hwaddr;
> -
> - /* Set source MAC address appropriately */
> - memcpy(eth_data->h_source, hwaddr, ETH_ALEN);
> -
> - res = bond_dev_queue_xmit(bond, skb2, slave->dev);
> - if (res)
> - dev_kfree_skb(skb2);
> -
> - return;
> -}
>
> /*
> * in active-backup mode, we know that bond->curr_active_slave is always
> valid if
> @@ -4073,21 +4062,6 @@ static int bond_xmit_activebackup(struct
> if (!bond->curr_active_slave)
> goto out;
>
> - /* Xmit IGMP frames on all slaves to ensure rapid fail-over
> -for multicast traffic on snooping switches */
> - if (skb->protocol == __constant_htons(ETH_P_IP) &&
> - skb->nh.iph->protocol == IPPROTO_IGMP) {
> - struct slave *slave, *active_slave;
> - int i;
> -
> - active_slave = bond->curr_active_slave;
> - bond_for_each_slave_from_to(bond, slave, i, active_slave->next,
> - active_slave->prev)
> - if (IS_UP(slave
Re: [Kgdb-bugreport] [PATCH 2.6.20-rc7] 8139too KGDBoE fix
komal wrote:
Hi all,
As the discussion was going on about the effects of trapping the
netpoll queue during KGDBoE debugging, I tried avoiding it. So in
eth_pre_exception_handler() I did not set net_poll_trap to 1 and did not
reset it back to 0 in eth_post_exception_handler()
file drivers/net/kgdboe.c
static void eth_pre_exception_handler(void)
{
/* Increment the module count when the debugger is active */
if (!kgdb_connected)
try_module_get(THIS_MODULE);
// netpoll_set_trap(1);
}
static void eth_post_exception_handler(void)
{
/* decrement the module count when the debugger detaches */
if (!kgdb_connected)
module_put(THIS_MODULE);
// netpoll_set_trap(0);
}
I'm afraid that was a wrong thing to do. We were talking only about
disabling CONFIG_NETPOLL_TRAP option
BTW, I don't see how CONFIG_NETPOLL_RX actually could influence anything --
looks like it just may be completely removed).
As i started testing KGDBoe, 1st time I did
(gdb)info threads
and it worked, but after that I set breakpoint
(gdb)break link_path_walk
after this any of the commands were not working and the test machine
went in hang state.
To provide more information, I am working on an i386/x86_64 Athlon box,
using 2.6.17 kernel and 100Mbps, full-duplex, VIA Rhine network card.
This driver also seems prone to TX queue overwrites since its TX ring size
is only 16.
-Regards
Komal Nawandar
WBR, Sergei
-
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
Additional run-tme check [Run-time kfree check for correct cache]
Due to slab poisoning after origianl freeing, skb->users will not allow
subsequent freeing to succeed and fire slab debugging, which ends up
with obscure bugs.
Patch based on Eric Sesterhenn's <[EMAIL PROTECTED]> one, I changed
check to skb>truesize instead of skb->users.counter, since the latter in
theory can be different than simple integer containing structure.
--- linux/net/core/skbuff.c.orig2007-02-28 11:34:13.865540564 +0100
+++ linux/net/core/skbuff.c 2007-03-01 13:42:05.633136591 +0100
@@ -407,6 +407,11 @@ void kfree_skb(struct sk_buff *skb)
{
if (unlikely(!skb))
return;
+#ifdef CONFIG_DEBUG_SLAB
+ /* check for double kfree_skb() */
+ WARN_ON(unlikely((skb->truesize & 0x) == 0x6b6b6b6b));
+#endif
+
if (likely(atomic_read(&skb->users) == 1))
smp_rmb();
else if (likely(!atomic_dec_and_test(&skb->users)))
--
Evgeniy Polyakov
-
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: CLOCK_MONOTONIC datagram timestamps by the kernel
On Thursday 01 March 2007 16:54, Stephen Hemminger wrote: > > I like it except changing stamp to stampns all over the place is > unnecessary, just change the > type. Well... After seeing the compat code using casts, I felt some external users could try to cast it as well and not detect the new type... > > I assume old tcpdump works as expected. Yes, of course... - 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] bonding: replace system timer with work queue
Andrew Morton wrote:
On Wed, 28 Feb 2007 10:12:01 +0100 (CET) Jaroslav Kysela <[EMAIL PROTECTED]>
wrote:
Hi,
please, review and apply to mm tree for further testing. The patch
is also available at
ftp://ftp.alsa-project.org/pub/kernel-patches/bonding-workqueue.patch .
Please cc netdev@vger.kernel.org on net-related patches, thanks.
Thank you,
Jaroslav
==
bonding: replace system timer with work queue
This patch replaces system timer with work queue in monitor functions.
The reason for this change is that bonding handlers calls various
sleeping functions from the timer handler which is not allowed.
Which sleeping functions? I'd have expected the kernel to spew runtime
warnings when this happens, but I don't recall any such reports.
Because we cannot share the main workqueue threads (rtnl_lock is used
also in linkwatch_event) - new bond workqueue thread is created.
Signed-off-by: Jaroslav Kysela <[EMAIL PROTECTED]>
diff -rupN linux-2.6.20.orig/drivers/net/bonding/bond_3ad.c
linux-2.6.20/drivers/net/bonding/bond_3ad.c
--- linux-2.6.20.orig/drivers/net/bonding/bond_3ad.c2007-02-04
19:44:54.0 +0100
+++ linux-2.6.20/drivers/net/bonding/bond_3ad.c 2007-02-28 09:19:43.831369202
+0100
@@ -2097,8 +2097,10 @@ void bond_3ad_unbind_slave(struct slave
* times out, and it selects an aggregator for the ports that are yet not
* related to any aggregator, and selects the active aggregator for a bond.
*/
-void bond_3ad_state_machine_handler(struct bonding *bond)
+void bond_3ad_state_machine_handler(struct work_struct *work)
{
+ struct ad_bond_info *ad_info = container_of(work, struct ad_bond_info,
ad_work.work);
+ struct bonding *bond = (struct bonding *)((char *)ad_info -
offsetof(struct bonding, ad_info));
We can use containers_of here too?
-void bond_alb_monitor(struct bonding *bond)
+void bond_alb_monitor(struct work_struct *work)
{
- struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond));
+ struct alb_bond_info *bond_info = container_of(work, struct
alb_bond_info, alb_work.work);
+ struct bonding *bond = (struct bonding *)((char *)bond_info -
offsetof(struct bonding, alb_info));
And here.
+ cancel_rearming_delayed_workqueue(bond_wq,
&(BOND_AD_INFO(bond).ad_work));
As I mentioned earlier this call to cancel_rearming_delayed_workqueue
can deadlock
with netlink_watch. This happens if:
dev_close
rtnl_lock carrier lost on device
bond_close netlink related workqueue event waiting
for rtnl
cancel_workqueue
spinning waiting for workq to drain
The agreed upon semantics is to never do any operation that waits for workq
to drain with RTNL held.
-
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: CLOCK_MONOTONIC datagram timestamps by the kernel
Eric Dumazet wrote: On Wednesday 28 February 2007 17:07, John wrote: Consider an idle Linux 2.6.20-rt8 system, equipped with a single PCI-E gigabit Ethernet NIC, running on a modern CPU (e.g. Core 2 Duo E6700). All this system does is time stamp 1000 packets per second. Are you claiming that this platform *cannot* handle most packets within less than 1 microsecond of their arrival? Yes I claim it. You expect too much of this platform, unless "most" means 10 % for you ;) If you replace "1 us" by "50 us", then yes, it probably can do it, if "most" means 99%, (not 99.999 %) Anyway, if you want to play, you can apply this patch on top of linux-2.6.21-rc2 (nanosecond resolution infrastruture needs 2.6.21) I let you do the adjustments for rt kernel. I like it except changing stamp to stampns all over the place is unnecessary, just change the type. I compiled it on my i386 machine, and tested it with a patched libpcap/tcpdump I assume old tcpdump works as expected. - 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 -mm 3/5] Blackfin: on-chip ethernet MAC controller driver
Wu, Bryan wrote: Hi folks, Here is the blackfin on-chip ethernet MAC controller driver for Linux. It's name is blackfin-driver-net-stamp537.patch [PATCH] Blackfin: on-chip ethernet MAC controller driver This patch implements the driver necessary use the Analog Devices Blackfin processor's on-chip ethernet MAC controller. Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> --- drivers/net/Kconfig| 44 ++ drivers/net/Makefile |1 drivers/net/bfin_mac.c | 988 + drivers/net/bfin_mac.h | 146 + 4 files changed, 1179 insertions(+) Index: linux-2.6/drivers/net/Kconfig === --- linux-2.6.orig/drivers/net/Kconfig 2007-03-01 11:39:14.0 +0800 +++ linux-2.6/drivers/net/Kconfig 2007-03-01 11:39:19.0 +0800 @@ -836,6 +836,50 @@ module, say M here and read as well as . +config BFIN_MAC + tristate "Blackfin 536/537 on-chip mac support" + depends on NET_ETHERNET && (BF537 || BF536) && (!BF537_PORT_H) + select CRC32 + select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE + help + This is the driver for blackfin on-chip mac device. Say Y if you want it + compiled into the kernel. This driver is also available as a module + ( = code which can be inserted in and removed from the running kernel + whenever you want). The module will be called bfin_mac. + +config BFIN_MAC_USE_L1 + bool "Use L1 memory for rx/tx packets" + depends on BFIN_MAC && BF537 + default y + help + To get maximum network performace, you should use L1 memory as rx/tx buffers. + Say N here if you want to reserve L1 memory for other uses. + +config BFIN_TX_DESC_NUM + int "Number of transmit buffer packets" + depends on BFIN_MAC + range 6 10 if BFIN_MAC_USE_L1 + range 10 100 + default "10" + help + Set the number of buffer packets used in driver. + +config BFIN_RX_DESC_NUM + int "Number of receive buffer packets" + depends on BFIN_MAC + range 20 100 if BFIN_MAC_USE_L1 + range 20 800 + default "20" + help + Set the number of buffer packets used in driver The regular practice is to put these in a device include file, and not make them kernel configurable. Why would you want to make it tuneable at compile time? + +config BFIN_MAC_RMII + bool "RMII PHY Interface (EXPERIMENTAL)" + depends on BFIN_MAC && EXPERIMENTAL + default n + help + Use Reduced PHY MII Interface + config SMC9194 tristate "SMC 9194 support" depends on NET_VENDOR_SMC && (ISA || MAC && BROKEN) Index: linux-2.6/drivers/net/Makefile === --- linux-2.6.orig/drivers/net/Makefile 2007-03-01 11:33:24.0 +0800 +++ linux-2.6/drivers/net/Makefile 2007-03-01 11:39:19.0 +0800 @@ -195,6 +195,7 @@ obj-$(CONFIG_MYRI10GE) += myri10ge/ obj-$(CONFIG_SMC91X) += smc91x.o obj-$(CONFIG_SMC911X) += smc911x.o +obj-$(CONFIG_BFIN_MAC) += bfin_mac.o obj-$(CONFIG_DM9000) += dm9000.o obj-$(CONFIG_FEC_8XX) += fec_8xx/ obj-$(CONFIG_PASEMI_MAC) += pasemi_mac.o Index: linux-2.6/drivers/net/bfin_mac.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6/drivers/net/bfin_mac.c2007-03-01 11:39:19.0 +0800 @@ -0,0 +1,988 @@ +/* + * File: drivers/net/bfin_mac.c + * Based on: + * Author: Luke Yang <[EMAIL PROTECTED]> + * + * Created: + * Description: + * + * Rev: $Id: bfin_mac.c,v 1.60 2006/12/16 11:23:56 hennerich Exp $ + * + * Modified: + * Copyright 2004-2006 Analog Devices Inc. + * + * Bugs: Enter bugs at http://blackfin.uclinux.org/ + * + * This program is free software ; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation ; either version 2, or (at your option) + * any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY ; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program ; see the file COPYING. + * If not, write to the Free Software Foundation, + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include + +#i
Re: [PATCH 1/2] [TCP]: Add two new spurious RTO responses to FRTO
On Thu, Mar 01, 2007 at 01:30:20PM +0200, Ilpo Järvinen wrote: > On Wed, 28 Feb 2007, Jarek Poplawski wrote: ... > > Probably something for the next "BTW". ... > missing. Spotted by Jarek Poplawski. Thanks! But I really think such a cosmetic suggestion isn't worth to mention. Jarek P. - 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] bridge: avoid ptype_all packet handling
On Wed, 2007-28-02 at 23:30 -0800, David Miller wrote: > That would be perfect for new applications. > But we have to support all the old ones, so we're stuck > providing correctly functioning AF_PACKET handling on > all devices, sorry. > It also breaks all the ingress tc code by making that change. The two scenarios i see in respect to performance are: - run a sniffer and you will see a substantial performance degradation as the pps goes up. There is no rocket science to that. This has nothing to do with bridging and will happen still even if that patch went in. - dont run any tap with the current codepath and you still see the _substantial_ performance drop then we have an opportunity to optimize. Not _by avoiding the code_ as in Stephens patch but by tunning that tap code path. [For example, you should still see a _tiny_ performance degradation if you turned on TC actions on ingress at compile time but had zero policies at run time - but that code path has been reduce to a single compare]. > And in fact that effectively makes the new socket option > pointless, since it doesn't buy us anything since we have > to support the old stuff fully anyways. agreed. I have been tied up elsewhere so havent been following netdev closely: There seem to be complaints of bridging performance going down in recent kernels - or is that someone misconfiguring their drivers? 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: CLOCK_MONOTONIC datagram timestamps by the kernel
On Wednesday 28 February 2007 17:07, John wrote:
>
> Consider an idle Linux 2.6.20-rt8 system, equipped with a single PCI-E
> gigabit Ethernet NIC, running on a modern CPU (e.g. Core 2 Duo E6700).
> All this system does is time stamp 1000 packets per second.
>
> Are you claiming that this platform *cannot* handle most packets within
> less than 1 microsecond of their arrival?
Yes I claim it.
You expect too much of this platform, unless "most" means 10 % for
you ;)
If you replace "1 us" by "50 us", then yes, it probably can do it, if "most"
means 99%, (not 99.999 %)
Anyway, if you want to play, you can apply this patch on top of
linux-2.6.21-rc2 (nanosecond resolution infrastruture needs 2.6.21)
I let you do the adjustments for rt kernel.
I compiled it on my i386 machine, and tested it with a patched libpcap/tcpdump
[PATCH] NET : introduce nanosecond time infrastructure and SIOCGSTAMPNS
It appears some machines are *really* fast and that micro second resolution is
a limiting factor.
This patch converts sk_buff timestamp to use new nanosecond infra (added in
2.6.21), and introduces a new ioctl SIOCGSTAMPNS to let applications access
nanosecond resolution (ie a timespec instead of timeval)
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
fs/compat_ioctl.c | 17
include/asm-alpha/sockios.h |1
include/asm-arm26/sockios.h |3 +
include/asm-avr32/sockios.h |3 +
include/asm-cris/sockios.h |3 +
include/asm-frv/sockios.h |3 +
include/asm-h8300/sockios.h |3 +
include/asm-i386/sockios.h |3 +
include/asm-ia64/sockios.h |3 +
include/asm-m32r/sockios.h |3 +
include/asm-m68k/sockios.h |3 +
include/asm-mips/sockios.h |3 +
include/asm-parisc/sockios.h|3 +
include/asm-powerpc/sockios.h |3 +
include/asm-s390/sockios.h |3 +
include/asm-sh/sockios.h|1
include/asm-sh64/sockios.h |1
include/asm-sparc/sockios.h |3 +
include/asm-sparc64/sockios.h |3 +
include/asm-v850/sockios.h |3 +
include/asm-x86_64/sockios.h|3 +
include/asm-xtensa/sockios.h|3 +
include/linux/skbuff.h | 42 +++---
include/net/compat.h|1
include/net/sock.h | 16 +---
net/appletalk/ddp.c |3 +
net/atm/ioctl.c |3 +
net/ax25/af_ax25.c |4 ++
net/bridge/netfilter/ebt_ulog.c |2 -
net/compat.c| 31 +---
net/core/dev.c | 14 +++
net/core/skbuff.c |4 +-
net/core/sock.c | 28 +++---
net/econet/af_econet.c |4 +-
net/ipv4/af_inet.c |3 +
net/ipv4/ip_fragment.c |6 +--
net/ipv4/tcp_output.c |2 -
net/ipv6/af_inet6.c |3 +
net/ipv6/netfilter/nf_conntrack_reasm.c |6 +--
net/ipv6/reassembly.c |6 +--
net/ipx/af_ipx.c|2 -
net/netrom/af_netrom.c |5 ++
net/packet/af_packet.c |8 ++--
net/rose/af_rose.c |2 +
net/sunrpc/svcsock.c|9 ++--
net/wanrouter/af_wanpipe.c |3 +
net/x25/af_x25.c| 12 ++
47 files changed, 216 insertions(+), 77 deletions(-)
--- linux-2.6.21-rc2/include/linux/skbuff.h 2007-02-28 20:54:35.0
+0100
+++ linux-2.6.21-rc2-ed/include/linux/skbuff.h 2007-03-01 13:15:07.0
+0100
@@ -156,9 +156,13 @@ struct skb_shared_info {
#define SKB_DATAREF_SHIFT 16
#define SKB_DATAREF_MASK ((1 << SKB_DATAREF_SHIFT) - 1)
-struct skb_timeval {
+/*
+ * We use a special timespec like structure, because ABI constraints
+ * make 'struct timespec' being 16 bytes on 64bit platforms.
+ */
+struct skb_timespec {
u32 off_sec;
- u32 off_usec;
+ u32 off_nsec;
};
@@ -186,7 +190,7 @@ enum {
* @next: Next buffer in list
* @prev: Previous buffer in list
* @sk: Socket we are owned by
- * @tstamp: Time we arrived
+ * @tstampns: Time we arrived
* @dev: Device we arrived on/are leaving by
* @input_dev: Device we arrived on
* @h: Transport layer header
@@ -233,7 +237,7 @@ struct sk_buff {
struct sk_buff *prev;
struct sock *sk;
- struct skb_timeval tstamp;
+ struct skb_timespec tstampns;
struct net_device *dev;
struct net_device *input_dev;
@@ -1350,6 +1354,20 @@ extern void skb_init(vo
Re: [PATCH 1/2] [TCP]: Add two new spurious RTO responses to FRTO
On Wed, 28 Feb 2007, Jarek Poplawski wrote:
> On 27-02-2007 16:50, Ilpo Järvinen wrote:
> > New sysctl tcp_frto_response is added to select amongst these
> ...
> > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
> > @@ -762,15 +763,17 @@ __u32 tcp_init_cwnd(struct tcp_sock *tp,
> > }
> >
> > /* Set slow start threshold and cwnd not falling to slow start */
> > -void tcp_enter_cwr(struct sock *sk)
> > +void tcp_enter_cwr(struct sock *sk, const int set_ssthresh)
> > {
> > struct tcp_sock *tp = tcp_sk(sk);
> > + const struct inet_connection_sock *icsk = inet_csk(sk);
> >
> > tp->prior_ssthresh = 0;
> > tp->bytes_acked = 0;
> > if (inet_csk(sk)->icsk_ca_state < TCP_CA_CWR) {
>
> - if (inet_csk(sk)->icsk_ca_state < TCP_CA_CWR) {
> + if (icsk->icsk_ca_state < TCP_CA_CWR) {
>
> Probably something for the next "BTW".
These are going to 2.6.22, not to 2.6.21, see:
http://marc.theaimsgroup.com/?l=linux-netdev&m=117213215924406&w=2
...or do you mean something else?
Since DaveM has already applied this, here is a patch with your correction
alone on the top of tcp-2.6.
--
[PATCH] [TCP]: Complete icsk-to-local-variable change (in tcp_enter_cwr)
A local variable for icsk was created but this change was
missing. Spotted by Jarek Poplawski.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index d6e1776..dc221a3 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -770,7 +770,7 @@ void tcp_enter_cwr(struct sock *sk, cons
tp->prior_ssthresh = 0;
tp->bytes_acked = 0;
- if (inet_csk(sk)->icsk_ca_state < TCP_CA_CWR) {
+ if (icsk->icsk_ca_state < TCP_CA_CWR) {
tp->undo_marker = 0;
if (set_ssthresh)
tp->snd_ssthresh = icsk->icsk_ca_ops->ssthresh(sk);
--
1.4.2
[PATCH] vlan & net drivers: avoid a 4-order allocation]
Hello,
This patch splits the vlan_group struct into a multi-allocated struct. On
x86_64, the size of the original struct is a little more than 32KB, causing
a 4-order allocation, which is prune to problems caused by buddy-system
external fragmentation conditions.
I couldn't just use vmalloc() because vfree() cannot be called in the
softirq context of the RCU callback.
Signed-off-by: Dan Aloni <[EMAIL PROTECTED]>
---
commit 3e6b63d0827461154066ff4c51f295bfd5006bd7
tree ccd06cfd2acd6e8f2d07dd2fa2f5cf31dc0c1011
parent 8d1117a9f5d302d8d460fbe7ef322b382e45c9ce
author Dan Aloni <[EMAIL PROTECTED]> Wed, 28 Feb 2007 14:20:36 +0200
committer Dan Aloni <[EMAIL PROTECTED]> Wed, 28 Feb 2007 14:20:36 +0200
drivers/net/8139cp.c|3 +--
drivers/net/acenic.c|5 +
drivers/net/amd8111e.c |3 +--
drivers/net/bnx2.c |4 +---
drivers/net/bonding/bond_main.c | 14 +++--
drivers/net/chelsio/cxgb2.c |3 +--
drivers/net/e1000/e1000_main.c | 13 +---
drivers/net/ehea/ehea_main.c|3 +--
drivers/net/gianfar.c |3 +--
drivers/net/ixgb/ixgb_main.c|5 ++---
drivers/net/ns83820.c |3 +--
drivers/net/r8169.c |3 +--
drivers/net/s2io.c |3 +--
drivers/net/sky2.c |3 +--
drivers/net/starfire.c |5 ++---
drivers/net/tg3.c |3 +--
drivers/net/typhoon.c |3 +--
drivers/s390/net/qeth_main.c| 25 ---
include/linux/if_vlan.h | 25 ---
net/8021q/vlan.c| 42 ++-
20 files changed, 96 insertions(+), 75 deletions(-)
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index 6f93a76..12c8453 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -448,8 +448,7 @@ static void cp_vlan_rx_kill_vid(struct net_device *dev,
unsigned short vid)
spin_lock_irqsave(&cp->lock, flags);
cp->cpcmd &= ~RxVlanOn;
cpw16(CpCmd, cp->cpcmd);
- if (cp->vlgrp)
- cp->vlgrp->vlan_devices[vid] = NULL;
+ vlan_group_set_device(cp->vlgrp, vid, NULL);
spin_unlock_irqrestore(&cp->lock, flags);
}
#endif /* CP_VLAN_TAG_USED */
diff --git a/drivers/net/acenic.c b/drivers/net/acenic.c
index 33c6645..7138e0e 100644
--- a/drivers/net/acenic.c
+++ b/drivers/net/acenic.c
@@ -2293,10 +2293,7 @@ static void ace_vlan_rx_kill_vid(struct net_device *dev,
unsigned short vid)
local_irq_save(flags);
ace_mask_irq(dev);
-
- if (ap->vlgrp)
- ap->vlgrp->vlan_devices[vid] = NULL;
-
+ vlan_group_set_device(ap->vlgrp, vid, NULL);
ace_unmask_irq(dev);
local_irq_restore(flags);
}
diff --git a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c
index 18896f2..8d57f5a 100644
--- a/drivers/net/amd8111e.c
+++ b/drivers/net/amd8111e.c
@@ -1738,8 +1738,7 @@ static void amd8111e_vlan_rx_kill_vid(struct net_device
*dev, unsigned short vid
{
struct amd8111e_priv *lp = netdev_priv(dev);
spin_lock_irq(&lp->lock);
- if (lp->vlgrp)
- lp->vlgrp->vlan_devices[vid] = NULL;
+ vlan_group_set_device(lp->vlgrp, vid, NULL);
spin_unlock_irq(&lp->lock);
}
#endif
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index ee7b75b..7f5f772 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -4470,9 +4470,7 @@ bnx2_vlan_rx_kill_vid(struct net_device *dev, uint16_t
vid)
struct bnx2 *bp = netdev_priv(dev);
bnx2_netif_stop(bp);
-
- if (bp->vlgrp)
- bp->vlgrp->vlan_devices[vid] = NULL;
+ vlan_group_set_device(bp->vlgrp, vid, NULL);
bnx2_set_rx_mode(dev);
bnx2_netif_start(bp);
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 6482aed..55d3553 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -489,9 +489,9 @@ static void bond_vlan_rx_kill_vid(struct net_device
*bond_dev, uint16_t vid)
/* Save and then restore vlan_dev in the grp array,
* since the slave's driver might clear it.
*/
- vlan_dev = bond->vlgrp->vlan_devices[vid];
+ vlan_dev = vlan_group_get_device(bond->vlgrp, vid);
slave_dev->vlan_rx_kill_vid(slave_dev, vid);
- bond->vlgrp->vlan_devices[vid] = vlan_dev;
+ vlan_group_set_device(bond->vlgrp, vid, vlan_dev);
}
}
@@ -551,9 +551,9 @@ static void bond_del_vlans_from_slave(struct bonding *bond,
struct net_device *s
/* Save and then restore vlan_dev in the grp array,
* since the slave's driver might clear it.
*/
- vlan_dev = bond->vlgrp->vlan_devices[vlan->vlan_id];
+ vlan_dev = vla
Re: CLOCK_MONOTONIC datagram timestamps by the kernel
On Wed, Feb 28, 2007 at 05:07:10PM +0100, John ([EMAIL PROTECTED]) wrote: > Again, this is irrelevant. We are discussing whether it would make sense > to support sub-microsecond resolution. If there is one platform that can > achieve sub-microsecond precision, there is a need for sub-microsecond > resolution. As long as we are changing the resolution, we might as well > use something standard like struct timespec. You can not blindly change skb timestamps to different entities - you need to change all users (at least in kernel). Exporting it to userspace must require new socket option and old one ust be changed accordingly, but there is nothing wrong in having nanosecond resolution in packet timestamp except that it might not be 100% correct receiving time. -- Evgeniy Polyakov - 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: need some help on a backport of r8169
Hello Ueimor, I succeeded to make the MII ioctls work in the r1000 driver. It seems to be a solution for my problem. Thank you a lot, it wouldn't have been possible without your help. You allowed me to place some debug in the r8169 driver and look at it with an up interface so I could compare some values. I will send you my patch for r1000, if it can be of any use for you, however I don't think I can do it before next week. Though I continue to send you the interesting informations. See further. Francois Romieu a écrit, le Thu 01 Mar 2007 à 12:08:07AM : > [EMAIL PROTECTED] <[EMAIL PROTECTED]> : > [...] > > The problem comes here, I do a ping and it seems to have just the time > > to make the DNS resolution but not further. When I do a new ifconfig, > > the TX dropped is not 0 anymore. Then I can turn up and down my > > interface, I won't be able to ping anything. > > Ok, almost perfect for a first try. :o) > > If you can issue 'ifconfig' and do an ethtool dump of the registers at > the interesting points in time, it could surely help. eth0 Link encap:Ethernet HWaddr 00:16:EC:8F:2F:AF inet addr:172.16.39.95 Bcast:172.16.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1523 errors:0 dropped:0 overruns:0 frame:0 TX packets:154 errors:0 dropped:43 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:138174 (134.9 Kb) TX bytes:14386 (14.0 Kb) Interrupt:10 Offset Value - 00 0x00 01 0x16 02 0xec 03 0x8f 04 0x2f 05 0xaf 06 0x00 07 0x00 08 0xff 09 0xff 10 0xff 11 0xff 12 0xff 13 0xff 14 0xff 15 0xff 16 0x80 17 0x81 18 0x32 19 0xf7 20 0xc4 21 0x81 22 0x32 23 0xf7 24 0x00 25 0x00 26 0x00 27 0x00 28 0x00 29 0x00 30 0x00 31 0x00 32 0x00 33 0x60 34 0x7b 35 0x17 36 0x00 37 0x00 38 0x00 39 0x00 40 0x00 41 0x81 42 0x32 43 0xf7 44 0xc4 45 0x81 46 0x32 47 0xf7 48 0x00 49 0x00 50 0x00 51 0x00 52 0x00 53 0x00 54 0x00 55 0x0c 56 0x00 57 0x00 58 0x00 59 0x00 60 0x7f 61 0x80 62 0x00 63 0x00 64 0x00 65 0x06 66 0x00 67 0x3b 68 0x0e 69 0xe6 70 0x00 71 0x00 72 0xa9 73 0xcf 74 0xfa 75 0xc5 76 0x00 77 0x00 78 0x00 79 0x00 80 0x00 81 0x05 82 0x0f 83 0x30 84 0x20 85 0x00 86 0x01 87 0x00 88 0x00 89 0x00 90 0x00 91 0x00 92 0x00 93 0x00 94 0x00 95 0x00 96 0x00 97 0x10 98 0x00 99 0x80 100 0xc4 101 0x81 102 0x32 103 0xf7 104 0x7f 105 0xab 106 0x00 107 0x00 108 0x73 109 0x02 110 0x01 111 0x00 112 0x00 113 0x00 114 0x00 115 0x00 116 0x00 117 0x00 118 0x00 119 0x00 120 0x00 121 0x00 122 0xff 123 0xff 124 0x00 125 0x00 126 0x00 127 0x00 128 0x93 129 0x1b 130 0x01 131 0x80 132 0xc4 133 0x81 134 0x32 135 0xf7 136 0xc4 137 0x81 138 0x32 139 0xf7 140 0xc4 141 0x81 142 0x32 143 0xf7 144 0xc4 145 0x81 146 0x32 147 0xf7 148 0xc4 149 0x81 150 0x32 151 0xf7 152 0xc4 153 0x81 154 0x32 155 0xf7 156 0xc4 157 0x81 158 0x32 159 0xf7 160 0xc4 161 0x81 162 0x32 163 0xf7 164 0xc4 165 0x81 166 0x32 167 0xf7 168 0xc4 169 0x81 170 0x32 171 0xf7 172 0xc4 173 0x81 174 0x32 175 0xf7 176 0xc4 177 0x81 178 0x32 179 0xf7 180 0xc4 181 0x81 182 0x32 183 0xf7 184 0xc4 185 0x81 186 0x32 187 0xf7 188 0xc4 189 0x81 190 0x32 191 0xf7 192 0xc4 193 0x81 194 0x32 195 0xf7 196 0xc4 197 0x81 198 0x32 199 0xf7 200 0xc4 201 0x81 202 0x32 203 0xf7 204 0xc4 205 0x81 206 0x00 207 0x00 208 0x00 209 0x00 210 0x00 211 0x00 212 0x00 213 0x00 214 0x00 215 0x00 216 0x00 217 0x00 218 0xff 219 0x3f 220 0x00 221 0x00 222 0x00 223 0x00 224 0x28 225 0x20 226 0x00 227 0x00 228 0x00 229 0x90 230 0x74 231 0x17 232 0x00 233 0x00 234 0x00 235 0x00 236 0x3f 237 0x00 238 0x00 239 0x00 240 0x00 241 0x00 242 0x00 243 0x00 244 0x00 245 0x00 246 0x00 247 0x00 248 0x00 249 0x00 250 0x00 251 0x00 252 0x00 253 0x00 254 0x00 255 0x00 I'm so sorry I couldn't give you a better dump, ethtool 5 told me "Unknown Realtek chipset". FYI: I noticed that ethtool -d e
Re: [PATCH -mm 3/5] Blackfin: on-chip ethernet MAC controller driver
On Thu, 01 Mar 2007 12:15:14 +0800 "Wu, Bryan" <[EMAIL PROTECTED]> wrote:
> Hi folks,
>
> Here is the blackfin on-chip ethernet MAC controller driver for Linux.
>
> It's name is blackfin-driver-net-stamp537.patch
>
> [PATCH] Blackfin: on-chip ethernet MAC controller driver
>
> This patch implements the driver necessary use the Analog Devices
> Blackfin processor's on-chip ethernet MAC controller.
>
> ...
>
> +
> +extern void get_bf537_ether_addr(char *addr);
Please don't put extern declarations in .c code. Put them in a header file
which is included by the file which provides the definition and by all
files which refer to the symbol.
Please review the entire blackfin patchset for more occurrences of this
mistake.
> +static int bf537mac_hard_start_xmit(struct sk_buff *skb, struct net_device
> *dev)
> +{
> + struct bf537mac_local *lp = netdev_priv(dev);
> + unsigned int data;
> +
> + current_tx_ptr->skb = skb;
> + // Is skb->data always 16-bit aligned? Do we need to memcpy((char
> *)(tail->packet + 2),skb->data,len)?
> + if unsigned int)(skb->data)) & 0x02) == 2) {
> + //move skb->data to current_tx_ptr payload
> + data = (unsigned int)(skb->data) - 2;
> + *((unsigned short *)data) = (unsigned short)(skb->len);
> + current_tx_ptr->desc_a.start_addr = (unsigned long)data;
> + blackfin_dcache_flush_range(data, (data + (skb->len)) + 2);
> //this is important!
> +
> + } else {
> + *((unsigned short *)(current_tx_ptr->packet)) =
> + (unsigned short)(skb->len);
> + memcpy((char *)(current_tx_ptr->packet + 2), skb->data,
> +(skb->len));
> + current_tx_ptr->desc_a.start_addr =
> + (unsigned long)current_tx_ptr->packet;
> + if (current_tx_ptr->status.status_word != 0)
> + current_tx_ptr->status.status_word = 0;
> + blackfin_dcache_flush_range((unsigned int)current_tx_ptr->
> + packet,
> + (unsigned int)(current_tx_ptr->
> +packet + skb->len) +
> + 2);
> + }
hm, I'd have thought that networking provided a way of avoiding that
memcpy, but it has been too long..
> + current_tx_ptr->desc_a.config.b_DMA_EN = 1; //enable this packet's
> dma
> +
> + if (bfin_read_DMA2_IRQ_STATUS() & 0x08) { //tx dma is running,
> just return
> + goto out;
> + } else {//tx dma is not running
> + bfin_write_DMA2_NEXT_DESC_PTR(&(current_tx_ptr->desc_a));
> + bfin_write_DMA2_CONFIG(*((unsigned short
> *)(&(current_tx_ptr->desc_a.config;// dma enabled, read from
> memory, size is 6
> + // Turn on the EMAC tx
> + bfin_write_EMAC_OPMODE(bfin_read_EMAC_OPMODE() | TE);
> + }
> +
> + out:
> + adjust_tx_list();
> + current_tx_ptr = current_tx_ptr->next;
> + dev->trans_start = jiffies;
> + lp->stats.tx_packets++;
> + lp->stats.tx_bytes += (skb->len);
> + 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
