date:20060711

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

2006-07-11 Thread Shailabh Nagar

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

2006-07-11 Thread Michael Chan

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

2006-07-11 Thread Stephen Hemminger

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

2006-07-11 Thread Zhu Yi

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

2006-07-11 Thread Tetsuo Takata

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

2006-07-11 Thread Kevin Brown


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

2006-07-11 Thread Larry Finger

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?

2006-07-11 Thread Ian McDonald


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

2006-07-11 Thread Andreas Kleen


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

2006-07-11 Thread Anthony DeRobertis

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?

2006-07-11 Thread Ian McDonald


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

2006-07-11 Thread Ravinandan Arakali

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

2006-07-11 Thread Randy.Dunlap

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.

2006-07-11 Thread Ben Greear

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.

2006-07-11 Thread Ben Greear


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

2006-07-11 Thread john stultz

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

2006-07-11 Thread Jar



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

2006-07-11 Thread Stefan Rompf

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()

2006-07-11 Thread Stefan Rompf

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()

2006-07-11 Thread Stefan Rompf

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

2006-07-11 Thread Laurent Riffard


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)

2006-07-11 Thread shawvrana

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

2006-07-11 Thread Joel Becker

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

2006-07-11 Thread Ben Greear


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

2006-07-11 Thread Pavel Machek


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

2006-07-11 Thread Pavel Machek

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

2006-07-11 Thread 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.


--- 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*()

2006-07-11 Thread Krzysztof Halasa

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)

2006-07-11 Thread Auke Kok

[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

2006-07-11 Thread Simon Williams


  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?

2006-07-11 Thread John W. Linville

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

2006-07-11 Thread Dan Williams

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

2006-07-11 Thread Roland Dreier

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)

2006-07-11 Thread shaw

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

2006-07-11 Thread Shailabh Nagar

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

2006-07-11 Thread Larry Finger

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

2006-07-11 Thread Brown, Len

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

2006-07-11 Thread Arjan van de Ven

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

2006-07-11 Thread Arjan van de Ven

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

2006-07-11 Thread Alex Davis

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()

2006-07-11 Thread Or Gerlitz


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?

2006-07-11 Thread Andy Gay

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()

2006-07-11 Thread Or Gerlitz


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)

2006-07-11 Thread Steve Wise

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..

2006-07-11 Thread Valdis . Kletnieks

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

2006-07-11 Thread Ingo Molnar


* 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

2006-07-11 Thread Pavel Machek

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

2006-07-11 Thread Andrew Morton

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

2006-07-11 Thread Andrew Morton

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

2006-07-11 Thread Andrew Morton

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

2006-07-11 Thread Arjan van de Ven

> 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