Re: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
[Trimmed CC list as we're off topic] Am Sonntag, 9. Juli 2006 22:05 schrieb Krzysztof Halasa: ... and where the maintainer doesn't seem to care to use it now that the infrastructure is there. Sigh. This is very different from what I proposed and doesn't fit very well. We've been discussing this to death. You've been asking for two independant flags of which one does not stop the queue. You've got two independant flags of which one does not stop the queue. If you're claiming now that this doesn't fit well you either did not bother to look at the result or you are outrigthly lying. End of story. 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: [patch 1/7] net_device list cleanup: core
On Sat, Jul 08, 2006 at 01:48:13AM +0900, YOSHIFUJI Hideaki / [EMAIL
PROTECTED](B wrote:
In article [EMAIL PROTECTED] (at Fri, 7 Jul 2006 11:54:25 +0400), Andrey
Savochkin [EMAIL PROTECTED] says:
On Fri, Jul 07, 2006 at 01:34:34PM +0900, YOSHIFUJI Hideaki / [EMAIL
PROTECTED](B wrote:
In article [EMAIL PROTECTED] (at Mon, 3 Jul 2006 12:18:51 +0400),
Andrey Savochkin [EMAIL PROTECTED] says:
@@ -3271,22 +3277,22 @@ int unregister_netdevice(struct net_devi
/* And unlink it from device chain. */
for (dp = dev_base; (d = *dp) != NULL; dp = d-next) {
Why not for_each_netdev?
it's a different list
Sorry, I still do not understand.
In other words, why will we still have dev-next?
After introducing net_device-dev_list, we do not need
dev-next anymore, do we?
dev-next is removed in the last patch, to make possible the bisection
of patch list.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: auro deadlock
* David Miller [EMAIL PROTECTED] wrote: The lockdep fixes are starting to cause us to go in and start adding hard IRQ protection to many socket layer objects and I want this thinking to end quickly :) In earlier lockdep versions we had many such hacks, but in the current upstream kernel we've only got one such case so far: one netlink function, where the alternative was to rewrite softmac. I fixed all the earlier hacks to be proper annotations - and the plan is to keep things clean in the future too :-) Ingo - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc1-mm1 inconsistent lock state in netpoll_send_skb
On Sun, 2006-07-09 at 23:37 +0200, Laurent Riffard wrote:
ei_start_xmit
please try this patch
---
drivers/net/8390.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6.17-mm4/drivers/net/8390.c
===
--- linux-2.6.17-mm4.orig/drivers/net/8390.c
+++ linux-2.6.17-mm4/drivers/net/8390.c
@@ -299,7 +299,7 @@ static int ei_start_xmit(struct sk_buff
* Slow phase with lock held.
*/
- disable_irq_nosync(dev-irq);
+ disable_irq_nosync_lockdep(dev-irq);
spin_lock(ei_local-page_lock);
@@ -338,7 +338,7 @@ static int ei_start_xmit(struct sk_buff
netif_stop_queue(dev);
outb_p(ENISR_ALL, e8390_base + EN0_IMR);
spin_unlock(ei_local-page_lock);
- enable_irq(dev-irq);
+ enable_irq_lockdep(dev-irq);
ei_local-stat.tx_errors++;
return 1;
}
@@ -379,7 +379,7 @@ static int ei_start_xmit(struct sk_buff
outb_p(ENISR_ALL, e8390_base + EN0_IMR);
spin_unlock(ei_local-page_lock);
- enable_irq(dev-irq);
+ enable_irq_lockdep(dev-irq);
dev_kfree_skb (skb);
ei_local-stat.tx_bytes += send_length;
@@ -505,9 +505,9 @@ irqreturn_t ei_interrupt(int irq, void *
#ifdef CONFIG_NET_POLL_CONTROLLER
void ei_poll(struct net_device *dev)
{
- disable_irq(dev-irq);
+ disable_irq_lockdep(dev-irq);
ei_interrupt(dev-irq, dev, NULL);
- enable_irq(dev-irq);
+ enable_irq_lockdep(dev-irq);
}
#endif
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
On Fri, 2006-07-07 at 10:00 +0200, Patrick McHardy wrote: Russell Stuart wrote: Unfortunately you do things in the wrong order for ATM. See: http://mailman.ds9a.nl/pipermail/lartc/2006q1/018314.html for an overview of the problem, and then the attached email for a detailed description of how the current patch addresses it. It is a trivial fix. Actually that was the part I didn't understand, you keep talking (also in that comment in tc_core.c) about an unknown overhead. What is that and why would it be unknown? The mail you attached is quite long, is there an simple example that shows what you mean? The unknown overhead is just the overhead passed to tc using the tc ... overhead xxx option. It is probably what you intended to put into your addend attribute. It is unknown because the kernel currently doesn't use it. It is passed in the tc_ratespec, but is ignored by the kernel as are most fields in there. The easy way to fix the ATM problem described in the big comment is simply to add the overhead to the packet length before doing the RTAB lookup. (Identical comments apply to STAB). If you don't accept this or understand why, then go read the long emails which attempt to explain it in detail. Jesper's initial version of the patch did just that, BTW. However if you do that then you have to adjust RTAB for all cases (not just ATM) to reflect that the kernel is now adding the overhead. Thus the RTAB tc sends to the kernel now changes for different kernel versions, making modern versions of tc incompatible with older kernels, and visa versa. I didn't consider that acceptable. My solution to this to give the kernel the old format RTAB (ie the one that assumed the kernel didn't add the overhead) and a small adjustment. This small adjustment is called cell_align in the ATM patch. You do the same thing with cell_align as the previous solution did with the overhead - ie add it in just before looking up RTAB. This is in effect all the kernel part of the ATM patch does - make the kernel accept the cell_align option, and add it to skb-len before looking up RTAB. The difference between cell_align and overhead is that cell_align is always 0 when there is no packetisation, and even when non zero it is small (less than 1cell_log, ie less than 8 for typical MTU's). So for anything bar ATM it is zero which means old kernels are completely unaffected, and even for ATM not sending it produces a small error which means older kernels still benefit from the ATM user space patch. This makes the proposed ATM version of tc both forward and backward compatible. One other point arises here. The fields in tc_ratespec that tc fills and the kernel ignores are there so tc show will work. The essence of the problem is tc compiles the stuff you give it into a single RTAB. That RTAB can't be reverse compiled into the original numbers the user provided. So if tc show is to work, tc has to save that information somewhere. I don't think the tc_ratespec was the best choice for two reasons. Firstly, having the fields show up in tc_ratespec makes it seem like the kernel can use them. It can't, as the overhead example above shows. Secondly, from tc's point of view it is inflexible. Over time new features have been be added to tc, and each time a new way of encoding it in the existing tc_ratespec has to be invented. Thus we now have hacks like the storing the overhead in the upper bits of the MPU figure. A better solution would be to provide a TLV (ie a TCA_XXX constant) for TC's private use. From the kernels point of view it would be an opaque structure which just saves and echos back when asked. This would solve both problems. However, now you lot have made me go away and think, I have another idea on how to attack this. Perhaps it will be more palatable to you. It would replace RTAB and STAB with a 28 byte structure for most protocol stacks - well all I can think of off the top of my head, anyway. RTAB would have to remain for backwards compatibility, of course. Can you describe in more detail? OK, but first I want to make the point that the only reason I suggest this is to get some sort of ATM patch into the kernel, as the current patch on the table is having a rough time. Alan Cox made the point earlier (if I understood him correctly) that this tabling lookup probably isn't a big win on modern CPU's - we may be better off moving it all into the kernel. Thinking about this, I tried to come up with a way of describing the mapping between skb-len and the on the wire packet length for every protocol I know. This is what I came up with. Assume we have a packet length L, which is to be transported by some protocol. For now we consider one protocol only, ie: TCP, PPP, ATM, Ethernet or whatever. I will generalise it to multiple protocols later. I think a generalised transformation can be made using using 5 numbers which are applied in this order:
Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
On Tue, 4 Jul 2006, Andi Kleen wrote: On Tuesday 04 July 2006 13:41, Jesper Dangaard Brouer wrote: Actually the change happens between kernel version 2.6.15 and 2.6.16. The timestamp optimizations are older. Don't remember the exact release, but earlier 2.6. What I'm saying is that, with the same Config file, some Kconfig option changed between 2.6.15 and 2.6.16, that made my system use pmtmr for high-res timesource instead of TSC. And is a result of Andi's changes to arch/x86_64/Kconfig and drivers/acpi/Kconfig, which allows/activates the use of the timer on x86_64. Not sure what you mean here? I think, that the changes you made to the files arch/x86_64/Kconfig and drivers/acpi/Kconfig, caused this change... commit: e78256b8f3e2850ad55c2d69e1429e6c2607afd3 http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.17.y.git;a=commitdiff;h=e78256b8f3e2850ad55c2d69e1429e6c2607afd3 and maybe commit: 2eb1bdbad89b19c99f8ac1de1492cdabbff6b3d3 http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.17.y.git;a=commitdiff;h=2eb1bdbad89b19c99f8ac1de1492cdabbff6b3d3 Hilsen Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- - To unsubscribe from this list: send 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] IB/mthca: fix static rate returned by mthca_ah_query
Andrew,
this has been out for a couple of days - could you drop this into -mm /
push this along to Linus, please?
- Forwarded message from Michael S. Tsirkin [EMAIL PROTECTED] -
Please review:
git://www.mellanox.co.il/~git/infiniband mst-for-2.6.18
This has the following patch:
IB/mthca: fix static rate returned by mthca_ah_query
--
commit 8b9395d3b67af87ce4c218af06a259a8af246d75
Author: Jack Morgenstein [EMAIL PROTECTED]
Date: Thu Jul 6 19:33:25 2006 +0300
mthca_ah_query returs the static rate of the address handle in internal mthc
format. fix it to use rate encoding from enum ib_rate, which is what users
expect.
Signed-off-by: Jack Morgenstein [EMAIL PROTECTED]
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: latest/drivers/infiniband/hw/mthca/mthca_av.c
===
--- latest.orig/drivers/infiniband/hw/mthca/mthca_av.c 2006-07-02
18:00:34.0 +0300
+++ latest/drivers/infiniband/hw/mthca/mthca_av.c 2006-07-05
13:50:06.0 +0300
@@ -303,9 +303,10 @@ int mthca_ah_query(struct ib_ah *ibah, s
memset(attr, 0, sizeof *attr);
attr-dlid = be16_to_cpu(ah-av-dlid);
attr-sl= be32_to_cpu(ah-av-sl_tclass_flowlabel) 28;
- attr-static_rate = ah-av-msg_sr 0x7;
- attr-src_path_bits = ah-av-g_slid 0x7F;
attr-port_num = be32_to_cpu(ah-av-port_pd) 24;
+ attr-static_rate = mthca_rate_to_ib(dev, ah-av-msg_sr 0x7,
+ attr-port_num);
+ attr-src_path_bits = ah-av-g_slid 0x7F;
attr-ah_flags = mthca_ah_grh_present(ah) ? IB_AH_GRH : 0;
if (attr-ah_flags) {
--
MST
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IB/mthca: comment fix
Hi Andrew, Here's a cosmetic patch for IB/mthca. Pls drop it into -mm and on. --- comment in mthca_qp.c makes it seem lockdep is the only reason WQ locks should be initialized separately, but as Zach Brown and Roland pointed out, there are other reasons, e.g. that mthca_wq_init is called from modify qp as well. Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c b/drivers/infiniband/hw/mthca/mthca_qp.c index 490fc78..2f3917e 100644 --- a/drivers/infiniband/hw/mthca/mthca_qp.c +++ b/drivers/infiniband/hw/mthca/mthca_qp.c @@ -1114,7 +1114,7 @@ static int mthca_alloc_qp_common(struct qp-sq_policy= send_policy; mthca_wq_init(qp-sq); mthca_wq_init(qp-rq); - /* these are initialized separately so lockdep can tell them apart */ + spin_lock_init(qp-sq.lock); spin_lock_init(qp-rq.lock); -- MST - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IB/mthca: comment fix
On Mon, 2006-07-10 at 14:14 +0300, Michael S. Tsirkin wrote: Hi Andrew, Here's a cosmetic patch for IB/mthca. Pls drop it into -mm and on. --- comment in mthca_qp.c makes it seem lockdep is the only reason WQ locks should be initialized separately, but as Zach Brown and Roland pointed out, there are other reasons, e.g. that mthca_wq_init is called from modify qp as well. ehh.. shouldn't the comment say that instead then? that's one tricky thing and might as well have that documented in the code! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IB/mthca: comment fix
Quoting r. Arjan van de Ven [EMAIL PROTECTED]: Subject: Re: [PATCH] IB/mthca: comment fix On Mon, 2006-07-10 at 14:14 +0300, Michael S. Tsirkin wrote: Hi Andrew, Here's a cosmetic patch for IB/mthca. Pls drop it into -mm and on. --- comment in mthca_qp.c makes it seem lockdep is the only reason WQ locks should be initialized separately, but as Zach Brown and Roland pointed out, there are other reasons, e.g. that mthca_wq_init is called from modify qp as well. ehh.. shouldn't the comment say that instead then? that's one tricky thing and might as well have that documented in the code! Hmm. Okay. Maybe we should rename mthca_wq_init to mthca_wq_reset? This would make it clear that it does not init the spinlocks, but just resets the rest of the fields, would not it? How does this sound? -- MST - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
David Miller [EMAIL PROTECTED] writes: I'm a single developer BTW. So am I, and I've been keeping the core networking and the sparc64 port afloat for more than 10 years. I was just referring to your use of plural form. I don't know about you, but I'm doing Linux (and other related) work in my free time, and things like feeding my family have priority. I was under impression this is common and acceptable. -- Krzysztof Halasa - To unsubscribe from this list: send the 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] IB/mthca: comment fix
On Mon, 2006-07-10 at 14:31 +0300, Michael S. Tsirkin wrote: Quoting r. Arjan van de Ven [EMAIL PROTECTED]: Subject: Re: [PATCH] IB/mthca: comment fix On Mon, 2006-07-10 at 14:14 +0300, Michael S. Tsirkin wrote: Hi Andrew, Here's a cosmetic patch for IB/mthca. Pls drop it into -mm and on. --- comment in mthca_qp.c makes it seem lockdep is the only reason WQ locks should be initialized separately, but as Zach Brown and Roland pointed out, there are other reasons, e.g. that mthca_wq_init is called from modify qp as well. ehh.. shouldn't the comment say that instead then? that's one tricky thing and might as well have that documented in the code! Hmm. Okay. Maybe we should rename mthca_wq_init to mthca_wq_reset? This would make it clear that it does not init the spinlocks, but just resets the rest of the fields, would not it? makes sense to me; my main concern is that we document the bug that was there; unless you document such things.. these bugs tend to have a habit of resurfacing later ;) - To unsubscribe from this list: send the 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] IB/mthca: comment fix
Quoting r. Arjan van de Ven [EMAIL PROTECTED]: makes sense to me; my main concern is that we document the bug that was there; unless you document such things.. these bugs tend to have a habit of resurfacing later ;) Right. Although lockdep will catch this one quickly :) -- MST - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
Stefan Rompf [EMAIL PROTECTED] writes: You've been asking for two independant flags of which one does not stop the queue. Actually I asked for only one flag which can be set independently of others, and which would be visible to userspace. I provided a patch as well. It didn't break anything. I provided a sample of code showing usage of the flag. I still have Message-Ids and the actual messages so don't hesitate to ask if you want to see that again. Then we had that long discussion with you and Jamal and, I admit, I said pass. You've got two independant flags of which one does not stop the queue. Is it ok to set that flag without synchronization with other flags? I.e, from within another module and without using cross-module locks, as I've shown at the time? Just asking, I don't know what the final conclusion was. I.e., is it ok if the hardware module does netif_carrier_on/off() (for example, from its IRQ handler) and if the protocol module does netif_dormant_on/off() independently (for example, from its timer or linkwatch)? If it's ok then I'll be happy to implement the support in my drivers ASAP (this uncertainty was, in fact, the main problem). That should also mean others things I have on queue (blocked by this issue) would go upstream. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
Thomas Hellström wrote: Does the noirqdebug option fix the problem? Yes... but it breaks switching to a text console. I get an interesting fluid effect on the screen (a bright static pattern), and the keyboard locks up. Marcus signature.asc Description: OpenPGP digital signature
Re: Netchannels: progress report. Sending benchmark.
On Mon, Jul 10, 2006 at 05:23:21PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED]) wrote: After week vacations I'm pleased to announce following progress report. Numbers for small packets (80 bytes) bulk sending: * netchannel: 57 MB/sec, ~80% CPU usage * socket: 22 MB/sec, ~90% CPU usage Receiving side is netcat server, which dumps received data into /dev/null Actually it is not 100% correct to call that results correct, since it uses hackish optimisations, which can lead to broken behaviour for non-bulk transfers or transfers over bad lines. If some of them are removed, speed drops to 54 MB/sec for 80 bytes packets, and if socket analog for NODELAY flag is set, i.e. each packet is immediately being sent when it has been written, speed drops down to 16 MB/sec (socket with SO_NODELAY was not tested though). I mean TCP_NODELAY. Socket code uses nonblocking mode and epoll. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
active-backup/bonding with drivers not supporting set_mac_address()
Looking on the linux bonding driver, it seems to unconditionally (*) assume that the enslaved device supports the set_mac_address call. From reading the doc (Documentation/networking/bonding.txt) i understand that it is **not** a must prerequisite for the active-backup mode, this is since there is at most one active slave at each point of time and as the doc states: when a failover occurs in active-backup mode, bonding will issue one or more gratuitous ARPs on the newly active slave. I'd like to get feedback from people here if you think it makes sense to change the bonding driver to actually allow for active-backup/bonding with network device drivers which does not support set_mac_address. thanks, Or Gerlitz. (*) in the sense that it checks for each enslaved device and reports an error if dev-set_mac_address is not supported and later use dev_set_mac_address elsewhere in the code. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
Marcus Better wrote: Thomas Hellström wrote: Does the noirqdebug option fix the problem? Yes... but it breaks switching to a text console. I get an interesting fluid effect on the screen (a bright static pattern), and the keyboard locks up. Marcus Hi! Are you _sure_ these are related? If you don't use the noirqdebug option, do you have the same problem? /Thomas - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
Thomas Hellström wrote: Does the noirqdebug option fix the problem? Yes... but it breaks switching to a text console. Are you _sure_ these are related? Yes. (I tried a few times and it always crashed, whereas without noirqdebug I've switched mode successfully hundreds of times.) Without the i915 module both network and console switching work. Marcus signature.asc Description: OpenPGP digital signature
Re: d80211 sysfs
On Sat, 8 Jul 2006 14:05:08 +0200, Ivo Van Doorn wrote: Since I didn't want to loose any tested because of the new field in the net_device structure, I have used the base_addr field instead and used the following access functions: This will horribly fail when you send something to master device (wmaster0) directly. For example, having ipv6 enabled is enough to produce some funny Oopses. kernel BUG at fs/sysfs/symlink.c:88! invalid opcode: [#1] SMP d80211 stack is not SMP safe yet. Is this reproducible on non-SMP non-preemptible kernel without your base_addr patches? Thanks, Jiri -- 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
[PATCH updated] IB/mthca: comment fix
OK, the following makes it clear what the function does, from its name.
More comments?
---
After recent changes, mthca_wq_init does not actually initialize the WQ as it
used to - it simply resets all index fields to their initial values. So,
let's rename it to mthca_wq_reset.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c
b/drivers/infiniband/hw/mthca/mthca_qp.c
index 490fc78..cd8b672 100644
--- a/drivers/infiniband/hw/mthca/mthca_qp.c
+++ b/drivers/infiniband/hw/mthca/mthca_qp.c
@@ -222,9 +222,8 @@ static void *get_send_wqe(struct mthca_q
(PAGE_SIZE - 1));
}
-static void mthca_wq_init(struct mthca_wq *wq)
+static void mthca_wq_reset(struct mthca_wq *wq)
{
- /* mthca_alloc_qp_common() initializes the locks */
wq-next_ind = 0;
wq-last_comp = wq-max - 1;
wq-head = 0;
@@ -845,10 +844,10 @@ int mthca_modify_qp(struct ib_qp *ibqp,
mthca_cq_clean(dev, to_mcq(qp-ibqp.recv_cq), qp-qpn,
qp-ibqp.srq ? to_msrq(qp-ibqp.srq) :
NULL);
- mthca_wq_init(qp-sq);
+ mthca_wq_reset(qp-sq);
qp-sq.last = get_send_wqe(qp, qp-sq.max - 1);
- mthca_wq_init(qp-rq);
+ mthca_wq_reset(qp-rq);
qp-rq.last = get_recv_wqe(qp, qp-rq.max - 1);
if (mthca_is_memfree(dev)) {
@@ -1112,9 +,9 @@ static int mthca_alloc_qp_common(struct
qp-atomic_rd_en = 0;
qp-resp_depth = 0;
qp-sq_policy= send_policy;
- mthca_wq_init(qp-sq);
- mthca_wq_init(qp-rq);
- /* these are initialized separately so lockdep can tell them apart */
+ mthca_wq_reset(qp-sq);
+ mthca_wq_reset(qp-rq);
+
spin_lock_init(qp-sq.lock);
spin_lock_init(qp-rq.lock);
--
MST
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BPQ] lockdep: fix false positive
Bpqether is encapsulating AX.25 frames into ethernet frames. There is a
virtual bpqether device paired with each ethernet devices, so it's normal
to pass through dev_queue_xmit twice for each frame which triggers the
locking detector.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
---
drivers/net/hamradio/bpqether.c |7 +++
1 file changed, 7 insertions(+)
Index: linux-net/drivers/net/hamradio/bpqether.c
===
--- linux-net.orig/drivers/net/hamradio/bpqether.c 2006-07-09
02:47:59.0 +0100
+++ linux-net/drivers/net/hamradio/bpqether.c 2006-07-10 14:18:48.0
+0100
@@ -122,6 +122,12 @@ struct bpqdev {
static LIST_HEAD(bpq_devices);
+/*
+ * bpqether network devices are paired with ethernet devices below them, so
+ * form a special super class of normal ethernet devices; split their locks
+ * off into a separate class since they always nest.
+ */
+static struct lock_class_key bpq_netdev_xmit_lock_key;
/* */
@@ -528,6 +534,7 @@ static int bpq_new_device(struct net_dev
err = register_netdevice(ndev);
if (err)
goto error;
+ lockdep_set_class(ndev-_xmit_lock, bpq_netdev_xmit_lock_key);
/* List protected by RTNL */
list_add_rcu(bpq-bpq_list, bpq_devices);
-
To unsubscribe from this list: send 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] ixgb: fix tx unit hang - properly calculate desciptor count
Jeff,
Please apply to #upstream-fixes.
Cheers,
Auke
---
There were some tso bugs that only showed up with heavy load and 16kB
pages that this patch fixes by making the driver's internal use count
of descriptors match the count that it was estimating it needed using
the DESC_NEEDED macro. This bug caused NETDEV_WATCHDOG resets aka
tx timeouts.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/ixgb/ixgb_main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index b91e082..846e11b 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -1281,7 +1281,7 @@ ixgb_tx_map(struct ixgb_adapter *adapter
while(len) {
buffer_info = tx_ring-buffer_info[i];
- size = min(len, IXGB_MAX_JUMBO_FRAME_SIZE);
+ size = min(len, IXGB_MAX_DATA_PER_TXD);
buffer_info-length = size;
buffer_info-dma =
pci_map_single(adapter-pdev,
@@ -1306,7 +1306,7 @@ ixgb_tx_map(struct ixgb_adapter *adapter
while(len) {
buffer_info = tx_ring-buffer_info[i];
- size = min(len, IXGB_MAX_JUMBO_FRAME_SIZE);
+ size = min(len, IXGB_MAX_DATA_PER_TXD);
buffer_info-length = size;
buffer_info-dma =
pci_map_page(adapter-pdev,
Re: [PATCH] airo: make debug-like messages printed by airo_print_dbg()
Hi,
I regret making a mistake yesterday, I forgot a comma.
Here now is the working patch.
[PATCH] airo: collapse debugging-messages in issuecommand to one line
Robert Schulze
--- linux-2.6.17.1/drivers/net/wireless/airo.c.orig 2006-07-08
14:02:12.0 +0200
+++ linux-2.6.17.1/drivers/net/wireless/airo.c 2006-07-10 18:30:30.0
+0200
@@ -3897,11 +3897,10 @@ static u16 issuecommand(struct airo_info
pRsp-rsp1 = IN4500(ai, RESP1);
pRsp-rsp2 = IN4500(ai, RESP2);
if ((pRsp-status 0xff00)!=0 pCmd-cmd != CMD_SOFTRESET) {
- airo_print_err(ai-dev-name, cmd= %x\n, pCmd-cmd);
- airo_print_err(ai-dev-name, status= %x\n, pRsp-status);
- airo_print_err(ai-dev-name, Rsp0= %x\n, pRsp-rsp0);
- airo_print_err(ai-dev-name, Rsp1= %x\n, pRsp-rsp1);
- airo_print_err(ai-dev-name, Rsp2= %x\n, pRsp-rsp2);
+ airo_print_err(ai-dev-name,
+ cmd:%x status:%x rsp0:%x rsp1:%x rsp2:%x,
+ pCmd-cmd, pRsp-status, pRsp-rsp0, pRsp-rsp1,
+ pRsp-rsp2);
}
// clear stuck command busy if necessary
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
On Sun, 9 Jul 2006 10:49:31 +0200
Stefan Rompf [EMAIL PROTECTED] wrote:
Am Freitag, 7. Juli 2006 23:33 schrieb Stephen Hemminger:
Not really. The flag code last major change was to do the dormant
stuff that HDLC wanted.
... and where the maintainer doesn't seem to care to use it now that the
infrastructure is there. Sigh.
IMHO VLAN device's should mirror the state of the underlying physical
device.
I can't really follow the thread well. What is broken?
The thread is still quite short and describes the problem, look at
http://marc.theaimsgroup.com/?t=11520078264r=1w=2
Stefan
Okay, going back to the original problem, before the current round
of name calling. This bug shows a lot of problems with the existing
VLAN device state management.
1. I think vlan code should never be using the state bits directly at all.
It makes the code error prone if the bits ever change, and it means
that the proper callbacks are not being done. The existing
vlan_transfer_operstate
does what you want. VLAN_LINK_STATE_MASK etc, should go.
2. The vlan device should not be marked as up when it
is registered. Couldn't it wait for the user to bring it up?
If you want to automagically bring the device up, you need to call
dev_open() so that all the proper notifier's get called.
3. All checks for IFF_UP should be using netif_running instead.
IFF_UP is a leftover BSDism.
Instead of:
int vlan_dev_open(struct net_device *dev)
{
if (!(VLAN_DEV_INFO(dev)-real_dev-flags IFF_UP))
return -ENETDOWN;
return 0;
}
Use:
int vlan_dev_open(struct net_device *dev)
{
return netif_running(VLAN_DEV_INFO(dev)-real_dev) ? 0 : -ENETDOWN;
}
--
Stephen Hemminger [EMAIL PROTECTED]
Quis custodiet ipsos custodes?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
Stephen Hemminger wrote:
On Sun, 9 Jul 2006 10:49:31 +0200
Stefan Rompf [EMAIL PROTECTED] wrote:
Am Freitag, 7. Juli 2006 23:33 schrieb Stephen Hemminger:
Not really. The flag code last major change was to do the dormant
stuff that HDLC wanted.
... and where the maintainer doesn't seem to care to use it now that the
infrastructure is there. Sigh.
IMHO VLAN device's should mirror the state of the underlying physical
device.
I can't really follow the thread well. What is broken?
The thread is still quite short and describes the problem, look at
http://marc.theaimsgroup.com/?t=11520078264r=1w=2
Stefan
Okay, going back to the original problem, before the current round
of name calling. This bug shows a lot of problems with the existing
VLAN device state management.
1. I think vlan code should never be using the state bits directly at all.
It makes the code error prone if the bits ever change, and it means
that the proper callbacks are not being done. The existing
vlan_transfer_operstate
does what you want. VLAN_LINK_STATE_MASK etc, should go.
2. The vlan device should not be marked as up when it
is registered. Couldn't it wait for the user to bring it up?
If you want to automagically bring the device up, you need to call
dev_open() so that all the proper notifier's get called.
This sounds good to me.
3. All checks for IFF_UP should be using netif_running instead.
IFF_UP is a leftover BSDism.
That also sounds good.
Instead of:
int vlan_dev_open(struct net_device *dev)
{
if (!(VLAN_DEV_INFO(dev)-real_dev-flags IFF_UP))
return -ENETDOWN;
return 0;
}
Use:
int vlan_dev_open(struct net_device *dev)
{
return netif_running(VLAN_DEV_INFO(dev)-real_dev) ? 0 : -ENETDOWN;
}
--
Ben Greear [EMAIL PROTECTED]
Candela Technologies Inc http://www.candelatech.com
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] do not allow IPW_2100=Y or IPW_2200=Y
Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel (not as a module). Unfortunately, such configuration does not work, because these drivers need a firmware, and it can't be loaded by userspace loader when userspace is not running. Is there better way of creating N/m config option? Signed-off-by: Pavel Machek [EMAIL PROTECTED] diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig index fa9d2c4..050febb 100644 --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -144,9 +144,14 @@ config PCMCIA_RAYCS comment Wireless 802.11b ISA/PCI cards support depends on NET_RADIO (ISA || PCI || PPC_PMAC || PCMCIA) + +config MODULE_ONLY + tristate + default m + config IPW2100 tristate Intel PRO/Wireless 2100 Network Connection - depends on NET_RADIO PCI + depends on NET_RADIO PCI MODULE_ONLY select FW_LOADER select IEEE80211 ---help--- @@ -200,7 +205,7 @@ config IPW2100_DEBUG config IPW2200 tristate Intel PRO/Wireless 2200BG and 2915ABG Network Connection - depends on NET_RADIO PCI + depends on NET_RADIO PCI MODULE_ONLY select FW_LOADER select IEEE80211 ---help--- -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y
Pavel Machek wrote: Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel (not as a module). Unfortunately, such configuration does not work, because these drivers need a firmware, and it can't be loaded by userspace loader when userspace is not running. False, initramfs... - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: active-backup/bonding with drivers not supporting set_mac_address()
From: Or Gerlitz [EMAIL PROTECTED] Date: Mon, 10 Jul 2006 16:43:36 +0300 (IDT) Looking on the linux bonding driver, it seems to unconditionally (*) assume that the enslaved device supports the set_mac_address call. From reading the doc (Documentation/networking/bonding.txt) i understand that it is **not** a must prerequisite for the active-backup mode, this is since there is at most one active slave at each point of time and as the doc states: when a failover occurs in active-backup mode, bonding will issue one or more gratuitous ARPs on the newly active slave. I'd like to get feedback from people here if you think it makes sense to change the bonding driver to actually allow for active-backup/bonding with network device drivers which does not support set_mac_address. Blindly dereferencing the -set_mac_address method is wrong, it does seem. Regardless of whether we add support for active-backup/bonding for devices without this method, in the mean time the bonding driver should check for whether that method is NULL and disallow the bond configuration if it is. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BPQ] lockdep: fix false positive
From: Ralf Baechle [EMAIL PROTECTED] Date: Mon, 10 Jul 2006 16:53:34 +0100 Bpqether is encapsulating AX.25 frames into ethernet frames. There is a virtual bpqether device paired with each ethernet devices, so it's normal to pass through dev_queue_xmit twice for each frame which triggers the locking detector. Signed-off-by: Ralf Baechle [EMAIL PROTECTED] Applied, thanks Ralf. - To unsubscribe from this list: send 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] Don't call request_region() for 3C90x chips
It's generally not a good idea to call request_region() on an address returned
by pci_iomap(), even less so on a MMIO address. And there was absolutely no
point in claiming the region already claimed by the PCI core, especially with
the same PCI generic owner's name. As this is the only case of the
must_free_region flag being set, this flag may go away as well...
Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/3c59x.c
===
--- linux-2.6.orig/drivers/net/3c59x.c
+++ linux-2.6/drivers/net/3c59x.c
@@ -630,7 +630,6 @@ struct vortex_private {
pm_state_valid:1, /*
pci_dev-saved_config_space has sane contents */
open:1,
medialock:1,
- must_free_region:1, /* Flag: if
zero, Cardbus owns the I/O region */
large_frames:1; /* accept large frames */
int drv_flags;
u16 status_enable;
@@ -1084,11 +1083,6 @@ static int __devinit vortex_probe1(struc
/* PCI-only startup logic */
if (pdev) {
- /* EISA resources already marked, so only PCI needs to do this
here */
- /* Ignore return value, because Cardbus drivers already
allocate for us */
- if (request_region(dev-base_addr, vci-io_size, print_name) !=
NULL)
- vp-must_free_region = 1;
-
/* enable bus-mastering if necessary */
if (vci-flags PCI_USES_MASTER)
pci_set_master(pdev);
@@ -1125,7 +1119,7 @@ static int __devinit vortex_probe1(struc
vp-rx_ring_dma);
retval = -ENOMEM;
if (vp-rx_ring == 0)
- goto free_region;
+ goto free_netdev;
vp-tx_ring = (struct boom_tx_desc *)(vp-rx_ring + RX_RING_SIZE);
vp-tx_ring_dma = vp-rx_ring_dma + sizeof(struct boom_rx_desc) *
RX_RING_SIZE;
@@ -1410,9 +1404,7 @@ free_ring:
+ sizeof(struct
boom_tx_desc) * TX_RING_SIZE,
vp-rx_ring,
vp-rx_ring_dma);
-free_region:
- if (vp-must_free_region)
- release_region(dev-base_addr, vci-io_size);
+free_netdev:
free_netdev(dev);
printk(KERN_ERR PFX vortex_probe1 fails. Returns %d\n, retval);
out:
@@ -3143,8 +3135,6 @@ static void __devexit vortex_remove_one(
+ sizeof(struct
boom_tx_desc) * TX_RING_SIZE,
vp-rx_ring,
vp-rx_ring_dma);
- if (vp-must_free_region)
- release_region(dev-base_addr, vp-io_size);
free_netdev(dev);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: active-backup/bonding with drivers not supporting set_mac_address()
Or Gerlitz [EMAIL PROTECTED] wrote: Looking on the linux bonding driver, it seems to unconditionally (*) assume that the enslaved device supports the set_mac_address call. From reading the doc (Documentation/networking/bonding.txt) i understand that it is **not** a must prerequisite for the active-backup mode, this is since there is at most one active slave at each point of time and as the doc states: when a failover occurs in active-backup mode, bonding will issue one or more gratuitous ARPs on the newly active slave. I think you're misreading the documentation a bit. Some specific modes (balance-alb, for example) require that the slave device driver support set_mac_address while the device is up. Many device drivers will only allow MAC changes while the device is down; those drivers won't work with the alb mode. The active-backup and other modes have always needed a set_mac functionality, but they don't require that the device be up when changing the MAC (those modes set the mac for a slave one time, during the enslavement process, and the device is down when this is done). The purpose of the gratuitous ARP is to update switch forwarding tables (i.e., announce that the device has moved from one port to another), not to announce a change of MAC address. I'd like to get feedback from people here if you think it makes sense to change the bonding driver to actually allow for active-backup/bonding with network device drivers which does not support set_mac_address. What network device drivers are there that don't permit ever changing the device MAC address? I think changing active-backup (as an example here) to cause a MAC change during failover will have some side effects and secondary requirements that aren't necessarily obvious. For example, the MAC of the bond itself will change during failover; I'm not sure right offhand what effect if any this might have on third parties. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] workaround zd1201 interference problem
- Forwarded message from Pavel Machek [EMAIL PROTECTED] - zd1201 has nasty tendency to emit magicall anti-wifi cloud when it is inserted into slot, but not used. Signed-off-by: Pavel Machek [EMAIL PROTECTED] --- linux-good/drivers/usb/net/zd1201.c 2006-03-30 13:51:58.0 +0200 +++ linux/drivers/net/wireless/zd1201.c 2006-06-15 23:28:04.0 +0200 @@ -1835,6 +1835,8 @@ zd-dev-name); usb_set_intfdata(interface, zd); + zd1201_enable(zd); /* zd1201 likes to startup enabled, interfering */ + zd1201_disable(zd); /* with all the wifis in range */ return 0; err_net: Pavel's patch is still the best thing proposed so far to resolve this issue, ugly as it may be. It does seem to fix a real issue. Is anyone gonna puke if a merge this? If so, where is your patch? John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: active-backup/bonding with drivers not supporting set_mac_address()
David Miller [EMAIL PROTECTED] wrote: [...] Regardless of whether we add support for active-backup/bonding for devices without this method, in the mean time the bonding driver should check for whether that method is NULL and disallow the bond configuration if it is. That's what it does; if a slave lacks a set_mac_address function, the enslavement fails. Changes to the MAC are done via dev_set_mac_address. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: active-backup/bonding with drivers not supporting set_mac_address()
From: Jay Vosburgh [EMAIL PROTECTED] Date: Mon, 10 Jul 2006 11:29:14 -0700 What network device drivers are there that don't permit ever changing the device MAC address? Good question. Look at a driver such as 3c509.c, for example. Sure, it will get the default eth_mac_addr() software implementation, but this is not going to do what you expect. It may change the dev-dev_addr[] value, and change the MAC address used on outgoing packets, but it is unlikely to make the device actually receive packets with the MAC address in non-promiscuous mode. If the driver isn't setting up an explicit -set_mac_address handler, it isn't going to be programming the RX MAC of the chip and therefore not recognize packets to that new MAC as destined for 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: active-backup/bonding with drivers not supporting set_mac_address()
From: Jay Vosburgh [EMAIL PROTECTED] Date: Mon, 10 Jul 2006 11:31:48 -0700 David Miller [EMAIL PROTECTED] wrote: [...] Regardless of whether we add support for active-backup/bonding for devices without this method, in the mean time the bonding driver should check for whether that method is NULL and disallow the bond configuration if it is. That's what it does; if a slave lacks a set_mac_address function, the enslavement fails. Changes to the MAC are done via dev_set_mac_address. Ok, please see my other comments about the ramifications of devices that end up with the default eth_mac_addr() software implementation. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] let BT_HIDP depend on INPUT
This patch let's BT_HIDP depend on instead of select INPUT. This fixes the following warning during an s390 build: -- snip -- ... net/bluetooth/hidp/Kconfig:4:warning: 'select' used by config symbol 'BT_HIDP' refer to undefined symbol 'INPUT' ... -- snip -- A dependency on INPUT also implies !S390 (and therefore makes the explicit dependency obsolete) since INPUT is not available on s390. The practical difference should be nearly zero, since INPUT is always set to y unless EMBEDDED=y (or S390=y). Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- linux-2.6.18-rc1-mm1-full/net/bluetooth/hidp/Kconfig.old2006-07-10 16:51:59.0 +0200 +++ linux-2.6.18-rc1-mm1-full/net/bluetooth/hidp/Kconfig2006-07-10 16:52:52.0 +0200 @@ -1,7 +1,6 @@ config BT_HIDP tristate HIDP protocol support - depends on BT BT_L2CAP (BROKEN || !S390) - select INPUT + depends on INPUT BT BT_L2CAP help HIDP (Human Interface Device Protocol) is a transport layer for HID reports. HIDP is required for the Bluetooth Human - To unsubscribe from this list: send the 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] do not allow IPW_2100=Y or IPW_2200=Y
Jeff Garzik wrote: Pavel Machek wrote: Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel (not as a module). Unfortunately, such configuration does not work, because these drivers need a firmware, and it can't be loaded by userspace loader when userspace is not running. False, initramfs... which would warrant some extra documentation in Kconfig explaining that this driver needs initramfs with firmware for it to work when compiled in the kernel. A link to the ipw2x00 documentation might also help. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y
From: Auke Kok [EMAIL PROTECTED] Date: Mon, 10 Jul 2006 11:29:30 -0700 Jeff Garzik wrote: Pavel Machek wrote: Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel (not as a module). Unfortunately, such configuration does not work, because these drivers need a firmware, and it can't be loaded by userspace loader when userspace is not running. False, initramfs... which would warrant some extra documentation in Kconfig explaining that this driver needs initramfs with firmware for it to work when compiled in the kernel. A link to the ipw2x00 documentation might also help. Besides, the initramfs runs long after the driver init routine runs which is when the firmware needs to be available. - To unsubscribe from this list: send the 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] do not allow IPW_2100=Y or IPW_2200=Y
On Mon, 2006-07-10 at 11:47 -0700, David Miller wrote: From: Auke Kok [EMAIL PROTECTED] Date: Mon, 10 Jul 2006 11:29:30 -0700 Jeff Garzik wrote: Pavel Machek wrote: Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel (not as a module). Unfortunately, such configuration does not work, because these drivers need a firmware, and it can't be loaded by userspace loader when userspace is not running. False, initramfs... which would warrant some extra documentation in Kconfig explaining that this driver needs initramfs with firmware for it to work when compiled in the kernel. A link to the ipw2x00 documentation might also help. Besides, the initramfs runs long after the driver init routine runs which is when the firmware needs to be available. .. unless you use sysfs to do a fake hotunplug + replug the device, at which point the driver init routine runs again. - To unsubscribe from this list: send the 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.18-rc1-mm1 inconsistent lock state in netpoll_send_skb
Le 10.07.2006 10:40, Arjan van de Ven a écrit :
On Sun, 2006-07-09 at 23:37 +0200, Laurent Riffard wrote:
ei_start_xmit
please try this patch
---
drivers/net/8390.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-2.6.17-mm4/drivers/net/8390.c
===
--- linux-2.6.17-mm4.orig/drivers/net/8390.c
+++ linux-2.6.17-mm4/drivers/net/8390.c
@@ -299,7 +299,7 @@ static int ei_start_xmit(struct sk_buff
* Slow phase with lock held.
*/
- disable_irq_nosync(dev-irq);
+ disable_irq_nosync_lockdep(dev-irq);
spin_lock(ei_local-page_lock);
@@ -338,7 +338,7 @@ static int ei_start_xmit(struct sk_buff
netif_stop_queue(dev);
outb_p(ENISR_ALL, e8390_base + EN0_IMR);
spin_unlock(ei_local-page_lock);
- enable_irq(dev-irq);
+ enable_irq_lockdep(dev-irq);
ei_local-stat.tx_errors++;
return 1;
}
@@ -379,7 +379,7 @@ static int ei_start_xmit(struct sk_buff
outb_p(ENISR_ALL, e8390_base + EN0_IMR);
spin_unlock(ei_local-page_lock);
- enable_irq(dev-irq);
+ enable_irq_lockdep(dev-irq);
dev_kfree_skb (skb);
ei_local-stat.tx_bytes += send_length;
@@ -505,9 +505,9 @@ irqreturn_t ei_interrupt(int irq, void *
#ifdef CONFIG_NET_POLL_CONTROLLER
void ei_poll(struct net_device *dev)
{
- disable_irq(dev-irq);
+ disable_irq_lockdep(dev-irq);
ei_interrupt(dev-irq, dev, NULL);
- enable_irq(dev-irq);
+ enable_irq_lockdep(dev-irq);
}
#endif
Reversed (or previously applied) patch detected!
Wrong patch ? This one won't apply, it seems to be already
applied to 2.6.18-rc1-mm1.
--
laurent
-
To unsubscribe from this list: send the 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] let BT_HIDP depend on INPUT
Hi Adrian, This patch let's BT_HIDP depend on instead of select INPUT. This fixes the following warning during an s390 build: -- snip -- ... net/bluetooth/hidp/Kconfig:4:warning: 'select' used by config symbol 'BT_HIDP' refer to undefined symbol 'INPUT' ... -- snip -- A dependency on INPUT also implies !S390 (and therefore makes the explicit dependency obsolete) since INPUT is not available on s390. The practical difference should be nearly zero, since INPUT is always set to y unless EMBEDDED=y (or S390=y). I actually have no idea why we ended up with using select, but depends is also fine by me. Except I like to see it BT BT_L2CAP INPUT ;) Regards Marcel - To unsubscribe from this list: send 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] IB/addr: gid structure alignment fix
Hello, Andrew!
Could you please drop the following in -mm and on to Linus?
---
The device address contains unsigned character arrays, which contain raw GID
addresses. The GIDs may not be naturally aligned, so do not cast them to
structures or unions.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: gitcma/include/rdma/ib_addr.h
===
--- gitcma.orig/include/rdma/ib_addr.h 2006-07-09 23:41:27.0 +0300
+++ gitcma/include/rdma/ib_addr.h 2006-07-09 23:51:23.0 +0300
@@ -89,9 +89,10 @@ static inline void ib_addr_set_pkey(stru
dev_addr-broadcast[9] = (unsigned char) pkey;
}
-static inline union ib_gid *ib_addr_get_sgid(struct rdma_dev_addr *dev_addr)
+static inline void ib_addr_get_sgid(struct rdma_dev_addr *dev_addr,
+ union ib_gid *gid)
{
- return (union ib_gid *) (dev_addr-src_dev_addr + 4);
+ memcpy(gid, dev_addr-src_dev_addr + 4, sizeof *gid);
}
static inline void ib_addr_set_sgid(struct rdma_dev_addr *dev_addr,
@@ -100,9 +101,10 @@ static inline void ib_addr_set_sgid(stru
memcpy(dev_addr-src_dev_addr + 4, gid, sizeof *gid);
}
-static inline union ib_gid *ib_addr_get_dgid(struct rdma_dev_addr *dev_addr)
+static inline void ib_addr_get_dgid(struct rdma_dev_addr *dev_addr,
+ union ib_gid *gid)
{
- return (union ib_gid *) (dev_addr-dst_dev_addr + 4);
+ memcpy(gid, dev_addr-dst_dev_addr + 4, sizeof *gid);
}
static inline void ib_addr_set_dgid(struct rdma_dev_addr *dev_addr,
Index: gitcma/drivers/infiniband/core/cma.c
===
--- gitcma.orig/drivers/infiniband/core/cma.c 2006-07-09 23:41:26.0
+0300
+++ gitcma/drivers/infiniband/core/cma.c2006-07-09 23:51:23.0
+0300
@@ -262,14 +262,14 @@ static void cma_detach_from_dev(struct r
static int cma_acquire_ib_dev(struct rdma_id_private *id_priv)
{
struct cma_device *cma_dev;
- union ib_gid *gid;
+ union ib_gid gid;
int ret = -ENODEV;
- gid = ib_addr_get_sgid(id_priv-id.route.addr.dev_addr);
+ ib_addr_get_sgid(id_priv-id.route.addr.dev_addr, gid),
mutex_lock(lock);
list_for_each_entry(cma_dev, dev_list, list) {
- ret = ib_find_cached_gid(cma_dev-device, gid,
+ ret = ib_find_cached_gid(cma_dev-device, gid,
id_priv-id.port_num, NULL);
if (!ret) {
cma_attach_to_dev(id_priv, cma_dev);
@@ -1134,8 +1134,8 @@ static int cma_query_ib_route(struct rdm
struct ib_sa_path_rec path_rec;
memset(path_rec, 0, sizeof path_rec);
- path_rec.sgid = *ib_addr_get_sgid(addr);
- path_rec.dgid = *ib_addr_get_dgid(addr);
+ ib_addr_get_sgid(addr, path_rec.sgid);
+ ib_addr_get_dgid(addr, path_rec.dgid);
path_rec.pkey = cpu_to_be16(ib_addr_get_pkey(addr));
path_rec.numb_path = 1;
@@ -1263,7 +1263,7 @@ static int cma_bind_loopback(struct rdma
{
struct cma_device *cma_dev;
struct ib_port_attr port_attr;
- union ib_gid *gid;
+ union ib_gid gid;
u16 pkey;
int ret;
u8 p;
@@ -1284,8 +1284,7 @@ static int cma_bind_loopback(struct rdma
}
port_found:
- gid = ib_addr_get_sgid(id_priv-id.route.addr.dev_addr);
- ret = ib_get_cached_gid(cma_dev-device, p, 0, gid);
+ ret = ib_get_cached_gid(cma_dev-device, p, 0, gid);
if (ret)
goto out;
@@ -1293,6 +1292,7 @@ port_found:
if (ret)
goto out;
+ ib_addr_set_sgid(id_priv-id.route.addr.dev_addr, gid);
ib_addr_set_pkey(id_priv-id.route.addr.dev_addr, pkey);
id_priv-id.port_num = p;
cma_attach_to_dev(id_priv, cma_dev);
@@ -1339,6 +1339,7 @@ static int cma_resolve_loopback(struct r
{
struct cma_work *work;
struct sockaddr_in *src_in, *dst_in;
+ union ib_gid gid;
int ret;
work = kzalloc(sizeof *work, GFP_KERNEL);
@@ -1351,8 +1352,8 @@ static int cma_resolve_loopback(struct r
goto err;
}
- ib_addr_set_dgid(id_priv-id.route.addr.dev_addr,
-ib_addr_get_sgid(id_priv-id.route.addr.dev_addr));
+ ib_addr_get_sgid(id_priv-id.route.addr.dev_addr, gid);
+ ib_addr_set_dgid(id_priv-id.route.addr.dev_addr, gid);
if (cma_zero_addr(id_priv-id.route.addr.src_addr)) {
src_in = (struct sockaddr_in *)id_priv-id.route.addr.src_addr;
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
- End forwarded message -
--
MST
[PATCH] IB/cm: drop REQ when out of memory
Hello Andrew!
Could you please drop the following in -mm and on to Linus?
---
If a user of the IB CM returns -ENOMEM from their connection callback,
simply drop the incoming REQ - do not attempt to send a reject. This should
allow the sender to retry the request.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
Index: l/drivers/infiniband/core/cm.c
===
--- l/drivers/infiniband/core/cm.c (revision 8224)
+++ l/drivers/infiniband/core/cm.c (working copy)
@@ -702,7 +702,7 @@ static void cm_reset_to_idle(struct cm_i
}
}
-void ib_destroy_cm_id(struct ib_cm_id *cm_id)
+static void cm_destroy_id(struct ib_cm_id *cm_id, int err)
{
struct cm_id_private *cm_id_priv;
struct cm_work *work;
@@ -736,12 +736,22 @@ retest:
sizeof cm_id_priv-av.port-cm_dev-ca_guid,
NULL, 0);
break;
+ case IB_CM_REQ_RCVD:
+ if (err == -ENOMEM) {
+ /* Do not reject to allow future retries. */
+ cm_reset_to_idle(cm_id_priv);
+ spin_unlock_irqrestore(cm_id_priv-lock, flags);
+ } else {
+ spin_unlock_irqrestore(cm_id_priv-lock, flags);
+ ib_send_cm_rej(cm_id, IB_CM_REJ_CONSUMER_DEFINED,
+ NULL, 0, NULL, 0);
+ }
+ break;
case IB_CM_MRA_REQ_RCVD:
case IB_CM_REP_SENT:
case IB_CM_MRA_REP_RCVD:
ib_cancel_mad(cm_id_priv-av.port-mad_agent, cm_id_priv-msg);
/* Fall through */
- case IB_CM_REQ_RCVD:
case IB_CM_MRA_REQ_SENT:
case IB_CM_REP_RCVD:
case IB_CM_MRA_REP_SENT:
@@ -776,6 +786,11 @@ retest:
kfree(cm_id_priv-private_data);
kfree(cm_id_priv);
}
+
+void ib_destroy_cm_id(struct ib_cm_id *cm_id)
+{
+ cm_destroy_id(cm_id, 0);
+}
EXPORT_SYMBOL(ib_destroy_cm_id);
int ib_cm_listen(struct ib_cm_id *cm_id, __be64 service_id, __be64
service_mask,
@@ -1164,7 +1179,7 @@ static void cm_process_work(struct cm_id
}
cm_deref_id(cm_id_priv);
if (ret)
- ib_destroy_cm_id(cm_id_priv-id);
+ cm_destroy_id(cm_id_priv-id, ret);
}
static void cm_format_mra(struct cm_mra_msg *mra_msg,
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
- End forwarded message -
--
MST
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] let BT_HIDP depend on INPUT
On Mon, Jul 10, 2006 at 09:07:20PM +0200, Marcel Holtmann wrote: Hi Adrian, This patch let's BT_HIDP depend on instead of select INPUT. This fixes the following warning during an s390 build: -- snip -- ... net/bluetooth/hidp/Kconfig:4:warning: 'select' used by config symbol 'BT_HIDP' refer to undefined symbol 'INPUT' ... -- snip -- A dependency on INPUT also implies !S390 (and therefore makes the explicit dependency obsolete) since INPUT is not available on s390. The practical difference should be nearly zero, since INPUT is always set to y unless EMBEDDED=y (or S390=y). I actually have no idea why we ended up with using select, but depends is also fine by me. Except I like to see it BT BT_L2CAP INPUT ;) Updated patch below. Regards Marcel cu Adrian -- snip -- This patch lets BT_HIDP depend on instead of select INPUT. This fixes the following warning during an s390 build: -- snip -- ... net/bluetooth/hidp/Kconfig:4:warning: 'select' used by config symbol 'BT_HIDP' r efer to undefined symbol 'INPUT' ... -- snip -- A dependency on INPUT also implies !S390 (and therefore makes the explicit dependency obsolete) since INPUT is not available on s390. The practical difference should be nearly zero, since INPUT is always set to y unless EMBEDDED=y (or S390=y). Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- linux-2.6.18-rc1-mm1-full/net/bluetooth/hidp/Kconfig.old2006-07-10 16:51:59.0 +0200 +++ linux-2.6.18-rc1-mm1-full/net/bluetooth/hidp/Kconfig2006-07-10 21:21:46.0 +0200 @@ -1,7 +1,6 @@ config BT_HIDP tristate HIDP protocol support - depends on BT BT_L2CAP (BROKEN || !S390) - select INPUT + depends on BT BT_L2CAP INPUT help HIDP (Human Interface Device Protocol) is a transport layer for HID reports. HIDP is required for the Bluetooth Human - To unsubscribe from this list: send 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] srp: fix fmr error handling
Andrew, could you pls drop the following in -mm and on to Linus?
---
From: Vu Pham [EMAIL PROTECTED]
srp_unmap_data assumes req-fmr is NULL if the request is not mapped,
so we must clean it out in case of an error.
Signed-off-by: Vu Pham [EMAIL PROTECTED]
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Acked-by: Roland Dreier [EMAIL PROTECTED]
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index 4e22afe..8f472e7 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -615,9 +615,10 @@ static int srp_map_fmr(struct srp_device
(sg_dma_address(scat[i]) dev-fmr_page_mask)
+ j;
req-fmr = ib_fmr_pool_map_phys(dev-fmr_pool,
dma_pages, page_cnt, io_addr);
if (IS_ERR(req-fmr)) {
ret = PTR_ERR(req-fmr);
+ req-fmr = NULL;
goto out;
}
--
MST
- End forwarded message -
--
MST
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y
On Mon, Jul 10, 2006 at 08:51:58PM +0200, Arjan van de Ven wrote: Besides, the initramfs runs long after the driver init routine runs which is when the firmware needs to be available. .. unless you use sysfs to do a fake hotunplug + replug the device, at which point the driver init routine runs again. Can we document how to do that? I've wanted to synthesize such things before, and I couldn't quite reason how. In my case, I had RHEL4 module-init-tools that don't wait for modprobe, so I had to compile in scsi and qla2x00, but the qla2x00 needs firmware, and it's too early...etc. Joel -- Baby, even the losers Get luck sometimes. Even the losers Keep a little bit of pride. Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the 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] do not allow IPW_2100=Y or IPW_2200=Y
On Monday 10 July 2006 19:53, you wrote: Pavel Machek wrote: Kconfig currently allows compiling IPW_2100 and IPW_2200 into kernel (not as a module). Unfortunately, such configuration does not work, because these drivers need a firmware, and it can't be loaded by userspace loader when userspace is not running. False, initramfs... Does the ipw driver _really_ need the firmware on insmod time? bcm43xx, for example, loads the firmware on ifconfig up time. If ipw really needs the firmware on insmod, is it possible to defer it to later at ifconfig up time? -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] IB/mthca: comment fix
OK, this is fine with both Arjan van de Ven and Roland Dreier, so -
Andrew, could you take this into -mm please?
---
After recent changes, mthca_wq_init does not actually initialize the WQ as it
used to - it simply resets all index fields to their initial values. So,
let's rename it to mthca_wq_reset.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c
b/drivers/infiniband/hw/mthca/mthca_qp.c
index 490fc78..cd8b672 100644
--- a/drivers/infiniband/hw/mthca/mthca_qp.c
+++ b/drivers/infiniband/hw/mthca/mthca_qp.c
@@ -222,9 +222,8 @@ static void *get_send_wqe(struct mthca_q
(PAGE_SIZE - 1));
}
-static void mthca_wq_init(struct mthca_wq *wq)
+static void mthca_wq_reset(struct mthca_wq *wq)
{
- /* mthca_alloc_qp_common() initializes the locks */
wq-next_ind = 0;
wq-last_comp = wq-max - 1;
wq-head = 0;
@@ -845,10 +844,10 @@ int mthca_modify_qp(struct ib_qp *ibqp,
mthca_cq_clean(dev, to_mcq(qp-ibqp.recv_cq), qp-qpn,
qp-ibqp.srq ? to_msrq(qp-ibqp.srq) :
NULL);
- mthca_wq_init(qp-sq);
+ mthca_wq_reset(qp-sq);
qp-sq.last = get_send_wqe(qp, qp-sq.max - 1);
- mthca_wq_init(qp-rq);
+ mthca_wq_reset(qp-rq);
qp-rq.last = get_recv_wqe(qp, qp-rq.max - 1);
if (mthca_is_memfree(dev)) {
@@ -1112,9 +,9 @@ static int mthca_alloc_qp_common(struct
qp-atomic_rd_en = 0;
qp-resp_depth = 0;
qp-sq_policy= send_policy;
- mthca_wq_init(qp-sq);
- mthca_wq_init(qp-rq);
- /* these are initialized separately so lockdep can tell them apart */
+ mthca_wq_reset(qp-sq);
+ mthca_wq_reset(qp-rq);
+
spin_lock_init(qp-sq.lock);
spin_lock_init(qp-rq.lock);
--
MST
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please pull 'upstream-fixes' branch of wireless-2.6
The following changes since commit 120bda20c6f64b32e8bfbdd7b34feafaa5f5332e: Linus Torvalds: Linux 2.6.18-rc1 are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-fixes Daniel Drake: zd1211rw: usb_clear_halt not allowed in IRQ context Larry Finger: bcm43xx-softmac: Fix an off-by-one condition in handle_irq_noise drivers/net/wireless/bcm43xx/bcm43xx_main.c |2 +- drivers/net/wireless/zd1211rw/zd_usb.c | 12 +++- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/bcm43xx/bcm43xx_main.c index e1c5a93..3889f79 100644 --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c @@ -1547,7 +1547,7 @@ static void handle_irq_noise(struct bcm4 goto generate_new; /* Get the noise samples. */ - assert(bcm-noisecalc.nr_samples = 8); + assert(bcm-noisecalc.nr_samples 8); i = bcm-noisecalc.nr_samples; noise[0] = limit_value(noise[0], 0, ARRAY_SIZE(radio-nrssi_lt) - 1); noise[1] = limit_value(noise[1], 0, ARRAY_SIZE(radio-nrssi_lt) - 1); diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c index ce1cb2c..72f9052 100644 --- a/drivers/net/wireless/zd1211rw/zd_usb.c +++ b/drivers/net/wireless/zd1211rw/zd_usb.c @@ -375,10 +375,8 @@ static void int_urb_complete(struct urb case -ENODEV: case -ENOENT: case -ECONNRESET: - goto kfree; case -EPIPE: - usb_clear_halt(urb-dev, EP_INT_IN); - /* FALL-THROUGH */ + goto kfree; default: goto resubmit; } @@ -580,10 +578,8 @@ static void rx_urb_complete(struct urb * case -ENODEV: case -ENOENT: case -ECONNRESET: - return; case -EPIPE: - usb_clear_halt(urb-dev, EP_DATA_IN); - /* FALL-THROUGH */ + return; default: dev_dbg_f(urb_dev(urb), urb %p error %d\n, urb, urb-status); goto resubmit; @@ -749,11 +745,9 @@ static void tx_urb_complete(struct urb * case -ENODEV: case -ENOENT: case -ECONNRESET: + case -EPIPE: dev_dbg_f(urb_dev(urb), urb %p error %d\n, urb, urb-status); break; - case -EPIPE: - usb_clear_halt(urb-dev, EP_DATA_OUT); - /* FALL-THROUGH */ default: dev_dbg_f(urb_dev(urb), urb %p error %d\n, urb, urb-status); goto resubmit; -- John W. Linville [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
Please pull 'upstream' branch of wireless-2.6
These patches are to be queued for 2.6.19...
---
The following changes since commit b312d799b324e895745ffe148def234fc60d5b74:
Daniel Drake:
zd1211rw: usb_clear_halt not allowed in IRQ context
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream
Daniel Drake:
zd1211rw: Add Sagem device ID's
Larry Finger:
bcm43xx: improved statistics
Michael Buesch:
bcm43xx: opencoded locking
bcm43xx: voluntary preemtion in the calibration loops
drivers/net/wireless/bcm43xx/bcm43xx.h | 64 ++---
drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c | 34 +++--
drivers/net/wireless/bcm43xx/bcm43xx_leds.c| 10 +
drivers/net/wireless/bcm43xx/bcm43xx_main.c| 64 +
drivers/net/wireless/bcm43xx/bcm43xx_phy.c | 33 +++--
drivers/net/wireless/bcm43xx/bcm43xx_pio.c |4 -
drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c | 34 +++--
drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 162 ++--
drivers/net/wireless/zd1211rw/zd_usb.c |2
9 files changed, 215 insertions(+), 192 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx.h
b/drivers/net/wireless/bcm43xx/bcm43xx.h
index 17a5682..ee6571e 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -649,6 +649,19 @@ enum {
#define bcm43xx_status(bcm)atomic_read((bcm)-init_status)
#define bcm43xx_set_status(bcm, stat) atomic_set((bcm)-init_status, (stat))
+/**** THEORY OF LOCKING ***
+ *
+ * We have two different locks in the bcm43xx driver.
+ * = bcm-mutex:General sleeping mutex. Protects struct bcm43xx_private
+ * and the device registers. This mutex does _not_ protect
+ * against concurrency from the IRQ handler.
+ * = bcm-irq_lock: IRQ spinlock. Protects against IRQ handler concurrency.
+ *
+ * Please note that, if you only take the irq_lock, you are not protected
+ * against concurrency from the periodic work handlers.
+ * Most times you want to take _both_ locks.
+ */
+
struct bcm43xx_private {
struct ieee80211_device *ieee;
struct ieee80211softmac_device *softmac;
@@ -659,7 +672,6 @@ struct bcm43xx_private {
void __iomem *mmio_addr;
- /* Locking, see theory of locking text below. */
spinlock_t irq_lock;
struct mutex mutex;
@@ -691,6 +703,7 @@ struct bcm43xx_private {
struct bcm43xx_sprominfo sprom;
#define BCM43xx_NR_LEDS4
struct bcm43xx_led leds[BCM43xx_NR_LEDS];
+ spinlock_t leds_lock;
/* The currently active core. */
struct bcm43xx_coreinfo *current_core;
@@ -763,55 +776,6 @@ #endif
};
-/**** THEORY OF LOCKING ***
- *
- * We have two different locks in the bcm43xx driver.
- * = bcm-mutex:General sleeping mutex. Protects struct bcm43xx_private
- * and the device registers.
- * = bcm-irq_lock: IRQ spinlock. Protects against IRQ handler concurrency.
- *
- * We have three types of helper function pairs to utilize these locks.
- * (Always use the helper functions.)
- * 1) bcm43xx_{un}lock_noirq():
- * Takes bcm-mutex. Does _not_ protect against IRQ concurrency,
- * so it is almost always unsafe, if device IRQs are enabled.
- * So only use this, if device IRQs are masked.
- * Locking may sleep.
- * You can sleep within the critical section.
- * 2) bcm43xx_{un}lock_irqonly():
- * Takes bcm-irq_lock. Does _not_ protect against
- * bcm43xx_lock_noirq() critical sections.
- * Does only protect against the IRQ handler path and other
- * irqonly() critical sections.
- * Locking does not sleep.
- * You must not sleep within the critical section.
- * 3) bcm43xx_{un}lock_irqsafe():
- * This is the cummulative lock and takes both, mutex and irq_lock.
- * Protects against noirq() and irqonly() critical sections (and
- * the IRQ handler path).
- * Locking may sleep.
- * You must not sleep within the critical section.
- */
-
-/* Lock type 1 */
-#define bcm43xx_lock_noirq(bcm)mutex_lock((bcm)-mutex)
-#define bcm43xx_unlock_noirq(bcm) mutex_unlock((bcm)-mutex)
-/* Lock type 2 */
-#define bcm43xx_lock_irqonly(bcm, flags) \
- spin_lock_irqsave((bcm)-irq_lock, flags)
-#define bcm43xx_unlock_irqonly(bcm, flags) \
- spin_unlock_irqrestore((bcm)-irq_lock, flags)
-/* Lock type 3 */
-#define bcm43xx_lock_irqsafe(bcm, flags) do { \
- bcm43xx_lock_noirq(bcm);\
- bcm43xx_lock_irqonly(bcm, flags); \
- } while (0)
-#define bcm43xx_unlock_irqsafe(bcm, flags) do {\
- bcm43xx_unlock_irqonly(bcm, flags); \
- bcm43xx_unlock_noirq(bcm); \
- } while (0)
-
-
static inline
struct bcm43xx_private * bcm43xx_priv(struct net_device *dev)
{
diff --git
Re: Please pull 'upstream' branch of wireless-2.6
On Monday 10 July 2006 23:31, you wrote: These patches are to be queued for 2.6.19... --- The following changes since commit b312d799b324e895745ffe148def234fc60d5b74: Daniel Drake: zd1211rw: usb_clear_halt not allowed in IRQ context are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream Daniel Drake: zd1211rw: Add Sagem device ID's Larry Finger: bcm43xx: improved statistics Larry, I see that several patches from you got merged now. Please make sure that you also submit patches for bcm43xx-d80211. If you don't, your changes will all be lost, as soon as bcm43xx-d80211 is merged upstream and softmac is dropped. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'upstream' branch of wireless-2.6
Michael Buesch wrote: On Monday 10 July 2006 23:31, you wrote: Larry, I see that several patches from you got merged now. Please make sure that you also submit patches for bcm43xx-d80211. If you don't, your changes will all be lost, as soon as bcm43xx-d80211 is merged upstream and softmac is dropped. Will do. A couple of days ago I downloaded a copy of the wireless-dev repository, and now have the master code so that I can prepare the patches. Will the upstream merge of d80211 be made for 2.6.19 or later? Larry - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
Am Montag, 10. Juli 2006 14:01 schrieb Krzysztof Halasa: You've got two independant flags of which one does not stop the queue. Is it ok to set that flag without synchronization with other flags? I.e, from within another module and without using cross-module locks, as I've shown at the time? Just asking, I don't know what the final conclusion was. I.e., is it ok if the hardware module does netif_carrier_on/off() (for example, from its IRQ handler) and if the protocol module does netif_dormant_on/off() independently (for example, from its timer or linkwatch)? Yes, you can read and write these flags independantly. For the details, look at Documentation/networking/operstates.txt in the 2.6.17 tree. 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: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
Am Montag, 10. Juli 2006 18:56 schrieb Stephen Hemminger: 1. I think vlan code should never be using the state bits directly at all. It makes the code error prone if the bits ever change, and it means that the proper callbacks are not being done. The existing vlan_transfer_operstate does what you want. VLAN_LINK_STATE_MASK etc, should go. I just realized why 2.6.16 explicitely transfers LINK_STATE_PRESENT. This flag is positive true, and the code just assumes that it is always set in real_dev: new_dev-state = real_dev-state VLAN_LINK_STATE_INITIAL_MASK; So I think the fix for 2.6.17-stable should be: - new_dev-state = real_dev-state ~(1__LINK_STATE_START); + new_dev-state = real_dev-state (1__LINK_STATE_NOCARRIER) | (1__LINK_STATE_DORMANT)) | (1__LINK_STATE_PRESENT); , dropping VLAN_LINK_STATE_INITIAL_MASK. I can produce and test such a patch tomorrow evening, if someone needs it faster, feel free to go ahead ;-) For the rest of your comment and 3. All checks for IFF_UP should be using netif_running instead. IFF_UP is a leftover BSDism. ACK. However, 2. The vlan device should not be marked as up when it is registered. this is a userspace visible API change I don't like, but you are right it should use dev_open(). I would take responsibility to implement this on one of the next two weekends. Should be 2.6.19 stuff IMHO. 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: [PATCH] ipv6: order addresses by scope
From: Brian Haley [EMAIL PROTECTED] Date: Fri, 09 Jun 2006 14:14:50 -0400 If IPv6 addresses are ordered by scope, then ipv6_dev_get_saddr() can break-out of the device addr_list for() loop when the candidate source address scope is less than the destination address scope. Signed-off-by: Brian Haley [EMAIL PROTECTED] This patch looks fine to me, it's an optimization and not a correctness issue. But I'd like an ACK from an ipv6 developer, such as Yoshifuji, before adding this patch. 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] ipv6: order addresses by scope
In article [EMAIL PROTECTED] (at Mon, 10 Jul 2006 15:00:45 -0700 (PDT)), David Miller [EMAIL PROTECTED] says: If IPv6 addresses are ordered by scope, then ipv6_dev_get_saddr() can break-out of the device addr_list for() loop when the candidate source address scope is less than the destination address scope. Signed-off-by: Brian Haley [EMAIL PROTECTED] This patch looks fine to me, it's an optimization and not a correctness issue. But I'd like an ACK from an ipv6 developer, such as Yoshifuji, before adding this patch. I agree, too. Note: People should not depend on the order of addresses. Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] --yoshfuji - To unsubscribe from this list: send the 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] ipv6: order addresses by scope
From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Mon, 10 Jul 2006 18:18:16 -0400 (EDT) In article [EMAIL PROTECTED] (at Mon, 10 Jul 2006 15:00:45 -0700 (PDT)), David Miller [EMAIL PROTECTED] says: If IPv6 addresses are ordered by scope, then ipv6_dev_get_saddr() can break-out of the device addr_list for() loop when the candidate source address scope is less than the destination address scope. Signed-off-by: Brian Haley [EMAIL PROTECTED] This patch looks fine to me, it's an optimization and not a correctness issue. But I'd like an ACK from an ipv6 developer, such as Yoshifuji, before adding this patch. I agree, too. Note: People should not depend on the order of addresses. Acked-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] Thank you for reviewing, patch 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
oops in current -git
I see a reproducible oops in the current -git. It occurs on an Fedora Core 5 box w/ 2.6.18-rc1-git (HEAD e2b209509ca33743864846aef2e1b2afc21f7915). The topmost information scrolls off the screen, so I don't know if its an oops or a BUG. What I do see: * FC5 boot proceeds normally, mounting local filesystems etc., until it reaches the step where it determines the network address for eth0 (8139too). * oops process shown as ipcalc * complete call trace: ip_generic_getfrag, udp_sendmsg, neigh_lookup, sock_sendmsg, find_get_page, autoremove_wake_function, __handle_mm_fault, sys_sendto, do_page_fault, sys_connect * This only occurs when I specify 'acpi=off'. If ACPI is enabled, the box boots and networks happily. Kernel .config is attached. I can't post dmesg or lspci for this machine publicly. It's a modern Intel EM64T class machine. Jeff # # Automatically generated make config: don't edit # Linux kernel version: 2.6.18-rc1 # Mon Jul 10 10:23:00 2006 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y # CONFIG_IKCONFIG is not set # CONFIG_CPUSETS is not set # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_UID16=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_RT_MUTEXES=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set CONFIG_MPSC=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_SCHED_SMT=y # CONFIG_SCHED_MC is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_BKL is not set # CONFIG_NUMA is not set CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_NR_CPUS=4 # CONFIG_HOTPLUG_CPU is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y # CONFIG_X86_MCE_AMD is not set # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_REORDER=y CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y CONFIG_GENERIC_PENDING_IRQ=y # # Power management options # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_AC=m # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=m # CONFIG_ACPI_VIDEO is not set # CONFIG_ACPI_HOTKEY is not set CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set
Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y
Is there better way of creating N/m config option? config IPW2100 tristate Intel PRO/Wireless 2100 Network Connection - depends on NET_RADIO PCI + depends on NET_RADIO PCI MODULE_ONLY depends on NET_RADIO PCI m Jan Engelhardt -- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] net/*/nf_conntrack_*.c:possible cleanups
This patch contains the following possible cleanups:
- make the following needlessly global functions static:
- net/netfilter/nf_conntrack_core.c: nf_conntrack_register_cache()
- net/netfilter/nf_conntrack_core.c: nf_conntrack_unregister_cache()
- net/netfilter/nf_conntrack_core.c: __nf_conntrack_attach()
- net/netfilter/nf_conntrack_core.c: set_hashsize()
- net/netfilter/nf_conntrack_proto_sctp.c: nf_conntrack_proto_sctp_init()
- net/netfilter/nf_conntrack_proto_sctp.c: nf_conntrack_proto_sctp_fini()
- make the following needlessly global variables/locks/structs static:
- net/ipv6/netfilter/nf_conntrack_reasm.c: nf_ct_frag6_secret_interval
- net/ipv6/netfilter/nf_conntrack_reasm.c: nf_ct_frag6_mem
- net/netfilter/nf_conntrack_core.c: nf_ct_cache_lock
- net/netfilter/nf_conntrack_proto_sctp.c: nf_conntrack_protocol_sctp4
- net/netfilter/nf_conntrack_proto_sctp.c: nf_conntrack_protocol_sctp6
- #if 0 the following unused global functions:
- net/ipv6/netfilter/nf_conntrack_reasm.c: nf_ct_frag6_kfree_frags()
- net/netfilter/nf_conntrack_core.c: nf_conntrack_tuple_taken()
- net/netfilter/nf_conntrack_core.c: nf_ct_helper_find_get()
- net/netfilter/nf_conntrack_core.c: nf_ct_helper_put()
- net/netfilter/nf_conntrack_core.c: nf_ct_invert_tuplepr()
- remove the following unused or write-only variables:
- net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c: nat_module_is_loaded
- net/ipv6/netfilter/nf_conntrack_reasm.c: nf_ct_frag6_nqueues
- remove the following unused hooks:
- net/netfilter/nf_conntrack_core.c: nf_conntrack_destroyed()
- net/netfilter/nf_conntrack_ftp.c: nf_nat_ftp_hook()
- remove the following unused EXPORT_SYMBOL's:
- nf_ct_iterate_cleanup
- nf_ct_protos
- nf_ct_l3protos
Please review which of these changes make sense and which might conflict
with pending patches.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
include/net/netfilter/nf_conntrack.h | 21 -
include/net/netfilter/nf_conntrack_core.h |2 -
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c |4 --
net/ipv6/netfilter/nf_conntrack_reasm.c|9 ++---
net/netfilter/nf_conntrack_core.c | 25 +---
net/netfilter/nf_conntrack_ftp.c | 26 +++--
net/netfilter/nf_conntrack_proto_sctp.c|8 ++---
net/netfilter/nf_conntrack_standalone.c|9 -
8 files changed, 27 insertions(+), 77 deletions(-)
---
linux-2.6.18-rc1-mm1-full/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c.old
2006-07-09 19:20:35.0 +0200
+++ linux-2.6.18-rc1-mm1-full/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
2006-07-09 19:20:46.0 +0200
@@ -113,12 +113,8 @@
return NF_ACCEPT;
}
-int nat_module_is_loaded = 0;
static u_int32_t ipv4_get_features(const struct nf_conntrack_tuple *tuple)
{
- if (nat_module_is_loaded)
- return NF_CT_F_NAT;
-
return NF_CT_F_BASIC;
}
--- linux-2.6.18-rc1-mm1-full/net/ipv6/netfilter/nf_conntrack_reasm.c.old
2006-07-09 19:21:08.0 +0200
+++ linux-2.6.18-rc1-mm1-full/net/ipv6/netfilter/nf_conntrack_reasm.c
2006-07-09 19:22:45.0 +0200
@@ -99,13 +99,11 @@
static DEFINE_RWLOCK(nf_ct_frag6_lock);
static u32 nf_ct_frag6_hash_rnd;
static LIST_HEAD(nf_ct_frag6_lru_list);
-int nf_ct_frag6_nqueues = 0;
static __inline__ void __fq_unlink(struct nf_ct_frag6_queue *fq)
{
hlist_del(fq-list);
list_del(fq-lru_list);
- nf_ct_frag6_nqueues--;
}
static __inline__ void fq_unlink(struct nf_ct_frag6_queue *fq)
@@ -143,7 +141,7 @@
}
static struct timer_list nf_ct_frag6_secret_timer;
-int nf_ct_frag6_secret_interval = 10 * 60 * HZ;
+static int nf_ct_frag6_secret_interval = 10 * 60 * HZ;
static void nf_ct_frag6_secret_rebuild(unsigned long dummy)
{
@@ -173,7 +171,7 @@
mod_timer(nf_ct_frag6_secret_timer, now + nf_ct_frag6_secret_interval);
}
-atomic_t nf_ct_frag6_mem = ATOMIC_INIT(0);
+static atomic_t nf_ct_frag6_mem = ATOMIC_INIT(0);
/* Memory Tracking Functions. */
static inline void frag_kfree_skb(struct sk_buff *skb, unsigned int *work)
@@ -331,7 +329,6 @@
hlist_add_head(fq-list, nf_ct_frag6_hash[hash]);
INIT_LIST_HEAD(fq-lru_list);
list_add_tail(fq-lru_list, nf_ct_frag6_lru_list);
- nf_ct_frag6_nqueues++;
write_unlock(nf_ct_frag6_lock);
return fq;
}
@@ -842,6 +839,7 @@
nf_conntrack_put_reasm(skb);
}
+#if 0
int nf_ct_frag6_kfree_frags(struct sk_buff *skb)
{
struct sk_buff *s, *s2;
@@ -856,6 +854,7 @@
return 0;
}
+#endif /* 0 */
int nf_ct_frag6_init(void)
{
--- linux-2.6.18-rc1-mm1-full/include/net/netfilter/nf_conntrack_core.h.old
2006-07-09 19:23:09.0 +0200
+++ linux-2.6.18-rc1-mm1-full/include/net/netfilter/nf_conntrack_core.h
2006-07-09 19:23:16.0 +0200
@@ -68,8 +68,6 @@
return ret;
}
-extern void __nf_conntrack_attach(struct sk_buff
Re: [PATCH RFC]rfkill - Hardware button support for Wireless cards
Am Sonntag, 9. Juli 2006 17:49 schrieb Ivo Van Doorn:
I have been quite busy lately, hence the reason for this late continuance
of the Hardware button support for Wireless cards discussion.
I have CC'ed the people who discussed this in earlier threads.
no problem. Look good, just one thing I'm missing:
+ For each registered hardware button an input device will be created.
+ If this input device has been opened by the user, rfkill will send a
+ signal to userspace instead of the hardware about the new button
+ status. This will allow userpace to perform the correct steps
+ in order to bring down all interfaces.
+ if (rfkill-input_dev-users) {
+ input_report_key(rfkill-input_dev,
+ KEY_RFKILL, new_status);
+ input_sync(rfkill-input_dev);
Shouldn't there be a continue to avoid calling enable/disable_radio()?
+ }
Stefan
PS: This rfkill stuff is really caught between two stools. Sending a netlink
event for the device with an additional TLV for radio button status seems as
valid as sending an input event...
-
To unsubscribe from this list: send 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] bcm43xx-d80211: Fix an off-by-one condition in handle_irq_noise
An assert statement near the start of handle_irq_noise in the d80211 version of bcm43xx_main.c is there to protect against out of bound addressing using variable bcm-noisecalc.nr_samples. The arrays in question have a dimension of 8, thus the value must be 8. This patch mirrors the one submitted earlier for the softmac version of bcm43xx. Signed-Off-By: Larry.Finger [EMAIL PROTECTED] index 7ed18ca..37bb0dd 100644 --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c @@ -1534,7 +1534,7 @@ static void handle_irq_noise(struct bcm4 goto generate_new; /* Get the noise samples. */ - assert(bcm-noisecalc.nr_samples = 8); + assert(bcm-noisecalc.nr_samples 8); i = bcm-noisecalc.nr_samples; noise[0] = limit_value(noise[0], 0, ARRAY_SIZE(radio-nrssi_lt) - 1); noise[1] = limit_value(noise[1], 0, ARRAY_SIZE(radio-nrssi_lt) - 1); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bcm43xx-d80211: Fix an off-by-one condition in handle_irq_noise
On Tuesday 11 July 2006 00:56, you wrote: An assert statement near the start of handle_irq_noise in the d80211 version of bcm43xx_main.c is there to protect against out of bound addressing using variable bcm-noisecalc.nr_samples. The arrays in question have a dimension of 8, thus the value must be 8. This patch mirrors the one submitted earlier for the softmac version of bcm43xx. Signed-Off-By: Larry.Finger [EMAIL PROTECTED] index 7ed18ca..37bb0dd 100644 --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c This is not a patch against bcm43xx-d80211. @@ -1534,7 +1534,7 @@ static void handle_irq_noise(struct bcm4 goto generate_new; /* Get the noise samples. */ - assert(bcm-noisecalc.nr_samples = 8); + assert(bcm-noisecalc.nr_samples 8); i = bcm-noisecalc.nr_samples; noise[0] = limit_value(noise[0], 0, ARRAY_SIZE(radio-nrssi_lt) - 1); noise[1] = limit_value(noise[1], 0, ARRAY_SIZE(radio-nrssi_lt) - 1); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Greetings Michael. - To unsubscribe from this list: send the 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] bcm43xx-d80211: Fix an off-by-one condition in handle_irq_noise
Michael Buesch wrote: On Tuesday 11 July 2006 00:56, you wrote: An assert statement near the start of handle_irq_noise in the d80211 version of bcm43xx_main.c is there to protect against out of bound addressing using variable bcm-noisecalc.nr_samples. The arrays in question have a dimension of 8, thus the value must be 8. This patch mirrors the one submitted earlier for the softmac version of bcm43xx. Signed-Off-By: Larry.Finger [EMAIL PROTECTED] index 7ed18ca..37bb0dd 100644 --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c This is not a patch against bcm43xx-d80211. Sorry. I misunderstood the organization of wireless-dev. The correct patch will be sent shortly. Larry - To unsubscribe from this list: send 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] bcm43xx-d80211 (try 2): Fix an off-by-one condition in handle_irq_noise
An assert statement near the start of handle_irq_noise in the d80211 version of bcm43xx_main.c is there to protect against out of bound addressing using variable bcm-noisecalc.nr_samples. The arrays in question have a dimension of 8, thus the value must be 8. This patch mirrors the one submitted earlier for the softmac version of bcm43xx. Signed-Off-By: Larry.Finger [EMAIL PROTECTED] index a400bd6..1db471e 100644 --- a/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c +++ b/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c @@ -1434,7 +1434,7 @@ static void handle_irq_noise(struct bcm4 goto generate_new; /* Get the noise samples. */ - assert(bcm-noisecalc.nr_samples = 8); + assert(bcm-noisecalc.nr_samples 8); i = bcm-noisecalc.nr_samples; noise[0] = limit_value(noise[0], 0, ARRAY_SIZE(radio-nrssi_lt) - 1); noise[1] = limit_value(noise[1], 0, ARRAY_SIZE(radio-nrssi_lt) - 1); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[AX.25] Fix locking of ax25 protocol function list.
Delivery of AX.25 frame to the layer 3 protocols happens in softirq context
so locking needs to be bh-proof.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
diff --git a/net/ax25/ax25_iface.c b/net/ax25/ax25_iface.c
index 77ba07c..07ac020 100644
--- a/net/ax25/ax25_iface.c
+++ b/net/ax25/ax25_iface.c
@@ -66,10 +66,10 @@ #endif
protocol-pid = pid;
protocol-func = func;
- write_lock(protocol_list_lock);
+ write_lock_bh(protocol_list_lock);
protocol-next = protocol_list;
protocol_list = protocol;
- write_unlock(protocol_list_lock);
+ write_unlock_bh(protocol_list_lock);
return 1;
}
@@ -80,16 +80,16 @@ void ax25_protocol_release(unsigned int
{
struct protocol_struct *s, *protocol;
- write_lock(protocol_list_lock);
+ write_lock_bh(protocol_list_lock);
protocol = protocol_list;
if (protocol == NULL) {
- write_unlock(protocol_list_lock);
+ write_unlock_bh(protocol_list_lock);
return;
}
if (protocol-pid == pid) {
protocol_list = protocol-next;
- write_unlock(protocol_list_lock);
+ write_unlock_bh(protocol_list_lock);
kfree(protocol);
return;
}
@@ -98,14 +98,14 @@ void ax25_protocol_release(unsigned int
if (protocol-next-pid == pid) {
s = protocol-next;
protocol-next = protocol-next-next;
- write_unlock(protocol_list_lock);
+ write_unlock_bh(protocol_list_lock);
kfree(s);
return;
}
protocol = protocol-next;
}
- write_unlock(protocol_list_lock);
+ write_unlock_bh(protocol_list_lock);
}
EXPORT_SYMBOL(ax25_protocol_release);
@@ -266,13 +266,13 @@ int ax25_protocol_is_registered(unsigned
struct protocol_struct *protocol;
int res = 0;
- read_lock(protocol_list_lock);
+ read_lock_bh(protocol_list_lock);
for (protocol = protocol_list; protocol != NULL; protocol =
protocol-next)
if (protocol-pid == pid) {
res = 1;
break;
}
- read_unlock(protocol_list_lock);
+ read_unlock_bh(protocol_list_lock);
return res;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[NETROM] adsf
When establishing a new circuit in nr_rx_frame the locks are taken in a different order than in the rest of the stack. This should be harmless but triggers lockdep. Either way, reordering the code a little solves the issue. Signed-off-by: Ralf Baechle [EMAIL PROTECTED] diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c index ecc7968..672d5f8 100644 --- a/net/netrom/af_netrom.c +++ b/net/netrom/af_netrom.c @@ -986,18 +986,18 @@ int nr_rx_frame(struct sk_buff *skb, str nr_make-vl= 0; nr_make-state = NR_STATE_3; sk_acceptq_added(sk); - - nr_insert_socket(make); - skb_queue_head(sk-sk_receive_queue, skb); - nr_start_heartbeat(make); - nr_start_idletimer(make); - if (!sock_flag(sk, SOCK_DEAD)) sk-sk_data_ready(sk, skb-len); bh_unlock_sock(sk); + + nr_insert_socket(make); + + nr_start_heartbeat(make); + nr_start_idletimer(make); + return 1; } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] IB/mthca: comment fix
Michael S. Tsirkin wrote: OK, this is fine with both Arjan van de Ven and Roland Dreier, so - Andrew, could you take this into -mm please? Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] Acked-by: Zach Brown [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
infiniband patch series (was Re: ipath patch series a-comin', but no IB maintainer to shepherd them)
Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]: Yes, -mm seems like a good way to get more review. Andrew, am I using the right format to send things upstream to you? There's really a set of independent patches, so it didn't make sense to me to batch them up in a series. OK? Maybe the addition of the git tree (below) serves to clarify things. Further, in the hope that this will help keep things reasonably stable till Roland comes back, and help everyone see what's being merged, I have created a git branch for all things infiniband going into 2.6.18. You can get at it here: git://www.mellanox.co.il/~git/infiniband mst-for-2.6.18 BTW, all outstanding infiniband patches intended for upstream are currently there. Here's the list: Jack Morgenstein: IB/mthca: fix mthca_ah_query static rate format Michael S. Tsirkin: IB/cm: drop REQ when out of memory IB/mthca: comment fix Sean Hefty: IB/addr: gid structure alignment fix Vu Pham: IB/srp: fix fmr error handling -- MST - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IB/cm: set private data length for reject messages
Hi Andrew, Here's another infiniband patch that needs to go upstream. --- From: Ira Weiny [EMAIL PROTECTED] Set private data length for reject messages to the correct size. Fix from openib svn r8483. Signed-off-by: Sean Hefty [EMAIL PROTECTED] Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] Index: openib/drivers/infiniband/core/cma.c === --- openib/drivers/infiniband/core/cma.c(revision 8482) +++ openib/drivers/infiniband/core/cma.c(revision 8483) @@ -906,6 +906,7 @@ static int cma_ib_handler(struct ib_cm_i cma_modify_qp_err(id_priv-id); status = ib_event-param.rej_rcvd.reason; event = RDMA_CM_EVENT_REJECTED; + private_data_len = IB_CM_REJ_PRIVATE_DATA_SIZE; break; default: printk(KERN_ERR RDMA CMA: unexpected IB CM event: %d, -- MST - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH fixed] srp: fix fmr error handling
Sorry, the last patch I sent was corrupted, here's an updated version:
---
commit 7289361d5f81463e4abb27334773750279547e8a
Author: Vu Pham [EMAIL PROTECTED]
Date: Mon Jul 10 22:38:14 2006 +0300
[PATCH] srp: fix fmr error handling
srp_unmap_data assumes req-fmr is NULL if the request is not mapped,
so we must clean it out in case of an error.
Signed-off-by: Vu Pham [EMAIL PROTECTED]
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Acked-by: Roland Dreier [EMAIL PROTECTED]
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index 4e22afe..6191180 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -618,6 +618,7 @@ static int srp_map_fmr(struct srp_device
dma_pages, page_cnt, io_addr);
if (IS_ERR(req-fmr)) {
ret = PTR_ERR(req-fmr);
+ req-fmr = NULL;
goto out;
}
--
MST
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [AX.25] Fix locking of ax25 protocol function list.
From: Ralf Baechle [EMAIL PROTECTED] Date: Tue, 11 Jul 2006 00:09:43 +0100 Delivery of AX.25 frame to the layer 3 protocols happens in softirq context so locking needs to be bh-proof. Signed-off-by: Ralf Baechle [EMAIL PROTECTED] Applied, thanks Ralf. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: possible dos / wsize affected frozen connection length (was: Re: 2.6.17.1: fails to fully get webpage)
On Wed, Jul 05, 2006 at 07:54:01AM -0400, linux-os (Dick Johnson) wrote: running since 8:42pm yesterday. It's 8:37am now. It hasn't progressed in any way. It hasn't quit. It hasn't timed out. It just sits there, hung. This leads me to consider the possibility of a DOS, either intentional or accidental (think about 2.6.17.x running on a mail server and someone mails/spams from a broken place). TCP/IP connections can continue forever. That's one of the reasons why Berkeley sockets has SO_KEEPALIVE for a socket option. In the absence of such an option, the physical connection can be broken for a week, reconnected, then the session can continue. D'oh. I knew that. Sigh. It's one of the things I like about having a static ip on a bad connection. :) In your case, you probably have a real error in which one end of the connection crashed. However, until the other end shuts down that Well not so much crashed but became unreachable due to the wsize thing. socket, the connection is logically correct and should not be forcefully terminated. It'll never terminate right now unless I hit ^c. A DOS is unlikely because with no data being transferred, little Not all DOS' are transfer based. Just anything that uses up resources to the point where a service is no longer able to be performed. non-swapable resources are used. You can control the maximum number of connections allowed from a host with your firewall software (like iptables). After the fact really. In this case one can send mail to a box and make it bounce to someplace behind a wsize broken network. Resources taken up that wont return until someone spots what's wrong. You could make your own wsize broken network, connect to someplace a few times and then move on whilst their end hangs around, waiting for the connections to do somthing. In my test case I am wondering if there was/is a web process hanging about doing nothing other then waiting for my end to do something. -- To the extent that we overreact, we proffer the terrorists the greatest tribute. - High Court Judge Michael Kirby - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NETROM] adsf
From: Ralf Baechle [EMAIL PROTECTED] Date: Tue, 11 Jul 2006 00:14:46 +0100 When establishing a new circuit in nr_rx_frame the locks are taken in a different order than in the rest of the stack. This should be harmless but triggers lockdep. Either way, reordering the code a little solves the issue. Signed-off-by: Ralf Baechle [EMAIL PROTECTED] Care to give me a better header line than [NETROM]: adsf? :-) 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
[NETROM] Drop lock before calling nr_destroy_socket
nr_destroy_socket takes the socket lock itself so it should better be
called with the socket unlocked.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
---
diff --git a/net/netrom/nr_timer.c b/net/netrom/nr_timer.c
index 75b72d3..ddba1c1 100644
--- a/net/netrom/nr_timer.c
+++ b/net/netrom/nr_timer.c
@@ -138,8 +138,8 @@ static void nr_heartbeat_expiry(unsigned
if (sock_flag(sk, SOCK_DESTROY) ||
(sk-sk_state == TCP_LISTEN sock_flag(sk, SOCK_DEAD))) {
sock_hold(sk);
- nr_destroy_socket(sk);
bh_unlock_sock(sk);
+ nr_destroy_socket(sk);
sock_put(sk);
return;
}
-
To unsubscribe from this list: send 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] cancel_rearming_delayed_work infinite loop fix
cancel_rearming_delayed_work{queue} is broken, because it is
possible to enter an infinite loop if:
We call the function on a work that is currently not executing or pending.
But, as this is a synchronization function and as its only purpose
is to synchronize the work, that should not loop infinite.
This patch rewrites the function.
It now first cancels the work, but throws the retval of that function
away, because it is meaningless in this context. (The retval is 1,
if the work was pending and 0, if not)
After that we flush the queue to make sure any work function returns.
Now, if it was indeed running, it rescheduled itself. That is caught
by the test_bit(). If it rescheduled itself, we have the schedule-delay
time to cancel the work again (without it rescheduling itself again).
So we redo the loop. Most likely it will succeed on the
second loop iteration at least.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev-dscapeports/kernel/workqueue.c
===
--- wireless-dev-dscapeports.orig/kernel/workqueue.c2006-06-13
14:44:16.0 +0200
+++ wireless-dev-dscapeports/kernel/workqueue.c 2006-07-11 00:19:06.0
+0200
@@ -461,8 +461,10 @@
void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
struct work_struct *work)
{
- while (!cancel_delayed_work(work))
+ do {
+ cancel_delayed_work(work);
flush_workqueue(wq);
+ } while (test_bit(0, work-pending));
}
EXPORT_SYMBOL(cancel_rearming_delayed_workqueue);
--
Greetings Michael.
-
To unsubscribe from this list: send 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] d80211: make sleeping in hw-config possible #2
Hi John,
Please apply this to wireless-dev.
Note that this is the second try to submit this patch.
The first try contained a little bug. I'm sorry for that.
If you already applied the first one, I can provide an incremental patch.
Note2 that this patch depends on the
[PATCH] cancel_rearming_delayed_work infinite loop fix
I just sent out to the lists and akpm.
--
This patch makes sleeping in the hw-config callback possible
by removing the only atomic caller. The atomic caller was
a timer and is replaced by a workqueue.
In general, allowing to sleep in the config callback is a
good thing. bcm43xx must be able to sleep here, as it is
required to lock a mutex.
But there are other good reasons to sleep here. We might
want to sleep for a grace period on channel switch, for example.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev-dscapeports/net/d80211/ieee80211.c
===
--- wireless-dev-dscapeports.orig/net/d80211/ieee80211.c2006-06-17
21:26:10.0 +0200
+++ wireless-dev-dscapeports/net/d80211/ieee80211.c 2006-07-11
00:53:44.0 +0200
@@ -4327,8 +4327,8 @@
del_timer_sync(local-rate_limit_timer);
if (local-stat_time)
del_timer_sync(local-stat_timer);
- if (local-scan_timer.data)
- del_timer_sync(local-scan_timer);
+ if (local-scan_work.data)
+ cancel_rearming_delayed_work(local-scan_work);
ieee80211_rx_bss_list_deinit(dev);
rtnl_lock();
Index: wireless-dev-dscapeports/net/d80211/ieee80211_i.h
===
--- wireless-dev-dscapeports.orig/net/d80211/ieee80211_i.h 2006-06-17
21:26:10.0 +0200
+++ wireless-dev-dscapeports/net/d80211/ieee80211_i.h 2006-07-09
19:52:07.0 +0200
@@ -17,6 +17,7 @@
#include linux/list.h
#include linux/netdevice.h
#include linux/skbuff.h
+#include linux/workqueue.h
#include ieee80211_key.h
#include sta_info.h
@@ -407,7 +408,7 @@
int scan_channel_idx;
enum { SCAN_SET_CHANNEL, SCAN_SEND_PROBE } scan_state;
unsigned long last_scan_completed;
- struct timer_list scan_timer;
+ struct work_struct scan_work;
int scan_oper_channel;
int scan_oper_channel_val;
int scan_oper_power_level;
Index: wireless-dev-dscapeports/net/d80211/ieee80211_iface.c
===
--- wireless-dev-dscapeports.orig/net/d80211/ieee80211_iface.c 2006-06-17
21:26:10.0 +0200
+++ wireless-dev-dscapeports/net/d80211/ieee80211_iface.c 2006-07-09
20:03:32.0 +0200
@@ -271,8 +271,8 @@
case IEEE80211_IF_TYPE_STA:
case IEEE80211_IF_TYPE_IBSS:
del_timer_sync(sdata-u.sta.timer);
- if (local-scan_timer.data == (unsigned long) sdata-dev)
- del_timer_sync(local-scan_timer);
+ if (local-scan_work.data == sdata-dev)
+ cancel_rearming_delayed_work(local-scan_work);
kfree(sdata-u.sta.extra_ie);
sdata-u.sta.extra_ie = NULL;
kfree(sdata-u.sta.assocreq_ies);
Index: wireless-dev-dscapeports/net/d80211/ieee80211_sta.c
===
--- wireless-dev-dscapeports.orig/net/d80211/ieee80211_sta.c2006-06-17
21:26:10.0 +0200
+++ wireless-dev-dscapeports/net/d80211/ieee80211_sta.c 2006-07-09
20:21:44.0 +0200
@@ -2422,15 +2422,16 @@
}
-static void ieee80211_sta_scan_timer(unsigned long ptr)
+static void ieee80211_sta_scan_work(void *_data)
{
- struct net_device *dev = (struct net_device *) ptr;
+ struct net_device *dev = _data;
struct ieee80211_local *local = dev-ieee80211_ptr;
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct ieee80211_hw_modes *mode;
struct ieee80211_channel *chan;
int skip;
union iwreq_data wrqu;
+ unsigned long next_delay = 0;
if (!local-sta_scanning)
return;
@@ -2498,29 +2499,27 @@
local-scan_channel_idx = 0;
}
- if (skip) {
- local-scan_timer.expires = jiffies;
+ if (skip)
break;
- }
- local-scan_timer.expires = jiffies + IEEE80211_PROBE_DELAY;
+ next_delay = IEEE80211_PROBE_DELAY;
local-scan_state = SCAN_SEND_PROBE;
break;
case SCAN_SEND_PROBE:
if (ieee80211_active_scan(local)) {
ieee80211_send_probe_req(dev, NULL, local-scan_ssid,
local-scan_ssid_len);
- local-scan_timer.expires =
- jiffies + IEEE80211_CHANNEL_TIME;
-
Re: [NETROM] Drop lock before calling nr_destroy_socket
From: Ralf Baechle [EMAIL PROTECTED] Date: Tue, 11 Jul 2006 00:25:45 +0100 nr_destroy_socket takes the socket lock itself so it should better be called with the socket unlocked. Signed-off-by: Ralf Baechle [EMAIL PROTECTED] Applied, thanks Ralf. - To unsubscribe from this list: send the 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] d80211: make sleeping in hw-config possible #2
On Tue, 11 Jul 2006 00:54:33 +0200 Michael Buesch [EMAIL PROTECTED] wrote: Please apply this to wireless-dev. Note that this is the second try to submit this patch. The first try contained a little bug. I'm sorry for that. If you already applied the first one, I can provide an incremental patch. Note2 that this patch depends on the [PATCH] cancel_rearming_delayed_work infinite loop fix I just sent out to the lists and akpm. Am still scratching my head over that. I wouldn't really call it a fix. More an enhcancement to cover unanticipated (and arguably strange) usage. It's odd to call cancel_rearming_delayed_work() against a rearming workqueue which isn't actually running. It tends to indicate that the caller has lost track of what it's up to. But as a convenience thing I guess it's an OK thing to do. I need to stare at the implementation for a bit longer - that stuff's tricky. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: infiniband patch series (was Re: ipath patch series a-comin', but no IB maintainer to shepherd them)
On Tue, 11 Jul 2006 01:19:02 +0300 Michael S. Tsirkin [EMAIL PROTECTED] wrote: Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]: Yes, -mm seems like a good way to get more review. Andrew, am I using the right format to send things upstream to you? There's really a set of independent patches, so it didn't make sense to me to batch them up in a series. OK? Sure. Although I am a little surprised to be be receiving them while Roland is in taking-time-off-but-not-really-doing-so mode. But whatever - I'll put them in the for-2.6.18 queue, 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
[Patch 6/6] per task delay accounting taskstats interface: fix clone skbs for each listener
Use a cloned sk_buff for each netlink message sent to multiple listeners.
Earlier, the same skb, representing a netlink message, was being erroneously
reused for doing genetlink_unicast()'s (effectively netlink_unicast()) to
each listener on the per-cpu list of listeners. Since netlink_unicast() frees
up the skb passed to it, regardless of status of the send, reuse is bad.
Thanks to Chandra Seetharaman for discovering this bug.
Signed-Off-By: Shailabh Nagar [EMAIL PROTECTED]
Signed-Off-By: Chandra Seetharaman [EMAIL PROTECTED]
kernel/taskstats.c | 13 -
1 files changed, 12 insertions(+), 1 deletion(-)
Index: linux-2.6.18-rc1/kernel/taskstats.c
===
--- linux-2.6.18-rc1.orig/kernel/taskstats.c2006-07-10 23:44:56.0
-0400
+++ linux-2.6.18-rc1/kernel/taskstats.c 2006-07-10 23:45:15.0 -0400
@@ -125,6 +125,7 @@ static int send_cpu_listeners(struct sk_
struct genlmsghdr *genlhdr = nlmsg_data((struct nlmsghdr *)skb-data);
struct listener_list *listeners;
struct listener *s, *tmp;
+ struct sk_buff *skb_next, *skb_cur = skb;
void *reply = genlmsg_data(genlhdr);
int rc, ret;
@@ -138,12 +139,22 @@ static int send_cpu_listeners(struct sk_
listeners = per_cpu(listener_array, cpu);
down_write(listeners-sem);
list_for_each_entry_safe(s, tmp, listeners-list, list) {
- ret = genlmsg_unicast(skb, s-pid);
+ skb_next = NULL;
+ if (!list_islast(s-list, listeners-list)) {
+ skb_next = skb_clone(skb_cur, GFP_KERNEL);
+ if (!skb_next) {
+ nlmsg_free(skb_cur);
+ rc = -ENOMEM;
+ break;
+ }
+ }
+ ret = genlmsg_unicast(skb_cur, s-pid);
if (ret == -ECONNREFUSED) {
list_del(s-list);
kfree(s);
rc = ret;
}
+ skb_cur = skb_next;
}
up_write(listeners-sem);
-
To unsubscribe from this list: send 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]unaligned access in irda protocol stack
Hi all,
For struct irda_device_info in irda.h:
struct irda_device_info {
__u32 saddr;/* Address of local interface */
__u32 daddr;/* Address of remote device */
charinfo[22]; /* Description */
__u8charset; /* Charset used for description */
__u8hints[2]; /* Hint bits */
};
The hints member aligns at the third byte of a word, an odd
address. So if we visit hints as a short in irlmp.c and discorery.c:
u16ho(irlmp-discovery_cmd.data.hints) = irlmp-hints.word;
will cause alignment problem on some machines. Architectures with
strict alignment rules do not allow 16-bit read on an odd address.
Signed-off-by: Luke Yang [EMAIL PROTECTED]
Acked-by: David Miller [EMAIL PROTECTED]
discovery.c |6 --
irlmp.c |8 +---
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/irda/discovery.c b/net/irda/discovery.c
index 3fefc82..bc5280c 100644
--- a/net/irda/discovery.c
+++ b/net/irda/discovery.c
@@ -38,6 +38,7 @@ #include net/irda/irda.h
#include net/irda/irlmp.h
#include net/irda/discovery.h
+#include asm/unaligned.h
/*
* Function irlmp_add_discovery (cachelog, discovery)
@@ -86,7 +87,8 @@ void irlmp_add_discovery(hashbin_t *cach
*/
hashbin_remove_this(cachelog, (irda_queue_t *) node);
/* Check if hints bits are unchanged */
- if(u16ho(node-data.hints) == u16ho(new-data.hints))
+ if(get_unaligned(node-data.hints) ==
+ get_unaligned(new-data.hints))
/* Set time of first discovery for this node */
new-firststamp = node-firststamp;
kfree(node);
@@ -280,7 +282,7 @@ struct irda_device_info *irlmp_copy_disc
/* Mask out the ones we don't want :
* We want to match the discovery mask, and to get only
* the most recent one (unless we want old ones) */
- if ((u16ho(discovery-data.hints) mask)
+ if ((get_unaligned(discovery-data.hints) mask)
((old_entries) ||
((jiffies - discovery-firststamp) j_timeout)) ) {
/* Create buffer as needed.
diff --git a/net/irda/irlmp.c b/net/irda/irlmp.c
index 129ad64..dc36528 100644
--- a/net/irda/irlmp.c
+++ b/net/irda/irlmp.c
@@ -42,7 +42,6 @@ #include net/irda/irlap.h
#include net/irda/iriap.h
#include net/irda/irlmp.h
#include net/irda/irlmp_frame.h
-
#include asm/unaligned.h
static __u8 irlmp_find_free_slsap(void);
@@ -1063,7 +1062,8 @@ void irlmp_discovery_expiry(discinfo_t *
for(i = 0; i number; i++) {
/* Check if we should notify client */
if ((client-expir_callback)
- (client-hint_mask.word u16ho(expiries[i].hints)
+ (client-hint_mask.word
+get_unaligned(expiries[i].hints)
0x7f7f) )
client-expir_callback((expiries[i]),
EXPIRY_TIMEOUT,
@@ -1083,11 +1083,13 @@ void irlmp_discovery_expiry(discinfo_t *
*/
discovery_t *irlmp_get_discovery_response(void)
{
+ __u16 *data_hintsp;
IRDA_DEBUG(4, %s()\n, __FUNCTION__);
IRDA_ASSERT(irlmp != NULL, return NULL;);
- u16ho(irlmp-discovery_rsp.data.hints) = irlmp-hints.word;
+ data_hintsp = (__u16 *) irlmp-discovery_rsp.data.hints;
+ put_unaligned(irlmp-hints.word, data_hintsp);
/*
* Set character set for device name (we use ASCII), and
--
Best regards,
Luke Yang
[EMAIL PROTECTED]
diff --git a/net/irda/discovery.c b/net/irda/discovery.c
index 3fefc82..bc5280c 100644
--- a/net/irda/discovery.c
+++ b/net/irda/discovery.c
@@ -38,6 +38,7 @@ #include net/irda/irda.h
#include net/irda/irlmp.h
#include net/irda/discovery.h
+#include asm/unaligned.h
/*
* Function irlmp_add_discovery (cachelog, discovery)
@@ -86,7 +87,8 @@ void irlmp_add_discovery(hashbin_t *cach
*/
hashbin_remove_this(cachelog, (irda_queue_t *) node);
/* Check if hints bits are unchanged */
- if(u16ho(node-data.hints) == u16ho(new-data.hints))
+ if(get_unaligned(node-data.hints) ==
+ get_unaligned(new-data.hints))
/* Set time of first discovery for this node */
new-firststamp = node-firststamp;
kfree(node);
@@ -280,7 +282,7 @@ struct irda_device_info *irlmp_copy_disc
/* Mask out the ones we don't want :
* We want to match the discovery mask, and to get only
* the most recent one (unless we want old ones) */
- if ((u16ho(discovery-data.hints) mask)
+ if ((get_unaligned(discovery-data.hints) mask)
((old_entries) ||
((jiffies - discovery-firststamp) j_timeout)) ) {
/* Create buffer as needed.
diff --git a/net/irda/irlmp.c
Re: infiniband patch series (was Re: ipath patch series a-comin', but no IB maintainer to shepherd them)
Quoting r. Andrew Morton [EMAIL PROTECTED]: Sure. Although I am a little surprised to be be receiving them while Roland is in taking-time-off-but-not-really-doing-so mode. Well, I don't know what's up either, but Roland acked patches explicitly so I figured that's what he wants, too. -- MST - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: active-backup/bonding with drivers not supporting set_mac_address()
David Miller [EMAIL PROTECTED] wrote: Look at a driver such as 3c509.c, for example. [...] If the driver isn't setting up an explicit -set_mac_address handler, it isn't going to be programming the RX MAC of the chip and therefore not recognize packets to that new MAC as destined for it. If I'm not mistaken, it looks like 3c509.c sets the MAC on the chip from dev-dev_addr in el3_up(): /* Set the station address in window 2 each time opened. */ EL3WINDOW(2); for (i = 0; i 6; i++) outb(dev-dev_addr[i], ioaddr + i); I don't have the spec for 3c509 handy, but 3c59x.c does the same thing in vortex_up(), and its spec says the first 6 bytes of register window 2 are the StationAddress. So, I'm still wondering what drivers really never let you change the MAC address. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Netchannel: default, find, add to socket
Implement finding of correct netchannel for buffer, default netchannel and
attach a netchannel to a socket
Signed-off-by: Kelly Daly [EMAIL PROTECTED]
---
diff -urp davem/include/linux/netchannel.h
kelly_new/include/linux/netchannel.h
--- davem/include/linux/netchannel.h2006-06-16 15:14:15.0 +1000
+++ kelly_new/include/linux/netchannel.h2006-07-10 14:04:54.0
+1000
@@ -19,6 +19,7 @@ struct netchannel {
void(*netchan_callb)(struct netchannel *);
void*netchan_callb_data;
unsigned long netchan_head;
+ wait_queue_head_t wq;
};
extern void netchannel_init(struct netchannel *,
@@ -56,6 +57,11 @@ static inline unsigned char *netchan_buf
return netchan_buf_base(bp) + bp-netchan_buf_offset;
}
+static inline int netchan_data_len(const struct netchannel_buftrailer *bp)
+{
+ return bp-netchan_buf_len - bp-netchan_buf_offset;
+}
+
extern int netchannel_enqueue(struct netchannel *, struct
netchannel_buftrailer *);
extern struct netchannel_buftrailer *__netchannel_dequeue(struct netchannel
*);
static inline struct netchannel_buftrailer *netchannel_dequeue(struct
netchannel *np)
@@ -65,6 +71,10 @@ static inline struct netchannel_buftrail
return __netchannel_dequeue(np);
}
+extern struct netchannel *find_netchannel(const struct netchannel_buftrailer
*bp);
+extern int sock_add_netchannel(struct sock *sk);
extern struct sk_buff *skb_netchan_graft(struct netchannel_buftrailer *,
gfp_t);
#endif /* _LINUX_NETCHANNEL_H */
diff -urp davem/include/net/inet_hashtables.h
kelly_new/include/net/inet_hashtables.h
--- davem/include/net/inet_hashtables.h 2006-06-16 14:34:20.0 +1000
+++ kelly_new/include/net/inet_hashtables.h 2006-06-19 10:42:45.0
+1000
@@ -418,4 +418,7 @@ static inline struct sock *inet_lookup(s
extern int inet_hash_connect(struct inet_timewait_death_row *death_row,
struct sock *sk);
+extern void inet_hash_register(u8 proto, struct inet_hashinfo *hashinfo);
+extern struct sock *inet_lookup_proto(u8 protocol, u32 saddr, u16 sport, u32
daddr, u16 dport, int ifindex);
+
#endif /* _INET_HASHTABLES_H */
diff -urp davem/include/net/sock.h kelly_new/include/net/sock.h
--- davem/include/net/sock.h2006-06-16 15:14:16.0 +1000
+++ kelly_new/include/net/sock.h2006-06-19 10:42:45.0 +1000
@@ -196,6 +196,7 @@ struct sock {
unsigned short sk_type;
int sk_rcvbuf;
socket_lock_t sk_lock;
+ struct netchannel *sk_channel;
wait_queue_head_t *sk_sleep;
struct dst_entry*sk_dst_cache;
struct xfrm_policy *sk_policy[2];
diff -urp davem/net/core/dev.c kelly_new/net/core/dev.c
--- davem/net/core/dev.c2006-06-16 15:14:16.0 +1000
+++ kelly_new/net/core/dev.c2006-07-10 14:11:22.0 +1000
@@ -113,9 +113,12 @@
#include linux/delay.h
#include linux/wireless.h
#include linux/netchannel.h
+#include linux/kthread.h
+#include linux/wait.h
#include net/iw_handler.h
#include asm/current.h
#include linux/audit.h
+#include net/inet_hashtables.h
/*
* The list of packet types we will receive (as opposed to discard)
@@ -190,6 +193,8 @@ static inline struct hlist_head *dev_ind
return dev_index_head[ifindex ((1NETDEV_HASHBITS)-1)];
}
+static struct netchannel default_netchannel;
+
/*
* Our notifier list
*/
@@ -1854,11 +1859,18 @@ softnet_break:
goto out;
}
+void netchannel_wake(struct netchannel *np)
+{
+ wake_up(np-wq);
+}
+
void netchannel_init(struct netchannel *np,
void (*callb)(struct netchannel *), void *callb_data)
{
memset(np, 0, sizeof(*np));
+ init_waitqueue_head(np-wq);
+
np-netchan_callb = callb;
np-netchan_callb_data = callb_data;
}
@@ -1912,6 +1924,122 @@ struct netchannel_buftrailer *__netchann
}
EXPORT_SYMBOL_GPL(__netchannel_dequeue);
+/* Find the channel for a packet, or return default channel. */
+struct netchannel *find_netchannel(const struct netchannel_buftrailer *bp)
+{
+ struct sock *sk = NULL;
+ int datalen = netchan_data_len(bp);
+
+ switch (bp-netchan_buf_proto) {
+ case __constant_htons(ETH_P_IP): {
+ struct iphdr *ip = (void *)bp - datalen;
+ int iphl = ip-ihl * 4;
+
+ /* FIXME: Do sanity checks, parse packet. */
+
+ if (datalen + (iphl + 4) iphl == sizeof(struct iphdr)) {
+ u16 *ports = (u16 *)ip + 1;
+ sk = inet_lookup_proto(ip-protocol,
+ip-saddr, ports[0],
+ip-daddr, ports[1],
+bp-netchan_buf_dev-ifindex);
+ }
+ break;
+ }
+ }
+
+ if (sk
Re: [PATCH] Netchannel: default, find, add to socket
On Tue, Jul 11, 2006 at 03:39:25PM +1000, Kelly Daly ([EMAIL PROTECTED]) wrote:
Implement finding of correct netchannel for buffer, default netchannel and
attach a netchannel to a socket
Signed-off-by: Kelly Daly [EMAIL PROTECTED]
Hi Kelly.
You have a typo in the code commented below.
I have a question regarsing your netchannel design - as far as I can
see, you steal data in interrupts and then convert it into skb and run
through usual netif_receive_skb(). Thus you dedicate one thread (one
CPU) to do the whole processing for all sockets which do not have
netchannels bound to them. Did you benchmarked such approach both with
and without netchannel bound to the socket?
+/* Find the channel for a packet, or return default channel. */
+struct netchannel *find_netchannel(const struct netchannel_buftrailer *bp)
+{
+ struct sock *sk = NULL;
+ int datalen = netchan_data_len(bp);
+
+ switch (bp-netchan_buf_proto) {
+ case __constant_htons(ETH_P_IP): {
+ struct iphdr *ip = (void *)bp - datalen;
+ int iphl = ip-ihl * 4;
+
+ /* FIXME: Do sanity checks, parse packet. */
+
+ if (datalen + (iphl + 4) iphl == sizeof(struct iphdr)) {
A typo + instead of =.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
