Re: [Comment] sizeof(struct tcp_sock) is above 1024 on x86 since linux-2.6.15
From: Eric Dumazet [EMAIL PROTECTED] Date: Tue, 21 Mar 2006 15:17:17 +0100 I would like to point out that struct tcp_sock was enlarged in 2.6.15, and the 'TCP' kmem_cache now needs order-1 allocations instead of order-0 Thanks for pointing this out Eric, I'll see what I can do to trim it down a bit. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/6] s390: qeth driver statistics fixes
On Wed, 22 Mar 2006 20:30:31 -0500 Jeff Garzik [EMAIL PROTECTED] wrote: Frank Pavlic wrote: [patch 2/6] s390: qeth driver statistics fixes From: Ursula Braun [EMAIL PROTECTED] - display unsigned int values in /proc/qeth_perf with %u instead of %i - omit qdio header length when increasing card-stats.tx_bytes Signed-off-by: Frank Pavlic [EMAIL PROTECTED] applied 2-4 I am OK with removing tty from network driver (patches 5-6), but they didn't apply hmm ok , I have built new ones today ... Let me know if you still run into problems to apply the new two ctc tty removal patches... Thanks Frank - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND patch 6/6] s390: remove tty support from ctc network device driver [2/2]
[patch 6/6] s390: remove tty support from ctc network device driver [2/2]
From: Peter Tiedemann [EMAIL PROTECTED]
[2/2]: remove ctctty.c and ctctty.h files .
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
diffstat:
drivers/s390/net/ctctty.c | 1259 -
drivers/s390/net/ctctty.h | 35 -
2 files changed, 0 insertions(+), 1294 deletions(-)
delete mode 100644 drivers/s390/net/ctctty.c
delete mode 100644 drivers/s390/net/ctctty.h
5849a244ec8f32fe4dbbb8212cb48dc688e7a17d
diff --git a/drivers/s390/net/ctctty.c b/drivers/s390/net/ctctty.c
deleted file mode 100644
index 5cdcdbf..000
--- a/drivers/s390/net/ctctty.c
+++ /dev/null
@@ -1,1259 +0,0 @@
-/*
- * CTC / ESCON network driver, tty interface.
- *
- * Copyright (C) 2001 IBM Deutschland Entwicklung GmbH, IBM Corporation
- * Author(s): Fritz Elfert ([EMAIL PROTECTED], [EMAIL PROTECTED])
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2, or (at your option)
- * any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- *
- */
-
-#include linux/config.h
-#include linux/module.h
-#include linux/tty.h
-#include linux/tty_flip.h
-#include linux/serial_reg.h
-#include linux/interrupt.h
-#include linux/delay.h
-#include asm/uaccess.h
-#include linux/devfs_fs_kernel.h
-#include ctctty.h
-#include ctcdbug.h
-
-#define CTC_TTY_MAJOR 43
-#define CTC_TTY_MAX_DEVICES 64
-
-#define CTC_ASYNC_MAGIC 0x49344C01 /* for paranoia-checking*/
-#define CTC_ASYNC_INITIALIZED0x8000 /* port was initialized */
-#define CTC_ASYNC_NORMAL_ACTIVE 0x2000 /* Normal device active */
-#define CTC_ASYNC_CLOSING0x0800 /* Serial port is closing */
-#define CTC_ASYNC_CTS_FLOW 0x0400 /* Do CTS flow control */
-#define CTC_ASYNC_CHECK_CD 0x0200 /* i.e., CLOCAL */
-#define CTC_ASYNC_HUP_NOTIFY 0x0001 /* Notify tty on hangups/closes */
-#define CTC_ASYNC_NETDEV_OPEN0x0002 /* Underlying netdev is open*/
-#define CTC_ASYNC_TX_LINESTAT0x0004 /* Must send line status*/
-#define CTC_ASYNC_SPLIT_TERMIOS 0x0008 /* Sep. termios for dialin/out */
-#define CTC_TTY_XMIT_SIZE 1024 /* Default bufsize for write*/
-#define CTC_SERIAL_XMIT_MAX4000 /* Maximum bufsize for write*/
-
-/* Private data (similar to async_struct in linux/serial.h) */
-typedef struct {
- int magic;
- int flags; /* defined in tty.h */
- int mcr; /* Modem control register */
- int msr; /* Modem status register */
- int lsr; /* Line status register */
- int line;
- int count; /* # of fd on device */
- int blocked_open;/* # of blocked opens */
- struct net_device *netdev;
- struct sk_buff_head tx_queue;/* transmit queue */
- struct sk_buff_head rx_queue;/* receive queue */
- struct tty_struct*tty;/* Pointer to corresponding tty */
- wait_queue_head_topen_wait;
- wait_queue_head_tclose_wait;
- struct semaphore write_sem;
- struct tasklet_struct tasklet;
- struct timer_list stoptimer;
-} ctc_tty_info;
-
-/* Description of one CTC-tty */
-typedef struct {
- struct tty_driver *ctc_tty_device; /* tty-device */
- ctc_tty_info info[CTC_TTY_MAX_DEVICES]; /* Private data
*/
-} ctc_tty_driver;
-
-static ctc_tty_driver *driver;
-
-/* Leave this unchanged unless you know what you do! */
-#define MODEM_PARANOIA_CHECK
-#define MODEM_DO_RESTART
-
-#define CTC_TTY_NAME ctctty
-
-static __u32 ctc_tty_magic = CTC_ASYNC_MAGIC;
-static int ctc_tty_shuttingdown = 0;
-
-static spinlock_t ctc_tty_lock;
-
-/* ctc_tty_try_read() is called from within ctc_tty_rcv_skb()
- * to stuff incoming data directly into a tty's flip-buffer. If the
- * flip buffer is full, the packet gets queued up.
- *
- * Return:
- * 1 = Success
- * 0 = Failure, data has to be buffered and later processed by
- * ctc_tty_readmodem().
- */
-static int
-ctc_tty_try_read(ctc_tty_info * info, struct sk_buff *skb)
-{
- int len;
- struct tty_struct *tty;
-
-
[RESEND patch 5/6] s390: remove tty support from ctc network device driver [1/2]
[patch 5/6] s390: remove tty support from ctc network device driver [1/2]
From: Peter Tiedemann [EMAIL PROTECTED]
[1/2]:
tty support code will be removed from the ctc network device driver.
Today we have a couple of alternatives which are performing much
better. The second thing is that ctc should be a network
device driver only.
We should not mix tty and networking here.
This first patch will remove the tty code from ctcmain.c .
It also removes the build entry from the Makefile as well as TTY
definitions from ctcmain.h.
The second patch will remove two files, ctctty.c and ctctty.h.
Signed-off-by: Frank Pavlic [EMAIL PROTECTED]
diffstat:
Makefile |3 ++-
ctcmain.c | 45 +
ctcmain.h | 12 +---
3 files changed, 16 insertions(+), 44 deletions(-)
diff -Naupr git-linux/drivers/s390/net/ctcmain.c
git-patched/drivers/s390/net/ctcmain.c
--- git-linux/drivers/s390/net/ctcmain.c2006-03-24 09:21:59.0
+0100
+++ git-patched/drivers/s390/net/ctcmain.c 2006-03-24 09:41:17.0
+0100
@@ -6,7 +6,7 @@
* Fixes by : Jochen Röhrig ([EMAIL PROTECTED])
*Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Peter Tiedemann ([EMAIL PROTECTED])
- * Driver Model stuff by : Cornelia Huck [EMAIL PROTECTED]
+ * Driver Model stuff by : Cornelia Huck [EMAIL PROTECTED]
*
* Documentation used:
* - Principles of Operation (IBM doc#: SA22-7201-06)
@@ -65,7 +65,6 @@
#include asm/idals.h
-#include ctctty.h
#include fsm.h
#include cu3088.h
@@ -479,10 +478,7 @@ ctc_unpack_skb(struct channel *ch, struc
skb-dev = pskb-dev;
skb-protocol = pskb-protocol;
pskb-ip_summed = CHECKSUM_UNNECESSARY;
- if (ch-protocol == CTC_PROTO_LINUX_TTY)
- ctc_tty_netif_rx(skb);
- else
- netif_rx_ni(skb);
+ netif_rx_ni(skb);
/**
* Successful rx; reset logflags
*/
@@ -557,8 +553,7 @@ ccw_unit_check(struct channel *ch, unsig
DBF_TEXT(trace, 5, __FUNCTION__);
if (sense SNS0_INTERVENTION_REQ) {
if (sense 0x01) {
- if (ch-protocol != CTC_PROTO_LINUX_TTY)
- ctc_pr_debug(%s: Interface disc. or Sel. reset
+ ctc_pr_debug(%s: Interface disc. or Sel. reset
(remote)\n, ch-id);
fsm_event(ch-fsm, CH_EVENT_UC_RCRESET, ch);
} else {
@@ -2034,7 +2029,6 @@ static void
dev_action_chup(fsm_instance * fi, int event, void *arg)
{
struct net_device *dev = (struct net_device *) arg;
- struct ctc_priv *privptr = dev-priv;
DBF_TEXT(trace, 3, __FUNCTION__);
switch (fsm_getstate(fi)) {
@@ -2049,8 +2043,6 @@ dev_action_chup(fsm_instance * fi, int e
fsm_newstate(fi, DEV_STATE_RUNNING);
ctc_pr_info(%s: connected with remote side\n,
dev-name);
- if (privptr-protocol == CTC_PROTO_LINUX_TTY)
- ctc_tty_setcarrier(dev, 1);
ctc_clear_busy(dev);
}
break;
@@ -2059,8 +2051,6 @@ dev_action_chup(fsm_instance * fi, int e
fsm_newstate(fi, DEV_STATE_RUNNING);
ctc_pr_info(%s: connected with remote side\n,
dev-name);
- if (privptr-protocol == CTC_PROTO_LINUX_TTY)
- ctc_tty_setcarrier(dev, 1);
ctc_clear_busy(dev);
}
break;
@@ -2086,14 +2076,10 @@ dev_action_chup(fsm_instance * fi, int e
static void
dev_action_chdown(fsm_instance * fi, int event, void *arg)
{
- struct net_device *dev = (struct net_device *) arg;
- struct ctc_priv *privptr = dev-priv;
DBF_TEXT(trace, 3, __FUNCTION__);
switch (fsm_getstate(fi)) {
case DEV_STATE_RUNNING:
- if (privptr-protocol == CTC_PROTO_LINUX_TTY)
- ctc_tty_setcarrier(dev, 0);
if (event == DEV_EVENT_TXDOWN)
fsm_newstate(fi, DEV_STATE_STARTWAIT_TX);
else
@@ -2397,8 +2383,6 @@ ctc_tx(struct sk_buff *skb, struct net_d
*/
if (fsm_getstate(privptr-fsm) != DEV_STATE_RUNNING) {
fsm_event(privptr-fsm, DEV_EVENT_START, dev);
- if (privptr-protocol == CTC_PROTO_LINUX_TTY)
- return -EBUSY;
dev_kfree_skb(skb);
Re: [RFC] lmc wan driver rewrite
David Boggs [EMAIL PROTECTED] writes: If you insist, I will run it through scripts/Lindent before submitting. I will not but others may do. Standard formatting is just better and the cost is near zero. The same two source files compile on Linux, FreeBSD, NetBSD and OpenBSD. I intend to maintain this driver and keep it in sync across OSs, so I would rather not strip out the BSD code. I tried to minimize the number of #if FOO statements and I added comments attempting to make it clear which kernels used which code. I'm almost sure it won't be accepted upstream in this shape. OTOH having all sources in one place (Free/Net/OpenBSD/Linux) and passing make some parameter to decide what kernel are we building is an interesting idea :-) The driver configuration program reports the currently-selected line protocol to the user. hdlcdev-proto.id is public, so... Well, the comment before proto struct in include/linux/hdlc.h says: /* Things below are for HDLC layer internal use only */ but of course it's not a strict requirement, given that access to it makes sense. -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.16-gitX] heavy performance regression in ipw2200 wireless driver
On 3/24/06, Zhu Yi [EMAIL PROTECTED] wrote: On Thu, 2006-03-23 at 15:02 +0100, Alessandro Suardi wrote: That scp test shows 50%ish - but that was a quickie. The VNC client even reported a 719Kbps throughput down from the more usual 11500Kbps it starts off with. The first scp I tried when the sluggishness was intolerable was going at 200KB/s - which shows the problem can easily get in the neighborhood of an order of magnitude. What kind of wireless encryption do you use? We turned off hardware encryption by default recently as a workaround for a firmware restart bug. You might want to load module with modprobe ipw2200 hwcrypto=1 and retest. I actually use no encryption yet, as I still have to find out time to call D-Link about the fact that my router hangs when I try to set up a whitelist of MAC addresses for the wireless AP; WPA would be up next... Would loading the module with h/w encryption turned on make any difference in my case ? Thanks, PS don't tell my neighbors ;) --alessandro Dreamer ? Each one of us is a dreamer. We just push it down deep because we are repeatedly told that we are not allowed to dream in real life (Reinhold Ziegler) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ebt_ulog: not logging via ulog since somebody else already registered for PF_BRIDGE
David S. Miller wrote: From: Andrew Morton [EMAIL PROTECTED] Date: Thu, 23 Mar 2006 21:51:24 -0800 How come? Because you can't enable ebt_ulog and ebt_log at the same time. All of the ULOG targets are obsolete, but are kept around for compatability. It's problematic when these things are all built statically into the kernel, but I don't think the answer is to prevent them from being built statically either. Perhaps if one is built statically, we should prevent it's counterpart from being built at all. Patrick? The message is actually obsolete and should be changed. When the ULOG changes first went in they changed all *LOG targets to register as netfilter log backends and use these backends to log themselves. Since there can be only a single log backend currently for each family, this broke compabilitlity when multiple backends are loaded, which is why I changed it so the targets register as backends, but still always use their own log functions. I'm going to change this message in my next batch of patches to something like not registering as primary logging backend for AF_... to be less misleading. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.16-git7] AT91RM9200 Ethernet driver
This patch adds support for the Ethernet controller integrated in the
Atmel AT91RM9200 SoC processor.
Changes since the previous submission (01/02/2006) are:
- Make use of the clk.h clock infrastructure.
- The multicast hash function is not crc32. [Patch by Pedro Perez]
Signed-off-by: Andrew Victor [EMAIL PROTECTED]
diff -urN linux-2.6.16-git7.orig/drivers/net/arm/Kconfig
linux-2.6.16-git7/drivers/net/arm/Kconfig
--- linux-2.6.16-git7.orig/drivers/net/arm/Kconfig Mon Mar 20 11:17:12 2006
+++ linux-2.6.16-git7/drivers/net/arm/Kconfig Fri Mar 24 11:30:40 2006
@@ -31,3 +31,11 @@
help
If you have an Acorn system with one of these network cards, you
should say Y to this option if you wish to use it with Linux.
+
+config ARM_AT91_ETHER
+ tristate AT91RM9200 Ethernet support
+ depends on NET_ETHERNET ARM ARCH_AT91RM9200
+ select MII
+ help
+ If you wish to compile a kernel for the AT91RM9200 and enable
+ ethernet support, then you should always answer Y to this.
diff -urN linux-2.6.16-git7.orig/drivers/net/arm/Makefile
linux-2.6.16-git7/drivers/net/arm/Makefile
--- linux-2.6.16-git7.orig/drivers/net/arm/Makefile Mon Mar 20 11:17:12 2006
+++ linux-2.6.16-git7/drivers/net/arm/Makefile Fri Mar 24 11:30:21 2006
@@ -7,3 +7,4 @@
obj-$(CONFIG_ARM_ETHERH) += etherh.o
obj-$(CONFIG_ARM_ETHER3) += ether3.o
obj-$(CONFIG_ARM_ETHER1) += ether1.o
+obj-$(CONFIG_ARM_AT91_ETHER) += at91_ether.o
diff -urN linux-2.6.16-git7.orig/drivers/net/arm/at91_ether.c
linux-2.6.16-git7/drivers/net/arm/at91_ether.c
--- linux-2.6.16-git7.orig/drivers/net/arm/at91_ether.c Thu Jan 1 02:00:00 1970
+++ linux-2.6.16-git7/drivers/net/arm/at91_ether.c Fri Mar 24 11:30:21 2006
@@ -0,0 +1,1110 @@
+/*
+ * Ethernet driver for the Atmel AT91RM9200 (Thunder)
+ *
+ * Copyright (C) 2003 SAN People (Pty) Ltd
+ *
+ * Based on an earlier Atmel EMAC macrocell driver by Atmel and Lineo Inc.
+ * Initial version by Rick Bronson 01/11/2003
+ *
+ * Intel LXT971A PHY support by Christopher Bahns David Knickerbocker
+ * (Polaroid Corporation)
+ *
+ * Realtek RTL8201(B)L PHY support by Roman Avramenko [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/config.h
+#include linux/mii.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/skbuff.h
+#include linux/dma-mapping.h
+#include linux/ethtool.h
+#include linux/platform_device.h
+#include linux/clk.h
+
+#include asm/io.h
+#include asm/uaccess.h
+#include asm/mach-types.h
+
+#include asm/arch/at91rm9200_emac.h
+#include asm/arch/gpio.h
+#include asm/arch/board.h
+
+#include at91_ether.h
+
+#define DRV_NAME at91_ether
+#define DRV_VERSION1.0
+
+static struct net_device *at91_dev;
+static struct clk *ether_clk;
+
+/* . */
+
+/*
+ * Read from a EMAC register.
+ */
+static inline unsigned long at91_emac_read(unsigned int reg)
+{
+ void __iomem *emac_base = (void __iomem *)AT91_VA_BASE_EMAC;
+
+ return __raw_readl(emac_base + reg);
+}
+
+/*
+ * Write to a EMAC register.
+ */
+static inline void at91_emac_write(unsigned int reg, unsigned long value)
+{
+ void __iomem *emac_base = (void __iomem *)AT91_VA_BASE_EMAC;
+
+ __raw_writel(value, emac_base + reg);
+}
+
+/* ... PHY INTERFACE ... */
+
+/*
+ * Enable the MDIO bit in MAC control register
+ * When not called from an interrupt-handler, access to the PHY must be
+ * protected by a spinlock.
+ */
+static void enable_mdi(void)
+{
+ unsigned long ctl;
+
+ ctl = at91_emac_read(AT91_EMAC_CTL);
+ at91_emac_write(AT91_EMAC_CTL, ctl | AT91_EMAC_MPE);/* enable
management port */
+}
+
+/*
+ * Disable the MDIO bit in the MAC control register
+ */
+static void disable_mdi(void)
+{
+ unsigned long ctl;
+
+ ctl = at91_emac_read(AT91_EMAC_CTL);
+ at91_emac_write(AT91_EMAC_CTL, ctl ~AT91_EMAC_MPE); /* disable
management port */
+}
+
+/*
+ * Wait until the PHY operation is complete.
+ */
+static inline void at91_phy_wait(void) {
+ unsigned long timeout = jiffies + 2;
+
+ while (!(at91_emac_read(AT91_EMAC_SR) AT91_EMAC_SR_IDLE)) {
+ if (time_after(jiffies, timeout)) {
+ printk(at91_ether: MIO timeout\n);
+ break;
+ }
+ cpu_relax();
+ }
+}
+
+/*
+ * Write value to the a PHY register
+ * Note: MDI interface is assumed to already have been enabled.
+ */
+static void write_phy(unsigned char phy_addr, unsigned char address, unsigned
int value)
+{
+
Re: [SOFTMAC] Reduce scan dwell time
On Thu, 2006-03-23 at 20:16 -0500, Dan Williams wrote: Ok, that's cool. Wasn't apparent to me from the initial message. But does that mean that softmac is doing the scanning with _probe_ requests on each channel? It's not doing passive scanning? Right. It's an active scan. -- dwmw2 - To unsubscribe from this list: send the 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] ip6_tunnel: fix a soft lockup when there is no active tunnel for an encapsulated packet
When xfrm6_tunnel is in use you've just made it use a freed skb. Also IPv4 has the same problem so we shold fix them both. I didn't hit this since i'm not currently using xfrm6_tunnel (which is also why i got the soft lockup). I'll consider the case when xfrm6_tunnel is being used, and submit another patch. Thanks, Hugo signature.asc Description: Digital signature
[PATCH] ip6_tunnel: fix a soft lockup when there is no active tunnel for an encapsulated packet
Hi, This patch fixes a soft lockup in ip6_tunnel when not using xfrm6_tunnel (CONFIG_INET6_TUNNEL). It is triggered when an encapsula- ted packet reaches ip6ip6_rcv() and there is no tunnel associated with it. The error path returns a positive value (1) which will trigger ip6_input to re-submit the packet for processing. As no skb parameters have been changed, ip6ip6_rcv() will continue to be called with the exact same context. Also, ip6ip6_rcv() should free the skb when discarding it. Signed-off-by: Hugo Santos [EMAIL PROTECTED] --- linux-2.6.16/net/ipv6/ip6_tunnel.c.orig 2006-03-23 16:19:19.0 + +++ linux-2.6.16/net/ipv6/ip6_tunnel.c 2006-03-24 11:19:51.0 + @@ -557,7 +557,12 @@ ip6ip6_rcv(struct sk_buff **pskb) read_unlock(ip6ip6_lock); icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_ADDR_UNREACH, 0, skb-dev); discard: - return 1; + /* If xfrm6_tunnel is being used, it will free the skb +* otherwise we must do it */ +#ifndef CONFIG_INET6_TUNNEL + kfree_skb(skb); +#endif + return -1; } static inline struct ipv6_txoptions *create_tel(__u8 encap_limit) signature.asc Description: Digital signature
Re: [PATCH] [IPV4] PMTU issues due to TOS field manipulation
On Thu, Feb 16, 2006 at 10:04:14PM +0200, Ilia Sotnikov wrote:
Here it is, against 2.6.16-rc3.
OK, I've brought this patch up-to-date with 2.6.16 and got rid of a few
more references to tos in ip_rt_redirect. Please note that the author
of this patch is Ilia Sotnikov [EMAIL PROTECTED].
From: Ilia Sotnikov [EMAIL PROTECTED]
[IPV4]: Aggregate route entries with different TOS values
When we get an ICMP need-to-frag message, the original TOS value in the
ICMP payload cannot be used as a key to look up the routes to update.
This is because the TOS field may have been modified by routers on the
way. Similarly, ip_rt_redirect should also ignore the TOS as the router
that gave us the message may have modified the TOS value.
The patch achieves this objective by aggregating entries with different
TOS values (but are otherwise identical) into the same bucket. This
makes it easy to update them at the same time when an ICMP message is
received.
In future we should use a twin-hashing scheme where teh aggregation
occurs at the entry level. That is, the TOS goes back into the hash
for normal lookups while ICMP lookups will end up with a node that
gives us a list that contains all other route entries that differ
only by TOS.
Signed-off-by: Ilia Sotnikov [EMAIL PROTECTED]
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/include/net/route.h b/include/net/route.h
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -110,7 +110,7 @@ extern struct ip_rt_acct *ip_rt_acct;
struct in_device;
extern int ip_rt_init(void);
extern voidip_rt_redirect(u32 old_gw, u32 dst, u32 new_gw,
- u32 src, u8 tos, struct net_device *dev);
+ u32 src, struct net_device *dev);
extern voidip_rt_advice(struct rtable **rp, int advice);
extern voidrt_cache_flush(int how);
extern int __ip_route_output_key(struct rtable **, const struct
flowi *flp);
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -753,7 +753,7 @@ static void icmp_redirect(struct sk_buff
case ICMP_REDIR_HOST:
case ICMP_REDIR_HOSTTOS:
ip_rt_redirect(skb-nh.iph-saddr, ip, skb-h.icmph-un.gateway,
- iph-saddr, iph-tos, skb-dev);
+ iph-saddr, skb-dev);
break;
}
out:
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -55,6 +55,8 @@
* Robert Olsson : Added rt_cache statistics
* Arnaldo C. Melo : Convert proc stuff to seq_file
* Eric Dumazet: hashed spinlocks and rt_check_expire()
fixes.
+ * Ilia Sotnikov : Ignore TOS on PMTUD and Redirect
+ * Ilia Sotnikov : Removed TOS from hash calculations
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -247,9 +249,9 @@ static DEFINE_PER_CPU(struct rt_cache_st
static int rt_intern_hash(unsigned hash, struct rtable *rth,
struct rtable **res);
-static unsigned int rt_hash_code(u32 daddr, u32 saddr, u8 tos)
+static unsigned int rt_hash_code(u32 daddr, u32 saddr)
{
- return (jhash_3words(daddr, saddr, (u32) tos, rt_hash_rnd)
+ return (jhash_2words(daddr, saddr, rt_hash_rnd)
rt_hash_mask);
}
@@ -,7 +1113,7 @@ static void rt_del(unsigned hash, struct
}
void ip_rt_redirect(u32 old_gw, u32 daddr, u32 new_gw,
- u32 saddr, u8 tos, struct net_device *dev)
+ u32 saddr, struct net_device *dev)
{
int i, k;
struct in_device *in_dev = in_dev_get(dev);
@@ -1119,8 +1121,6 @@ void ip_rt_redirect(u32 old_gw, u32 dadd
u32 skeys[2] = { saddr, 0 };
int ikeys[2] = { dev-ifindex, 0 };
- tos = IPTOS_RT_MASK;
-
if (!in_dev)
return;
@@ -1141,8 +1141,7 @@ void ip_rt_redirect(u32 old_gw, u32 dadd
for (i = 0; i 2; i++) {
for (k = 0; k 2; k++) {
unsigned hash = rt_hash_code(daddr,
-skeys[i] ^ (ikeys[k] 5),
-tos);
+skeys[i] ^ (ikeys[k]
5));
rthp=rt_hash_table[hash].chain;
@@ -1152,7 +1151,6 @@ void ip_rt_redirect(u32 old_gw, u32 dadd
if (rth-fl.fl4_dst != daddr ||
rth-fl.fl4_src != skeys[i] ||
-
Re: tg3 breakage this morning
Michael Chan wrote:
On Thu, 2006-03-23 at 14:16 -0800, walt wrote:
tg3.c:v3.53 (Mar 22, 2006)
PCI: Enabling device :00:09.0 (0014 - 0016)
ACPI: PCI Interrupt :00:09.0[A] - GSI 18 (level, low) - IRQ 17
tg3: Could not obtain valid ethernet address, aborting.
ACPI: PCI interrupt for device :00:09.0 disabled
tg3: probe of :00:09.0 failed with error -22
These are the patches between 3.52 and 3.53:
[TG3]: Bump driver version and reldate.
[TG3]: Skip phy power down on some devices
[TG3]: Fix SRAM access during tg3_init_one()
[TG3]: Don't mark tg3_test_registers() as returning ...
[TG3]: make drivers/net/tg3.c:tg3_request_irq() static
[TG3]: netif_carrier_off runs too early; could still ..
I cannot think of anything in here that can cause MAC address failure on
your 5702. The 3rd one Fix SRAM access .. is a remote and only
possibility. Can you back out that patch to see if it works? ...
Nope, it was the second one: Skip phy power down...
Let me know if can test any patches, etc.
This is the problem code:
$diff -u tg3.c.good tg3.c
--- tg3.c.good 2006-03-23 20:08:55.0 -0800
+++ tg3.c 2006-03-24 04:19:59.0 -0800
@@ -1148,6 +1148,19 @@
static int tg3_nvram_lock(struct tg3 *);
static void tg3_nvram_unlock(struct tg3 *);
+static void tg3_power_down_phy(struct tg3 *tp)
+{
+ /* The PHY should not be powered down on some chips because
+* of bugs.
+*/
+ if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5700 ||
+ GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5704 ||
+ (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5780
+(tp-tg3_flags2 TG3_FLG2_MII_SERDES)))
+ return;
+ tg3_writephy(tp, MII_BMCR, BMCR_PDOWN);
+}
+
static int tg3_set_power_state(struct tg3 *tp, pci_power_t state)
{
u32 misc_host_ctrl;
@@ -1327,8 +1340,7 @@
tg3_writephy(tp, MII_TG3_EXT_CTRL,
MII_TG3_EXT_CTRL_FORCE_LED_OFF);
tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x01b2);
- if (GET_ASIC_REV(tp-pci_chip_rev_id) !=
ASIC_REV_5700)
- tg3_writephy(tp, MII_BMCR, BMCR_PDOWN);
+ tg3_power_down_phy(tp);
}
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
still regarding ip6_tunnel and xfrm6_tunnel
Hi, When ip6_tunnel discards a packet because there is no tunnel associated with it, it sends a ICMPV6_DEST_UNREACH error to the packet source. However, when using ip6_tunnel and xfrm6_tunnel, if there is a a tunnel spi allocated for it, it may be processed dispite ip6_tunnel having already sent the error to the source. Is this behaviour expected? Thanks, Hugo signature.asc Description: Digital signature
Re: [SOFTMAC] Reduce scan dwell time
On Fri, 2006-03-24 at 07:58 -0500, Dan Williams wrote: Ok, so why is softmac doing an active scan, per my previous email message? Why is it not doing passive scan for normal SIOCSIWSCAN like most every other driver? (to be honest, I'm not entirely sure what ipw is doing here, but I think its passive along with the rest of the drivers) Because no one bothered to fix it yet, and we needed active scanning for when you want to associate with a hidden network. johannes signature.asc Description: This is a digitally signed message part
Re: wireless-2.6-softmac patch: prism54usb update
On Thu, Mar 23, 2006 at 09:05:24PM -0800, Pete Zaitcev wrote: On Thu, 23 Mar 2006 14:06:24 -0500, John W. Linville [EMAIL PROTECTED] wrote: Pete, I couldn't get this to apply. It seemed like there was a mismatch between your codebase and mine. I removed my repository and cloned your wireless-2.6 again. It turned out that the branch softmac was removed, and, naturally, old prism54usb was removed too. It's a small wonder that my patch did not apply. Yes, sorry. I renamed the softmac branch as devel -- it has the stuff that was on the softmac branch, other than softmac component itself. Don't worry, I didn't lose the old stuff! I'm going to send you a patch which re-adds the whole enchilada again, diffed against your master branch. Is this all right? It could be alright, depending on what you want to do next (as we discussed off-line). Do you think prism54usb is ready to go upstream? With softmac merged, I think we should start getting softmac-based drivers reviewed and merged. If it is basically functional, I think it is probably worth consideration. If you think it is ready, go ahead and post the master-based branches here. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6-softmac patch: prism54usb update
On Fri, Mar 24, 2006 at 08:15:24AM -0500, John W. Linville wrote: If you think it is ready, go ahead and post the master-based branches here. s/branches/patches/ -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
On Thu, 2006-23-03 at 21:11 +0530, Balbir Singh wrote: On Thu, Mar 23, 2006 at 09:04:46AM -0500, jamal wrote: Should there be at least either a pid or tgid? If yes, you need to validate here... Yes, you are correct. One of my test cases caught it too.. But I did not want to untidy the code with if-else's which will keep growing if the attributes change in the future. I just followed the controller example. I will change it and validate it. Currently if the attribute is not valid, a stat of all zero's is returned back. There are many ways to skin this cat. As an example: you could make pid and tgid global to the function and set them to 0. At the end of the if statements, you could check if at least one of them is set - if not you know none was passed and bail out. As a general comment double check your logic for errors; if you already have stashed something in the skb, you need to remove it etc. Wouldn't genlmsg_cancel() take care of cleaning all attributes? it would for attribute setting - but not for others. As a general comment this is one of those areas where cutnpasting aka TheLinuxWay(tm) could result in errors. A single message with PID+TGID sounds reasonable. Why two messages with two stats? all you will need to do is get rid of the prepare_reply() above and NLA_PUT_U32() below (just like you do in a response to a GET. The reason for two stats is that for TGID, we return accumulated values (of all threads in the group) and for PID we return the value just for that pid. The return value is Ok, I understand the dilemma now - but still not thrilled with having two messages. Perhaps you could have nesting of TLVs? This is widely used in the net code for example i.e: TLV = TASKSTATS_TYPE_TGID/PID TLV = TASKSTATS_TYPE_STATS Look at using nla_nest_start/end/cancel cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
On Fri, 2006-24-03 at 07:02 +0530, Balbir Singh wrote: On Thu, Mar 23, 2006 at 09:04:46AM -0500, jamal wrote: 3. nlmsg_new() now allocates for 2*u32 + sizeof(taskstats) Not the right size; the u32 covers the V part of TLV. The T = 16 bits and L = 16 bits. And if you nest TLVs, then it gets more interesting. Look at using proper macros instead of hard coding like you did. grep for something like RTA_SPACE and perhaps send a patch to make it generic for netlink.h cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
On Fri, Mar 24, 2006 at 09:04:21AM -0500, jamal wrote: On Thu, 2006-23-03 at 21:11 +0530, Balbir Singh wrote: On Thu, Mar 23, 2006 at 09:04:46AM -0500, jamal wrote: Should there be at least either a pid or tgid? If yes, you need to validate here... Yes, you are correct. One of my test cases caught it too.. But I did not want to untidy the code with if-else's which will keep growing if the attributes change in the future. I just followed the controller example. I will change it and validate it. Currently if the attribute is not valid, a stat of all zero's is returned back. There are many ways to skin this cat. As an example: you could make pid and tgid global to the function and set them to 0. At the end of the if statements, you could check if at least one of them is set - if not you know none was passed and bail out. The latest patch does fix it this issue. In the Changelog 6. taskstats_send_stats() now validates the command attributes and ensures that it either gets a PID or a TGID. If it gets both simultaneously the PID stats are sent. Is this change ok with you? As a general comment double check your logic for errors; if you already have stashed something in the skb, you need to remove it etc. Wouldn't genlmsg_cancel() take care of cleaning all attributes? it would for attribute setting - but not for others. As a general comment this is one of those areas where cutnpasting aka TheLinuxWay(tm) could result in errors. :-) I understand. What I have done is moved all the NLA_PUT_U32 to after verifying the return values of functions fill_*(). That way we do not stash anything into the skb if there are pending errors. A single message with PID+TGID sounds reasonable. Why two messages with two stats? all you will need to do is get rid of the prepare_reply() above and NLA_PUT_U32() below (just like you do in a response to a GET. The reason for two stats is that for TGID, we return accumulated values (of all threads in the group) and for PID we return the value just for that pid. The return value is Ok, I understand the dilemma now - but still not thrilled with having two messages. Perhaps you could have nesting of TLVs? This is widely used in the net code for example i.e: TLV = TASKSTATS_TYPE_TGID/PID TLV = TASKSTATS_TYPE_STATS Look at using nla_nest_start/end/cancel Hmm... Would it be ok to send one message with the following format 1. TLV=TASKSTATS_TYPE_PID 2. TLV=TASKSTATS_TYPE_STATS 3. TLV=TASKSTATS_TYPE_TGID 4. TLV=TASKSTATS_TYPE_STATS It would still be one message, except that 3 and 4 would be optional. What do you think? cheers, jamal Thanks for your comments, Balbir - To unsubscribe from this list: send the 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][UPDATED PATCH 2.6.16] [Patch 9/9] Generic netlink interface for delay accounting
On Fri, Mar 24, 2006 at 09:11:58AM -0500, jamal wrote: On Fri, 2006-24-03 at 07:02 +0530, Balbir Singh wrote: On Thu, Mar 23, 2006 at 09:04:46AM -0500, jamal wrote: 3. nlmsg_new() now allocates for 2*u32 + sizeof(taskstats) Not the right size; the u32 covers the V part of TLV. The T = 16 bits and L = 16 bits. And if you nest TLVs, then it gets more interesting. Look at using proper macros instead of hard coding like you did. grep for something like RTA_SPACE and perhaps send a patch to make it generic for netlink.h cheers, jamal My bad, but I was wondering why my test case did not segfault until I saw the implementation of nlmsg_new :-) I will fix this and use nla_total_size() to calculate the correct sizes including padding and TLV. Thanks again, Balbir - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Fri, 2006-03-24 at 14:08 +0100, Johannes Berg wrote: On Fri, 2006-03-24 at 07:58 -0500, Dan Williams wrote: Ok, so why is softmac doing an active scan, per my previous email message? Why is it not doing passive scan for normal SIOCSIWSCAN like most every other driver? (to be honest, I'm not entirely sure what ipw is doing here, but I think its passive along with the rest of the drivers) Because no one bothered to fix it yet, and we needed active scanning for when you want to associate with a hidden network. Well, that's an application-defined decision, NOT a driver decision. And if you want active scanning, then softmac needs to implement SIOCSIWMLME, not do it in SIOCSIWSCAN. Drivers don't know what the user's power settings and preferences are. And they shouldn't. Lets try to be consistent among drivers here, and not balkanize the already wireless driver situation more than it already is. I'm not objecting to softmac going upstream here, but there's got to be an understanding that softmac is doing the _wrong_ thing in SIOCSIWSCAN. And that eventually that wrong thing will be fixed. Again, if you want active scans, implement SIOCSIWMLME. Dan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tg3 breakage this morning
Walt wrote:
Nope, it was the second one: Skip phy power down...
Let me know if can test any patches, etc.
It doesn't make sense. This code should have no effect on your
5702. With or without this patch, the 5702 will be powered down
the same with tg3_writephy(tp, MII_BMCR, BMCR_PDOWN) if WOL
is not enabled when you ifdown.
Also, for this code to have any effect, you must do ifdown or
suspend. So presumably the driver loaded fine at least once and
you get the failure during subsequent modprode. Is that right? But
the driver should behave the same on 5702 with or without the patch
if you follow the same sequence.
You can also try to bypass this code by setting WOL. Use
ethtool -S eth0 wol g to enable WOL and the phy will not be powered
down.
I'll look into this some more later today. Thanks.
This is the problem code:
$diff -u tg3.c.good tg3.c
--- tg3.c.good 2006-03-23 20:08:55.0 -0800
+++ tg3.c 2006-03-24 04:19:59.0 -0800
@@ -1148,6 +1148,19 @@
static int tg3_nvram_lock(struct tg3 *);
static void tg3_nvram_unlock(struct tg3 *);
+static void tg3_power_down_phy(struct tg3 *tp)
+{
+ /* The PHY should not be powered down on some chips because
+* of bugs.
+*/
+ if (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5700 ||
+ GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5704 ||
+ (GET_ASIC_REV(tp-pci_chip_rev_id) == ASIC_REV_5780
+(tp-tg3_flags2 TG3_FLG2_MII_SERDES)))
+ return;
+ tg3_writephy(tp, MII_BMCR, BMCR_PDOWN);
+}
+
static int tg3_set_power_state(struct tg3 *tp, pci_power_t state)
{
u32 misc_host_ctrl;
@@ -1327,8 +1340,7 @@
tg3_writephy(tp, MII_TG3_EXT_CTRL,
MII_TG3_EXT_CTRL_FORCE_LED_OFF);
tg3_writephy(tp, MII_TG3_AUX_CTRL, 0x01b2);
- if (GET_ASIC_REV(tp-pci_chip_rev_id) !=
ASIC_REV_5700)
- tg3_writephy(tp, MII_BMCR,
BMCR_PDOWN);
+ tg3_power_down_phy(tp);
}
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
via_rhine modules error on 2.6.16 with mii-tool
Hello evebody. I get this error on linux vanilla 2.6.16 with via_rhine module loaded when I run mii-tool: cheduling while atomic: mii-tool/0x0001/923 [c02bfca2] schedule+0x632/0x640 [c02c0577] schedule_timeout+0x57/0xb0 [c011c100] process_timeout+0x0/0x10 [c011c378] msleep+0x28/0x30 [c883d0bb] rhine_disable_linkmon+0xab/0x130 [via_rhine] [c022f11f] do_con_write+0x22f/0x5a0 [c883d16f] mdio_read+0x2f/0xd0 [via_rhine] [c88348c4] generic_mii_ioctl+0x84/0x164 [mii] [c883e7b0] netdev_ioctl+0x0/0x80 [via_rhine] [c883e7fd] netdev_ioctl+0x4d/0x80 [via_rhine] [c025f764] dev_ifsioc+0x334/0x3a0 [c025f964] dev_ioctl+0x194/0x2a0 [c0254528] sock_ioctl+0xe8/0x1f0 [c01637de] do_ioctl+0x8e/0xa0 [c0163995] vfs_ioctl+0x65/0x1f0 [c0163b65] sys_ioctl+0x45/0x70 [c0102d55] syscall_call+0x7/0xb scheduling while atomic: mii-tool/0x0001/923 [c02bfca2] schedule+0x632/0x640 [c02c0577] schedule_timeout+0x57/0xb0 [c011c100] process_timeout+0x0/0x10 [c011c378] msleep+0x28/0x30 [c883d0bb] rhine_disable_linkmon+0xab/0x130 [via_rhine] [c022f11f] do_con_write+0x22f/0x5a0 [c883d16f] mdio_read+0x2f/0xd0 [via_rhine] [c88348c4] generic_mii_ioctl+0x84/0x164 [mii] [c883e7b0] netdev_ioctl+0x0/0x80 [via_rhine] [c883e7fd] netdev_ioctl+0x4d/0x80 [via_rhine] [c025f764] dev_ifsioc+0x334/0x3a0 [c025f964] dev_ioctl+0x194/0x2a0 [c0254528] sock_ioctl+0xe8/0x1f0 [c01637de] do_ioctl+0x8e/0xa0 [c0163995] vfs_ioctl+0x65/0x1f0 [c0163b65] sys_ioctl+0x45/0x70 [c0102d55] syscall_call+0x7/0xb scheduling while atomic: mii-tool/0x0001/923 [c02bfca2] schedule+0x632/0x640 [c02c0577] schedule_timeout+0x57/0xb0 [c011c100] process_timeout+0x0/0x10 [c011c378] msleep+0x28/0x30 [c883d0bb] rhine_disable_linkmon+0xab/0x130 [via_rhine] [c022f11f] do_con_write+0x22f/0x5a0 [c883d16f] mdio_read+0x2f/0xd0 [via_rhine] [c88348c4] generic_mii_ioctl+0x84/0x164 [mii] [c883e7b0] netdev_ioctl+0x0/0x80 [via_rhine] [c883e7fd] netdev_ioctl+0x4d/0x80 [via_rhine] [c025f764] dev_ifsioc+0x334/0x3a0 [c025f964] dev_ioctl+0x194/0x2a0 [c0254528] sock_ioctl+0xe8/0x1f0 [c01637de] do_ioctl+0x8e/0xa0 [c0163995] vfs_ioctl+0x65/0x1f0 [c0163b65] sys_ioctl+0x45/0x70 [c0102d55] syscall_call+0x7/0xb scheduling while atomic: mii-tool/0x0001/923 [c02bfca2] schedule+0x632/0x640 [c02c0577] schedule_timeout+0x57/0xb0 [c011c100] process_timeout+0x0/0x10 [c011c378] msleep+0x28/0x30 [c883d0bb] rhine_disable_linkmon+0xab/0x130 [via_rhine] [c022f11f] do_con_write+0x22f/0x5a0 [c883d16f] mdio_read+0x2f/0xd0 [via_rhine] [c88348c4] generic_mii_ioctl+0x84/0x164 [mii] [c883e7b0] netdev_ioctl+0x0/0x80 [via_rhine] [c883e7fd] netdev_ioctl+0x4d/0x80 [via_rhine] [c025f764] dev_ifsioc+0x334/0x3a0 [c025f964] dev_ioctl+0x194/0x2a0 [c0254528] sock_ioctl+0xe8/0x1f0 [c01637de] do_ioctl+0x8e/0xa0 [c0163995] vfs_ioctl+0x65/0x1f0 [c0163b65] sys_ioctl+0x45/0x70 [c0102d55] syscall_call+0x7/0xb scheduling while atomic: mii-tool/0x0001/923 [c02bfca2] schedule+0x632/0x640 [c02c0577] schedule_timeout+0x57/0xb0 [c011c100] process_timeout+0x0/0x10 [c011c378] msleep+0x28/0x30 [c883d0bb] rhine_disable_linkmon+0xab/0x130 [via_rhine] [c022f11f] do_con_write+0x22f/0x5a0 [c883d16f] mdio_read+0x2f/0xd0 [via_rhine] [c88348c4] generic_mii_ioctl+0x84/0x164 [mii] [c883e7b0] netdev_ioctl+0x0/0x80 [via_rhine] [c883e7fd] netdev_ioctl+0x4d/0x80 [via_rhine] [c025f764] dev_ifsioc+0x334/0x3a0 [c025f964] dev_ioctl+0x194/0x2a0 [c0254528] sock_ioctl+0xe8/0x1f0 [c01637de] do_ioctl+0x8e/0xa0 [c0163995] vfs_ioctl+0x65/0x1f0 [c0163b65] sys_ioctl+0x45/0x70 [c0102d55] syscall_call+0x7/0xb scheduling while atomic: mii-tool/0x0001/923 [c02bfca2] schedule+0x632/0x640 [c02c0577] schedule_timeout+0x57/0xb0 [c011c100] process_timeout+0x0/0x10 [c011c378] msleep+0x28/0x30 [c883d0bb] rhine_disable_linkmon+0xab/0x130 [via_rhine] [c022f11f] do_con_write+0x22f/0x5a0 [c883d16f] mdio_read+0x2f/0xd0 [via_rhine] [c88348c4] generic_mii_ioctl+0x84/0x164 [mii] [c883e7b0] netdev_ioctl+0x0/0x80 [via_rhine] [c883e7fd] netdev_ioctl+0x4d/0x80 [via_rhine] [c025f764] dev_ifsioc+0x334/0x3a0 [c025f964] dev_ioctl+0x194/0x2a0 [c0254528] sock_ioctl+0xe8/0x1f0 [c01637de] do_ioctl+0x8e/0xa0 [c0163995] vfs_ioctl+0x65/0x1f0 [c0163b65] sys_ioctl+0x45/0x70 [c0102d55] syscall_call+0x7/0xb scheduling while atomic: mii-tool/0x0001/923 [c02bfca2] schedule+0x632/0x640 [c02c0577] schedule_timeout+0x57/0xb0 [c011c100] process_timeout+0x0/0x10 [c011c378] msleep+0x28/0x30 [c883d0bb] rhine_disable_linkmon+0xab/0x130 [via_rhine] [c022f11f] do_con_write+0x22f/0x5a0 [c883d16f] mdio_read+0x2f/0xd0 [via_rhine] [c88348c4] generic_mii_ioctl+0x84/0x164 [mii] [c883e7b0] netdev_ioctl+0x0/0x80 [via_rhine] [c883e7fd] netdev_ioctl+0x4d/0x80 [via_rhine] [c025f764] dev_ifsioc+0x334/0x3a0 [c025f964] dev_ioctl+0x194/0x2a0 [c0254528] sock_ioctl+0xe8/0x1f0 [c01637de] do_ioctl+0x8e/0xa0 [c0163995] vfs_ioctl+0x65/0x1f0 [c0163b65] sys_ioctl+0x45/0x70 [c0102d55] syscall_call+0x7/0xb scheduling while atomic: mii-tool/0x0001/923 [c02bfca2] schedule+0x632/0x640 [c02c0577] schedule_timeout+0x57/0xb0 [c011c100]
[patch] net/ieee80211: report hidden ESSIDs as zero-length, not hidden
hidden this is something that ieee80211 does that's completely wrong.
Drivers need to report the _exact_ ESSID from the air in their scan
results. It's up to the user space app to deal with ESSID length of 0.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
--- net/ieee80211/ieee80211_wx.c2006-03-24 10:43:04.0 -0500
+++ net/ieee80211/ieee80211_wx.c2006-03-24 10:53:27.0 -0500
@@ -64,8 +64,8 @@
iwe.cmd = SIOCGIWESSID;
iwe.u.data.flags = 1;
if (network-flags NETWORK_EMPTY_ESSID) {
- iwe.u.data.length = sizeof(hidden);
- start = iwe_stream_add_point(start, stop, iwe, hidden);
+ iwe.u.data.length = 0;
+ start = iwe_stream_add_point(start, stop, iwe, );
} else {
iwe.u.data.length = min(network-ssid_len, (u8) 32);
start = iwe_stream_add_point(start, stop, iwe, network-ssid);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: about cached dst in ip6_tunnel
Sorry the patch looks corrupted so I repost with attachment.
Jean-Mickael
--
[IPV6] ip6ip6_tnl_dst_check() : invalidate dst cache whenever xfrm
policies change
Signed-off-by: [EMAIL PROTECTED]
diff --git a/include/net/ip6_tunnel.h b/include/net/ip6_tunnel.h
index 29c9da7..5bc6e98 100644
--- a/include/net/ip6_tunnel.h
+++ b/include/net/ip6_tunnel.h
@@ -27,6 +27,7 @@ struct ip6_tnl {
struct flowi fl;/* flowi template for xmit */
struct dst_entry *dst_cache;/* cached dst */
u32 dst_cookie;
+ u32 fl_genid;
};
/* Tunnel encapsulation limit destination sub-option */
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 4859753..ded9c52 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -92,8 +92,9 @@ static inline struct dst_entry *ip6_tnl_
{
struct dst_entry *dst = t-dst_cache;
- if (dst dst-obsolete
- dst-ops-check(dst, t-dst_cookie) == NULL) {
+ if ((dst dst-obsolete
+ dst-ops-check(dst, t-dst_cookie) == NULL) ||
+ t-fl_genid != atomic_read(flow_cache_genid)) {
t-dst_cache = NULL;
dst_release(dst);
return NULL;
@@ -114,6 +115,7 @@ static inline void ip6_tnl_dst_store(str
t-dst_cookie = rt-rt6i_node ? rt-rt6i_node-fn_sernum : 0;
dst_release(t-dst_cache);
t-dst_cache = dst;
+ t-fl_genid = atomic_read(flow_cache_genid);
}
/**
Re: [SOFTMAC] Reduce default rate to 11Mbps.
On Thu, Mar 23, 2006 at 10:43:38PM +, David Woodhouse wrote: This patch makes us default to 11M, which ought to work for most people. Is this code supposed to work with IEEE 802.11a (which would also use OFDM modulation)? If yes, please note that 11 Mbps is not a valid IEEE 802.11a TX rate. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote: fixed it. Active scanning has been out of vogue as the default scan method for like 2 years with wireless-tools/WE, I'm not sure why softmac thinks it should be different here. Active scanning takes more power anyway, since you have to power up the card to transmit the probe requests. That's why wireless-tools and Wireless Extensions switched to passive scanning. Can you please point to some documentation/email thread/etc. describing this preference to use passive scanning? I was not aware of such a preference and have assumed that active scanning would be the preferred default because it is quite a bit faster and provides more complete results. I'd have issues with softmac doing active scanning unless _specifically_ requested to do so, by using the SIOCGIWMLME with a iw_scan_req structure requesting IW_SCAN_TYPE_ACTIVE. But _only_ then... Normal SIOCGIWSCAN shouldn't do active scanning. SIOCGIWSCAN does not request scanning, SIOCSIWSCAN does.. I don't understand what SIOCGIWMLME would have to do with this. SIOCSIWSCAN can use an optional iw_scan_req to control scan request. If this data is not present, I would assume that the drivers would do whatever they want and in many cases I would expect this to be active scan. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] net/ieee80211: report hidden ESSIDs as zero-length, nothidden
On Fri, Mar 24, 2006 at 10:57:22AM -0500, Dan Williams wrote: hidden this is something that ieee80211 does that's completely wrong. Drivers need to report the _exact_ ESSID from the air in their scan results. It's up to the user space app to deal with ESSID length of 0. I agree that hidden should not be used, but this is bit more complex than just reporting zero-length SSID. By the way, can we try to start getting rid of calling this ESSID; it's SSID and ESSID never made it to the IEEE 802.11 standard. Whatever component processes Probe Response frames, has to provide information from them to user space. If this is done in the kernel code, the BSS table should probably report multiple BSSID,SSID pairs even for the same BSSID in case of multi-SSID support in the AP. This is needed to handle cases where SSIDs use different security policy and this requires that active scan was used to probe for specific SSID(s). If this information is not available, reporting an empty SSID sounds like a good policy. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] set default max TCP buffers from memory pool size
This patch sets the maximum TCP buffer sizes (available to automatic buffer
tuning, not to setsockopt) based on the TCP memory pool size. The maximum
sndbuf and rcvbuf each will be up to 4 MB, but no more than 1/128 of the
memory pressure threshold.
Signed-off-by: John Heffner [EMAIL PROTECTED]
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 4b0272c..b7dc697 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -276,8 +276,8 @@ atomic_t tcp_orphan_count = ATOMIC_INIT(
EXPORT_SYMBOL_GPL(tcp_orphan_count);
int sysctl_tcp_mem[3];
-int sysctl_tcp_wmem[3] = { 4 * 1024, 16 * 1024, 128 * 1024 };
-int sysctl_tcp_rmem[3] = { 4 * 1024, 87380, 87380 * 2 };
+int sysctl_tcp_wmem[3];
+int sysctl_tcp_rmem[3];
EXPORT_SYMBOL(sysctl_tcp_mem);
EXPORT_SYMBOL(sysctl_tcp_rmem);
@@ -2081,7 +2081,7 @@ __setup(thash_entries=, set_thash_entr
void __init tcp_init(void)
{
struct sk_buff *skb = NULL;
- int order, i;
+ int order, i, max_share;
if (sizeof(struct tcp_skb_cb) sizeof(skb-cb))
__skb_cb_too_small_for_tcp(sizeof(struct tcp_skb_cb),
@@ -2154,13 +2154,16 @@ void __init tcp_init(void)
sysctl_tcp_mem[0] = 768 order;
sysctl_tcp_mem[1] = 1024 order;
sysctl_tcp_mem[2] = 1536 order;
-
- if (order 3) {
- sysctl_tcp_wmem[2] = 64 * 1024;
- sysctl_tcp_rmem[0] = PAGE_SIZE;
- sysctl_tcp_rmem[1] = 43689;
- sysctl_tcp_rmem[2] = 2 * 43689;
- }
+
+ max_share = min(4*1024*1024, sysctl_tcp_mem[1] (PAGE_SHIFT - 7));
+
+ sysctl_tcp_wmem[0] = SK_STREAM_MEM_QUANTUM;
+ sysctl_tcp_wmem[1] = 16*1024;
+ sysctl_tcp_wmem[2] = max(64*1024, max_share);
+
+ sysctl_tcp_rmem[0] = SK_STREAM_MEM_QUANTUM;
+ sysctl_tcp_rmem[1] = 87380;
+ sysctl_tcp_rmem[2] = max(87380, max_share);
printk(KERN_INFO TCP: Hash tables configured
(established %d bind %d)\n,
Re: [patch] net/ieee80211: report hidden ESSIDs as zero-length, not hidden
On Fri, 2006-03-24 at 10:57 -0500, Dan Williams wrote: hidden this is something that ieee80211 does that's completely wrong. Drivers need to report the _exact_ ESSID from the air in their scan results. It's up to the user space app to deal with ESSID length of 0. That makes a lot of sense. On a related note, I'm also seeing 'hidden' in the results when wpa_supplicant scans for a specific SSID. If it's a response to an SSID-specific probe, shouldn't ieee80211 be able to work out what the SSID should be? It's rejecting it because hidden doesn't match the SSID it probed for. (This is bcm43xx+softmac, but it's still the ieee80211 code which is handling the probe responses.) -- dwmw2 - To unsubscribe from this list: send the 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/ieee80211: report hidden ESSIDs as zero-length, not hidden
Dan Williams wrote:
hidden this is something that ieee80211 does that's completely wrong.
Because it is not a part of the 802.11 specification, AP vendors have
each implemented their own method for disguising the SSID. Some set the
length to the actual SSID length but put fill the SSID with '\0', some
set the length and SSID to a single space, some set the length to 0.
Since the scan results are supposed to report networks found; the first
agreement we need to make between user space and the kernel is how we
define a 'network', and how do we determine when a network has been
updated?
Take the following flow where you have an AP that supports two networks
on the same channel using the same MAC, but does not beacon a hidden
network if a non-hidden network also exists:
Indirect scan finds via probe request:
ssid_len=3, ssid=Foo, channel 1, BSSID: 00:0e:de:ad:be:ef
and via beacons:
ssid_len=3, ssid=Foo, channel 1, BSSID: 00:0e:de:ad:be:ef
The user configures the SSID to look for to be Bar.
A direct scan for 'Bar' is sent, and the following is found via probe
request:
ssid_len=3, ssid=Bar, channel 1, BSSID: 00:0e:de:ad:be:ef
and via beacons:
ssid_len=3, ssid=Foo, channel 1, BSSID: 00:0e:de:ad:be:ef
The network Bar is associated with, and time passes with no data or
probe requests being sent (idle network). Beacons are received for Foo,
but nothing for Bar (since the AP isn't beaconing hidden networks).
Now you look for scan results with an indirect scan, and you will only see:
ssid_len=3, ssid=Foo, channel 1, BSSID: 00:0e:de:ad:be:ef
Aside from the probe response for Bar, there are never any beacons that
indicate that the network Bar still exists. Scan results *should*
display Foo and Bar, but the current ieee80211 subsystem will filter out
Bar once 15s has passed without receiving a probe response.
Currently ieee80211 does not differentiate between probe responses and
beacons for collecting network data. To fix the problem we have now,
ieee80211 needs to be changed to be able to distinguish between probe
respones and beacons, and update all networks that match channel and MAC
when a beacon is received (regardless of SSID) and update a specific
network if the frame is a probe response.
If the above change is made, we can perhaps remove all knowledge of a
hidden vs. broadcast network from the drivers and ieee80211 subsystem.
Drivers need to report the _exact_ ESSID from the air in their scan
results. It's up to the user space app to deal with ESSID length of 0.
Agree the kernel should pass the SSID as received.
Ideally user space should just register to receive all beacons and probe
responses from the network device and do all the parsing and network
management, with a timing interval specified for frequency to receive
beacons/probe responses that have not changed (although one packet every
100ms isn't likely to cause too much thrash)
Exporting the entire frame allows user space to provide information on
802.11h, 802.11e, 802.11i and other network capabilities that currently
aren't exposed via the wireless extension interface.
Doing this also has the advantage of being able to remove all scan and
network collection logistics out of the kernel and into user space.
In light of the above, I started playing with a raw packet interface on
the ipw2200 and ipw3945 projects that export all frames to user space in
radiotap format through a 2nd network device. I am working on changing
the way the raw packet interface is configured to be via netlink (vs. a
sysfs entry) but you can apply it to ipw2200-1.1.1 via
http://ipw2200.sf.net/ipw2200-1.1.1-rtap_iface.patch if interested.
Signed-off-by: Dan Williams [EMAIL PROTECTED]
--- net/ieee80211/ieee80211_wx.c 2006-03-24 10:43:04.0 -0500
+++ net/ieee80211/ieee80211_wx.c 2006-03-24 10:53:27.0 -0500
@@ -64,8 +64,8 @@
iwe.cmd = SIOCGIWESSID;
iwe.u.data.flags = 1;
if (network-flags NETWORK_EMPTY_ESSID) {
- iwe.u.data.length = sizeof(hidden);
- start = iwe_stream_add_point(start, stop, iwe, hidden);
+ iwe.u.data.length = 0;
+ start = iwe_stream_add_point(start, stop, iwe, );
} else {
iwe.u.data.length = min(network-ssid_len, (u8) 32);
start = iwe_stream_add_point(start, stop, iwe, network-ssid);
See (untested) attached to change ieee80211 to expose the SSID as received.
James
ieee80211: Change _rx and _wx to export full SSIDs as received over air
This patch modifies the frame parsing code to copy the contents of a
hidden network's SSID information element as well as modify the
wireless extension handler for providing that information to user space.
With this patch applied, no hidden network string will be returned
to user space -- it is up to user space to determine if a network is
hidden or not.
Signed-off-by: James Ketrenos [EMAIL PROTECTED]
---
ieee80211/ieee80211_rx.c |4 +---
[2.6 patch] PCMCIA_SPECTRUM must select FW_LOADER
On Fri, Mar 24, 2006 at 09:36:09PM +0500, Alexander E. Patrakov wrote: In linux-2.6.16, it is possible to compile spectrum_cs.ko without enabling firmware loader. Result: WARNING: /lib/modules/2.6.16/kernel/drivers/net/wireless/spectrum_cs.ko needs unknown symbol request_firmware Thanks for your report, a fix is below. Alexander E. Patrakov cu Adrian -- snip -- PCMCIA_SPECTRUM must select FW_LOADER. Reported by Alexander E. Patrakov [EMAIL PROTECTED]. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- linux-2.6.16-mm1-full/drivers/net/wireless/Kconfig.old 2006-03-24 17:45:05.0 +0100 +++ linux-2.6.16-mm1-full/drivers/net/wireless/Kconfig 2006-03-24 17:45:38.0 +0100 @@ -397,6 +397,7 @@ config PCMCIA_SPECTRUM tristate Symbol Spectrum24 Trilogy PCMCIA card support depends on NET_RADIO PCMCIA HERMES + select FW_LOADER ---help--- This is a driver for 802.11b cards using RAM-loadable Symbol - To unsubscribe from this list: send the 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/ieee80211: report hidden ESSIDs as zero-length, not hidden
On Fri, 2006-03-24 at 11:05 -0600, James Ketrenos wrote: Dan Williams wrote: hidden this is something that ieee80211 does that's completely wrong. See (untested) attached to change ieee80211 to expose the SSID as received. Patch looks good to me in principle. All I'm objecting to is the hidden when that's not actually what the network is calling itself. Dan - To unsubscribe from this list: send the 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] set default max TCP buffers from memory pool size
On Fri, 24 Mar 2006 11:47:29 -0500 John Heffner [EMAIL PROTECTED] wrote: This patch sets the maximum TCP buffer sizes (available to automatic buffer tuning, not to setsockopt) based on the TCP memory pool size. The maximum sndbuf and rcvbuf each will be up to 4 MB, but no more than 1/128 of the memory pressure threshold. Signed-off-by: John Heffner [EMAIL PROTECTED] We should also tag tcp_rmem/tcp_wmem as __read_mostly - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sky2: hangs on 2.6.16
transfer of data hangs with sky2 very often on a :02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast Ethernet Controller (rev 10) found on toshiba laptops, when using 2.6.16, which proves a critical problem since the proprietary driver does not support .16 at the moment. debug=16 doesn't produce any info I can understand, most of it looks like .. eth0: tx queued, slot 15, len 78 sky2 eth0: rx slot 3 status 0x4e0100 len 78 .. before, during, and after transfer of data stops. let me know if you need that full data or anything else that may help. thanks. ps. please cc me any replies - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2: hangs on 2.6.16
On Fri, 24 Mar 2006 17:14:49 +
michael [EMAIL PROTECTED] wrote:
transfer of data hangs with sky2 very often on a
:02:00.0 Ethernet controller: Marvell Technology Group
Ltd. 88E8036 Fast Ethernet Controller (rev 10)
found on toshiba laptops,
when using 2.6.16, which proves a critical problem since the proprietary
driver does not support .16 at the moment.
debug=16 doesn't produce any info I can understand, most of it looks
like
..
eth0: tx queued, slot 15, len 78
sky2 eth0: rx slot 3 status 0x4e0100 len 78
..
before, during, and after transfer of data stops.
let me know if you need that full data or anything else that may help.
thanks.
ps. please cc me any replies
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
I sent an update post 2.6.16 that should fix most of these problems.
or try this which is the important bit. Unfortunately, I may have to bend
the rules to get this in for -stable.
--- linux-2.6.16/drivers/net/sky2.c.orig2006-03-24 09:36:42.0
-0800
+++ linux-2.6.16/drivers/net/sky2.c 2006-03-24 09:36:51.0 -0800
@@ -96,6 +96,10 @@ static int copybreak __read_mostly = 256
module_param(copybreak, int, 0);
MODULE_PARM_DESC(copybreak, Receive copy threshold);
+static int disable_msi = 0;
+module_param(disable_msi, int, 0);
+MODULE_PARM_DESC(disable_msi, Disable Message Signaled Interrupt (MSI));
+
static const struct pci_device_id sky2_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, 0x9000) },
{ PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, 0x9E00) },
@@ -504,9 +508,9 @@ static void sky2_phy_init(struct sky2_hw
/* Force a renegotiation */
static void sky2_phy_reinit(struct sky2_port *sky2)
{
- down(sky2-phy_sema);
+ spin_lock_bh(sky2-phy_lock);
sky2_phy_init(sky2-hw, sky2-port);
- up(sky2-phy_sema);
+ spin_unlock_bh(sky2-phy_lock);
}
static void sky2_mac_init(struct sky2_hw *hw, unsigned port)
@@ -571,9 +575,9 @@ static void sky2_mac_init(struct sky2_hw
sky2_read16(hw, SK_REG(port, GMAC_IRQ_SRC));
- down(sky2-phy_sema);
+ spin_lock_bh(sky2-phy_lock);
sky2_phy_init(hw, port);
- up(sky2-phy_sema);
+ spin_unlock_bh(sky2-phy_lock);
/* MIB clear */
reg = gma_read16(hw, port, GM_PHY_ADDR);
@@ -886,9 +890,9 @@ static int sky2_ioctl(struct net_device
case SIOCGMIIREG: {
u16 val = 0;
- down(sky2-phy_sema);
+ spin_lock_bh(sky2-phy_lock);
err = __gm_phy_read(hw, sky2-port, data-reg_num 0x1f, val);
- up(sky2-phy_sema);
+ spin_unlock_bh(sky2-phy_lock);
data-val_out = val;
break;
@@ -898,10 +902,10 @@ static int sky2_ioctl(struct net_device
if (!capable(CAP_NET_ADMIN))
return -EPERM;
- down(sky2-phy_sema);
+ spin_lock_bh(sky2-phy_lock);
err = gm_phy_write(hw, sky2-port, data-reg_num 0x1f,
data-val_in);
- up(sky2-phy_sema);
+ spin_unlock_bh(sky2-phy_lock);
break;
}
return err;
@@ -1014,7 +1018,7 @@ static int sky2_up(struct net_device *de
struct sky2_port *sky2 = netdev_priv(dev);
struct sky2_hw *hw = sky2-hw;
unsigned port = sky2-port;
- u32 ramsize, rxspace;
+ u32 ramsize, rxspace, imask;
int err = -ENOMEM;
if (netif_msg_ifup(sky2))
@@ -1079,10 +1083,10 @@ static int sky2_up(struct net_device *de
goto err_out;
/* Enable interrupts from phy/mac for port */
- spin_lock_irq(hw-hw_lock);
- hw-intr_mask |= (port == 0) ? Y2_IS_PORT_1 : Y2_IS_PORT_2;
- sky2_write32(hw, B0_IMSK, hw-intr_mask);
- spin_unlock_irq(hw-hw_lock);
+ imask = sky2_read32(hw, B0_IMSK);
+ imask |= (port == 0) ? Y2_IS_PORT_1 : Y2_IS_PORT_2;
+ sky2_write32(hw, B0_IMSK, imask);
+
return 0;
err_out:
@@ -1375,6 +1379,7 @@ static int sky2_down(struct net_device *
struct sky2_hw *hw = sky2-hw;
unsigned port = sky2-port;
u16 ctrl;
+ u32 imask;
/* Never really got started! */
if (!sky2-tx_le)
@@ -1386,14 +1391,6 @@ static int sky2_down(struct net_device *
/* Stop more packets from being queued */
netif_stop_queue(dev);
- /* Disable port IRQ */
- spin_lock_irq(hw-hw_lock);
- hw-intr_mask = ~((sky2-port == 0) ? Y2_IS_IRQ_PHY1 : Y2_IS_IRQ_PHY2);
- sky2_write32(hw, B0_IMSK, hw-intr_mask);
- spin_unlock_irq(hw-hw_lock);
-
- flush_scheduled_work();
-
sky2_phy_reset(hw, port);
/* Stop transmitter */
@@ -1437,6 +1434,11 @@ static int sky2_down(struct net_device *
Re: [patch] net/ieee80211: report hidden ESSIDs as zero-length, not hidden
On Fri, Mar 24, 2006 at 11:05:02AM -0600, James Ketrenos wrote: Since the scan results are supposed to report networks found; the first agreement we need to make between user space and the kernel is how we define a 'network', and how do we determine when a network has been updated? Whenever a frame for matching BSSID is received(?) A direct scan for 'Bar' is sent, and the following is found via probe request: ssid_len=3, ssid=Bar, channel 1, BSSID: 00:0e:de:ad:be:ef and via beacons: ssid_len=3, ssid=Foo, channel 1, BSSID: 00:0e:de:ad:be:ef The network Bar is associated with, and time passes with no data or probe requests being sent (idle network). Beacons are received for Foo, but nothing for Bar (since the AP isn't beaconing hidden networks). Aside from the probe response for Bar, there are never any beacons that indicate that the network Bar still exists. Scan results *should* display Foo and Bar, but the current ieee80211 subsystem will filter out Bar once 15s has passed without receiving a probe response. Yes, I would like to see both Foo and Bar being reported to user space and neither should be timed out as long as Beacon frames are received for the shared BSSID. Currently ieee80211 does not differentiate between probe responses and beacons for collecting network data. To fix the problem we have now, ieee80211 needs to be changed to be able to distinguish between probe respones and beacons, and update all networks that match channel and MAC when a beacon is received (regardless of SSID) and update a specific network if the frame is a probe response. Agreed. Ideally user space should just register to receive all beacons and probe responses from the network device and do all the parsing and network management, with a timing interval specified for frequency to receive beacons/probe responses that have not changed (although one packet every 100ms isn't likely to cause too much thrash) Exporting the entire frame allows user space to provide information on 802.11h, 802.11e, 802.11i and other network capabilities that currently aren't exposed via the wireless extension interface. This is something I would like to see happening at least as an option. It would be useful to be able to replace all management frame processing by user space mechanism. This is exactly what hostapd does for AP mode with Host AP driver and Devicescape 802.11 code. Similar mechanism would be nice to have for client mode. Timing requirements for 802.11 management frames are not too strict (with a potential exception with Probe Response, but even that seems to work quite well on Linux when done from user space), so they can be easily handled in user space. Implementing things like 802.11r will be quite a bit easier if both the management frames (authentication, association) and EAPOL frames can be taken care of by the same component. Otherwise, large number of new kernel - user space interfaces will be needed for adding IEs and interacting with roaming and association. Doing this also has the advantage of being able to remove all scan and network collection logistics out of the kernel and into user space. Agreed. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Fri, 2006-03-24 at 08:28 -0800, Jouni Malinen wrote: On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote: fixed it. Active scanning has been out of vogue as the default scan method for like 2 years with wireless-tools/WE, I'm not sure why softmac thinks it should be different here. Active scanning takes more power anyway, since you have to power up the card to transmit the probe requests. That's why wireless-tools and Wireless Extensions switched to passive scanning. Can you please point to some documentation/email thread/etc. describing this preference to use passive scanning? I was not aware of such a preference and have assumed that active scanning would be the preferred default because it is quite a bit faster and provides more complete results. I'd have issues with softmac doing active scanning unless _specifically_ requested to do so, by using the SIOCGIWMLME with a iw_scan_req structure requesting IW_SCAN_TYPE_ACTIVE. But _only_ then... Normal SIOCGIWSCAN shouldn't do active scanning. SIOCGIWSCAN does not request scanning, SIOCSIWSCAN does.. I don't Right, typo on my part. Had considered sending mail correcting this, but that would have been pointless for 1 word. understand what SIOCGIWMLME would have to do with this. SIOCSIWSCAN can use an optional iw_scan_req to control scan request. If this data is not present, I would assume that the drivers would do whatever they want and in many cases I would expect this to be active scan. My fault here too. In my quick reading of wireless.h, I confused some of the comments regarding iw_scan_req and SIOCSIWSCAN. So you're correct here, that iw_scan_req should be used with SIOCSIWSCAN, and my comments about MLME are wrong. However, the problem with active scanning is that you have to power up the transmit components of the radio, while passive scanning, even though it takes a bit longer, doesn't necessarily require that. Active scanning takes more power. So what I'm arguing for here is that drivers should _default_ to passive scanning when given a scan request with no scan type information. But they should be able to do so when they get a request for an active scan using IW_SCAN_TYPE_ACTIVE. Drivers should default to using less power, and more only when the app requests so. However: It's somewhat unfortunate that wireless.h defines ACTIVE scan type as 0 since then, that's what non-WE-18 apps would inadvertently set. And apps that are power-aware would be setting that bit anyway. Most drivers that are FullMAC do passive scanning without sending probe requests, AFAIK, and so do OK here. In short, since WE already defines ACTIVE to be 0, and we're not going to change that, consider my arguments here withdrawn. We should just note that if an application wants the card to be power-conservative, that the _app_ needs to set the correct bits in the scan. Were ACTIVE defined as 1, the story would be different, but it's not. So be it. Dan - To unsubscribe from this list: send the 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] set default max TCP buffers from memory pool size
Stephen Hemminger wrote: On Fri, 24 Mar 2006 11:47:29 -0500 John Heffner [EMAIL PROTECTED] wrote: This patch sets the maximum TCP buffer sizes (available to automatic buffer tuning, not to setsockopt) based on the TCP memory pool size. The maximum sndbuf and rcvbuf each will be up to 4 MB, but no more than 1/128 of the memory pressure threshold. Signed-off-by: John Heffner [EMAIL PROTECTED] We should also tag tcp_rmem/tcp_wmem as __read_mostly That would apply to just about all the tcp sysctl's yes? rick jones - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] net/ieee80211: report hidden ESSIDs as zero-length, not hidden
James Ketrenos wrote: In light of the above, I started playing with a raw packet interface on the ipw2200 and ipw3945 projects that export all frames to user space in radiotap format through a 2nd network device. I am working on changing the way the raw packet interface is configured to be via netlink (vs. a sysfs entry) but you can apply it to ipw2200-1.1.1 via http://ipw2200.sf.net/ipw2200-1.1.1-rtap_iface.patch if interested. Brain/computer short http://ipw2200.sf.net/patches/ipw2200-1.1.1-rtap_iface.patch (I missed /patches/ in the URL) Thanks, James - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Fri, Mar 24, 2006 at 12:38:40PM -0500, Dan Williams wrote: However, the problem with active scanning is that you have to power up the transmit components of the radio, while passive scanning, even though it takes a bit longer, doesn't necessarily require that. Active scanning takes more power. For some class of devices, that is certainly correct. For other classes, it does not really matter much (e.g., my laptop has large enough battery for me not to care about active scan). So what I'm arguing for here is that drivers should _default_ to passive scanning when given a scan request with no scan type information. But they should be able to do so when they get a request for an active scan using IW_SCAN_TYPE_ACTIVE. Drivers should default to using less power, and more only when the app requests so. Is battery use more important than accuracy of results and the amount of time needed to perform the operation? It's somewhat unfortunate that wireless.h defines ACTIVE scan type as 0 since then, that's what non-WE-18 apps would inadvertently set. And apps that are power-aware would be setting that bit anyway. Most drivers that are FullMAC do passive scanning without sending probe requests, AFAIK, and so do OK here. Please note that this field is in struct iw_scan_req and non-WE-18 apps do not know about that in the first place. In other words, it does not really matter what the value of IW_SCAN_TYPE_ACTIVE is.. The only open question I see here is what should happen if struct iw_scan_req is not included and my current understanding is that the driver is allowed to do either active or passive scanning based on its default and I just happen to think that the default would more likely be active scanning unless somehow (driver specific parameter) it has been modified to do something else. Have you actually observed that FullMAC drivers are using passive scanning (i.e., used a wireless sniffer to see what they are doing)? Most drivers I've looked at at this level are sending out probe request frames.. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2: hangs on 2.6.16
On Fri, Mar 24, 2006 at 09:38:44AM -0800, Stephen Hemminger wrote: On Fri, 24 Mar 2006 17:14:49 + michael [EMAIL PROTECTED] wrote: transfer of data hangs with sky2 very often on a :02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast Ethernet Controller (rev 10) found on toshiba laptops, when using 2.6.16, which proves a critical problem since the proprietary driver does not support .16 at the moment. debug=16 doesn't produce any info I can understand, most of it looks like .. eth0: tx queued, slot 15, len 78 sky2 eth0: rx slot 3 status 0x4e0100 len 78 .. before, during, and after transfer of data stops. let me know if you need that full data or anything else that may help. thanks. ps. please cc me any replies - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html I sent an update post 2.6.16 that should fix most of these problems. or try this which is the important bit. Unfortunately, I may have to bend the rules to get this in for -stable. Maybe the hang I notice is different because it stays with this patch and appears primarily after using multiple connections. An easy way to reproduce it here is this axel -n 40 http://..file (a downloader that opens 40 connections) it will go on downloading normally without problem. If I ctrl-c that process and immediately re-run it, it will not start again (or any other internet connection). rmmod, modprobe and reconfiguring the iface brings it back to normal. I haven't checked if all those 40 connections are opened or at some point it doesn't open more than 10 or sth. Let me know if I can help somehow further. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2: hangs on 2.6.16
On Fri, 24 Mar 2006 18:18:57 + michael [EMAIL PROTECTED] wrote: On Fri, Mar 24, 2006 at 09:38:44AM -0800, Stephen Hemminger wrote: On Fri, 24 Mar 2006 17:14:49 + michael [EMAIL PROTECTED] wrote: transfer of data hangs with sky2 very often on a :02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8036 Fast Ethernet Controller (rev 10) found on toshiba laptops, when using 2.6.16, which proves a critical problem since the proprietary driver does not support .16 at the moment. debug=16 doesn't produce any info I can understand, most of it looks like .. eth0: tx queued, slot 15, len 78 sky2 eth0: rx slot 3 status 0x4e0100 len 78 .. before, during, and after transfer of data stops. let me know if you need that full data or anything else that may help. thanks. ps. please cc me any replies - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html I sent an update post 2.6.16 that should fix most of these problems. or try this which is the important bit. Unfortunately, I may have to bend the rules to get this in for -stable. Maybe the hang I notice is different because it stays with this patch and appears primarily after using multiple connections. An easy way to reproduce it here is this axel -n 40 http://..file (a downloader that opens 40 connections) it will go on downloading normally without problem. If I ctrl-c that process and immediately re-run it, it will not start again (or any other internet connection). rmmod, modprobe and reconfiguring the iface brings it back to normal. I haven't checked if all those 40 connections are opened or at some point it doesn't open more than 10 or sth. Let me know if I can help somehow further. How far away is the site you are downloading from. Perhaps it just means you have lots of connections open, and the memory is getting low. I can't reproduce it here (downloading from kernel.org on P4 with motherboard chip and 2.6.16-git latest). But I have 2G of memory. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2: hangs on 2.6.16
On Fri, Mar 24, 2006 at 10:40:00AM -0800, Stephen Hemminger wrote: Maybe the hang I notice is different because it stays with this patch and appears primarily after using multiple connections. An easy way to reproduce it here is this axel -n 40 http://..file (a downloader that opens 40 connections) it will go on downloading normally without problem. If I ctrl-c that process and immediately re-run it, it will not start again (or any other internet connection). rmmod, modprobe and reconfiguring the iface brings it back to normal. I haven't checked if all those 40 connections are opened or at some point it doesn't open more than 10 or sth. Let me know if I can help somehow further. How far away is the site you are downloading from. Perhaps it just means you have lots of connections open, and the memory is getting low. I can't reproduce it here (downloading from kernel.org on P4 with motherboard chip and 2.6.16-git latest). But I have 2G of memory. The problem doesn't appear with the proprietary driver on .15 on the same sites. Basically, when the hang happens I can't open an inet connection without rmmod, modprobe, iface reconfiguration. I have 1.5gb. - To unsubscribe from this list: send the 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] new qla3xxx NIC Driver v2.02.00b01
* Use existing MII code and interface Do you mean support for the get/set IOCTLS SIOCGMIIREG/SIOCSMIIREG? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Two comments on the H.323 conntrack/NAT helper
- Original Message - From: Patrick McHardy [EMAIL PROTECTED] To: Adrian Bunk [EMAIL PROTECTED] Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Jing Min Zhao [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Sent: Thursday, March 23, 2006 9:02 PM Subject: Re: Two comments on the H.323 conntrack/NAT helper [The hotmail address of the author doesn't work, CCed sourceforge-address] Adrian Bunk wrote: Two comments on the H.323 conntrack/NAT helper: - the function prototypes in ip_nat_helper_h323.c are _ugly_, please move them to a header file Their ugliness is because of the current API, which cleaned up quite a lot of the surrounding code, but requires this ugliness from each helper. I would like to keep them visible as a reminder that a cleaner solution is wanted, but moving them to header files certainly sound like a good idea to eliminate the risk of prototype conflicts. But please do this for all helpers at once. - is there a reason for not using EXPORT_SYMBOL_GPL? I would prefer that too. I've moved those prototypes. But the move involves moving of two header files: ip_conntrack_helper_h323_asn1.h and ip_conntrack_helper_h323_types.h. This is because ip_conntrack_h323.h now has to include ip_conntrack_helper_h323_asn1.h and thus ip_conntrack_helper_h323_types.h, so they are moved from net/ipv4/netfilter/ to include/linux/netfilter_ipv4/ to make sure other header files like ip_conntrack_h323.h and ip_conntrack.h be able to find them. Is this ok or you have a better idea? Thanks a lot! Jing Min Zhao - To unsubscribe from this list: send the 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] new qla3xxx NIC Driver v2.02.00b01
On Fri, 24 Mar 2006 10:58:44 -0800 Ron Mercer [EMAIL PROTECTED] wrote: * Use existing MII code and interface Do you mean support for the get/set IOCTLS SIOCGMIIREG/SIOCSMIIREG? If you can look at using mii.c and include/linux/mii.h. Not all drivers can, and the interface is poorly documented and not that up to date, but it is easier to use existing code. There is also drivers/net/phy and include/linux/phy.h as another alternative. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2: hangs on 2.6.16
On Fri, 24 Mar 2006 18:48:37 + fs [EMAIL PROTECTED] wrote: On Fri, Mar 24, 2006 at 10:40:00AM -0800, Stephen Hemminger wrote: Maybe the hang I notice is different because it stays with this patch and appears primarily after using multiple connections. An easy way to reproduce it here is this axel -n 40 http://..file (a downloader that opens 40 connections) it will go on downloading normally without problem. If I ctrl-c that process and immediately re-run it, it will not start again (or any other internet connection). rmmod, modprobe and reconfiguring the iface brings it back to normal. I haven't checked if all those 40 connections are opened or at some point it doesn't open more than 10 or sth. Let me know if I can help somehow further. How far away is the site you are downloading from. Perhaps it just means you have lots of connections open, and the memory is getting low. I can't reproduce it here (downloading from kernel.org on P4 with motherboard chip and 2.6.16-git latest). But I have 2G of memory. The problem doesn't appear with the proprietary driver on .15 on the same sites. Basically, when the hang happens I can't open an inet connection without rmmod, modprobe, iface reconfiguration. I have 1.5gb. Do you see anything on the console log (dmesg) like transmit timeouts? or allocation failures? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2: hangs on 2.6.16
On Fri, Mar 24, 2006 at 11:24:35AM -0800, Stephen Hemminger wrote: On Fri, 24 Mar 2006 18:48:37 + fs [EMAIL PROTECTED] wrote: On Fri, Mar 24, 2006 at 10:40:00AM -0800, Stephen Hemminger wrote: Maybe the hang I notice is different because it stays with this patch and appears primarily after using multiple connections. An easy way to reproduce it here is this axel -n 40 http://..file (a downloader that opens 40 connections) it will go on downloading normally without problem. If I ctrl-c that process and immediately re-run it, it will not start again (or any other internet connection). rmmod, modprobe and reconfiguring the iface brings it back to normal. I haven't checked if all those 40 connections are opened or at some point it doesn't open more than 10 or sth. Let me know if I can help somehow further. How far away is the site you are downloading from. Perhaps it just means you have lots of connections open, and the memory is getting low. I can't reproduce it here (downloading from kernel.org on P4 with motherboard chip and 2.6.16-git latest). But I have 2G of memory. The problem doesn't appear with the proprietary driver on .15 on the same sites. Basically, when the hang happens I can't open an inet connection without rmmod, modprobe, iface reconfiguration. I have 1.5gb. Do you see anything on the console log (dmesg) like transmit timeouts? or allocation failures? no, nothing out of the ordinary on dmesg. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [patch] net/ieee80211: report hidden ESSIDs as zero-length, not
Jouni Malinen wrote :
On Fri, Mar 24, 2006 at 10:57:22AM -0500, Dan Williams wrote:
hidden this is something that ieee80211 does that's completely wrong.
Drivers need to report the _exact_ ESSID from the air in their scan
results. It's up to the user space app to deal with ESSID length of 0.
I agree that hidden should not be used, but this is bit more complex
than just reporting zero-length SSID.
The Wireless Extension API has the notion of absent ESSID as
opposed to zero-length ESSID. Maybe we could use that ?
The patch would look like (totally untested) :
--- net/ieee80211/ieee80211_wx.c2006-03-24 10:43:04.0 -0500
+++ net/ieee80211/ieee80211_wx.c2006-03-24 10:53:27.0 -0500
@@ -64,8 +64,8 @@
iwe.cmd = SIOCGIWESSID;
iwe.u.data.flags = 1;
if (network-flags NETWORK_EMPTY_ESSID) {
- iwe.u.data.length = sizeof(hidden);
- start = iwe_stream_add_point(start, stop, iwe, hidden);
+ iwe.u.data.flags = 1; /* Hidden ESSID */
+ iwe.u.data.length = 0;
+ start = iwe_stream_add_point(start, stop, iwe, );
} else {
iwe.u.data.length = min(network-ssid_len, (u8) 32);
start = iwe_stream_add_point(start, stop, iwe, network-ssid);
If you want, I can change the source of iwlist.c to mention
'hidden' explicitely.
The other suggestions all look good to me...
By the way, can we try to start
getting rid of calling this ESSID; it's SSID and ESSID never made it to
the IEEE 802.11 standard.
I've seen time where people said SSID when referring to the
BSSID, so I just wanted the terminology to be without ambiguity.
James Ketrenos wrote :
Since the scan results are supposed to report networks found; the first
agreement we need to make between user space and the kernel is how we
define a 'network', and how do we determine when a network has been
updated?
[...]
Currently ieee80211 does not differentiate between probe responses and
beacons for collecting network data. To fix the problem we have now,
ieee80211 needs to be changed to be able to distinguish between probe
respones and beacons, and update all networks that match channel and MAC
when a beacon is received (regardless of SSID) and update a specific
network if the frame is a probe response.
The problem of trying to keep probe response for longer period
of time is that they may no longer be valid. As you roam around,
things need to timeout/expire because they are no longer reachable.
But, before going into deep technical discussions, we may want
to remind us what is the goal of this API. The goal is to present the
user a list of potential networks that can be used by him, in the case
he doesn't want to associate with a specific network. Not all
associations need it, it's a convenience feature for finding open
networks.
The network that don't send beacon do so to cloak themselves,
i.e. they don't want random joe to access them. If they don't want to
advertise themselves, the user don't really need to know about them,
therefore it's acceptable to not show them in a scan result.
If the user know about this network via other means, he can
still associate with it by entering manually the ESSID. And you you
really want to know the exhaustive list of networks around, please use
kismet.
The only thing debatable is about the current associated
network, in case it's cloaked. This network has already been
discovered (we are associated with it), therefore the user does not
really require to see it in scan results, however it would be nice for
completness.
Ideally user space should just register to receive all beacons and probe
responses from the network device and do all the parsing and network
management
We may get there one day, but it will take time. That would be
the most simple and efficient API. Note that some old hardware would
not allow that.
Have fun...
Jean
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [SOFTMAC] Reduce scan dwell time
Jouni Malinen wrote : On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote: That's why wireless-tools and Wireless Extensions switched to passive scanning. Can you please point to some documentation/email thread/etc. describing this preference to use passive scanning? I was not aware of such a preference and have assumed that active scanning would be the preferred default because it is quite a bit faster and provides more complete results. I was scratchig my head over that one, I'm glad I'm not the only one. Prior to WE-18, the API did not specify anything, so it was left to the discretion of the driver/card. With WE-18, you can specify what you want, but most apps don't, so effectively we are in the pre-WE-18 situation. I think that active scanning is preferred is most case because it's faster. The power issue is likely overblown, as scanning doesn't occur that frequently and generate a minimal number of packets. If scanning had a real impact on power, it would have the same impact on throughput, and people would complain about it (I almost wrote a paper on the parallel between power and throughput optimisation). The first type of card are cards that do scanning in the background. Thos cards need to interrupt traffic on a periodic basis to perform scanning, the less time they spend scanning, the less impact it will have on throughput and latency. If the card detect that there is no traffic, it could use passice scanning. The second type of card are cards that don't do scanning in the background. In that case, scanning is triggered at the time of the request, and both the user and the app are waiting for the result (well, except those wasteful apps that do periodic scans). You don't want the user to wait. Jouni Malinen wrote : On Fri, Mar 24, 2006 at 12:38:40PM -0500, Dan Williams wrote: However, the problem with active scanning is that you have to power up the transmit components of the radio, while passive scanning, even though it takes a bit longer, doesn't necessarily require that. Active scanning takes more power. For some class of devices, that is certainly correct. For other classes, it does not really matter much (e.g., my laptop has large enough battery for me not to care about active scan). Thinking about it some more... In most cards, the difference of power consumption between Tx and Rx is not that much, less than an order of magnitude. Unfortunately, my link to number is 404. If you do active scanning, you are done much faster and thefore can switch your receiver off and go back to full power saving much earlier. Which means that you may actually consume less power... Let pull hypothetical numbers, for the sake of the argument, let say Tx = 1W, Rx = 200mW, idle = 20mW. Let say active scanning is 20ms per channel (2ms Tx, 18ms Rx), passive scanning is 200ms per channel. Let say we scan 10 channels. Over a 2 sec period, active scanning is 72mW. Over a 2 sec period, passive scanning is 200mW. Actually, it's a well known fact that in wireless networking, it's not Tx that kill your battery, but Rx. Have fun... Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] net/ieee80211: report hidden ESSIDs as zero-length, not
On Fri, Mar 24, 2006 at 11:41:14AM -0800, Jean Tourrilhes wrote: I've seen time where people said SSID when referring to the BSSID, so I just wanted the terminology to be without ambiguity. Well.. It is just somewhat funny to see ESSID being used in Linux wireless discussion when most other areas are using the correct term, SSID. I would assume that wireless.h and iwconfig documentation are the main reasons for this.. ;-) The problem of trying to keep probe response for longer period of time is that they may no longer be valid. As you roam around, things need to timeout/expire because they are no longer reachable. If beacon frames are received for the same BSSID, the probe responses are very likely still valid. The only thing expiring them would be configuration change in the AP.. But, before going into deep technical discussions, we may want to remind us what is the goal of this API. The goal is to present the user a list of potential networks that can be used by him, in the case he doesn't want to associate with a specific network. Not all associations need it, it's a convenience feature for finding open networks. It is also convenient for figuring out security policy for closed networks.. The network that don't send beacon do so to cloak themselves, Or to support multiple SSIDs with radios that cannot use multiple BSSIDs.. If the user know about this network via other means, he can still associate with it by entering manually the ESSID. This would work if there is only one hidden SSID. However, if there are more than one, it may be useful to be able to scan (without associating) multiple SSIDs. This was one of the reason for adding scan parameters in WE-18. The only thing debatable is about the current associated network, in case it's cloaked. This network has already been discovered (we are associated with it), therefore the user does not really require to see it in scan results, however it would be nice for completness. Maybe not in scan results, but the same parameters have to be available for WPA supplicant and fetching them from scan results is one convenient mechanism. In other words, proper WPA/WPA2 validation of WPA/RSN IEs requires that the Beacon/ProbeResp IEs are available for the current AP. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6-softmac patch: prism54usb update
On Fri, 24 Mar 2006 08:15:24 -0500, John W. Linville [EMAIL PROTECTED] wrote: Yes, sorry. I renamed the softmac branch as devel -- it has the stuff that was on the softmac branch, other than softmac component itself. Aww dang, I already sent it to you diffed against master. With softmac merged, I think we should start getting softmac-based drivers reviewed and merged. If it is basically functional, I think it is probably worth consideration. If that is the criteria, then no, it's not ready. But I'd like your tree to have the freqently updated head version, because right now the patch is 350KB, and it was just one month of work! Would you just keep it on master without pushing to Linus? They way you manipulate branches of wireless-2.6 is bewildering for me, and softmac branch was updated very infrequently. It's something Greg Kroah does with his USB trees: experimental stuff gets staged there. When I get /pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-04-usb, I receive everything neatly packed together. No branches... -- Pete - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [SOFTMAC] Reduce scan dwell time
On Fri, Mar 24, 2006 at 03:38:50PM -0500, Dan Williams wrote: On Fri, 2006-03-24 at 12:12 -0800, Jean Tourrilhes wrote: Jouni Malinen wrote : On Thu, Mar 23, 2006 at 08:16:04PM -0500, Dan Williams wrote: That's why wireless-tools and Wireless Extensions switched to passive scanning. Can you please point to some documentation/email thread/etc. describing this preference to use passive scanning? I was not aware of such a preference and have assumed that active scanning would be the preferred default because it is quite a bit faster and provides more complete results. I was scratchig my head over that one, I'm glad I'm not the only one. Don't worry, it's hard not to scratch your head when somebody (ie, me) is on large amounts crack. Want some? It makes everything so much clearer :) Dan We are all bringing different expertise and viewpoint to the party, which are often complementary. Don't underestimate what you have achieved, you have contributed a lot in term of normalising the API between drivers and user-space. All this wireless stuff is quite tricky. Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ip6_tunnel: fix a soft lockup when there is no active tunnel for an encapsulated packet
Hugo Santos [EMAIL PROTECTED] wrote:
This patch fixes a soft lockup in ip6_tunnel when not using
xfrm6_tunnel (CONFIG_INET6_TUNNEL). It is triggered when an encapsula-
ted packet reaches ip6ip6_rcv() and there is no tunnel associated with
it. The error path returns a positive value (1) which will trigger
ip6_input to re-submit the packet for processing. As no skb parameters
have been changed, ip6ip6_rcv() will continue to be called with the
exact same context. Also, ip6ip6_rcv() should free the skb when
discarding it.
Signed-off-by: Hugo Santos [EMAIL PROTECTED]
OK this is a bit ugly but will do for now. Could you please do it for
the ICMP packet and IPv4 as well?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tg3 breakage this morning
Michael Chan wrote: Walt wrote: Nope, it was the second one: Skip phy power down... It doesn't make sense. This code should have no effect on your 5702. With or without this patch, the 5702 will be powered down the same with tg3_writephy(tp, MII_BMCR, BMCR_PDOWN) if WOL is not enabled when you ifdown. Also, for this code to have any effect, you must do ifdown or suspend. So presumably the driver loaded fine at least once and you get the failure during subsequent modprode... I confess I'm a bit confused by your question. I have no idea why an ifdown would be executed during boot, but the startup scripts are so complicated that I can't understand what they do. The network script does print a message that the eth0 interface doesn't exist, so I assume that the script tried to use ifconfig to do something and failed (wouldn't that most likely be an ifup rather than ifdown, during bootup?). the driver should behave the same on 5702 with or without the patch if you follow the same sequence. Yes, if I'm reading the code correctly. Is it possible that the driver is mis-identifying the chip? You can also try to bypass this code by setting WOL. Use ethtool -S eth0 wol g to enable WOL and the phy will not be powered down. I'm not sure what to do with this information. The chip certainly would not be powered down during bootup -- would it? I dunno. Sounds to me like this code is being executed by mistake. - To unsubscribe from this list: send 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] PCI Error Recovery: e1000 network device driver
Jeff,
Can you please review and forward this patch upstream? A previous
version of this patch has been ack'ed by Jesse Brandeburg, one
of the e1000 maintainers.
--linas
[PATCH] PCI Error Recovery: e1000 network device driver
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel gigabit
ethernet e1000 device driver. The patch has been tested, and appears
to work well.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Acked-by: Jesse Brandeburg [EMAIL PROTECTED]
drivers/net/e1000/e1000_main.c | 114 -
1 files changed, 113 insertions(+), 1 deletion(-)
Index: linux-2.6.16-git6/drivers/net/e1000/e1000_main.c
===
--- linux-2.6.16-git6.orig/drivers/net/e1000/e1000_main.c 2006-03-23
15:48:01.0 -0600
+++ linux-2.6.16-git6/drivers/net/e1000/e1000_main.c2006-03-24
15:14:40.431371705 -0600
@@ -226,6 +226,16 @@ static int e1000_resume(struct pci_dev *
static void e1000_netpoll (struct net_device *netdev);
#endif
+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state);
+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev);
+static void e1000_io_resume(struct pci_dev *pdev);
+
+static struct pci_error_handlers e1000_err_handler = {
+ .error_detected = e1000_io_error_detected,
+ .slot_reset = e1000_io_slot_reset,
+ .resume = e1000_io_resume,
+};
static struct pci_driver e1000_driver = {
.name = e1000_driver_name,
@@ -235,8 +245,9 @@ static struct pci_driver e1000_driver =
/* Power Managment Hooks */
#ifdef CONFIG_PM
.suspend = e1000_suspend,
- .resume = e1000_resume
+ .resume = e1000_resume,
#endif
+ .err_handler = e1000_err_handler,
};
MODULE_AUTHOR(Intel Corporation, [EMAIL PROTECTED]);
@@ -3063,6 +3074,10 @@ e1000_update_stats(struct e1000_adapter
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
+ /* Prevent stats update while adapter is being reset */
+ if (adapter-link_speed == 0)
+ return;
+
spin_lock_irqsave(adapter-stats_lock, flags);
/* these counters are modified from e1000_adjust_tbi_stats,
@@ -4631,4 +4646,101 @@ e1000_netpoll(struct net_device *netdev)
}
#endif
+/**
+ * e1000_io_error_detected - called when PCI error is detected
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ *
+ * This function is called after a PCI bus error affecting
+ * this device has been detected.
+ */
+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev-priv;
+
+ netif_device_detach(netdev);
+
+ if (netif_running(netdev))
+ e1000_down(adapter);
+
+ /* Request a slot slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * e1000_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch, as if from a cold-boot. Implementation
+ * resembles the first-half of the e1000_resume routine.
+ */
+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev-priv;
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR e1000: Cannot re-enable PCI device after
reset.\n);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ pci_set_master(pdev);
+
+ pci_enable_wake(pdev, 3, 0);
+ pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */
+
+ /* Perform card reset only on one instance of the card */
+ if(0 != PCI_FUNC (pdev-devfn))
+ return PCI_ERS_RESULT_RECOVERED;
+
+ e1000_reset(adapter);
+ E1000_WRITE_REG(adapter-hw, WUS, ~0);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * e1000_io_resume - called when traffic can start flowing again.
+ * @pdev: Pointer to PCI device
+ *
+ * This callback is called when the error recovery driver tells us that
+ * its OK to resume normal operation. Implementation resembles the
+ * second-half of the e1000_resume routine.
+ */
+static void e1000_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev-priv;
+ uint32_t manc, swsm;
+
+ if(netif_running(netdev)) {
+ if (e1000_up(adapter)) {
+ printk(e1000: can't bring device back up after
reset\n);
+ return;
+ }
+ }
+
+ netif_device_attach(netdev);
+
+ if(adapter-hw.mac_type = e1000_82540
+ adapter-hw.media_type == e1000_media_type_copper) {
+ manc =
Re: sky2: hangs on 2.6.16
On Fri, Mar 24, 2006 at 07:29:33PM +, fs wrote: On Fri, Mar 24, 2006 at 11:24:35AM -0800, Stephen Hemminger wrote: On Fri, 24 Mar 2006 18:48:37 + fs [EMAIL PROTECTED] wrote: On Fri, Mar 24, 2006 at 10:40:00AM -0800, Stephen Hemminger wrote: Maybe the hang I notice is different because it stays with this patch and appears primarily after using multiple connections. An easy way to reproduce it here is this axel -n 40 http://..file (a downloader that opens 40 connections) it will go on downloading normally without problem. If I ctrl-c that process and immediately re-run it, it will not start again (or any other internet connection). rmmod, modprobe and reconfiguring the iface brings it back to normal. I haven't checked if all those 40 connections are opened or at some point it doesn't open more than 10 or sth. Let me know if I can help somehow further. How far away is the site you are downloading from. Perhaps it just means you have lots of connections open, and the memory is getting low. I can't reproduce it here (downloading from kernel.org on P4 with motherboard chip and 2.6.16-git latest). But I have 2G of memory. The problem doesn't appear with the proprietary driver on .15 on the same sites. Basically, when the hang happens I can't open an inet connection without rmmod, modprobe, iface reconfiguration. I have 1.5gb. Do you see anything on the console log (dmesg) like transmit timeouts? or allocation failures? no, nothing out of the ordinary on dmesg. So, any idea how I should go into debugging this? I have no much experience in debugging, and none at all in network debugging. debug=16 was repeating things like .. Mar 24 18:05:34 localhost kernel: eth0: tx done, up to 184 Mar 24 18:05:34 localhost kernel: sky2 eth0: rx slot 138 status 0x59a0100 len 14 .. were they any helpfull? - To unsubscribe from this list: send the 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/ieee80211: report hidden ESSIDs as zero-length,not hidden
On Fri, Mar 24, 2006 at 09:31:56PM +, David Woodhouse wrote: wpa_supplicant appears to be aware of none of this -- it expects the SSID to be precisely correct in the scan results after it does an active probe for a specific SSID. Thus, it doesn't work when SSID broadcasting is turned off unless I apply the hack at http://david.woodhou.se/wpa_supplicant-hack.patch wpa_supplicant does indeed require that the scan results are reported correctly. I don't see much point in the results if they are not correct.. It is unfortunate if you need to use this kind of patch since it would not work very well in cases where there is more than one BSSID with hidden reported as the SSID.. Do we really expect to push this problem to userspace, or should the kernel drivers be assuming for themselves that the probe response _should_ have the same SSID as we actually probed for, then fixing it up accordingly? I think that whoever is responsible for processing Beacon and Probe Response frames should report SSIDs correctly. In case this is done in kernel code (which is the case for more or less all Linux drivers at the moment), this would need to be in kernel (but can and should be shared with all drivers). As an example, Host AP driver keeps a local list of detected BSSes and it keeps a separate entry for each SSID to support multi-SSID configuration. SIOCGIWSCAN will then get list of all detected BSSID,SSID combinations with SSID field updated based on Probe Response for the cases where Beacon frame used an empty SSID (or had another SSID in case of multi-SSID). In case scanning is moved to user space, this process would happen in an user space application instead. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce scan dwell time
On Fri, 2006-03-24 at 09:48 -0800, Jouni Malinen wrote: Is battery use more important than accuracy of results and the amount of time needed to perform the operation? You're going to be using *more* battery when doing a passive scan because the dwell time is much much larger, and you can't power down the rx component during scan. So much for a power issue. johannes signature.asc Description: This is a digitally signed message part
Re: sky2: hangs on 2.6.16
On Fri, 24 Mar 2006 22:13:54 + Michael Menegakis [EMAIL PROTECTED] wrote: were they any helpfull? The first thing to look for is are packets showing up (and being transmitted) by doing ethtool -S eth0 Since in this driver stats come out of the PHY, it is possible for the PHY to be receiving packets but have the bus interface wedged. It also will tell you if you have pause frames going back and forth. You might have a bad switch that doesn't do flow-control properly. Next you can turn on debug with: ethtool -s eth0 msglvl 0xfff and see if packets are being received and transmitted. In your case, it looks like the driver is receiving and transmitting fine; so it probably is in the upper layers. So look into higher level statistics like: netstat (or ip and ss). Other possiblities: * turn off TSO ethtool -K eth0 tso off * turn off Tx checksum ethtool -K eth0 tx off * turn off Rx checksum ethtool -K eth0 rx off If you get things really wedged and want to dig into the driver and look at all the registers. But it really requires lots of time to decode... ethtool -d eth0 raw on /tmp/eth0.dump hexdump /tmp/eth0.dump - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless-2.6-softmac patch: prism54usb update
On Fri, Mar 24, 2006 at 01:13:12PM -0800, Pete Zaitcev wrote: Would you just keep it on master without pushing to Linus? They way you manipulate branches of wireless-2.6 is bewildering for me, and softmac I'm trying to get away from excessive branching. It gets to be a big PITA, and it confuses people (sometimes including me). That's why I separated the dscape branch out to wireless-dev. I think you have a point. I'll ditch the devel branch and just use the master branch for the unmerged stuff, while the merge candidate stuff will go in the upstream branch for Jeff to pull. Andrew will probably like that better for -mm as well. I should be able to take the master-based patches you sent me and massage them into wireless-2.6 -- no need for you to do it. I apologize for the confusion! John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
rtnetlink compile failure.
I accidentally ended up with a config that set NET_RADIO off, and NET_WIRELESS_RTNETLINK on, which blew up thus.. net/built-in.o: In function `do_setlink':net/core/rtnetlink.c:479: undefined reference to `wireless_rtnetlink_set' net/built-in.o: In function `do_getlink':net/core/rtnetlink.c:521: undefined reference to `wireless_rtnetlink_get' Signed-off-by: Dave Jones [EMAIL PROTECTED] --- linux-2.6.16.noarch/drivers/net/wireless/Kconfig~ 2006-03-24 18:01:46.0 -0500 +++ linux-2.6.16.noarch/drivers/net/wireless/Kconfig2006-03-24 18:02:03.0 -0500 @@ -27,6 +27,7 @@ config NET_RADIO config NET_WIRELESS_RTNETLINK bool Wireless Extension API over RtNetlink + depends on NET_RADIO ---help--- Support the Wireless Extension API over the RtNetlink socket in addition to the traditional ioctl interface (selected above). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tg3 breakage this morning
On Fri, 24 Mar 2006, walt wrote: Michael Chan wrote: Walt wrote: Nope, it was the second one: Skip phy power down... It doesn't make sense. This code should have no effect on your 5702. With or without this patch, the 5702 will be powered down the same with tg3_writephy(tp, MII_BMCR, BMCR_PDOWN) if WOL is not enabled when you ifdown. Also, for this code to have any effect, you must do ifdown or suspend. So presumably the driver loaded fine at least once and you get the failure during subsequent modprode... I confess I'm a bit confused by your question. I have no idea why an ifdown would be executed during boot, but the startup scripts are so complicated that I can't understand what they do. The network script does print a message that the eth0 interface doesn't exist, so I assume that the script tried to use ifconfig to do something and failed (wouldn't that most likely be an ifup rather than ifdown, during bootup?). The eth0 interface not existing does sound somewhat like the tg3 problem I had. Did you check if you had PCI_MMCONFIG enabled in your config? -Bill - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tg3 breakage this morning
On Fri, 2006-03-24 at 14:06 -0800, walt wrote: I confess I'm a bit confused by your question. I have no idea why an ifdown would be executed during boot, but the startup scripts are so complicated that I can't understand what they do. The best thing to do is probably to disable all the scripts and load the driver by hand and do ifup/ifdown and see what happens. The patch that you identified is in the code path of ifdown or suspend only. And even then, the patch does not affect 5702 at all. So this is still a big mystery to me. I'll see if I can find a similar machine with on-board 5702 to test. I tested 5702 add-in cards and they worked 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: rtnetlink compile failure.
From: Dave Jones [EMAIL PROTECTED] Date: Fri, 24 Mar 2006 18:04:28 -0500 I accidentally ended up with a config that set NET_RADIO off, and NET_WIRELESS_RTNETLINK on, which blew up thus.. net/built-in.o: In function `do_setlink':net/core/rtnetlink.c:479: undefined reference to `wireless_rtnetlink_set' net/built-in.o: In function `do_getlink':net/core/rtnetlink.c:521: undefined reference to `wireless_rtnetlink_get' Signed-off-by: Dave Jones [EMAIL PROTECTED] Applied, thanks a lot Dave. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtnetlink compile failure.
Dave Jones wrote : I accidentally ended up with a config that set NET_RADIO off, and NET_WIRELESS_RTNETLINK on, which blew up thus.. Good catch ! Actually, in 2.6.17, NET_RADIO and WIRELESS_EXT were separated. So, I would suggest the following instead : - config NET_WIRELESS_RTNETLINK bool Wireless Extension API over RtNetlink + select WIRELESS_EXT ---help--- Support the Wireless Extension API over the RtNetlink socket in addition to the traditional ioctl interface (selected above). - Have fun... Jean - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ip6_tunnel: fix a soft lockup when there is no active tunnel for an encapsulated packet
OK this is a bit ugly but will do for now. Could you please do it for
the ICMP packet and IPv4 as well?
I find it ugly that the same function, in this case ip6ip6_rcv(), is
used in two contexts where the expected behaviour differs. Also, using
the current #ifdefs, ip6_tunnel is only loadable when xfrm6_tunnel
isn't loaded (as xfrm6_tunnel takes over as IPPROTO_IPV6 handler). A
solution would involve ip6_tunnel depend on xfrm6_tunnel if it was
built either statically or as a module (something that i don't quite
appreciate due to the extra tunnel-spi-lookup but that could do for
now).
Hugo
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: Digital signature
Re: [patch] net/ieee80211: report hidden ESSIDs as zero-length,not hidden
On Fri, 2006-03-24 at 14:14 -0800, Jouni Malinen wrote: wpa_supplicant does indeed require that the scan results are reported correctly. I don't see much point in the results if they are not correct.. It is unfortunate if you need to use this kind of patch since it would not work very well in cases where there is more than one BSSID with hidden reported as the SSID.. Define 'correctly'. There's definitely something to be said for reporting precisely what we got from the scan, without munging it. The fact that we currently mix the probe responses with random beacons we happen to receive at the same time (and in fact, that ieee80211 doesn't actually seem to _know_ when the device issued a probe, and what for) does make things somewhat suboptimal though. -- dwmw2 - To unsubscribe from this list: send the 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] ip6_tunnel: fix a soft lockup when there is no active tunnel for an encapsulated packet
From: Hugo Santos [EMAIL PROTECTED] Date: Sat, 25 Mar 2006 00:18:04 + I find it ugly that the same function, in this case ip6ip6_rcv(), is used in two contexts where the expected behaviour differs. It would have been even worse, IMHO, to have two copies of nearly identical code sitting around which is basically what the alternative is. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ip6_tunnel: fix a soft lockup when there is no active tunnel for an encapsulated packet
On Fri, Mar 24, 2006 at 04:31:15PM -0800, David S. Miller wrote:
It would have been even worse, IMHO, to have two copies of
nearly identical code sitting around which is basically what
the alternative is.
Actually, it might be cleaner to have wrappers around a common
(possibly inline as well) function. Let me have a go at that.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the 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] ip6_tunnel: fix a soft lockup when there is no active tunnel for an encapsulated packet
From: Herbert Xu [EMAIL PROTECTED] Date: Sat, 25 Mar 2006 11:36:36 +1100 On Fri, Mar 24, 2006 at 04:31:15PM -0800, David S. Miller wrote: It would have been even worse, IMHO, to have two copies of nearly identical code sitting around which is basically what the alternative is. Actually, it might be cleaner to have wrappers around a common (possibly inline as well) function. Let me have a go at that. Sounds good. - To unsubscribe from this list: send the 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] ip6_tunnel: fix a soft lockup when there is no active tunnel for an encapsulated packet
It would have been even worse, IMHO, to have two copies of
nearly identical code sitting around which is basically what
the alternative is.
We don't need two copies. We just need a function that does the real
work if there is a tunnel to be used (what xfrm6_tunnel needs), and
another one that would call the previous (used when xfrm6_tunnel isn't
used) that frees the skb on errors. Something like:
int ip6ip6_rcv(...) {
...
}
int ip6ip6_proto_rcv(...) {
int res = ip6ip6_rcv();
if (res 0) {
icmpv6_send_error();
kfree_skb();
}
return res;
}
Where ip6ip6_rcv is used when ip6_tunnel is registed via
xfrm6_tunnel, and the second as the IPPROTO_IPV6 handler (when this
functionality is compiled in).
Hugo
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: Digital signature
[PATCH 2.6.16] zd1201 wireless stat update
Hi all, The dev-get_wireless_stats field is deprecated and slowly be surely going away. Most drivers have been updated months ago. Actually, there is an annoying message for driver still using it, but it seems that user of zd1201 were not annoyed enough ;-) Patch was compiled on 2.6.16. I don't have hardware, so it's not tested, but I can't see how I could have messed up. Regards, Jean Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED] - diff -u -p linux/drivers/usb/net/zd1201.19.c linux/drivers/usb/net/zd1201.c --- linux/drivers/usb/net/zd1201.19.c 2006-03-14 16:05:33.0 -0800 +++ linux/drivers/usb/net/zd1201.c 2006-03-14 16:07:21.0 -0800 @@ -1737,6 +1737,7 @@ static const struct iw_handler_def zd120 .standard = (iw_handler *)zd1201_iw_handler, .private= (iw_handler *)zd1201_private_handler, .private_args = (struct iw_priv_args *) zd1201_private_args, + .get_wireless_stats = zd1201_get_wireless_stats, }; static int zd1201_probe(struct usb_interface *interface, @@ -1799,7 +1800,6 @@ static int zd1201_probe(struct usb_inter zd-dev-open = zd1201_net_open; zd-dev-stop = zd1201_net_stop; zd-dev-get_stats = zd1201_get_stats; - zd-dev-get_wireless_stats = zd1201_get_wireless_stats; zd-dev-wireless_handlers = (struct iw_handler_def *)zd1201_iw_handlers; zd-dev-hard_start_xmit = zd1201_hard_start_xmit; - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SOFTMAC] Reduce default rate to 11Mbps.
On Fri, 2006-03-24 at 08:18 -0800, Jouni Malinen wrote:
On Thu, Mar 23, 2006 at 10:43:38PM +, David Woodhouse wrote:
This patch makes us default to 11M, which ought to work for most people.
Is this code supposed to work with IEEE 802.11a (which would also use
OFDM modulation)? If yes, please note that 11 Mbps is not a valid IEEE
802.11a TX rate.
Er, well spotted. Let's do it like this instead...
diff --git a/net/ieee80211/softmac/ieee80211softmac_module.c
b/net/ieee80211/softmac/ieee80211softmac_module.c
index 6f99f78..60f06a3 100644
--- a/net/ieee80211/softmac/ieee80211softmac_module.c
+++ b/net/ieee80211/softmac/ieee80211softmac_module.c
@@ -183,16 +183,21 @@ void ieee80211softmac_start(struct net_d
*/
if (mac-txrates_change)
oldrates = mac-txrates;
- if (ieee-modulation IEEE80211_OFDM_MODULATION) {
- mac-txrates.default_rate = IEEE80211_OFDM_RATE_54MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
- mac-txrates.default_fallback = IEEE80211_OFDM_RATE_24MB;
- change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
- } else if (ieee-modulation IEEE80211_CCK_MODULATION) {
+ /* FIXME: We don't correctly handle backing down to lower
+ rates, so 801.11g devices start off at 11M for now. People
+ can manually change it if they really need to, but 11M is
+ more reliable. Note similar logic in
+ ieee80211softmac_wx_set_rate() */
+ if (ieee-modulation IEEE80211_CCK_MODULATION) {
mac-txrates.default_rate = IEEE80211_CCK_RATE_11MB;
change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
mac-txrates.default_fallback = IEEE80211_CCK_RATE_5MB;
change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
+ } else if (ieee-modulation IEEE80211_OFDM_MODULATION) {
+ mac-txrates.default_rate = IEEE80211_OFDM_RATE_54MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT;
+ mac-txrates.default_fallback = IEEE80211_OFDM_RATE_24MB;
+ change |= IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK;
} else
assert(0);
if (mac-txrates_change)
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c
b/net/ieee80211/softmac/ieee80211softmac_wx.c
index e1a9bc6..b559aa9 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -135,11 +135,15 @@ ieee80211softmac_wx_set_rate(struct net_
int err = -EINVAL;
if (in_rate == -1) {
- /* automatic detect */
- if (ieee-modulation IEEE80211_OFDM_MODULATION)
- in_rate = 5400;
- else
+ /* FIXME: We don't correctly handle backing down to lower
+ rates, so 801.11g devices start off at 11M for now. People
+ can manually change it if they really need to, but 11M is
+ more reliable. Note similar logic in
+ ieee80211softmac_wx_set_rate() */
+ if (ieee-modulation IEEE80211_CCK_MODULATION)
in_rate = 1100;
+ else
+ in_rate = 5400;
}
switch (in_rate) {
--
dwmw2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.16: assertion (!sk-sk_forward_alloc) failed
Upgraded a number of heavily used squid boxes to 2.6.16 from 2.6.13 this week, and noticed these errors in the logs: KERNEL: assertion (!sk-sk_forward_alloc) failed at net/core/stream.c (279) KERNEL: assertion (!sk-sk_forward_alloc) failed at net/ipv4/af_inet.c (148) but then looked through the logs and noticed they were occurring even on 2.6.13. I see some talk about the messages in the archives, but no resolution. Some of the discussion centered around e1000, which these boxes do use. I checked another squid box which uses e100, and it does not have these errors. Thoughts? Phil - To unsubscribe from this list: send the 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.16: assertion (!sk-sk_forward_alloc) failed
From: Phil Oester [EMAIL PROTECTED] Date: Fri, 24 Mar 2006 17:03:35 -0800 Upgraded a number of heavily used squid boxes to 2.6.16 from 2.6.13 this week, and noticed these errors in the logs: KERNEL: assertion (!sk-sk_forward_alloc) failed at net/core/stream.c (279) KERNEL: assertion (!sk-sk_forward_alloc) failed at net/ipv4/af_inet.c (148) but then looked through the logs and noticed they were occurring even on 2.6.13. I see some talk about the messages in the archives, but no resolution. Some of the discussion centered around e1000, which these boxes do use. I checked another squid box which uses e100, and it does not have these errors. Thoughts? E1000 has some TSO bug most likely, try reproducing with ethtool -K eth0 tso off, replacing eth0 with your actual e1000 interface name(s). Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtnetlink compile failure.
From: Jean Tourrilhes [EMAIL PROTECTED] Date: Fri, 24 Mar 2006 15:47:51 -0800 Actually, in 2.6.17, NET_RADIO and WIRELESS_EXT were separated. So, I would suggest the following instead : - config NET_WIRELESS_RTNETLINK bool Wireless Extension API over RtNetlink + select WIRELESS_EXT ---help--- Support the Wireless Extension API over the RtNetlink socket in addition to the traditional ioctl interface (selected above). - Both approaches are functionally equivalent since NET_RADIO selects WIRELESS_EXT already. Therefore I think the fix selection is arbitrary, and I'll just take Dave's since he posted his version first :) - To unsubscribe from this list: send the 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] PCI Error Recovery: e1000 network device driver
On Fri, Mar 24, 2006 at 04:00:02PM -0600, Linas Vepstas wrote:
+ /* Perform card reset only on one instance of the card */
+ if(0 != PCI_FUNC (pdev-devfn))
+ return PCI_ERS_RESULT_RECOVERED;
You seem to have forgotton to put a ' ' after the 'if' in a number of
different places in this patch. Also the (0 != foo) form is a bit
different from the traditional kernel coding style.
+ switch(adapter-hw.mac_type) {
And here too.
Remember, if and switch are not functions...
thanks,
greg k-h
-
To unsubscribe from this list: send the 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] PCI Error Recovery: e1000 network device driver
On Fri, Mar 24, 2006 at 06:22:06PM -0800, Greg KH wrote:
... a bit
different from the traditional kernel coding style.
Sorry, this is due to inattention on my part; I get cross-eyed
after staring at the same code for too long. The patch below should
fix things.
--linas
[PATCH] PCI Error Recovery: e1000 network device driver
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel gigabit
ethernet e1000 device driver. The patch has been tested, and appears
to work well.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Acked-by: Jesse Brandeburg [EMAIL PROTECTED]
drivers/net/e1000/e1000_main.c | 114 -
1 files changed, 113 insertions(+), 1 deletion(-)
Index: linux-2.6.16-git6/drivers/net/e1000/e1000_main.c
===
--- linux-2.6.16-git6.orig/drivers/net/e1000/e1000_main.c 2006-03-23
15:48:01.0 -0600
+++ linux-2.6.16-git6/drivers/net/e1000/e1000_main.c2006-03-24
15:14:40.431371705 -0600
@@ -226,6 +226,16 @@ static int e1000_resume(struct pci_dev *
static void e1000_netpoll (struct net_device *netdev);
#endif
+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev,
+ pci_channel_state_t state);
+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev);
+static void e1000_io_resume(struct pci_dev *pdev);
+
+static struct pci_error_handlers e1000_err_handler = {
+ .error_detected = e1000_io_error_detected,
+ .slot_reset = e1000_io_slot_reset,
+ .resume = e1000_io_resume,
+};
static struct pci_driver e1000_driver = {
.name = e1000_driver_name,
@@ -235,8 +245,9 @@ static struct pci_driver e1000_driver =
/* Power Managment Hooks */
#ifdef CONFIG_PM
.suspend = e1000_suspend,
- .resume = e1000_resume
+ .resume = e1000_resume,
#endif
+ .err_handler = e1000_err_handler,
};
MODULE_AUTHOR(Intel Corporation, [EMAIL PROTECTED]);
@@ -3063,6 +3074,10 @@ e1000_update_stats(struct e1000_adapter
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
+ /* Prevent stats update while adapter is being reset */
+ if (adapter-link_speed == 0)
+ return;
+
spin_lock_irqsave(adapter-stats_lock, flags);
/* these counters are modified from e1000_adjust_tbi_stats,
@@ -4631,4 +4646,101 @@ e1000_netpoll(struct net_device *netdev)
}
#endif
+/**
+ * e1000_io_error_detected - called when PCI error is detected
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ *
+ * This function is called after a PCI bus error affecting
+ * this device has been detected.
+ */
+static pci_ers_result_t e1000_io_error_detected(struct pci_dev *pdev,
pci_channel_state_t state)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev-priv;
+
+ netif_device_detach(netdev);
+
+ if (netif_running(netdev))
+ e1000_down(adapter);
+
+ /* Request a slot slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * e1000_io_slot_reset - called after the pci bus has been reset.
+ * @pdev: Pointer to PCI device
+ *
+ * Restart the card from scratch, as if from a cold-boot. Implementation
+ * resembles the first-half of the e1000_resume routine.
+ */
+static pci_ers_result_t e1000_io_slot_reset(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev-priv;
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR e1000: Cannot re-enable PCI device after
reset.\n);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ pci_set_master(pdev);
+
+ pci_enable_wake(pdev, 3, 0);
+ pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */
+
+ /* Perform card reset only on one instance of the card */
+ if (PCI_FUNC (pdev-devfn) != 0)
+ return PCI_ERS_RESULT_RECOVERED;
+
+ e1000_reset(adapter);
+ E1000_WRITE_REG(adapter-hw, WUS, ~0);
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * e1000_io_resume - called when traffic can start flowing again.
+ * @pdev: Pointer to PCI device
+ *
+ * This callback is called when the error recovery driver tells us that
+ * its OK to resume normal operation. Implementation resembles the
+ * second-half of the e1000_resume routine.
+ */
+static void e1000_io_resume(struct pci_dev *pdev)
+{
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct e1000_adapter *adapter = netdev-priv;
+ uint32_t manc, swsm;
+
+ if (netif_running(netdev)) {
+ if (e1000_up(adapter)) {
+ printk(e1000: can't bring device back up after
reset\n);
+ return;
+ }
+ }
+
+ netif_device_attach(netdev);
+
+ if (adapter-hw.mac_type =
nf_conntrack_l3proto_ipv6.c Kconfig confusion
x86 allmodconfig: bix:/usr/src/25 make net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.o CC net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.o net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c: In function `ipv6_conntrack_in': net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c:254: error: structure has no member named `nfct_reasm' Because: #if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE) struct sk_buff *nfct_reasm; #endif and bix:/usr/src/25 grep CONNTRACK .config CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CONNTRACK_EVENTS=y CONFIG_IP_NF_CONNTRACK_NETLINK=m I would naively expect that the above CONFIG_NF_CONNTRACK should be CONFIG_IP_NF_CONNTRACK but it's scary in there. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET]: Take RTNL when unregistering notifier
Hi Dave:
The netdev notifier call chain is currently unregistered without taking
any locks outside the notifier system. Because the notifier system itself
does not synchronise unregistration with respect to the calling of the
chain, we as its user need to do our own locking.
We are supposed to take the RTNL for all calls to netdev notifiers, so
taking the RTNL should be sufficient to protect it.
The registration path in dev.c already takes the RTNL so it's OK.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/net/core/dev.c b/net/core/dev.c
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -978,7 +978,12 @@ int register_netdevice_notifier(struct n
int unregister_netdevice_notifier(struct notifier_block *nb)
{
- return notifier_chain_unregister(netdev_chain, nb);
+ int err;
+
+ rtnl_lock();
+ err = notifier_chain_unregister(netdev_chain, nb);
+ rtnl_unlock();
+ return err;
}
/**
[PATCH 0/2] Host AP driver update
Please apply following two patches to Host AP driver in wireless-2.6. The second patch (Fix EAPOL frame encryption) is a trivial bug fix for a somewhat unfortunate bug and it could be a good candidate for a 2.6.16.x stable release ([EMAIL PROTECTED] cc'ed). -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] hostap: Fix EAPOL frame encryption
Fixed encrypted of EAPOL frames from wlan#ap interface (hostapd). This
was broken when moving to use new frame control field defines in
net/ieee80211.h. hostapd uses Protected flag, not protocol version
(which was cleared in this function anyway). This fixes WPA group key
handshake and re-authentication.
http://hostap.epitest.fi/bugz/show_bug.cgi?id=126
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: linux-2.6.16/drivers/net/wireless/hostap/hostap_80211_tx.c
===
--- linux-2.6.16.orig/drivers/net/wireless/hostap/hostap_80211_tx.c
+++ linux-2.6.16/drivers/net/wireless/hostap/hostap_80211_tx.c
@@ -469,7 +469,7 @@ int hostap_master_start_xmit(struct sk_b
}
if (local-ieee_802_1x meta-ethertype == ETH_P_PAE tx.crypt
- !(fc IEEE80211_FCTL_VERS)) {
+ !(fc IEEE80211_FCTL_PROTECTED)) {
no_encrypt = 1;
PDEBUG(DEBUG_EXTRA2, %s: TX: IEEE 802.1X - passing
unencrypted EAPOL frame\n, dev-name);
--
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] hostap: Make hostap_tx_encrypt() static
hostap_tx_encrypt() is used only inside hostap_80211_tx.c and there
are no plans to use it elsewhere in the future either, so let's make
it static. As a bonus, this should silence Coverity scanner from
complaining about bogus FORWARD_NULL case (CID: 274).
Signed-off-by: Jouni Malinen [EMAIL PROTECTED]
Index: linux-2.6.16/drivers/net/wireless/hostap/hostap_80211_tx.c
===
--- linux-2.6.16.orig/drivers/net/wireless/hostap/hostap_80211_tx.c
+++ linux-2.6.16/drivers/net/wireless/hostap/hostap_80211_tx.c
@@ -299,8 +299,8 @@ int hostap_mgmt_start_xmit(struct sk_buf
/* Called only from software IRQ */
-struct sk_buff * hostap_tx_encrypt(struct sk_buff *skb,
- struct ieee80211_crypt_data *crypt)
+static struct sk_buff * hostap_tx_encrypt(struct sk_buff *skb,
+ struct ieee80211_crypt_data *crypt)
{
struct hostap_interface *iface;
local_info_t *local;
@@ -317,7 +317,7 @@ struct sk_buff * hostap_tx_encrypt(struc
}
if (local-tkip_countermeasures
- crypt crypt-ops strcmp(crypt-ops-name, TKIP) == 0) {
+ strcmp(crypt-ops-name, TKIP) == 0) {
hdr = (struct ieee80211_hdr_4addr *) skb-data;
if (net_ratelimit()) {
printk(KERN_DEBUG %s: TKIP countermeasures: dropped
@@ -535,5 +535,4 @@ int hostap_master_start_xmit(struct sk_b
EXPORT_SYMBOL(hostap_dump_tx_80211);
-EXPORT_SYMBOL(hostap_tx_encrypt);
EXPORT_SYMBOL(hostap_master_start_xmit);
Index: linux-2.6.16/drivers/net/wireless/hostap/hostap_80211.h
===
--- linux-2.6.16.orig/drivers/net/wireless/hostap/hostap_80211.h
+++ linux-2.6.16/drivers/net/wireless/hostap/hostap_80211.h
@@ -92,8 +92,6 @@ void hostap_dump_rx_80211(const char *na
void hostap_dump_tx_80211(const char *name, struct sk_buff *skb);
int hostap_data_start_xmit(struct sk_buff *skb, struct net_device *dev);
int hostap_mgmt_start_xmit(struct sk_buff *skb, struct net_device *dev);
-struct sk_buff * hostap_tx_encrypt(struct sk_buff *skb,
- struct ieee80211_crypt_data *crypt);
int hostap_master_start_xmit(struct sk_buff *skb, struct net_device *dev);
#endif /* HOSTAP_80211_H */
--
--
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stretch ACKs, etc. (was TSO and IPoIB performance degradation)
Wouldn't the appropriate place to add the tunable for Stretch ACKs be as a route attribute similar to RTAX_ADVMSS? Then system administrators who are aware of the local network topology, netfilters, etc, could use an ip route or whatever command to enable it on the route entry for the local IPoIB subnet. On a more general note, I find the idea that a current dst entry doesn't actually reflect the interface (even a logical interface) and nexthop that will be used to deliver a packet a little disturbing. It would seem to me that any filter that is going to re-route a packet to a different address or a different interface should be a logical device (with its own IP address) or logical interface, respectively. Otherwise what is going on is completely invisible to the transport protocol, as well as users of tools like traceroute. In other words, if a netfilter rule needs to actually re-reroute / transform packets, it shouldn't be a netfilter rule at all. It should be a logical device accepting and delivering packets on one or more interfaces. A case where this is important is localhost optimization. Both OpenSolaris and FreeBSD eliminate SCTP CRC32c checksum processing on localhost connections. That cannot be done if netfilter can redirect packets in a way completely invisible to the transport layer. If transforming operations were required to be performed by a logical device, the fact that a packet is routed or transformed in an unusual manner would be easily detectable. 127.0.0.1 could be reserved for the true localhost interface, and various other packet transformers could use other 127.0.0.0/8 addresses. A side benefit would be that various byzantine NAT transformations could be moved into userspace, where they belong. Is H323 or FTP NAT so performance critical that it needs to be done in kernel? Comments? - Mark B. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[SCTP]: Fix up sctp_rcv return value
Hi Dave:
I was working on the ipip/xfrm problem and as usual I get side-tracked by
other problems.
As part of an attempt to change the IPv4 protocol handler calling
convention I found that SCTP violated the existing convention.
It's returning non-zero values after freeing the skb. This is doubly bad
as 1) the skb gets resubmitted; 2) the return value is interpreted as a
protocol number.
This patch changes those return values to zero.
IPv6 doesn't suffer from this problem because it uses a positive return
value as an indication for resubmission. So the only effect of this patch
there is to increment the IPSTATS_MIB_INDELIVERS counter which IMHO is
the right thing to do.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/net/sctp/input.c b/net/sctp/input.c
--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -127,7 +127,6 @@ int sctp_rcv(struct sk_buff *skb)
union sctp_addr dest;
int family;
struct sctp_af *af;
- int ret = 0;
if (skb-pkt_type!=PACKET_HOST)
goto discard_it;
@@ -227,16 +226,13 @@ int sctp_rcv(struct sk_buff *skb)
goto discard_release;
nf_reset(skb);
- ret = sk_filter(sk, skb, 1);
- if (ret)
+ if (sk_filter(sk, skb, 1))
goto discard_release;
/* Create an SCTP packet structure. */
chunk = sctp_chunkify(skb, asoc, sk);
- if (!chunk) {
- ret = -ENOMEM;
+ if (!chunk)
goto discard_release;
- }
SCTP_INPUT_CB(skb)-chunk = chunk;
/* Remember what endpoint is to handle this packet. */
@@ -277,11 +273,11 @@ int sctp_rcv(struct sk_buff *skb)
sctp_bh_unlock_sock(sk);
sock_put(sk);
- return ret;
+ return 0;
discard_it:
kfree_skb(skb);
- return ret;
+ return 0;
discard_release:
/* Release any structures we may be holding. */
