Re: ip_finish_output2: No header cache and no neighbour! in 2.6.15-git7
Herbert Xu wrote:
On Mon, Jan 16, 2006 at 08:08:19AM +0100, Patrick McHardy wrote:
I can't figure out how this can happen. If a local outgoing multicast
packet would have been SNATed to a non-local IP, ip_route_input would
have been used by ip_route_me_harder. In that case we should see
ip_output instead of ip_mc_output in the backtrace. But it definitely
looks related to the rerouting changes in the NAT code.
The reason it stays in ip_mc_output is because the SNAT is performed
by the POST_ROUTING hook in ip_mc_output. So it's too late to get out
of it.
Because at this stage in the stack we no longer look at dst-output the
skb is simply passed onto ip_finish_output and then ip_finish_output2.
You're absolutely right. Using ip_route_output for local outgoing
packets in POST_ROUTING should fix this problem.
Andi, can you please try this patch?
diff --git a/include/linux/netfilter_ipv4.h b/include/linux/netfilter_ipv4.h
index fdc4a95..4eaecea 100644
--- a/include/linux/netfilter_ipv4.h
+++ b/include/linux/netfilter_ipv4.h
@@ -78,7 +78,7 @@ enum nf_ip_hook_priorities {
#define SO_ORIGINAL_DST 80
#ifdef __KERNEL__
-extern int ip_route_me_harder(struct sk_buff **pskb);
+extern int ip_route_me_harder(struct sk_buff **pskb, unsigned int hook);
#endif /*__KERNEL__*/
diff --git a/net/ipv4/netfilter.c b/net/ipv4/netfilter.c
index 52a3d7c..0205bfa 100644
--- a/net/ipv4/netfilter.c
+++ b/net/ipv4/netfilter.c
@@ -8,10 +8,10 @@
#include net/ip.h
/* route_me_harder function, used by iptable_nat, iptable_mangle + ip_queue */
-int ip_route_me_harder(struct sk_buff **pskb)
+int ip_route_me_harder(struct sk_buff **pskb, unsigned int hook)
{
struct iphdr *iph = (*pskb)-nh.iph;
- struct rtable *rt;
+ struct rtable *rt = (struct rtable *)(*pskb)-dst;
struct flowi fl = {};
struct dst_entry *odst;
unsigned int hh_len;
@@ -19,7 +19,8 @@ int ip_route_me_harder(struct sk_buff **
/* some non-standard hacks like ipt_REJECT.c:send_reset() can cause
* packets with foreign saddr to appear on the NF_IP_LOCAL_OUT hook.
*/
- if (inet_addr_type(iph-saddr) == RTN_LOCAL) {
+ if ((hook == NF_IP_POST_ROUTING rt-fl.iif == 0) ||
+ inet_addr_type(iph-saddr) == RTN_LOCAL) {
fl.nl_u.ip4_u.daddr = iph-daddr;
fl.nl_u.ip4_u.saddr = iph-saddr;
fl.nl_u.ip4_u.tos = RT_TOS(iph-tos);
@@ -115,7 +116,7 @@ static int queue_reroute(struct sk_buff
if (!(iph-tos == rt_info-tos
iph-daddr == rt_info-daddr
iph-saddr == rt_info-saddr))
- return ip_route_me_harder(pskb);
+ return ip_route_me_harder(pskb, info-hook);
}
return 0;
}
diff --git a/net/ipv4/netfilter/ip_nat_standalone.c
b/net/ipv4/netfilter/ip_nat_standalone.c
index ad438fb..d1d89ea 100644
--- a/net/ipv4/netfilter/ip_nat_standalone.c
+++ b/net/ipv4/netfilter/ip_nat_standalone.c
@@ -246,7 +246,8 @@ ip_nat_out(unsigned int hooknum,
ct-tuplehash[!dir].tuple.dst.u.all
#endif
)
- return ip_route_me_harder(pskb) == 0 ? ret : NF_DROP;
+ if (ip_route_me_harder(pskb, hooknum) != 0)
+ ret = NF_DROP;
}
return ret;
}
@@ -279,7 +280,8 @@ ip_nat_local_fn(unsigned int hooknum,
ct-tuplehash[dir].tuple.src.u.all
#endif
)
- return ip_route_me_harder(pskb) == 0 ? ret : NF_DROP;
+ if (ip_route_me_harder(pskb, hooknum) != 0)
+ ret = NF_DROP;
}
return ret;
}
diff --git a/net/ipv4/netfilter/iptable_mangle.c
b/net/ipv4/netfilter/iptable_mangle.c
index 3212a5c..78a58f7 100644
--- a/net/ipv4/netfilter/iptable_mangle.c
+++ b/net/ipv4/netfilter/iptable_mangle.c
@@ -158,7 +158,8 @@ ipt_local_hook(unsigned int hook,
|| (*pskb)-nfmark != nfmark
#endif
|| (*pskb)-nh.iph-tos != tos))
- return ip_route_me_harder(pskb) == 0 ? ret : NF_DROP;
+ if (ip_route_me_harder(pskb, hook) != 0)
+ ret = NF_DROP;
return ret;
}
Re: PATCH: iproute2 - prio qdisc, fix priomap
jamal wrote: On Mon, 2006-16-01 at 06:51 +0100, Patrick McHardy wrote: jamal wrote: On Mon, 2006-16-01 at 05:56 +0100, Patrick McHardy wrote: This is a dead horse since I ACKed the patch, but that patch is _wrong_ without the user space fix. What's wrong with this: tc qdisc add dev dummy0 root handle 1: prio bands 5 for i in $(seq 1 5); do tc filter add dev dummy0 parent 1: handle $i fw classid 1:$i done Clearly nothing in the kernel patch fixed anything for the above. [dummy by default just blackholes packets - so it doesnt matter if you have noop or fifo or red qdiscs attached on all 5 classes]. Admittedly using dummy in this example wasn't the best choice, the point was that its absolutely fine to use prio without a priomap at all. ;- so in your opinion was it fine for tc to send it anyways or does tc need fixing? ;- It shouldn't use the default mapping if its known to be invalid. ;- what is invalid is to use a priomap for 3 bands when there is infact X bands - where X !=3. Would you agree? If X 3 then maybe, priomap points to nonexistant classes which the kernel will reject, which it doesn't have to do, but I'm fine with it. If X 3 then this just means no value of skb-priority maps to some classes, but this doesn't make them any less usable. Ok Patrick, we can discuss this until the cows come home, for simplicity sake: just answer the question above if you think it is ok for tc to behave the way it does (then the debate on the patch is resolved while we can still disagree at the latte-philosophical level). i.e: tc always assumes a map to 3 queues regardless of whether you have 15 or 2. I say it should not - what says you? See above. But I agree, lets stop this discussion, its leading nowhere. - To unsubscribe from this list: send 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] [IPV4] : rt_cache_stat can be statically defined
Using __get_cpu_var(obj) is slightly faster than per_cpu_ptr(obj,
raw_smp_processor_id()).
1) Smaller code and memory use
For static and small objects, DEFINE_PER_CPU(type, object) is preferred over a
alloc_percpu() : Better and smaller code to access them, and no extra memory
(storing the pointer, and the percpu array of pointers)
x86_64 code before patch
mov1237577(%rip),%rax# 803e5990 rt_cache_stat
not%rax # part of per_cpu machinery
mov%gs:0x3c,%edx # get cpu number
movslq %edx,%rdx # extend 32 bits cpu number to 64 bits
mov(%rax,%rdx,8),%rax # get the pointer for this cpu
incl 0x38(%rax)
x86_64 code after patch
mov$per_cpu__rt_cache_stat,%rdx
mov%gs:0x48,%rax # get percpu data offset
incl 0x38(%rax,%rdx,1)
2) False sharing avoidance for SMP :
For a small NR_CPUS, the array of per cpu pointers allocated in alloc_percpu()
can be = 32 bytes. This let slab code gives a part of a cache line. If the
other part of this 64 bytes (or 128 bytes) cache line is used by a mostly
written object, we can have false sharing and expensive per_cpu_ptr() operations.
Size of rt_cache_stat is 64 bytes, so this patch is not a danger of a too big
increase of bss (in UP mode) or static per_cpu data for SMP
(PERCPU_ENOUGH_ROOM is currently 32768 bytes)
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
--- net-2.6/net/ipv4/route.c2006-01-17 10:51:24.0 +0100
+++ net-2.6-ed/net/ipv4/route.c 2006-01-17 11:25:33.0 +0100
@@ -240,9 +240,8 @@
static int rt_hash_log;
static unsigned intrt_hash_rnd;
-static struct rt_cache_stat *rt_cache_stat;
-#define RT_CACHE_STAT_INC(field) \
- (per_cpu_ptr(rt_cache_stat, raw_smp_processor_id())-field++)
+static DEFINE_PER_CPU(struct rt_cache_stat, rt_cache_stat);
+#define RT_CACHE_STAT_INC(field) (__get_cpu_var(rt_cache_stat).field++)
static int rt_intern_hash(unsigned hash, struct rtable *rth,
struct rtable **res);
@@ -401,7 +400,7 @@
if (!cpu_possible(cpu))
continue;
*pos = cpu+1;
- return per_cpu_ptr(rt_cache_stat, cpu);
+ return per_cpu(rt_cache_stat, cpu);
}
return NULL;
}
@@ -414,7 +413,7 @@
if (!cpu_possible(cpu))
continue;
*pos = cpu+1;
- return per_cpu_ptr(rt_cache_stat, cpu);
+ return per_cpu(rt_cache_stat, cpu);
}
return NULL;
@@ -3160,10 +3159,6 @@
ipv4_dst_ops.gc_thresh = (rt_hash_mask + 1);
ip_rt_max_size = (rt_hash_mask + 1) * 16;
- rt_cache_stat = alloc_percpu(struct rt_cache_stat);
- if (!rt_cache_stat)
- return -ENOMEM;
-
devinet_init();
ip_fib_init();
@@ -3191,7 +3186,6 @@
if (!proc_net_fops_create(rt_cache, S_IRUGO, rt_cache_seq_fops) ||
!(rtstat_pde = create_proc_entry(rt_cache, S_IRUGO,
proc_net_stat))) {
- free_percpu(rt_cache_stat);
return -ENOMEM;
}
rtstat_pde-proc_fops = rt_cpu_seq_fops;
Re: Resubmit: [PATCH] net: fix PRIO qdisc bands init
From: Amnon Aaronsohn [EMAIL PROTECTED] Date: Sat, 14 Jan 2006 16:24:59 +0200 (IST) Currently when PRIO is configured to use N bands, it lets the packets be directed to any of the bands 0..N-1. However, PRIO attaches a fifo qdisc only to the bands that appear in the priomap; the rest of the N bands remain with a noop qdisc attached. This patch changes PRIO's behavior so that it attaches a fifo qdisc to all of the N bands. Signed-off-by: Amnon Aaronsohn [EMAIL PROTECTED] Applied, thanks Amnon. - To unsubscribe from this list: send 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 whitespace issues in net/core/filter.c
From: Kris Katterjohn [EMAIL PROTECTED] Date: Sat, 14 Jan 2006 08:37:48 -0800 This fixes some whitespace issues in net/core/filter.c Signed-off-by: Kris Katterjohn [EMAIL PROTECTED] 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] fix ip[6]t_policy compiler warnings after x_tables merge
From: Harald Welte [EMAIL PROTECTED] Date: Sat, 14 Jan 2006 21:40:53 +0100 [NETFILTER] ip[6]t_policy: Fix compilation warnings ip[6]t_policy argument conversion slipped when merging with x_tables Signed-off-by: Benoit Boissinot [EMAIL PROTECTED] Signed-off-by: Harald Welte [EMAIL PROTECTED] 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 3/3] [NETFILTER] ip6tables: whitespace and indent cosmetic cleanup
All 3 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] tg3: Refine nvram locking
From: Michael Chan [EMAIL PROTECTED] Date: Mon, 16 Jan 2006 14:36:34 -0800 Add nvram lock count so that calls to tg3_nvram_lock()/unlock() can be nested. Add error checking to all callers of tg3_nvram_lock() where appropriate. To prevent nvram lock failures after halting the firmware, it is also necessary to release firmware's nvram lock in tg3_halt_cpu(). Update version to 3.48. Based on David Miller's initial patch. Signed-off-by: Michael Chan [EMAIL PROTECTED] 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] [IPV4] : rt_cache_stat can be statically defined
From: Eric Dumazet [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 10:56:13 +0100 x86_64 code before patch mov1237577(%rip),%rax# 803e5990 rt_cache_stat not%rax # part of per_cpu machinery mov%gs:0x3c,%edx # get cpu number movslq %edx,%rdx # extend 32 bits cpu number to 64 bits mov(%rax,%rdx,8),%rax # get the pointer for this cpu incl 0x38(%rax) x86_64 code after patch mov$per_cpu__rt_cache_stat,%rdx mov%gs:0x48,%rax # get percpu data offset incl 0x38(%rax,%rdx,1) Similar gains on sparc64 :-) Signed-off-by: Eric Dumazet [EMAIL PROTECTED] I think I'll apply this, thanks a lot Eric. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux networking kernel layer and STREAMS
But you haven't even studied how the Linux networking works, so how would you know? I guess time is better spent reinventing the wheel. Since you don't know, by definition you're spewing. You don't know the Linux networking, and therefore you don't know whether existing mechanisms can solve your problem or not. First of all, thanks for the pointer to XFRM. I have tried to find information about it, but this is few and far between. For example, mailing list messages about a 3COM 3CR990 patch for IPSEC offloading are easily missed. About your remark: I have studied linux networking so far as it has crossed my path. IPSEC, the only place for which XFRM is being used it seems, was scheduled for later. You don't expect to see a different framework in a subset of the stack. Also, I don't see how this invalidates my use of another streams-like framework any more than the existence of STREAMS in solaris does. XFRM is pretty much tailored to its use-case. FFPF (what I'm working on) is in its own right. Does XFRM support big little endian hardware to work on the same structures? Does is support transparent context-switch reduction and zero-copy? If so, then it is unfortunate that I didn't find out before. Which brings me to point two. My network subsystem knowledge comes mostly from previously published work at academic venues -- as I wrote before. This is accepted procedure in scientific circles (even applied science like systems research). The underlying idea is that if implementations (Linux, Windows, Plan9) are innovative in any way, those features would have been published about independently in the same venues (or at least the Linux Symposium, BSDCon, ..). It appears the communities don't mix enough. Publish what you have, if it's new. Why? because if you don't you can make a snide remark to one guy that he didn't study linux, but how many systems should a person study before you start coding? Is it ok to know just linux? or should I also know all internals of NetBSD? What about WindowsNT, Plan9, VMS, IOS? You can reprimande me, but there are countless others who will make the same 'mistake'. In short, I would love to build on top of your work, instead of having to deal with the same kernel panic you probably encountered a few years ago. But first of all the system you point to doesn't seem appropriate for my research. More importantly, even if it had, I didn't come across it in time. You're opinion is that this is my fault, that I didn't read through enough code and mailing list messages. I believe this is only partly the truth. Equally important is that your work wasn't brought to publicly attention throught he standard method (i.e. publishing a paper). If - on the other hand - you don't care about these things, that's okay too. But then reprimanding someone afterwards for not having heard of your work is a bit odd. By the way, I never meant to start a discussion about this topic. It seems out-of-place in a net-dev mailing list. As you threw the ball, though, it's only decent to return it. Is research funding that hard to obtain these days? was this really necessary? respectfully, Willem - To unsubscribe from this list: send 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/1] LSM-IPsec SELinux Authorize
From: Trent Jaeger [EMAIL PROTECTED] Date: Mon, 16 Jan 2006 21:54:13 -0500 We want to limit the modification of security contexts only to the minimal set of programs (e.g., setkey and racoon). SELinux generally restricts root programs to least privilege rights, such that a root program that does not modify security policy under any normal circumstances is not given permissions to do so. As a result, such programs are constrained from modifying security policy if compromised. What about per-socket IPSEC policy settings installed via setsockopt()? - To unsubscribe from this list: send 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] 3c59x: improve usage of netif_carrier_{on,off}
Steffen Klassert [EMAIL PROTECTED] wrote:
The patch _should_ do the following:
1. Set the polling intervall for media changes to 5 seconds if link is down
and 60 seconds if link is up.
2. Handle netif_carrier_{on,of} and check for media changes in
proper way by using mii_check_media() in the mii case.
3. Handle netif_carrier_{on,of} also if media is forced to 10baseT/100baseTx.
4. Use ethtool_op_get_link instead of vortex_get_link.
So it is possible to test with ethtool.
This makes a 3c980-TX NIC start throwing Tx timeout errors once it's put
under a bit of load.
If the patch had been separated into a series of four (as it should have
been) then I'd have been able to identify the offending one. But I don't
really have the time to work out what's gone wrong here, sorry.
-
To unsubscribe from this list: send 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] signed long - long
Kris Katterjohn wrote: I learned C with KR (ANSI) and it says: C99 seems to be the standard used in kernel. It clarifies much and aligns with real machines in many cases. Regards Ingo Oeser - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux networking kernel layer and STREAMS
From: Willem de Bruijn [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 11:55:44 +0100 About your remark: I have studied linux networking so far as it has crossed my path. IPSEC, the only place for which XFRM is being used it seems, was scheduled for later. You don't expect to see a different framework in a subset of the stack. I'm talking about stackable routes, which is in the destination cache and is at the core of how all routing works in the Linux kernel. It's generic and has absolutely nothing to do with IPSEC. You don't have to learn XFRM, or IPSEC, to learn how stackable destination cache entries work. They're very simple, and you can hook them up however you like to transform your data as it traverses the input and output paths of the stack. You have to learn one data structure (struct dst_entry) and two inline functions (dst_input() and dst_output()). It's been referred to now twice in this thread. Also, I don't see how this invalidates my use of another streams-like framework any more than the existence of STREAMS in solaris does. XFRM is pretty much tailored to its use-case. Stackable destination cache infrastructure, which is what I was actually talking about, is not. It's generic. My network subsystem knowledge comes mostly from previously published work at academic venues -- as I wrote before. This is accepted procedure in scientific circles (even applied science like systems research). The underlying idea is that if implementations (Linux, Windows, Plan9) are innovative in any way, those features would have been published about independently in the same venues (or at least the Linux Symposium, BSDCon, ..). It appears the communities don't mix enough. Publish what you have, if it's new. I'm sorry but that is totally backwards. When I want to see what the start of the art is, I go look at other implementations not research papers. Research papers are the last resort. In fact, existing implementations are the ultimate shit filter for all the research out there. Why? because if you don't you can make a snide remark to one guy that he didn't study linux, but how many systems should a person study before you start coding? Is it ok to know just linux? or should I also know all internals of NetBSD? What about WindowsNT, Plan9, VMS, IOS? You can reprimande me, but there are countless others who will make the same 'mistake'. If you are doing systems work and are unfamiliar with what systems actually implement, you're by definition a charlatan. When Van Jacobson did his TCP congestion control work, he learned the BSD TCP stack backwards and forwards before he started making his changes. He made sure to take advantage of what was already there, and add only what was needed. When he did his pbuf networking stack work, he made himself aware of exactly how the networking stacks he could get his hands on operated, and why their buffer management was poor. He made better things because he knew in detail what was out there already. He looked at implementations, not papers. Van Jacobson is a real researcher and not a charlatan. - To unsubscribe from this list: send 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: State of the Union: Wireless
On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote: Actually, there is a use for the master device. It can be used to monitor what is going on over the radio from all virtual APs/STAs, e.g., by running Ethereal on it. You can add a new soft monitor interface and use it instead. There is no need for separate master device. -- Jiri Benc SUSE Labs - To unsubscribe from this list: send 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: Pull request for wireless-2.6
pulled, 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 01/13] mv643xx_eth: Add Dale Farnsworth as a maintainer
applied 1-13 - To unsubscribe from this list: send 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/5] spidernet: check if firmware was loaded correctly
applied 1-5 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux networking kernel layer and STREAMS
I'm talking about stackable routes, which is in the destination cache and is at the core of how all routing works in the Linux kernel. I misunderstood you there. Stackable routes are interesting, and indeed simple. They are miles apart from my work, and certainly not innovative. They are interesting to this discussion, however. In the discussion of STREAMS vs Linux networking I was not the right person to give a simple overview. I figured that my response was more useful to John than keeping my mouth shut. Bad judgement call, as you guys pointed out correctly. When I want to see what the start of the art is, I go look at other implementations not research papers. Research papers are the last resort. In fact, existing implementations are the ultimate shit filter for all the research out there. I definitely disagree with you here. Linux, Windows and other 'production' environments are quite conservative. Research initiatives don't have to be, and are therefore often more cutting edge. Compare Inferno, Legion or Singularity. Their implementation may suck compared to linux. The ideas embedded can form a basis for features in Linux 2.9, however. Hell, 9fs has recently been ported. When Van Jacobson did his TCP congestion control work, he learned the BSD TCP stack backwards and forwards before he started making his changes. He made sure to take advantage of what was already there, and add only what was needed. ofcourse, because his goal was to improve upon this state-of-the-art. Mine isn't. I have to learn how these things work, even implement some features (such as reassembly) in order to continue with my main work. But nowhere do I state that I am an expert on these topics. That my kernel knowledge is not 100% perhaps disqualifies me as kernel hacker. This says nothing about my qualifications as researcher, where other knowledge is of more importance. Implying that I am not just inadequate at my job, but even dishonest (a charlatan) without knowing what I do is out of place Willem - To unsubscribe from this list: send 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 RESEND netdev-2.6 1/3] e100: Fix TX hang and RMCP Ping issue (due to a microcode loading issue)
Jesse Brandeburg wrote: e100: Fix TX hang and RMCP Ping issue (due to a microcode loading issue) The large number of lines changed for this patch are due to several fuctions moving in order to be called from a new function. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] this try was even worse :( Both git-applymbox and patch(1) fail: [EMAIL PROTECTED] netdev-2.6]$ git-applymbox /g/tmp/mbox ~/info/signoff.txt 3 patch(es) to process. Applying 'e100: Fix TX hang and RMCP Ping issue (due to a microcode loading issue)' error: patch failed: drivers/net/e100.c:872 error: drivers/net/e100.c: patch does not apply and [EMAIL PROTECTED] netdev-2.6]$ patch -sp1 /g/tmp/mbox 1 out of 6 hunks FAILED -- saving rejects to file drivers/net/e100.c.rej Is this patch even against upstream??? - To unsubscribe from this list: send 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 netdev-2.6 01/39] Fix jumbo frame performance
Jeff Kirsher wrote: Partition PBA for Jumbo frames based on MTU size. Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] yay! applied patches 1-10, finally worked this time. one flaw, that required me to hand-edit stuff: remember, your emails go directly into the git changelog. Your email's subject line becomes the one-line summary for your change. Fix jumbo frame performance is not adequate, because it does not give the reader enough context. Typically, you should prefix the summary with a word indicating the subsystem or driver. In this case, I hand-edited in the prefix e1000: immediately following the [PATCH...] part. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH netdev-2.6 11/39] Fix loopback logic
Jeff Kirsher wrote: Fixed the loopback logic to work for the PCI express adapters. Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] applied 11-20, after hand-editing e1000: prefix into subject lines. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH netdev-2.6 32/39] Added disable packet split capability
Jeff Kirsher wrote: Adds the ability to disability packet split at compile time and use the legacy receive path on PCI express hardware. Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] NAK, use CONFIG for this sort of stuff - To unsubscribe from this list: send 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 netdev-2.6 21/39] Fix __pskb_pull_tail
Jeff Kirsher wrote: Fixed by moving code to correct location (for 82572 and 82571 controllers). Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] applied 21-30, after hand-editing e1000: prefix into subject lines. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH netdev-2.6 31/39] Added copy break code
Jeff Kirsher wrote: Improves small packet performance with large amounts of reassembly being done in the stack. Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] Applied 31, 33, 34, and dropped the remaining ones due to patch conflicts. Please resend those. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH ] ethtool: Remove duplex info from CTRL register dump
Jeff Kirsher wrote: The duplex control register is used for setting the driver and is not necessary for debug purposes. The value of the duplex control register is what the register's current value is and may not reflect the correct status of te current connection. That is what the duplex status register is used for. To keep from confusing the user, we are removing the duplex register from the ethtool dump of the registers. Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] applied, after replacing ethtool: with e1000: in the subject line. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND netdev-2.6 1/3] e100: Fix TX hang and RMCP Ping issue (due to a microcode loading issue)
Jesse Brandeburg wrote: e100: Fix TX hang and RMCP Ping issue (due to a microcode loading issue) The large number of lines changed for this patch are due to several fuctions moving in order to be called from a new function. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Jeff Kirsher [EMAIL PROTECTED] Signed-off-by: John Ronciak [EMAIL PROTECTED] patch content OK, but: [EMAIL PROTECTED] netdev-2.6]$ git-applymbox /g/tmp/mbox ~/info/signoff.txt 3 patch(es) to process. Applying 'e100: Fix TX hang and RMCP Ping issue (due to a microcode loading issue)' error: patch failed: drivers/net/e100.c:872 error: drivers/net/e100.c: patch does not apply - To unsubscribe from this list: send 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/arcnet/: possible cleanups
Adrian Bunk wrote: This patch contains the following possible cleanups: - make needlessly global code static - arcnet.c: remove the unneeded EXPORT_SYMBOL(arc_proto_null) - arcnet.c: remove the unneeded EXPORT_SYMBOL(arcnet_dump_packet) To make Jeff happy, arcnet.c still prints arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] applied - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remove MANY unneeded header files in net/core/filter.c
This removes many unneeded header files in net/core/filter.c Signed-off-by: Kris Katterjohn [EMAIL PROTECTED] This is a diff against -rc1. This compiles fine with no warnings and seems to run perfectly fine. Are there any headers I'm deleting that _should_ be there, but not necessarily required for a clean compilation? If so, let me know and I'll redo the patch. Thanks! --- x/net/core/filter.c 2006-01-17 10:54:42.0 -0600 +++ y/net/core/filter.c 2006-01-17 10:55:01.0 -0600 @@ -16,24 +16,9 @@ * Kris Katterjohn - Added many additional checks in sk_chk_filter() */ -#include linux/module.h -#include linux/types.h -#include linux/sched.h -#include linux/mm.h -#include linux/fcntl.h -#include linux/socket.h -#include linux/in.h -#include linux/inet.h -#include linux/netdevice.h -#include linux/if_packet.h -#include net/ip.h -#include net/protocol.h #include linux/skbuff.h #include net/sock.h #include linux/errno.h -#include linux/timer.h -#include asm/system.h -#include asm/uaccess.h #include linux/filter.h /* No hurry in this branch */ - To unsubscribe from this list: send 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: iproute2 - prio qdisc, fix priomap
Stephen Hemminger wrote: Here is another useful example without priomap that is on the netem info. # tc qdisc add dev eth0 root handle 1: prio # tc qdisc add dev eth0 parent 1:3 handle 30: netem \ delay 200ms 10ms distribution normal # tc qdisc add dev eth0 parent 30:1 tbf rate 20kbit buffer 1600 limit 3000 # tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 \ match ip dst 65.172.181.4/32 flowid 10:3 I think this should be 1:3. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
TIPC needs some cleanup
TIPC got added to 2.6.16-rc1, but needs some work. Look at some of the global symbols, from tipc.ko Standard practice is to restrict the namespace of modules to a small set of prefixes (like tipc_). How about some cleanup here. 000c T addr_domain_valid 0088 T addr_node_valid 01bc T bcbearer_push 06b5 T bcbearer_send 00ac T bcbearer_sort 0b9d T bclink_acknowledge 093a T bclink_acks_missing 0cc2 T bclink_check_gap 0903 T bclink_get_last_sent 0488 T bclink_init D bc_link_name 0d29 T bclink_peek_nack 0ed9 T bclink_recv_pkt 037c T bclink_reset_stats 060e T bclink_send_msg 03c5 T bclink_set_queue_limits 01f3 T bclink_stats 041b T bclink_stop 1f5c T bearer_add_dest 1713 T bearer_find_interface 176f T bearer_get_names 21ff T bearer_init 21c9 T bearer_lock_push 1fa7 T bearer_remove_dest 216e T bearer_resolve_congestion 0020 B bearers 2030 T bearer_schedule 1eb2 T bearer_stop 23e2 T cfg_append_tlv 259a T cfg_do_cmd 22f1 T cfg_init 22eb T cfg_link_event 22b4 T cfg_reply_alloc 24b4 T cfg_reply_string_type 250c T cfg_reply_unsigned_type 23c3 T cfg_stop T cleanup_module 3269 T cluster_attach_node 3d42 T cluster_bcast_lost_route 3cc8 T cluster_bcast_new_route 00a0 B cluster_bcast_nodes 30db T cluster_broadcast 34de T cluster_create 3078 T cluster_delete 35f9 T cluster_init 3b94 T cluster_multicast 31e4 T cluster_next_node 390e T cluster_prepare_routing_msg 3624 T cluster_recv_routing_table 3474 T cluster_remove_as_router 33a6 T cluster_select_node 32d4 T cluster_select_router 3f30 T cluster_send_ext_routes 3a4d T cluster_send_local_routes 3dbc T cluster_send_slave_routes 06a0 D CONS a23a T disc_init_link_req a092 T disc_init_msg a309 T disc_link_event a30f T disc_recv_msg 9f34 T disc_stop_link_req 9f82 T disc_update_link_req 0001654e T eth_media_start 0001660f T eth_media_stop 428e T handler_start 42ee T handler_stop 0080 B highest_allowed_slave T init_module 41c4 T k_signal 75b3 T link_changeover 574e T link_cmd_config 5089 T link_cmd_reset_stats 9af6 T link_cmd_show_stats 626b T link_create 4fc3 T link_defer_pkt 5f90 T link_delete 4574 T link_get_max_pkt 443c T link_is_active 5173 T link_is_up 4c71 T link_push_packet 4f74 T link_push_queue 47e7 T link_recv_bundle 84b7 T link_recv_fragment 5d43 T link_reset 461d T link_reset_fragments 89db T link_retransmit 7887 T link_send 6a1b T link_send_buf 722e T link_send_duplicate 6f2b T link_send_long_buf 519b T link_send_proto_msg 795b T link_send_sections_fast 4496 T link_set_queue_limits 6a0b T link_start 466e T link_stop 7487 T link_tunnel 5c28 T link_wakeup_ports 02a8 B local_nodes 0698 D LOG 000161a2 T log_dump 00016010 T log_reinit 00016128 T log_resize 00015fd0 T log_stop 15a1 T media_addr_printf 164a T media_get_names a5d3 T msg_get_media_addr a5e6 T msg_print a5c0 T msg_set_media_addr b3fe T named_node_up b5af T named_publish b0f7 T named_recv b07b T named_reinit b528 T named_withdraw c8bb T nameseq_create ce50 T nameseq_insert_publ d2ba T nameseq_remove_publ c10a T nameseq_subscribe c6e0 T nametbl_dump c6fb T nametbl_get c496 T nametbl_init d13c T nametbl_insert_publ 0080 D nametbl_lock cb2c T nametbl_mc_translate c847 T nametbl_print d1ea T nametbl_publish c1c8 T nametbl_publish_rsv d58d T nametbl_remove_publ c503 T nametbl_stop ca93 T nametbl_subscribe ccdf T nametbl_translate c9ca T nametbl_unsubscribe d633 T nametbl_withdraw 0368 B net d74c T net_init dd41 T netlink_start
Re: wireless: recap of current issues (stack)
On Sat, Jan 14, 2006 at 02:51:14PM +0100, Michael Buesch wrote: On Saturday 14 January 2006 00:03, you wrote: As an aside to this whole thing, I know we're talking about *kernel* wireless but it's worthless to most people without good userland support as well. Anyone have any thoughts and feelings on what things look like on the desktop? I think if we work closely with some desktop people, we can shepard in some wonderful new desktop support on top of the new netlink API. I am in the KDE development and have (almost) full access to the KDE svn repository. Altought I did not do much coding on KDE apps recently, I will be able to help in WiFi support for KDE. The first thing I thought of, was a tray icon with basic information about the available interfaces and basic configuration capabilities. There is already at least 2 KDE applications for WiFi stuff, and both are fully fledged (i.e. not just a signal meter) : http://websvn.kde.org/trunk/KDE/kdenetwork/wifi/ http://websvn.kde.org/trunk/kdenonbeta/kifi/ Note that I've used neither, so I don't know how good they are and what features are missing. If you decide to write another apps, please send me the link so I can add it on my web page. Greetings Michael. Have fun... Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TIPC needs some cleanup
On Tue, 17 Jan 2006, Stephen Hemminger wrote: TIPC got added to 2.6.16-rc1, but needs some work. Look at some of the global symbols, from tipc.ko Standard practice is to restrict the namespace of modules to a small set of prefixes (like tipc_). Yep, we are aware of the problem as Jamal also pointed this out when he reviewed the code. I'm working on fixing this as we speak. /Per - To unsubscribe from this list: send 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] [TRIVIAL] prism54/islpci_eth.c: dev_kfree_skb in irq context
I am going to NACK this. Two reasons : 1) Unless we are patching different trees, it appears the dev_kfree_skb at label drop_free got missed. 2) I still do not understand this. Quote from the definition of dev_kfree_skb_irq - /* Use this variant when it is known for sure that it * is executing from interrupt context. */ This patch is within the (hard)transmit path called from the upper layers. I do not see any other driver doing this in the hard transmit path. Can we really get this in IRQ context ? If, for any reason, that is so then we should use dev_kfree_skb_any. (Or I am being particularly thick) Roger While On 17/01/06, John W. Linville [EMAIL PROTECTED] wrote: On Wed, Jan 04, 2006 at 09:33:27AM +1030, Graham Gower wrote: On 03/01/06, Patrick McHardy [EMAIL PROTECTED] wrote: Graham Gower wrote: My logs were starting to fill with messages exatcly like that mentioned here: http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=2840 In any event, the patch at the end of that link was never applied (it doesn't fix the other call to dev_kfree_skb). After applying my patch, I've not had any more messages in the logs. The patch has been applied to 2.6.15-rc. Only the first hunk of your patch is still required, but it doesn't apply anymore. Can you send a new patch against 2.6.15 please? Ok, here's a new one. Hope I got it right this time. Signed-off-by: Graham Gower [EMAIL PROTECTED] --- linux-2.6.15/drivers/net/wireless/prism54/islpci_eth.c.orig +++ linux-2.6.15/drivers/net/wireless/prism54/islpci_eth.c @@ -177,7 +177,7 @@ #endif newskb-dev = skb-dev; - dev_kfree_skb(skb); + dev_kfree_skb_irq(skb); skb = newskb; } } - I'm planning to apply this patch with the following changelog commentary: [PATCH] prism54/islpci_eth.c: dev_kfree_skb used with interrupts disabled dev_kfree_skb should not be used with interrupts disabled. Change to use dev_kfree_skb_irq instead. Is that alright w/ everyone? Fine by me. - To unsubscribe from this list: send 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 RESEND netdev-2.6 1/3] e100: Fix TX hang and RMCP Ping issue (due to a microcode loading issue)
On Tue, 17 Jan 2006, Jeff Garzik wrote: [EMAIL PROTECTED] netdev-2.6]$ patch -sp1 /g/tmp/mbox 1 out of 6 hunks FAILED -- saving rejects to file drivers/net/e100.c.rej Is this patch even against upstream??? it failed because upstream changed out from underneath us when the mdio lock fixes went in from mm I'm working on regenerating them against current upstream, we're working to make this easier by having a git:// repository hosted around here. Apologies for the thrash, whee... Jesse - To unsubscribe from this list: send 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: wireless: recap of current issues (stack)
Hi, On Fri, Jan 13, 2006 at 05:03:28PM -0600, Chase Venters wrote: On Friday 13 January 2006 15:32, John W. Linville wrote: What about the suggestion of having both stacks in the kernel at once? I'm not very excited about two in-kernel stacks. Still, consolidating wireless drivers down to two stacks is probably better than what we have now...? Either way, we would have to have general understanding that at some point (not too far away), one of the stacks would have to disappear. But I have to NAK the idea of two stacks. There are implications in the 'here and now', so to speak, but what worries me the most is long term. You know how it's no fun fixing bugs when you could be adding new features? Let's say that on May 2006, you drop the hammer and decide that Stack B is the winner. You've now got to convince / motivate the Stack A users to stop what they're doing and work hard to migrate to Stack B. At the present time, the ieee80211 stack is used by ipw2x00 (heavily) and hostap (a little bit). Other mainline drivers only use headers (mainly constants). If it shows that the DeviceScape stack is more mature and appropriate (which I think it is), I don't see anything wrong with having both in the kernel at one time time. - DeviceScape can be there so it can be polished and new drivers can start using it. - ieee80211 could be there with a big fat warning that it will go away soon, just to allow ipw2x00 to work while DeviceScape and the ipw2x00 port for it to be stabilized. Isnt't this a viable option? Regards, -- Jirka Bohac [EMAIL PROTECTED] SUSE Labs, SUSE CR - To unsubscribe from this list: send 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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote: If I have told my equipment to obey UK law I expect it to do so. If I hop on the train to France and forget to revise my configuration I'd prefer it also believed the APs It's not that you might forget to revise your configuration, but that the vast majority of users will not revise anything, and still expect things to just work. Kind of like multi-band cell phones. This isn't that big of a deal in the 2.4GHz band, but when you start talking about 5GHz, especially in France, things get a lot trickier. Of course, all of this automagic just work crap only affects the STAs. For AP operation, we have to trust the user to set the correct locale -- I don't see any way of including a sane just-works default in the stock kernel.org tree, so I think the default should be be none. This way the user is forced to explicitly set the regdomain in order for the AP startup to succeed. ...and pray that the AP isn't migrating to a different regdomain, but there's really nothing anyone can do about that. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpgMqdzpwaQM.pgp Description: PGP signature
Re: [RFC: 2.6 patch] remove drivers/net/eepro100.c
On Sun, Jan 15, 2006 at 04:03:40PM -0800, Stephen Hemminger wrote: On Sun, 15 Jan 2006 16:19:58 +0300 Vitaly Bordug [EMAIL PROTECTED] wrote: On Thu, 5 Jan 2006 19:18:26 +0100 Adrian Bunk [EMAIL PROTECTED] wrote: This patch removes the obsolete drivers/net/eepro100.c driver. Is there any known problem in e100 still preventing us from removing this driver (it seems noone was able anymore to verify the ARM problem)? I think I am recalling some problems on ppc82xx, when e100 was stuck on startup, and eepro100 worked just fine. Even if the patch below will be scheduled for application, we need to set up enough time for approval that e100 will be fine for all the up-to-date hw; or it should be fixed/updated before eepro100 removal. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] How about doing what was done with devfs removal, and remove it from the config menu system for a couple of releases. IMHO the devfs case was different since the complete devfs removal patch (although being straightforward) touches many files. In the eepro100 case (assuming there were no more known regressions in the e100 driver), reverting the removal patch would be trivial. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send 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: wireless: recap of current issues (configuration)
On Jan 17, 2006, at 13:41, Stuffed Crust wrote: On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote: If I have told my equipment to obey UK law I expect it to do so. If I hop on the train to France and forget to revise my configuration I'd prefer it also believed the APs It's not that you might forget to revise your configuration, but that the vast majority of users will not revise anything, and still expect things to just work. Kind of like multi-band cell phones. Alan's point is still very valid. From a poweruser point of view, if I specifically tell my wireless client You must obey US laws, and then I wander over past a broken imported AP, I don't want my client to _expand_ its allowable range. IMHO, userspace should be able to forcibly restrict wireless frequencies to a certain regdomain (or leave unrestricted and passive-scan-only), and specify how AP/ configured regdomains act. Given the range of possibilities, I think that a userspace daemon monitoring events and dynamically configuring the useable frequencies would best. That way the userspace daemon could be configured to ignore APs, union/intersect the APs with the configured regdomain, ignore the configured regdomain in the presence of APs, etc. Cheers, Kyle Moffett -- I lost interest in blade servers when I found they didn't throw knives at people who weren't supposed to be in your machine room. -- Anthony de Boer - To unsubscribe from this list: send 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: iproute2 - prio qdisc, fix priomap
The example you provide is not affected since it will be given the default 3 band and 1:3 is valid. Where it matters is when you say something like: tc qdisc add dev eth0 root handle 1: prio bands X where X is not 3. In such a case the map for the priority will be the default priomap to 3 queues only. This is wrong when you have only 2 queues and according to me inaccurate policy when you have 3 queues. This later point is the contention. I don't think i can convince Patrick neither he will convince me - so you be the tie breaker;- cheers, jamal On Tue, 2006-17-01 at 09:28 -0800, Stephen Hemminger wrote: Unless there is consensus, I'll leave it as is. Here is another useful example without priomap that is on the netem info. # tc qdisc add dev eth0 root handle 1: prio # tc qdisc add dev eth0 parent 1:3 handle 30: netem \ delay 200ms 10ms distribution normal # tc qdisc add dev eth0 parent 30:1 tbf rate 20kbit buffer 1600 limit 3000 # tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 \ match ip dst 65.172.181.4/32 flowid 10:3 - To unsubscribe from this list: send 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: TIPC needs some cleanup
On Tue, 2006-17-01 at 19:35 +0100, Andi Kleen wrote: On Tuesday 17 January 2006 18:41, Stephen Hemminger wrote: TIPC got added to 2.6.16-rc1, but needs some work. Look at some of the global symbols, from tipc.ko Standard practice is to restrict the namespace of modules to a small set of prefixes (like tipc_). Also it has its own questionable reimplementation of relayfs Andi, What do you mean reimplementing relayfs? TIPC is by definition an IPC implementation so there may be some crossover. Can you be more specific? cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TIPC needs some cleanup
On Tuesday 17 January 2006 19:58, jamal wrote: On Tue, 2006-17-01 at 19:35 +0100, Andi Kleen wrote: On Tuesday 17 January 2006 18:41, Stephen Hemminger wrote: TIPC got added to 2.6.16-rc1, but needs some work. Look at some of the global symbols, from tipc.ko Standard practice is to restrict the namespace of modules to a small set of prefixes (like tipc_). Also it has its own questionable reimplementation of relayfs Andi, What do you mean reimplementing relayfs? TIPC is by definition an IPC implementation so there may be some crossover. Can you be more specific? net/tipc/dbg.c -Andi - To unsubscribe from this list: send 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: State of the Union: Wireless / 802.11 master device
On Tue, Jan 17, 2006 at 01:05:16PM +0100, Jiri Benc wrote: On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote: Actually, there is a use for the master device. It can be used to monitor what is going on over the radio from all virtual APs/STAs, e.g., by running Ethereal on it. You can add a new soft monitor interface and use it instead. There is no need for separate master device. Sure, you can do it that way, too. However, this is not the only use. I just remembered another one: QoS. Devicescape 802.11 code uses a qdisc on the master interface to take care of determining which hardware TX queue to use with WMM (which uses four different TX queues). Each virtual interface do not include own queue and outgoing frames are queued through the master device (again, this is something that matches with VLAN implementation). For WMM, the frames in different classes would need to be scheduled from all virtual interfaces together, not just separately. Would there be a better way of doing this without using a master netdev and qdisc/netsched? -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send 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: wireless: recap of current issues (stack)
On Tue, Jan 17, 2006 at 08:23:50PM +0100, Olivier Blin wrote: And most of the time, userland has to poll for scan results or association status, netlink notifications would help. For example, it would be a lot easier for ifplugd to listen on a netlink, instead of polling for current AP and signal level every few seconds. All AP changes are sent as wireless events (for drivers that implement iwevent), so you can use that to track APs. Kernel has no way to know at which rate you want to check signal strenght, and for some card this involve interrogating the card (i.e. I/O overhead), which is why polling make sense (same for Scanning). Note that for Scanning there was some talks of sending Scanning events each time the card has updated the Scanning info, if Scanning is done in the driver (that won't work when Scanning is done in FW). I guess the only thing missing is driver patches. Please consider this page about drakroam and net_applet as well: http://qa.mandriva.com/twiki/bin/view/Main/EasyWifi NetApplet was already on my page, but thanks to you I've checked it and it's now 404. Well, assuming your netapplet is the same/continuation of the netapplet from Robert Love Joe Shaw, and not something totally different using the same name. I'll update that. Thanks -- Olivier Blin - Mandriva Merci, A+ Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless: recap of current issues (stack)
Jean Tourrilhes [EMAIL PROTECTED] writes: Please consider this page about drakroam and net_applet as well: http://qa.mandriva.com/twiki/bin/view/Main/EasyWifi NetApplet was already on my page, but thanks to you I've checked it and it's now 404. Well, assuming your netapplet is the same/continuation of the netapplet from Robert Love Joe Shaw, and not something totally different using the same name. I'll update that. Nope, it's not the same project. Our net_applet was born only a bit earlier, though it didn't support wireless at this time. Thanks -- Olivier Blin - Mandriva - To unsubscribe from this list: send 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: TIPC needs some cleanup
There are two good reasons (exuses?) for this: First, the dbg.c code was written well before relayfs, so for natural reasons we could not consider it back then. Second, at least I wasn't aware of relayfs until recently, and I am still not sure if and how much the functionalities overlap. Now that we are aware, we will of course look into this, and use relayfs if it is adeqate. Regards ///jon Andi Kleen wrote: On Tuesday 17 January 2006 19:58, jamal wrote: On Tue, 2006-17-01 at 19:35 +0100, Andi Kleen wrote: On Tuesday 17 January 2006 18:41, Stephen Hemminger wrote: TIPC got added to 2.6.16-rc1, but needs some work. Look at some of the global symbols, from tipc.ko Standard practice is to restrict the namespace of modules to a small set of prefixes (like tipc_). Also it has its own questionable reimplementation of relayfs Andi, What do you mean reimplementing relayfs? TIPC is by definition an IPC implementation so there may be some crossover. Can you be more specific? net/tipc/dbg.c -Andi - To unsubscribe from this list: send 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: State of the Union: Wireless
To do qos properly there needs to be a single net_device that a single qdisc can be installed on - this alone is a good reason for a master net_device. (there must be a single 802.11 qdisc for a single physical piece of hardware). Here is another reason (for hardware devices that do not include a MLME in hardware): In the Devicescape stack the hardware driver (called the low level driver) uses an internal interface to the rest of the stack. The master net_device is created by the rest of the stack (80211.o module). I would like to change this, so that the hardware driver itself creates a net_device, with an 802.11 ARP_HDR. This would be the master device, and the interface between the kernel 802.11 code and a hardware 802.11 device that does not implement the MLME in hardware. The 80211.o module in the kernel would hook itself into this device by watching for the broadcast message when a new device is registered, and automatically installing the 802.11 qdisc on the new device. When the hadware receives 802.11 frames the hardware device driver would set the protocol type to 802.11 before calling netif_rx, and the 80211.o module would register itself as a protocol handler for 802.11. This change would remove the current special internal interface in the Devicescape stack between the hardware driver and the core of the stack - and would make the stack better integrated with the kernel. The design here is similar to the VLAN code for the RX direction, but using the qdisc for both queueing and part of the stack implementation is a new direction for the TX. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jiri Benc Sent: Tuesday, January 17, 2006 2:05 AM To: Jouni Malinen Cc: Krzysztof Halasa; Mike Kershaw; netdev@vger.kernel.org; Stefan Rompf; John W.Linville Subject: Re: State of the Union: Wireless On Mon, 16 Jan 2006 19:07:51 -0800, Jouni Malinen wrote: Actually, there is a use for the master device. It can be used to monitor what is going on over the radio from all virtual APs/STAs, e.g., by running Ethereal on it. You can add a new soft monitor interface and use it instead. There is no need for separate master device. -- Jiri Benc SUSE Labs - To unsubscribe from this list: send 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
[PATCH 1/1] LSM-IPsec SELinux Authorize (with fixes)
Minor fixes, per James' comment.
thanks,
Catherine
This patch contains a fix for the previous patch that adds security
contexts to IPsec policies and security associations. In the previous
patch, no authorization (besides the check for write permissions to
SAD and SPD) is required to delete IPsec policies and security
assocations with security contexts. Thus a user authorized to change
SAD and SPD can bypass the IPsec policy authorization by simply
deleteing policies with security contexts. To fix this security hole,
an additional authorization check is added for removing security
policies and security associations with security contexts.
Note that if no security context is supplied on add or present on
policy to be deleted, the SELinux module allows the change
unconditionally. The hook is called on deletion when no context is
present, which we may want to change. At present, I left it up to the
module.
LSM changes:
The patch adds two new LSM hooks: xfrm_policy_delete and
xfrm_state_delete. The new hooks are necessary to authorize deletion
of IPsec policies that have security contexts. The existing hooks
xfrm_policy_free and xfrm_state_free lack the context to do the
authorization, so I decided to split authorization of deletion and
memory management of security data, as is typical in the LSM
interface.
Use:
The new delete hooks are checked when xfrm_policy or xfrm_state are
deleted by either the xfrm_user interface (xfrm_get_policy,
xfrm_del_sa) or the pfkey interface (pfkey_spddelete, pfkey_delete).
Note that the line that adds a free to xfrm_add_policy addresses a
memory leak. The security context must be freed when the insertion
fails also.
SELinux changes:
The new policy_delete and state_delete functions are added.
Signed-off-by: Trent Jaeger [EMAIL PROTECTED]
---
include/linux/security.h| 40
+--
net/key/af_key.c| 18 +++--
net/xfrm/xfrm_user.c| 19 +++---
security/dummy.c| 12 +++
security/selinux/hooks.c|2 +
security/selinux/include/xfrm.h |2 +
security/selinux/xfrm.c | 41
7 files changed, 111 insertions(+), 23 deletions(-)
diff -puN include/linux/security.h~lsm-labels-nethooks
include/linux/security.h
--- linux-2.6.15-mm3/include/linux/security.h~lsm-labels-nethooks
2006-01-13 16:00:39.0 -0500
+++ linux-2.6.15-mm3-cxzhang/include/linux/security.h2006-01-13
18:35:28.0 -0500
@@ -805,31 +805,37 @@ struct swap_info_struct;
*used by the XFRM system.
*@sec_ctx contains the security context information being provided by
*the user-level policy update program (e.g., setkey).
- *Allocate a security structure to the xp-selector.security field.
+ *Allocate a security structure to the xp-security field.
*The security field is initialized to NULL when the xfrm_policy is
*allocated.
*Return 0 if operation was successful (memory to allocate, legal
context)
* @xfrm_policy_clone_security:
*@old contains an existing xfrm_policy in the SPD.
*@new contains a new xfrm_policy being cloned from old.
- *Allocate a security structure to the new-selector.security field
- *that contains the information from the old-selector.security field.
+ *Allocate a security structure to the new-security field
+ *that contains the information from the old-security field.
*Return 0 if operation was successful (memory to allocate).
* @xfrm_policy_free_security:
*@xp contains the xfrm_policy
- *Deallocate xp-selector.security.
+ *Deallocate xp-security.
+ * @xfrm_policy_delete_security:
+ *@xp contains the xfrm_policy
+ *Authorize deleteion of xp-security.
* @xfrm_state_alloc_security:
*@x contains the xfrm_state being added to the Security Association
*Database by the XFRM system.
*@sec_ctx contains the security context information being provided by
*the user-level SA generation program (e.g., setkey or racoon).
- *Allocate a security structure to the x-sel.security field. The
+ *Allocate a security structure to the x-security field. The
*security field is initialized to NULL when the xfrm_state is
*allocated.
*Return 0 if operation was successful (memory to allocate, legal
context).
* @xfrm_state_free_security:
*@x contains the xfrm_state.
- *Deallocate xsel.security.
+ *Deallocate x-security.
+ * @xfrm_state_delete_security:
+ *@x contains the xfrm_state.
+ *Authorize deleteion of x-security.
* @xfrm_policy_lookup:
*@xp contains the xfrm_policy for which the access control is being
*checked.
@@ -1303,8 +1309,10 @@ struct security_operations {
int (*xfrm_policy_alloc_security) (struct xfrm_policy *xp, struct
xfrm_user_sec_ctx *sec_ctx);
int (*xfrm_policy_clone_security) (struct xfrm_policy *old, struct
Re: TIPC needs some cleanup
On Tue, 2006-17-01 at 21:18 +0100, Andi Kleen wrote: That is what we have code reviews for - to tell you about such things - but somehow you seem to have sneaked your code around that. That sounds a little harsh Andi and i know you are a much bigger boy than you sound above. The decision was made at netconf and announcements were made in the kernel summit; the TIPC tree has been open for months now for review. Give these guys a break and help them with good feedback as you just did before this email. cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TIPC needs some cleanup
On Tuesday 17 January 2006 21:31, jamal wrote: The decision was made at netconf and announcements were made in the kernel summit That's the famous smoke filled backrooms where Linux development shouldn't happen. the TIPC tree has been open for months now for review. That is not how Linux code review works - the code is supposed to get posted to the appropiate mailing lists so that people can go over it. Reviewers normally don't hunt for random websites to look at code there. Give these guys a break and help them with good feedback as you just did before this email. My feedback is to follow the standard code merging procedures next time. Since they skipped that they deserve some flames for poor code quality. -Andi - To unsubscribe from this list: send 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: State of the Union: Wireless / 802.11 master device
On Tue, Jan 17, 2006 at 02:55:31PM -0500, jamal wrote: On Tue, 2006-17-01 at 11:42 -0800, Jouni Malinen wrote: so if i understood correctly: You have a master netdevice which underneath it has child netdevices? I'm not sure what exactly child netdev means, but it sounds like something that could be indeed what the stack is using. The master netdev has a queue and all other netdevs do not use their own queue (i.e., they share the one used in the master netdev and all TX frames go through that). Each virtual interface do not include own queue and outgoing frames are queued through the master device (again, this is something that matches with VLAN implementation). If i understood you correctly, what you are doing is certainly reasonable. Instead of restructuring the netdevice layer to deal with with multiple independent h/ware tx queues you've added a mother device which does intermidiate queueing. The master netdev collects all TX frames and the special 802.11-aware qdisc takes care of scheduling them, e.g., based on WMM access categories to independent hardware TX queues. For WMM, the frames in different classes would need to be scheduled from all virtual interfaces together, not just separately. Would there be a better way of doing this without using a master netdev and qdisc/netsched? I havent been following the thread so i dont understand this problem. Can you explain it in details? Simon wrote some more details on related topic. The way I see this is that there can be multiple virtual netdevs (e.g., multiple virtual APs) using the same wlan radio. The frames for all these virtual APs should be able to share the same scheduling procedure, e.g., to allow voice calls get high priority regardless of which virtual AP is sending the frames for these traffic flows. Being able to set this all with existing tc tool for the master netdev looks like quite clean way of handling this. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send 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: [PKT_SCHED]: Handle SCTP/DCCP in sfq_hash
From: Patrick McHardy [EMAIL PROTECTED] Date: Thu, 12 Jan 2006 06:53:01 +0100 Handle SCTP/DCCP in sfq_hash to make it recognize seperate connections. 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: [EBTABLES]: Handle SCTP/DCCP in ebt_{ip,log}
From: Patrick McHardy [EMAIL PROTECTED] Date: Thu, 12 Jan 2006 06:53:57 +0100 This patch adds SCTP/DCCP support to ebt_ip.c and ebt_log.c. The ebt_ipt.c change needs a userspace change as well, this is the second attached patch. Kernel side applied, thanks Patrick. - To unsubscribe from this list: send 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] Replacing with (compare|is_zero)_ether_addr() and ETH_ALEN in pktgen.c
From: Kris Katterjohn [EMAIL PROTECTED] Date: Sun, 15 Jan 2006 19:50:47 -0800 This replaces some tests with is_zero_ether_addr(), memcmp(one, two, 6) with compare_ether_addr(one, two), and 6 with ETH_ALEN where appropriate. Signed-off-by: Kris Katterjohn [EMAIL PROTECTED] 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: IPSEC Offload
From: Dave Dillow [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 11:45:04 -0500 Would this still be interesting to anyone? If I can get a good framework in place, maybe we can get Intel to open up their cards to work with it as well. I feel like support for this is inevitable, personally. It's not a matter of if but when. - To unsubscribe from this list: send 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 Offload
On Tue, 2006-01-17 at 13:16 -0800, David S. Miller wrote: From: Dave Dillow [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 11:45:04 -0500 Would this still be interesting to anyone? If I can get a good framework in place, maybe we can get Intel to open up their cards to work with it as well. I feel like support for this is inevitable, personally. It's not a matter of if but when. In that case, I'll blow the dust off and try to make it sooner rather than later. -- Dave Dillow [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Use is_zero_ether_addr() in net/core/netpoll.c
This replaces a memcmp() with is_zero_ether_addr().
Signed-off-by: Kris Katterjohn [EMAIL PROTECTED]
Thanks!
--- x/net/core/netpoll.c2006-01-17 08:25:32.0 -0600
+++ y/net/core/netpoll.c2006-01-17 15:45:01.0 -0600
@@ -703,7 +703,7 @@ int netpoll_setup(struct netpoll *np)
}
}
- if (!memcmp(np-local_mac, \0\0\0\0\0\0, 6) ndev-dev_addr)
+ if (is_zero_ether_addr(np-local_mac) ndev-dev_addr)
memcpy(np-local_mac, ndev-dev_addr, 6);
if (!np-local_ip) {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 2.6.15] starfire: Implement suspend/resume
This patch implements suspend and resume methods for the starfire driver. It
allows me to put my desktop PC with a starfire dual board into S4.
Signed-Off-By: Stefan Rompf [EMAIL PROTECTED]
--- linux-2.6.15/drivers/net/starfire.c.orig2006-01-04 01:01:18.0
+0100
+++ linux-2.6.15/drivers/net/starfire.c 2006-01-17 22:46:53.0 +0100
@@ -2084,6 +2084,38 @@
return 0;
}
+#ifdef CONFIG_PM
+static int starfire_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+
+ if (netif_running(dev)) {
+ netif_device_detach(dev);
+ netdev_close(dev);
+ }
+
+ pci_save_state(pdev);
+ pci_set_power_state(pdev, pci_choose_state(pdev,state));
+
+ return 0;
+}
+
+static int starfire_resume(struct pci_dev *pdev)
+{
+ struct net_device *dev = pci_get_drvdata(pdev);
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+
+ if (netif_running(dev)) {
+ netdev_open(dev);
+ netif_device_attach(dev);
+ }
+
+ return 0;
+}
+#endif /* CONFIG_PM */
+
static void __devexit starfire_remove_one (struct pci_dev *pdev)
{
@@ -2115,6 +2147,10 @@
.name = DRV_NAME,
.probe = starfire_init_one,
.remove = __devexit_p(starfire_remove_one),
+#ifdef CONFIG_PM
+ .suspend= starfire_suspend,
+ .resume = starfire_resume,
+#endif /* CONFIG_PM */
.id_table = starfire_pci_tbl,
};
-
To unsubscribe from this list: send 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 00/12] sky2:
Updates to sky2 driver (based on 2.6.16-rc1). Includes previously posted 0.12 patches, which Jeff hasn't merged yet... The most important fixes are: * ram buffer initialization for Yukon FE revision A3 (88E8053) * race in transmit locking -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger - To unsubscribe from this list: send 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 08/12] sky2: ratelimit error messages
Make sure and rate limit all the error messages that might occur. If a problem
occurs then a few messages are enough.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.orig/drivers/net/sky2.c
+++ sky2-2.6/drivers/net/sky2.c
@@ -92,7 +92,7 @@
static const u32 default_msg =
NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK
| NETIF_MSG_TIMER | NETIF_MSG_TX_ERR | NETIF_MSG_RX_ERR
-| NETIF_MSG_IFUP | NETIF_MSG_IFDOWN | NETIF_MSG_INTR;
+| NETIF_MSG_IFUP | NETIF_MSG_IFDOWN;
static int debug = -1; /* defaults above */
module_param(debug, int, 0);
@@ -1125,8 +1125,9 @@ static int sky2_xmit_frame(struct sk_buf
*/
if (!netif_queue_stopped(dev)) {
netif_stop_queue(dev);
- printk(KERN_WARNING PFX %s: ring full when queue
awake!\n,
- dev-name);
+ if (net_ratelimit())
+ printk(KERN_WARNING PFX %s: ring full when
queue awake!\n,
+ dev-name);
}
spin_unlock(sky2-tx_lock);
@@ -1770,7 +1771,7 @@ oversize:
error:
++sky2-net_stats.rx_errors;
- if (netif_msg_rx_err(sky2))
+ if (netif_msg_rx_err(sky2) net_ratelimit())
printk(KERN_INFO PFX %s: rx error, status 0x%x length %d\n,
sky2-netdev-name, status, length);
@@ -1920,35 +1921,42 @@ static void sky2_hw_error(struct sky2_hw
{
struct net_device *dev = hw-dev[port];
- printk(KERN_INFO PFX %s: hw error interrupt status 0x%x\n,
- dev-name, status);
+ if (net_ratelimit())
+ printk(KERN_INFO PFX %s: hw error interrupt status 0x%x\n,
+ dev-name, status);
if (status Y2_IS_PAR_RD1) {
- printk(KERN_ERR PFX %s: ram data read parity error\n,
- dev-name);
+ if (net_ratelimit())
+ printk(KERN_ERR PFX %s: ram data read parity error\n,
+ dev-name);
/* Clear IRQ */
sky2_write16(hw, RAM_BUFFER(port, B3_RI_CTRL), RI_CLR_RD_PERR);
}
if (status Y2_IS_PAR_WR1) {
- printk(KERN_ERR PFX %s: ram data write parity error\n,
- dev-name);
+ if (net_ratelimit())
+ printk(KERN_ERR PFX %s: ram data write parity error\n,
+ dev-name);
sky2_write16(hw, RAM_BUFFER(port, B3_RI_CTRL), RI_CLR_WR_PERR);
}
if (status Y2_IS_PAR_MAC1) {
- printk(KERN_ERR PFX %s: MAC parity error\n, dev-name);
+ if (net_ratelimit())
+ printk(KERN_ERR PFX %s: MAC parity error\n,
dev-name);
sky2_write8(hw, SK_REG(port, TX_GMF_CTRL_T), GMF_CLI_TX_PE);
}
if (status Y2_IS_PAR_RX1) {
- printk(KERN_ERR PFX %s: RX parity error\n, dev-name);
+ if (net_ratelimit())
+ printk(KERN_ERR PFX %s: RX parity error\n, dev-name);
sky2_write32(hw, Q_ADDR(rxqaddr[port], Q_CSR), BMU_CLR_IRQ_PAR);
}
if (status Y2_IS_TCP_TXA1) {
- printk(KERN_ERR PFX %s: TCP segmentation error\n, dev-name);
+ if (net_ratelimit())
+ printk(KERN_ERR PFX %s: TCP segmentation error\n,
+ dev-name);
sky2_write32(hw, Q_ADDR(txqaddr[port], Q_CSR), BMU_CLR_IRQ_TCP);
}
}
@@ -1964,8 +1972,9 @@ static void sky2_hw_intr(struct sky2_hw
u16 pci_err;
pci_read_config_word(hw-pdev, PCI_STATUS, pci_err);
- printk(KERN_ERR PFX %s: pci hw error (0x%x)\n,
- pci_name(hw-pdev), pci_err);
+ if (net_ratelimit())
+ printk(KERN_ERR PFX %s: pci hw error (0x%x)\n,
+ pci_name(hw-pdev), pci_err);
sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
pci_write_config_word(hw-pdev, PCI_STATUS,
@@ -1979,8 +1988,9 @@ static void sky2_hw_intr(struct sky2_hw
pci_read_config_dword(hw-pdev, PEX_UNC_ERR_STAT, pex_err);
- printk(KERN_ERR PFX %s: pci express error (0x%x)\n,
- pci_name(hw-pdev), pex_err);
+ if (net_ratelimit())
+ printk(KERN_ERR PFX %s: pci express error (0x%x)\n,
+ pci_name(hw-pdev), pex_err);
/* clear the interrupt */
sky2_write32(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH 09/12] sky2: use kzalloc
Can use kzalloc here.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.orig/drivers/net/sky2.c
+++ sky2-2.6/drivers/net/sky2.c
@@ -3099,14 +3099,13 @@ static int __devinit sky2_probe(struct p
#endif
err = -ENOMEM;
- hw = kmalloc(sizeof(*hw), GFP_KERNEL);
+ hw = kzalloc(sizeof(*hw), GFP_KERNEL);
if (!hw) {
printk(KERN_ERR PFX %s: cannot allocate hardware struct\n,
pci_name(pdev));
goto err_out_free_regions;
}
- memset(hw, 0, sizeof(*hw));
hw-pdev = pdev;
hw-regs = ioremap_nocache(pci_resource_start(pdev, 0), 0x4000);
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send 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 04/12] sky2: fix ram buffer for Yukon FE rev 2
Fix problems with Yukon FE rev 2 chipset. Don't cut and paste bugs in from
sk98lin driver. Change how the ram buffer is divided up, and make the math
clearer. Also, set the thresholds where rx takes precedence. The threshold
values are just guesses at this point, it might be worth tuning them later.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.orig/drivers/net/sky2.c
+++ sky2-2.6/drivers/net/sky2.c
@@ -625,13 +625,16 @@ static void sky2_mac_init(struct sky2_hw
}
-static void sky2_ramset(struct sky2_hw *hw, u16 q, u32 start, size_t len)
+/* Assign Ram Buffer allocation.
+ * start and end are in units of 4k bytes
+ * ram registers are in units of 64bit words
+ */
+static void sky2_ramset(struct sky2_hw *hw, u16 q, u8 startk, u8 endk)
{
- u32 end;
+ u32 start, end;
- start /= 8;
- len /= 8;
- end = start + len - 1;
+ start = startk * 4096/8;
+ end = (endk * 4096/8) - 1;
sky2_write8(hw, RB_ADDR(q, RB_CTRL), RB_RST_CLR);
sky2_write32(hw, RB_ADDR(q, RB_START), start);
@@ -640,14 +643,19 @@ static void sky2_ramset(struct sky2_hw *
sky2_write32(hw, RB_ADDR(q, RB_RP), start);
if (q == Q_R1 || q == Q_R2) {
- u32 rxup, rxlo;
+ u32 space = (endk - startk) * 4096/8;
+ u32 tp = space - space/4;
- rxlo = len/2;
- rxup = rxlo + len/4;
+ /* On receive queue's set the thresholds
+* give receiver priority when 3/4 full
+* send pause when down to 2K
+*/
+ sky2_write32(hw, RB_ADDR(q, RB_RX_UTHP), tp);
+ sky2_write32(hw, RB_ADDR(q, RB_RX_LTHP), space/2);
- /* Set thresholds on receive queue's */
- sky2_write32(hw, RB_ADDR(q, RB_RX_UTPP), rxup);
- sky2_write32(hw, RB_ADDR(q, RB_RX_LTPP), rxlo);
+ tp = space - 2048/8;
+ sky2_write32(hw, RB_ADDR(q, RB_RX_UTPP), tp);
+ sky2_write32(hw, RB_ADDR(q, RB_RX_LTPP), space/4);
} else {
/* Enable store forward on Tx queue's because
* Tx FIFO is only 1K on Yukon
@@ -1002,19 +1010,19 @@ static int sky2_up(struct net_device *de
sky2_mac_init(hw, port);
- /* Configure RAM buffers */
- if (hw-chip_id == CHIP_ID_YUKON_FE ||
- (hw-chip_id == CHIP_ID_YUKON_EC hw-chip_rev == 2))
- ramsize = 4096;
- else {
- u8 e0 = sky2_read8(hw, B2_E_0);
- ramsize = (e0 == 0) ? (128 * 1024) : (e0 * 4096);
- }
+ /* Determine available ram buffer space (in 4K blocks).
+* Note: not sure about the FE setting below yet
+*/
+ if (hw-chip_id == CHIP_ID_YUKON_FE)
+ ramsize = 4;
+ else
+ ramsize = sky2_read8(hw, B2_E_0);
+
+ /* Give transmitter one third (rounded up) */
+ rxspace = ramsize - (ramsize + 2) / 3;
- /* 2/3 for Rx */
- rxspace = (2 * ramsize) / 3;
sky2_ramset(hw, rxqaddr[port], 0, rxspace);
- sky2_ramset(hw, txqaddr[port], rxspace, ramsize - rxspace);
+ sky2_ramset(hw, txqaddr[port], rxspace, ramsize);
/* Make sure SyncQ is disabled */
sky2_write8(hw, RB_ADDR(port == 0 ? Q_XS1 : Q_XS2, RB_CTRL),
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send 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 11/12] sky2: more conservative transmit locking
Be more careful about transmit locking, this solves a possible race
between tx_complete and transmit, that would cause a tx timeout.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-git.orig/drivers/net/sky2.c
+++ sky2-git/drivers/net/sky2.c
@@ -889,13 +889,13 @@ static void sky2_vlan_rx_register(struct
struct sky2_hw *hw = sky2-hw;
u16 port = sky2-port;
- spin_lock(sky2-tx_lock);
+ spin_lock_bh(sky2-tx_lock);
sky2_write32(hw, SK_REG(port, RX_GMF_CTRL_T), RX_VLAN_STRIP_ON);
sky2_write32(hw, SK_REG(port, TX_GMF_CTRL_T), TX_VLAN_TAG_ON);
sky2-vlgrp = grp;
- spin_unlock(sky2-tx_lock);
+ spin_unlock_bh(sky2-tx_lock);
}
static void sky2_vlan_rx_kill_vid(struct net_device *dev, unsigned short vid)
@@ -904,14 +904,14 @@ static void sky2_vlan_rx_kill_vid(struct
struct sky2_hw *hw = sky2-hw;
u16 port = sky2-port;
- spin_lock(sky2-tx_lock);
+ spin_lock_bh(sky2-tx_lock);
sky2_write32(hw, SK_REG(port, RX_GMF_CTRL_T), RX_VLAN_STRIP_OFF);
sky2_write32(hw, SK_REG(port, TX_GMF_CTRL_T), TX_VLAN_TAG_OFF);
if (sky2-vlgrp)
sky2-vlgrp-vlan_devices[vid] = NULL;
- spin_unlock(sky2-tx_lock);
+ spin_unlock_bh(sky2-tx_lock);
}
#endif
@@ -1116,6 +1116,10 @@ static int sky2_xmit_frame(struct sk_buf
u16 mss;
u8 ctrl;
+ /* No BH disabling for tx_lock here. We are running in BH disabled
+* context and TX reclaim runs via poll inside of a software
+* interrupt, and no related locks in IRQ processing.
+*/
if (!spin_trylock(sky2-tx_lock))
return NETDEV_TX_LOCKED;
@@ -1308,17 +1312,17 @@ static void sky2_tx_complete(struct sky2
dev_kfree_skb_any(skb);
}
- spin_lock(sky2-tx_lock);
sky2-tx_cons = put;
if (netif_queue_stopped(dev) tx_avail(sky2) MAX_SKB_TX_LE)
netif_wake_queue(dev);
- spin_unlock(sky2-tx_lock);
}
/* Cleanup all untransmitted buffers, assume transmitter not running */
static void sky2_tx_clean(struct sky2_port *sky2)
{
+ spin_lock_bh(sky2-tx_lock);
sky2_tx_complete(sky2, sky2-tx_prod);
+ spin_unlock_bh(sky2-tx_lock);
}
/* Network shutdown */
@@ -1608,28 +1612,40 @@ out:
local_irq_enable();
}
+
+/* Transmit timeout is only called if we are running, carries is up
+ * and tx queue is full (stopped).
+ */
static void sky2_tx_timeout(struct net_device *dev)
{
struct sky2_port *sky2 = netdev_priv(dev);
struct sky2_hw *hw = sky2-hw;
unsigned txq = txqaddr[sky2-port];
+ u16 ridx;
+
+ /* Maybe we just missed an status interrupt */
+ spin_lock(sky2-tx_lock);
+ ridx = sky2_read16(hw,
+ sky2-port == 0 ? STAT_TXA1_RIDX : STAT_TXA2_RIDX);
+ sky2_tx_complete(sky2, ridx);
+ spin_unlock(sky2-tx_lock);
+
+ if (!netif_queue_stopped(dev)) {
+ if (net_ratelimit())
+ pr_info(PFX transmit interrupt missed? recovered\n);
+ return;
+ }
if (netif_msg_timer(sky2))
printk(KERN_ERR PFX %s: tx timeout\n, dev-name);
- netif_stop_queue(dev);
-
sky2_write32(hw, Q_ADDR(txq, Q_CSR), BMU_STOP);
- sky2_read32(hw, Q_ADDR(txq, Q_CSR));
-
sky2_write32(hw, Y2_QADDR(txq, PREF_UNIT_CTRL), PREF_UNIT_RST_SET);
sky2_tx_clean(sky2);
sky2_qset(hw, txq);
sky2_prefetch_init(hw, txq, sky2-tx_le_map, TX_RING_SIZE - 1);
-
- netif_wake_queue(dev);
}
@@ -1798,7 +1814,10 @@ static void sky2_tx_check(struct sky2_hw
struct net_device *dev = hw-dev[port];
if (dev netif_running(dev)) {
struct sky2_port *sky2 = netdev_priv(dev);
+
+ spin_lock(sky2-tx_lock);
sky2_tx_complete(sky2, last);
+ spin_unlock(sky2-tx_lock);
}
}
}
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send 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 06/12] sky2: don't bother clearing status ring elements
Don't need to zero out the status ring entries after processing.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.orig/drivers/net/sky2.c
+++ sky2-2.6/drivers/net/sky2.c
@@ -1825,7 +1825,6 @@ static int sky2_poll(struct net_device *
struct sk_buff *skb;
u32 status;
u16 length;
- u8 op;
le = hw-st_le + hw-st_idx;
hw-st_idx = (hw-st_idx + 1) % STATUS_RING_SIZE;
@@ -1839,10 +1838,8 @@ static int sky2_poll(struct net_device *
sky2 = netdev_priv(dev);
status = le32_to_cpu(le-status);
length = le16_to_cpu(le-length);
- op = le-opcode ~HW_OWNER;
- le-opcode = 0;
- switch (op) {
+ switch (le-opcode ~HW_OWNER) {
case OP_RXSTAT:
skb = sky2_receive(sky2, length, status);
if (!skb)
@@ -1890,7 +1887,7 @@ static int sky2_poll(struct net_device *
default:
if (net_ratelimit())
printk(KERN_WARNING PFX
- unknown status opcode 0x%x\n, op);
+ unknown status opcode 0x%x\n,
le-opcode);
break;
}
}
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send 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 01/12] sky2: receive buffer alignment
Need to make sure that sky2 receive buffers are 64 bit
aligned. Also, don't need to start off with GFP_ATOMIC
on initial setup.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- netdev-2.6.orig/drivers/net/sky2.c
+++ netdev-2.6/drivers/net/sky2.c
@@ -75,6 +75,7 @@
#define RX_LE_BYTES(RX_LE_SIZE*sizeof(struct sky2_rx_le))
#define RX_MAX_PENDING (RX_LE_SIZE/2 - 2)
#define RX_DEF_PENDING RX_MAX_PENDING
+#define RX_SKB_ALIGN 8
#define TX_RING_SIZE 512
#define TX_DEF_PENDING (TX_RING_SIZE - 1)
@@ -905,15 +906,30 @@ static void sky2_vlan_rx_kill_vid(struct
#endif
/*
+ * It appears the hardware has a bug in the FIFO logic that
+ * cause it to hang if the FIFO gets overrun and the receive buffer
+ * is not aligned. ALso alloc_skb() won't align properly if slab
+ * debugging is enabled.
+ */
+static inline struct sk_buff *sky2_alloc_skb(unsigned int size, gfp_t gfp_mask)
+{
+ struct sk_buff *skb;
+
+ skb = alloc_skb(size + RX_SKB_ALIGN, gfp_mask);
+ if (likely(skb)) {
+ unsigned long p = (unsigned long) skb-data;
+ skb_reserve(skb,
+ ((p + RX_SKB_ALIGN - 1) ~(RX_SKB_ALIGN - 1)) - p);
+ }
+
+ return skb;
+}
+
+/*
* Allocate and setup receiver buffer pool.
* In case of 64 bit dma, there are 2X as many list elements
* available as ring entries
* and need to reserve one list element so we don't wrap around.
- *
- * It appears the hardware has a bug in the FIFO logic that
- * cause it to hang if the FIFO gets overrun and the receive buffer
- * is not aligned. This means we can't use skb_reserve to align
- * the IP header.
*/
static int sky2_rx_start(struct sky2_port *sky2)
{
@@ -929,7 +945,7 @@ static int sky2_rx_start(struct sky2_por
for (i = 0; i sky2-rx_pending; i++) {
struct ring_info *re = sky2-rx_ring + i;
- re-skb = dev_alloc_skb(sky2-rx_bufsize);
+ re-skb = sky2_alloc_skb(sky2-rx_bufsize, GFP_KERNEL);
if (!re-skb)
goto nomem;
@@ -1713,7 +1729,7 @@ static struct sk_buff *sky2_receive(stru
} else {
struct sk_buff *nskb;
- nskb = dev_alloc_skb(sky2-rx_bufsize);
+ nskb = sky2_alloc_skb(sky2-rx_bufsize, GFP_ATOMIC);
if (!nskb)
goto resubmit;
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send 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 12/12] sky2: 0.13 version
--- sky2-git.orig/drivers/net/sky2.c +++ sky2-git/drivers/net/sky2.c @@ -57,7 +57,7 @@ #include sky2.h #define DRV_NAME sky2 -#define DRV_VERSION0.12 +#define DRV_VERSION0.13 #define PFXDRV_NAME /* -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger - To unsubscribe from this list: send 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 07/12] sky2: optimize for 32 bit dma
Small optimization, if dma addresses are 32 bits, then high
bits are always zero.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.orig/drivers/net/sky2.c
+++ sky2-2.6/drivers/net/sky2.c
@@ -745,7 +745,7 @@ static inline struct sky2_rx_le *sky2_ne
/* Return high part of DMA address (could be 32 or 64 bit) */
static inline u32 high32(dma_addr_t a)
{
- return (a 16) 16;
+ return sizeof(a) sizeof(u32) ? (a 16) 16 : 0;
}
/* Build description to hardware about buffer */
@@ -1225,7 +1225,7 @@ static int sky2_xmit_frame(struct sk_buf
mapping = pci_map_page(hw-pdev, frag-page, frag-page_offset,
frag-size, PCI_DMA_TODEVICE);
- addr64 = (mapping 16) 16;
+ addr64 = high32(mapping);
if (addr64 != sky2-tx_addr64) {
le = get_tx_le(sky2);
le-tx.addr = cpu_to_le32(addr64);
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send 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 10/12] sky2: don't inline so much
Don't need to inline quite so many routines, let the compiler
decide
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.orig/drivers/net/sky2.c
+++ sky2-2.6/drivers/net/sky2.c
@@ -704,7 +704,7 @@ static inline struct sky2_tx_le *get_tx_
* This is a workaround code taken from SysKonnect sk98lin driver
* to deal with chip bug on Yukon EC rev 0 in the wraparound case.
*/
-static inline void sky2_put_idx(struct sky2_hw *hw, unsigned q,
+static void sky2_put_idx(struct sky2_hw *hw, unsigned q,
u16 idx, u16 *last, u16 size)
{
wmb();
@@ -749,7 +749,7 @@ static inline u32 high32(dma_addr_t a)
}
/* Build description to hardware about buffer */
-static inline void sky2_rx_add(struct sky2_port *sky2, dma_addr_t map)
+static void sky2_rx_add(struct sky2_port *sky2, dma_addr_t map)
{
struct sky2_rx_le *le;
u32 hi = high32(map);
@@ -1080,7 +1080,7 @@ static inline int tx_avail(const struct
}
/* Estimate of number of transmit list elements required */
-static inline unsigned tx_le_req(const struct sk_buff *skb)
+static unsigned tx_le_req(const struct sk_buff *skb)
{
unsigned count;
@@ -1792,7 +1792,7 @@ error:
*/
#define TX_NO_STATUS 0x
-static inline void sky2_tx_check(struct sky2_hw *hw, int port, u16 last)
+static void sky2_tx_check(struct sky2_hw *hw, int port, u16 last)
{
if (last != TX_NO_STATUS) {
struct net_device *dev = hw-dev[port];
@@ -2280,7 +2280,7 @@ static int sky2_reset(struct sky2_hw *hw
return 0;
}
-static inline u32 sky2_supported_modes(const struct sky2_hw *hw)
+static u32 sky2_supported_modes(const struct sky2_hw *hw)
{
u32 modes;
if (hw-copper) {
@@ -3025,7 +3025,7 @@ static __devinit struct net_device *sky2
return dev;
}
-static inline void sky2_show_addr(struct net_device *dev)
+static void __devinit sky2_show_addr(struct net_device *dev)
{
const struct sky2_port *sky2 = netdev_priv(dev);
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send 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 02/12] sky2: call pci_set_consistent_dma_mask
Need to call pci_set_consistent_dma_mask in the case of 64 bit
DMA.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- netdev-2.6.orig/drivers/net/sky2.c
+++ netdev-2.6/drivers/net/sky2.c
@@ -3054,13 +3054,17 @@ static int __devinit sky2_probe(struct p
goto err_out_free_regions;
}
- if (sizeof(dma_addr_t) sizeof(u32)) {
- err = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
- if (!err)
- using_dac = 1;
- }
+ if (sizeof(dma_addr_t) sizeof(u32)
+ !(err = pci_set_dma_mask(pdev, DMA_64BIT_MASK))) {
+ using_dac = 1;
+ err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
+ if (err 0) {
+ printk(KERN_ERR PFX %s unable to obtain 64 bit DMA
+ for consistent allocations\n, pci_name(pdev));
+ goto err_out_free_regions;
+ }
- if (!using_dac) {
+ } else {
err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
if (err) {
printk(KERN_ERR PFX %s no usable DMA configuration\n,
@@ -3068,6 +3072,7 @@ static int __devinit sky2_probe(struct p
goto err_out_free_regions;
}
}
+
#ifdef __BIG_ENDIAN
/* byte swap descriptors in hardware */
{
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send 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 05/12] sky2: write barrier's
Be more careful about memory barriers. The only place we really
need them is before and after updating the chip's ring interface.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.orig/drivers/net/sky2.c
+++ sky2-2.6/drivers/net/sky2.c
@@ -707,6 +707,7 @@ static inline struct sky2_tx_le *get_tx_
static inline void sky2_put_idx(struct sky2_hw *hw, unsigned q,
u16 idx, u16 *last, u16 size)
{
+ wmb();
if (is_ec_a1(hw) idx *last) {
u16 hwget = sky2_read16(hw, Y2_QADDR(q, PREF_UNIT_GET_IDX));
@@ -730,6 +731,7 @@ setnew:
sky2_write16(hw, Y2_QADDR(q, PREF_UNIT_PUT_IDX), idx);
}
*last = idx;
+ mmiowb();
}
@@ -1253,7 +1255,6 @@ static int sky2_xmit_frame(struct sk_buf
netif_stop_queue(dev);
out_unlock:
- mmiowb();
spin_unlock(sky2-tx_lock);
dev-trans_start = jiffies;
@@ -1896,7 +1897,6 @@ static int sky2_poll(struct net_device *
exit_loop:
sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
- mmiowb();
sky2_tx_check(hw, 0, tx_done[0]);
sky2_tx_check(hw, 1, tx_done[1]);
@@ -1911,7 +1911,6 @@ exit_loop:
netif_rx_complete(dev0);
hw-intr_mask |= Y2_IS_STAT_BMU;
sky2_write32(hw, B0_IMSK, hw-intr_mask);
- mmiowb();
return 0;
} else {
*budget -= work_done;
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send 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: State of the Union: Wireless / 802.11 master device
Am Dienstag 17 Januar 2006 20:42 schrieb Jouni Malinen: Sure, you can do it that way, too. However, this is not the only use. I just remembered another one: QoS. Devicescape 802.11 code uses a qdisc on the master interface to take care of determining which hardware TX queue to use with WMM (which uses four different TX queues). so after all, it should be an implementation detail whether our master device is a struct net_device or not, depending on how much infrastructure of the networking core we need at this point. Stefan - To unsubscribe from this list: send 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: State of the Union: Wireless / 802.11 master device
On Tue, 17 Jan 2006 23:16:43 +0100 Stefan Rompf [EMAIL PROTECTED] wrote: Am Dienstag 17 Januar 2006 20:42 schrieb Jouni Malinen: Sure, you can do it that way, too. However, this is not the only use. I just remembered another one: QoS. Devicescape 802.11 code uses a qdisc on the master interface to take care of determining which hardware TX queue to use with WMM (which uses four different TX queues). so after all, it should be an implementation detail whether our master device is a struct net_device or not, depending on how much infrastructure of the networking core we need at this point. Stefan What ever it is, it needs to be a kobject, to allow for sysfs to work. Also, please make it hot removable (like netdevices) so module can be unloaded at any time (independent of ref counts). Look at bonding, bridging, and VLAN to see how layered devices can work. -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger - To unsubscribe from this list: send 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: wireless: recap of current issues (configuration)
Am Sonntag 15 Januar 2006 21:11 schrieb Johannes Berg: [iwconfig mode ...] Yeah, I agree with this, it is much cleaner to handle in the kernel. Think about the issues if you have a struct net_device that has 250 bytes of payload for the struct virtual_sta_device in it and you want to switch that to a struct virtual_monitor_device. Icky. Well, nobody forces you to allocate dev-priv together with the net_device, you can set and change this pointer yourself. So I don't see a problem here. Stefan - To unsubscribe from this list: send 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: 2.6 patch] remove drivers/net/eepro100.c
We don't of any problems reported against e100 that have not been talked about in this thread (in old ARCH types). I think the eepro100 driver should be removed from the config just in case but we are in full support of the e100 driver and if somebody says that it's not working on one of the different ARCHs we are willing to work with them to get it fixed. The problem is that we don't have all these different ARCH systems around to test against. Another thing is that removal of the driver (or disabling the config) will hopefully force the issue in that people with these ARCHs will use the e100 and if they have problems we can get them fixed in the e100 driver. At this point nobody seems to be able to define a real problem other than talking about it. -- Cheers, John - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
NIP6_FMT breaks ifconfig
The use of NIP6_FMT from kernel.h in net/ipv6/addrconf.c changes how / proc/net/if_inet6 format's IPv6 addresses and thus breaks ifconfig's ability to display IPv6 addresses. I'm not sure if this is acceptable breakage of a userspace app or not. - kumar - To unsubscribe from this list: send 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 ] ethtool: Remove duplex info from CTRL register dump
applied, after replacing ethtool: with e1000: in the subject line. Even if it's modifying the ethtool app? As long as it doesn't confuse your scripts, I suppose. -Jeb - To unsubscribe from this list: send 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: wireless: recap of current issues (stack)
Am Dienstag 17 Januar 2006 19:37 schrieb Jirka Bohac: - DeviceScape can be there so it can be polished and new drivers can start using it. - ieee80211 could be there with a big fat warning that it will go away soon, just to allow ipw2x00 to work while DeviceScape and the ipw2x00 port for it to be stabilized. Isnt't this a viable option? As I was the one who tried porting ipw2100 to devicescape, I can tell you that it isn't that easy. Both stacks require major surgery to be really generic. Devicescape doesn't support cards with firmware, e.g. ipw2100. ieee80211 on the other hand is far away from supporting multiple associations or access point and is putting way too much kernel interface burden on the driver writer. At this point, it's too early to decide what stack to enhance, we need to discuss our requirements first, then API between stack and device driver. Then we can choose one stack as primary development target. Stefan - To unsubscribe from this list: send 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: TIPC needs some cleanup
From: Andi Kleen [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 21:42:38 +0100 On Tuesday 17 January 2006 21:31, jamal wrote: the TIPC tree has been open for months now for review. That is not how Linux code review works - the code is supposed to get posted to the appropiate mailing lists so that people can go over it. Reviewers normally don't hunt for random websites to look at code there. I agree with Andi, TIPC should have been submitted as a set of patches or a pointer to such, on netdev before going in. I take the blame for this, as I didn't enforce this procedure for the TIPC folks and I definitely should have. So let's clean it up and I'll be more mindful to not sidestep this in the future. Andi, thanks for calling a spade a spade. It definitely was in this case. TIPC went through the back door and that's totally unacceptable. - To unsubscribe from this list: send 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 RESEND netdev-2.6 3/3] e100: e100 whitespace fixes
e100: e100 whitespace fixes
These are whitespace only fixes.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Jeff Kirsher [EMAIL PROTECTED]
Signed-off-by: John Ronciak [EMAIL PROTECTED]
---
drivers/net/e100.c | 74 ++--
1 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -1,25 +1,25 @@
/***
-
+
Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
-
- This program is free software; you can redistribute it and/or modify it
- under the terms of the GNU General Public License as published by the Free
- Software Foundation; either version 2 of the License, or (at your option)
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your option)
any later version.
-
- This program is distributed in the hope that it will be useful, but WITHOUT
- ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+
+ This program is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
-
+
You should have received a copy of the GNU General Public License along with
- this program; if not, write to the Free Software Foundation, Inc., 59
+ this program; if not, write to the Free Software Foundation, Inc., 59
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-
+
The full GNU General Public License is included in this distribution in the
file called LICENSE.
-
+
Contact Information:
Linux NICS [EMAIL PROTECTED]
Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
@@ -320,7 +320,7 @@ enum cuc_dump {
cuc_dump_complete = 0xA005,
cuc_dump_reset_complete = 0xA007,
};
-
+
enum port {
software_reset = 0x,
selftest= 0x0001,
@@ -715,10 +715,10 @@ static u16 e100_eeprom_read(struct nic *
ctrl = (cmd_addr_data (1 i)) ? eecs | eedi : eecs;
writeb(ctrl, nic-csr-eeprom_ctrl_lo);
e100_write_flush(nic); udelay(4);
-
+
writeb(ctrl | eesk, nic-csr-eeprom_ctrl_lo);
e100_write_flush(nic); udelay(4);
-
+
/* Eeprom drives a dummy zero to EEDO after receiving
* complete address. Use this to adjust addr_len. */
ctrl = readb(nic-csr-eeprom_ctrl_lo);
@@ -726,7 +726,7 @@ static u16 e100_eeprom_read(struct nic *
*addr_len -= (i - 16);
i = 17;
}
-
+
data = (data 1) | (ctrl eedo ? 1 : 0);
}
@@ -1213,13 +1213,13 @@ static void e100_setup_ucode(struct nic
* driver can change the algorithm.
*
* INTDELAY - This loads the dead-man timer with its inital value.
-*When this timer expires the interrupt is asserted, and the
+*When this timer expires the interrupt is asserted, and the
*timer is reset each time a new packet is received. (see
*BUNDLEMAX below to set the limit on number of chained packets)
*The current default is 0x600 or 1536. Experiments show that
*the value should probably stay within the 0x200 - 0x1000.
*
-* BUNDLEMAX -
+* BUNDLEMAX -
*This sets the maximum number of frames that will be bundled. In
*some situations, such as the TCP windowing algorithm, it may be
*better to limit the growth of the bundle size than let it go as
@@ -1229,7 +1229,7 @@ static void e100_setup_ucode(struct nic
*an interrupt for every frame received. If you do not want to put
*a limit on the bundle size, set this value to x.
*
-* BUNDLESMALL -
+* BUNDLESMALL -
*This contains a bit-mask describing the minimum size frame that
*will be bundled. The default masks the lower 7 bits, which means
*that any frame less than 128 bytes in length will not be bundled,
@@ -1244,7 +1244,7 @@ static void e100_setup_ucode(struct nic
*
*The current default is 0xFF80, which masks out the lower 7 bits.
*This means that any frame which is x7F (127) bytes or smaller
-*will cause an immediate interrupt. Because this value must be a
+*will cause an immediate interrupt. Because this value must be a
*bit mask, there are only a few valid values that can be used. To
*turn this feature off, the driver can write the value x to the
*lower word of this instruction (in the
[PATCH RESEND netdev-2.6 1/3] e100: Fix TX hang and RMCP Ping issue (due to a microcode loading issue)
e100: Fix TX hang and RMCP Ping issue (due to a microcode loading issue)
Set the end of list bit to cause the hardware's transmit state machine to
work correctly and not prevent management (BMC) traffic.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Jeff Kirsher [EMAIL PROTECTED]
Signed-off-by: John Ronciak [EMAIL PROTECTED]
---
drivers/net/e100.c | 44 +++-
1 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -160,7 +160,7 @@
#define DRV_NAME e100
#define DRV_EXT-NAPI
-#define DRV_VERSION3.4.14-k4DRV_EXT
+#define DRV_VERSION3.5.10-k2DRV_EXT
#define DRV_DESCRIPTIONIntel(R) PRO/100 Network Driver
#define DRV_COPYRIGHT Copyright(c) 1999-2005 Intel Corporation
#define PFXDRV_NAME :
@@ -1170,7 +1170,7 @@ static void e100_configure(struct nic *n
0x, 0x, 0x, 0x, \
}
-static void e100_load_ucode(struct nic *nic, struct cb *cb, struct sk_buff
*skb)
+static void e100_setup_ucode(struct nic *nic, struct cb *cb, struct sk_buff
*skb)
{
/* *INDENT-OFF* */
static struct {
@@ -1284,12 +1284,46 @@ static void e100_load_ucode(struct nic *
for (i = 0; i UCODE_SIZE; i++)
cb-u.ucode[i] = cpu_to_le32(ucode[i]);
- cb-command = cpu_to_le16(cb_ucode);
+ cb-command = cpu_to_le16(cb_ucode | cb_el);
return;
}
noloaducode:
- cb-command = cpu_to_le16(cb_nop);
+ cb-command = cpu_to_le16(cb_nop | cb_el);
+}
+
+static inline int e100_exec_cb_wait(struct nic *nic, struct sk_buff *skb,
+ void (*cb_prepare)(struct nic *, struct cb *, struct sk_buff *))
+{
+ int err = 0, counter = 50;
+ struct cb *cb = nic-cb_to_clean;
+
+ if ((err = e100_exec_cb(nic, NULL, e100_setup_ucode)))
+ DPRINTK(PROBE,ERR, ucode cmd failed with error %d\n, err);
+
+ /* must restart cuc */
+ nic-cuc_cmd = cuc_start;
+
+ /* wait for completion */
+ e100_write_flush(nic);
+ udelay(10);
+
+ /* wait for possibly (ouch) 500ms */
+ while (!(cb-status cpu_to_le16(cb_complete))) {
+ msleep(10);
+ if (!--counter) break;
+ }
+
+ /* ack any interupts, something could have been set */
+ writeb(~0, nic-csr-scb.stat_ack);
+
+ /* if the command failed, or is not OK, notify and return */
+ if (!counter || !(cb-status cpu_to_le16(cb_ok))) {
+ DPRINTK(PROBE,ERR, ucode load failed\n);
+ err = -EPERM;
+ }
+
+ return err;
}
static void e100_setup_iaaddr(struct nic *nic, struct cb *cb,
@@ -1388,7 +1422,7 @@ static int e100_hw_init(struct nic *nic)
return err;
if((err = e100_exec_cmd(nic, ruc_load_base, 0)))
return err;
- if((err = e100_exec_cb(nic, NULL, e100_load_ucode)))
+ if ((err = e100_exec_cb_wait(nic, NULL, e100_setup_ucode)))
return err;
if((err = e100_exec_cb(nic, NULL, e100_configure)))
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
[PATCH RESEND netdev-2.6 2/3] e100: Handle the return values from pci_* functions
e100: Handle the return values from pci_* functions
This is to resolve warnings during compile time.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Jeff Kirsher [EMAIL PROTECTED]
Signed-off-by: John Ronciak [EMAIL PROTECTED]
---
drivers/net/e100.c | 30 +++---
1 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2665,7 +2665,9 @@ static int __devinit e100_probe(struct p
nic-flags |= wol_magic;
/* ack any pending wake events, disable PME */
- pci_enable_wake(pdev, 0, 0);
+ err = pci_enable_wake(pdev, 0, 0);
+ if (err)
+ DPRINTK(PROBE, ERR, Error clearing wake event\n);
strcpy(netdev-name, eth%d);
if((err = register_netdev(netdev))) {
@@ -2716,6 +2718,7 @@ static int e100_suspend(struct pci_dev *
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
+ int retval;
if(netif_running(netdev))
e100_down(nic);
@@ -2723,9 +2726,14 @@ static int e100_suspend(struct pci_dev *
netif_device_detach(netdev);
pci_save_state(pdev);
- pci_enable_wake(pdev, pci_choose_state(pdev, state), nic-flags
(wol_magic | e100_asf(nic)));
+ retval = pci_enable_wake(pdev, pci_choose_state(pdev, state),
+nic-flags (wol_magic | e100_asf(nic)));
+ if (retval)
+ DPRINTK(PROBE,ERR, Error enabling wake\n);
pci_disable_device(pdev);
- pci_set_power_state(pdev, pci_choose_state(pdev, state));
+ retval = pci_set_power_state(pdev, pci_choose_state(pdev, state));
+ if (retval)
+ DPRINTK(PROBE,ERR, Error %d setting power state\n, retval);
return 0;
}
@@ -2734,11 +2742,16 @@ static int e100_resume(struct pci_dev *p
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
+ int retval;
- pci_set_power_state(pdev, PCI_D0);
+ retval = pci_set_power_state(pdev, PCI_D0);
+ if (retval)
+ DPRINTK(PROBE,ERR, Error waking adapter\n);
pci_restore_state(pdev);
/* ack any pending wake events, disable PME */
- pci_enable_wake(pdev, 0, 0);
+ retval = pci_enable_wake(pdev, 0, 0);
+ if (retval)
+ DPRINTK(PROBE,ERR, Error clearing wake events\n);
if(e100_hw_init(nic))
DPRINTK(HW, ERR, e100_hw_init failed\n);
@@ -2755,12 +2768,15 @@ static void e100_shutdown(struct pci_dev
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
+ int retval;
#ifdef CONFIG_PM
- pci_enable_wake(pdev, 0, nic-flags (wol_magic | e100_asf(nic)));
+ retval = pci_enable_wake(pdev, 0, nic-flags (wol_magic |
e100_asf(nic)));
#else
- pci_enable_wake(pdev, 0, nic-flags (wol_magic));
+ retval = pci_enable_wake(pdev, 0, nic-flags (wol_magic));
#endif
+ if (retval)
+ DPRINTK(PROBE,ERR, Error enabling wake\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
[PATCH RESEND netdev-2.6 0/3] e100: driver updates
I'm actually getting better at this, really, no, really... This patch set is against linus-2.6 repository updated today e100 driver update 1. Fix TX hang and RMCP Ping issue (due to a microcode loading issue) 2. Handle the return values from pci_* functions 3. e100 whitespace fixes - To unsubscribe from this list: send 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: NIP6_FMT breaks ifconfig
From: Kumar Gala [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 16:35:01 -0600 The use of NIP6_FMT from kernel.h in net/ipv6/addrconf.c changes how / proc/net/if_inet6 format's IPv6 addresses and thus breaks ifconfig's ability to display IPv6 addresses. I'm not sure if this is acceptable breakage of a userspace app or not. I know, I have a fix from Yoshifuji in my tree and I'll make sure Linus gets it. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TIPC needs some cleanup
On Tue, 17 Jan 2006 14:55:10 -0800 (PST) David S. Miller [EMAIL PROTECTED] wrote: From: Andi Kleen [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 21:42:38 +0100 On Tuesday 17 January 2006 21:31, jamal wrote: the TIPC tree has been open for months now for review. That is not how Linux code review works - the code is supposed to get posted to the appropiate mailing lists so that people can go over it. Reviewers normally don't hunt for random websites to look at code there. I agree with Andi, TIPC should have been submitted as a set of patches or a pointer to such, on netdev before going in. I take the blame for this, as I didn't enforce this procedure for the TIPC folks and I definitely should have. So let's clean it up and I'll be more mindful to not sidestep this in the future. Andi, thanks for calling a spade a spade. It definitely was in this case. TIPC went through the back door and that's totally unacceptable. Also, let's work with the current code. It is a lot easier to let others clean it up, if the changes are against the mainline (or -mm) rather than having to send it off to get put into yet another git repo. -- Stephen Hemminger [EMAIL PROTECTED] OSDL http://developer.osdl.org/~shemminger - To unsubscribe from this list: send 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: TIPC needs some cleanup
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 15:04:34 -0800 Also, let's work with the current code. It is a lot easier to let others clean it up, if the changes are against the mainline (or -mm) rather than having to send it off to get put into yet another git repo. I totally agree. - To unsubscribe from this list: send 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] Use is_zero_ether_addr() in net/core/netpoll.c
From: Kris Katterjohn [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 13:51:11 -0800 This replaces a memcmp() with is_zero_ether_addr(). Signed-off-by: Kris Katterjohn [EMAIL PROTECTED] Applied, thanks Kris. - To unsubscribe from this list: send 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] Remove MANY unneeded header files in net/core/filter.c
From: Kris Katterjohn [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 09:03:22 -0800 Are there any headers I'm deleting that _should_ be there, but not necessarily required for a clean compilation? If so, let me know and I'll redo the patch. If the build still works, that doesn't mean much :-) Often you get the necessary headers by accident through another header you are actually including. The only tried and true way to go about this is to really look at what interfaces and data types the whole C file uses and make sure the necessary headers are there. Other folks take another approach, wherein you pick a specific header file or interface, and walk over the tree making sure the header is used where it is needed and only where it is needed. It would be nice to automate this, but that's not easy. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES] SCTP bugfixes for 2.6.16
Dave, Please pull the following SCTP bugfixes from master.kernel.org:/pub/scm/linux/kernel/git/sridhar/lksctp-2.6.git Thanks Sridhar include/net/sctp/sctp.h|2 + include/net/sctp/structs.h | 89 +--- net/sctp/input.c | 73 ++-- net/sctp/inqueue.c |4 +- net/sctp/proc.c| 32 ++-- net/sctp/sm_make_chunk.c | 16 ++-- net/sctp/sm_sideeffect.c |4 +- net/sctp/sm_statefuns.c|2 + net/sctp/socket.c |6 ++- net/sctp/sysctl.c |7 +-- net/sctp/transport.c |2 - 11 files changed, 154 insertions(+), 83 deletions(-) commit a7d1f1b66c05ef4ebb58a34be7caad9af15546a4 Author: Tsutomu Fujii [EMAIL PROTECTED] Date: Tue Jan 17 11:57:09 2006 -0800 [SCTP]: Fix sctp_rcv_ootb() to handle the last chunk of a packet correctly. Signed-off-by: Tsutomu Fujii [EMAIL PROTECTED] Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] commit c4d2444e992c4eda1d7fc3287e93ba58295bf6b9 Author: Sridhar Samudrala [EMAIL PROTECTED] Date: Tue Jan 17 11:56:26 2006 -0800 [SCTP]: Fix couple of races between sctp_peeloff() and sctp_rcv(). Validate and update the sk in sctp_rcv() to avoid the race where an assoc/ep could move to a different socket after we get the sk, but before the skb is added to the backlog. Also migrate the skb's in backlog queue to new sk when doing a peeloff. Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] commit 313e7b4d2588539e388d31c1febd50503a0083fc Author: Vlad Yasevich [EMAIL PROTECTED] Date: Tue Jan 17 11:55:57 2006 -0800 [SCTP]: Fix machine check/connection hang on IA64. sctp_unpack_cookie used an on-stack array called digest as a result/out parameter in the call to crypto_hmac. However, hmac code (crypto_hmac_final) assumes that the 'out' argument is in virtual memory (identity mapped region) and can use virt_to_page call on it. This does not work with the on-stack declared digest. The problems observed so far have been: a) incorrect hmac digest b) machine check and hardware reset. Solution is to define the digest in an identity mapped region by kmalloc'ing it. We can do this once as part of the endpoint structure and re-use it when verifying the SCTP cookie. Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] commit 8116ffad4180b39d7a755345c1fde09da83930c0 Author: Vlad Yasevich [EMAIL PROTECTED] Date: Tue Jan 17 11:55:17 2006 -0800 [SCTP]: Fix bad sysctl formatting of SCTP timeout values on 64-bit m/cs. Change all the structure members that hold jiffies to be of type unsigned long. This also corrects bad sysctl formating on 64 bit architectures. Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] commit 38b0e42aba928d9929a26ec23b850c36a31fca5f Author: Vlad Yasevich [EMAIL PROTECTED] Date: Tue Jan 17 11:54:06 2006 -0800 [SCTP]: Fix sctp_assoc_seq_show() panics on big-endian systems. This patch corrects the panic by casting the argument to the pointer of correct size. On big-endian systems we ended up loading only 32 bits of data because we are treating the pointer as an int*. By treating this pointer as loff_t*, we'll load the full 64 bits and then let regular integer demotion take place which will give us the correct value. Signed-off-by: Vlad Yaseivch [EMAIL PROTECTED] Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] commit 49392e5ecf608da6770fd8723b534a0fc851edc4 Author: Vlad Yasevich [EMAIL PROTECTED] Date: Tue Jan 17 11:53:06 2006 -0800 [SCTP]: sctp doesn't show all associations/endpoints in /proc When creating a very large number of associations (and endpoints), /proc/assocs and /proc/eps will not show all of them. As a result netstat will not show all of the either. This is particularly evident when creating 1000+ associations (or endpoints). As an example with 1500 tcp style associations over loopback, netstat showed 1420 on my system instead of 3000. The reason for this is that the seq_operations start method is invoked multiple times bacause of the amount of data that is provided. The start method always increments the position parameter and since we use the position as the hash bucket id, we end up skipping hash buckets. This patch corrects this situation and get's rid of the silly hash-1 decrement. Signed-off-by: Vlad Yasevich [EMAIL PROTECTED] Signed-off-by: Sridhar Samudrala [EMAIL PROTECTED] commit 9834a2bb4970547540222fcba04e0a37d04cb0a0 Author: Vlad Yasevich [EMAIL PROTECTED] Date: Tue Jan 17 11:52:12 2006 -0800 [SCTP]: Fix sctp_cookie alignment in the packet. On 64 bit
Re: NIP6_FMT breaks ifconfig
On Jan 17, 2006, at 5:05 PM, David S. Miller wrote: From: Kumar Gala [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 16:35:01 -0600 The use of NIP6_FMT from kernel.h in net/ipv6/addrconf.c changes how / proc/net/if_inet6 format's IPv6 addresses and thus breaks ifconfig's ability to display IPv6 addresses. I'm not sure if this is acceptable breakage of a userspace app or not. I know, I have a fix from Yoshifuji in my tree and I'll make sure Linus gets it. Cool. thanks - k - To unsubscribe from this list: send 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: wireless: recap of current issues (other issues / fake ethernet)
Am Sonntag 15 Januar 2006 16:39 schrieb Stuffed Crust: Internally, we're pure 802.11. One thing to keep in mind that we're not going to be bridging/translating non-data traffic to other networks, and with that in mind, 802.3-802.11 translation is trivial, and won't lose anything except for a bit of efficiency. (and then, just to be contrary, the prism54 hardware actually requires 802.3 frames!) prism2 usb is even worse - the urb is build of some control structure, the 802.11 3 address header, a 802.3 header and the 802.11 data part. Some bits in the control structure decide whether the 802.11 or the 802.3 header is used to create the frame sent to the air. Fortunately, a driver should be able to specify it's additional memory need at the front of the frame via hard_header_len. Some drivers will need to do some ugly memmove()s at the packet begin then. (Part of the problem is that 802.11 has a variable-length header - 24, 26, 30, or 32 bytes, and each address field means different things depending on which mode we're using..) .. and it gets even worse as soon as we start encrypting packets. I think we should start using the netdev wiki at http://linux-net.osdl.org/ to collect information. For this part of the discussion, we need to know what transmit frame formats different hardware needs. I'll ask Stephen Hemminger to put a link for wireless development on the index page and will start with frame information for prism2 and other hardware I have and understand good enough. Stefan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES] SCTP bugfixes for 2.6.16
From: Sridhar Samudrala [EMAIL PROTECTED] Date: Tue, 17 Jan 2006 15:20:50 -0800 Please pull the following SCTP bugfixes from master.kernel.org:/pub/scm/linux/kernel/git/sridhar/lksctp-2.6.git Looks good. Pulled, thanks Sridhar. - To unsubscribe from this list: send 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 0/5] [RFC] Infiniband: connection abstraction
The following set of patches defines a connection abstraction for Infiniband and other RDMA devices, and serves several purposes: * It implements a connection protocol over Infiniband based on IP addressing. This greatly simplifies clients wishing to establish connections over Infiniband. * It defines a connection abstraction that works over multiple RDMA devices. The submitted implementation targets Infiniband, but has been tested over other RDMA devices as well. * It handles RDMA device insertion and removal on behalf of its clients. The changes have been broken into 5 separate patches. The basic purpose of each patch is: 1. Provide common handling for marshalling data between userspace clients and kernel mode Infiniband drivers. 2. Extend the Infiniband CM to include private data comparisons as part of its connection request matching process. 3. Provide an address translation service that maps IP addresses to Infiniband addresses (GIDs). This patch touches outside of the Infiniband core, so I'm including the netdev mailing list. 4. Implement the kernel mode RDMA connection management agent. 5. Implement the userspace RDMA connection management agent kernel support module. Please copy the openib-general mailing list on any replies. Thanks, Sean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] [RFC] Infiniband: connection abstraction
The following patch provides common handling for marshalling data between
userspace clients and kernel mode Infiniband drivers.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/Makefile
linux-2.6.ib/drivers/infiniband/core/Makefile
--- linux-2.6.git/drivers/infiniband/core/Makefile 2006-01-16
10:25:27.0 -0800
+++ linux-2.6.ib/drivers/infiniband/core/Makefile 2006-01-16
15:34:15.0 -0800
@@ -16,4 +16,5 @@ ib_umad-y := user_mad.o
ib_ucm-y :=ucm.o
-ib_uverbs-y := uverbs_main.o uverbs_cmd.o uverbs_mem.o
+ib_uverbs-y := uverbs_main.o uverbs_cmd.o uverbs_mem.o \
+ uverbs_marshall.o
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/ucm.c
linux-2.6.ib/drivers/infiniband/core/ucm.c
--- linux-2.6.git/drivers/infiniband/core/ucm.c 2006-01-16 10:25:26.0
-0800
+++ linux-2.6.ib/drivers/infiniband/core/ucm.c 2006-01-16 15:34:15.0
-0800
@@ -30,7 +30,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
- * $Id: ucm.c 2594 2005-06-13 19:46:02Z libor $
+ * $Id: ucm.c 4311 2005-12-05 18:42:01Z sean.hefty $
*/
#include linux/init.h
#include linux/fs.h
@@ -48,6 +48,7 @@
#include rdma/ib_cm.h
#include rdma/ib_user_cm.h
+#include rdma/ib_marshall.h
MODULE_AUTHOR(Libor Michalek);
MODULE_DESCRIPTION(InfiniBand userspace Connection Manager access);
@@ -203,36 +204,6 @@ error:
return NULL;
}
-static void ib_ucm_event_path_get(struct ib_ucm_path_rec *upath,
- struct ib_sa_path_rec *kpath)
-{
- if (!kpath || !upath)
- return;
-
- memcpy(upath-dgid, kpath-dgid.raw, sizeof *upath-dgid);
- memcpy(upath-sgid, kpath-sgid.raw, sizeof *upath-sgid);
-
- upath-dlid = kpath-dlid;
- upath-slid = kpath-slid;
- upath-raw_traffic = kpath-raw_traffic;
- upath-flow_label = kpath-flow_label;
- upath-hop_limit= kpath-hop_limit;
- upath-traffic_class= kpath-traffic_class;
- upath-reversible = kpath-reversible;
- upath-numb_path= kpath-numb_path;
- upath-pkey = kpath-pkey;
- upath-sl = kpath-sl;
- upath-mtu_selector = kpath-mtu_selector;
- upath-mtu = kpath-mtu;
- upath-rate_selector= kpath-rate_selector;
- upath-rate = kpath-rate;
- upath-packet_life_time = kpath-packet_life_time;
- upath-preference = kpath-preference;
-
- upath-packet_life_time_selector =
- kpath-packet_life_time_selector;
-}
-
static void ib_ucm_event_req_get(struct ib_ucm_req_event_resp *ureq,
struct ib_cm_req_event_param *kreq)
{
@@ -251,8 +222,10 @@ static void ib_ucm_event_req_get(struct
ureq-srq= kreq-srq;
ureq-port = kreq-port;
- ib_ucm_event_path_get(ureq-primary_path, kreq-primary_path);
- ib_ucm_event_path_get(ureq-alternate_path, kreq-alternate_path);
+ ib_copy_path_rec_to_user(ureq-primary_path, kreq-primary_path);
+ if (kreq-alternate_path)
+ ib_copy_path_rec_to_user(ureq-alternate_path,
+kreq-alternate_path);
}
static void ib_ucm_event_rep_get(struct ib_ucm_rep_event_resp *urep,
@@ -322,8 +295,8 @@ static int ib_ucm_event_process(struct i
info = evt-param.rej_rcvd.ari;
break;
case IB_CM_LAP_RECEIVED:
- ib_ucm_event_path_get(uvt-resp.u.lap_resp.path,
- evt-param.lap_rcvd.alternate_path);
+ ib_copy_path_rec_to_user(uvt-resp.u.lap_resp.path,
+evt-param.lap_rcvd.alternate_path);
uvt-data_len = IB_CM_LAP_PRIVATE_DATA_SIZE;
uvt-resp.present = IB_UCM_PRES_ALTERNATE;
break;
@@ -635,65 +608,11 @@ static ssize_t ib_ucm_attr_id(struct ib_
return result;
}
-static void ib_ucm_copy_ah_attr(struct ib_ucm_ah_attr *dest_attr,
- struct ib_ah_attr *src_attr)
-{
- memcpy(dest_attr-grh_dgid, src_attr-grh.dgid.raw,
- sizeof src_attr-grh.dgid);
- dest_attr-grh_flow_label = src_attr-grh.flow_label;
- dest_attr-grh_sgid_index = src_attr-grh.sgid_index;
- dest_attr-grh_hop_limit = src_attr-grh.hop_limit;
- dest_attr-grh_traffic_class = src_attr-grh.traffic_class;
-
- dest_attr-dlid = src_attr-dlid;
- dest_attr-sl = src_attr-sl;
- dest_attr-src_path_bits = src_attr-src_path_bits;
- dest_attr-static_rate = src_attr-static_rate;
- dest_attr-is_global = (src_attr-ah_flags
RE: [PATCH 2/5] [RFC] Infiniband: connection abstraction
The following patch extends matching connection requests to listens in the
Infiniband CM to include private data.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/cm.c
linux-2.6.ib/drivers/infiniband/core/cm.c
--- linux-2.6.git/drivers/infiniband/core/cm.c 2006-01-16 10:25:26.0
-0800
+++ linux-2.6.ib/drivers/infiniband/core/cm.c 2006-01-16 16:03:35.0
-0800
@@ -32,7 +32,7 @@
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
- * $Id: cm.c 2821 2005-07-08 17:07:28Z sean.hefty $
+ * $Id: cm.c 4311 2005-12-05 18:42:01Z sean.hefty $
*/
#include linux/dma-mapping.h
#include linux/err.h
@@ -130,6 +130,7 @@ struct cm_id_private {
/* todo: use alternate port on send failure */
struct cm_av av;
struct cm_av alt_av;
+ struct ib_cm_private_data_compare *compare_data;
void *private_data;
__be64 tid;
@@ -355,6 +356,40 @@ static struct cm_id_private * cm_acquire
return cm_id_priv;
}
+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
+{
+ int i;
+
+ for (i = 0; i IB_CM_PRIVATE_DATA_COMPARE_SIZE; i++)
+ dst[i] = src[i] mask[i];
+}
+
+static int cm_compare_data(struct ib_cm_private_data_compare *src_data,
+ struct ib_cm_private_data_compare *dst_data)
+{
+ u8 src[IB_CM_PRIVATE_DATA_COMPARE_SIZE];
+ u8 dst[IB_CM_PRIVATE_DATA_COMPARE_SIZE];
+
+ if (!src_data || !dst_data)
+ return 0;
+
+ cm_mask_compare_data(src, src_data-data, dst_data-mask);
+ cm_mask_compare_data(dst, dst_data-data, src_data-mask);
+ return memcmp(src, dst, IB_CM_PRIVATE_DATA_COMPARE_SIZE);
+}
+
+static int cm_compare_private_data(u8 *private_data,
+ struct ib_cm_private_data_compare *dst_data)
+{
+ u8 src[IB_CM_PRIVATE_DATA_COMPARE_SIZE];
+
+ if (!dst_data)
+ return 0;
+
+ cm_mask_compare_data(src, private_data, dst_data-mask);
+ return memcmp(src, dst_data-data, IB_CM_PRIVATE_DATA_COMPARE_SIZE);
+}
+
static struct cm_id_private * cm_insert_listen(struct cm_id_private
*cm_id_priv)
{
struct rb_node **link = cm.listen_service_table.rb_node;
@@ -362,14 +397,18 @@ static struct cm_id_private * cm_insert_
struct cm_id_private *cur_cm_id_priv;
__be64 service_id = cm_id_priv-id.service_id;
__be64 service_mask = cm_id_priv-id.service_mask;
+ int data_cmp;
while (*link) {
parent = *link;
cur_cm_id_priv = rb_entry(parent, struct cm_id_private,
service_node);
+ data_cmp = cm_compare_data(cm_id_priv-compare_data,
+ cur_cm_id_priv-compare_data);
if ((cur_cm_id_priv-id.service_mask service_id) ==
(service_mask cur_cm_id_priv-id.service_id)
- (cm_id_priv-id.device == cur_cm_id_priv-id.device))
+ (cm_id_priv-id.device == cur_cm_id_priv-id.device)
+ !data_cmp)
return cur_cm_id_priv;
if (cm_id_priv-id.device cur_cm_id_priv-id.device)
@@ -378,6 +417,10 @@ static struct cm_id_private * cm_insert_
link = (*link)-rb_right;
else if (service_id cur_cm_id_priv-id.service_id)
link = (*link)-rb_left;
+ else if (service_id cur_cm_id_priv-id.service_id)
+ link = (*link)-rb_right;
+ else if (data_cmp 0)
+ link = (*link)-rb_left;
else
link = (*link)-rb_right;
}
@@ -387,16 +430,20 @@ static struct cm_id_private * cm_insert_
}
static struct cm_id_private * cm_find_listen(struct ib_device *device,
-__be64 service_id)
+__be64 service_id,
+u8 *private_data)
{
struct rb_node *node = cm.listen_service_table.rb_node;
struct cm_id_private *cm_id_priv;
+ int data_cmp;
while (node) {
cm_id_priv = rb_entry(node, struct cm_id_private, service_node);
+ data_cmp = cm_compare_private_data(private_data,
+ cm_id_priv-compare_data);
if ((cm_id_priv-id.service_mask service_id) ==
cm_id_priv-id.service_id
- (cm_id_priv-id.device == device))
+ (cm_id_priv-id.device == device) !data_cmp)
return cm_id_priv;
if (device cm_id_priv-id.device)
@@ -405,6 +452,10 @@ static struct cm_id_private * cm_find_li
node = node-rb_right;
[PATCH 3/5] [RFC] Infiniband: connection abstraction
The following provides an address translation service that maps IP addresses
to Infiniband addresses (GIDs) using IPoIB.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/addr.c
linux-2.6.ib/drivers/infiniband/core/addr.c
--- linux-2.6.git/drivers/infiniband/core/addr.c1969-12-31
16:00:00.0 -0800
+++ linux-2.6.ib/drivers/infiniband/core/addr.c 2006-01-16 16:14:24.0
-0800
@@ -0,0 +1,356 @@
+/*
+ * Copyright (c) 2005 Voltaire Inc. All rights reserved.
+ * Copyright (c) 2002-2005, Network Appliance, Inc. All rights reserved.
+ * Copyright (c) 1999-2005, Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2005 Intel Corporation. All rights reserved.
+ *
+ * This Software is licensed under one of the following licenses:
+ *
+ * 1) under the terms of the Common Public License 1.0 a copy of which is
+ *available from the Open Source Initiative, see
+ *http://www.opensource.org/licenses/cpl.php.
+ *
+ * 2) under the terms of the The BSD License a copy of which is
+ *available from the Open Source Initiative, see
+ *http://www.opensource.org/licenses/bsd-license.php.
+ *
+ * 3) under the terms of the GNU General Public License (GPL) Version 2 a
+ *copy of which is available from the Open Source Initiative, see
+ *http://www.opensource.org/licenses/gpl-license.php.
+ *
+ * Licensee has the right to choose one of the above licenses.
+ *
+ * Redistributions of source code must retain the above copyright
+ * notice and one of the license notices.
+ *
+ * Redistributions in binary form must reproduce both the above copyright
+ * notice, one of the license notices in the documentation
+ * and/or other materials provided with the distribution.
+ */
+#include linux/inetdevice.h
+#include linux/workqueue.h
+#include net/arp.h
+#include net/neighbour.h
+#include net/route.h
+#include rdma/ib_addr.h
+
+MODULE_AUTHOR(Sean Hefty);
+MODULE_DESCRIPTION(IB Address Translation);
+MODULE_LICENSE(Dual BSD/GPL);
+
+struct addr_req {
+ struct list_head list;
+ struct sockaddr src_addr;
+ struct sockaddr dst_addr;
+ struct rdma_dev_addr *addr;
+ void *context;
+ void (*callback)(int status, struct sockaddr *src_addr,
+struct rdma_dev_addr *addr, void *context);
+ unsigned long timeout;
+ int status;
+};
+
+static void process_req(void *data);
+
+static DECLARE_MUTEX(mutex);
+static LIST_HEAD(req_list);
+static DECLARE_WORK(work, process_req, NULL);
+struct workqueue_struct *rdma_wq;
+EXPORT_SYMBOL(rdma_wq);
+
+static int copy_addr(struct rdma_dev_addr *dev_addr, struct net_device *dev,
+unsigned char *dst_dev_addr)
+{
+ switch (dev-type) {
+ case ARPHRD_INFINIBAND:
+ dev_addr-dev_type = IB_NODE_CA;
+ break;
+ default:
+ return -EADDRNOTAVAIL;
+ }
+
+ memcpy(dev_addr-src_dev_addr, dev-dev_addr, MAX_ADDR_LEN);
+ memcpy(dev_addr-broadcast, dev-broadcast, MAX_ADDR_LEN);
+ if (dst_dev_addr)
+ memcpy(dev_addr-dst_dev_addr, dst_dev_addr, MAX_ADDR_LEN);
+ return 0;
+}
+
+int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr)
+{
+ struct net_device *dev;
+ u32 ip = ((struct sockaddr_in *) addr)-sin_addr.s_addr;
+ int ret;
+
+ dev = ip_dev_find(ip);
+ if (!dev)
+ return -EADDRNOTAVAIL;
+
+ ret = copy_addr(dev_addr, dev, NULL);
+ dev_put(dev);
+ return ret;
+}
+EXPORT_SYMBOL(rdma_translate_ip);
+
+static void set_timeout(unsigned long time)
+{
+ unsigned long delay;
+
+ cancel_delayed_work(work);
+
+ delay = time - jiffies;
+ if ((long)delay = 0)
+ delay = 1;
+
+ queue_delayed_work(rdma_wq, work, delay);
+}
+
+static void queue_req(struct addr_req *req)
+{
+ struct addr_req *temp_req;
+
+ down(mutex);
+ list_for_each_entry_reverse(temp_req, req_list, list) {
+ if (time_after(req-timeout, temp_req-timeout))
+ break;
+ }
+
+ list_add(req-list, temp_req-list);
+
+ if (req_list.next == req-list)
+ set_timeout(req-timeout);
+ up(mutex);
+}
+
+static void addr_send_arp(struct sockaddr_in *dst_in)
+{
+ struct rtable *rt;
+ struct flowi fl;
+ u32 dst_ip = dst_in-sin_addr.s_addr;
+
+ memset(fl, 0, sizeof fl);
+ fl.nl_u.ip4_u.daddr = dst_ip;
+ if (ip_route_output_key(rt, fl))
+ return;
+
+ arp_send(ARPOP_REQUEST, ETH_P_ARP, rt-rt_gateway, rt-idev-dev,
+rt-rt_src, NULL, rt-idev-dev-dev_addr, NULL);
+ ip_rt_put(rt);
+}
+
+static int addr_resolve_remote(struct sockaddr_in *src_in,
+ struct sockaddr_in *dst_in,
+ struct rdma_dev_addr *addr)
+{
+ u32 src_ip
[PATCH 4/5] [RFC] Infiniband: connection abstraction
The following patch implements a kernel mode connection management agent
over Infiniband that connects based on IP addresses.
The agent defines a generic RDMA connection abstraction to support clients
wanting to connect over different RDMA devices.
It also handles RDMA device hotplug events on behalf of clients.
- Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/cma.c
linux-2.6.ib/drivers/infiniband/core/cma.c
--- linux-2.6.git/drivers/infiniband/core/cma.c 1969-12-31 16:00:00.0
-0800
+++ linux-2.6.ib/drivers/infiniband/core/cma.c 2006-01-16 16:17:34.0
-0800
@@ -0,0 +1,1639 @@
+/*
+ * Copyright (c) 2005 Voltaire Inc. All rights reserved.
+ * Copyright (c) 2002-2005, Network Appliance, Inc. All rights reserved.
+ * Copyright (c) 1999-2005, Mellanox Technologies, Inc. All rights reserved.
+ * Copyright (c) 2005 Intel Corporation. All rights reserved.
+ *
+ * This Software is licensed under one of the following licenses:
+ *
+ * 1) under the terms of the Common Public License 1.0 a copy of which is
+ *available from the Open Source Initiative, see
+ *http://www.opensource.org/licenses/cpl.php.
+ *
+ * 2) under the terms of the The BSD License a copy of which is
+ *available from the Open Source Initiative, see
+ *http://www.opensource.org/licenses/bsd-license.php.
+ *
+ * 3) under the terms of the GNU General Public License (GPL) Version 2 a
+ *copy of which is available from the Open Source Initiative, see
+ *http://www.opensource.org/licenses/gpl-license.php.
+ *
+ * Licensee has the right to choose one of the above licenses.
+ *
+ * Redistributions of source code must retain the above copyright
+ * notice and one of the license notices.
+ *
+ * Redistributions in binary form must reproduce both the above copyright
+ * notice, one of the license notices in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ */
+#include linux/in.h
+#include linux/in6.h
+#include linux/random.h
+#include rdma/rdma_cm.h
+#include rdma/ib_cache.h
+#include rdma/ib_cm.h
+#include rdma/ib_sa.h
+
+MODULE_AUTHOR(Guy German);
+MODULE_DESCRIPTION(Generic RDMA CM Agent);
+MODULE_LICENSE(Dual BSD/GPL);
+
+#define CMA_CM_RESPONSE_TIMEOUT 20
+#define CMA_MAX_CM_RETRIES 3
+
+static void cma_add_one(struct ib_device *device);
+static void cma_remove_one(struct ib_device *device);
+
+static struct ib_client cma_client = {
+ .name = cma,
+ .add= cma_add_one,
+ .remove = cma_remove_one
+};
+
+static LIST_HEAD(dev_list);
+static LIST_HEAD(listen_any_list);
+static DECLARE_MUTEX(mutex);
+
+struct cma_device {
+ struct list_headlist;
+ struct ib_device*device;
+ __be64 node_guid;
+ wait_queue_head_t wait;
+ atomic_trefcount;
+ struct list_headid_list;
+};
+
+enum cma_state {
+ CMA_IDLE,
+ CMA_ADDR_QUERY,
+ CMA_ADDR_RESOLVED,
+ CMA_ROUTE_QUERY,
+ CMA_ROUTE_RESOLVED,
+ CMA_CONNECT,
+ CMA_ADDR_BOUND,
+ CMA_LISTEN,
+ CMA_DEVICE_REMOVAL,
+ CMA_DESTROYING
+};
+
+/*
+ * Device removal can occur at anytime, so we need extra handling to
+ * serialize notifying the user of device removal with other callbacks.
+ * We do this by disabling removal notification while a callback is in process,
+ * and reporting it after the callback completes.
+ */
+struct rdma_id_private {
+ struct rdma_cm_id id;
+
+ struct list_headlist;
+ struct list_headlisten_list;
+ struct cma_device *cma_dev;
+
+ enum cma_state state;
+ spinlock_t lock;
+ wait_queue_head_t wait;
+ atomic_trefcount;
+ wait_queue_head_t wait_remove;
+ atomic_tdev_remove;
+
+ int backlog;
+ int timeout_ms;
+ struct ib_sa_query *query;
+ int query_id;
+ struct ib_cm_id *cm_id;
+
+ u32 seq_num;
+ u32 qp_num;
+ enum ib_qp_type qp_type;
+ u8 srq;
+};
+
+struct cma_work {
+ struct work_struct work;
+ struct rdma_id_private *id;
+};
+
+union cma_ip_addr {
+ struct in6_addr ip6;
+ struct {
+ __u32 pad[3];
+ __u32 addr;
+ } ip4;
+};
+
+struct cma_hdr {
+ u8 cma_version;
+ u8 ip_version; /* IP version: 7:4 */
+ __u16 port;
+ union cma_ip_addr src_addr;
+ union cma_ip_addr dst_addr;
+};
+
+struct sdp_hh {
+ u8 sdp_version;
+ u8 ip_version; /* IP version: 7:4 */
+ u8 sdp_specific1[10];
+ __u16 port;
+ __u16 sdp_specific2;
+ union cma_ip_addr src_addr;
+ union cma_ip_addr dst_addr;
+};
+
Re: [PATCH 2/5] [RFC] Infiniband: connection abstraction
Minor nits.
On Tue, 17 Jan 2006 15:24:37 -0800
Sean Hefty [EMAIL PROTECTED] wrote:
The following patch extends matching connection requests to listens in the
Infiniband CM to include private data.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
static void cm_mask_compare_data(u8 *dst, const u8 *src, u8 *mask)
but I would rename it to cm_mask_copy since it doesn't really do a compare.
+{
+ int i;
+
+ for (i = 0; i IB_CM_PRIVATE_DATA_COMPARE_SIZE; i++)
+ dst[i] = src[i] mask[i];
+}
+
+static int cm_compare_data(struct ib_cm_private_data_compare *src_data,
+struct ib_cm_private_data_compare *dst_data)
static int cm_compare_data(const struct ib_cm_private_data_compare *src,
cosnt struct ib_cm_private_data_compare *dst)
Your data type names are getting too long
flamebait
Also should infiniband exports be EXPORT_SYMBOL_GPL, to make
it clear that binary drivers for this are not allowed??
/flamebait
--
Stephen Hemminger [EMAIL PROTECTED]
OSDL http://developer.osdl.org/~shemminger
-
To unsubscribe from this list: send 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 5/5] [RFC] Infiniband: connection abstraction
This patch adds the kernel component to support the userspace Infiniband/RDMA
connection agent library.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/Makefile
linux-2.6.ib/drivers/infiniband/core/Makefile
--- linux-2.6.git/drivers/infiniband/core/Makefile 2006-01-16
16:58:58.0 -0800
+++ linux-2.6.ib/drivers/infiniband/core/Makefile 2006-01-16
16:55:25.0 -0800
@@ -1,5 +1,5 @@
obj-$(CONFIG_INFINIBAND) +=ib_core.o ib_mad.o ib_sa.o \
- ib_cm.o ib_addr.o rdma_cm.o
+ ib_cm.o ib_addr.o rdma_cm.o rdma_ucm.o
obj-$(CONFIG_INFINIBAND_USER_MAD) += ib_umad.o
obj-$(CONFIG_INFINIBAND_USER_ACCESS) +=ib_uverbs.o ib_ucm.o
@@ -14,6 +14,8 @@ ib_cm-y :=cm.o
rdma_cm-y := cma.o
+rdma_ucm-y := ucma.o
+
ib_addr-y := addr.o
ib_umad-y := user_mad.o
diff -uprN -X linux-2.6.git/Documentation/dontdiff
linux-2.6.git/drivers/infiniband/core/ucma.c
linux-2.6.ib/drivers/infiniband/core/ucma.c
--- linux-2.6.git/drivers/infiniband/core/ucma.c1969-12-31
16:00:00.0 -0800
+++ linux-2.6.ib/drivers/infiniband/core/ucma.c 2006-01-16 16:54:31.0
-0800
@@ -0,0 +1,788 @@
+/*
+ * Copyright (c) 2005 Intel Corporation. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials
+ * provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include linux/poll.h
+#include linux/idr.h
+#include linux/in.h
+#include linux/in6.h
+#include linux/miscdevice.h
+
+#include rdma/rdma_user_cm.h
+#include rdma/ib_marshall.h
+#include rdma/rdma_cm.h
+
+MODULE_AUTHOR(Sean Hefty);
+MODULE_DESCRIPTION(RDMA Userspace Connection Manager Access);
+MODULE_LICENSE(Dual BSD/GPL);
+
+enum {
+ UCMA_MAX_BACKLOG= 128
+};
+
+struct ucma_file {
+ struct semaphoremutex;
+ struct file *filp;
+ struct list_headctxs;
+ struct list_headevents;
+ wait_queue_head_t poll_wait;
+};
+
+struct ucma_context {
+ int id;
+ wait_queue_head_t wait;
+ atomic_tref;
+ int events_reported;
+ int backlog;
+
+ struct ucma_file*file;
+ struct rdma_cm_id *cm_id;
+ __u64 uid;
+
+ struct list_headevents;/* list of pending events. */
+ struct list_headfile_list; /* member in file ctx list */
+};
+
+struct ucma_event {
+ struct ucma_context *ctx;
+ struct list_headfile_list; /* member in file event list */
+ struct list_headctx_list; /* member in ctx event list */
+ struct rdma_cm_id *cm_id;
+ struct rdma_ucm_event_resp resp;
+};
+
+static DECLARE_MUTEX(ctx_mutex);
+static DEFINE_IDR(ctx_idr);
+
+static struct ucma_context* ucma_get_ctx(struct ucma_file *file, int id)
+{
+ struct ucma_context *ctx;
+
+ down(ctx_mutex);
+ ctx = idr_find(ctx_idr, id);
+ if (!ctx)
+ ctx = ERR_PTR(-ENOENT);
+ else if (ctx-file != file)
+ ctx = ERR_PTR(-EINVAL);
+ else
+ atomic_inc(ctx-ref);
+ up(ctx_mutex);
+
+ return ctx;
+}
+
+static void ucma_put_ctx(struct ucma_context *ctx)
+{
+ if (atomic_dec_and_test(ctx-ref))
+ wake_up(ctx-wait);
+}
+
+static void ucma_cleanup_events(struct ucma_context *ctx)
+{
+ struct ucma_event *uevent;
+
+ down(ctx-file-mutex);
+
Re: R8169 driver Netgear GA511 NIC - soft lockup/hang in rtl8169_phy_timer
Russell Steinthal [EMAIL PROTECTED] :
[...]
Thanks again for the help --- if you have any other ideas or things
you'd like me to test, let me know.
I am probably not searching in the right direction. :o/
CONFIG_LOG_BUF_SHIFT=14
- Please make it 17, your dmesg are trimmed.
# CONFIG_PRINTK_TIME is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
- Please enable these (and go SMP without PREEMPT).
CONFIG_BROKEN_ON_SMP=y
- be nice with me and disable this one until your system
behaves more correctly, ok ?
And add this code to an otherwise standard kernel:
diff --git a/kernel/softlockup.c b/kernel/softlockup.c
index c67189a..3aa27e4 100644
--- a/kernel/softlockup.c
+++ b/kernel/softlockup.c
@@ -85,6 +85,7 @@ static int watchdog(void * __bind_cpu)
* in softlockup_tick():
*/
while (!kthread_should_stop()) {
+ printk(KERN_INFO -- MARK --\n);
msleep_interruptible(1000);
touch_softlockup_watchdog();
}
A single test will be enough. No need to try different combinations.
--
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: wireless: recap of current issues (stack)
On Tuesday 17 January 2006 12:37, Jirka Bohac wrote: At the present time, the ieee80211 stack is used by ipw2x00 (heavily) and hostap (a little bit). Other mainline drivers only use headers (mainly constants). If it shows that the DeviceScape stack is more mature and appropriate (which I think it is), I don't see anything wrong with having both in the kernel at one time time. - DeviceScape can be there so it can be polished and new drivers can start using it. - ieee80211 could be there with a big fat warning that it will go away soon, just to allow ipw2x00 to work while DeviceScape and the ipw2x00 port for it to be stabilized. Isnt't this a viable option? It would not bother me as much to have two stacks in the kernel if the current stack were immediately marked as deprecated and a concrete schedule for its complete removal were established. I mainly object to the idea the idea that both stacks should be given full-class citizenry to allow 'natural evolution' to choose the best one. Cheers, Chase - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
