Re: Repost: Re: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
Stefan Rompf wrote: > the following patch should fix the problem. Patrick, can you give it a > try? As the bug did not affect me through my testing, I want to be sure it > works now. This is stuff for 2.6.18 and 2.6.17-stable. I'm on my way out the door and will be gone for a couple of days, so its going to take me a while. But it looks fine, if you want to test it yourself, just pull the ethernet cable before adding a VLAN and plug it in again afterwards. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]NET: Add ECN support for TSO
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 11 Jul 2006 21:53:42 -0700 > There is no reason to find out if ECN is enabled or not for any > TCP connections. Hw just needs to watch the above bits in the > incoming packets. Correct, it can be done in a completely stateless manner. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 6/6] per task delay accounting taskstats interface: fix clone skbs for each listener
On Tue, 2006-07-11 at 07:15, Herbert Xu wrote: > On Tue, Jul 11, 2006 at 03:57:31AM -0700, Andrew Morton wrote: > > > > > >> 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 we do a GFP_KERNEL allocation with this semaphore held, and the > > > > oom-killer tries to kill something to satisfy the allocation, and the > > > > killed task gets stuck on that semaphore, I wonder of the box locks up. > > > > > > We do GFP_KERNEL inside semaphores/mutexes in lots of places. So if this > > > can deadlock with the oom-killer we probably should fix that, preferably > > > by having GFP_KERNEL fail in that case. > > > > This lock is special, in that it's taken on the exit() path (I think). So > > it can block tasks which are trying to exit. > > Sorry, missed the context. > > If there is a deadlock then it's not just this allocation that you > need worry about. There is also an allocation within genlmsg_uniast > that would be GFP_KERNEL. Remove down_write() from taskstats code invoked on the exit() path. In send_cpu_listeners(), which is called on the exit path, a down_write() was protecting operations like skb_clone() and genlmsg_unicast() that do GFP_KERNEL allocations. If the oom-killer decides to kill tasks to satisfy the allocations,the exit of those tasks could block on the same semphore. The down_write() was only needed to allow removal of invalid listeners from the listener list. The patch converts the down_write to a down_read and defers the removal to a separate critical region. This ensures that even if the oom-killer is called, no other task's exit is blocked as it can still acquire another down_read. Thanks to Andrew Morton & Herbert Xu for pointing out the oom related pitfalls, and to Chandra Seetharaman for suggesting this fix instead of using something more complex like RCU. Signed-Off-By: Chandra Seetharaman <[EMAIL PROTECTED]> Signed-Off-By: Shailabh Nagar <[EMAIL PROTECTED]> --- kernel/taskstats.c | 24 +++- 1 files changed, 19 insertions(+), 5 deletions(-) Index: linux-2.6.18-rc1/kernel/taskstats.c === --- linux-2.6.18-rc1.orig/kernel/taskstats.c2006-07-11 00:13:00.0 -0400 +++ linux-2.6.18-rc1/kernel/taskstats.c 2006-07-12 00:07:53.0 -0400 @@ -51,6 +51,7 @@ __read_mostly = { struct listener { struct list_head list; pid_t pid; + char valid; }; struct listener_list { @@ -127,7 +128,7 @@ static int send_cpu_listeners(struct sk_ struct listener *s, *tmp; struct sk_buff *skb_next, *skb_cur = skb; void *reply = genlmsg_data(genlhdr); - int rc, ret; + int rc, ret, delcount = 0; rc = genlmsg_end(skb, reply); if (rc < 0) { @@ -137,7 +138,7 @@ static int send_cpu_listeners(struct sk_ rc = 0; listeners = &per_cpu(listener_array, cpu); - down_write(&listeners->sem); + down_read(&listeners->sem); list_for_each_entry_safe(s, tmp, &listeners->list, list) { skb_next = NULL; if (!list_islast(&s->list, &listeners->list)) { @@ -150,14 +151,26 @@ static int send_cpu_listeners(struct sk_ } ret = genlmsg_unicast(skb_cur, s->pid); if (ret == -ECONNREFUSED) { - list_del(&s->list); - kfree(s); + s->valid = 0; + delcount++; rc = ret; } skb_cur = skb_next; } - up_write(&listeners->sem); + up_read(&listeners->sem); + + if (!delcount) + return rc; + /* Delete invalidated entries */ + down_write(&listeners->sem); + list_for_each_entry_safe(s, tmp, &listeners->list, list) { + if (!s->valid) { + list_del(&s->list); + kfree(s); + } + } + up_write(&listeners->sem); return rc; } @@ -290,6 +303,7 @@ static int add_del_listener(pid_t pid, c goto cleanup; s->pid = pid; INIT_LIST_HEAD(&s->list); + s->valid = 1; listeners = &per_cpu(listener_array, cpu); down_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
Re: [PATCH] bonding: enhance the IP address check of arp_ip_target
Stephen Hemminger <[EMAIL PROTECTED]> wrote: > > Why not just use sscanf? Better yet, use a better interface like netlink rather than module parameters. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]NET: Add ECN support for TSO
David Miller wrote: > On receive? There is no reason for skb->sk to be anything other than > NULL on receive, the networking stack hasn't even seen the packet yet. > Only the driver has seen the skb. > > Yeah, here's roughly how LRO should work for ECN: If CE, ECE, or CWR is set on an incoming packet, hw should stop LRO on that TCP stream and indicate the packet(s) to the driver right away. In the future if RFC 3540 is implemented, hw needs to do the above and keep track of ECT(0) and ECT(1) on incoming packets. It needs to do a partial sum or parity on the ECT codes and give it to the driver when an LRO packet is ready. There is no reason to find out if ECN is enabled or not for any TCP connections. Hw just needs to watch the above bits in the incoming packets. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bonding: enhance the IP address check of arp_ip_target
On Wed, 12 Jul 2006 13:25:52 +0900 Tetsuo Takata <[EMAIL PROTECTED]> wrote: > Hi, > > > I found this in drivers/net/bonding/bond_main.c. > > /* not complete check, but should be good enough to > > catch mistakes */ > > I made a patch which I believe is little bit better than this, > I hope... > > > best regards, > > --- > Signed-off-by: Tetsuo Takata <[EMAIL PROTECTED]> > > --- linux-2.6.17.3/drivers/net/bonding/bond_main.c2006-07-01 > 02:37:38.0 +0900 > +++ linux-2.6.17.3-bonding-ipcheck/drivers/net/bonding/bond_main.c > 2006-07-12 09:51:12.0 +0900 > @@ -4455,7 +4455,113 @@ static int bond_check_params(struct bond >arp_ip_count++) { > /* not complete check, but should be good enough to > catch mistakes */ > - if (!isdigit(arp_ip_target[arp_ip_count][0])) { > + int i, notip = 0; > + char *cp; > + > + cp = arp_ip_target[arp_ip_count]; > + > + /* notip's number is the error code for debug purpose */ > + do { > + if (cp == NULL) { > + notip = 1; > + break; > + } > + > + /* check digit */ > + for (i = 0; isdigit(*cp); i++) { > + if ((i < 0) || (i >= 3)) { > + notip = 2; > + break; > + } > + cp++; > + } > + if (notip) > + break; > + > + if (i == 0) { > + notip = 3; > + break; > + } > + > + /* check delimiter */ > + if (*cp != '.') { > + notip = 4; > + break; > + } > + cp++; > + > + /* check digit */ > + for (i = 0; isdigit(*cp); i++) { > + if ((i < 0) || (i >= 3)) { > + notip = 5; > + break; > + } > + cp++; > + } > + if (notip) > + break; > + > + if (i == 0) { > + notip = 6; > + break; > + } > + > + /* check delimiter */ > + if (*cp != '.') { > + notip = 7; > + break; > + } > + cp++; > + > + /* check digit */ > + for (i = 0; isdigit(*cp); i++) { > + if ((i < 0) || (i >= 3)) { > + notip = 8; > + break; > + } > + cp++; > + } > + if (notip) > + break; > + > + if (i == 0) { > + notip = 9; > + break; > + } > + > + /* check delimiter */ > + if (*cp != '.') { > + notip = 10; > + break; > + } > + cp++; > + > + /* check digit */ > + for (i = 0; isdigit(*cp); i++) { > + if ((i < 0) || (i >= 3)) { > + notip = 11; > + break; > + } > + cp++; > + } > + if (notip) > + break; > + > + if (i == 0) { > + notip = 12; > + break; > + } > + > + > + /* check EOS */ > + if (*cp != '\0') { > + notip = 13; > + break; > + } > + > + } while(0); > + > + if (notip) { > printk(KERN_WARNING DRV_NAME > ": Warning: bad arp_ip_target module parameter " > "(%s), ARP monitoring will not be performed\n", > > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html Why not just use sscanf? -- If one would give me six lines written by the hand of th
Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y
On Tue, 2006-07-11 at 15:32 +0200, Pavel Machek wrote: > Probably not. This (very dirty) hack implements that (with some level > of success -- ifconfig down/ifconfig up is enough to get wireless > working). You just need to $ iwpriv ethX reset Thanks, -yi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unnecessary check in __sk_stream_mem_reclaim?
From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 12 Jul 2006 14:30:00 +1000 > On Wed, Jul 12, 2006 at 03:17:43PM +1200, Ian McDonald wrote: > > > > I'm not saying the check is unneeded - just saying doing it twice is > > unneeded. > > Right, got you this time. > > I don't think we need to worry about people who use __sk_stream_mem_reclaim > when there is a perfectly good sk_stream_mem_reclaim around. > > Besides, this function has only been exported since 2004 so it's highly > unlikely for there to be stuff out there using it. Agreed. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unnecessary check in __sk_stream_mem_reclaim?
On Wed, Jul 12, 2006 at 03:17:43PM +1200, Ian McDonald wrote: > > I'm not saying the check is unneeded - just saying doing it twice is > unneeded. Right, got you this time. I don't think we need to worry about people who use __sk_stream_mem_reclaim when there is a perfectly good sk_stream_mem_reclaim around. Besides, this function has only been exported since 2004 so it's highly unlikely for there to be stuff out there using it. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bonding: enhance the IP address check of arp_ip_target
Hi, I found this in drivers/net/bonding/bond_main.c. > /* not complete check, but should be good enough to > catch mistakes */ I made a patch which I believe is little bit better than this, I hope... best regards, --- Signed-off-by: Tetsuo Takata <[EMAIL PROTECTED]> --- linux-2.6.17.3/drivers/net/bonding/bond_main.c 2006-07-01 02:37:38.0 +0900 +++ linux-2.6.17.3-bonding-ipcheck/drivers/net/bonding/bond_main.c 2006-07-12 09:51:12.0 +0900 @@ -4455,7 +4455,113 @@ static int bond_check_params(struct bond arp_ip_count++) { /* not complete check, but should be good enough to catch mistakes */ - if (!isdigit(arp_ip_target[arp_ip_count][0])) { + int i, notip = 0; + char *cp; + + cp = arp_ip_target[arp_ip_count]; + + /* notip's number is the error code for debug purpose */ + do { + if (cp == NULL) { + notip = 1; + break; + } + + /* check digit */ + for (i = 0; isdigit(*cp); i++) { + if ((i < 0) || (i >= 3)) { + notip = 2; + break; + } + cp++; + } + if (notip) + break; + + if (i == 0) { + notip = 3; + break; + } + + /* check delimiter */ + if (*cp != '.') { + notip = 4; + break; + } + cp++; + + /* check digit */ + for (i = 0; isdigit(*cp); i++) { + if ((i < 0) || (i >= 3)) { + notip = 5; + break; + } + cp++; + } + if (notip) + break; + + if (i == 0) { + notip = 6; + break; + } + + /* check delimiter */ + if (*cp != '.') { + notip = 7; + break; + } + cp++; + + /* check digit */ + for (i = 0; isdigit(*cp); i++) { + if ((i < 0) || (i >= 3)) { + notip = 8; + break; + } + cp++; + } + if (notip) + break; + + if (i == 0) { + notip = 9; + break; + } + + /* check delimiter */ + if (*cp != '.') { + notip = 10; + break; + } + cp++; + + /* check digit */ + for (i = 0; isdigit(*cp); i++) { + if ((i < 0) || (i >= 3)) { + notip = 11; + break; + } + cp++; + } + if (notip) + break; + + if (i == 0) { + notip = 12; + break; + } + + + /* check EOS */ + if (*cp != '\0') { + notip = 13; + break; + } + + } while(0); + + if (notip) { printk(KERN_WARNING DRV_NAME ": Warning: bad arp_ip_target module parameter " "(%s), ARP monitoring will not be performed\n", - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
Andreas Kleen wrote: If it helps I can do a proper patch that only bounces IO > 4GB through the copy. For the A8V series of boards, that will almost certainly be just fine, because as far as I know you can't populate them with more than 4G of memory anyway. If someone has more than 4G of memory, it's likely they'll be willing to take the performance hit from the mod in exchange for being able to use more than 4G of memory. Bottom line: do the patch. It'll be worth using. - Kevin - To unsubscribe from this list: send the 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-softmac: Further improvement in wireless statistics
Dan Williams wrote: NAK... remember, range->max_qual.level must be _0_ if you're in dBm, I do not think this is right. From the comments in include/linux/wireless.h: /* Quality of link & SNR stuff */ /* Quality range (link, level, noise) * If the quality is absolute, it will be in the range [0 ; max_qual], * if the quality is dBm, it will be in the range [max_qual ; 0]. * Don't forget that we use 8 bit arithmetics... */ My interpretation of this is that if 0 < max_qual < 128, the quantity is absolute. Conversely, if -129 < max_qual < 0, the quantity is in dBm. This is in fact what I see, both from the KDE applets and the various wireless extension tools. since 0 is the actual maximum, and your level values are negative since they are in dBm. If KDE network applets display the wrong value when max_qual.level == 0, then they are wrong and need to be fixed. They display correctly; however, choosing 0 rather than -100 expands the scale to the point that my noise values of -65 dBm display as rather high values. Despite the 8-bit arithmetic, I think it creates a scale from 0 to -255 dBm. My choice of parameters expands the scale by limiting the lower value to -100 dBm. If you actually want RSSI, then you set max_qual.level to the upper limit of your RSSI, and the RSSI is assumed to go from 0 -> max_qual.level. AFAIK, the patch you had earlier is using dBm, _not_ RSSI, so max_qual.level = 0 is correct. As I explained earlier, the RSSI value returned by the firmware has been processed by the driver into a quantity that varies between -10 and -65 as the receiver is moved from very close to very far from the AP, which looks like strength in dBm. This is what is stored in stats.rssi. As this seems to be confusing, I will rewrite the driver code so that this value is returned in stats.signal with the RSSI value preserved in stats.rssi. The quality output will be derived from stats.rssi, and the level output will come from stats.signal. These two quantities have a correlation of -1 so there is no new information, but that might change in the future. 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: Unnecessary check in __sk_stream_mem_reclaim?
On 7/12/06, Herbert Xu <[EMAIL PROTECTED]> wrote: Ian McDonald <[EMAIL PROTECTED]> wrote: > > It looks to me like this check here in net/core/stream.c for > __sk_stream_mem_reclaim: >if (sk->sk_forward_alloc >= SK_STREAM_MEM_QUANTUM) { > > is unnecessary. It's needed after skb's have been freed which can push sk_forward_alloc above a quantum. I'm not saying the check is unneeded - just saying doing it twice is unneeded. Sorry Herbert for two copies - forgot to add netdev first time. -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unnecessary check in __sk_stream_mem_reclaim?
Ian McDonald <[EMAIL PROTECTED]> wrote: > > It looks to me like this check here in net/core/stream.c for > __sk_stream_mem_reclaim: >if (sk->sk_forward_alloc >= SK_STREAM_MEM_QUANTUM) { > > is unnecessary. It's needed after skb's have been freed which can push sk_forward_alloc above a quantum. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
Spamming bug robot dropped from cc list. Am Mi 12.07.2006 04:46 schrieb Anthony DeRobertis <[EMAIL PROTECTED]>: > OK, here are the results with iommu=force. All of these are copied > down > by hand, so please forgive any transcription errors: You need to use iommu=soft swiotlb=force The standard IOMMU is also broken on VIA, but forced swiotlb should work. However it is a bit slow because it will force all IO through an additional copy. If it helps I can do a proper patch that only bounces IO > 4GB through the copy. > Honestly, should I chuck this board through the window of my nearest > ASUS and/or VIA office, and buy an NForce board? We can probably get it to work, but you're clearly outside validated territory (= you're running the hardware in a untested by the vendor configuration). Normally that's not a good idea. BTW there are NForce systems with similar problems, but they are rare. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
OK, here are the results with iommu=force. All of these are copied down by hand, so please forgive any transcription errors: 2.6.12[1]: Last line displayed on screen is "ata1: dev 0 ATA max UDMA/133 390721968 sectors, lba48". Then it sits there. Scrolling with shift-pgup/pgdown works. Control-Alt-Del reboots the machine. According to /var/log/dmesg, the next line --- which never appears --- should be "ata1: dev 0 configured for UDMA/133" 2.6.17-1: The kernel panics with a null pointer dereference on loading uhci_hcd. The addresses given are usb_kick_khud+7, usb_hc_died+106, pcibios_set_master+30, etc. After the panic, it sits there (just like 2.6.12) 2.6.17-mm6: The last line displayed is "SATA link up 1.5 Gbps SStatus 113 Scontrol 300". It completely hangs: neither scrolling nor control-alt-del work. Honestly, should I chuck this board through the window of my nearest ASUS and/or VIA office, and buy an NForce board? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Unnecessary check in __sk_stream_mem_reclaim?
Folks, It looks to me like this check here in net/core/stream.c for __sk_stream_mem_reclaim: if (sk->sk_forward_alloc >= SK_STREAM_MEM_QUANTUM) { is unnecessary. It is also done in include/net/sock.h for sk_stream_mem_reclaim which if the test succeeds calls __sk_stream_mem_reclaim. This is the only use of it in the kernel. Now sk_stream_mem_reclaim seems to be in the current form for perfomance reasons which make sense so I think it makes sense to remove it from __sk_stream_mem_reclaim The danger of removing the check is an external module could use it - which I suspect is highly unlikely. This could be overcome by removing the export_symbol_gpl and shifting the function into the header file although this would result in mutliple instances being linked in. I am guessing that there is a smarter way to do this though which still results in the symbol not being exported. I don't know my way around the linking/exporting very well. Comments? I guess if this was done it would have to be put in feature removal schedule though because it is currently exported? Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]NET: Add ECN support for TSO
From: "Ravinandan Arakali" <[EMAIL PROTECTED]> Date: Tue, 11 Jul 2006 18:45:48 -0700 > tk = tcp_sk(skb->sk); > if (tk->ecn_flags & TCP_ECN_OK) >/* Check CE, ECE, CWR etc */ > > I find that skb->sk is NULL. Is this the correct way to check the > per-session > ECN capability ? Why is skb->sk NULL ? On receive? There is no reason for skb->sk to be anything other than NULL on receive, the networking stack hasn't even seen the packet yet. Only the driver has seen the skb. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH]NET: Add ECN support for TSO
Michael/David, Thanks for the comments on LRO. The current LRO code in S2io driver is not aware of ECN. While I was trying to fix this, the first thing I encountered was to check, in the driver, if ECN is enabled for current session. To do this, I try to get hold of the socket by doing something like: tk = tcp_sk(skb->sk); if (tk->ecn_flags & TCP_ECN_OK) /* Check CE, ECE, CWR etc */ I find that skb->sk is NULL. Is this the correct way to check the per-session ECN capability ? Why is skb->sk NULL ? Thanks, Ravi -Original Message- From: David Miller [mailto:[EMAIL PROTECTED] Sent: Saturday, July 08, 2006 1:32 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; netdev@vger.kernel.org Subject: Re: [PATCH]NET: Add ECN support for TSO From: "Michael Chan" <[EMAIL PROTECTED]> Date: Fri, 7 Jul 2006 18:01:34 -0700 > However, Large Receive Offload will be a different story. If > packets are accumulated in the hardware and presented to the stack > as one large packet, the stack will not be able to calculate the > cumulative NS correctly. Unless the hardware calculates the partial > NS over the LRO packet and puts it in the SKB when handing over the > packet. This is correct, LRO hardware would need to do something to make sure the nonce parity works out. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] workaround zd1201 interference problem
Pavel Machek wrote: I'd actually like you to keep it, it does not seem ZyDas contacts are going anywhere. ZyDAS did not respond to me about this. At least we know more about the problem now anyway :) Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DOC]: generic netlink
On Tue, 20 Jun 2006 10:50:13 -0400 jamal wrote: > > > > PS:- I dont have a good place to put this doc and point to, hence the > > > 17K attachment > > > > > > > http://www.kernel.org/pub/linux/kernel/people/hadi/ ? > > > > (unless your permissions have been revoked for lack of use ! :-) > > > > I am only allowed to put kernel patches there by the powers that be. So > this wont fit the criteria. It is hard to believe in these > times my ISP charges me $1/M/month every time i exceed my allocated 5M > quota. I have been with this ISP for > 10 years, hence migration gets > harder - and given that many years on the same account, even my .bashrc > approaches 5M ;-> so make it a patch to Documentation/networking/... I have some doc corrections, Jamal. Do I send them against the 2006-june-19 doc posting? and as email comments or as a patch? thanks, --- ~Randy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question on device events and unregister_netdev.
David Miller wrote: From: Ben Greear <[EMAIL PROTECTED]> Date: Tue, 11 Jul 2006 16:27:25 -0700 So, the question is: Should I be calling unregister_netdev from the notifier callback? Not really, as you saw it can be deadlock prone. One idea is to run the unregister asynchronously via a workqueue. That should be able to get you out of the deadlock. After more poking, I notice that 802.1q uses unregister_netdevice, which does not grab rtnl. It seems that the notifiers are always called with rtnl asserted. That would be a recursive call to unregister_netdevice, however...any reason that won't work? Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question on device events and unregister_netdev.
From: Ben Greear <[EMAIL PROTECTED]> Date: Tue, 11 Jul 2006 16:27:25 -0700 > So, the question is: Should I be calling unregister_netdev from the > notifier callback? Not really, as you saw it can be deadlock prone. One idea is to run the unregister asynchronously via a workqueue. That should be able to get you out of the deadlock. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Question on device events and unregister_netdev.
Hello! I'm working on stacking some virtual interfaces, and ran into a problem with locking. Basically, I have an ethernet-like device, and on top of that I am putting 802.1Q vlans..and on top of that, some other vlan (macvlan). In the event notifier for the vlan, I attempt to delete all vlans who's under-lying device is going away. I do the same for the macvlan. Currently, I am setting a deadlock warning because the macvlan code is calling unregister_netdev, but the 'rmmod' method already has a lock in there due to having earlier called unregister_netdev on the .1q vlan. So, the question is: Should I be calling unregister_netdev from the notifier callback? Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPCOMP]: Fix truesize after decompression
On Tue, Jul 11, 2006 at 04:22:17PM -0700, David Miller wrote: > > What ATM is doing here is charging the SKB to the virtual circuit > sockets. At least in the few cases I've looked at just now, the > skb is some private ATM level signalling message, and not part of > a normal transmit/receive packet from the normal networking stack. Indeed, at least they do have an sk to charge things to :) -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPCOMP]: Fix truesize after decompression
From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 12 Jul 2006 09:12:51 +1000 > On Tue, Jul 11, 2006 at 01:55:53PM -0700, David Miller wrote: > > > > I think it is possible cover a certain class of these situations > > from within pskb_expand_head. For example, if skb->sk is NULL > > we can prove that updating skb->truesize is safe since no > > socket's buffer accounting can possible depend upon the truesize > > value of this skb. > > Yes that's certainly possible. However, we'll need to audit the few > spots (e.g., ATM) that use truesize without setting skb->sk. Yuck, I'd forgotten about that usage What ATM is doing here is charging the SKB to the virtual circuit sockets. At least in the few cases I've looked at just now, the skb is some private ATM level signalling message, and not part of a normal transmit/receive packet from the normal networking stack. Therefore, there seems to be no reason why ATM can't use the destructor callback of the SKB to manage this accounting just like the rest of the kernel does. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Two BUG warnings in net/core/dev.c
john stultz <[EMAIL PROTECTED]> wrote: > Both of these were seen on my laptop w/ the current (as of this writing) > -git tree using the e1000 driver after a suspend/resume cycle. It's just a reminder that we need to fix NAT to update checksums incrementally. You'll only see it once per boot. > BUG: warning at net/core/dev.c:1171/skb_checksum_help() > [] show_trace_log_lvl+0x149/0x170 > [] show_trace+0x1b/0x20 > [] dump_stack+0x24/0x30 > [] skb_checksum_help+0x163/0x170 > [] ip_nat_fn+0x1a5/0x210 Of course, if anyone sees it with a backtrace that does not contain ip_nat_fn, please let us know. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPCOMP]: Fix truesize after decompression
On Tue, Jul 11, 2006 at 01:55:53PM -0700, David Miller wrote: > > I think it is possible cover a certain class of these situations > from within pskb_expand_head. For example, if skb->sk is NULL > we can prove that updating skb->truesize is safe since no > socket's buffer accounting can possible depend upon the truesize > value of this skb. Yes that's certainly possible. However, we'll need to audit the few spots (e.g., ATM) that use truesize without setting skb->sk. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Two BUG warnings in net/core/dev.c
Both of these were seen on my laptop w/ the current (as of this writing) -git tree using the e1000 driver after a suspend/resume cycle. thanks -john BUG: warning at net/core/dev.c:1171/skb_checksum_help() [] show_trace_log_lvl+0x149/0x170 [] show_trace+0x1b/0x20 [] dump_stack+0x24/0x30 [] skb_checksum_help+0x163/0x170 [] ip_nat_fn+0x1a5/0x210 [] ip_nat_local_fn+0x65/0xf0 [] nf_iterate+0x60/0x90 [] nf_hook_slow+0x5c/0x100 [] ip_queue_xmit+0x1f1/0x4c0 [] tcp_transmit_skb+0x3bf/0x7d0 [] tcp_push_one+0x9f/0x120 [] tcp_sendmsg+0x393/0xbf0 [] inet_sendmsg+0x35/0x60 [] sock_sendmsg+0xcd/0x100 [] sys_sendto+0xd3/0x100 [] sys_send+0x32/0x40 [] sys_socketcall+0x142/0x260 [] sysenter_past_esp+0x56/0x8d [] 0xb7fa8410 BUG: warning at net/core/dev.c:1225/skb_gso_segment() [] show_trace_log_lvl+0x149/0x170 [] show_trace+0x1b/0x20 [] dump_stack+0x24/0x30 [] skb_gso_segment+0x20a/0x210 [] dev_hard_start_xmit+0x15f/0x300 [] __qdisc_run+0x7b/0x1f0 [] dev_queue_xmit+0x127/0x310 [] neigh_resolve_output+0xec/0x2a0 [] ip_output+0x170/0x260 [] ip_queue_xmit+0x2a6/0x4c0 [] tcp_transmit_skb+0x3bf/0x7d0 [] tcp_push_one+0x9f/0x120 [] tcp_sendmsg+0x393/0xbf0 [] inet_sendmsg+0x35/0x60 [] sock_sendmsg+0xcd/0x100 [] sys_sendto+0xd3/0x100 [] sys_send+0x32/0x40 [] sys_socketcall+0x142/0x260 [] sysenter_past_esp+0x56/0x8d [] 0xb7fa8410 - To unsubscribe from this list: send the 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] softmac: do shared key auth in workqueue
On Wednesday 12 July 2006 00:16, you wrote: > Johann Uhrmann reported a bcm43xx crash and Michael Buesch tracked it down > to a problem with the new shared key auth code (recursive calls into the > driver) > > This patch (effectively Michael's patch with a couple of small modifications) > solves the problem by sending the authentication challenge response frame > from a workqueue entry. > > I also removed a lone \n from the bcm43xx messages relating to authentication > mode - this small change was previously discussed but not patched in. > > Signed-off-by: Daniel Drake <[EMAIL PROTECTED]> > Acked-by: Johannes Berg <[EMAIL PROTECTED]> Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> > > Index: linux/net/ieee80211/softmac/ieee80211softmac_auth.c > === > --- linux.orig/net/ieee80211/softmac/ieee80211softmac_auth.c > +++ linux/net/ieee80211/softmac/ieee80211softmac_auth.c > @@ -116,6 +116,16 @@ ieee80211softmac_auth_queue(void *data) > kfree(auth); > } > > +/* Sends a response to an auth challenge (for shared key auth). */ > +static void > +ieee80211softmac_auth_challenge_response(void *_aq) > +{ > + struct ieee80211softmac_auth_queue_item *aq = _aq; > + > + /* Send our response */ > + ieee80211softmac_send_mgt_frame(aq->mac, aq->net, IEEE80211_STYPE_AUTH, > aq->state); > +} > + > /* Handle the auth response from the AP > * This should be registered with ieee80211 as handle_auth > */ > @@ -197,24 +207,30 @@ ieee80211softmac_auth_resp(struct net_de > case IEEE80211SOFTMAC_AUTH_SHARED_CHALLENGE: > /* Check to make sure we have a challenge IE */ > data = (u8 *)auth->info_element; > - if(*data++ != MFIE_TYPE_CHALLENGE){ > + if (*data++ != MFIE_TYPE_CHALLENGE) { > printkl(KERN_NOTICE PFX "Shared Key > Authentication failed due to a missing challenge.\n"); > break; > } > /* Save the challenge */ > spin_lock_irqsave(&mac->lock, flags); > net->challenge_len = *data++; > - if(net->challenge_len > WLAN_AUTH_CHALLENGE_LEN) > + if (net->challenge_len > WLAN_AUTH_CHALLENGE_LEN) > net->challenge_len = WLAN_AUTH_CHALLENGE_LEN; > - if(net->challenge != NULL) > + if (net->challenge != NULL) > kfree(net->challenge); > net->challenge = kmalloc(net->challenge_len, > GFP_ATOMIC); > memcpy(net->challenge, data, net->challenge_len); > aq->state = IEEE80211SOFTMAC_AUTH_SHARED_RESPONSE; > - spin_unlock_irqrestore(&mac->lock, flags); > > - /* Send our response */ > - ieee80211softmac_send_mgt_frame(mac, aq->net, > IEEE80211_STYPE_AUTH, aq->state); > + /* We reuse the work struct from the auth request here. > + * It is safe to do so as each one is per-request, and > + * at this point (dealing with authentication response) > + * we have obviously already sent the initial auth > + * request. */ > + cancel_delayed_work(&aq->work); > + INIT_WORK(&aq->work, > &ieee80211softmac_auth_challenge_response, (void *)aq); > + schedule_work(&aq->work); > + spin_unlock_irqrestore(&mac->lock, flags); > return 0; > case IEEE80211SOFTMAC_AUTH_SHARED_PASS: > kfree(net->challenge); > Index: linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c > === > --- linux.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c > +++ linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c > @@ -3701,7 +3701,7 @@ static void bcm43xx_ieee80211_set_securi > } > if (sec->flags & SEC_AUTH_MODE) { > secinfo->auth_mode = sec->auth_mode; > - dprintk(", .auth_mode = %d\n", sec->auth_mode); > + dprintk(", .auth_mode = %d", sec->auth_mode); > } > dprintk("\n"); > if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED && > -- 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: oops in current -git
This happen to me with FC4 and 2.6.17-1.2141_FC4. I have eth0=e100, eth1=8139too and wlan0=hostap_pci. When ACPI is enabled, all works. If acpi=off it hangs for a minute (at stage: Bringing up interface eth1: Determinig IP information for eth1...SIOCSIFFLAGS: Device of recource busy) and then recovers but only eth0 works. But when I put 'acpi=off noapic nolapic' all works again. Strange Linux version 2.6.17-1.2141_FC4 ([EMAIL PROTECTED]) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Fri Jun 30 14:53:04 EDT 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000ca000 - 000ce000 (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff8000 (ACPI data) BIOS-e820: 1fff8000 - 2000 (ACPI NVS) BIOS-e820: fff0 - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. found SMP MP-table at 000fb6b0 Using x86 segment limits to approximate NX protection On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 126960 pages, LIFO batch:31 DMI 2.3 present. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: INTELProduct ID: I845 APIC at: 0xFEE0 Processor #0 15:1 APIC version 20 I/O APIC #2 Version 32 at 0xFEC0. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 1 Allocating PCI resources starting at 3000 (gap: 2000:dff0) Built 1 zonelists Kernel command line: ro root=LABEL=/ vga=771 acpi=off mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c077d000 soft=c077e000 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 1594.361 MHz processor. Using tsc for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 514048k/524224k available (1977k kernel code, 9552k reserved, 1358k data, 212k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 3193.59 BogoMIPS (lpj=6387188) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: After generic identify, caps: 3febfbff CPU: After vendor identify, caps: 3febfbff CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 256K CPU: After all inits, caps: 3febf3ff 0080 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU0: Intel P4/Xeon Extended MCE MSRs (12) available CPU0: Thermal monitoring enabled CPU: Intel(R) Pentium(R) 4 CPU 1.60GHz stepping 02 Checking 'hlt' instruction... OK. ExtINT not setup in hardware but reported by MP table ENABLING IO-APIC IRQs ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0 checking if image is initramfs... it is Freeing initrd memory: 1070k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfdab1, last bus=2 Setting up standard PCI resources ACPI: Subsystem revision 20060127 ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI quirk: region 0800-087f claimed by ICH4 ACPI/GPIO/TCO PCI quirk: region 0400-043f claimed by ICH4 GPIO Boot video device is :01:00.0 PCI: Transparent bridge - :00:1e.0 PCI: Using IRQ router PIIX/ICH [8086/2440] at :00:1f.0 PCI->APIC IRQ transform: :00:1f.2[D] -> IRQ 185 PCI->APIC IRQ transform: :00:1f.3[B] -> IRQ 177 PCI->APIC IRQ transform: :00:1f.4[C] -> IRQ 201 PCI->APIC IRQ transform: :00:1f.5[B] -> IRQ 177 PCI->APIC IRQ transform: :01:00.0[A] -> IRQ 169 PCI->APIC IRQ transform: :02:08.0[A] -> IRQ 193 PCI: Bridge: :00:01.0 IO window: 9000-9fff MEM window: dfd0-dfdf PREFETCH window: d7a0-dfaf PCI: Bridge: :00:1e.0 IO window: a000-afff MEM window: dfe0-dfef PREFETCH window: dfb0-dfbf PCI: Setting latency timer of device :00:1e.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 4096 (order: 2, 16384 bytes) TCP established hash table entries: 16384 (order: 6, 262144 bytes) TCP bind hash table entries: 8192 (order: 5,
[PATCH] softmac: do shared key auth in workqueue
Johann Uhrmann reported a bcm43xx crash and Michael Buesch tracked it down to a problem with the new shared key auth code (recursive calls into the driver) This patch (effectively Michael's patch with a couple of small modifications) solves the problem by sending the authentication challenge response frame from a workqueue entry. I also removed a lone \n from the bcm43xx messages relating to authentication mode - this small change was previously discussed but not patched in. Signed-off-by: Daniel Drake <[EMAIL PROTECTED]> Acked-by: Johannes Berg <[EMAIL PROTECTED]> Index: linux/net/ieee80211/softmac/ieee80211softmac_auth.c === --- linux.orig/net/ieee80211/softmac/ieee80211softmac_auth.c +++ linux/net/ieee80211/softmac/ieee80211softmac_auth.c @@ -116,6 +116,16 @@ ieee80211softmac_auth_queue(void *data) kfree(auth); } +/* Sends a response to an auth challenge (for shared key auth). */ +static void +ieee80211softmac_auth_challenge_response(void *_aq) +{ + struct ieee80211softmac_auth_queue_item *aq = _aq; + + /* Send our response */ + ieee80211softmac_send_mgt_frame(aq->mac, aq->net, IEEE80211_STYPE_AUTH, aq->state); +} + /* Handle the auth response from the AP * This should be registered with ieee80211 as handle_auth */ @@ -197,24 +207,30 @@ ieee80211softmac_auth_resp(struct net_de case IEEE80211SOFTMAC_AUTH_SHARED_CHALLENGE: /* Check to make sure we have a challenge IE */ data = (u8 *)auth->info_element; - if(*data++ != MFIE_TYPE_CHALLENGE){ + if (*data++ != MFIE_TYPE_CHALLENGE) { printkl(KERN_NOTICE PFX "Shared Key Authentication failed due to a missing challenge.\n"); break; } /* Save the challenge */ spin_lock_irqsave(&mac->lock, flags); net->challenge_len = *data++; - if(net->challenge_len > WLAN_AUTH_CHALLENGE_LEN) + if (net->challenge_len > WLAN_AUTH_CHALLENGE_LEN) net->challenge_len = WLAN_AUTH_CHALLENGE_LEN; - if(net->challenge != NULL) + if (net->challenge != NULL) kfree(net->challenge); net->challenge = kmalloc(net->challenge_len, GFP_ATOMIC); memcpy(net->challenge, data, net->challenge_len); aq->state = IEEE80211SOFTMAC_AUTH_SHARED_RESPONSE; - spin_unlock_irqrestore(&mac->lock, flags); - /* Send our response */ - ieee80211softmac_send_mgt_frame(mac, aq->net, IEEE80211_STYPE_AUTH, aq->state); + /* We reuse the work struct from the auth request here. +* It is safe to do so as each one is per-request, and +* at this point (dealing with authentication response) +* we have obviously already sent the initial auth +* request. */ + cancel_delayed_work(&aq->work); + INIT_WORK(&aq->work, &ieee80211softmac_auth_challenge_response, (void *)aq); + schedule_work(&aq->work); + spin_unlock_irqrestore(&mac->lock, flags); return 0; case IEEE80211SOFTMAC_AUTH_SHARED_PASS: kfree(net->challenge); Index: linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c === --- linux.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c +++ linux/drivers/net/wireless/bcm43xx/bcm43xx_main.c @@ -3701,7 +3701,7 @@ static void bcm43xx_ieee80211_set_securi } if (sec->flags & SEC_AUTH_MODE) { secinfo->auth_mode = sec->auth_mode; - dprintk(", .auth_mode = %d\n", sec->auth_mode); + dprintk(", .auth_mode = %d", sec->auth_mode); } dprintk("\n"); if (bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED && - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] vlan handling of up/down
Am Dienstag, 11. Juli 2006 23:28 schrieb Stephen Hemminger: > Untested, but here is the basic idea of how I think up/down should be > handled. Basically, rather than changing the flags directly the VLAN code > should call dev_open/dev_close. The notifier end's up recursively calling > but this is okay. Seems false alarm. I've just tested 2.6.16(-Suse), and new VLAN devices have been registered as admin down. Same for 2.6.17 as even with my change __LINK_STATE_START was not transferred. > - new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START); No reason to change this behaviour, we just need to stop messing with new_dev->state (IMHO too late for 2.6.18, but I've already been wrong ;-) 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()
Ok, the following patch should fix the problem. Patrick, can you give it a try? As the bug did not affect me through my testing, I want to be sure it works now. This is stuff for 2.6.18 and 2.6.17-stable. Stefan [VLAN]: Fix link state propagation When the queue of the underlying device is stopped at initialization time or the device is marked "not present", the state will be propagated to the vlan device and never change. This also fixes VLAN devices being wrongly registered as admin up since 2.6.17. Based on an analysis by Patrick McHardy. Signed-off-by: Stefan Rompf <[EMAIL PROTECTED]> --- linux-2.6.17/net/8021q/vlan.c.orig 2006-07-07 13:00:56.0 +0200 +++ linux-2.6.17/net/8021q/vlan.c 2006-07-11 23:20:32.0 +0200 @@ -67,10 +67,6 @@ static struct packet_type vlan_packet_ty .func = vlan_skb_recv, /* VLAN receive method */ }; -/* Bits of netdev state that are propagated from real device to virtual */ -#define VLAN_LINK_STATE_MASK \ - ((1<<__LINK_STATE_PRESENT)|(1<<__LINK_STATE_NOCARRIER)|(1<<__LINK_STATE_DORMANT)) - /* End of global variables definitions. */ /* @@ -470,7 +466,9 @@ static struct net_device *register_vlan_ new_dev->flags = real_dev->flags; new_dev->flags &= ~IFF_UP; - 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); /* need 4 bytes for extra VLAN header info, * hope the underlying device can handle 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
Repost: Re: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
VLAN devices did not get registered as admin up in 2.6.16 and IMHO also not in 2.6.17. So update patch description. Ok, the following patch should fix the problem. Patrick, can you give it a try? As the bug did not affect me through my testing, I want to be sure it works now. This is stuff for 2.6.18 and 2.6.17-stable. Stefan [VLAN]: Fix link state propagation When the queue of the underlying device is stopped at initialization time or the device is marked "not present", the state will be propagated to the vlan device and never change. Based on an analysis by Patrick McHardy. Signed-off-by: Stefan Rompf <[EMAIL PROTECTED]> --- linux-2.6.17/net/8021q/vlan.c.orig 2006-07-07 13:00:56.0 +0200 +++ linux-2.6.17/net/8021q/vlan.c 2006-07-11 23:20:32.0 +0200 @@ -67,10 +67,6 @@ static struct packet_type vlan_packet_ty .func = vlan_skb_recv, /* VLAN receive method */ }; -/* Bits of netdev state that are propagated from real device to virtual */ -#define VLAN_LINK_STATE_MASK \ - ((1<<__LINK_STATE_PRESENT)|(1<<__LINK_STATE_NOCARRIER)|(1<<__LINK_STATE_DORMANT)) - /* End of global variables definitions. */ /* @@ -470,7 +466,9 @@ static struct net_device *register_vlan_ new_dev->flags = real_dev->flags; new_dev->flags &= ~IFF_UP; - 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); /* need 4 bytes for extra VLAN header info, * hope the underlying device can handle 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: 2.6.18-rc1-mm1 inconsistent lock state in netpoll_send_skb
Le 11.07.2006 10:40, Arjan van de Ven a écrit : >> 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. > > ok these patches ought to fix this for real (sorry I don't have this > hardware so I cannot actually do the testing) > > I hope you have time to test these.. > > Greetings, >Arjan van de Ven > > From: Arjan van de Ven <[EMAIL PROTECTED]> > Subject: lockdep: core, add enable/disable_irq_irqsave/irqrestore() APIs > > Introduce the disable_irq_nosync_lockdep_irqsave() and > enable_irq_lockdep_irqrestore() APIs. > These are needed for NE2000; basically NE2000 calls disable_irq and > enable_irq as locking > against the IRQ handler, but both in cases where interrupts are on and off. > This means that > lockdep needs to track the old state of the virtual irq flags on disable_irq, > and restore these > at enable_irq time. > > Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> > Index: linux-2.6.18-rc1/include/linux/interrupt.h > === > --- linux-2.6.18-rc1.orig/include/linux/interrupt.h > +++ linux-2.6.18-rc1/include/linux/interrupt.h > @@ -123,6 +123,14 @@ static inline void disable_irq_nosync_lo > #endif > } > > +static inline void disable_irq_nosync_lockdep_irqsave(unsigned int irq, > unsigned long *flags) > +{ > + disable_irq_nosync(irq); > +#ifdef CONFIG_LOCKDEP > + local_irq_save(*flags); > +#endif > +} > + > static inline void disable_irq_lockdep(unsigned int irq) > { > disable_irq(irq); > @@ -139,6 +147,14 @@ static inline void enable_irq_lockdep(un > enable_irq(irq); > } > > +static inline void enable_irq_lockdep_irqrestore(unsigned int irq, unsigned > long *flags) > +{ > +#ifdef CONFIG_LOCKDEP > + local_irq_restore(*flags); > +#endif > + enable_irq(irq); > +} > + > /* IRQ wakeup (PM) control: */ > extern int set_irq_wake(unsigned int irq, unsigned int on); > > From: Arjan van de Ven <[EMAIL PROTECTED]> > Subject: lockdep: annotate the ne2000 driver with the new disable_irq API > addition > > The ne2000 driver's xmit function gets called from netpoll with the > _xmit_lock spinlock held as _irqsave. This means the xmit function needs to > preserve this > irq-off state throughout to avoid deadlock. It does, but we need to also tell > lockdep that > the function indeed does this by using the proper disable_irq annotation. > > Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> > > Index: linux-2.6.18-rc1/drivers/net/8390.c > === > --- linux-2.6.18-rc1.orig/drivers/net/8390.c > +++ linux-2.6.18-rc1/drivers/net/8390.c > @@ -299,7 +299,7 @@ static int ei_start_xmit(struct sk_buff >* Slow phase with lock held. >*/ > > - disable_irq_nosync_lockdep(dev->irq); > + disable_irq_nosync_lockdep_irqsave(dev->irq, &flags); > > 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_lockdep(dev->irq); > + enable_irq_lockdep_irqrestore(dev->irq, &flags); > 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_lockdep(dev->irq); > + enable_irq_lockdep_irqrestore(dev->irq, &flags); > > dev_kfree_skb (skb); > ei_local->stat.tx_bytes += send_length; > > Well, the warning did not go away: = [ INFO: inconsistent lock state ] - inconsistent {in-softirq-W} -> {softirq-on-W} usage. swapper/1 [HC0[0]:SC0[0]:HE1:SE1] takes: (&dev->_xmit_lock){-+..}, at: [] netpoll_send_skb+0x6b/0xdb {in-softirq-W} state was registered at: [] lock_acquire+0x60/0x80 [] _spin_lock+0x19/0x28 [] dev_watchdog+0x11/0xaf [] run_timer_softirq+0xed/0x145 [] __do_softirq+0x46/0x9c [] do_softirq+0x4d/0xab irq event stamp: 616419 hardirqs last enabled at (616419): [] restore_nocheck+0x12/0x15 hardirqs last disabled at (616417): [] __do_softirq+0x5f/0x9c softirqs last enabled at (616418): [] __do_softirq+0x97/0x9c softirqs last disabled at (616413): [] do_softirq+0x4d/0xab other info that might help us debug this: no locks held by swapper/1. stack backtrace: [] show_trace+0xd/0x10 [] dump_stack+0x19/0x1d [] print_usage_bug+0x1cc/0x1d9 [] mark_lock+0x22d/0x349 [] __lock_acquire+0x463/0x9a5 [] lock_acquire+0x60/0x80 [] _spin_lock+0x19/0x28 [] netpoll_send_skb+0x6b/0xdb [] netpoll_send_udp+0x
Re: e1000 TX unit hang (redux)
Hi Auke, On Tuesday 11 July 2006 14:09, Auke Kok wrote: > > > that seems to address this problem by creating a > > > > tx_timeout_factor relative to the speed of the NIC. However, there is no > > mention of this workaround/fix on the bug at the link above and I haven't > > found any discussion of it here on netdev. > > I wouldn't even know what patch you are talking about (?!) Ok, well, the patch is in 2.6.17.4 and looks to have been announced in the 2.6.16-c2 changelog -- http://lwn.net/Articles/170529/ -- and written by Jeff Kirsher. I haven't been able to find a link to the original patch submission anywhere. The code looks something like this now: /* Detect a transmit hang in hardware, this serializes the * check with the clearing of time_stamp and movement of i */ adapter->detect_tx_hung = FALSE; if (tx_ring->buffer_info[eop].dma && time_after(jiffies, tx_ring->buffer_info[eop].time_stamp + (adapter->tx_timeout_factor * HZ)) && !(E1000_READ_REG(&adapter->hw, STATUS) & E1000_STATUS_TXOFF)) { ..where the tx_timeout_factor has been added and is set in the watchdog code based on the link speed. > that's not only impossible but also unlikely - we don't push changes to 2.4 > kernels anymore a lot, I think the last change is likely older than 2.4.28. I'm sure you're right. Jumped to conclusions on a patch I saw posted at redhat.. I'll be more careful next time :) I'll also try to get some better debugging info from my side. Thanks. Shaw - To unsubscribe from this list: send the 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 Tue, Jul 11, 2006 at 04:42:13PM +0200, Arjan van de Ven wrote: > just load fakephp Thanks! I'd never heard of it :-) Joel -- "The only way to get rid of a temptation is to yield to it." - Oscar Wilde 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: [RFC] vlan handling of up/down
Stephen Hemminger wrote: Untested, but here is the basic idea of how I think up/down should be handled. Basically, rather than changing the flags directly the VLAN code should call dev_open/dev_close. The notifier end's up recursively calling but this is okay. --- vlan.orig/net/8021q/vlan.c +++ vlan/net/8021q/vlan.c @@ -427,7 +427,7 @@ static struct net_device *register_vlan_ /* The real device must be up and operating in order to * assosciate a VLAN device with it. */ - if (!(real_dev->flags & IFF_UP)) + if (!netif_running(real_dev)) goto out_unlock; I can't remember why I thought this check was a good idea..but is there any reason to keep it in? I mean, why not allow attaching VLANs to a 'down' device? if (__find_vlan_dev(real_dev, VLAN_ID) != NULL) { @@ -476,10 +476,7 @@ static struct net_device *register_vlan_ printk(VLAN_DBG "Allocated new name -:%s:-\n", new_dev->name); #endif /* IFF_BROADCAST|IFF_MULTICAST; ??? */ - new_dev->flags = real_dev->flags; - new_dev->flags &= ~IFF_UP; - - new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START); + new_dev->flags = real_dev->flags & ~IFF_UP; /* need 4 bytes for extra VLAN header info, * hope the underlying device can handle it. @@ -566,6 +563,9 @@ static struct net_device *register_vlan_ if (real_dev->features & NETIF_F_HW_VLAN_FILTER) real_dev->vlan_rx_add_vid(real_dev, VLAN_ID); + /* Real device is up so bring up the vlan */ + dev_open(new_dev); + rtnl_unlock(); Assuming we take out the 'is-up' check above, this would need a check added here (if real-dev is up, then bring up vlan, else leave it down.) @@ -624,11 +624,7 @@ static int vlan_device_event(struct noti if (!vlandev) continue; - flgs = vlandev->flags; - if (!(flgs & IFF_UP)) - continue; - - dev_change_flags(vlandev, flgs & ~IFF_UP); + dev_close(vlandev); } break; @@ -638,12 +634,8 @@ static int vlan_device_event(struct noti vlandev = grp->vlan_devices[i]; if (!vlandev) continue; - - flgs = vlandev->flags; - if (flgs & IFF_UP) - continue; - dev_change_flags(vlandev, flgs | IFF_UP); + dev_open(vlandev); } break; Although it may be too late to change this (don't want to change user-visible behaviour), I don't really like that bouncing the real-dev could cause the VLANs to come up, even if previously user-space had forced them down. Perhaps a piece of state in the vlan dev could be added to remember the 'desired state', and then only bring back up interfaces that are desired-up when the real-dev comes back online Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] cleanup // comments from ipw2200
ipw2200 uses // comments, and uses them for removing unneeded code. Clean it up a bit. Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c index b3300ff..758459e 100644 --- a/drivers/net/wireless/ipw2200.c +++ b/drivers/net/wireless/ipw2200.c @@ -2667,7 +2667,7 @@ static void ipw_fw_dma_abort(struct ipw_ IPW_DEBUG_FW(">> :\n"); - //set the Stop and Abort bit + /* set the Stop and Abort bit */ control = DMA_CONTROL_SMALL_CB_CONST_VALUE | DMA_CB_STOP_AND_ABORT; ipw_write_reg32(priv, IPW_DMA_I_DMA_CONTROL, control); priv->sram_desc.last_cb_index = 0; @@ -3002,8 +3002,6 @@ static int ipw_load_ucode(struct ipw_pri if (rc < 0) return rc; -// spin_lock_irqsave(&priv->lock, flags); - for (addr = IPW_SHARED_LOWER_BOUND; addr < IPW_REGISTER_DOMAIN1_END; addr += 4) { ipw_write32(priv, addr, 0); @@ -3097,8 +3095,6 @@ static int ipw_load_ucode(struct ipw_pri firmware have problem getting alive resp. */ ipw_write_reg8(priv, IPW_BASEBAND_CONTROL_STATUS, 0); -// spin_unlock_irqrestore(&priv->lock, flags); - return rc; } @@ -6387,13 +6383,6 @@ static int ipw_wx_set_genie(struct net_d (wrqu->data.length && extra == NULL)) return -EINVAL; - //mutex_lock(&priv->mutex); - - //if (!ieee->wpa_enabled) { - // err = -EOPNOTSUPP; - // goto out; - //} - if (wrqu->data.length) { buf = kmalloc(wrqu->data.length, GFP_KERNEL); if (buf == NULL) { @@ -6413,7 +6402,6 @@ static int ipw_wx_set_genie(struct net_d ipw_wpa_assoc_frame(priv, ieee->wpa_ie, ieee->wpa_ie_len); out: - //mutex_unlock(&priv->mutex); return err; } @@ -6426,13 +6414,6 @@ static int ipw_wx_get_genie(struct net_d struct ieee80211_device *ieee = priv->ieee; int err = 0; - //mutex_lock(&priv->mutex); - - //if (!ieee->wpa_enabled) { - // err = -EOPNOTSUPP; - // goto out; - //} - if (ieee->wpa_ie_len == 0 || ieee->wpa_ie == NULL) { wrqu->data.length = 0; goto out; @@ -6447,7 +6428,6 @@ static int ipw_wx_get_genie(struct net_d memcpy(extra, ieee->wpa_ie, ieee->wpa_ie_len); out: - //mutex_unlock(&priv->mutex); return err; } @@ -6558,7 +6538,6 @@ static int ipw_wx_set_auth(struct net_de ieee->ieee802_1x = param->value; break; - //case IW_AUTH_ROAMING_CONTROL: case IW_AUTH_PRIVACY_INVOKED: ieee->privacy_invoked = param->value; break; @@ -6680,7 +6659,7 @@ static int ipw_wx_set_mlme(struct net_de switch (mlme->cmd) { case IW_MLME_DEAUTH: - // silently ignore + /* silently ignore */ break; case IW_MLME_DISASSOC: @@ -9766,7 +9745,7 @@ static int ipw_wx_set_monitor(struct net return 0; } -#endif // CONFIG_IPW2200_MONITOR +#endif /* CONFIG_IPW2200_MONITOR */ static int ipw_wx_reset(struct net_device *dev, struct iw_request_info *info, @@ -10009,7 +9988,7 @@ static void init_sys_config(struct ipw_ sys_config->dot11g_auto_detection = 0; sys_config->enable_cts_to_self = 0; sys_config->bt_coexist_collision_thr = 0; - sys_config->pass_noise_stats_to_host = 1; //1 -- fix for 256 + sys_config->pass_noise_stats_to_host = 1; /* 1 -- fix for 256 */ sys_config->silence_threshold = 0x1e; } -- (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
On Mon 2006-07-10 23:05:06, Michael Buesch wrote: > 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? Probably not. This (very dirty) hack implements that (with some level of success -- ifconfig down/ifconfig up is enough to get wireless working). Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> Pavel --- clean-mm/drivers/net/wireless/ipw2200.c 2006-07-11 15:22:50.0 +0200 +++ linux-mm/drivers/net/wireless/ipw2200.c 2006-07-11 14:38:01.0 +0200 @@ -97,6 +97,7 @@ static int bt_coexist = 0; static int hwcrypto = 0; static int roaming = 1; +static int needs_reinit = 1; static const char ipw_modes[] = { 'a', 'b', 'g', '?' }; @@ -10013,10 +10014,20 @@ sys_config->silence_threshold = 0x1e; } +static int ipw_pci_suspend(struct pci_dev *pdev, pm_message_t state); +static int ipw_pci_resume(struct pci_dev *pdev); + static int ipw_net_open(struct net_device *dev) { struct ipw_priv *priv = ieee80211_priv(dev); IPW_DEBUG_INFO("dev->open\n"); + + if (needs_reinit) { + printk("ipw: Delayed loading the firmware\n"); + ipw_pci_suspend(priv->pci_dev, PMSG_FREEZE); + ipw_pci_resume(priv->pci_dev); + } + /* we should be verifying the device is ready to be opened */ mutex_lock(&priv->mutex); if (!(priv->status & STATUS_RF_KILL_MASK) && @@ -11295,7 +11306,8 @@ if (ipw_up(priv)) { mutex_unlock(&priv->mutex); - return -EIO; + needs_reinit = 1; + return 0; } mutex_unlock(&priv->mutex); -- (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
[RFC] vlan handling of up/down
Untested, but here is the basic idea of how I think up/down should be handled. Basically, rather than changing the flags directly the VLAN code should call dev_open/dev_close. The notifier end's up recursively calling but this is okay. --- vlan.orig/net/8021q/vlan.c +++ vlan/net/8021q/vlan.c @@ -427,7 +427,7 @@ static struct net_device *register_vlan_ /* The real device must be up and operating in order to * assosciate a VLAN device with it. */ - if (!(real_dev->flags & IFF_UP)) + if (!netif_running(real_dev)) goto out_unlock; if (__find_vlan_dev(real_dev, VLAN_ID) != NULL) { @@ -476,10 +476,7 @@ static struct net_device *register_vlan_ printk(VLAN_DBG "Allocated new name -:%s:-\n", new_dev->name); #endif /* IFF_BROADCAST|IFF_MULTICAST; ??? */ - new_dev->flags = real_dev->flags; - new_dev->flags &= ~IFF_UP; - - new_dev->state = real_dev->state & ~(1<<__LINK_STATE_START); + new_dev->flags = real_dev->flags & ~IFF_UP; /* need 4 bytes for extra VLAN header info, * hope the underlying device can handle it. @@ -566,6 +563,9 @@ static struct net_device *register_vlan_ if (real_dev->features & NETIF_F_HW_VLAN_FILTER) real_dev->vlan_rx_add_vid(real_dev, VLAN_ID); + /* Real device is up so bring up the vlan */ + dev_open(new_dev); + rtnl_unlock(); @@ -624,11 +624,7 @@ static int vlan_device_event(struct noti if (!vlandev) continue; - flgs = vlandev->flags; - if (!(flgs & IFF_UP)) - continue; - - dev_change_flags(vlandev, flgs & ~IFF_UP); + dev_close(vlandev); } break; @@ -638,12 +634,8 @@ static int vlan_device_event(struct noti vlandev = grp->vlan_devices[i]; if (!vlandev) continue; - - flgs = vlandev->flags; - if (flgs & IFF_UP) - continue; - dev_change_flags(vlandev, flgs | IFF_UP); + dev_open(vlandev); } break; -- 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
[PATCH] WAN: converting generic HDLC to use netif_dormant*()
Hi, This patch converts generic HDLC (and WAN drivers using it) from hdlc_set_carrier() to netif_dormant*() interface. WAN hardware drivers should now use netif_carrier_on|off() like other network drivers. Please apply. Thanks. Signed-off-by: Krzysztof Halasa <[EMAIL PROTECTED]> diff --git a/drivers/net/wan/c101.c b/drivers/net/wan/c101.c index 43d854a..3796a59 100644 --- a/drivers/net/wan/c101.c +++ b/drivers/net/wan/c101.c @@ -116,27 +116,33 @@ static inline void openwin(card_t *card, #include "hd6457x.c" +static inline void set_carrier(port_t *port) +{ + if (!sca_in(MSCI1_OFFSET + ST3, port) & ST3_DCD) + netif_carrier_on(port_to_dev(port)); + else + netif_carrier_off(port_to_dev(port)); +} + + static void sca_msci_intr(port_t *port) { - struct net_device *dev = port_to_dev(port); - card_t* card = port_to_card(port); - u8 stat = sca_in(MSCI1_OFFSET + ST1, card); /* read MSCI ST1 status */ + u8 stat = sca_in(MSCI1_OFFSET + ST1, port); /* read MSCI ST1 status */ /* Reset MSCI TX underrun status bit */ - sca_out(stat & ST1_UDRN, MSCI0_OFFSET + ST1, card); + sca_out(stat & ST1_UDRN, MSCI0_OFFSET + ST1, port); if (stat & ST1_UDRN) { - struct net_device_stats *stats = hdlc_stats(dev); + struct net_device_stats *stats = hdlc_stats(port_to_dev(port)); stats->tx_errors++; /* TX Underrun error detected */ stats->tx_fifo_errors++; } /* Reset MSCI CDCD status bit - uses ch#2 DCD input */ - sca_out(stat & ST1_CDCD, MSCI1_OFFSET + ST1, card); + sca_out(stat & ST1_CDCD, MSCI1_OFFSET + ST1, port); if (stat & ST1_CDCD) - hdlc_set_carrier(!(sca_in(MSCI1_OFFSET + ST3, card) & ST3_DCD), -dev); + set_carrier(port); } @@ -190,7 +196,7 @@ static int c101_open(struct net_device * sca_out(IE1_UDRN, MSCI0_OFFSET + IE1, port); sca_out(IE0_TXINT, MSCI0_OFFSET + IE0, port); - hdlc_set_carrier(!(sca_in(MSCI1_OFFSET + ST3, port) & ST3_DCD), dev); + set_carrier(port); printk(KERN_DEBUG "0x%X\n", sca_in(MSCI1_OFFSET + ST3, port)); /* enable MSCI1 CDCD interrupt */ @@ -378,7 +384,7 @@ static int __init c101_run(unsigned long } sca_init_sync_port(card); /* Set up C101 memory */ - hdlc_set_carrier(!(sca_in(MSCI1_OFFSET + ST3, card) & ST3_DCD), dev); + set_carrier(card); printk(KERN_INFO "%s: Moxa C101 on IRQ%u," " using %u TX + %u RX packets rings\n", diff --git a/drivers/net/wan/hd6457x.c b/drivers/net/wan/hd6457x.c index d374332..dce2bb3 100644 --- a/drivers/net/wan/hd6457x.c +++ b/drivers/net/wan/hd6457x.c @@ -168,6 +168,23 @@ static inline u32 buffer_offset(port_t * } +static inline void sca_set_carrier(port_t *port) +{ + if (!(sca_in(get_msci(port) + ST3, port_to_card(port)) & ST3_DCD)) { +#ifdef DEBUG_LINK + printk(KERN_DEBUG "%s: sca_set_carrier on\n", + port_to_dev(port)->name); +#endif + netif_carrier_on(port_to_dev(port)); + } else { +#ifdef DEBUG_LINK + printk(KERN_DEBUG "%s: sca_set_carrier off\n", + port_to_dev(port)->name); +#endif + netif_carrier_off(port_to_dev(port)); + } +} + static void sca_init_sync_port(port_t *port) { @@ -237,9 +254,7 @@ #endif sca_out(DIR_BOFE, DIR_TX(phy_node(port)), card); } } - - hdlc_set_carrier(!(sca_in(get_msci(port) + ST3, card) & ST3_DCD), -port_to_dev(port)); + sca_set_carrier(port); } @@ -262,8 +277,7 @@ static inline void sca_msci_intr(port_t } if (stat & ST1_CDCD) - hdlc_set_carrier(!(sca_in(msci + ST3, card) & ST3_DCD), -port_to_dev(port)); + sca_set_carrier(port); } #endif @@ -566,7 +580,7 @@ #endif - all DMA interrupts */ - hdlc_set_carrier(!(sca_in(msci + ST3, card) & ST3_DCD), dev); + sca_set_carrier(port); #ifdef __HD64570_H /* MSCI TX INT and RX INT A IRQ enable */ diff --git a/drivers/net/wan/hdlc_cisco.c b/drivers/net/wan/hdlc_cisco.c index 1fd0466..f289dab 100644 --- a/drivers/net/wan/hdlc_cisco.c +++ b/drivers/net/wan/hdlc_cisco.c @@ -192,9 +192,7 @@ static int cisco_rx(struct sk_buff *skb) "uptime %ud%uh%um%us)\n", dev->name, days, hrs, min, sec); -#if 0 - netif_carrier_on(dev); -#endif + netif_dormant_off(dev); hdlc->state.cisco.up = 1; } } @@ -227,9 +225,7 @@ static void cisco
Re: e1000 TX unit hang (redux)
[EMAIL PROTECTED] wrote: I have an e1000 card periodically misbehaving with the message 'Detected Tx unit hang'. I've noticed this problem come up on netdev a couple of times and found the link to the bug tracking page-- http://sourceforge.net/tracker/index.php?func=detail&aid=1463045&group_id=42302&atid=447449 I've also seen the patch that I believe was placed in 2.6.16 and subsequently brought down to 2.4.2? that's not only impossible but also unlikely - we don't push changes to 2.4 kernels anymore a lot, I think the last change is likely older than 2.4.28 or so. > that seems to address this problem by creating a tx_timeout_factor relative to the speed of the NIC. However, there is no mention of this workaround/fix on the bug at the link above and I haven't found any discussion of it here on netdev. I wouldn't even know what patch you are talking about (?!) Auke recommends turning off tso to see if that resolves the problem and this also seems to work, though I have as yet not been able to confirm this and would prefer a more performance friendly fix..if available ;) Would one of you pplease give an update on the status of the bug? If a cause was ever found and if the tx_timeout_factor was intended as a fix or temporary workaround? I feel like I must have missed something, because I never saw the tx_timeout_factor patch go through netdev at all.. One possible problem is a bad EEPROM bit, where the hardware might have been misconfigured. This only affects _some_ older e1000's. Any bugreport therefore should include the output of `ethtool -e ethX` (as well as the `lspci -vv` output of course. If you haven't already done so, please submit this to the bugtracker or to us by e-mail 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
Hello Str
Hi Str, I came accross your info online and I wanted to know if you may be interested in exploring some of the new opportunities we are working on. The job market is back in full swing and we are working with a lot of interesting companies.Specifically I was interested in the work you may have done with H.264. If you have any time open to talk today or tomorrow please let me know. I am pretty easy to reach between 8:15am and 6pm. Thanks, Simon Simon Williams Cross Creek Systems 570 El Camino Real Suite 150 Redwood City CA 94063 (650)261-0411 Phone (650)261-0433 Fax [EMAIL PROTECTED] www.Xcreek.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPCOMP]: Fix truesize after decompression
From: Herbert Xu <[EMAIL PROTECTED]> Date: Tue, 11 Jul 2006 21:45:44 +1000 > [IPCOMP]: Fix truesize after decompression > > The truesize check has uncovered the fact that we forgot to update truesize > after pskb_expand_head. Unfortunately pskb_expand_head can't update it for > us because it's used in all sorts of different contexts, some of which would > not allow truesize to be updated by itself. > > So the solution for now is to simply update it in IPComp. > > This patch also changes skb_put to __skb_put since we've just expanded > tailroom by exactly that amount so we know it's there (but gcc does not). > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Applied. I think it is possible cover a certain class of these situations from within pskb_expand_head. For example, if skb->sk is NULL we can prove that updating skb->truesize is safe since no socket's buffer accounting can possible depend upon the truesize value of this skb. That way, we don't need to dilly-dally around spotting all the cases like these two decompression bits where we need to add the truesize adjustment by-hand. This got me thinking... we can probably handle the skb->sk != NULL case with some minor surgery. If we could give some more information to the skb->destructor callback, it could be used for truesize adjustments. The only remaining issue is context within which the destructor is called for truesize changes. There are some messy assumptions out that, such as sk_stream_rfree(), which work on the basis that the SKB is always freed up from the socket code with the socket locked. They use this assumption in order to safely be able to adjust sk->sk_forward_alloc without any explicit locking. So it gets a little messy, but I think it's doable in the end. - To unsubscribe from this list: send the 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
Michael Buesch wrote: Yes. We have a PROM that is readable without firmware. (And we actually do this and did it forever. So I don't know where your assumption comes from ;) ) It wasn't an assumption: I was stating something about the Intel cards. It is not possible to determine the MAC address for ipw2100/ipw2200 until the firmware is loaded. Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
What's new in wireless-dev?
I apologize for the delay. Between the 2.6.18 merge window and things heating up at the paying job, I've been a bit behind. Along w/ pulling some updates from Jiri and some random bug fixes, this includes the new d80211-based adm8211 driver from Michael Wu. I'm sure he would love for anyone equipped with that hardware to beat the crap out of his driver. :-) Happy hacking! John --- The following changes since commit 46226c37e4764103719005eb363b3bc53216caea: John W. Linville: Merge branch 'from-linus' are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git Alexander Tsvyashchenko: bcm43xx-d80211: AccessPoint mode related fixes Gertjan van Wingerde: d80211: Take lowlevel driver's channel change time into account during scanning. Ivo van Doorn: rt2x00: per-queue TX flow control Jiri Benc: d80211: update tx.skb after TX handler calls d80211: per-queue TX flow control d80211: handle full queue when sending fragments d80211: add first_fragment flag to ieee80211_tx_control bcm43xx-d80211: fix sending of fragments bcm43xx-d80211: per-queue TX flow control John W. Linville: Merge branch 'master' of git://git.kernel.org/.../jbenc/dscape d80211: use netif_tx_lock API bcm43xx-d80211: fixup UTS_RELEASE build break Michael Buesch: d80211: allow NULL for control in beacon_get bcm43xx-d80211: fix mac_suspend refcount Michael Wu: add adm8211 driver drivers/net/wireless/d80211/Kconfig|1 drivers/net/wireless/d80211/Makefile |1 drivers/net/wireless/d80211/adm8211/Kconfig| 24 drivers/net/wireless/d80211/adm8211/Makefile |1 drivers/net/wireless/d80211/adm8211/adm8211.c | 2202 drivers/net/wireless/d80211/adm8211/adm8211.h | 631 ++ drivers/net/wireless/d80211/bcm43xx/bcm43xx_dma.c |8 .../net/wireless/d80211/bcm43xx/bcm43xx_ethtool.c |1 drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c | 482 +++- drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.h | 24 drivers/net/wireless/d80211/bcm43xx/bcm43xx_pio.c |2 drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.c | 18 drivers/net/wireless/d80211/bcm43xx/bcm43xx_xmit.h |3 drivers/net/wireless/d80211/rt2x00/rt2400pci.c | 41 drivers/net/wireless/d80211/rt2x00/rt2500pci.c | 41 drivers/net/wireless/d80211/rt2x00/rt2500usb.c | 40 drivers/net/wireless/d80211/rt2x00/rt61pci.c | 41 drivers/net/wireless/d80211/rt2x00/rt73usb.c | 40 include/net/d80211.h | 32 net/d80211/ieee80211.c | 293 ++- net/d80211/ieee80211_i.h | 20 net/d80211/ieee80211_sta.c |4 net/d80211/wme.c |9 23 files changed, 3723 insertions(+), 236 deletions(-) create mode 100644 drivers/net/wireless/d80211/adm8211/Kconfig create mode 100644 drivers/net/wireless/d80211/adm8211/Makefile create mode 100644 drivers/net/wireless/d80211/adm8211/adm8211.c create mode 100644 drivers/net/wireless/d80211/adm8211/adm8211.h Full diff attached as wireless-dev.patch.bz2 -- John W. Linville [EMAIL PROTECTED] wireless-dev.patch.bz2 Description: BZip2 compressed data
Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y
On Tuesday 11 July 2006 13:53, you wrote: > Michael Buesch wrote: > > 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? > > Is bcm43xx able to get the MAC address before the firmware is loaded? Yes. We have a PROM that is readable without firmware. (And we actually do this and did it forever. So I don't know where your assumption comes from ;) ) > Last time I checked, if the MAC address is only discovered after the > interface is created (as would be the case with ipw loading firmware on > ifconfig up, I think), interface renaming does not work. -- 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-softmac: Further improvement in wireless statistics
On Tue, 2006-07-11 at 11:04 -0500, Larry Finger wrote: > This minor patch adjusts the parameters of the wireless statistics to improve > the display of > programs such as the "Wireless Network Information" applet of KDE. > > Signed-Off-By: Larry Finger <[EMAIL PROTECTED]> > > == > > > > diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c > b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c > index 8ffd760..1ea04da 100644 > --- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c > +++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c > @@ -49,7 +49,7 @@ #define BCM43xx_WX_VERSION 18 > #define MAX_WX_STRING 80 > /* FIXME: the next line is a guess as to what the maximum value of RX power > (in dBm) might be */ > -#define RX_POWER_MAX -10 > +#define RX_POWER_MAX -20 > > > static int bcm43xx_wx_get_name(struct net_device *net_dev, > @@ -231,8 +231,8 @@ static int bcm43xx_wx_get_rangeparams(st > > range->max_qual.qual = 100; > /* TODO: Real max RSSI */ > - range->max_qual.level = 0; > - range->max_qual.noise = 0; > + range->max_qual.level = -100; > + range->max_qual.noise = -100; > range->max_qual.updated = IW_QUAL_ALL_UPDATED; NAK... remember, range->max_qual.level must be _0_ if you're in dBm, since 0 is the actual maximum, and your level values are negative since they are in dBm. If KDE network applets display the wrong value when max_qual.level == 0, then they are wrong and need to be fixed. If you actually want RSSI, then you set max_qual.level to the upper limit of your RSSI, and the RSSI is assumed to go from 0 -> max_qual.level. AFAIK, the patch you had earlier is using dBm, _not_ RSSI, so max_qual.level = 0 is correct. Dan > range->avg_qual.qual = 50; > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: infiniband patch series
Andrew> Sure. Although I am a little surprised to be be receiving Andrew> them while Roland is in Andrew> taking-time-off-but-not-really-doing-so mode. Michael> Well, I don't know what's up either, but Roland acked Michael> patches explicitly so I figured that's what he wants, Michael> too. I'm in steal-10-minutes-to-read-email-every-now-and-then-mode, so I'd rather let someone else handle all the patch merging etc. I'll be back for real after Ottawa I guess... - R. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
e1000 TX unit hang (redux)
Hello All, I have an e1000 card periodically misbehaving with the message 'Detected Tx unit hang'. I've noticed this problem come up on netdev a couple of times and found the link to the bug tracking page-- http://sourceforge.net/tracker/index.php?func=detail&aid=1463045&group_id=42302&atid=447449 I've also seen the patch that I believe was placed in 2.6.16 and subsequently brought down to 2.4.2? that seems to address this problem by creating a tx_timeout_factor relative to the speed of the NIC. However, there is no mention of this workaround/fix on the bug at the link above and I haven't found any discussion of it here on netdev. Auke recommends turning off tso to see if that resolves the problem and this also seems to work, though I have as yet not been able to confirm this and would prefer a more performance friendly fix..if available ;) Would one of you pplease give an update on the status of the bug? If a cause was ever found and if the tx_timeout_factor was intended as a fix or temporary workaround? I feel like I must have missed something, because I never saw the tx_timeout_factor patch go through netdev at all.. Thanks again for your help, Shaw - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 6/6] per task delay accounting taskstats interface: fix clone skbs for each listener
Herbert Xu wrote: > On Tue, Jul 11, 2006 at 03:57:31AM -0700, Andrew Morton wrote: > > 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 we do a GFP_KERNEL allocation with this semaphore held, and the oom-killer tries to kill something to satisfy the allocation, and the killed task gets stuck on that semaphore, I wonder of the box locks up. Hmm...doesn't look very safe does it. There's no real need for us to skb_clone within the sem. Keeping a count of listeners and doing the clone outside should let us avoid this problem. I was trying to avoid doing the above because of the potential for listeners getting added continuously to the list (and having to repeat the allocation loop outside the down_write). But on second thoughts, we're under no obligation to send the data to all the listeners who add themselves in the short time between our taking a snapshot of the listener count and when the send is done (within the down_write). So it should be ok. >>> >>>We do GFP_KERNEL inside semaphores/mutexes in lots of places. So if this >>>can deadlock with the oom-killer we probably should fix that, preferably >>>by having GFP_KERNEL fail in that case. >> >>This lock is special, in that it's taken on the exit() path (I think). So >>it can block tasks which are trying to exit. > > > Sorry, missed the context. > > If there is a deadlock then it's not just this allocation that you > need worry about. There is also an allocation within genlmsg_uniast > that would be GFP_KERNEL. > Thats true. The GFP_KERNEL allocation potentially called in netlink_trim() as part of the genlmsg/netlink_unicast() is again a problem. So perhaps we should switch to using RCU for protecting the listener list. --Shailabh > Cheers, - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bcm43xx-softmac: Further improvement in wireless statistics
This minor patch adjusts the parameters of the wireless statistics to improve the display of programs such as the "Wireless Network Information" applet of KDE. Signed-Off-By: Larry Finger <[EMAIL PROTECTED]> == diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c index 8ffd760..1ea04da 100644 --- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c +++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c @@ -49,7 +49,7 @@ #define BCM43xx_WX_VERSION18 #define MAX_WX_STRING 80 /* FIXME: the next line is a guess as to what the maximum value of RX power (in dBm) might be */ -#define RX_POWER_MAX -10 +#define RX_POWER_MAX -20 static int bcm43xx_wx_get_name(struct net_device *net_dev, @@ -231,8 +231,8 @@ static int bcm43xx_wx_get_rangeparams(st range->max_qual.qual = 100; /* TODO: Real max RSSI */ - range->max_qual.level = 0; - range->max_qual.noise = 0; + range->max_qual.level = -100; + range->max_qual.noise = -100; range->max_qual.updated = IW_QUAL_ALL_UPDATED; range->avg_qual.qual = 50; - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: oops in current -git
try latest -mm, latest ACPI patch, or try CONFIG_ACPI_BATTERY=n -Len - To unsubscribe from this list: send the 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 Tue, 2006-07-11 at 13:27 +0200, Pavel Machek wrote: > Hi! > > > > > >> 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. > > Ouch, nice trick. But how do I actually pull it up? There's nothing > that looks like allowing that in /sys: > > [EMAIL PROTECTED]:/sys/devices/pci:00/:00:1e.0/:02:02.0# ls /sys/bus/pci/slots/:04:02.1 need to go there via bus/pci/slots - To unsubscribe from this list: send the 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 13:56 -0700, Joel Becker wrote: > 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. just load fakephp then do echo -n 0 > /sys/bus/pci/slots/:04:02.1/power this hotunplugs it (fake) then just do echo -n 1 > /sys/bus/pci/slots/:04:02.0/power (or any other device on the 04 bus) and the kernel finds the 04:02.1 device 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: d80211 sysfs
Hi, [snip] > EIP: 0060:[] Tainted: P VLI ^^^ Just out of curiosity, what's tainting your kernel? Hmm, no idea actually. This trace came from a user who submitted a bugreport. But I had a lot of traces for this bug, so I just selected one to indicate what the problem was. Ivo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
d80211 sysfs
Ivo Van Doorn wrote: [snip] > EIP: 0060:[] Tainted: P VLI ^^^ Just out of curiosity, what's tainting your kernel? -Alex I code, therefore I am __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: IPsec and netfilter needs INPUT rule for protocol 4?
Andy Gay wrote: Since 2.6.16 it's been necessary to add an ACCEPT rule for IPIP (protocol 4) in the INPUT chain, otherwise IPsec tunnel mode packets get dropped (if your INPUT policy is DROP). I was wondering if that's the intended behavior. No it isn't the desired behaviour. It is a know issue. - To unsubscribe from this list: send 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] rt2x00 makefile
Hi John, This patch fixes a copy&paste error by correcting the name for hardware button support in rt61pci. Please apply to wireless-dev. Thanks. Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]> --- diff -uprN wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig wireless-dev-end/drivers/net/wireless/d80211/rt2x00/Kconfig --- wireless-dev/drivers/net/wireless/d80211/rt2x00/Kconfig 2006-07-11 15:44:19.0 +0200 +++ wireless-dev-end/drivers/net/wireless/d80211/rt2x00/Kconfig 2006-07-11 16:01:59.0 +0200 @@ -61,7 +61,7 @@ config RT61PCI When compiled as a module, this driver will be called "rt61pci.ko". -config RT2500PCI_BUTTON +config RT61PCI_BUTTON bool "Ralink rt61 hardware button support" depends on RT61PCI && X86 ---help--- - To unsubscribe from this list: send the 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()
Jay Vosburgh wrote: Or Gerlitz <[EMAIL PROTECTED]> wrote: What network device drivers are there that don't permit ever changing the device MAC address? I am thinking about what would it take to support active-backup/bonding for IP over Infiniband (see Documentation/infiniband/ipoib.txt). The IPoIB MAC address (defined in RFC 4391 section 9.1.1) is 20 bytes long and made of the IB port GID (16 bytes), the IB QPN (Queue-Pair number) used by this device (3 bytes) plus 1 reserved byte. The IPoIB MAC address is made of two unique hardware resource identifiers: the GID which identifies the HCA IP port and the number of the QP opened by the driver on this HCA/port. Currently the driver does not support changing this MAC and i am also looking into whether its possible and what does it would take to have some abstraction layer implemented in the driver that would allow for external setting of the MAC address; that is an intermediate data structure that would translate from the MAC address exposed in the device and neigh structures to the actual IB hardware address. However, again, if you would ACK an intension to patch the bonding driver such that it will not force usage of dev->set_mac_address for active-backup/bonding i would prefer to first produce and test a patch which does not change the IPoIB driver (drivers/infiniband/ulp/ipoib) Or. Below is the addr info on a node named dill with two ipoib devices ib0 (192.168.10.118) and ib1 (not up) and the neigh info for an ipoib endpoint whose address is 192.168.10.57 so the GID of the port associated with ib0 is fe:80:00:00:00:00:00:00:00:08:f1:04:03:96:51:dd the GID of the port associated with ib1 is fe:80:00:00:00:00:00:00:00:08:f1:04:03:96:51:de the qpn used by ib0 is 00:04:04 (0x404) the qpn used by ib1 is 00:04:05 (0x405) the remote GID in this example is fe:80:00:00:00:00:00:00:00:08:f1:04:03:97:07:99 and the remote qpn is 0x404 dill # ip addr show ib0 6: ib0: mtu 2044 qdisc pfifo_fast qlen 128 link/[32] 00:00:04:04:fe:80:00:00:00:00:00:00:00:08:f1:04:03:96:51:dd brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff inet 192.168.10.118/24 brd 192.168.10.255 scope global ib0 inet6 fe80::208:f104:396:51dd/64 scope link valid_lft forever preferred_lft forever dill# ip addr show ib1 7: ib1: mtu 2044 qdisc noop qlen 128 link/[32] 00:00:04:05:fe:80:00:00:00:00:00:00:00:08:f1:04:03:96:51:de brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff dill# ip neigh show 192.168.10.57 192.168.10.57 dev ib0 lladdr 00:00:04:04:fe:80:00:00:00:00:00:00:00:08:f1:04:03:97:07:99 nud reachable - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
IPsec and netfilter needs INPUT rule for protocol 4?
Since 2.6.16 it's been necessary to add an ACCEPT rule for IPIP (protocol 4) in the INPUT chain, otherwise IPsec tunnel mode packets get dropped (if your INPUT policy is DROP). I was wondering if that's the intended behavior. I did google around for this, I found a few reports of the same thing but no explanation. For example, Patrick discusses this in - http://lists.netfilter.org/pipermail/netfilter-devel/2006-February/023420.html but that thread seems to end inconclusively. - To unsubscribe from this list: send the 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()
Jay Vosburgh wrote: 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). Thanks for clarifying and sharpening this point; however thinking about set_mac_address for active-backup mode i could not convince myself that there is a **need** for that. However, at high level it does make some (much) sense that the bond net device exposes a mac which is not changed when the active slave changes. 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 see, but it will have the affect of MAC address change announcement. 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. I will be glad to know if you have more concrete ideas what would be the possible problems with such impl. Or. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is RDMA (was: RDMA will be reverted)
On Tue, 2006-07-11 at 18:17 +1000, Herbert Xu wrote: > On Fri, Jul 07, 2006 at 01:25:44PM -0500, Steve Wise wrote: > > > > Some IP networking is involved for this. IP addresses and port numbers > > are used by the RDMA Connection Manager. The motivation for this was > > two-fold, I think: > > > > 1) to simplify the connection setup model. The IB CM model was very > > complex. > > > > 2) to allow ULPs to be transport independent. Thus a single code base > > for NFSoRDMA, for example, can run over Infiniband and RDMA/TCP > > transports without code changes or knowing about transport-specific > > addressing. > > > > The routing table is also consulted to determine which rdma device > > should be used for connection setup. Each rdma device also installs a > > netdev device for native stack traffic. The RDMA CM maintains an > > association between the netdev device and the rdma device. > > > > And the Infiniband subsystem uses ARP over IPoIB to map IP addresses to > > GID/QPN info. This is done by calling arp_send() directly, and snooping > > all ARP packets to "discover" when the arp entry is completed. > > This sounds interesting. > > Since this is going to be IB-neutral, what about moving high-level logic > like this is moved out of drivers/infiniband and into net? > > That way the rest of the networking community can add input into how > things are done. > The notifier patch I posted sort of does this already by eliminating the need to snoop arp replies. It will notify interested subsystems of neighbour changes (EG when an ARP reply is processed and the neighbour struct updated with the correct hw mac addr). And I _think_ neigh_event_send() could be used instead of arp_send(). Steve. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with xfrm (IPSec) and multicast
On Wed, Jun 14, 2006 at 01:09:59PM +, Roar Bj?rgum Rotvik wrote: > > So I cannot make encrypted multicast traffic to flow both ways at the same > time, and has no clue as to why the first packets after changing direction > is dropped somewhere. Sounds like conntrack. Check /proc/net/ip_conntrack when this happens. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc1-mm1 - VPN chewing CPU like crazy..
On Mon, 10 Jul 2006 23:19:39 PDT, Andrew Morton said: > > Any suggestions/hints (besides rebuilding the implicated .ko with debugging > > symbols so oprofile can be more granular - that's already on the to-do > > list)? > > > > I'd suggest you whack sysrq-T 5-10 times when it happens, capture a few > stack traces. "D-Oh!" -- Homer Simpson. I knew that. :) pgpyZkkRQbKJz.pgp Description: PGP signature
Re: [BPQ] lockdep: fix false positive
* Ralf Baechle <[EMAIL PROTECTED]> wrote: > 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]> thanks! Acked-by: Ingo Molnar <[EMAIL PROTECTED]> 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: ipsec tunnel asymmetrical mtu
On Tue, Jul 11, 2006 at 12:32:45PM +0200, Marco Berizzi wrote: > Running this on mimosa 'mitigates' the problem: > > ip addr add 172.29.128.1/28 dev eth2 > > Connections are pretty slow but they aren't > reseted anymore. Hmm, I thought 172.29.128.1 was already a local address? What does ip addr show? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] do not allow IPW_2100=Y or IPW_2200=Y
Michael Buesch wrote: 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? Is bcm43xx able to get the MAC address before the firmware is loaded? Last time I checked, if the MAC address is only discovered after the interface is created (as would be the case with ipw loading firmware on ifconfig up, I think), interface renaming does not work. Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[IPCOMP]: Fix truesize after decompression
On Thu, Jul 06, 2006 at 12:53:45PM +, Beschorner Daniel wrote: > Does it harm? > > SKB BUG: Invalid truesize (380) len=1383, sizeof(sk_buff)=156 > SKB BUG: Invalid truesize (316) len=1383, sizeof(sk_buff)=156 > SKB BUG: Invalid truesize (348) len=1383, sizeof(sk_buff)=156 > SKB BUG: Invalid truesize (316) len=1383, sizeof(sk_buff)=156 > SKB BUG: Invalid truesize (380) len=1383, sizeof(sk_buff)=156 > > I found it in the log of a 2.6.17 box using IPSEC tunnels. It's not fatal, but it does stuff up socket accounting. Unfortunately getting totally accurate truesizes is not easy due to the large numbers of pskb_expand_head calls scattered around the stack. [IPCOMP]: Fix truesize after decompression The truesize check has uncovered the fact that we forgot to update truesize after pskb_expand_head. Unfortunately pskb_expand_head can't update it for us because it's used in all sorts of different contexts, some of which would not allow truesize to be updated by itself. So the solution for now is to simply update it in IPComp. This patch also changes skb_put to __skb_put since we've just expanded tailroom by exactly that amount so we know it's there (but gcc does not). Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- diff --git a/net/ipv4/ipcomp.c b/net/ipv4/ipcomp.c index 8e03748..8a8b5cf 100644 --- a/net/ipv4/ipcomp.c +++ b/net/ipv4/ipcomp.c @@ -70,7 +70,8 @@ static int ipcomp_decompress(struct xfrm if (err) goto out; - skb_put(skb, dlen - plen); + skb->truesize += dlen - plen; + __skb_put(skb, dlen - plen); memcpy(skb->data, scratch, dlen); out: put_cpu(); diff --git a/net/ipv6/ipcomp6.c b/net/ipv6/ipcomp6.c index b285b03..7e4d1c1 100644 --- a/net/ipv6/ipcomp6.c +++ b/net/ipv6/ipcomp6.c @@ -109,7 +109,8 @@ static int ipcomp6_input(struct xfrm_sta goto out_put_cpu; } - skb_put(skb, dlen - plen); + skb->truesize += dlen - plen; + __skb_put(skb, dlen - plen); memcpy(skb->data, scratch, dlen); err = ipch->nexthdr; - To unsubscribe from this list: send the 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
Hi! > > > >> 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. Ouch, nice trick. But how do I actually pull it up? There's nothing that looks like allowing that in /sys: [EMAIL PROTECTED]:/sys/devices/pci:00/:00:1e.0/:02:02.0# ls broken_parity_status config irq power/ subsystem@ uevent bus@ device local_cpus resource subsystem_device vendor class enable modaliasresource0 subsystem_vendor [EMAIL PROTECTED]:/sys/devices/pci:00/:00:1e.0/:02:02.0# I tried going to bus/drivers/ and unbind/rebind ipw2200 driver; that does not work. I tried echo 0 > enable; echo 1 > enable, but no trick, either. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipsec tunnel asymmetrical mtu
On Tue, Jul 11, 2006 at 11:31:33AM +0200, Marco Berizzi wrote: > > Me again. After a while here is: > > [EMAIL PROTECTED]:/tmp# ping 10.49.59.23 > PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data. > > --- 10.49.59.23 ping statistics --- > 4 packets transmitted, 0 received, 100% packet loss, time 3010ms Please check using ip -s x p to make sure that the packet is hitting the right policy. Unfortunately we don't update the byte/packet counters so you'll have to look at the `use' time stamp. If it's passing through IPsec, then you should trace through your iptables rules using the LOG target to see if it's hitting them. We need to know if it's being dropped before, in, or after netfilter. Please also do ip r g 10.49.59.23 to make sure that it says something sane. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 6/6] per task delay accounting taskstats interface: fix clone skbs for each listener
On Tue, Jul 11, 2006 at 03:57:31AM -0700, Andrew Morton wrote: > > > >> 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 we do a GFP_KERNEL allocation with this semaphore held, and the > > > oom-killer tries to kill something to satisfy the allocation, and the > > > killed task gets stuck on that semaphore, I wonder of the box locks up. > > > > We do GFP_KERNEL inside semaphores/mutexes in lots of places. So if this > > can deadlock with the oom-killer we probably should fix that, preferably > > by having GFP_KERNEL fail in that case. > > This lock is special, in that it's taken on the exit() path (I think). So > it can block tasks which are trying to exit. Sorry, missed the context. If there is a deadlock then it's not just this allocation that you need worry about. There is also an allocation within genlmsg_uniast that would be GFP_KERNEL. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 6/6] per task delay accounting taskstats interface: fix clone skbs for each listener
On Tue, 11 Jul 2006 20:28:50 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote: > Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Tue, 11 Jul 2006 00:36:39 -0400 > > Shailabh Nagar <[EMAIL PROTECTED]> wrote: > > > >> 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 we do a GFP_KERNEL allocation with this semaphore held, and the > > oom-killer tries to kill something to satisfy the allocation, and the > > killed task gets stuck on that semaphore, I wonder of the box locks up. > > We do GFP_KERNEL inside semaphores/mutexes in lots of places. So if this > can deadlock with the oom-killer we probably should fix that, preferably > by having GFP_KERNEL fail in that case. This lock is special, in that it's taken on the exit() path (I think). So it can block tasks which are trying to exit. But yes. Reliable, deadlock-free oom-killing is, err, a matter of ongoing research. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipsec tunnel asymmetrical mtu
On Tue, Jul 11, 2006 at 11:22:18AM +0200, Marco Berizzi wrote: > > I'm able to connect to a sap server connected to the milano network > from a sapgui client connected to the venezia network. No problem. > If packet loss is a problem it should be also a problem with this tunnel. > Am I wrong? It depends. A mild packet loss problem can become a big one when it is exacerbated by fragmentation, e.g., a 20% rate can become 40%. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipsec tunnel asymmetrical mtu
Running this on mimosa 'mitigates' the problem: ip addr add 172.29.128.1/28 dev eth2 Connections are pretty slow but they aren't reseted anymore. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 6/6] per task delay accounting taskstats interface: fix clone skbs for each listener
Andrew Morton <[EMAIL PROTECTED]> wrote: > On Tue, 11 Jul 2006 00:36:39 -0400 > Shailabh Nagar <[EMAIL PROTECTED]> wrote: > >> 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 we do a GFP_KERNEL allocation with this semaphore held, and the > oom-killer tries to kill something to satisfy the allocation, and the > killed task gets stuck on that semaphore, I wonder of the box locks up. We do GFP_KERNEL inside semaphores/mutexes in lots of places. So if this can deadlock with the oom-killer we probably should fix that, preferably by having GFP_KERNEL fail in that case. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cancel_rearming_delayed_work infinite loop fix
Michael Buesch <[EMAIL PROTECTED]> wrote: > 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. Why are you calling it on a work that was never scheduled? Sounds like a bug to me. > 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)); This is broken. If the work just starts running before your test_bit you'd exit without cancelling it properly. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] d80211: make sleeping in hw->config possible #2
On Tuesday 11 July 2006 11:31, you wrote: > On Tue, 11 Jul 2006 11:11:27 +0200 > Michael Buesch <[EMAIL PROTECTED]> wrote: > > > But I think the following is also broken in the old code: > > A wq is not pending anymore, but just executing (before it reschedules > > itself). > > I think that would also loop forever. I don't think that's what we want. > > Because we can't really keep track of _this_. > > The present implementation assumes that the handler will re-arm itself. > > I agree that extending that makes sense. But beware that it's easy to > leave subtle holes in this logic. Needs careful thought to get right. Yeah, as I said. There is still a race. Should I redo the patch to fix it? -- 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 6/6] per task delay accounting taskstats interface: fix clone skbs for each listener
On Tue, 11 Jul 2006 00:36:39 -0400 Shailabh Nagar <[EMAIL PROTECTED]> wrote: > 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 we do a GFP_KERNEL allocation with this semaphore held, and the oom-killer tries to kill something to satisfy the allocation, and the killed task gets stuck on that semaphore, I wonder of the box locks up. Probably it'll work out OK if the semaphore is taken after that task has had some resources torn down. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipsec tunnel asymmetrical mtu
Another tricky behaviour: [EMAIL PROTECTED]:/tmp# telnet 10.49.59.23 3218 Trying 10.49.59.23... Connected to 10.49.59.23. Escape character is '^]'. Connection closed by foreign host. [EMAIL PROTECTED]:/tmp# tcpdump -p -n -v ip host 10.49.59.23 > HERBERT-20060711 & [1] 4797 [EMAIL PROTECTED]:/tmp# tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes [EMAIL PROTECTED]:/tmp# telnet 10.49.59.23 3218 Trying 10.49.59.23... Connected to 10.49.59.23. Escape character is '^]'. Connection closed by foreign host. [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# cat HERBERT-20060711 [EMAIL PROTECTED]:/tmp# fg tcpdump -p -n -v ip host 10.49.59.23 >HERBERT-20060711 4 packets captured 4 packets received by filter 0 packets dropped by kernel [EMAIL PROTECTED]:/tmp# cat HERBERT-20060711 11:38:27.795246 IP (tos 0x0, ttl 53, id 5339, offset 0, flags [none], length: 44) 10.49.59.23.3218 > 172.29.128.1.4743: S [tcp sum ok] 2786256910:2786256910(0) ack 1185072116 win 65535 11:38:29.052501 IP (tos 0x0, ttl 53, id 5348, offset 0, flags [none], length: 40) 10.49.59.23.3218 > 172.29.128.1.4743: . [tcp sum ok] ack 3 win 65535 11:38:29.303111 IP (tos 0x0, ttl 53, id 5349, offset 0, flags [none], length: 40) 10.49.59.23.3218 > 172.29.128.1.4743: F [tcp sum ok] 1:1(0) ack 5 win 65535 11:38:29.369664 IP (tos 0x0, ttl 53, id 5350, offset 0, flags [none], length: 40) 10.49.59.23.3218 > 172.29.128.1.4743: . [tcp sum ok] ack 6 win 65535 [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# [EMAIL PROTECTED]:/tmp# tcpdump -p -n -v ip host 10.16.24.117 > HERBERT-20060711 & [1] 4801 [EMAIL PROTECTED]:/tmp# tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes [EMAIL PROTECTED]:/tmp# telnet 10.16.24.117 3219 Trying 10.16.24.117... [***while waiting, I run the same command from my box (172.16.1.247)***] [EMAIL PROTECTED]:/tmp# fg tcpdump -p -n -v ip host 10.16.24.117 >HERBERT-20060711 9 packets captured 9 packets received by filter 0 packets dropped by kernel [EMAIL PROTECTED]:/tmp# cat HERBERT-20060711 11:39:10.792018 IP (tos 0x10, ttl 63, id 51971, offset 0, flags [DF], length: 60) 172.16.1.247.1953 > 10.16.24.117.3219: S [tcp sum ok] 781753718:781753718(0) win 5840 0,nop,wscale 3> 11:39:10.825135 IP (tos 0x0, ttl 52, id 14748, offset 0, flags [none], length: 44) 10.16.24.117.3219 > 172.29.128.1.1953: S [tcp sum ok] 1452857781:1452857781(0) ack 781753719 win 17520 11:39:10.852659 IP (tos 0x10, ttl 63, id 51972, offset 0, flags [DF], length: 40) 172.16.1.247.1953 > 10.16.24.117.3219: . [tcp sum ok] ack 1452857782 win 5840 11:39:12.094752 IP (tos 0x10, ttl 63, id 51973, offset 0, flags [DF], length: 42) 172.16.1.247.1953 > 10.16.24.117.3219: P [tcp sum ok] 0:2(2) ack 1 win 5840 11:39:12.270403 IP (tos 0x0, ttl 52, id 14764, offset 0, flags [none], length: 40) 10.16.24.117.3219 > 172.29.128.1.1953: . [tcp sum ok] ack 3 win 17520 11:39:13.664803 IP (tos 0x10, ttl 63, id 51974, offset 0, flags [DF], length: 42) 172.16.1.247.1953 > 10.16.24.117.3219: P [tcp sum ok] 2:4(2) ack 1 win 5840 11:39:13.733259 IP (tos 0x0, ttl 52, id 14771, offset 0, flags [none], length: 40) 10.16.24.117.3219 > 172.29.128.1.1953: F [tcp sum ok] 1:1(0) ack 5 win 17520 11:39:13.774786 IP (tos 0x10, ttl 63, id 51975, offset 0, flags [DF], length: 40) 172.16.1.247.1953 > 10.16.24.117.3219: F [tcp sum ok] 4:4(0) ack 2 win 5840 11:39:13.809809 IP (tos 0x0, ttl 52, id 14772, offset 0, flags [none], length: 40) 10.16.24.117.3219 > 172.29.128.1.1953: . [tcp sum ok] ack 6 win 17520 [EMAIL PROTECTED]:/tmp# tcpdump -p -n -v ip host 10.16.24.117 > HERBERT-20060711 & [1] 4804 [EMAIL PROTECTED]:/tmp# tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes [EMAIL PROTECTED]:/tmp# telnet 10.16.24.117 3219 Trying 10.16.24.117... [EMAIL PROTECTED]:/tmp# ping 10.16.24.117 PING 10.16.24.117 (10.16.24.117) 56(84) bytes of data. 64 bytes from 10.16.24.117: icmp_seq=1 ttl=247 time=32.6 ms 64 bytes from 10.16.24.117: icmp_seq=2 ttl=247 time=30.0 ms --- 10.16.24.117 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 30.087/31.382/32.677/1.295 ms [EMAIL PROTECTED]:/tmp# fg tcpdump -p -n -v ip host 10.16.24.117 >HERBERT-20060711 2 packets captured 2 packets received by filter 0 packets dropped by kernel [EMAIL PROTECTED]:/tmp# cat HERBERT-20060711 11:40:29.523461 IP (tos 0x0, ttl 247, id 15804, offset 0, flags [none], length: 84) 10.16.24.117 > 172.29.128.1: icmp 64: echo reply seq 1 11:40:30.521196 IP (tos 0x0, ttl 247, id 15810, offset 0, flags [none], leng
Re: ipsec tunnel asymmetrical mtu
Marco Berizzi wrote: Herbert Xu wrote: On Mon, May 08, 2006 at 08:28:32AM +, Marco Berizzi wrote: > > [EMAIL PROTECTED]:~# ping 10.49.59.23 > PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data. > 64 bytes from 10.49.59.23: icmp_seq=1 ttl=247 time=91.9 ms > 64 bytes from 10.49.59.23: icmp_seq=2 ttl=247 time=49.3 ms > 64 bytes from 10.49.59.23: icmp_seq=3 ttl=247 time=106 ms > 64 bytes from 10.49.59.23: icmp_seq=4 ttl=247 time=74.3 ms > > --- 10.49.59.23 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 2998ms > rtt min/avg/max/mdev = 49.316/80.460/106.257/21.241 ms > [EMAIL PROTECTED]:~# cd /tmp/ > [EMAIL PROTECTED]:/tmp# tcpdump -v -p -n ip host 10.49.59.23 > > /tmp/NULL-10.49.59.23 & > [1] 18981 > [EMAIL PROTECTED]:/tmp# tcpdump: listening on eth0, link-type EN10MB (Ethernet), > capture size 96 bytes > > [EMAIL PROTECTED]:/tmp# ping 10.49.59.23 > PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data. > > --- 10.49.59.23 ping statistics --- > 8 packets transmitted, 0 received, 100% packet loss, time 6999ms > > [EMAIL PROTECTED]:/tmp# fg > tcpdump -v -p -n ip host 10.49.59.23 >/tmp/NULL-10.49.59.23 > 101 packets captured > 101 packets received by filter > 0 packets dropped by kernel Yes this is really weird. The only thing I can think of is that it somehow managed to put some bogus entry into the conntrack table. What happens if you do grep 10.49.59.23 /proc/net/ip_conntrack before and after the tcpdump? I'm not able to reproduce it :-[[[ Today mimosa is running 2.6.17.4, mon May 8 mimosa was running 2.6.16.12 If you want I could downgrade to 2.6.16.12 and see if I'm able to reproduce it. Sorry. Me again. After a while here is: [EMAIL PROTECTED]:/tmp# ping 10.49.59.23 PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data. --- 10.49.59.23 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3010ms [EMAIL PROTECTED]:/tmp# grep 10.49.59.23 /proc/net/ip_conntrack tcp 6 431889 ESTABLISHED src=172.16.0.167 dst=10.49.59.23 sport=1142 dport=3218 packets=27 bytes=3559 src=10.49.59.23 dst=172.29.128.1 sport=3218 dport=1142 packets=37 bytes=38629 [ASSURED] mark=0 use=1 [EMAIL PROTECTED]:/tmp# ping 10.49.59.23 PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data. --- 10.49.59.23 ping statistics --- 13 packets transmitted, 0 received, 100% packet loss, time 11999ms [EMAIL PROTECTED]:/tmp# grep 10.49.59.23 /proc/net/ip_conntrack tcp 6 431868 ESTABLISHED src=172.16.0.167 dst=10.49.59.23 sport=1142 dport=3218 packets=27 bytes=3559 src=10.49.59.23 dst=172.29.128.1 sport=3218 dport=1142 packets=37 bytes=38629 [ASSURED] mark=0 use=1 [EMAIL PROTECTED]:/tmp# tcpdump -v -p -n ip host 10.49.59.23 > HERBERT-20060711 & [1] 4747 [EMAIL PROTECTED]:/tmp# tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes [EMAIL PROTECTED]:/tmp# grep 10.49.59.23 /proc/net/ip_conntrack tcp 6 431853 ESTABLISHED src=172.16.0.167 dst=10.49.59.23 sport=1142 dport=3218 packets=27 bytes=3559 src=10.49.59.23 dst=172.29.128.1 sport=3218 dport=1142 packets=37 bytes=38629 [ASSURED] mark=0 use=1 [EMAIL PROTECTED]:/tmp# ping 10.49.59.23 PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data. --- 10.49.59.23 ping statistics --- 9 packets transmitted, 0 received, 100% packet loss, time 8026ms [EMAIL PROTECTED]:/tmp# grep 10.49.59.23 /proc/net/ip_conntrack tcp 6 431837 ESTABLISHED src=172.16.0.167 dst=10.49.59.23 sport=1142 dport=3218 packets=27 bytes=3559 src=10.49.59.23 dst=172.29.128.1 sport=3218 dport=1142 packets=37 bytes=38629 [ASSURED] mark=0 use=1 [EMAIL PROTECTED]:/tmp# fg tcpdump -v -p -n ip host 10.49.59.23 >HERBERT-20060711 9 packets captured 9 packets received by filter 0 packets dropped by kernel [EMAIL PROTECTED]:/tmp# cat HERBERT-20060711 11:23:48.981383 IP (tos 0x0, ttl 248, id 27422, offset 0, flags [none], length: 84) 10.49.59.23 > 172.29.128.1: icmp 64: echo reply seq 1 11:23:49.983515 IP (tos 0x0, ttl 248, id 27426, offset 0, flags [none], length: 84) 10.49.59.23 > 172.29.128.1: icmp 64: echo reply seq 2 11:23:50.983110 IP (tos 0x0, ttl 248, id 27521, offset 0, flags [none], length: 84) 10.49.59.23 > 172.29.128.1: icmp 64: echo reply seq 3 11:23:51.994398 IP (tos 0x0, ttl 248, id 27523, offset 0, flags [none], length: 84) 10.49.59.23 > 172.29.128.1: icmp 64: echo reply seq 4 11:23:52.999726 IP (tos 0x0, ttl 248, id 27525, offset 0, flags [none], length: 84) 10.49.59.23 > 172.29.128.1: icmp 64: echo reply seq 5 11:23:53.999583 IP (tos 0x0, ttl 248, id 27529, offset 0, flags [none], length: 84) 10.49.59.23 > 172.29.128.1: icmp 64: echo reply seq 6 11:23:54.999584 IP (tos 0x0, ttl 248, id 27531, offset 0, flags [none], length: 84) 10.49.59.23 > 172.29.128.1: icmp 64: echo reply seq 7 11:23:56.013499 IP (tos 0x0, ttl 248, id 27554, offset 0, flags [none], length: 84)
Re: [PATCH] d80211: make sleeping in hw->config possible #2
On Tue, 11 Jul 2006 11:11:27 +0200 Michael Buesch <[EMAIL PROTECTED]> wrote: > But I think the following is also broken in the old code: > A wq is not pending anymore, but just executing (before it reschedules > itself). > I think that would also loop forever. I don't think that's what we want. > Because we can't really keep track of _this_. The present implementation assumes that the handler will re-arm itself. I agree that extending that makes sense. But beware that it's easy to leave subtle holes in this logic. Needs careful thought to get right. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipsec tunnel asymmetrical mtu
Herbert Xu wrote: We can say these things for certain: 1) The path between mimosa and pleiadi has a packet loss problem. A small burst of 10 or so fragments is enough to cause at least half of them to be lost. This problem may be specific to IPsec traffic (ISPs often discriminate against traffic with protocols other than TCP/UDP). This is my company network schema: sap server---milano-network==mimosa-+-internet-+-pleiadi==venezia-network--sap client I'm able to connect to a sap server connected to the milano network from a sapgui client connected to the venezia network. No problem. If packet loss is a problem it should be also a problem with this tunnel. Am I wrong? - To unsubscribe from this list: send the 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 Tuesday 11 July 2006 06:25, you wrote: > 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. No, I don't think so. Let's say we have the following scenario: A wq reschedules itself x times after it was scheduled once from outside. After these x times, it does not reschedule anymore. That's what happens in d80211. And I don't see a solution to sync this, other than modifying the function, because we may call it after the x reschedule times. Or do you think we should really do a statemachine to workaround it? I am not the first one to hit this (I call it) bug. It is _very_ confusing to see this sync function blocking forever. I saw several people complaining about it. Also on #kernelnewbies. > 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. Actually, I think there's still a little race. I will send a more complex fix for this, if you agree to change the function. If you say "no, we don't fix this. Insert a statemachine or something in your code instead", I can use the time for better things. :) But I think the following is also broken in the old code: A wq is not pending anymore, but just executing (before it reschedules itself). I think that would also loop forever. I don't think that's what we want. Because we can't really keep track of _this_. -- 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: ipsec tunnel asymmetrical mtu
Herbert Xu wrote: On Mon, May 08, 2006 at 08:28:32AM +, Marco Berizzi wrote: > > [EMAIL PROTECTED]:~# ping 10.49.59.23 > PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data. > 64 bytes from 10.49.59.23: icmp_seq=1 ttl=247 time=91.9 ms > 64 bytes from 10.49.59.23: icmp_seq=2 ttl=247 time=49.3 ms > 64 bytes from 10.49.59.23: icmp_seq=3 ttl=247 time=106 ms > 64 bytes from 10.49.59.23: icmp_seq=4 ttl=247 time=74.3 ms > > --- 10.49.59.23 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 2998ms > rtt min/avg/max/mdev = 49.316/80.460/106.257/21.241 ms > [EMAIL PROTECTED]:~# cd /tmp/ > [EMAIL PROTECTED]:/tmp# tcpdump -v -p -n ip host 10.49.59.23 > > /tmp/NULL-10.49.59.23 & > [1] 18981 > [EMAIL PROTECTED]:/tmp# tcpdump: listening on eth0, link-type EN10MB (Ethernet), > capture size 96 bytes > > [EMAIL PROTECTED]:/tmp# ping 10.49.59.23 > PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data. > > --- 10.49.59.23 ping statistics --- > 8 packets transmitted, 0 received, 100% packet loss, time 6999ms > > [EMAIL PROTECTED]:/tmp# fg > tcpdump -v -p -n ip host 10.49.59.23 >/tmp/NULL-10.49.59.23 > 101 packets captured > 101 packets received by filter > 0 packets dropped by kernel Yes this is really weird. The only thing I can think of is that it somehow managed to put some bogus entry into the conntrack table. What happens if you do grep 10.49.59.23 /proc/net/ip_conntrack before and after the tcpdump? I'm not able to reproduce it :-[[[ Today mimosa is running 2.6.17.4, mon May 8 mimosa was running 2.6.16.12 If you want I could downgrade to 2.6.16.12 and see if I'm able to reproduce it. Sorry. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: d80211 sysfs
Hi, > 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? Ok I think I am closer to the source of the problem. Some users just verified that the problem does not excist in the 2.6.17 kernel. So it must have been an issue already resolved in the kernel. I'll ask my testers to upgrade their kernels, or perhaps I am going to ask them to use the wireless-dev or dscape git tree to test rt2x00. Thanks. Ivo - To unsubscribe from this list: send the 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
> 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. ok these patches ought to fix this for real (sorry I don't have this hardware so I cannot actually do the testing) I hope you have time to test these.. Greetings, Arjan van de Ven From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: lockdep: core, add enable/disable_irq_irqsave/irqrestore() APIs Introduce the disable_irq_nosync_lockdep_irqsave() and enable_irq_lockdep_irqrestore() APIs. These are needed for NE2000; basically NE2000 calls disable_irq and enable_irq as locking against the IRQ handler, but both in cases where interrupts are on and off. This means that lockdep needs to track the old state of the virtual irq flags on disable_irq, and restore these at enable_irq time. Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Index: linux-2.6.18-rc1/include/linux/interrupt.h === --- linux-2.6.18-rc1.orig/include/linux/interrupt.h +++ linux-2.6.18-rc1/include/linux/interrupt.h @@ -123,6 +123,14 @@ static inline void disable_irq_nosync_lo #endif } +static inline void disable_irq_nosync_lockdep_irqsave(unsigned int irq, unsigned long *flags) +{ + disable_irq_nosync(irq); +#ifdef CONFIG_LOCKDEP + local_irq_save(*flags); +#endif +} + static inline void disable_irq_lockdep(unsigned int irq) { disable_irq(irq); @@ -139,6 +147,14 @@ static inline void enable_irq_lockdep(un enable_irq(irq); } +static inline void enable_irq_lockdep_irqrestore(unsigned int irq, unsigned long *flags) +{ +#ifdef CONFIG_LOCKDEP + local_irq_restore(*flags); +#endif + enable_irq(irq); +} + /* IRQ wakeup (PM) control: */ extern int set_irq_wake(unsigned int irq, unsigned int on); From: Arjan van de Ven <[EMAIL PROTECTED]> Subject: lockdep: annotate the ne2000 driver with the new disable_irq API addition The ne2000 driver's xmit function gets called from netpoll with the _xmit_lock spinlock held as _irqsave. This means the xmit function needs to preserve this irq-off state throughout to avoid deadlock. It does, but we need to also tell lockdep that the function indeed does this by using the proper disable_irq annotation. Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Index: linux-2.6.18-rc1/drivers/net/8390.c === --- linux-2.6.18-rc1.orig/drivers/net/8390.c +++ linux-2.6.18-rc1/drivers/net/8390.c @@ -299,7 +299,7 @@ static int ei_start_xmit(struct sk_buff * Slow phase with lock held. */ - disable_irq_nosync_lockdep(dev->irq); + disable_irq_nosync_lockdep_irqsave(dev->irq, &flags); 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_lockdep(dev->irq); + enable_irq_lockdep_irqrestore(dev->irq, &flags); 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_lockdep(dev->irq); + enable_irq_lockdep_irqrestore(dev->irq, &flags); dev_kfree_skb (skb); ei_local->stat.tx_bytes += send_length; - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipsec tunnel asymmetrical mtu
Herbert Xu wrote: Hi Marco: Hi Herbert, I'm very happy hearing you. On Mon, Apr 24, 2006 at 09:23:00AM +, Marco Berizzi wrote: > > What should I do? Mangling MSS with iptables --set-mss ? > Altering MSS to 1440 did the trick. See: > http://marc.theaimsgroup.com/?l=linux-netdev&m=114373067423528&w=2 Yes that's enough, although proper PMTU would be better. > and here is snmp when the sapgui client has told me that the > connections has been reset: > > [EMAIL PROTECTED]:/var/log# cat SNMP-CONN-RESET > Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams > InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes > ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates > Ip: 1 64 79257 0 31 48139 0 0 38799 56650 2 0 2 182 90 2 90 0 124 OK, the number of reassemblies equals the number of FragOKs. So it does not look like there is a problem within mimosa, i.e., Linux. I've looked at your packet dumps again and in fact there is not qualitative difference between WITHTCPDUMP and WITHOUTTCPDUMP. What is different is that the latter seems to have experienced a higher packet loss rate at an early stage and therefore the sender has already backed off to a very long retry period. The fact that tcpdump makes a difference could simply be that it changes the timing of the fragment tramissions on mimosa which has an impact on the loss rate between mimosa and pleiadi. We can say these things for certain: 1) The path between mimosa and pleiadi has a packet loss problem. A small burst of 10 or so fragments is enough to cause at least half of them to be lost. This problem may be specific to IPsec traffic (ISPs often discriminate against traffic with protocols other than TCP/UDP). 2) Fragmentation exacerbates the packet loss problem because it increases the number of packets and a packet is lost if only one of its fragments is lost. 3) The fact that the TCP connections are not using PMTU causes fragmentation in the presence of IPsec. What should I do to use PMTU? From what I've seen, there does not appear to be a bug in Linux that could explain the behaviour change that is seen when you run tcpdump. Ok, thanks for the explanation. I have a couple of question. 1) If mimosa is switched to klips the problem disappear. Why? 2) I have done another test bypassing pleiadi. Only mimosa is involved. Here is network schema (I hope it is clear): customer private network 10.0.0.0/8 | | +ipsec customer gateway (nokia/checkpoint) |==MTU=1444 | | |---ipsec tunnel 10.0.0.0/8<->172.29.128.0/28 (3DES/MD5) | | |+---win_XP + modem 56K + sapgui | / | /---ipsec tunnel 10.0.0.0/8<->road_warrior_ip(3DES/MD5/IPCOMP) | / |/ +upgraded ipsec gateway (mimosa) from klips to 2.6.17.4 |On mimosa I have inserted these this rule: |Chain POSTROUTING (policy ACCEPT) |target prot opt source destination |SNAT all -- road-warrior-ip 10.0.0.0/8 to:172.29.128.1 | | priv network (172.18.1.0/24) Now, a windows XPsp2 roadwarrior connect to the internet with a slow 56k analog modem, get a public dyn ip address, and establish an IPsec tunnel to mimosa, then mimosa snat the rw dyn ip address to 172.29.128.1 When I try to connect to the sap server I get the same issue: without tcpdump I get the connection reset, with tcpdump running all is fine. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is RDMA (was: RDMA will be reverted)
On Fri, Jul 07, 2006 at 01:25:44PM -0500, Steve Wise wrote: > > Some IP networking is involved for this. IP addresses and port numbers > are used by the RDMA Connection Manager. The motivation for this was > two-fold, I think: > > 1) to simplify the connection setup model. The IB CM model was very > complex. > > 2) to allow ULPs to be transport independent. Thus a single code base > for NFSoRDMA, for example, can run over Infiniband and RDMA/TCP > transports without code changes or knowing about transport-specific > addressing. > > The routing table is also consulted to determine which rdma device > should be used for connection setup. Each rdma device also installs a > netdev device for native stack traffic. The RDMA CM maintains an > association between the netdev device and the rdma device. > > And the Infiniband subsystem uses ARP over IPoIB to map IP addresses to > GID/QPN info. This is done by calling arp_send() directly, and snooping > all ARP packets to "discover" when the arp entry is completed. This sounds interesting. Since this is going to be IB-neutral, what about moving high-level logic like this is moved out of drivers/infiniband and into net? That way the rest of the networking community can add input into how things are done. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: d80211 sysfs
Sorry for the double mail. Forgot to CC netdev list. Hi, > 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? Yes, I have verified this problem on my PC as well and it is running a non-SMP kernel. I have also checked the reports from other users and it seems to affect both SMP as non-SMP users/kernels. Ivo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ipsec tunnel asymmetrical mtu
On Mon, May 08, 2006 at 08:28:32AM +, Marco Berizzi wrote: > > [EMAIL PROTECTED]:~# ping 10.49.59.23 > PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data. > 64 bytes from 10.49.59.23: icmp_seq=1 ttl=247 time=91.9 ms > 64 bytes from 10.49.59.23: icmp_seq=2 ttl=247 time=49.3 ms > 64 bytes from 10.49.59.23: icmp_seq=3 ttl=247 time=106 ms > 64 bytes from 10.49.59.23: icmp_seq=4 ttl=247 time=74.3 ms > > --- 10.49.59.23 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 2998ms > rtt min/avg/max/mdev = 49.316/80.460/106.257/21.241 ms > [EMAIL PROTECTED]:~# cd /tmp/ > [EMAIL PROTECTED]:/tmp# tcpdump -v -p -n ip host 10.49.59.23 > > /tmp/NULL-10.49.59.23 & > [1] 18981 > [EMAIL PROTECTED]:/tmp# tcpdump: listening on eth0, link-type EN10MB > (Ethernet), > capture size 96 bytes > > [EMAIL PROTECTED]:/tmp# ping 10.49.59.23 > PING 10.49.59.23 (10.49.59.23) 56(84) bytes of data. > > --- 10.49.59.23 ping statistics --- > 8 packets transmitted, 0 received, 100% packet loss, time 6999ms > > [EMAIL PROTECTED]:/tmp# fg > tcpdump -v -p -n ip host 10.49.59.23 >/tmp/NULL-10.49.59.23 > 101 packets captured > 101 packets received by filter > 0 packets dropped by kernel Yes this is really weird. The only thing I can think of is that it somehow managed to put some bogus entry into the conntrack table. What happens if you do grep 10.49.59.23 /proc/net/ip_conntrack before and after the tcpdump? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Netchannel: default, find, add to socket
From: Evgeniy Polyakov <[EMAIL PROTECTED]> Date: Tue, 11 Jul 2006 09:57:08 +0400 > Did you benchmarked such approach both with > and without netchannel bound to the socket? It is not meant to be used in "real life" :-) So benchmark is quite useless. We are starting simple, and eventually all types of packets will hit some kind of channel, thus making the default channel a kind of anomaly slow path. That code will not come immediately, therefore it would be nice if the performance were not too bad, and it can be made into a software interrupt or tasklet with some care. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html