Re: [PATCH] possible deadlock in tulip driver
Manual code check. The similar fixes are present in almost all drivers, f.e. tg3 one. I have an unrelated deadlock with rtnl. Regards, Den Valerie Henson wrote: (No longer maintainer, btw.) What situation have you tested this under? Thanks, -VAL On Tue, Jul 24, 2007 at 11:49:08AM +0400, Denis V. Lunev wrote: Calling flush_scheduled_work() may deadlock if called under rtnl_lock (from dev-stop) as linkwatch_event() may be on the workqueue and it will try to get the rtnl_lock Signed-off-by: Denis V. Lunev [EMAIL PROTECTED] --- tulip_core.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- ./drivers/net/tulip/tulip_core.c.tulip 2007-07-16 12:54:29.0 +0400 +++ ./drivers/net/tulip/tulip_core.c2007-07-23 19:06:24.0 +0400 @@ -726,8 +726,6 @@ static void tulip_down (struct net_devic void __iomem *ioaddr = tp-base_addr; unsigned long flags; - flush_scheduled_work(); - del_timer_sync (tp-timer); #ifdef CONFIG_TULIP_NAPI del_timer_sync (tp-oom_timer); @@ -1788,6 +1786,8 @@ static void __devexit tulip_remove_one ( if (!dev) return; + flush_scheduled_work(); + tp = netdev_priv(dev); unregister_netdev(dev); pci_free_consistent (pdev, - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] Preparatory refactoring part 2.
Patrick McHardy wrote:
Corey Hickey wrote:
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 8ae077f..0c46938 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -380,71 +380,71 @@ static void sfq_perturbation(unsigned long arg)
}
}
-static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
+static int sfq_q_init(struct sfq_sched_data *q, struct rtattr *opt)
{
- struct sfq_sched_data *q = qdisc_priv(sch);
struct tc_sfq_qopt *ctl = RTA_DATA(opt);
- unsigned int qlen;
+ int i;
- if (opt-rta_len RTA_LENGTH(sizeof(*ctl)))
+ if (opt opt-rta_len RTA_LENGTH(sizeof(*ctl)))
opt is dereferenced above (RTA_DATA), so if it is NULL we've already
crashed.
I think that test made ESFQ not crash when I did a qdisc change
without giving any parameters, but that was a while ago and I might be
mistaken. I'll need to rewrite much of this function anyway, and I'll
pay attention to what happens when I get there.
return -EINVAL;
- sch_tree_lock(sch);
- q-quantum = ctl-quantum ? : psched_mtu(sch-dev);
- q-perturb_period = ctl-perturb_period*HZ;
- if (ctl-limit)
- q-limit = min_t(u32, ctl-limit, SFQ_DEPTH);
+ q-perturbation = 0;
+ q-max_depth = 0;
+ q-tail = q-limit = SFQ_DEPTH;
+ if (opt == NULL) {
+ q-perturb_period = 0;
+ } else {
+ struct tc_sfq_qopt *ctl = RTA_DATA(opt);
+ if (ctl-quantum)
+ q-quantum = ctl-quantum;
+ q-perturb_period = ctl-perturb_period*HZ;
- qlen = sch-q.qlen;
- while (sch-q.qlen = q-limit-1)
- sfq_drop(sch);
- qdisc_tree_decrease_qlen(sch, qlen - sch-q.qlen);
I hope that patch that makes changing possible brings this back ..
checking .. it doesn't. Please either keep this or fix up 6/7
to bring it back.
It got lost in translation; I will add it to 6/7.
Thanks,
Corey
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] Make qdisc changeable.
Patrick McHardy wrote:
Corey Hickey wrote:
Re-implement sfq_change() and enable Qdisc_opts.change so tc qdisc
change will work.
Signed-off-by: Corey Hickey [EMAIL PROTECTED]
---
net/sched/sch_sfq.c | 51 ++-
1 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index e6a6a21..e042cd0 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -485,6 +485,55 @@ static int sfq_init(struct Qdisc *sch, struct rtattr *opt)
return 0;
}
+static int sfq_change(struct Qdisc *sch, struct rtattr *opt)
+{
+ struct sfq_sched_data *q = qdisc_priv(sch);
+ struct sfq_sched_data tmp;
+ struct sk_buff *skb;
+ int err;
+
+ /* set up tmp queue */
+ memset(tmp, 0, sizeof(struct sfq_sched_data));
+ tmp.quantum = psched_mtu(sch-dev); /* default */
If no value is given it should use the old value instead of
reinitializing to the default.
+ if ((err = sfq_q_init(tmp, opt)))
+ return err;
This will also use defaults for all unspecified values. It would
be more consistent with other qdiscs to only change those values
that are actually specified, so something like tc qdisc change ...
perturb 10 will *only* change the perturbation parameter.
I somehow had it in my head that a qdisc change was supposed to work
that way. I'll change my patch.
I'm not sure reusing the initialization function and copying the
parameters is the best way to do this.
I'm not sure either, but I do like that it's conceptually simple and it
keeps the parameter handling in one place. I've thought and stared for a
while, and I don't see a better way, but that could of course be due to
my limited understanding and general newbiehood in that regard.
Thanks again for the review. I'll try to get a new batch of patches sent
off tomorrow.
-Corey
-
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: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
On 28-07-2007 20:42, Gabriel C wrote: Andrew Morton wrote: On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C [EMAIL PROTECTED] wrote: Hi, I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). ... net/core/netpoll.c: In function 'netpoll_poll': net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c: In function 'netpoll_setup': net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller' make[2]: *** [net/core/netpoll.o] Error 1 make[1]: *** [net/core] Error 2 make: *** [net] Error 2 make: *** Waiting for unfinished jobs ... I think is because KGDBOE selects just NETPOLL. Looks like it. Select went and selected NETPOLL and NETPOLL_TRAP but things like CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select' remains evil. ... I think there may be a logical issue ( again if I got it right ). We need some ethernet card to work with kgdboe right ? but we don't have any if !NETDEVICES !NET_ETHERNET. So maybe some ' depends on ... NETDEVICES!=n NET_ETHERNET!=n ' is needed too ? IMHO, the only logical issue here is netpoll.c mustn't use CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't add this dependency itself. Cheers, 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: [RESEND][PATCH 1/3] PPPoE: improved hashing routine
From: Florian Zumbiehl [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 10:07:19 +0200 Erm, I'd say this not only produces different results than the old version, but it also produces wrong results, in that it ignores quite a bit of the data that's supposed to be hashed. If I didn't overlook something, it only considers addr0x0f0f0f0f0f00 and sid0x0f0f, given the right endianness of addr and that PPPOE_HASH_SIZE stays 16. You're right, I need to fix the shifts up. How does this version look? hash ^= (hash 4) ^ (hash 12) ^ (hash 20); return (head ^ (hash 8) ^ (hash 24)) (PPPOE_HASH_SIZE - 1); Actually it might be simpler and more efficient to just make PPPOE_HASH_SHIFT be 8. - 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: zd1211rw and mac80211: multicast/v6 doesn't work in 2.6.21.5
FWIW, multicast/v6 is still broken on zd1211rw on 2.6.22.1 based Fedora 7 kernel (2.6.22.1-33.fc7). On Thu, 28 Jun 2007, Pekka Savola wrote: On Fedora 7 (kernel 2.6.21-1.3228.fc7, based on 2.6.21.5), my zd1211rw_mac80211 WLAN USB stick and multicast/v6 no longer works. On Fedora 6 (kernel 2.6.20, no mac80211) it was OK. I get wlan0: duplicate address detected! on dmesg when the kernel is trying to autoconfigure a global address. I suppose this is caused by the IPv6 stack seeing my own ICMPv6 neighbor solicitation and thinking it was originated by someone else: 08:46:21.762807 00:02:72:5b:dc:28 33:33:ff:5b:dc:28, ethertype IPv6 (0x86dd), length 78: (hlim 255, next-header: ICMPv6 (58), length: 24) :: ff02::1:ff5b:dc28: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has 2001:708:10:90:202:72ff:fe5b:dc28 Strangely, the same error isn't printed with the link-local address which uses the same EUI-64. z1211rw Wiki seems to imply that this might be an issue in generic mac80211 code: http://www.linuxwireless.org/en/users/Drivers/zd1211rw/mac80211Issues It'd be nice to get this fixed. Or has it already been? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - 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
[IPSEC]: Ensure that state inner family is set
Hi Dave:
[IPSEC]: Ensure that state inner family is set
Similar to the issue we had with template families which
specified the inner families of policies, we need to set
the inner families of states as the main xfrm user Openswan
leaves it as zero.
af_key is unaffected because the inner family is set by it
and not the KM.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index c06883b..61339e1 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -322,6 +322,13 @@ static void copy_from_user_state(struct xfrm_state *x,
struct xfrm_usersa_info *
x-props.family = p-family;
memcpy(x-props.saddr, p-saddr, sizeof(x-props.saddr));
x-props.flags = p-flags;
+
+ /*
+* Set inner address family if the KM left it as zero.
+* See comment in validate_tmpl.
+*/
+ if (!x-sel.family)
+ x-sel.family = p-family;
}
/*
-
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: [RESEND][PATCH 1/3] PPPoE: improved hashing routine
Hi,
-static int hash_item(unsigned long sid, unsigned char *addr)
+#if 8%PPPOE_HASH_BITS
+#error 8 must be a multiple of PPPOE_HASH_BITS
+#endif
Since PPPOE_HASH_BITS is 4 I would think this check will break the
build. :-)
Erm, I thought that 8 was 4*2, but maybe I didn't quite understand that
natural numbers business ;-)
Anyways, I looked at this myself and half of the problem comes from
the fact that sid is passed around as an unsigned long throughout
this entire file yet the thing is just a __u16.
So the first thing to fix is to use __u16 consistently for sid values.
Then the sid hash looks obviously wrong and is easy to fix.
Then you end up with a hash_item() that simply looks like:
static unsigned int hash_item(__u16 sid, unsigned char *addr)
{
unsigned int hash;
hash = (((unsigned int)addr[0] 24) |
((unsigned int)addr[1] 16) |
((unsigned int)addr[2] 8) |
((unsigned int)addr[3] 0));
hash ^= (((unsigned int)addr[4] 8) |
((unsigned int)addr[5] 0));
hash ^= sid;
return ((hash ^ (hash 8) ^ (hash 16))
(PPPOE_HASH_SIZE - 1));
}
which is what I've checked into my tree.
Erm, I'd say this not only produces different results than the old
version, but it also produces wrong results, in that it ignores quite
a bit of the data that's supposed to be hashed. If I didn't overlook
something, it only considers addr0x0f0f0f0f0f00 and sid0x0f0f, given
the right endianness of addr and that PPPOE_HASH_SIZE stays 16.
Florian
-
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: [RESEND][PATCH 1/3] PPPoE: improved hashing routine
Hi, Erm, I'd say this not only produces different results than the old version, but it also produces wrong results, in that it ignores quite a bit of the data that's supposed to be hashed. If I didn't overlook something, it only considers addr0x0f0f0f0f0f00 and sid0x0f0f, given the right endianness of addr and that PPPOE_HASH_SIZE stays 16. You're right, I need to fix the shifts up. How does this version look? hash ^= (hash 4) ^ (hash 12) ^ (hash 20); return (head ^ (hash 8) ^ (hash 24)) (PPPOE_HASH_SIZE - 1); Assuming that it was supposed to read s/head/hash/: Same disclaimers apply, but I'd say this considers only addr0xff0fff0f000f and sid0x0fff, so, well, yes, it's better, but still not quite what I think it should be ;-) Actually it might be simpler and more efficient to just make PPPOE_HASH_SHIFT be 8. SHIFT? SIZE? BITS? Florian - 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: [IPSEC]: Ensure that state inner family is set
From: Herbert Xu [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 16:53:56 +0800 Hi Dave: [IPSEC]: Ensure that state inner family is set Similar to the issue we had with template families which specified the inner families of policies, we need to set the inner families of states as the main xfrm user Openswan leaves it as zero. af_key is unaffected because the inner family is set by it and not the KM. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Applied, thanks Herbert. - 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: [RESEND][PATCH 1/3] PPPoE: improved hashing routine
From: Florian Zumbiehl [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 11:01:59 +0200 Assuming that it was supposed to read s/head/hash/: Same disclaimers apply, but I'd say this considers only addr0xff0fff0f000f and sid0x0fff, so, well, yes, it's better, but still not quite what I think it should be ;-) Indeed it's still bogus. Actually it might be simpler and more efficient to just make PPPOE_HASH_SHIFT be 8. SHIFT? SIZE? BITS? You know what I meant :-) PPPOE_HASH_BITS. I guess otherwise we degenerate back to your original patch :) - 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 net-2.6 1/2] [TCP]: Fix ratehalving with bidirectional flows
On Mon, 30 Jul 2007 22:21:12 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Ilpo_Järvinen [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 07:59:10 +0300 (EEST) I think it's probably good to add tp-snd_una != prior_snd_una check there too... It's not going to make a large difference, mostly just to be conservative when skb collapse stuff got done (and maybe to annoy cheaters too though I couldn't at this point figure out how they could abuse it)... ...I think I can come up with that on Wednesday, so please hold stable push until that. It'll definitely need to wait at least a day as I cannot even make TCP or UDP connections out from my machine with the current net-2.6 tree, and this is what I'm debugging at the moment. I'm hoping that it's just something stupid like the make not rebuilding everything necessary after I changed the __u16's into __u32's in skb_frag_t. I running tests over emulator this morning. Hopefully, this will fix the window collapse that occurs on startup of large queue sizes. - 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 net-2.6 1/2] [TCP]: Fix ratehalving with bidirectional flows
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 10:51:13 +0100 On Mon, 30 Jul 2007 22:21:12 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Ilpo_Järvinen [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 07:59:10 +0300 (EEST) I think it's probably good to add tp-snd_una != prior_snd_una check there too... It's not going to make a large difference, mostly just to be conservative when skb collapse stuff got done (and maybe to annoy cheaters too though I couldn't at this point figure out how they could abuse it)... ...I think I can come up with that on Wednesday, so please hold stable push until that. It'll definitely need to wait at least a day as I cannot even make TCP or UDP connections out from my machine with the current net-2.6 tree, and this is what I'm debugging at the moment. I'm hoping that it's just something stupid like the make not rebuilding everything necessary after I changed the __u16's into __u32's in skb_frag_t. I running tests over emulator this morning. Hopefully, this will fix the window collapse that occurs on startup of large queue sizes. Great. For the record the bug I was chasing was an IPSEC issue which Herbert fixed a few moments ago. - 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
Scatter gather and TCP MD5
Hello, I am using a vanilla 2.6.22.1 kernel and I see the same kind of problem as had been mentioned some time back on this list http://lkml.org/lkml/2007/5/22/45 The issue is essentially that with the MD5 option enabled for the specific TCP connection, the SYN and SYN-ACKS are passed ok and the connection establishes fine, but the other end (a cisco router) complains about incorrect MD5 signatures on any other message that is sent after this. Setting the scatter-gather offloading option to off on the NIC seems to correct this problem. Recently I had seen a checkin (as a response to the problem mentioned in the above link) where the TSO option was turned off to make MD5 work (my kernel has that fix). Is a similar solution needed here too? This is the information about my system: uname -a Linux stdalone 2.6.22.1 #1 SMP Mon Jul 23 20:15:21 PDT 2007 i686 i686 i386 GNU/Linux ethtool -i eth0 driver: e1000 version: 7.3.20-k2 firmware-version: N/A bus-info: :01:0a.0 ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: off tcp segmentation offload: off Thanks for your help. Siddharth PS: I would like to be CC'ed on the reply to this email. 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: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
Jarek Poplawski wrote: On 28-07-2007 20:42, Gabriel C wrote: Andrew Morton wrote: On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C [EMAIL PROTECTED] wrote: Hi, I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). ... net/core/netpoll.c: In function 'netpoll_poll': net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c: In function 'netpoll_setup': net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller' make[2]: *** [net/core/netpoll.o] Error 1 make[1]: *** [net/core] Error 2 make: *** [net] Error 2 make: *** Waiting for unfinished jobs ... I think is because KGDBOE selects just NETPOLL. Looks like it. Select went and selected NETPOLL and NETPOLL_TRAP but things like CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select' remains evil. ... I think there may be a logical issue ( again if I got it right ). We need some ethernet card to work with kgdboe right ? but we don't have any if !NETDEVICES !NET_ETHERNET. So maybe some ' depends on ... NETDEVICES!=n NET_ETHERNET!=n ' is needed too ? IMHO, the only logical issue here is netpoll.c mustn't use CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't add this dependency itself. Well it does if NETDEVICES if NET_ETHERNET which booth are N when !NETDEVICES is why KGDBOE uses select and not depends on. Now KGDBOE just selects NETPOLL and NETPOLL_TRAP. Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the question is does it work without any ethernet card ? Cheers, Jarek P. Gabriel - 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]: Fix sk_buff page offsets and lengths.
On Mon, Jul 30, 2007 at 06:50:28PM -0700, David Miller ([EMAIL PROTECTED]) wrote: Stephen Rothwell pointed out to me that the skb_frag_struct is broken on platforms using 64K or larger page sizes, it even generates warnings when (for example) the myri10ge driver tries to assign PAGE_SIZE into frag-size. I've thus increased page offset and size to __u32 in the patch below. Maybe wrap it into #if PAGE_OFFSET 12 #endif or something like that? I'm not sure actually why drivers would want to have list of 64k pages, instead driver could call give_me_pages(size) instead of alloc_pages and per-arch allocator would return one page or set of pages. This is a handwaving for now... -- 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: [PATCH net-2.6.22-rc7] xfrm beet interfamily support
On Thursday 19 July 2007 17:46:42 Patrick McHardy wrote: Joakim Koskela wrote: + skb_push(skb, hdrlen); + iphv6 = ipv6_hdr(skb); + + skb_reset_network_header(skb); + top_iphv6 = ipv6_hdr(skb); + + protocol = iphv6-nexthdr; + skb_pull(skb, delta); + skb_reset_network_header(skb); + top_iphv4 = ip_hdr(skb); + skb_set_transport_header(skb, hdrlen); + top_iphv4-ihl = (sizeof(struct iphdr) 2); + top_iphv4-version = 4; + top_iphv4-id = 0; + top_iphv4-frag_off = htons(IP_DF); + top_iphv4-ttl = dst_metric(dst-child, RTAX_HOPLIMIT); + top_iphv4-saddr = x-props.saddr.a4; + top_iphv4-daddr = x-id.daddr.a4; + skb-transport_header += top_iphv4-ihl*4; + top_iphv4-protocol = protocol; + + skb-protocol = htons(ETH_P_IP); +#endif The output function in the IPv6/IPv4 case is called from xfrm6_output_one, which loops until after a tunnel mode encapsulation is done and then returns to the outer loop in xfrm6_output_finish2, which passes the packet through the netfilter hooks and continues with the next transform. I'm not sure I really got this. IPv6/IPv4 means IPv6 inner, IPv4 outer, right? Isn't that called from xfrm4_output_one and subsequently passed through the right filters as well (as it has a ipv4 header by then)? There are multiple problems resulting from the inter-family encapsulation. First of all, the inner loop continues after beet mode encapsulation, skipping the netfilter hooks in case there are more transforms. It should (as with decaps = 1 on input) at least call netfilter hooks after an inter-family transform. If the beet transform is the last one, the IPv4 skb will be passed through the IPv6 netfilter hooks, which is clearly wrong. To fix these problems some restructuring in xfrm[46]_output.c seems to be necessary. Couldn't this be solved just by ending the inner loop in case of beet mode (as it is done for tunnel)? br, 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 1/7] Preparatory refactoring part 1.
Corey Hickey wrote: Patrick McHardy wrote: -static int -sfq_enqueue(struct sk_buff *skb, struct Qdisc* sch) +static void sfq_q_enqueue(struct sk_buff *skb, struct sfq_sched_data *q, unsigned int end) Please make sure to break at 80 chars and to keep the style in this file consistent (newline before function name). Ok. For what it's worth, though, most of the original functions in the file don't have a newline before the function name. Omitting the newline would thus make the new/changed functions more consistent with the rest of the file. I don't have a preference either way, so unless you change your mind I'll put the newline back in.. You're right, just keep it consistent please and break at 80 chars. -sch-qstats.backlog += skb-len; Why not keep this instead of having both callers do it? My idea was to have all the sfq_q_* functions operate on struct sfq_sched_data and have no knowledge of the struct Qdisc. I did this in order to be able to use the new functions in sfq_change() when the temporary sfq_sched_data doesn't have a parent Qdisc. There's probably a better way, and I am of course open to suggestions, but what I did made sense to me. Also sounds fine. - 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 net-2.6.22-rc7] xfrm beet interfamily support
Joakim Koskela wrote: On Thursday 19 July 2007 17:46:42 Patrick McHardy wrote: Joakim Koskela wrote: +skb_push(skb, hdrlen); +iphv6 = ipv6_hdr(skb); + +skb_reset_network_header(skb); +top_iphv6 = ipv6_hdr(skb); + +protocol = iphv6-nexthdr; +skb_pull(skb, delta); +skb_reset_network_header(skb); +top_iphv4 = ip_hdr(skb); +skb_set_transport_header(skb, hdrlen); +top_iphv4-ihl = (sizeof(struct iphdr) 2); +top_iphv4-version = 4; +top_iphv4-id = 0; +top_iphv4-frag_off = htons(IP_DF); +top_iphv4-ttl = dst_metric(dst-child, RTAX_HOPLIMIT); +top_iphv4-saddr = x-props.saddr.a4; +top_iphv4-daddr = x-id.daddr.a4; +skb-transport_header += top_iphv4-ihl*4; +top_iphv4-protocol = protocol; + +skb-protocol = htons(ETH_P_IP); +#endif The output function in the IPv6/IPv4 case is called from xfrm6_output_one, which loops until after a tunnel mode encapsulation is done and then returns to the outer loop in xfrm6_output_finish2, which passes the packet through the netfilter hooks and continues with the next transform. I'm not sure I really got this. IPv6/IPv4 means IPv6 inner, IPv4 outer, right? Isn't that called from xfrm4_output_one and subsequently passed through the right filters as well (as it has a ipv4 header by then)? I think you're right, it uses xfrm4_output. But there's a mismatch in either case, in both cases (IPv4 and IPv6) we first call the POSTROUTING hook for this family, than do the transform (changing the family), then call the OUTPUT hook for the same family. So either the POSTROUTING or the OUTPUT hook is called for the wrong family. There are multiple problems resulting from the inter-family encapsulation. First of all, the inner loop continues after beet mode encapsulation, skipping the netfilter hooks in case there are more transforms. It should (as with decaps = 1 on input) at least call netfilter hooks after an inter-family transform. If the beet transform is the last one, the IPv4 skb will be passed through the IPv6 netfilter hooks, which is clearly wrong. To fix these problems some restructuring in xfrm[46]_output.c seems to be necessary. Couldn't this be solved just by ending the inner loop in case of beet mode (as it is done for tunnel)? If the assumption that xfrm4_output is used for IPv6 in IPv4 encapsulation is correct and the problem mentioned above is fixed, that should work fine. - 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 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
Hi, Thanks for finding these bugs! I'll post an updated version soon (2 patches with no separate Kconfig patches, one LRO and one eHEA patch). See comments below. Thanks, Jan-Bernd On Monday 30 July 2007 22:32, Andrew Gallatin wrote: I was working on testing the myri10ge patch, and I ran into a few problems. I've attached a patch to inet_lro.c to fix some of them, and a patch to myri10ge.c to show how to use the page based interface. Both patches are signed off by Andrew Gallatin [EMAIL PROTECTED] First, the LRO_MAX_PG_HLEN is still a problem. Minimally sized 60 byte frames still cause problems in lro_gen_skb due to skb-len going negative. Fixed in the attached patch. It may be simpler to just drop LRO_MAX_PG_HLEN to ETH_ZLEN, but I'm not sure if that is enough. Are there smart NICs which might chop off padding themselves? I'd tend to stick to an explicit check as implemented in your patch for now Second, you still need to set skb-ip_summed = CHECKSUM_UNNECESSARY when modified packets are flushed, else the stack will see bad checksums for packets from CHECKSUM_COMPLETE drivers using the skb interface. Fixed in the attached patch. I thought about it... As we do update the TCP checksum for aggregated packets we could add a second ip_summed field in the net_lro_mgr struct used for aggregated packets to support HW that does not have any checksum helper functionality. These drivers could set this ip_summed field to CHECKSUM_NONE, and thus leave the checksum check to the stack. I'm not sure if these old devices benefit a lot from LRO. So what do you think? Fourth, I did some traffic sniffing to try to figure out what's going on above, and saw tcpdump complain about bad checksums. Have you tried running tcpdump -s 65535 -vvv? Have you also seen bad checksums? I seem to see this for both page- and skb-based versions of the driver. Hmmm, can't confirm that. For our skb-based version I see correct checksums for aggregated packets and for the page-based version as well. I used: (tcpdump -i ethX -s 0 -w dump.bin) in combination with ethereal. Don't see problems as well with your tcpdump command. - 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: [RESEND][PATCH 1/3] PPPoE: improved hashing routine
Hi, Actually it might be simpler and more efficient to just make PPPOE_HASH_SHIFT be 8. SHIFT? SIZE? BITS? You know what I meant :-) PPPOE_HASH_BITS. Actually, I wasn't sure, for SHIFT looks more similar to SIZE than to BITS, plus numbers are somewhat same order of magnitude anyway, and I didn't quite see what you were up to, so ... whatever ;-) I guess otherwise we degenerate back to your original patch :) Well, as I don't quite see what you were up to and as my patch doesn't change anything about the semantics of the code, I'd at least prefer that over your other suggestions so far ;-) A few variations I tried back when I created the patch, using larger things than a char for accumulating the pieces and then folding down from that, turned out to be slower than what I finally submitted, at least on the machines I tested it on. I didn't do comprehensive testing, as it really doesn't matter, after all, but I think the version I submitted is pretty fast, plus it's quite readable, and it keeps the flexibility of different hash sizes, but still should allow the compiler to optimize away the loops that allow for this flexibility. Florian - 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 net-2.6.22-rc7] xfrm beet interfamily support
On Tuesday 31 July 2007 13:51:42 Patrick McHardy wrote: Joakim Koskela wrote: I'm not sure I really got this. IPv6/IPv4 means IPv6 inner, IPv4 outer, right? Isn't that called from xfrm4_output_one and subsequently passed through the right filters as well (as it has a ipv4 header by then)? I think you're right, it uses xfrm4_output. But there's a mismatch in either case, in both cases (IPv4 and IPv6) we first call the POSTROUTING hook for this family, than do the transform (changing the family), then call the OUTPUT hook for the same family. So either the POSTROUTING or the OUTPUT hook is called for the wrong family. Ok, so changing int xfrm[46]_output(struct sk_buff*) to use the right PF hook based on the skb's [current] family should put things through the right hoops, right? br, 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 net-2.6.22-rc7] xfrm beet interfamily support
Joakim Koskela wrote: On Tuesday 31 July 2007 13:51:42 Patrick McHardy wrote: Joakim Koskela wrote: I'm not sure I really got this. IPv6/IPv4 means IPv6 inner, IPv4 outer, right? Isn't that called from xfrm4_output_one and subsequently passed through the right filters as well (as it has a ipv4 header by then)? I think you're right, it uses xfrm4_output. But there's a mismatch in either case, in both cases (IPv4 and IPv6) we first call the POSTROUTING hook for this family, than do the transform (changing the family), then call the OUTPUT hook for the same family. So either the POSTROUTING or the OUTPUT hook is called for the wrong family. Ok, so changing int xfrm[46]_output(struct sk_buff*) to use the right PF hook based on the skb's [current] family should put things through the right hoops, right? Almost, in xfrm4_output the conditional calling of the hook should only be done for IPv4 and the IPCB is not valid for IPv6 of course. Speaking of which, shouldn't the entire cb be zeroed for interfamily transforms? xfrm4_tunnel_output only clears out the options, and I think your patch didn't touch it at all .. - 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: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
If SCTP data sender received a SACK which contains Cumulative TSN Ack is
not less than the Cumulative TSN Ack Point, and if this Cumulative TSN
Ack is not used by the data sender, SCTP data sender still accept this
SACK , and next SACK which send correctly to DATA sender be dropped,
because it is less than the new Cumulative TSN Ack Point.
After received this SACK, data will be retrans again and again even if
correct SACK is received.
So I think this SACK must be dropped to let data transmit correctly.
Following is the tcpdump of my test. And patch in this mail can avoid
this problem.
02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS: 10]
[MIS: 65535] [init TSN: 217114040]
02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100]
[MIS: 65535] [init TSN: 100]
02:19:39.798583 sctp (1) [COOKIE ECHO]
02:19:40.082125 sctp (1) [COOKIE ACK]
02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0]
[PPID 0xf192090b]
02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1]
[PPID 0x3e467007]
02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2]
[PPID 0x11b12a0a]
02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3]
[PPID 0x30e7d979]
02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4]
[PPID 0x251ff86f]
02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5]
[PPID 0xe5d5da5d]
02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7]
[PPID 0xca47e645]
02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8]
[PPID 0x6c0ea150]
02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9]
[PPID 0x9cc1994f]
02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10]
[PPID 0xb1df4129]
02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks
0] [#dup tsns 0]
Signed-off-by: Wei Yongjun [EMAIL PROTECTED]
--- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.0 -0400
+++ net/sctp/sm_statefuns.c 2007-07-29 18:14:49.0 -0400
@@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
return SCTP_DISPOSITION_DISCARD;
}
+ /* If Cumulative TSN Ack is not less than the Cumulative TSN
+ * Ack which will be send in the next data, drop the SACK.
+ */
+ if (!TSN_lt(ctsn, asoc-next_tsn)) {
+ SCTP_DEBUG_PRINTK(ctsn %x\n, ctsn);
+ SCTP_DEBUG_PRINTK(next_tsn %x\n, asoc-next_tsn);
+ return SCTP_DISPOSITION_DISCARD;
+ }
+
/* Return this SACK for further processing. */
sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK,
Re: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
Gabriel C wrote: Jarek Poplawski wrote: On 28-07-2007 20:42, Gabriel C wrote: Andrew Morton wrote: On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C [EMAIL PROTECTED] wrote: Hi, I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). ... net/core/netpoll.c: In function 'netpoll_poll': net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c: In function 'netpoll_setup': net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller' make[2]: *** [net/core/netpoll.o] Error 1 make[1]: *** [net/core] Error 2 make: *** [net] Error 2 make: *** Waiting for unfinished jobs ... I think is because KGDBOE selects just NETPOLL. Looks like it. Select went and selected NETPOLL and NETPOLL_TRAP but things like CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select' remains evil. ... I think there may be a logical issue ( again if I got it right ). We need some ethernet card to work with kgdboe right ? but we don't have any if !NETDEVICES !NET_ETHERNET. So maybe some ' depends on ... NETDEVICES!=n NET_ETHERNET!=n ' is needed too ? IMHO, the only logical issue here is netpoll.c mustn't use CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't add this dependency itself. Well it does if NETDEVICES if NET_ETHERNET which booth are N when !NETDEVICES is why KGDBOE uses select and not depends on. Now KGDBOE just selects NETPOLL and NETPOLL_TRAP. Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the question is does it work without any ethernet card ? kgdboe is completely useless without a network card that has a polling driver. It seems to me that the simple and easy fix is to set it to depend on NETDEVICES but allow it to use select on NETPOLL. Would that seem reasonable? Jason. - 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: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote: Jarek Poplawski wrote: On 28-07-2007 20:42, Gabriel C wrote: Andrew Morton wrote: On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C [EMAIL PROTECTED] wrote: Hi, I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). ... net/core/netpoll.c: In function 'netpoll_poll': net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c: In function 'netpoll_setup': net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller' make[2]: *** [net/core/netpoll.o] Error 1 make[1]: *** [net/core] Error 2 make: *** [net] Error 2 make: *** Waiting for unfinished jobs ... I think is because KGDBOE selects just NETPOLL. Looks like it. Select went and selected NETPOLL and NETPOLL_TRAP but things like CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select' remains evil. ... I think there may be a logical issue ( again if I got it right ). We need some ethernet card to work with kgdboe right ? but we don't have any if !NETDEVICES !NET_ETHERNET. So maybe some ' depends on ... NETDEVICES!=n NET_ETHERNET!=n ' is needed too ? IMHO, the only logical issue here is netpoll.c mustn't use CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't add this dependency itself. Well it does if NETDEVICES if NET_ETHERNET which booth are N when !NETDEVICES is why KGDBOE uses select and not depends on. does if XXX means may use if XXX. Now KGDBOE just selects NETPOLL and NETPOLL_TRAP. Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the question is does it work without any ethernet card ? Why kgdboe should care what netpoll needs? So, I hope, you are adding this select under config NETPOLL. On the other hand, if NETPOLL should depend on NET_POLL_CONTROLLER there is probably no reason to have them both. The does it work question isn't logical issue, so it's irrelevant here... 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 net-2.6.22-rc7] xfrm beet interfamily support
On Tuesday 31 July 2007 14:14:30 Patrick McHardy wrote: Joakim Koskela wrote: Ok, so changing int xfrm[46]_output(struct sk_buff*) to use the right PF hook based on the skb's [current] family should put things through the right hoops, right? Almost, in xfrm4_output the conditional calling of the hook should only be done for IPv4 and the IPCB is not valid for IPv6 of course. Speaking of which, shouldn't the entire cb be zeroed for interfamily transforms? xfrm4_tunnel_output only clears out the options, and I think your patch didn't touch it at all .. Right, thanks for pointing out (to my understanding both flags and opts should be reset for 6-4, on 4-4 only the opts)! br ,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]: Fix sk_buff page offsets and lengths.
On Tue, Jul 31, 2007 at 02:20:51PM +0400, Evgeniy Polyakov wrote: On Mon, Jul 30, 2007 at 06:50:28PM -0700, David Miller ([EMAIL PROTECTED]) wrote: Stephen Rothwell pointed out to me that the skb_frag_struct is broken on platforms using 64K or larger page sizes, it even generates warnings when (for example) the myri10ge driver tries to assign PAGE_SIZE into frag-size. I've thus increased page offset and size to __u32 in the patch below. Maybe wrap it into #if PAGE_OFFSET 12 #endif or something like that? I'm not sure actually why drivers would want to have list of 64k pages, instead driver could call give_me_pages(size) instead of alloc_pages and per-arch allocator would return one page or set of pages. This is a handwaving for now... What about sendfile/splice on hugetlbfs? - 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: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
On Tue, Jul 31, 2007 at 06:44:52AM -0500, Jason Wessel wrote: ... kgdboe is completely useless without a network card that has a polling driver. It seems to me that the simple and easy fix is to set it to depend on NETDEVICES but allow it to use select on NETPOLL. Maybe I miss your point but polling drivers don't need NETPOLL to work (unless you need netconsole). But I don't know if there is any easy method to check such driver's dependency with select. 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: 2.6.20-2.6.21 - networking dies after random time
On Mon, Jul 30, 2007 at 09:29:38AM +0200, Marcin Ślusarz wrote: ... ps: I retested all patches posted in this thread on top of 2.6.22.1 and behavior from 2.6.21.3 didn't changed. My next tests will be on 2.6.22.x only. Marcin, I see you're quite busy, but if after testing this next Ingo's patch you are alive yet, maybe you could try one more idea? No patch this time, but if you could try this after adding boot option noirqdebug (I'd like to be sure it's not about timinig after all). Cheers thanks, 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 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
Jan-Bernd Themann wrote: On Monday 30 July 2007 22:32, Andrew Gallatin wrote: Second, you still need to set skb-ip_summed = CHECKSUM_UNNECESSARY when modified packets are flushed, else the stack will see bad checksums for packets from CHECKSUM_COMPLETE drivers using the skb interface. Fixed in the attached patch. I thought about it... As we do update the TCP checksum for aggregated packets we could add a second ip_summed field in the net_lro_mgr struct used for aggregated packets to support HW that does not have any checksum helper functionality. These drivers could set this ip_summed field to CHECKSUM_NONE, and thus leave the checksum check to the stack. I'm not sure if these old devices benefit a lot from LRO. So what do you think? This might be handy, and it would also fix the problem with CHECKSUM_PARTIAL drivers using the skb interface by allowing them to set it to CHECKSUM_UNNECESSARY. Fourth, I did some traffic sniffing to try to figure out what's going on above, and saw tcpdump complain about bad checksums. Have you tried running tcpdump -s 65535 -vvv? Have you also seen bad checksums? I seem to see this for both page- and skb-based versions of the driver. Hmmm, can't confirm that. For our skb-based version I see correct checksums for aggregated packets and for the page-based version as well. I used: (tcpdump -i ethX -s 0 -w dump.bin) in combination with ethereal. Don't see problems as well with your tcpdump command. I'm still trying to get a handle on this. It happens both with page based and skb based receive for me.. I would not be surprised if I was doing something wrong in myri10ge. But I don't see it without LRO, or with my LRO. I'll let you know when I figure it out.. In the meantime, in case you have any insight, I've left a capture of a small netcat transfer of a 64KB file full of zeros at http://www.myri.com/staff/gallatin/lro/netcat_dump.bz2 Drew - 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 net-2.6 1/2] [TCP]: Fix ratehalving with bidirectional flows
I noticed no difference in the two flow tests. That is not a bad thing, just that this test doesn't hit that code. The anomaly is that first flow does slow start then gets loss and ends up reducing it's window size all the way to the bottom, finally it recovers. This happens with Cubic, H-TCP and others as well; if the queue in the network is large enough, they don't handle the initial loss well. See the graph. attachment: reno2-after.png
Re: [ofa-general] Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver
Roland Dreier wrote: 1. When bonding enslaves an IPoIB device the bonding neighbor holds a reference to a cleanup function in the IPoIB drives. This makes it unsafe to unload the IPoIB module if there are bonding neighbors in the air. So, to avoid this race one must unload bonding before unloading IPoIB. I think we really want to resolve this somehow. Getting an oops by doing modprobe -r ipoib isn't that friendly. You are right and we want to resolve that. One way is to clean the neigh destructor function from all IPoIB neighs. The other way is to prevent ipoib unload if device is a slave or is referenced from somewhere else. I guess I would like an advice here. Also, what happened to the problem of having an address handle belonging to the wrong device on bond failover? Did you figure out a way to fix that one? This is what patch 2 handles. - R. ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Fix sk_buff page offsets and lengths.
On Tue, Jul 31, 2007 at 01:23:29PM +0100, Christoph Hellwig ([EMAIL PROTECTED]) wrote: On Tue, Jul 31, 2007 at 02:20:51PM +0400, Evgeniy Polyakov wrote: On Mon, Jul 30, 2007 at 06:50:28PM -0700, David Miller ([EMAIL PROTECTED]) wrote: Stephen Rothwell pointed out to me that the skb_frag_struct is broken on platforms using 64K or larger page sizes, it even generates warnings when (for example) the myri10ge driver tries to assign PAGE_SIZE into frag-size. I've thus increased page offset and size to __u32 in the patch below. Maybe wrap it into #if PAGE_OFFSET 12 #endif or something like that? I'm not sure actually why drivers would want to have list of 64k pages, instead driver could call give_me_pages(size) instead of alloc_pages and per-arch allocator would return one page or set of pages. This is a handwaving for now... What about sendfile/splice on hugetlbfs? offset in tcp_sendpage() ends up being poffset % PAGE_SIZE, page is struct page *page = pages[poffset / PAGE_SIZE]; So, as far as I understand, it will split bigpage into PAGE_SIZEd chunks. -- 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: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver
Quoting Moni Shoua [EMAIL PROTECTED]: Subject: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for?the bonding driver Roland Dreier wrote: 1. When bonding enslaves an IPoIB device the bonding neighbor holds a reference to a cleanup function in the IPoIB drives. This makes it unsafe to unload the IPoIB module if there are bonding neighbors in the air. So, to avoid this race one must unload bonding before unloading IPoIB. I think we really want to resolve this somehow. Getting an oops by doing modprobe -r ipoib isn't that friendly. You are right and we want to resolve that. One way is to clean the neigh destructor function from all IPoIB neighs. The other way is to prevent ipoib unload if device is a slave or is referenced from somewhere else. I guess I would like an advice here. I had this idea: Maybe we could use hard_header_cache/header_cache_update methods instead of neighbour cleanup calls. To do this, it is possible that we'll have to switch from storing pointers inside the neighbour to keeping an index there, but I expect the performance impact to be minimal. As a result, bonding would not have to copy pointers into ipoib module and module removal would get fixed. -- MST - 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: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver
Quoting Or Gerlitz [EMAIL PROTECTED]: Subject: Re: Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for?the bonding driver Michael S. Tsirkin wrote: Maybe we could use hard_header_cache/header_cache_update methods instead of neighbour cleanup calls. To do this, it is possible that we'll have to switch from storing pointers inside the neighbour to keeping an index there, but I expect the performance impact to be minimal. As a result, bonding would not have to copy pointers into ipoib module and module removal would get fixed. To be precise, bonding will copy all the symbols it copies today from the slave module (ipoib), see bond_setup_by_slave() in patch 3/7, except for the neighbour cleanup callback which is copied through coping the neigh_setup function. Not really. This copying of symbols is something that you added, isn't it? So with this approach, it won't be needed. It's always wrong to copy symbols from another module without referencing it. -- MST - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ofa-general] Re: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for the bonding driver
Michael S. Tsirkin wrote: Maybe we could use hard_header_cache/header_cache_update methods instead of neighbour cleanup calls. To do this, it is possible that we'll have to switch from storing pointers inside the neighbour to keeping an index there, but I expect the performance impact to be minimal. As a result, bonding would not have to copy pointers into ipoib module and module removal would get fixed. To be precise, bonding will copy all the symbols it copies today from the slave module (ipoib), see bond_setup_by_slave() in patch 3/7, except for the neighbour cleanup callback which is copied through coping the neigh_setup function. Or. - 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 V3 0/7] net/bonding: ADD IPoIB support for the bonding driver
Michael S. Tsirkin wrote:
Quoting Or Gerlitz [EMAIL PROTECTED]:
To be precise, bonding will copy all the symbols it copies today from
the slave module (ipoib), see bond_setup_by_slave() in patch 3/7
Not really.
This copying of symbols is something that you added, isn't it?
So with this approach, it won't be needed.
It's always wrong to copy symbols from another module without
referencing it.
Its the --first-- time you make this comment, please suggest a different
approach, the relevant code is below.
+static void bond_setup_by_slave(struct net_device *bond_dev,
+ struct net_device *slave_dev)
+{
+ bond_dev-hard_header= slave_dev-hard_header;
+ bond_dev-rebuild_header= slave_dev-rebuild_header;
+ bond_dev-hard_header_cache = slave_dev-hard_header_cache;
+ bond_dev-header_cache_update = slave_dev-header_cache_update;
+ bond_dev-hard_header_parse = slave_dev-hard_header_parse;
+
+ bond_dev-neigh_setup = slave_dev-neigh_setup;
+
+ bond_dev-type = slave_dev-type;
+ bond_dev-hard_header_len = slave_dev-hard_header_len;
+ bond_dev-addr_len = slave_dev-addr_len;
+
+ memcpy(bond_dev-broadcast, slave_dev-broadcast,
+ slave_dev-addr_len);
+}
+
/* enslave device slave to bond device master */
int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
{
@@ -1351,6 +1371,24 @@ int bond_enslave(struct net_device *bond
goto err_undo_flags;
}
+ /* set bonding device ether type by slave - bonding netdevices are
+* created with ether_setup, so when the slave type is not ARPHRD_ETHER
+* there is a need to override some of the type dependent attribs/funcs.
+*
+* bond ether type mutual exclusion - don't allow slaves of dissimilar
+* ether type (eg ARPHRD_ETHER and ARPHRD_INFINIBAND) share the same
bond
+*/
+ if (bond-slave_cnt == 0) {
+ if (slave_dev-type != ARPHRD_ETHER)
+ bond_setup_by_slave(bond_dev, slave_dev);
+ } else if (bond_dev-type != slave_dev-type) {
+ printk(KERN_ERR DRV_NAME : %s ether type (%d) is different from
+ other slaves (%d), can not enslave it.\n,
slave_dev-name,
+ slave_dev-type, bond_dev-type);
+ res = -EINVAL;
+ goto err_undo_flags;
+ }
+
-
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 V3 0/7] net/bonding: ADD IPoIB support for the bonding driver
Quoting Or Gerlitz [EMAIL PROTECTED]:
Subject: Re: [PATCH V3 0/7] net/bonding: ADD IPoIB support for?the?bonding
driver
Michael S. Tsirkin wrote:
Quoting Or Gerlitz [EMAIL PROTECTED]:
To be precise, bonding will copy all the symbols it copies today from
the slave module (ipoib), see bond_setup_by_slave() in patch 3/7
Not really.
This copying of symbols is something that you added, isn't it?
So with this approach, it won't be needed.
It's always wrong to copy symbols from another module without
referencing it.
Its the --first-- time you make this comment,
It's really a well known fact. That's where the crash
with modprobe -r comes from, right?
please suggest a different approach,
I don't know, really - if you want to access a module, you really must get
a reference to it, or to the device.
How about adding the module pointer to struct net_device?
the relevant code is below.
+static void bond_setup_by_slave(struct net_device *bond_dev,
+ struct net_device *slave_dev)
+{
+ bond_dev-hard_header = slave_dev-hard_header;
+ bond_dev-rebuild_header= slave_dev-rebuild_header;
+ bond_dev-hard_header_cache = slave_dev-hard_header_cache;
+ bond_dev-header_cache_update = slave_dev-header_cache_update;
+ bond_dev-hard_header_parse = slave_dev-hard_header_parse;
+
+ bond_dev-neigh_setup = slave_dev-neigh_setup;
+
+ bond_dev-type = slave_dev-type;
+ bond_dev-hard_header_len = slave_dev-hard_header_len;
+ bond_dev-addr_len = slave_dev-addr_len;
+
+ memcpy(bond_dev-broadcast, slave_dev-broadcast,
+ slave_dev-addr_len);
+}
+
Hmm, it seems that switching to hard_header_cache as I suggested won't help at
all.
I wonder: is bonding currently broken with devices that implement
hard_header_cache/header_cache_update?
--
MST
-
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] Trivial Kconfig fact correction
[PATCH] Trivial Kconfig fact correction This error seems to have been in the kernel for a long time. Signed-off-by: Erik Ekman [EMAIL PROTECTED] --- orig/drivers/net/wireless/Kconfig 2007-07-23 10:01:46.0 +0200 +++ edit/drivers/net/wireless/Kconfig 2007-07-31 16:47:26.0 +0200 @@ -130,7 +130,7 @@ comment Wireless 802.11 Frequency Hoppi depends on NET_RADIO PCMCIA config PCMCIA_RAYCS - tristate Aviator/Raytheon 2.4MHz wireless support + tristate Aviator/Raytheon 2.4GHz wireless support depends on NET_RADIO PCMCIA ---help--- Say Y here if you intend to attach an Aviator/Raytheon PCMCIA - 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 V3 0/7] net/bonding: ADD IPoIB support for the bonding driver
Michael S. Tsirkin wrote:
Quoting Or Gerlitz [EMAIL PROTECTED]:
Michael S. Tsirkin wrote:
It's always wrong to copy symbols from another module without
referencing it.
Its the --first-- time you make this comment,
It's really a well known fact. That's where the crash
with modprobe -r comes from, right?
no, the crash --only-- comes from the neighbour cleanup function being
called while ipoib is now probed out of the kernel. The other symbols
are not problematic. I got positive feedback that this --is-- the
problem in the previous posts and from Roland during my Sonoma presentation.
please suggest a different approach,
I don't know, really - if you want to access a module, you really must get
a reference to it, or to the device.
How about adding the module pointer to struct net_device?
I think there used to be there owner field of type struct module and it
was removed... we will check that.
the relevant code is below.
+static void bond_setup_by_slave(struct net_device *bond_dev,
+ struct net_device *slave_dev)
+{
+ bond_dev-hard_header= slave_dev-hard_header;
+ bond_dev-rebuild_header= slave_dev-rebuild_header;
+ bond_dev-hard_header_cache = slave_dev-hard_header_cache;
+ bond_dev-header_cache_update = slave_dev-header_cache_update;
+ bond_dev-hard_header_parse = slave_dev-hard_header_parse;
+
+ bond_dev-neigh_setup = slave_dev-neigh_setup;
+
+ bond_dev-type = slave_dev-type;
+ bond_dev-hard_header_len = slave_dev-hard_header_len;
+ bond_dev-addr_len = slave_dev-addr_len;
+
+ memcpy(bond_dev-broadcast, slave_dev-broadcast,
+ slave_dev-addr_len);
+}
+
Hmm, it seems that switching to hard_header_cache as I suggested won't help at
all.
why? please clarify.
I wonder: is bonding currently broken with devices that implement
hard_header_cache/header_cache_update?
I don't think so. Note that bond_setup_by_slave is only called for
slaves whose ether type is --not-- Ethernet.
Or.
-
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: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
Jarek Poplawski wrote: On Tue, Jul 31, 2007 at 12:14:36PM +0200, Gabriel C wrote: Jarek Poplawski wrote: On 28-07-2007 20:42, Gabriel C wrote: Andrew Morton wrote: On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C [EMAIL PROTECTED] wrote: Hi, I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). ... net/core/netpoll.c: In function 'netpoll_poll': net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c: In function 'netpoll_setup': net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller' make[2]: *** [net/core/netpoll.o] Error 1 make[1]: *** [net/core] Error 2 make: *** [net] Error 2 make: *** Waiting for unfinished jobs ... I think is because KGDBOE selects just NETPOLL. Looks like it. Select went and selected NETPOLL and NETPOLL_TRAP but things like CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select' remains evil. ... I think there may be a logical issue ( again if I got it right ). We need some ethernet card to work with kgdboe right ? but we don't have any if !NETDEVICES !NET_ETHERNET. So maybe some ' depends on ... NETDEVICES!=n NET_ETHERNET!=n ' is needed too ? IMHO, the only logical issue here is netpoll.c mustn't use CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't add this dependency itself. Well it does if NETDEVICES if NET_ETHERNET which booth are N when !NETDEVICES is why KGDBOE uses select and not depends on. does if XXX means may use if XXX. From what I know means only use if xxx on !xxx everything inside the if xxx is n and depends on something inside the if xxx does not work. ... menuconfig FOO bool FOO depends on BAR default y -- help -- something if FOO config BAZ depends on WHATEVR !NOT_THIS menuconfig SOMETHING_ELSE if SOMETHING_ELSE config BLUBB depends on PCI WHATNOT endif # SOMETHING_ELSE config NETPOLL def_bool NETCONSOLE config NETPOLL_TRAP bool Netpoll traffic trapping default n depends on NETPOLL config NET_POLL_CONTROLLER def_bool NETPOLL endif # FOO Now if you set FOO=n all is gone and your driver have to select whatever it needs from there. Now KGDBOE just selects NETPOLL and NETPOLL_TRAP. Adding 'select CONFIG_NET_POLL_CONTROLLER' let kgdboe compiles but the question is does it work without any ethernet card ? Why kgdboe should care what netpoll needs? So, I hope, you are adding this select under config NETPOLL. On the other hand, if NETPOLL should depend on NET_POLL_CONTROLLER there is probably no reason to have them both. NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES . Net peoples ping ?:) The does it work question isn't logical issue, so it's irrelevant here... Right irrelevant for the compile error but relevant for the fix in my opinion. Jarek P. Gabriel - 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: [TULIP] Need new maintainer
On Mon, Jul 30, 2007 at 03:31:58PM -0400, Kyle McMartin wrote: On Mon, Jul 30, 2007 at 01:04:13PM -0600, Valerie Henson wrote: The Tulip network driver needs a new maintainer! I no longer have time to maintain the Tulip network driver and I'm stepping down. Jeff Garzik would be happy to get volunteers. Val! I'm sorry to see you have to drop this one...C'est la Vie. Since I already take care of a major consumer of these devices (parisc, which pretty much all have tulip) I'm willing to take care of this. Alternately, Grant is probably willing. Yeah, I am willing and able to maintain tulip as well. Either way, parisc and some mips64 folks are stuck with tulip since that's what is embedded on the motherboard. So it would make sense for someone from either camp to maintain it. Thanks to David Lang for the offer of 4-port Dlink Tulip card. HP has two types of 4-port tulip cards (64-bit/33Mhz and 32-bit/33Mhz) that I gave to Val...so whoever picks up the maintainership can probably (eventually) get those from Val. thanks, grant - 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] genirq: temporary fix for level-triggered IRQ resend
Linus,
with -rc2 approaching i think we should apply the minimal fix below to
get Marcin's ne2k-pci networking back in working order. The
WARN_ON_ONCE() will not prevent the system from working and it will be a
reminder.
a better workaround would be to inhibit the resent vector via the
IO-APIC irqchip - but i'd still like to have the patch below because the
ne2k driver _should_ be able to survive the spurious irq that happens.
(even on Marcin's system that ne2k-pci irq line is shared with another
networking card, so an irq could happen at any moment - it's just that
with the delayed-disable logic it happens _all the time_.)
Ingo
---
From: Thomas Gleixner [EMAIL PROTECTED]
Subject: genirq: temporary fix for level-triggered IRQ resend
delayed disable relies on the ability to re-trigger the interrupt in the
case that a real interrupt happens after the software disable was set.
In this case we actually disable the interrupt on the hardware level
_after_ it occurred.
On enable_irq, we need to re-trigger the interrupt. On i386 this relies
on a hardware resend mechanism (send_IPI_self()).
Actually we only need the resend for edge type interrupts. Level type
interrupts come back once enable_irq() re-enables the interrupt line.
I assume that the interrupt in question is level triggered because it is
shared and above the legacy irqs 0-15:
17: 12 IO-APIC-fasteoi eth1, eth0
Looking into the IO_APIC code, the resend via send_IPI_self() happens
unconditionally. So the resend is done for level and edge interrupts.
This makes the problem more mysterious.
The code in question lib8390.c does
disable_irq();
fiddle_with_the_network_card_hardware()
enable_irq();
The fiddle_with_the_network_card_hardware() might cause interrupts,
which are cleared in the same code path again,
Marcin found that when he disables the irq line on the hardware level
(removing the delayed disable) the card is kept alive.
So the difference is that we can get a resend on enable_irq, when an
interrupt happens during the time, where we are in the disabled region.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
---
kernel/irq/resend.c |9 +
1 file changed, 9 insertions(+)
Index: linux/kernel/irq/resend.c
===
--- linux.orig/kernel/irq/resend.c
+++ linux/kernel/irq/resend.c
@@ -62,6 +62,15 @@ void check_irq_resend(struct irq_desc *d
*/
desc-chip-enable(irq);
+ /*
+* Temporary hack to figure out more about the problem, which
+* is causing the ancient network cards to die.
+*/
+ if (desc-handle_irq != handle_edge_irq) {
+ WARN_ON_ONCE(1);
+ return;
+ }
+
if ((status (IRQ_PENDING | IRQ_REPLAY)) == IRQ_PENDING) {
desc-status = (status ~IRQ_PENDING) | IRQ_REPLAY;
-
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 net-2.6 1/2] [TCP]: Fix ratehalving with bidirectional flows
On Tue, 31 Jul 2007, Stephen Hemminger wrote: I noticed no difference in the two flow tests. That is not a bad thing, just that this test doesn't hit that code. ...I'm not too sure about your test setup but the bugs I fixed only cover cases that occur if flow is bidirectional (and obviously active in both directions at the same time), they won't occur in a case of unidirectional transfer or in request-reply style connections (well, in the latter case if there's some overlap, it can have effect but that's usually not significant)... In case of bidirectional transfers, you *should* see some difference as previously the fast recovery was _very_ broken. Of course there could be other issue with large cwnd TCP that hides it by going to RTO still, but at least over 384k/200ms link (DBP sized buffers, IIRC), these change behavior very dramatically, mainly in the initial slow-start overshoot recovery because in there losses per RTT is so high number compared to what is experienced later on. One or a few losses are usually recovered without RTO when congestion happens later on. The anomaly is that first flow does slow start then gets loss and ends up reducing it's window size all the way to the bottom, finally it recovers. This happens with Cubic, H-TCP and others as well; if the queue in the network is large enough, they don't handle the initial loss well. ...TCP related stuff that changed in /proc/net/netstat might shed some light to this if none of the given explinations please you... :-) See the graph. What exactly do you mean by RENO in the title, I mean what's tcp_sack set to? There is occassionally a bit confusion in that respect in the terminology @ netdev, I've used to reno refering to non-SACK stuff elsewhere but in here that's not always the case... Usually it's possible to derive the correct interpretation from the context, but in this case I'm not too sure... :-) What I often have often seen with non-SACK TCP is that initial slow-start exhausts even very large advertised window on high DBP link and then due to draining of ACK feedback, gets RTOed... That usually shows up as long lasting recovery where one segment per RTT is recovered and new data is being sent as duplicate ACKs arrive with nearly constant rate until the window limit is hit (but I cannot see such periond in the graph you posted, so I guess it's not the explanation in this case). And if your RENO refers to something with SACK, that's not going to explain it anyway. ...Another nasty one I know is RED+ECN, though I'd say it's a bit far fetched one, as ECN cannot be used nicely in retransmission, a retransmission gets dropped instead of marking if RED wanted to mark. I guess that doesn't occur in your test case either? -- i. - 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] genirq: temporary fix for level-triggered IRQ resend
* Ingo Molnar [EMAIL PROTECTED] wrote: Linus, with -rc2 approaching i think we should apply the minimal fix below to get Marcin's ne2k-pci networking back in working order. The WARN_ON_ONCE() will not prevent the system from working and it will be a reminder. there's one more test-patch that Marcin has not tested yet (see below) - perhaps a POST artifact in ne2k could explain this bug. Ingo - * Alan Cox [EMAIL PROTECTED] wrote: Ok the logic behind the 8390 is very simple: thanks for the explanation Alan! A few comments and a question: Things to know - IRQ delivery is asynchronous to the PCI bus - Blocking the local CPU IRQ via spin locks was too slow - The chip has register windows needing locking work So the path was once (I say once as people appear to have changed it in the mean time and it now looks rather bogus if the changes to use disable_irq_nosync_irqsave are disabling the local IRQ) Take the page lock Mask the IRQ on chip Disable the IRQ (but not mask locally- someone seems to have broken this with the lock validator stuff) [This must be _nosync as the page lock may otherwise deadlock us] ( side-note: you can ignore the lock validator stuff here, the validator changes are supposed to a NOP on the !lockdep case. Local irqs will only be disabled if the validator is running. This could cause dropped serial irqs on very old boxes but i doubt anyone will want to run the validator on those. ) Drop the page lock and turn IRQs back on At this point an existing IRQ may still be running but we can't get a new one Take the lock (so we know the IRQ has terminated) but don't mask the IRQs on the processor Set irqlock [for debug] Transmit (slow as ) re-enable the IRQ We have to use disable_irq because otherwise you will get delayed interrupts on the APIC bus deadlocking the transmit path. Quite hairy but the chip simply wasn't designed for SMP and you can't even ACK an interrupt without risking corrupting other parallel activities on the chip. So the whole locking is to be able to keep irqs enabled for a long time, without risking entry of the same IRQ handler on this same CPU, correct? Marcin's test results suggest that if an IRQ is resent right at the enable_irq() point [be that via the hw irq-resend mechanism or the sw irq-resend mechanism], the hang happens. In the previous 2.6.20 logic we'd not normally generate an IRQ at that point (because we masked the irq and the card itself deasserts the line so any level-triggered irq is now moot). Once Thomas hacked off this resend mechanism for level-triggered irqs, Marcin saw the hangs go away. So it seems to me that maybe the driver could be surprised via these spurious interrupts that happen right after the irq_enable(). Does the patch below make any sense in your opinion? Ingo Index: linux/drivers/net/lib8390.c === --- linux.orig/drivers/net/lib8390.c +++ linux/drivers/net/lib8390.c @@ -375,6 +375,8 @@ static int ei_start_xmit(struct sk_buff /* Turn 8390 interrupts back on. */ ei_local-irqlock = 0; ei_outb_p(ENISR_ALL, e8390_base + EN0_IMR); + /* force POST: */ + ei_inb_p(e8390_base + EN0_IMR); spin_unlock(ei_local-page_lock); enable_irq_lockdep_irqrestore(dev-irq, flags); - 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
Disabling timestamps on AF_PACKET sockets
Hello,
I want to capture huge amounts of packets without timestamps, since the
machine the program is running on has a very slow clock that only yields
200,000 timestamps per second and uses 70% of CPU. But tpacket_rcv
reenables the timestamps every time it receives a packet at af_packet.c:643
if (skb-tstamp.tv64 == 0) {
__net_timestamp(skb);
sock_enable_timestamp(sk);
}
I suppose that a patch that just removes that four lines won't be
accepted, since breaks an userspace interface. Isn't it?
So I've tried to enable timestamp when you setup the ring (to not affect
other programs) and disabling it latter from user space clearing the
SO_TIMESTAMP option. But it doesn't work, since timestamps can't be
disabled until the socket is closed.
If enabling SO_TIMESTAMP socket option sets SOCK_RCVTSTAMP and calls
sock_enable_timestamp, why disabling it just clears SOCK_RCVTSTAMP and
don't call sock_disable_timestamp?
Thanks.
begin:vcard
fn;quoted-printable:Unai Uribarri Rodr=C3=ADguez
n;quoted-printable:Uribarri Rodr=C3=ADguez;Unai
org:Optenet;Research Development
adr;quoted-printable;quoted-printable:Calle Jos=C3=A9 Echegaray 8;;Parque Empresarial Alvia;Las Rozas;Madrid;28232;Espa=C3=B1a
email;internet:[EMAIL PROTECTED]
tel;work:+34 902 154 604
tel;home:+34 913 575 433
tel;cell:+34 609 54 91 61
x-mozilla-html:TRUE
url:http://www.optenet.com
version:2.1
end:vcard
Re: RFC: on [ab]use of skb-cb by VLAN code
Do we really need an 'unsigned int' for mac_len? Maybe we could use a 16-bit counter here, and then use the other 16 bits for the VLAN bits? Not knowing exactly if/how it interacts with that specific field I will point-out that IPoIB in OFED 1.2 just took their MTU to 65520. While that doesn't break the bitbank it does get rather close. rick jones - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote:
On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
If SCTP data sender received a SACK which contains Cumulative TSN Ack is
not less than the Cumulative TSN Ack Point, and if this Cumulative TSN
Ack is not used by the data sender, SCTP data sender still accept this
SACK , and next SACK which send correctly to DATA sender be dropped,
because it is less than the new Cumulative TSN Ack Point.
After received this SACK, data will be retrans again and again even if
correct SACK is received.
So I think this SACK must be dropped to let data transmit correctly.
Following is the tcpdump of my test. And patch in this mail can avoid
this problem.
02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS:
10] [MIS: 65535] [init TSN: 217114040]
02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100]
[MIS: 65535] [init TSN: 100]
02:19:39.798583 sctp (1) [COOKIE ECHO]
02:19:40.082125 sctp (1) [COOKIE ACK]
02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0]
[PPID 0xf192090b]
02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1]
[PPID 0x3e467007]
02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2]
[PPID 0x11b12a0a]
02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3]
[PPID 0x30e7d979]
02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4]
[PPID 0x251ff86f]
02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5]
[PPID 0xe5d5da5d]
02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7]
[PPID 0xca47e645]
02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8]
[PPID 0x6c0ea150]
02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9]
[PPID 0x9cc1994f]
02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10]
[PPID 0xb1df4129]
02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
Signed-off-by: Wei Yongjun [EMAIL PROTECTED]
--- net/sctp/sm_statefuns.c.orig2007-07-29 18:11:01.0 -0400
+++ net/sctp/sm_statefuns.c 2007-07-29 18:14:49.0 -0400
@@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
return SCTP_DISPOSITION_DISCARD;
}
+ /* If Cumulative TSN Ack is not less than the Cumulative TSN
+* Ack which will be send in the next data, drop the SACK.
+*/
+ if (!TSN_lt(ctsn, asoc-next_tsn)) {
+ SCTP_DEBUG_PRINTK(ctsn %x\n, ctsn);
+ SCTP_DEBUG_PRINTK(next_tsn %x\n, asoc-next_tsn);
+ return
[PATCH 20] net/decnet/dn_route.c: kmalloc + memset conversion to kzalloc
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
net/decnet/dn_route.c | 45013 - 44991 (-22 bytes)
net/decnet/dn_route.o | 199388 - 199580 (+192 bytes)
net/decnet/dn_route.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.23-rc1-mm1-a/net/decnet/dn_route.c2007-07-26
13:07:44.0 +0200
+++ linux-2.6.23-rc1-mm1-b/net/decnet/dn_route.c2007-07-31
15:15:11.0 +0200
@@ -1737,8 +1737,9 @@ static int dn_rt_cache_seq_open(struct i
{
struct seq_file *seq;
int rc = -ENOMEM;
- struct dn_rt_cache_iter_state *s = kmalloc(sizeof(*s), GFP_KERNEL);
-
+ struct dn_rt_cache_iter_state *s;
+
+ s = kzalloc(sizeof(*s), GFP_KERNEL);
if (!s)
goto out;
rc = seq_open(file, dn_rt_cache_seq_ops);
@@ -1746,7 +1747,6 @@ static int dn_rt_cache_seq_open(struct i
goto out_kfree;
seq = file-private_data;
seq-private= s;
- memset(s, 0, sizeof(*s));
out:
return rc;
out_kfree:
-
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: RFC: on [ab]use of skb-cb by VLAN code
Do we really need an 'unsigned int' for mac_len? Maybe we could use a 16-bit counter here, and then use the other 16 bits for the VLAN bits? Not knowing exactly if/how it interacts with that specific field I will point-out that IPoIB in OFED 1.2 just took their MTU to 65520. While that doesn't break the bitbank it does get rather close. Leaving aside OFED releases, the IPoIB connected mode code in the standard kernel also allows the MTU to go up to 65520. And there's nothing magic about that value -- we could easily do bigger packets. However, this is irrelevant for two reasons: mac_len is the length of the LL header, not the packet overall, *and* mac_len is already 16 bits as of commit 334a8132. - R. - 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.23 1/2] Make the iw_cxgb3 module parameters writable.
Roland Dreier wrote: ugh, missed these before my last merge... anyway: why do we want to parameters writable? a good changelog tells me what, why and how, and this changelog just covered the what. Also, I assume you've checked that it's OK for these variables to change at any time? I want to be able to changes these parameters at run time. Eventually, if we might want these parameters as rdma connection setup parameters. For now, its useful to be able to set them without reloading. Also, it is safe to change them at any time. All of these are read once and utilized at connection setup. So changing them is safe in that existing connections aren't affected, and only subsequent connections will utilize the new values. Sorry for the terse changelog... Steve. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 39] net/ipv4/ip_options.c: kmalloc + memset conversion to kzalloc
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
net/ipv4/ip_options.c | 15425 - 15368 (-57 bytes)
net/ipv4/ip_options.o | 133668 - 133588 (-80 bytes)
net/ipv4/ip_options.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
--- linux-2.6.23-rc1-mm1-a/net/ipv4/ip_options.c2007-07-26
13:07:44.0 +0200
+++ linux-2.6.23-rc1-mm1-b/net/ipv4/ip_options.c2007-07-31
15:17:22.0 +0200
@@ -513,11 +513,8 @@ void ip_options_undo(struct ip_options *
static struct ip_options *ip_options_get_alloc(const int optlen)
{
- struct ip_options *opt = kmalloc(sizeof(*opt) + ((optlen + 3) ~3),
-GFP_KERNEL);
- if (opt)
- memset(opt, 0, sizeof(*opt));
- return opt;
+ return kzalloc(sizeof(struct ip_options) + ((optlen + 3) ~3),
+ GFP_KERNEL);
}
static int ip_options_get_finish(struct ip_options **optp,
-
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] [NET]: fix multicast list when cloning sockets
On Tue, Jul 31, 2007 at 12:00:41AM -0300, Arnaldo Carvalho de Melo wrote:
On 7/30/07, David Miller [EMAIL PROTECTED] wrote:
Allowing non-datagram sockets to end up with a non-NULL inet-mc_list
in the first place is a bug.
Multicast subscriptions cannot even be used with TCP and DCCP, which
are the only two users of these connection oriented socket functions.
The first thing that TCP and DCCP do, in fact, for input packet
processing is drop the packet if it is not unicast.
Therefore the fix really is for the inet layer to reject multicast
subscription requests on sockets for which that absolutely does not
make sense. There is no reason these functions in
inet_connection_sock.c should need to be mindful of multicast
state. :-)
Well, we can add a BUG_ON there then 8)
Flavio, take a look at do_ip_setsockopt in net/ipv4/ip_sockglue.c, in
the IP_{ADD,DROP}_MEMBERSHIP labels.
Don't forget IPV6 (net/ipv6/ipv6_sockglue.c)
yes, right. What about the one below?
[NET]: Fix IP_ADD/DROP_MEMBERSHIP to handle only connectionless
Fix IP[V6]_ADD_MEMBERSHIP and IP[V6]_DROP_MEMBERSHIP to
return -EPROTO for connection oriented sockets.
Signed-off-by: Flavio Leitner [EMAIL PROTECTED]
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 4d54457..6b420ae 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -625,6 +625,10 @@ static int do_ip_setsockopt(struct sock *sk, int level,
{
struct ip_mreqn mreq;
+ err = -EPROTO;
+ if (inet_sk(sk)-is_icsk)
+ break;
+
if (optlen sizeof(struct ip_mreq))
goto e_inval;
err = -EFAULT;
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index d684639..350e584 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -554,6 +554,10 @@ done:
{
struct ipv6_mreq mreq;
+ retv = -EPROTO;
+ if (inet_sk(sk)-is_icsk)
+ break;
+
retv = -EFAULT;
if (copy_from_user(mreq, optval, sizeof(struct ipv6_mreq)))
break;
--
1.5.2.4
--
Flavio
-
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
[PATCHES] RFC: Ethtool patches to add multi queue support, LRO
All, Recently new features have been written to add multiqueue support and LRO. However, none of the patches touch on a basic configuration scheme and most use module parameters. I propose several patches to add support to change these features for LRO and multiqueue. Currently these patches are implemented in the most generic way possible (largely copy/paste from current ethtool code) - and add 'ethtool -k lro on|off' support that toggles the NETIF_F_LRO generic device flag, and a new ethtool_queueparam struct to get/pass rx and tx queue count. I'm contenplating adding a usecs-irq non-rx non-tx parameter for the intel (1/10) gigabit adapters since our adapters share an interrupt moderation counters for both rx and tx, but that will come later. 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
[PATCH] [NET] ethtool: Add LRO support
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
include/linux/ethtool.h |8 +++
include/linux/netdevice.h |1 +
net/core/ethtool.c| 54 -
3 files changed, 62 insertions(+), 1 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 3a63224..ab9d688 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -274,6 +274,8 @@ int ethtool_op_get_perm_addr(struct net_device *dev,
struct ethtool_perm_addr *addr, u8 *data);
u32 ethtool_op_get_ufo(struct net_device *dev);
int ethtool_op_set_ufo(struct net_device *dev, u32 data);
+u32 ethtool_op_get_lro(struct net_device *dev);
+int ethtool_op_set_lro(struct net_device *dev, u32 data);
/**
* ethtool_ops - Alter and report network device settings
@@ -305,6 +307,8 @@ int ethtool_op_set_ufo(struct net_device *dev, u32 data);
* set_tso: Turn TCP segmentation offload on or off
* get_ufo: Report whether UDP fragmentation offload is enabled
* set_ufo: Turn UDP fragmentation offload on or off
+ * get_lro: Report whether large receive offload is enabled
+ * set_lro: Turn large receive offload on or off
* self_test: Run specified self-tests
* get_strings: Return a set of strings that describe the requested objects
* phys_id: Identify the device
@@ -373,6 +377,8 @@ struct ethtool_ops {
void(*complete)(struct net_device *);
u32 (*get_ufo)(struct net_device *);
int (*set_ufo)(struct net_device *, u32);
+ u32 (*get_lro)(struct net_device *);
+ int (*set_lro)(struct net_device *, u32);
};
#endif /* __KERNEL__ */
@@ -414,6 +420,8 @@ struct ethtool_ops {
#define ETHTOOL_SUFO 0x0022 /* Set UFO enable (ethtool_value) */
#define ETHTOOL_GGSO 0x0023 /* Get GSO enable (ethtool_value) */
#define ETHTOOL_SGSO 0x0024 /* Set GSO enable (ethtool_value) */
+#define ETHTOOL_GLRO 0x0025 /* Get LRO enable (ethtool_value) */
+#define ETHTOOL_SLRO 0x0026 /* Set LRO enable (ethtool_value) */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 4a616d7..4863ffc 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -341,6 +341,7 @@ struct net_device
#define NETIF_F_GSO2048/* Enable software GSO. */
#define NETIF_F_LLTX 4096/* LockLess TX */
#define NETIF_F_MULTI_QUEUE16384 /* Has multiple TX/RX queues */
+#define NETIF_F_LRO32768 /* Has large receive offload */
/* Segmentation offload features */
#define NETIF_F_GSO_SHIFT 16
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 0b531e9..23ccaa1 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -104,7 +104,6 @@ int ethtool_op_get_perm_addr(struct net_device *dev, struct
ethtool_perm_addr *a
return 0;
}
-
u32 ethtool_op_get_ufo(struct net_device *dev)
{
return (dev-features NETIF_F_UFO) != 0;
@@ -119,6 +118,20 @@ int ethtool_op_set_ufo(struct net_device *dev, u32 data)
return 0;
}
+u32 ethtool_op_get_lro(struct net_device *dev)
+{
+ return (dev-features NETIF_F_LRO) != 0;
+}
+
+int ethtool_op_set_lro(struct net_device *dev, u32 data)
+{
+ if (data)
+ dev-features |= NETIF_F_LRO;
+ else
+ dev-features = ~NETIF_F_LRO;
+ return 0;
+}
+
/* Handlers for each ethtool command */
static int ethtool_get_settings(struct net_device *dev, void __user *useraddr)
@@ -514,6 +527,13 @@ static int __ethtool_set_sg(struct net_device *dev, u32
data)
if (err)
return err;
}
+
+ if (!data dev-ethtool_ops-set_lro) {
+ err = dev-ethtool_ops-set_lro(dev, 0);
+ if (err)
+ return err;
+ }
+
return dev-ethtool_ops-set_sg(dev, data);
}
@@ -625,6 +645,29 @@ static int ethtool_set_ufo(struct net_device *dev, char
__user *useraddr)
return dev-ethtool_ops-set_ufo(dev, edata.data);
}
+static int ethtool_get_lro(struct net_device *dev, char __user *useraddr)
+{
+ struct ethtool_value edata = { ETHTOOL_GLRO };
+
+ edata.data = dev-features NETIF_F_LRO;
+ if (copy_to_user(useraddr, edata, sizeof(edata)))
+return -EFAULT;
+ return 0;
+}
+
+static int ethtool_set_lro(struct net_device *dev, char __user *useraddr)
+{
+ struct ethtool_value edata;
+
+ if (copy_from_user(edata, useraddr, sizeof(edata)))
+ return -EFAULT;
+ if (edata.data)
+ dev-features |= NETIF_F_LRO;
+ else
+ dev-features = ~NETIF_F_LRO;
+ return 0;
+}
+
static int ethtool_get_gso(struct net_device *dev, char __user *useraddr)
{
struct ethtool_value edata = { ETHTOOL_GGSO };
@@ -840,6 +883,7 @@
[PATCH] ethtool: Add LRO support
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
ethtool-copy.h |8
ethtool.8 |8 ++--
ethtool.c | 39 +--
3 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index 3a63224..ab9d688 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -274,6 +274,8 @@ int ethtool_op_get_perm_addr(struct net_device *dev,
struct ethtool_perm_addr *addr, u8 *data);
u32 ethtool_op_get_ufo(struct net_device *dev);
int ethtool_op_set_ufo(struct net_device *dev, u32 data);
+u32 ethtool_op_get_lro(struct net_device *dev);
+int ethtool_op_set_lro(struct net_device *dev, u32 data);
/**
* ethtool_ops - Alter and report network device settings
@@ -305,6 +307,8 @@ int ethtool_op_set_ufo(struct net_device *dev, u32 data);
* set_tso: Turn TCP segmentation offload on or off
* get_ufo: Report whether UDP fragmentation offload is enabled
* set_ufo: Turn UDP fragmentation offload on or off
+ * get_lro: Report whether large receive offload is enabled
+ * set_lro: Turn large receive offload on or off
* self_test: Run specified self-tests
* get_strings: Return a set of strings that describe the requested objects
* phys_id: Identify the device
@@ -373,6 +377,8 @@ struct ethtool_ops {
void(*complete)(struct net_device *);
u32 (*get_ufo)(struct net_device *);
int (*set_ufo)(struct net_device *, u32);
+ u32 (*get_lro)(struct net_device *);
+ int (*set_lro)(struct net_device *, u32);
};
#endif /* __KERNEL__ */
@@ -414,6 +420,8 @@ struct ethtool_ops {
#define ETHTOOL_SUFO 0x0022 /* Set UFO enable (ethtool_value) */
#define ETHTOOL_GGSO 0x0023 /* Get GSO enable (ethtool_value) */
#define ETHTOOL_SGSO 0x0024 /* Set GSO enable (ethtool_value) */
+#define ETHTOOL_GLRO 0x0025 /* Get LRO enable (ethtool_value) */
+#define ETHTOOL_SLRO 0x0026 /* Set LRO enable (ethtool_value) */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/ethtool.8 b/ethtool.8
index af51056..89abf08 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -158,6 +158,7 @@ ethtool \- Display or change ethernet card settings
.B2 tso on off
.B2 ufo on off
.B2 gso on off
+.B2 lro on off
.B ethtool \-p|\-\-blink
.I ethX
@@ -289,10 +290,13 @@ Specifies whether scatter-gather should be enabled.
Specifies whether TCP segmentation offload should be enabled.
.TP
.A2 ufo on off
-Specifies whether UDP fragmentation offload should be enabled
+Specifies whether UDP fragmentation offload should be enabled.
.TP
.A2 gso on off
-Specifies whether generic segmentation offload should be enabled
+Specifies whether generic segmentation offload should be enabled.
+.TP
+.A2 lro on off
+Specifies whether large receive offload should be enabled.
.TP
.B \-p \-\-identify
Initiates adapter-specific action intended to enable an operator to
diff --git a/ethtool.c b/ethtool.c
index b04f747..4c9844a 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -151,7 +151,8 @@ static struct option {
[ sg on|off ]\n
[ tso on|off ]\n
[ ufo on|off ]\n
- [ gso on|off ]\n },
+ [ gso on|off ]\n
+ [ lro on|off ]\n },
{ -i, --driver, MODE_GDRV, Show driver information },
{ -d, --register-dump, MODE_GREGS, Do a register dump,
[ raw on|off ]\n
@@ -200,6 +201,7 @@ static int off_sg_wanted = -1;
static int off_tso_wanted = -1;
static int off_ufo_wanted = -1;
static int off_gso_wanted = -1;
+static int off_lro_wanted = -1;
static struct ethtool_pauseparam epause;
static int gpause_changed = 0;
@@ -310,6 +312,7 @@ static struct cmdline_info cmdline_offload[] = {
{ tso, CMDL_BOOL, off_tso_wanted, NULL },
{ ufo, CMDL_BOOL, off_ufo_wanted, NULL },
{ gso, CMDL_BOOL, off_gso_wanted, NULL },
+ { lro, CMDL_BOOL, off_lro_wanted, NULL },
};
static struct cmdline_info cmdline_pause[] = {
@@ -1207,7 +1210,7 @@ static int dump_coalesce(void)
return 0;
}
-static int dump_offload (int rx, int tx, int sg, int tso, int ufo, int gso)
+static int dump_offload (int rx, int tx, int sg, int tso, int ufo, int gso,
int lro)
{
fprintf(stdout,
rx-checksumming: %s\n
@@ -1215,13 +1218,15 @@ static int dump_offload (int rx, int tx, int sg, int
tso, int ufo, int gso)
scatter-gather: %s\n
tcp segmentation offload: %s\n
udp fragmentation offload: %s\n
- generic segmentation offload: %s\n,
+ generic segmentation offload: %s\n
+ large receive offload: %s\n,
rx ? on : off,
tx ? on : off,
sg ? on : off,
[PATCH] [NET] ethtool: Add support for multiple queues
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
include/linux/ethtool.h | 23 +++
net/core/ethtool.c | 34 ++
2 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index ab9d688..aefd580 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -196,6 +196,23 @@ struct ethtool_ringparam {
__u32 tx_pending;
};
+/* for configuring RX/TX queue count */
+struct ethtool_queueparam {
+ __u32 cmd;/* ETHTOOL_{G,S}QUEUEPARAM */
+
+ /* Read only attributes. These indicate the maximum number
+* of RX/TX queues the driver will allow the user to set.
+*/
+ __u32 rx_max;
+ __u32 tx_max;
+
+ /* Values changeable by the user. The valid values are
+* in the range 1 to the *_max counterpart above.
+*/
+ __u32 rx;
+ __u32 tx;
+};
+
/* for configuring link flow control parameters */
struct ethtool_pauseparam {
__u32 cmd;/* ETHTOOL_{G,S}PAUSEPARAM */
@@ -295,6 +312,8 @@ int ethtool_op_set_lro(struct net_device *dev, u32 data);
* set_coalesce: Set interrupt coalescing parameters
* get_ringparam: Report ring sizes
* set_ringparam: Set ring sizes
+ * get_queueparam: Report ring sizes
+ * set_queueparam: Set ring sizes
* get_pauseparam: Report pause parameters
* set_pauseparam: Set pause paramters
* get_rx_csum: Report whether receive checksums are turned on or off
@@ -356,6 +375,8 @@ struct ethtool_ops {
int (*set_coalesce)(struct net_device *, struct ethtool_coalesce *);
void(*get_ringparam)(struct net_device *, struct ethtool_ringparam
*);
int (*set_ringparam)(struct net_device *, struct ethtool_ringparam
*);
+ void(*get_queueparam)(struct net_device *, struct
ethtool_queueparam *);
+ int (*set_queueparam)(struct net_device *, struct
ethtool_queueparam *);
void(*get_pauseparam)(struct net_device *, struct
ethtool_pauseparam*);
int (*set_pauseparam)(struct net_device *, struct
ethtool_pauseparam*);
u32 (*get_rx_csum)(struct net_device *);
@@ -422,6 +443,8 @@ struct ethtool_ops {
#define ETHTOOL_SGSO 0x0024 /* Set GSO enable (ethtool_value) */
#define ETHTOOL_GLRO 0x0025 /* Get LRO enable (ethtool_value) */
#define ETHTOOL_SLRO 0x0026 /* Set LRO enable (ethtool_value) */
+#define ETHTOOL_GQUEUEPARAM0x0027 /* Get queue parameters */
+#define ETHTOOL_SQUEUEPARAM0x0028 /* Set queue parameters. */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 23ccaa1..f1a1234 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -443,6 +443,33 @@ static int ethtool_set_ringparam(struct net_device *dev,
void __user *useraddr)
return dev-ethtool_ops-set_ringparam(dev, ringparam);
}
+static int ethtool_get_queueparam(struct net_device *dev, void __user
*useraddr)
+{
+ struct ethtool_queueparam queueparam = { ETHTOOL_GQUEUEPARAM };
+
+ if (!dev-ethtool_ops-get_queueparam)
+ return -EOPNOTSUPP;
+
+ dev-ethtool_ops-get_queueparam(dev, queueparam);
+
+ if (copy_to_user(useraddr, queueparam, sizeof(queueparam)))
+ return -EFAULT;
+ return 0;
+}
+
+static int ethtool_set_queueparam(struct net_device *dev, void __user
*useraddr)
+{
+ struct ethtool_queueparam queueparam;
+
+ if (!dev-ethtool_ops-set_queueparam)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(queueparam, useraddr, sizeof(queueparam)))
+ return -EFAULT;
+
+ return dev-ethtool_ops-set_queueparam(dev, queueparam);
+}
+
static int ethtool_get_pauseparam(struct net_device *dev, void __user
*useraddr)
{
struct ethtool_pauseparam pauseparam = { ETHTOOL_GPAUSEPARAM };
@@ -875,6 +902,7 @@ int dev_ethtool(struct ifreq *ifr)
case ETHTOOL_GMSGLVL:
case ETHTOOL_GCOALESCE:
case ETHTOOL_GRINGPARAM:
+ case ETHTOOL_GQUEUEPARAM:
case ETHTOOL_GPAUSEPARAM:
case ETHTOOL_GRXCSUM:
case ETHTOOL_GTXCSUM:
@@ -946,6 +974,12 @@ int dev_ethtool(struct ifreq *ifr)
case ETHTOOL_SRINGPARAM:
rc = ethtool_set_ringparam(dev, useraddr);
break;
+ case ETHTOOL_GQUEUEPARAM:
+ rc = ethtool_get_queueparam(dev, useraddr);
+ break;
+ case ETHTOOL_SQUEUEPARAM:
+ rc = ethtool_set_queueparam(dev, useraddr);
+ break;
case ETHTOOL_GPAUSEPARAM:
rc = ethtool_get_pauseparam(dev, useraddr);
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] ethtool: Add support for setting multiple rx/tx queues
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
ethtool-copy.h | 23 +
ethtool.8 | 23 +
ethtool.c | 103
3 files changed, 149 insertions(+), 0 deletions(-)
diff --git a/ethtool-copy.h b/ethtool-copy.h
index ab9d688..aefd580 100644
--- a/ethtool-copy.h
+++ b/ethtool-copy.h
@@ -196,6 +196,23 @@ struct ethtool_ringparam {
__u32 tx_pending;
};
+/* for configuring RX/TX queue count */
+struct ethtool_queueparam {
+ __u32 cmd;/* ETHTOOL_{G,S}QUEUEPARAM */
+
+ /* Read only attributes. These indicate the maximum number
+* of RX/TX queues the driver will allow the user to set.
+*/
+ __u32 rx_max;
+ __u32 tx_max;
+
+ /* Values changeable by the user. The valid values are
+* in the range 1 to the *_max counterpart above.
+*/
+ __u32 rx;
+ __u32 tx;
+};
+
/* for configuring link flow control parameters */
struct ethtool_pauseparam {
__u32 cmd;/* ETHTOOL_{G,S}PAUSEPARAM */
@@ -295,6 +312,8 @@ int ethtool_op_set_lro(struct net_device *dev, u32 data);
* set_coalesce: Set interrupt coalescing parameters
* get_ringparam: Report ring sizes
* set_ringparam: Set ring sizes
+ * get_queueparam: Report ring sizes
+ * set_queueparam: Set ring sizes
* get_pauseparam: Report pause parameters
* set_pauseparam: Set pause paramters
* get_rx_csum: Report whether receive checksums are turned on or off
@@ -356,6 +375,8 @@ struct ethtool_ops {
int (*set_coalesce)(struct net_device *, struct ethtool_coalesce *);
void(*get_ringparam)(struct net_device *, struct ethtool_ringparam
*);
int (*set_ringparam)(struct net_device *, struct ethtool_ringparam
*);
+ void(*get_queueparam)(struct net_device *, struct
ethtool_queueparam *);
+ int (*set_queueparam)(struct net_device *, struct
ethtool_queueparam *);
void(*get_pauseparam)(struct net_device *, struct
ethtool_pauseparam*);
int (*set_pauseparam)(struct net_device *, struct
ethtool_pauseparam*);
u32 (*get_rx_csum)(struct net_device *);
@@ -422,6 +443,8 @@ struct ethtool_ops {
#define ETHTOOL_SGSO 0x0024 /* Set GSO enable (ethtool_value) */
#define ETHTOOL_GLRO 0x0025 /* Get LRO enable (ethtool_value) */
#define ETHTOOL_SLRO 0x0026 /* Set LRO enable (ethtool_value) */
+#define ETHTOOL_GQUEUEPARAM0x0027 /* Get queue parameters */
+#define ETHTOOL_SQUEUEPARAM0x0028 /* Set queue parameters. */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/ethtool.8 b/ethtool.8
index 89abf08..3f2e0c0 100644
--- a/ethtool.8
+++ b/ethtool.8
@@ -120,6 +120,17 @@ ethtool \- Display or change ethernet card settings
.RB [ tx
.IR N ]
+
+.B ethtool \-q|\-\-show\-queue
+.I ethX
+
+.B ethtool \-Q|\-\-set\-queue
+.I ethX
+.RB [ rx
+.IR N ]
+.RB [ tx
+.IR N ]
+
.B ethtool \-i|\-\-driver
.I ethX
@@ -243,6 +254,18 @@ Changes the number of ring entries for the Rx Jumbo ring.
.BI tx \ N
Changes the number of ring entries for the Tx ring.
.TP
+.B \-q \-\-show\-queue
+Queries the specified ethernet device for rx/tx queue parameter information.
+.TP
+.B \-Q \-\-set\-queue
+Changes the rx/tx queue parameters of the specified ethernet device.
+.TP
+.BI rx \ N
+Changes the number of Rx queues.
+.TP
+.BI tx \ N
+Changes the number of Tx queues.
+.TP
.B \-i \-\-driver
Queries the specified ethernet device for associated driver information.
.TP
diff --git a/ethtool.c b/ethtool.c
index 4c9844a..227349f 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -64,6 +64,8 @@ static int do_gpause(int fd, struct ifreq *ifr);
static int do_spause(int fd, struct ifreq *ifr);
static int do_gring(int fd, struct ifreq *ifr);
static int do_sring(int fd, struct ifreq *ifr);
+static int do_gqueue(int fd, struct ifreq *ifr);
+static int do_squeue(int fd, struct ifreq *ifr);
static int do_gcoalesce(int fd, struct ifreq *ifr);
static int do_scoalesce(int fd, struct ifreq *ifr);
static int do_goffload(int fd, struct ifreq *ifr);
@@ -87,6 +89,8 @@ static enum {
MODE_SCOALESCE,
MODE_GRING,
MODE_SRING,
+ MODE_GQUEUE,
+ MODE_SQUEUE,
MODE_GOFFLOAD,
MODE_SOFFLOAD,
MODE_GSTATS,
@@ -144,6 +148,10 @@ static struct option {
[ rx-mini N ]\n
[ rx-jumbo N ]\n
[ tx N ]\n },
+{ -q, --show-queue, MODE_GQUEUE, Query RX/TX queue parameters },
+{ -Q, --set-queue, MODE_SQUEUE, Set RX/TX queue parameters,
+ [ rx N ]\n
+ [ tx N ]\n },
{ -k, --show-offload, MODE_GOFFLOAD, Get protocol offload
information },
{ -K, --offload, MODE_SOFFLOAD, Set protocol offload,
[ rx on|off ]\n
@@ -216,6
Re: [Bugme-new] [Bug 8754] New: Kernel addrconf modifies MTU of non-kernel routes
On 15/07/07 10:29, Simon Arlott wrote: On 14/07/07 23:09, Andrew Morton wrote: On Sat, 14 Jul 2007 14:54:32 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8754 I have an MTU of 16110 set on eth0 on a network where the MTU is 1500 as set by RAs. One of the other hosts on the network has an MRU/MTU of 7200 so I have a specific route to it with this MTU. If I add the route early (i.e. on startup) before address autoconfiguration takes place, when the first RA is received the kernel changes the MTU on my route - this should not happen. This also happens whenever I change the MTU on eth0 - it will alter the MTU on routes *I* have added too. While this is valid behaviour for a new MTU that is too low for the route it is not for an MTU above the route. Changing the MTU also allows the next RA with MTU set changes non-kernel routes too problem to occur again. The problem seems to be that because the IPv6 code maintains its own MTU for each interface, which is set from RAs (router advertisements) and when the interface MTU is set (it's also improperly modifiable via sysctl when it shouldn't be, but that's another bug), it uses that to limit the MTU of every route. I propose that it should use the real interface MTU as the limit for non-kernel routes and the RA MTU for kernel routes. Since IPv6 routes (appear to) always have an MTU (IPv4 routes don't and hence inherit from the interface) this would have the side effect that a user-added route's automatically set MTU would not be lowered by the RA MTU. New user IPv6 routes without an explicit MTU should not have one set and use the RA MTU automatically. Is this ok? I'll send a patch to do this some time this week when I get around to it. -- Simon Arlott - 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] Get rid of dead code in net/wanrouter/wanmain.c
Hi,
File /home/devel/linux-rdc/net/wanrouter/wanmain.c line 569
Unknown CONFIG option! CONFIG_WANPIPE_MULTPPP
File /home/devel/linux-rdc/net/wanrouter/wanmain.c line 590
Unknown CONFIG option! CONFIG_WANPIPE_MULTPPP
File /home/devel/linux-rdc/net/wanrouter/wanmain.c line 663
Unknown CONFIG option! CONFIG_WANPIPE_MULTPPP
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
Signed-off-by: Michal Piotrowski [EMAIL PROTECTED]
--- linux-rdc-clean/net/wanrouter/wanmain.c 2007-07-09 01:32:17.0
+0200
+++ linux-rdc/net/wanrouter/wanmain.c 2007-07-31 18:04:58.0 +0200
@@ -566,9 +566,6 @@ static int wanrouter_device_new_if(struc
{
wanif_conf_t *cnf;
struct net_device *dev = NULL;
-#ifdef CONFIG_WANPIPE_MULTPPP
- struct ppp_device *pppdev=NULL;
-#endif
int err;
if ((wandev-state == WAN_UNCONFIGURED) || (wandev-new_if == NULL))
@@ -587,25 +584,10 @@ static int wanrouter_device_new_if(struc
goto out;
if (cnf-config_id == WANCONFIG_MPPP) {
-#ifdef CONFIG_WANPIPE_MULTPPP
- pppdev = kzalloc(sizeof(struct ppp_device), GFP_KERNEL);
- err = -ENOBUFS;
- if (pppdev == NULL)
- goto out;
- pppdev-dev = kzalloc(sizeof(struct net_device), GFP_KERNEL);
- if (pppdev-dev == NULL) {
- kfree(pppdev);
- err = -ENOBUFS;
- goto out;
- }
- err = wandev-new_if(wandev, (struct net_device *)pppdev, cnf);
- dev = pppdev-dev;
-#else
printk(KERN_INFO %s: Wanpipe Mulit-Port PPP support has not
been compiled in!\n,
wandev-name);
err = -EPROTONOSUPPORT;
goto out;
-#endif
} else {
dev = kzalloc(sizeof(struct net_device), GFP_KERNEL);
err = -ENOBUFS;
@@ -660,16 +642,9 @@ static int wanrouter_device_new_if(struc
kfree(dev-priv);
dev-priv = NULL;
-#ifdef CONFIG_WANPIPE_MULTPPP
- if (cnf-config_id == WANCONFIG_MPPP)
- kfree(pppdev);
- else
- kfree(dev);
-#else
/* Sync PPP is disabled */
if (cnf-config_id != WANCONFIG_MPPP)
kfree(dev);
-#endif
out:
kfree(cnf);
-
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] Get rid of dead code in net/ipv4/fib_semantics.c
Hi,
File /home/devel/linux-rdc/net/ipv4/fib_semantics.c line 525
Unknown CONFIG option! CONFIG_IP_ROUTE_PERVASIVE
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
Signed-off-by: Michal Piotrowski [EMAIL PROTECTED]
--- linux-rdc-clean/net/ipv4/fib_semantics.c2007-07-31 17:17:31.0
+0200
+++ linux-rdc/net/ipv4/fib_semantics.c 2007-07-31 18:22:54.0 +0200
@@ -522,10 +522,6 @@ static int fib_check_nh(struct fib_confi
if (nh-nh_gw) {
struct fib_result res;
-#ifdef CONFIG_IP_ROUTE_PERVASIVE
- if (nh-nh_flagsRTNH_F_PERVASIVE)
- return 0;
-#endif
if (nh-nh_flagsRTNH_F_ONLINK) {
struct net_device *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: [RESEND][PATCH 1/3] PPPoE: improved hashing routine
From: Florian Zumbiehl [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 13:05:47 +0200 A few variations I tried back when I created the patch, using larger things than a char for accumulating the pieces and then folding down from that, turned out to be slower than what I finally submitted, at least on the machines I tested it on. I didn't do comprehensive testing, as it really doesn't matter, after all, but I think the version I submitted is pretty fast, plus it's quite readable, and it keeps the flexibility of different hash sizes, but still should allow the compiler to optimize away the loops that allow for this flexibility. Therefore, I've put your original patch into the tree :-) 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 20] net/decnet/dn_route.c: kmalloc + memset conversion to kzalloc
From: Mariusz Kozlowski [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 19:33:33 +0200 Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED] Patch applied, 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 39] net/ipv4/ip_options.c: kmalloc + memset conversion to kzalloc
From: Mariusz Kozlowski [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 20:16:59 +0200 Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED] Applied, but note that this patch changes behavior, previously only the ip_options structure base was cleared out, but now the whole memory region is cleared. I think it's OK for this case, but I'm just making note of it. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] ISIC + 2.6.22 (via-rhine)
hi,
Running ISIC -- IP Stack Integrity Checker ( http://isic.sf.net ),
in Fedora-7-i386 with 2.6.22, the NIC stopped to send packages.
But one second latter it began to send out more of them.
dmesg shows the bug.
command is:
# tcpsic -s rand -d 172.26.0.2 -I100
driver is:
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
eth0: VIA Rhine II at 0xbc00, 00:11:d8:54:e9:3c, IRQ 19.
eth0: MII PHY found at address 1, status 0x786d advertising 01e1 Link 45e1.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
eth0: no IPv6 routers present
---lspci--
00:12.0 0200: 1106:3065 (rev 78)
Subsystem: 1043:80ed
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping+ SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 32 (750ns min, 2000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at 7000 [size=256]
Region 1: Memory at bc00 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] 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-
--end--
--dmesg output--
[...]
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timed out, status , PHY status 786d, resetting...
=
[ INFO: inconsistent lock state ]
2.6.22 #1
-
inconsistent {in-hardirq-W} - {hardirq-on-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(rp-lock){++..}, at: [f8c890db] rhine_tx_timeout+0x6f/0xf4 [via_rhine]
{in-hardirq-W} state was registered at:
[c04440d4] __lock_acquire+0x38c/0xb12
[c0444c1b] lock_acquire+0x56/0x6f
[c0615279] _spin_lock+0x2b/0x38
[f8c87b49] rhine_interrupt+0x16b/0x69b [via_rhine]
[c045aac6] handle_IRQ_event+0x1a/0x46
[c045bbc0] handle_fasteoi_irq+0x7d/0xb6
[c0407089] do_IRQ+0xb1/0xd8
[] 0x
irq event stamp: 18052892
hardirqs last enabled at (18052892): [c061567d]
_spin_unlock_irqrestore+0x36/0x3c
hardirqs last disabled at (18052891): [c061558d] _spin_lock_irqsave+0x12/0x44
softirqs last enabled at (18052876): [c042d272] __do_softirq+0xe3/0xe9
softirqs last disabled at (18052887): [c0406f72] do_softirq+0x61/0xc7
other info that might help us debug this:
1 lock held by swapper/0:
#0: (_xmit_ETHER){-+..}, at: [c05c042a] dev_watchdog+0x14/0xbf
stack backtrace:
[c0405e6a] show_trace_log_lvl+0x1a/0x2f
[c04068cf] show_trace+0x12/0x14
[c0406928] dump_stack+0x16/0x18
[c0442ccd] print_usage_bug+0x141/0x14b
[c04434fd] mark_lock+0x1fd/0x409
[c0444144] __lock_acquire+0x3fc/0xb12
[c0444c1b] lock_acquire+0x56/0x6f
[c0615279] _spin_lock+0x2b/0x38
[f8c890db] rhine_tx_timeout+0x6f/0xf4 [via_rhine]
[c05c048c] dev_watchdog+0x76/0xbf
[c04303be] run_timer_softirq+0x11a/0x182
[c042d1fe] __do_softirq+0x6f/0xe9
[c0406f72] do_softirq+0x61/0xc7
===
via-rhine: Reset not complete yet. Trying harder.
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
--end---
-thanks-
--
Politicos de mierda, yo no soy un terrorista.
-
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
[NEIGH]: Combine neighbour cleanup and release
Introduces neigh_cleanup_and_release() to be used after a
neighbour has been removed from its neighbour table. Serves
as preparation to add event notifications.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6/net/core/neighbour.c
===
--- net-2.6.orig/net/core/neighbour.c 2007-07-22 11:41:46.0 +0200
+++ net-2.6/net/core/neighbour.c2007-07-22 11:42:02.0 +0200
@@ -104,6 +104,14 @@ static int neigh_blackhole(struct sk_buf
return -ENETDOWN;
}
+static void neigh_cleanup_and_release(struct neighbour *neigh)
+{
+ if (neigh-parms-neigh_cleanup)
+ neigh-parms-neigh_cleanup(neigh);
+
+ neigh_release(neigh);
+}
+
/*
* It is random distribution in the interval (1/2)*base...(3/2)*base.
* It corresponds to default IPv6 settings and is not overridable,
@@ -140,9 +148,7 @@ static int neigh_forced_gc(struct neigh_
n-dead = 1;
shrunk = 1;
write_unlock(n-lock);
- if (n-parms-neigh_cleanup)
- n-parms-neigh_cleanup(n);
- neigh_release(n);
+ neigh_cleanup_and_release(n);
continue;
}
write_unlock(n-lock);
@@ -213,9 +219,7 @@ static void neigh_flush_dev(struct neigh
NEIGH_PRINTK2(neigh %p is stray.\n, n);
}
write_unlock(n-lock);
- if (n-parms-neigh_cleanup)
- n-parms-neigh_cleanup(n);
- neigh_release(n);
+ neigh_cleanup_and_release(n);
}
}
}
@@ -676,9 +680,7 @@ static void neigh_periodic_timer(unsigne
*np = n-next;
n-dead = 1;
write_unlock(n-lock);
- if (n-parms-neigh_cleanup)
- n-parms-neigh_cleanup(n);
- neigh_release(n);
+ neigh_cleanup_and_release(n);
continue;
}
write_unlock(n-lock);
@@ -2094,11 +2096,8 @@ void __neigh_for_each_release(struct nei
} else
np = n-next;
write_unlock(n-lock);
- if (release) {
- if (n-parms-neigh_cleanup)
- n-parms-neigh_cleanup(n);
- neigh_release(n);
- }
+ if (release)
+ neigh_cleanup_and_release(n);
}
}
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[NEIGH]: Netlink notifications
Currently neighbour event notifications are limited to update
notifications and only sent if the ARP daemon is enabled. This
patch extends the existing notification code by also reporting
neighbours being removed due to gc or administratively and
removes the dependency on the ARP daemon. This allows to keep
track of neighbour states without periodically fetching the
complete neighbour table.
Signed-off-by: Thomas Graf [EMAIL PROTECTED]
Index: net-2.6/net/core/neighbour.c
===
--- net-2.6.orig/net/core/neighbour.c 2007-07-22 11:42:02.0 +0200
+++ net-2.6/net/core/neighbour.c2007-07-22 11:49:15.0 +0200
@@ -54,9 +54,8 @@
#define PNEIGH_HASHMASK0xF
static void neigh_timer_handler(unsigned long arg);
-#ifdef CONFIG_ARPD
-static void neigh_app_notify(struct neighbour *n);
-#endif
+static void __neigh_notify(struct neighbour *n, int type, int flags);
+static void neigh_update_notify(struct neighbour *neigh);
static int pneigh_ifdown(struct neigh_table *tbl, struct net_device *dev);
void neigh_changeaddr(struct neigh_table *tbl, struct net_device *dev);
@@ -109,6 +108,7 @@ static void neigh_cleanup_and_release(st
if (neigh-parms-neigh_cleanup)
neigh-parms-neigh_cleanup(neigh);
+ __neigh_notify(neigh, RTM_DELNEIGH, 0);
neigh_release(neigh);
}
@@ -829,13 +829,10 @@ static void neigh_timer_handler(unsigned
out:
write_unlock(neigh-lock);
}
+
if (notify)
- call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
+ neigh_update_notify(neigh);
-#ifdef CONFIG_ARPD
- if (notify neigh-parms-app_probes)
- neigh_app_notify(neigh);
-#endif
neigh_release(neigh);
}
@@ -1064,11 +1061,8 @@ out:
write_unlock_bh(neigh-lock);
if (notify)
- call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
-#ifdef CONFIG_ARPD
- if (notify neigh-parms-app_probes)
- neigh_app_notify(neigh);
-#endif
+ neigh_update_notify(neigh);
+
return err;
}
@@ -2001,6 +1995,11 @@ nla_put_failure:
return -EMSGSIZE;
}
+static void neigh_update_notify(struct neighbour *neigh)
+{
+ call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh);
+ __neigh_notify(neigh, RTM_NEWNEIGH, 0);
+}
static int neigh_dump_table(struct neigh_table *tbl, struct sk_buff *skb,
struct netlink_callback *cb)
@@ -2420,7 +2419,6 @@ static const struct file_operations neig
#endif /* CONFIG_PROC_FS */
-#ifdef CONFIG_ARPD
static inline size_t neigh_nlmsg_size(void)
{
return NLMSG_ALIGN(sizeof(struct ndmsg))
@@ -2452,16 +2450,11 @@ errout:
rtnl_set_sk_err(RTNLGRP_NEIGH, err);
}
+#ifdef CONFIG_ARPD
void neigh_app_ns(struct neighbour *n)
{
__neigh_notify(n, RTM_GETNEIGH, NLM_F_REQUEST);
}
-
-static void neigh_app_notify(struct neighbour *n)
-{
- __neigh_notify(n, RTM_NEWNEIGH, 0);
-}
-
#endif /* CONFIG_ARPD */
#ifdef CONFIG_SYSCTL
-
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
[RTNETLINK]: Fix warning for !CONFIG_KMOD
replay label is unused otherwise. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Index: net-2.6/net/core/rtnetlink.c === --- net-2.6.orig/net/core/rtnetlink.c 2007-07-22 11:41:46.0 +0200 +++ net-2.6/net/core/rtnetlink.c2007-07-22 12:04:27.0 +0200 @@ -952,7 +952,9 @@ static int rtnl_newlink(struct sk_buff * struct nlattr *linkinfo[IFLA_INFO_MAX+1]; int err; +#ifdef CONFIG_KMOD replay: +#endif err = nlmsg_parse(nlh, sizeof(*ifm), tb, IFLA_MAX, ifla_policy); if (err 0) return err; - 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: [RTNETLINK]: Fix warning for !CONFIG_KMOD
From: Thomas Graf [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 23:12:58 +0200 replay label is unused otherwise. Signed-off-by: Thomas Graf [EMAIL PROTECTED] Applied, thanks Thomas. - 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 39] net/ipv4/ip_options.c: kmalloc + memset conversion to kzalloc
Applied, but note that this patch changes behavior, previously only the ip_options structure base was cleared out, but now the whole memory region is cleared. I think it's OK for this case, but I'm just making note of it. Agrh. Sorry. I must have overlook this. Feel free to drop it if you think its not worth it :-) Thanks, Mariusz - 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: [BUG] ISIC + 2.6.22 (via-rhine)
=
[ INFO: inconsistent lock state ]
2.6.22 #1
-
inconsistent {in-hardirq-W} - {hardirq-on-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(rp-lock){++..}, at: [f8c890db] rhine_tx_timeout+0x6f/0xf4 [via_rhine]
this is a case of homegrown locking: the via-rhine driver does
/* protect against concurrent rx interrupts */
disable_irq(rp-pdev-irq);
spin_lock(rp-lock);
/* clear all descriptors */
free_tbufs(dev);
free_rbufs(dev);
alloc_tbufs(dev);
alloc_rbufs(dev);
/* Reinitialize the hardware. */
rhine_chip_reset(dev);
init_registers(dev);
spin_unlock(rp-lock);
enable_irq(rp-pdev-irq);
as a way to protect code against interrupts... rather than using the
normal mechanism.
the annotation is pretty simple (untested, not even compiled):
--- linux-2.6.22/drivers/net/via-rhine.c.org2007-07-31 14:22:06.0
-0700
+++ linux-2.6.22/drivers/net/via-rhine.c2007-07-31 14:22:26.0
-0700
@@ -1191,7 +1191,7 @@
mdio_read(dev, rp-mii_if.phy_id, MII_BMSR));
/* protect against concurrent rx interrupts */
- disable_irq(rp-pdev-irq);
+ disable_irq_lockdep(rp-pdev-irq);
spin_lock(rp-lock);
@@ -1206,7 +1206,7 @@
init_registers(dev);
spin_unlock(rp-lock);
- enable_irq(rp-pdev-irq);
+ enable_irq_lockdep(rp-pdev-irq);
dev-trans_start = jiffies;
rp-stats.tx_errors++;
-
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: [BUG] ISIC + 2.6.22 (via-rhine)
Arjan van de Ven wrote:
=
[ INFO: inconsistent lock state ]
2.6.22 #1
-
inconsistent {in-hardirq-W} - {hardirq-on-W} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(rp-lock){++..}, at: [f8c890db] rhine_tx_timeout+0x6f/0xf4 [via_rhine]
this is a case of homegrown locking: the via-rhine driver does
/* protect against concurrent rx interrupts */
disable_irq(rp-pdev-irq);
spin_lock(rp-lock);
/* clear all descriptors */
free_tbufs(dev);
free_rbufs(dev);
alloc_tbufs(dev);
alloc_rbufs(dev);
/* Reinitialize the hardware. */
rhine_chip_reset(dev);
init_registers(dev);
spin_unlock(rp-lock);
enable_irq(rp-pdev-irq);
as a way to protect code against interrupts... rather than using the
normal mechanism.
the annotation is pretty simple (untested, not even compiled):
--- linux-2.6.22/drivers/net/via-rhine.c.org2007-07-31 14:22:06.0
-0700
+++ linux-2.6.22/drivers/net/via-rhine.c2007-07-31 14:22:26.0
-0700
@@ -1191,7 +1191,7 @@
mdio_read(dev, rp-mii_if.phy_id, MII_BMSR));
/* protect against concurrent rx interrupts */
- disable_irq(rp-pdev-irq);
+ disable_irq_lockdep(rp-pdev-irq);
spin_lock(rp-lock);
@@ -1206,7 +1206,7 @@
init_registers(dev);
spin_unlock(rp-lock);
- enable_irq(rp-pdev-irq);
+ enable_irq_lockdep(rp-pdev-irq);
dev-trans_start = jiffies;
rp-stats.tx_errors++;
thanks Arjan. Patch applied and now I get:
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Transmit timed out, status , PHY status 786d, resetting...
==
[ INFO: hard-safe - hard-unsafe lock order detected ]
2.6.22 #1
--
swapper/0 [HC0[0]:SC1[1]:HE0:SE0] is trying to acquire:
(af_callback_keys + sk-sk_family#3){-.-?}, at: [c05ab7d3]
sock_def_write_space+0x18/0x96
and this task is already holding:
(rp-lock){++..}, at: [f8d0a0e1] rhine_tx_timeout+0x75/0x102 [via_rhine]
which would create a new lock dependency:
(rp-lock){++..} - (af_callback_keys + sk-sk_family#3){-.-?}
but this new dependency connects a hard-irq-safe lock:
(rp-lock){++..}
... which became hard-irq-safe at:
[c04440d4] __lock_acquire+0x38c/0xb12
[c0444c1b] lock_acquire+0x56/0x6f
[c0615279] _spin_lock+0x2b/0x38
[f8d08b49] rhine_interrupt+0x16b/0x69b [via_rhine]
[c045aac6] handle_IRQ_event+0x1a/0x46
[c045bbc0] handle_fasteoi_irq+0x7d/0xb6
[c0407089] do_IRQ+0xb1/0xd8
[] 0x
to a hard-irq-unsafe lock:
(af_callback_keys + sk-sk_family#3){-.-?}
... which became hard-irq-unsafe at:
... [c0444144] __lock_acquire+0x3fc/0xb12
[c0444c1b] lock_acquire+0x56/0x6f
[c061532b] _write_lock_bh+0x30/0x3d
[c05d829e] tcp_close+0x24e/0x531
[c05f1175] inet_release+0x43/0x49
[c05a85d4] sock_release+0x17/0x62
[c05a89fb] sock_close+0x2d/0x33
[c047db0f] __fput+0xbe/0x168
[c047dbd0] fput+0x17/0x19
[c047b4b5] filp_close+0x54/0x5c
[c047c444] sys_close+0x78/0xb0
[c0404e26] sysenter_past_esp+0x5f/0x99
[] 0x
other info that might help us debug this:
2 locks held by swapper/0:
#0: (_xmit_ETHER){-+..}, at: [c05c042a] dev_watchdog+0x14/0xbf
#1: (rp-lock){++..}, at: [f8d0a0e1] rhine_tx_timeout+0x75/0x102
[via_rhine]
the hard-irq-safe lock's dependencies:
- (rp-lock){++..} ops: 0 {
initial-use at:
[c044417d] __lock_acquire+0x435/0xb12
[c0444c1b] lock_acquire+0x56/0x6f
[c06155af] _spin_lock_irqsave+0x34/0x44
[f8d0a19b] rhine_get_stats+0x2d/0x9d [via_rhine]
[c05b9017] rtnl_fill_ifinfo+0x2e9/0x414
[c05b9547] rtmsg_ifinfo+0x57/0xd4
[c05b95fc] rtnetlink_event+0x38/0x3c
[c0616f9e] notifier_call_chain+0x2b/0x4a
[c0433984] __raw_notifier_call_chain+0x19/0x1e
[c04339a3] raw_notifier_call_chain+0x1a/0x1c
[c05b14a3] register_netdevice+0x335/0x33f
[c05b27d6] register_netdev+0x40/0x4d
[f8d09d07] rhine_init_one+0x515/0x6c7 [via_rhine]
[c04f8085] pci_device_probe+0x39/0x5b
[c055cffc] driver_probe_device+0xe9/0x16a
[c055d1a6] __driver_attach+0x76/0xaf
[c055c4ec] bus_for_each_dev+0x3a/0x5f
[c055ce47] driver_attach+0x19/0x1b
[c055c80a] bus_add_driver+0x79/0x181
[c055d3a1] driver_register+0x67/0x6c
[c04f81dd] __pci_register_driver+0x56/0x83
[f885f06c] 0xf885f06c
[c044b77f] sys_init_module+0x1579/0x16ca
[PATCH 66] net/ipv4/raw.c: kmalloc + memset conversion to kzalloc
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
net/ipv4/raw.c | 21650 - 21628 (-22 bytes)
net/ipv4/raw.o | 179112 - 179272 (+160 bytes)
net/ipv4/raw.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.23-rc1-mm1-a/net/ipv4/raw.c 2007-07-26 13:07:44.0
+0200
+++ linux-2.6.23-rc1-mm1-b/net/ipv4/raw.c 2007-07-31 15:20:27.0
+0200
@@ -900,8 +900,9 @@ static int raw_seq_open(struct inode *in
{
struct seq_file *seq;
int rc = -ENOMEM;
- struct raw_iter_state *s = kmalloc(sizeof(*s), GFP_KERNEL);
-
+ struct raw_iter_state *s;
+
+ s = kzalloc(sizeof(*s), GFP_KERNEL);
if (!s)
goto out;
rc = seq_open(file, raw_seq_ops);
@@ -910,7 +911,6 @@ static int raw_seq_open(struct inode *in
seq = file-private_data;
seq-private = s;
- memset(s, 0, sizeof(*s));
out:
return rc;
out_kfree:
-
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 67] net/ipv4/route.c: mostly kmalloc + memset conversion to k[cz]alloc
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
net/ipv4/route.c | 75650 - 75628 (-22 bytes)
net/ipv4/route.o | 256303 - 256467 (+164 bytes)
net/ipv4/route.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.23-rc1-mm1-a/net/ipv4/route.c 2007-07-26 13:07:44.0
+0200
+++ linux-2.6.23-rc1-mm1-b/net/ipv4/route.c 2007-07-31 15:21:41.0
+0200
@@ -374,8 +374,9 @@ static int rt_cache_seq_open(struct inod
{
struct seq_file *seq;
int rc = -ENOMEM;
- struct rt_cache_iter_state *s = kmalloc(sizeof(*s), GFP_KERNEL);
-
+ struct rt_cache_iter_state *s;
+
+ s = kzalloc(sizeof(*s), GFP_KERNEL);
if (!s)
goto out;
rc = seq_open(file, rt_cache_seq_ops);
@@ -383,7 +384,6 @@ static int rt_cache_seq_open(struct inod
goto out_kfree;
seq = file-private_data;
seq-private = s;
- memset(s, 0, sizeof(*s));
out:
return rc;
out_kfree:
-
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 68] drivers/net/s2io.c: kmalloc + memset conversion to k[cz]alloc
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
drivers/net/s2io.c | 235587 - 235340 (-247 bytes)
drivers/net/s2io.o | 460768 - 460120 (-648 bytes)
drivers/net/s2io.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
--- linux-2.6.23-rc1-mm1-a/drivers/net/s2io.c 2007-07-26 13:07:42.0
+0200
+++ linux-2.6.23-rc1-mm1-b/drivers/net/s2io.c 2007-07-31 13:44:02.0
+0200
@@ -531,7 +531,7 @@ static int init_shared_mem(struct s2io_n
for (i = 0; i config-tx_fifo_num; i++) {
int fifo_len = config-tx_cfg[i].fifo_len;
int list_holder_size = fifo_len * sizeof(struct list_info_hold);
- mac_control-fifos[i].list_info = kmalloc(list_holder_size,
+ mac_control-fifos[i].list_info = kzalloc(list_holder_size,
GFP_KERNEL);
if (!mac_control-fifos[i].list_info) {
DBG_PRINT(INFO_DBG,
@@ -539,7 +539,6 @@ static int init_shared_mem(struct s2io_n
return -ENOMEM;
}
mem_allocated += list_holder_size;
- memset(mac_control-fifos[i].list_info, 0, list_holder_size);
}
for (i = 0; i config-tx_fifo_num; i++) {
int page_num = TXD_MEM_PAGE_CNT(config-tx_cfg[i].fifo_len,
@@ -3788,9 +3787,9 @@ static int s2io_enable_msi_x(struct s2io
u16 msi_control; /* Temp variable */
int ret, i, j, msix_indx = 1;
- nic-entries = kmalloc(MAX_REQUESTED_MSI_X * sizeof(struct msix_entry),
+ nic-entries = kcalloc(MAX_REQUESTED_MSI_X, sizeof(struct msix_entry),
GFP_KERNEL);
- if (nic-entries == NULL) {
+ if (!nic-entries) {
DBG_PRINT(INFO_DBG, %s: Memory allocation failed\n, \
__FUNCTION__);
nic-mac_control.stats_info-sw_stat.mem_alloc_fail_cnt++;
@@ -3798,12 +3797,11 @@ static int s2io_enable_msi_x(struct s2io
}
nic-mac_control.stats_info-sw_stat.mem_allocated
+= (MAX_REQUESTED_MSI_X * sizeof(struct msix_entry));
- memset(nic-entries, 0,MAX_REQUESTED_MSI_X * sizeof(struct msix_entry));
nic-s2io_entries =
- kmalloc(MAX_REQUESTED_MSI_X * sizeof(struct s2io_msix_entry),
+ kcalloc(MAX_REQUESTED_MSI_X, sizeof(struct s2io_msix_entry),
GFP_KERNEL);
- if (nic-s2io_entries == NULL) {
+ if (!nic-s2io_entries) {
DBG_PRINT(INFO_DBG, %s: Memory allocation failed\n,
__FUNCTION__);
nic-mac_control.stats_info-sw_stat.mem_alloc_fail_cnt++;
@@ -3814,8 +3812,6 @@ static int s2io_enable_msi_x(struct s2io
}
nic-mac_control.stats_info-sw_stat.mem_allocated
+= (MAX_REQUESTED_MSI_X * sizeof(struct s2io_msix_entry));
- memset(nic-s2io_entries, 0,
- MAX_REQUESTED_MSI_X * sizeof(struct s2io_msix_entry));
for (i=0; i MAX_REQUESTED_MSI_X; i++) {
nic-entries[i].entry = i;
-
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 69] drivers/net/sb1250-mac.c: kmalloc + memset conversion to kcalloc
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED] drivers/net/sb1250-mac.c | 76286 - 76199 (-87 bytes) drivers/net/sb1250-mac.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) --- linux-2.6.23-rc1-mm1-a/drivers/net/sb1250-mac.c 2007-07-26 13:07:43.0 +0200 +++ linux-2.6.23-rc1-mm1-b/drivers/net/sb1250-mac.c 2007-07-31 13:46:10.0 +0200 @@ -779,10 +779,8 @@ static void sbdma_initctx(sbmacdma_t *d, * And context table */ - d-sbdma_ctxtable = (struct sk_buff **) - kmalloc(d-sbdma_maxdescr*sizeof(struct sk_buff *), GFP_KERNEL); - - memset(d-sbdma_ctxtable,0,d-sbdma_maxdescr*sizeof(struct sk_buff *)); + d-sbdma_ctxtable = kcalloc(d-sbdma_maxdescr, + sizeof(struct sk_buff *), GFP_KERNEL); #ifdef CONFIG_SBMAC_COALESCE /* - 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 76] drivers/net/via-velocity.c: mostly kmalloc + memset conversion to kcalloc
Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED]
drivers/net/via-velocity.c | 88263 - 88120 (-143 bytes)
drivers/net/via-velocity.o | 254264 - 253828 (-436 bytes)
drivers/net/via-velocity.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
--- linux-2.6.23-rc1-mm1-a/drivers/net/via-velocity.c 2007-07-26
13:07:43.0 +0200
+++ linux-2.6.23-rc1-mm1-b/drivers/net/via-velocity.c 2007-07-31
13:50:28.0 +0200
@@ -1071,14 +1071,12 @@ static int velocity_rx_refill(struct vel
static int velocity_init_rd_ring(struct velocity_info *vptr)
{
- int ret = -ENOMEM;
- unsigned int rsize = sizeof(struct velocity_rd_info) *
- vptr-options.numrx;
+ int ret;
- vptr-rd_info = kmalloc(rsize, GFP_KERNEL);
- if(vptr-rd_info == NULL)
- goto out;
- memset(vptr-rd_info, 0, rsize);
+ vptr-rd_info = kcalloc(vptr-options.numrx,
+ sizeof(struct velocity_rd_info), GFP_KERNEL);
+ if (!vptr-rd_info)
+ return -ENOMEM;
vptr-rd_filled = vptr-rd_dirty = vptr-rd_curr = 0;
@@ -1088,7 +1086,7 @@ static int velocity_init_rd_ring(struct
%s: failed to allocate RX buffer.\n, vptr-dev-name);
velocity_free_rd_ring(vptr);
}
-out:
+
return ret;
}
@@ -1142,21 +1140,19 @@ static int velocity_init_td_ring(struct
dma_addr_t curr;
struct tx_desc *td;
struct velocity_td_info *td_info;
- unsigned int tsize = sizeof(struct velocity_td_info) *
- vptr-options.numtx;
/* Init the TD ring entries */
for (j = 0; j vptr-num_txq; j++) {
curr = vptr-td_pool_dma[j];
- vptr-td_infos[j] = kmalloc(tsize, GFP_KERNEL);
- if(vptr-td_infos[j] == NULL)
- {
+ vptr-td_infos[j] = kcalloc(vptr-options.numtx,
+ sizeof(struct velocity_td_info),
+ GFP_KERNEL);
+ if (!vptr-td_infos[j]) {
while(--j = 0)
kfree(vptr-td_infos[j]);
return -ENOMEM;
}
- memset(vptr-td_infos[j], 0, tsize);
for (i = 0; i vptr-options.numtx; i++, curr += sizeof(struct
tx_desc)) {
td = (vptr-td_rings[j][i]);
-
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: ATA over ethernet swapping
Hi!
...
Is the protocol documented somewhere? aoe.txt only points at
HOWTO... aha, protocol is linked from wikipedia.
http://www.coraid.com/documents/AoEr10.txt ... perhaps that should be
linked from aoe.txt, too?
Perhaps. Most people reading the aoe.txt file won't need to refer to
the protocol itself, though.
Some of your users are developers, too :-). Should I generate a patch?
Hmm, aoe protocol is really trivial. Perhaps netpoll/netconsole
infrastructure could be used to create driver good enough for
swapping? (Ok, it would not neccessarily perform too well, but... we'd
simply wait for the reply synchronously. It should be pretty simple).
I think that in general you still need a way to receive write
confirmations without allocating memory, and the driver can't provide
that mechanism. The problem is that when memory is scarce, writes of
dirty data must be able to complete, but because memory is scarce,
there might not be enough to receive and process packets write-reponse
packets, and the driver has no way of affecting the situation. That's
why I think a callback could work: The network layer could allow
storage drivers to register a callback that recognizes write
responses.
Hmm, ok, it is not as simple as I thought. include/linux/netpoll.h
already includes mechanism to notify interested parties really soon,
but drivers still call dev_alloc_skb() before that.
Usually the callback would not be used, but if free pages became so
scarce that network receives could not take place in a normal fashion,
the (zero or few) registered callbacks would be used to quickly
determine whether each packet was a write response. The distinction
is important, because write responses can result in the freeing of
pages.
Hmm, adding GFP_GIVE_ME_EMERGENCY_POOLS to dev_alloc_skb(), then doing
...
int netif_rx(struct sk_buff *skb)
{
struct softnet_data *queue;
unsigned long flags;
/* if netpoll wants it, pretend we never saw it */
if (netpoll_rx(skb))
return NET_RX_DROP;
if (memory_is_still_very_low())
return NET_RX_DROP;
...should do the trick. Would something like that be acceptable to
network people?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 76] drivers/net/via-velocity.c: mostly kmalloc + memset conversion to kcalloc
Mariusz Kozlowski [EMAIL PROTECTED] : Signed-off-by: Mariusz Kozlowski [EMAIL PROTECTED] drivers/net/via-velocity.c | 88263 - 88120 (-143 bytes) drivers/net/via-velocity.o | 254264 - 253828 (-436 bytes) drivers/net/via-velocity.c | 24 ++-- 1 file changed, 10 insertions(+), 14 deletions(-) Acked-by: Francois Romieu [EMAIL PROTECTED] -- Ueimor - 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: [2.6 patch] drivers/net/cxgb3/xgmac.c: remove dead code
Adrian Bunk wrote:
This patch removes dead code (tx_xcnt can never be != 0 at this place)
spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/xgmac.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- linux-2.6.22-rc6-mm1/drivers/net/cxgb3/xgmac.c.old 2007-07-24
13:55:33.0 +0200
+++ linux-2.6.22-rc6-mm1/drivers/net/cxgb3/xgmac.c 2007-07-24
13:57:06.0 +0200
@@ -510,38 +510,35 @@ int t3b2_mac_watchdog_task(struct cmac *
if (tx_mcnt == mac-tx_mcnt) {
tx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
A_XGM_TX_SPI4_SOP_EOP_CNT +
mac-offset)));
if (tx_xcnt == 0) {
t3_write_reg(adap, A_TP_PIO_ADDR,
A_TP_TX_DROP_CNT_CH0 + macidx(mac));
tx_tcnt = (G_TXDROPCNTCH0RCVD(t3_read_reg(adap,
A_TP_PIO_DATA)));
} else {
goto rxcheck;
}
} else {
mac-toggle_cnt = 0;
goto rxcheck;
}
- if (((tx_tcnt != mac-tx_tcnt)
-(tx_xcnt == 0) (mac-tx_xcnt == 0)) ||
- ((mac-tx_mcnt == tx_mcnt)
-(tx_xcnt != 0) (mac-tx_xcnt != 0))) {
+ if ((tx_tcnt != mac-tx_tcnt) (mac-tx_xcnt == 0)) {
if (mac-toggle_cnt 4) {
status = 2;
goto out;
} else {
status = 1;
goto out;
}
} else {
mac-toggle_cnt = 0;
goto rxcheck;
}
rxcheck:
if (rx_mcnt != mac-rx_mcnt)
rx_xcnt = (G_TXSPI4SOPCNT(t3_read_reg(adap,
A_XGM_RX_SPI4_SOP_EOP_CNT +
mac-offset)));
-
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: [OOPS] 2.6.23-rc1 Seems to be network related
On Wed, 1 Aug 2007 01:35:23 +0200 Bongani Hlope [EMAIL PROTECTED] wrote: I got this partial Oops on my work laptop (DELL D800), while using the linux 2.6.23-rc1 kernel. I've been using this kernel ever since it was released and this is the first and only time it did not boot. It was around the time it should have been trying to connect to my linksys wireless router (which has been working fine everyday since the 2.6.23-rc1 kernel was released). I copied what was on screen by hand, so some info is missing. I don't know how to reproduce it. Call Trace: [c0104cbc] show_trace_log_lvl+0x1a/0x2f [c0104d6c] show_stack_log_lvl+0x9b/0xa3 [c0104f36] show_registers+0x1c2/0x2db [c0105151] die+0x02/0x1de [c01052b6] do_trap+0x89/0xa2 [c010558e] do_invalid_op+0x88/0x92 [c035a162] error_code+0x6a/0x70 [c0114efa] kmap_atomic+0xe/0x10 [c014a29c] get_page_from_freelist+0x24c/0x3... [c015dd06] __alloc_pages+0x53/0x27d [c015da60] kmem_cache_alloc+0x32/0x68 [c02e5065] dst_alloc+0x28/0x60 [c02f45fe] ip_route_input+0x9b9/0xbba [c0314835] arp_process+0x155/0x4e1 [c0314caa] arp_rcv+0xe9/0xfd [c02e1660] netif_receive_skb+0x16e/0x1eb [c02e2efa] process_backlog+0x71/0xda [c02e2fb9] net_rx_action+0x56/0xee [c011f437] __do_softirq+0x38/0x7a [c0106145] do_soft_irq+0x41/0x91 [c011f3c5] irq_exit+0x2c/0x66 [c010644a] do_IRQ+0xb7/0xcd [c01047eb] common_interrupt+0x23/0x28 [c0151f87] handle_mm_fault+0x1fe/0x57e [c035a162] error_code+0x6a/0x70 === EIP: [c0114e87] kmap_atomic_prot+0x27/0x8.. Thanks. Commit b8c1c5da1520977cb55a358f20fc09567d40cad9 should have fixed this. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[OOPS] 2.6.23-rc1 Seems to be network related
Hi I got this partial Oops on my work laptop (DELL D800), while using the linux 2.6.23-rc1 kernel. I've been using this kernel ever since it was released and this is the first and only time it did not boot. It was around the time it should have been trying to connect to my linksys wireless router (which has been working fine everyday since the 2.6.23-rc1 kernel was released). I copied what was on screen by hand, so some info is missing. I don't know how to reproduce it. Call Trace: [c0104cbc] show_trace_log_lvl+0x1a/0x2f [c0104d6c] show_stack_log_lvl+0x9b/0xa3 [c0104f36] show_registers+0x1c2/0x2db [c0105151] die+0x02/0x1de [c01052b6] do_trap+0x89/0xa2 [c010558e] do_invalid_op+0x88/0x92 [c035a162] error_code+0x6a/0x70 [c0114efa] kmap_atomic+0xe/0x10 [c014a29c] get_page_from_freelist+0x24c/0x3... [c015dd06] __alloc_pages+0x53/0x27d [c015da60] kmem_cache_alloc+0x32/0x68 [c02e5065] dst_alloc+0x28/0x60 [c02f45fe] ip_route_input+0x9b9/0xbba [c0314835] arp_process+0x155/0x4e1 [c0314caa] arp_rcv+0xe9/0xfd [c02e1660] netif_receive_skb+0x16e/0x1eb [c02e2efa] process_backlog+0x71/0xda [c02e2fb9] net_rx_action+0x56/0xee [c011f437] __do_softirq+0x38/0x7a [c0106145] do_soft_irq+0x41/0x91 [c011f3c5] irq_exit+0x2c/0x66 [c010644a] do_IRQ+0xb7/0xcd [c01047eb] common_interrupt+0x23/0x28 [c0151f87] handle_mm_fault+0x1fe/0x57e [c035a162] error_code+0x6a/0x70 === EIP: [c0114e87] kmap_atomic_prot+0x27/0x8.. Linux bongani_nb 2.6.23-rc1 #4 PREEMPT Mon Jul 23 12:11:40 SAST 2007 i686 Intel(R) Pentium(R) M processor 1600MHz GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17.50.0.9 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.39 pcmciautils014 PPP2.4.4 Linux C Library libc.2.4 Dynamic linker (ldd) 2.4 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 106 wireless-tools 28 Modules Loaded tg3 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd soundcore video output thermal sbs processor fan container button battery ac pcmcia yenta_socket rsrc_nonstatic pcmcia_core intel_agp hidp nvram rfcomm l2cap ipw2100 ieee80211 ieee80211_crypt usbhid hci_usb bluetooth ohci1394 ieee1394 ehci_hcd uhci_hcd joydev evdev I'm sorry I can't provide more info, this is completely random and it's the first time it ever happened. config.gz Description: GNU Zip compressed data
Re: [PATCH] pktgen - define and use pktgen_dbg,err,warn,info
On Mon, 2007-07-30 at 16:05 -0700, David Miller wrote: I still don't know about this patch. Instead of the simple transformation: - printk(foo); + printk(KERN_INFO foo); we get this new macro, and the lines changes to use that macro. Actually, I agree. Many local macros could be eliminated that define printk(level prefix) I'd like to see macros added to kernel.h for: pr_err pr_notice pr_warn pr_alert pr_crit pr_emerge and convert tree-wide all the single-line printk(KERN_level [prefix] fmt \n, args...) calls to the equivalent pr_level calls. That would leave the multi-line printk(level...) calls to be sorted out so these messages might no longer be interleaved by multiple cpus/threads. - 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] atl1: use spin_trylock_irqsave()
From: Ingo Molnar [EMAIL PROTECTED]
use the simpler spin_trylock_irqsave() API to get the adapter lock.
[ this is also a fix for -rt where adapter-lock is a sleeping lock. ]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Jay Cliburn [EMAIL PROTECTED]
---
drivers/net/atl1/atl1_main.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index 56f6389..3c1984e 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -1704,10 +1704,8 @@ static int atl1_xmit_frame(struct sk_buff *skb, struct
net_device *netdev)
}
}
- local_irq_save(flags);
- if (!spin_trylock(adapter-lock)) {
+ if (!spin_trylock_irqsave(adapter-lock, flags)) {
/* Can't get lock - tell upper layer to requeue */
- local_irq_restore(flags);
dev_printk(KERN_DEBUG, adapter-pdev-dev, tx locked\n);
return NETDEV_TX_LOCKED;
}
--
1.5.2.2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION] tg3 dead after s2ram
On Tue, 31 Jul 2007 11:28:32 +0200 Joachim Deguara [EMAIL PROTECTED] wrote: On my Acer Ferrari 1000 the tg3 ethernet no longer is available after a suspend to ram with the latet 2.6.23-rc1-git9. Thanks. cc's added, body retained.. The tg3 works fine with s2ram in 2.6.22.1. The tell tail signs that is dead is this message from the kernel log: [6.754133] tg3: eth0: No firmware running. [6.816140] tg3: tg3_load_tso_firmware fails for eth0 to set CPU PC, is should be 0001 [7.285797] ACPI: EC: Handler for query 0x80 is not found! [8.016223] tg3: tg3_abort_hw timed out for eth0, TX_MODE_ENABLE will not clear MAC_TX_MODE= and trying to bring the link up resuls in: # ifconfig eth0 up SIOCSIFFLAGS: No such device Full kernel log follows. -Joachim [0.00] Linux version 2.6.23-rc1-git9 ([EMAIL PROTECTED]) (gcc version 4.2.1 20070705 (prerelease) (SUSE Linux)) #13 SMP PREEMPT Tue Jul 31 11:15:02 CEST 2007 [0.00] Command line: root=/dev/disk/by-id/scsi-SATA_Hitachi_HTS5416_SB2404SJHNT7YE-part6 sysrq_always_enable resume=/dev/sda5 splash=silent showopts [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009dc00 (usable) [0.00] BIOS-e820: 0009dc00 - 000a (reserved) [0.00] BIOS-e820: 000d - 0010 (reserved) [0.00] BIOS-e820: 0010 - 7be8 (usable) [0.00] BIOS-e820: 7be8 - 7be95000 (ACPI data) [0.00] BIOS-e820: 7be95000 - 7bf0 (ACPI NVS) [0.00] BIOS-e820: 7bf0 - 8000 (reserved) [0.00] BIOS-e820: e000 - f000 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 157) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 507520) 1 entries of 3200 used [0.00] end_pfn_map = 1048576 [0.00] DMI present. [0.00] ACPI: RSDP 000F81A0, 0014 (r0 PTLTD ) [0.00] ACPI: RSDT 7BE8D65C, 003C (r1 ACRSYS ACRPRDCT 604 LTP 0) [0.00] ACPI: FACP 7BE94B9A, 0074 (r1 ATIBowfin604 ATI F4240) [0.00] ACPI: DSDT 7BE8D698, 7502 (r1ATISB460 604 MSFT 202) [0.00] ACPI: FACS 7BE95FC0, 0040 [0.00] ACPI: SSDT 7BE94C0E, 01C4 (r1 PTLTD POWERNOW 604 LTP 1) [0.00] ACPI: APIC 7BE94DD2, 0054 (r1 PTLTD APIC604 LTP 0) [0.00] ACPI: MCFG 7BE94E26, 003C (r1 PTLTDMCFG604 LTP 0) [0.00] ACPI: BOOT 7BE94E62, 0028 (r1 PTLTD $SBFTBL$ 604 LTP 1) [0.00] ACPI: SLIC 7BE94E8A, 0176 (r1 ACRSYS ACRPRDCT 604 acer 0) [0.00] Scanning NUMA topology in Northbridge 24 [0.00] CPU has 2 num_cores [0.00] No NUMA configuration found [0.00] Faking a node at -7be8 [0.00] Entering add_active_range(0, 0, 157) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 507520) 1 entries of 3200 used [0.00] Bootmem setup node 0 -7be8 [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 157 [0.00] 0: 256 - 507520 [0.00] On node 0 totalpages: 507421 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1957 pages reserved [0.00] DMA zone: 1984 pages, LIFO batch:0 [0.00] DMA32 zone: 6882 pages used for memmap [0.00] DMA32 zone: 496542 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] ATI board detected. Disabling timer routing over 8254. [0.00] ACPI: PM-Timer IO Port: 0x8008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: IRQ9 used by override. [
[OOPS] 2.6.23-rc1 Seems to be network related
Hi I'm not sure if the first email went through, resending without .config attachment. I got this partial Oops on my work laptop (DELL D800), while using the linux 2.6.23-rc1 kernel. I've been using this kernel ever since it was released and this is the first and only time it did not boot. It was around the time it should have been trying to connect to my linksys wireless router (which has been working fine everyday since the 2.6.23-rc1 kernel was released). I copied what was on screen by hand, so some info is missing. I don't know how to reproduce it. Call Trace: [c0104cbc] show_trace_log_lvl+0x1a/0x2f [c0104d6c] show_stack_log_lvl+0x9b/0xa3 [c0104f36] show_registers+0x1c2/0x2db [c0105151] die+0x02/0x1de [c01052b6] do_trap+0x89/0xa2 [c010558e] do_invalid_op+0x88/0x92 [c035a162] error_code+0x6a/0x70 [c0114efa] kmap_atomic+0xe/0x10 [c014a29c] get_page_from_freelist+0x24c/0x3... [c015dd06] __alloc_pages+0x53/0x27d [c015da60] kmem_cache_alloc+0x32/0x68 [c02e5065] dst_alloc+0x28/0x60 [c02f45fe] ip_route_input+0x9b9/0xbba [c0314835] arp_process+0x155/0x4e1 [c0314caa] arp_rcv+0xe9/0xfd [c02e1660] netif_receive_skb+0x16e/0x1eb [c02e2efa] process_backlog+0x71/0xda [c02e2fb9] net_rx_action+0x56/0xee [c011f437] __do_softirq+0x38/0x7a [c0106145] do_soft_irq+0x41/0x91 [c011f3c5] irq_exit+0x2c/0x66 [c010644a] do_IRQ+0xb7/0xcd [c01047eb] common_interrupt+0x23/0x28 [c0151f87] handle_mm_fault+0x1fe/0x57e [c035a162] error_code+0x6a/0x70 === EIP: [c0114e87] kmap_atomic_prot+0x27/0x8.. Linux bongani_nb 2.6.23-rc1 #4 PREEMPT Mon Jul 23 12:11:40 SAST 2007 i686 Intel(R) Pentium(R) M processor 1600MHz GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17.50.0.9 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.39 pcmciautils014 PPP2.4.4 Linux C Library libc.2.4 Dynamic linker (ldd) 2.4 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 106 wireless-tools 28 Modules Loaded tg3 snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd soundcore video output thermal sbs processor fan container button battery ac pcmcia yenta_socket rsrc_nonstatic pcmcia_core intel_agp hidp nvram rfcomm l2cap ipw2100 ieee80211 ieee80211_crypt usbhid hci_usb bluetooth ohci1394 ieee1394 ehci_hcd uhci_hcd joydev evdev I'm sorry I can't provide more info, this is completely random and it's the first time it ever happened. - 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: [OOPS] 2.6.23-rc1 Seems to be network related
On Wed, 1 Aug 2007 02:57:48 +0200 Bongani Hlope [EMAIL PROTECTED] wrote: I'm not sure if the first email went through, resending without .config attachment. It did come through, and I replied ;) The below post-2.6.23-rc1 patch should fix it. commit b8c1c5da1520977cb55a358f20fc09567d40cad9 Author: Andrew Morton [EMAIL PROTECTED] Date: Tue Jul 24 12:02:40 2007 -0700 slab: correctly handle __GFP_ZERO Use the correct local variable when calling into the page allocator. Local `flags' can have __GFP_ZERO set, which causes us to pass __GFP_ZERO into the page allocator, possibly from illegal contexts. The page allocator will later do prep_zero_page()-kmap_atomic(..., KM_USER0) from irq contexts and will then go BUG. Cc: Mike Galbraith [EMAIL PROTECTED] Acked-by: Christoph Lameter [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] diff --git a/mm/slab.c b/mm/slab.c index bde271c..a684778 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -2776,7 +2776,7 @@ static int cache_grow(struct kmem_cache * 'nodeid'. */ if (!objp) - objp = kmem_getpages(cachep, flags, nodeid); + objp = kmem_getpages(cachep, local_flags, nodeid); if (!objp) goto failed; - 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] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote:
On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
If SCTP data sender received a SACK which contains Cumulative TSN Ack is
not less than the Cumulative TSN Ack Point, and if this Cumulative TSN
Ack is not used by the data sender, SCTP data sender still accept this
SACK , and next SACK which send correctly to DATA sender be dropped,
because it is less than the new Cumulative TSN Ack Point.
After received this SACK, data will be retrans again and again even if
correct SACK is received.
So I think this SACK must be dropped to let data transmit correctly.
Following is the tcpdump of my test. And patch in this mail can avoid
this problem.
02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS:
10] [MIS: 65535] [init TSN: 217114040]
02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100]
[MIS: 65535] [init TSN: 100]
02:19:39.798583 sctp (1) [COOKIE ECHO]
02:19:40.082125 sctp (1) [COOKIE ACK]
02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0]
[PPID 0xf192090b]
02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1]
[PPID 0x3e467007]
02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2]
[PPID 0x11b12a0a]
02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3]
[PPID 0x30e7d979]
02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4]
[PPID 0x251ff86f]
02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5]
[PPID 0xe5d5da5d]
02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7]
[PPID 0xca47e645]
02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8]
[PPID 0x6c0ea150]
02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9]
[PPID 0x9cc1994f]
02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10]
[PPID 0xb1df4129]
02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
Signed-off-by: Wei Yongjun [EMAIL PROTECTED]
--- net/sctp/sm_statefuns.c.orig2007-07-29 18:11:01.0 -0400
+++ net/sctp/sm_statefuns.c 2007-07-29 18:14:49.0 -0400
@@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
return SCTP_DISPOSITION_DISCARD;
}
+ /* If Cumulative TSN Ack is not less than the Cumulative TSN
+* Ack which will be send in the next data, drop the SACK.
+*/
+ if (!TSN_lt(ctsn, asoc-next_tsn)) {
+ SCTP_DEBUG_PRINTK(ctsn %x\n, ctsn);
+ SCTP_DEBUG_PRINTK(next_tsn %x\n, asoc-next_tsn);
+ return SCTP_DISPOSITION_DISCARD;
+ }
+
/* Return this SACK for further processing. */
Re: [PATCH] pktgen - define and use pktgen_dbg,err,warn,info
From: Joe Perches [EMAIL PROTECTED] Date: Tue, 31 Jul 2007 16:48:06 -0700 I'd like to see macros added to kernel.h for: pr_err pr_notice pr_warn pr_alert pr_crit pr_emerge No objections here :) - 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] net/sched: mark NET_CLS_RSVP6 depends on IPV6
Signed-off-by: Denis Cheng [EMAIL PROTECTED] --- net/sched/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/sched/Kconfig b/net/sched/Kconfig index 8a74cac..5d3749c 100644 --- a/net/sched/Kconfig +++ b/net/sched/Kconfig @@ -300,6 +300,7 @@ config NET_CLS_RSVP config NET_CLS_RSVP6 tristate IPv6 Resource Reservation Protocol (RSVP6) select NET_CLS + depends on IPV6 ---help--- The Resource Reservation Protocol (RSVP) permits end systems to request a minimum and maximum data flow rate for a connection; this -- 1.5.2.2 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/sched: mark NET_CLS_RSVP6 depends on IPV6
Denis Cheng wrote: Signed-off-by: Denis Cheng [EMAIL PROTECTED] --- net/sched/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/sched/Kconfig b/net/sched/Kconfig index 8a74cac..5d3749c 100644 --- a/net/sched/Kconfig +++ b/net/sched/Kconfig @@ -300,6 +300,7 @@ config NET_CLS_RSVP config NET_CLS_RSVP6 tristate IPv6 Resource Reservation Protocol (RSVP6) select NET_CLS + depends on IPV6 ---help--- The Resource Reservation Protocol (RSVP) permits end systems to request a minimum and maximum data flow rate for a connection; this I thought the same but ... see http://marc.info/?l=linux-kernelm=118440958516205w=2 http://marc.info/?l=linux-netdevm=118442747709230w=2 Regards, Gabriel - 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] net/sched: mark NET_CLS_RSVP6 depends on IPV6
On 8/1/07, Gabriel C [EMAIL PROTECTED] wrote: I thought the same but ... see http://marc.info/?l=linux-kernelm=118440958516205w=2 http://marc.info/?l=linux-netdevm=118442747709230w=2 That sounds good. Thanks. -- Denis - 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: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
Sorry, coming in late due to list issues...
Wei Yongjun wrote:
On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote:
On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
If SCTP data sender received a SACK which contains Cumulative TSN Ack is
not less than the Cumulative TSN Ack Point, and if this Cumulative TSN
Ack is not used by the data sender, SCTP data sender still accept this
SACK , and next SACK which send correctly to DATA sender be dropped,
because it is less than the new Cumulative TSN Ack Point.
After received this SACK, data will be retrans again and again even if
correct SACK is received.
So I think this SACK must be dropped to let data transmit correctly.
Following is the tcpdump of my test. And patch in this mail can avoid
this problem.
02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS:
10] [MIS: 65535] [init TSN: 217114040]
02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100]
[MIS: 65535] [init TSN: 100]
02:19:39.798583 sctp (1) [COOKIE ECHO]
02:19:40.082125 sctp (1) [COOKIE ACK]
02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0]
[PPID 0xf192090b]
02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1]
[PPID 0x3e467007]
02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2]
[PPID 0x11b12a0a]
02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3]
[PPID 0x30e7d979]
02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4]
[PPID 0x251ff86f]
02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5]
[PPID 0xe5d5da5d]
02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7]
[PPID 0xca47e645]
02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8]
[PPID 0x6c0ea150]
02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9]
[PPID 0x9cc1994f]
02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10]
[PPID 0xb1df4129]
02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6]
[PPID 0x87d8b423]
02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap
acks 0] [#dup tsns 0]
Signed-off-by: Wei Yongjun [EMAIL PROTECTED]
--- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.0 -0400
+++ net/sctp/sm_statefuns.c2007-07-29 18:14:49.0 -0400
@@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
return SCTP_DISPOSITION_DISCARD;
}
+ /* If Cumulative TSN Ack is not less than the Cumulative TSN
+ * Ack which will be send in the next data, drop the SACK.
+ */
+ if (!TSN_lt(ctsn, asoc-next_tsn)) {
+ SCTP_DEBUG_PRINTK(ctsn %x\n, ctsn);
+ SCTP_DEBUG_PRINTK(next_tsn %x\n, asoc-next_tsn);
+ return SCTP_DISPOSITION_DISCARD;
+ }
+
/* Return this
Re: [PATCH FINAL] Merge the Sonics Silicon Backplane subsystem
On Sun, 29 Jul 2007 13:24:54 +0200 Michael Buesch [EMAIL PROTECTED] wrote: The Sonics Silicon Backplane is a mini-bus used on various Broadcom chips and embedded devices. Sigh. s390: drivers/ssb/main.c: In function 'ssb_ssb_read16': drivers/ssb/main.c:489: error: implicit declaration of function 'readw' drivers/ssb/main.c: In function 'ssb_ssb_read32': drivers/ssb/main.c:497: error: implicit declaration of function 'readl' drivers/ssb/main.c: In function 'ssb_ssb_write16': drivers/ssb/main.c:505: error: implicit declaration of function 'writew' drivers/ssb/main.c: In function 'ssb_ssb_write32': drivers/ssb/main.c:513: error: implicit declaration of function 'writel' we shouldn't be compiling SSB on s390, because: config SSB tristate Sonics Silicon Backplane support depends on EXPERIMENTAL HAS_IOMEM and akpm2:/usr/src/25 grep IOMEM .config CONFIG_NO_IOMEM=y akpm2:/usr/src/25 but akpm2:/usr/src/25 grep SSB .config CONFIG_DCSSBLK=m CONFIG_SSB=m CONFIG_SSB_SILENT=y well, how did that come about? It _has_ to be `select'. It's _always_ `select'. yup, it's `select': Selected by: B44 NETDEVICES NET_ETHERNET || BCM43XX_MAC80211 NETDEVICES !S390 MAC80211 WLAN_80211 EXPERIMENTAL Look. Kconfig's `select' Just. Does. Not. Work. If you find yourself contemplating using it, please, don sackcloth, take a cold shower and several analgesics, then have another go, OK? ho hum. - 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 FINAL] Merge the Sonics Silicon Backplane subsystem
On Sun, 29 Jul 2007 13:24:54 +0200 Michael Buesch [EMAIL PROTECTED] wrote:
The Sonics Silicon Backplane is a mini-bus used on
various Broadcom chips and embedded devices.
A few probs with mips allmodconfig:
drivers/ssb/driver_mipscore.c:121: warning: struct ssb_serial_ports declared
inside parameter list
drivers/ssb/driver_mipscore.c:121: warning: its scope is only this definition
or declaration, which is probably not what you want
drivers/ssb/driver_mipscore.c: In function `ssb_mips_serial_init':
drivers/ssb/driver_mipscore.c:166: warning: passing arg 1 of
`ssb_extif_serial_init' from incompatible pointer type
drivers/ssb/driver_mipscore.c:166: warning: passing arg 2 of
`ssb_extif_serial_init' from incompatible pointer type
drivers/ssb/driver_mipscore.c: At top level:
drivers/ssb/driver_mipscore.c:188: warning: 'ssb_cpu_clock' defined but not used
drivers/ssb/driver_pcicore.c: In function `ssb_fixup_pcibridge':
drivers/ssb/driver_pcicore.c:98: error: implicit declaration of function
`pcibios_enable_device'
drivers/ssb/driver_pcicore.c: At top level:
drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expression
drivers/ssb/driver_pcicore.c:278: warning: integer overflow in expression
the latter is due to .end in
static struct resource ssb_pcicore_mem_resource = {
.name = SSB PCIcore external memory,
.start = SSB_PCI_DMA,
.end= SSB_PCI_DMA + SSB_PCI_DMA_SZ - 1,
.flags = IORESOURCE_MEM,
};
It could be more Kconfig select borkage, 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
