Re: Badness in cache_free_debugcheck at mm/slab.c:2315
On Sun, Jan 22, 2006 at 05:46:15PM +1100, herbert wrote:
This is due to the fclone patch. On the error path if we allocated an
fclone then we will free it in the wrong pool.
The following patch should fix the problem.
I let an extra blank line sneak in there. Can't have that :)
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/skbuff.c b/net/core/skbuff.c
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -135,13 +135,15 @@ void skb_under_panic(struct sk_buff *skb
struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
int fclone)
{
+ kmem_cache_t *cache;
struct skb_shared_info *shinfo;
struct sk_buff *skb;
u8 *data;
+ cache = fclone ? skbuff_fclone_cache : skbuff_head_cache;
+
/* Get the HEAD */
- skb = kmem_cache_alloc(fclone ? skbuff_fclone_cache : skbuff_head_cache,
- gfp_mask ~__GFP_DMA);
+ skb = kmem_cache_alloc(cache, gfp_mask ~__GFP_DMA);
if (!skb)
goto out;
@@ -180,7 +182,7 @@ struct sk_buff *__alloc_skb(unsigned int
out:
return skb;
nodata:
- kmem_cache_free(skbuff_head_cache, skb);
+ kmem_cache_free(cache, skb);
skb = NULL;
goto out;
}
[PATCH] trivial fix
Patch fixes misplaced (). Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko [EMAIL PROTECTED]
--
vda
diff -urpN softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c Sun Jan 22 13:12:30 2006
@@ -562,7 +562,7 @@ int ieee80211_rx(struct ieee80211_device
/* skb: hdr + (possibly fragmented) plaintext payload */
// PR: FIXME: hostap has additional conditions in the if below:
// ieee-host_decrypt (fc IEEE80211_FCTL_PROTECTED)
- if ((frag != 0 || (fc IEEE80211_FCTL_MOREFRAGS))) {
+ if ((frag != 0) || (fc IEEE80211_FCTL_MOREFRAGS)) {
int flen;
struct sk_buff *frag_skb = ieee80211_frag_cache_get(ieee, hdr);
IEEE80211_DEBUG_FRAG(Rx Fragment received (%u)\n, frag);
[PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to softmac
as ieee80211_rx_any() function.
Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko [EMAIL PROTECTED]
--
vda
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to softmac.
diff -urpN softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c Sun Jan 22 13:12:30 2006
@@ -758,6 +758,79 @@ int ieee80211_rx(struct ieee80211_device
/* Returning 0 indicates to caller that we have not handled the SKB--
* so it is still allocated and can be used again by underlying
* hardware as a DMA target */
+ return 0;
+}
+
+/* Kernel doesn't have it, why? */
+static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
+{
+return (0x01 addr[0]);
+}
+
+/* Filter out unrelated packets, call ieee80211_rx[_mgt] */
+int ieee80211_rx_any(struct ieee80211_device *ieee,
+ struct sk_buff *skb, struct ieee80211_rx_stats *stats)
+{
+ struct ieee80211_hdr_4addr *hdr;
+ int is_packet_for_us;
+ u16 fc;
+
+ if (ieee-iw_mode == IW_MODE_MONITOR)
+ return ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL;
+
+ hdr = (struct ieee80211_hdr_4addr *)skb-data;
+ fc = le16_to_cpu(hdr-frame_ctl);
+
+ switch (fc IEEE80211_FCTL_FTYPE) {
+ case IEEE80211_FTYPE_MGMT:
+ return ieee80211_rx_mgt(ieee, hdr, stats);
+ case IEEE80211_FTYPE_DATA:
+ break;
+ case IEEE80211_FTYPE_CTL:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+
+ is_packet_for_us = 0;
+ switch (ieee-iw_mode) {
+ case IW_MODE_ADHOC:
+ /* promisc: get all */
+ if (ieee-dev-flags IFF_PROMISC)
+ is_packet_for_us = 1;
+ /* our BSS */
+ else if (memcmp(hdr-addr3, ieee-bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr-addr1, ieee-dev-dev_addr, ETH_ALEN) == 0)
+is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr-addr1))
+is_packet_for_us = 1;
+ }
+ break;
+ case IW_MODE_INFRA:
+ /* promisc: get all */
+ if (ieee-dev-flags IFF_PROMISC)
+ is_packet_for_us = 1;
+ /* our BSS (== from our AP) */
+ else if (memcmp(hdr-addr2, ieee-bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr-addr1, ieee-dev-dev_addr, ETH_ALEN) == 0)
+is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr-addr1))
+/* not our own packet bcasted from AP */
+if (memcmp(hdr-addr3, ieee-dev-dev_addr, ETH_ALEN))
+ is_packet_for_us = 1;
+ }
+ break;
+ default:
+ /* ? */
+ break;
+ }
+
+ if (is_packet_for_us)
+ return (ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL);
return 0;
}
[PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
Patch adapts that code and adds it to 80211
as ieee80211_rx_any() function.
Diffed against wireless-2.6.git
Signed-off-by: Denis Vlasenko [EMAIL PROTECTED]
--
vda
diff -urp softmac-snapshot/net/ieee80211/ieee80211_rx.c softmac-snapshot.1/net/ieee80211/ieee80211_rx.c
--- softmac-snapshot/net/ieee80211/ieee80211_rx.c Wed Jan 18 07:27:03 2006
+++ softmac-snapshot.1/net/ieee80211/ieee80211_rx.c Sun Jan 22 14:01:43 2006
@@ -758,6 +758,80 @@ int ieee80211_rx(struct ieee80211_device
/* Returning 0 indicates to caller that we have not handled the SKB--
* so it is still allocated and can be used again by underlying
* hardware as a DMA target */
+ return 0;
+}
+
+/* Kernel doesn't have it, why? */
+static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
+{
+return (0x01 addr[0]);
+}
+
+/* Filter out unrelated packets, call ieee80211_rx[_mgt] */
+int ieee80211_rx_any(struct ieee80211_device *ieee,
+ struct sk_buff *skb, struct ieee80211_rx_stats *stats)
+{
+ struct ieee80211_hdr_4addr *hdr;
+ int is_packet_for_us;
+ u16 fc;
+
+ if (ieee-iw_mode == IW_MODE_MONITOR)
+ return ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL;
+
+ hdr = (struct ieee80211_hdr_4addr *)skb-data;
+ fc = le16_to_cpu(hdr-frame_ctl);
+
+ switch (fc IEEE80211_FCTL_FTYPE) {
+ case IEEE80211_FTYPE_MGMT:
+ ieee80211_rx_mgt(ieee, hdr, stats);
+ return 0;
+ case IEEE80211_FTYPE_DATA:
+ break;
+ case IEEE80211_FTYPE_CTL:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+
+ is_packet_for_us = 0;
+ switch (ieee-iw_mode) {
+ case IW_MODE_ADHOC:
+ /* promisc: get all */
+ if (ieee-dev-flags IFF_PROMISC)
+ is_packet_for_us = 1;
+ /* our BSS */
+ else if (memcmp(hdr-addr3, ieee-bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr-addr1, ieee-dev-dev_addr, ETH_ALEN) == 0)
+is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr-addr1))
+is_packet_for_us = 1;
+ }
+ break;
+ case IW_MODE_INFRA:
+ /* promisc: get all */
+ if (ieee-dev-flags IFF_PROMISC)
+ is_packet_for_us = 1;
+ /* our BSS (== from our AP) */
+ else if (memcmp(hdr-addr2, ieee-bssid, ETH_ALEN) == 0) {
+ /* to us */
+ if (memcmp(hdr-addr1, ieee-dev-dev_addr, ETH_ALEN) == 0)
+is_packet_for_us = 1;
+ /* mcast */
+ else if (is_mcast_or_bcast_ether_addr(hdr-addr1))
+/* not our own packet bcasted from AP */
+if (memcmp(hdr-addr3, ieee-dev-dev_addr, ETH_ALEN))
+ is_packet_for_us = 1;
+ }
+ break;
+ default:
+ /* ? */
+ break;
+ }
+
+ if (is_packet_for_us)
+ return (ieee80211_rx(ieee, skb, stats) ? 0 : -EINVAL);
return 0;
}
Re: [Bcm43xx-dev] Re: [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
On Sunday 22 January 2006 13:08, Denis Vlasenko wrote: On Sunday 22 January 2006 13:59, Denis Vlasenko wrote: bcm43xx_rx() contains code to filter out packets from foreign BSSes and decide whether to call ieee80211_rx or ieee80211_rx_mgt. This is not bcm specific. Patch adapts that code and adds it to softmac as ieee80211_rx_any() function. Diffed against wireless-2.6.git Signed-off-by: Denis Vlasenko [EMAIL PROTECTED] -- vda Please ignore this one. This is not good: + return ieee80211_rx_mgt(ieee, hdr, stats); Use corrected patch in my another email with Date: Sun, 22 Jan 2006 14:04:52 +0200 -- vda I would say, please also move the static inline int is_mcast_or_bcast_ether_addr(const u8 *addr) function into linux/etherdevice.h -- Greetings Michael. pgpHBpf6Jskup.pgp Description: PGP signature
Re: [PATCH] ieee80211_rx_any: filter out packets, call ieee80211_rx or ieee80211_rx_mgt
Denis Vlasenko wrote:
bcm43xx_rx() contains code to filter out packets from
foreign BSSes and decide whether to call ieee80211_rx
or ieee80211_rx_mgt. This is not bcm specific.
+/* Kernel doesn't have it, why? */
+static inline int is_mcast_or_bcast_ether_addr(const u8 *addr)
+{
+return (0x01 addr[0]);
+}
The same function exists in include/linux/etherdevice.h:
static inline int is_multicast_ether_addr(const u8 *addr)
{
return (0x01 addr[0]);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ip_finish_output2: No header cache and no neighbour! in 2.6.15-git7
David S. Miller wrote: From: Andi Kleen [EMAIL PROTECTED] Date: Fri, 20 Jan 2006 08:15:39 +0100 Sorry for the delay in testing. Looks good so far. I'm running with SNAT and the patch and the messages haven't appeared. Will keep it running for longer, but previously they would have started already, so it's probably ok now. Thanks for testing Andi. Patrick, please send me the final version of the fix you want me to put in when you get a chance. I need to rethink this, my patch breaks SNAT to non-local IPs because the NAT code will throw the packet away if ip_route_me_harder fails. - To unsubscribe from this list: send the 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 0.11 instability
Hi,
Carl-Daniel Hailfinger schrieb:
Carl-Daniel Hailfinger schrieb:
Carl-Daniel Hailfinger schrieb:
after sending 259 GB and receiving 25 GB over my SysKonnect SK-9E21
card (sky2 says it is a Yukon-EC (0xb6) rev 1), the card appears
dead. Machine is an Athlon64 3200+ on an Asus A8N-SLI Deluxe board.
I have now added a hard reset routine to the tx timeout
path and hope it won't kill my machine.
Apologies for mangled whitespace, this is just a rough cut'n'paste.
--- linux-2.6.15/drivers/net/sky2.c.orig2006-01-21 16:00:15.0
+0100
+++ linux-2.6.15/drivers/net/sky2.c 2006-01-21 14:08:28.0 +0100
@@ -1565,6 +1565,7 @@ static int sky2_autoneg_done(struct sky2
return 0;
}
+static int sky2_reset(struct sky2_hw *hw);
/*
* Interrupt from PHY are handled outside of interrupt context
* because accessing phy registers requires spin wait which might
@@ -1639,6 +1640,7 @@ static void sky2_tx_timeout(struct net_d
if (netif_msg_timer(sky2))
printk(KERN_ERR PFX %s: tx timeout\n, dev-name);
+ if (0) {
sky2_write32(hw, Q_ADDR(txq, Q_CSR), BMU_STOP);
sky2_write32(hw, Y2_QADDR(txq, PREF_UNIT_CTRL), PREF_UNIT_RST_SET);
@@ -1646,6 +1648,12 @@ static void sky2_tx_timeout(struct net_d
sky2_qset(hw, txq);
sky2_prefetch_init(hw, txq, sky2-tx_le_map, TX_RING_SIZE - 1);
+ } else {
+ printk(KERN_ERR PFX %s: recovering the HARD way...\n, dev-name);
+ sky2_down(dev);
+ sky2_reset(hw);
+ sky2_up(dev);
+ }
}
And everytime the kernel throws this message, I run the following
script:
#!/bin/bash
deadinterface=`dmesg|grep HARD|tail -1|sed s/.*sky2 //;s/:.*//`
ip l s $deadinterface down
ip l s $deadinterface up
After that, everything continues to work until the next tx timeout
happens, and then the script again saves the day.
More results about the circumstances of this bug: It seems that
it will only trigger under LOW load. As long as I keep the interface
busy, it will have no problems at all.
OK, more info about the circumstances of the bug.
- happens with sky2 0.11 and 0.13
- with low load (100 kB/s) it triggers after 12 hours and then
approx. every 50 minutes
- with medium load (100-1200 kB/s) it triggers after 30 minutes
and then approx. every 70 minutes
- with high RX load (9-12 MB/s) it triggers every 8 hours
- with high TX load (9-12 MB/s) I can't get it to trigger
- with stock tx_timeout handler, it will stay dead and no interrupts
are received from the nic once it hangs
- simply taking the interface down and up again doesn't help
- with my modified tx_timeout handler, taking the interface down and
up again after the timeout helps
- with stock tx_timeout handler, I have to unload and reload the
module to fix up the card
- general pattern seems to be medium interrupt load - instability
- ah yes, and this is a production machine at a slightly remote
location. Silly me.
If you want me to test any patch, tell me. It can only get better.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
-
To unsubscribe from this list: send 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] lp486e: remove SLOW_DOWN_IO
It's not used. Fix the following on alpha-eb66 as a side effect: In file included from drivers/net/lp486e.c:75: include/asm/io.h:20:1: warning: SLOW_DOWN_IO redefined drivers/net/lp486e.c:59:1: warning: this is the location of the previous definition Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- drivers/net/lp486e.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) --- a/drivers/net/lp486e.c +++ b/drivers/net/lp486e.c @@ -56,8 +56,6 @@ PORT SIZE ACTION MEANING All other communication is through memory! */ -#define SLOW_DOWN_IO udelay(5) - #include linux/module.h #include linux/init.h #include linux/delay.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
[2.6 patch] move some code to net/ipx/af_ipx.c
This patch moves some code only used in this file to net/ipx/af_ipx.c .
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 14 Jan 2006
include/net/p8022.h | 13 -
net/802/Makefile | 14 ++---
net/802/p8022.c | 66 ---
net/802/p8023.c | 61 -
net/8021q/vlan.c |1
net/8021q/vlan_dev.c |1
net/ethernet/Makefile |2
net/ethernet/pe2.c| 39
net/ipx/af_ipx.c | 102 --
9 files changed, 106 insertions(+), 193 deletions(-)
--- linux-2.6.15-rc1-mm1-full/net/ethernet/Makefile.old 2005-11-18
02:15:17.0 +0100
+++ linux-2.6.15-rc1-mm1-full/net/ethernet/Makefile 2005-11-18
02:15:22.0 +0100
@@ -4,5 +4,3 @@
obj-y += eth.o
obj-$(CONFIG_SYSCTL) += sysctl_net_ether.o
-obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
-obj-$(subst m,y,$(CONFIG_ATALK)) += pe2.o
--- linux-2.6.15-rc1-mm1-full/net/8021q/vlan.c.old 2005-11-18
02:19:40.0 +0100
+++ linux-2.6.15-rc1-mm1-full/net/8021q/vlan.c 2005-11-18 02:19:46.0
+0100
@@ -26,7 +26,6 @@
#include linux/mm.h
#include linux/in.h
#include linux/init.h
-#include net/p8022.h
#include net/arp.h
#include linux/rtnetlink.h
#include linux/notifier.h
--- linux-2.6.15-rc1-mm1-full/net/8021q/vlan_dev.c.old 2005-11-18
02:19:55.0 +0100
+++ linux-2.6.15-rc1-mm1-full/net/8021q/vlan_dev.c 2005-11-18
02:19:58.0 +0100
@@ -29,7 +29,6 @@
#include linux/netdevice.h
#include linux/etherdevice.h
#include net/datalink.h
-#include net/p8022.h
#include net/arp.h
#include vlan.h
--- linux-2.6.15-rc1-mm1-full/net/ipx/af_ipx.c.old 2005-11-18
02:17:00.0 +0100
+++ linux-2.6.15-rc1-mm1-full/net/ipx/af_ipx.c 2005-11-18 02:26:01.0
+0100
@@ -48,10 +48,10 @@
#include linux/termios.h
#include net/ipx.h
-#include net/p8022.h
#include net/psnap.h
#include net/sock.h
#include net/tcp_states.h
+#include net/llc.h
#include asm/uaccess.h
@@ -1939,8 +1939,104 @@
.notifier_call = ipxitf_device_event,
};
-extern struct datalink_proto *make_EII_client(void);
-extern void destroy_EII_client(struct datalink_proto *);
+static int p8022_request(struct datalink_proto *dl, struct sk_buff *skb,
+unsigned char *dest)
+{
+ llc_build_and_send_ui_pkt(dl-sap, skb, dest, dl-sap-laddr.lsap);
+ return 0;
+}
+
+static struct datalink_proto *register_8022_client(unsigned char type,
+ int (*func)(struct sk_buff *skb,
+ struct net_device *dev,
+ struct packet_type *pt,
+ struct net_device
*orig_dev))
+{
+ struct datalink_proto *proto;
+
+ proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
+ if (proto) {
+ proto-type[0] = type;
+ proto-header_length= 3;
+ proto-request = p8022_request;
+ proto-sap = llc_sap_open(type, func);
+ if (!proto-sap) {
+ kfree(proto);
+ proto = NULL;
+ }
+ }
+ return proto;
+}
+
+static void unregister_8022_client(struct datalink_proto *proto)
+{
+ llc_sap_put(proto-sap);
+ kfree(proto);
+}
+
+/*
+ * Place an 802.3 header on a packet. The driver will do the mac
+ * addresses, we just need to give it the buffer length.
+ */
+static int p8023_request(struct datalink_proto *dl,
+struct sk_buff *skb, unsigned char *dest_node)
+{
+ struct net_device *dev = skb-dev;
+
+ dev-hard_header(skb, dev, ETH_P_802_3, dest_node, NULL, skb-len);
+ return dev_queue_xmit(skb);
+}
+
+/*
+ * Create an 802.3 client. Note there can be only one 802.3 client
+ */
+static struct datalink_proto *make_8023_client(void)
+{
+ struct datalink_proto *proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
+
+ if (proto) {
+ proto-header_length = 0;
+ proto-request = p8023_request;
+ }
+ return proto;
+}
+
+/*
+ * Destroy the 802.3 client.
+ */
+static void destroy_8023_client(struct datalink_proto *dl)
+{
+ kfree(dl);
+}
+
+static int pEII_request(struct datalink_proto *dl,
+ struct sk_buff *skb, unsigned char *dest_node)
+{
+ struct net_device *dev = skb-dev;
+
+ skb-protocol = htons(ETH_P_IPX);
+ if (dev-hard_header)
+ dev-hard_header(skb, dev, ETH_P_IPX,
+dest_node, NULL, skb-len);
+ return dev_queue_xmit(skb);
+}
+
+static struct datalink_proto *make_EII_client(void)
+{
+ struct datalink_proto *proto = kmalloc(sizeof(*proto), GFP_ATOMIC);
[-mm patch] drivers/net/wireless/tiacx/: remove code for WIRELESS_EXT 18
WIRELESS_EXT 18 will never be true in the kernel.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 14 Jan 2006
drivers/net/wireless/tiacx/acx_struct.h |5
drivers/net/wireless/tiacx/common.c |4
drivers/net/wireless/tiacx/conv.c|2
drivers/net/wireless/tiacx/ioctl.c | 436 ---
drivers/net/wireless/tiacx/pci.c |8
drivers/net/wireless/tiacx/usb.c |6
drivers/net/wireless/tiacx/wlan.c|2
drivers/net/wireless/tiacx/wlan_compat.h | 10
8 files changed, 1 insertion(+), 472 deletions(-)
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/acx_struct.h.old
2005-12-03 02:58:36.0 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/acx_struct.h
2005-12-03 02:59:36.0 +0100
@@ -1053,9 +1053,8 @@
* the struct net_device. */
/*** Device statistics ***/
struct net_device_stats stats; /* net device statistics */
-#ifdef WIRELESS_EXT
struct iw_statisticswstats; /* wireless statistics */
-#endif
+
/*** Power managment ***/
struct pm_dev *pm;/* PM crap */
@@ -1103,9 +1102,7 @@
u8 scan_rate;
u16 scan_duration;
u16 scan_probe_delay;
-#if WIRELESS_EXT 15
struct iw_spy_data spy_data; /* FIXME: needs to be
implemented! */
-#endif
/*** Wireless network settings ***/
/* copy of the device address (ifconfig hw ether) that we actually use
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/common.c.old
2005-12-03 02:59:47.0 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/common.c2005-12-03
03:00:04.0 +0100
@@ -46,9 +46,7 @@
#include linux/wireless.h
#include linux/pm.h
#include linux/vmalloc.h
-#if WIRELESS_EXT = 13
#include net/iw_handler.h
-#endif /* WE = 13 */
#include acx.h
@@ -2707,7 +2705,6 @@
acxlog(L_ASSOC, %s(%d):%s\n,
__func__, new_status, acx_get_status_name(new_status));
-#if WIRELESS_EXT 13 /* wireless_send_event() and SIOCGIWSCAN */
/* wireless_send_event never sleeps */
if (ACX_STATUS_4_ASSOCIATED == new_status) {
union iwreq_data wrqu;
@@ -2729,7 +2726,6 @@
wrqu.ap_addr.sa_family = ARPHRD_ETHER;
wireless_send_event(priv-netdev, SIOCGIWAP, wrqu, NULL);
}
-#endif
priv-status = new_status;
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/conv.c.old 2005-12-03
03:00:17.0 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/conv.c 2005-12-03
03:00:26.0 +0100
@@ -36,9 +36,7 @@
#include linux/if_arp.h
#include linux/etherdevice.h
#include linux/wireless.h
-#if WIRELESS_EXT = 13
#include net/iw_handler.h
-#endif
#include acx.h
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/pci.c.old 2005-12-03
03:02:16.0 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/pci.c 2005-12-03
03:02:30.0 +0100
@@ -45,9 +45,7 @@
#include linux/if_arp.h
#include linux/rtnetlink.h
#include linux/wireless.h
-#if WIRELESS_EXT = 13
#include net/iw_handler.h
-#endif
#include linux/netdevice.h
#include linux/ioport.h
#include linux/pci.h
@@ -1820,11 +1818,7 @@
dev-hard_start_xmit = acx_i_start_xmit;
dev-get_stats = acx_e_get_stats;
dev-get_wireless_stats = acx_e_get_wireless_stats;
-#if WIRELESS_EXT = 13
dev-wireless_handlers = (struct iw_handler_def
*)acx_ioctl_handler_def;
-#else
- dev-do_ioctl = acx_e_ioctl_old;
-#endif
dev-set_multicast_list = acxpci_i_set_multicast_list;
dev-tx_timeout = acxpci_i_tx_timeout;
dev-change_mtu = acx_e_change_mtu;
@@ -3842,7 +3836,6 @@
r100 = txdesc-u.r1.rate;
r111 = txdesc-u.r2.rate111;
-#if WIRELESS_EXT 13 /* wireless_send_event() and IWEVTXDROP are WE13 */
/* need to check for certain error conditions before we
* clean the descriptor: we still need valid descr data here */
if (unlikely(0x30 error)) {
@@ -3857,7 +3850,6 @@
MAC_COPY(wrqu.addr.sa_data, hdr-a1);
wireless_send_event(priv-netdev, IWEVTXDROP, wrqu,
NULL);
}
-#endif
/* ...and free the desc */
txdesc-error = 0;
txdesc-ack_failures = 0;
--- linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/wlan.c.old 2005-12-03
03:02:58.0 +0100
+++ linux-2.6.15-rc3-mm1/drivers/net/wireless/tiacx/wlan.c 2005-12-03
03:03:02.0 +0100
@@ -43,9 +43,7 @@
#include linux/types.h
#include linux/if_arp.h
#include linux/wireless.h
-#if WIRELESS_EXT = 13
#include net/iw_handler.h
-#endif
#include acx.h
---
Re: [2.6 patch] schedule SHAPER for removal
On Sat, Jan 21, 2006 at 01:48:48AM +0100, Adrian Bunk wrote: Do we really have to wait the three years between stable Debian releases for removing an obsolete driver that has always been marked as EXPERIMENTAL? Please be serious. I am completely serious. The traditional cycle of obsolete code that works and is not causing a maintenence burden is 2 major releases -- one release during which the obsolete feature spews warnings on use, and another development cycle until it is actually removed. That's at least 3 years, which is still pretty short compared to distro cycles. There seems to be a lot of this disease of removing code for the sake of removal lately, and it's getting to the point of being really annoying. If the maintainer of the code in question isn't pushing for its removal, I see no need to rush the process too much, especially when the affected users aren't even likely to see the feature being marked obsolete since they don't troll the source code looking for things that break setups. -ben - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] schedule SHAPER for removal
On Sun, Jan 22, 2006 at 12:47:07PM -0500, Benjamin LaHaise wrote: On Sat, Jan 21, 2006 at 01:48:48AM +0100, Adrian Bunk wrote: Do we really have to wait the three years between stable Debian releases for removing an obsolete driver that has always been marked as EXPERIMENTAL? Please be serious. I am completely serious. The traditional cycle of obsolete code that works and is not causing a maintenence burden is 2 major releases -- one release during which the obsolete feature spews warnings on use, and another development cycle until it is actually removed. That's at least 3 years, which is still pretty short compared to distro cycles. There seems to be a lot of this disease of removing code for the sake of removal lately, and it's getting to the point of being really annoying. If the maintainer of the code in question isn't pushing for its removal, I see no need to rush the process too much, especially when the affected users aren't even likely to see the feature being marked obsolete since they don't troll the source code looking for things that break setups. The only supported combinations are distributions with the kernels they ship. E.g. running Debian stable with any kernel 2.6.8 is simply not supported. The only point where users are supposed to see such changes are upgrades to new releases of their distribution - and this is anyways a point where you have to double-check whether it hadn't broken anything. And the kernel isn't the main thing where things break during distribution upgrades - userspace breakages are much more common. As an example, not so long ago an upgrade of the hdparm package on my Debian unstable system broke one local boot script I'm using because upstream removed the short form of an option. And GNU make 3.81 will contain some backwards incompatible changes for being more POSIX compliant. And many more changes I do not remember. Distributions can document usespace-visible changes, but avoiding them is simply not possible. -ben cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] schedule SHAPER for removal
On Sun, 2006-01-22 at 19:20 +0100, Adrian Bunk wrote: On Sun, Jan 22, 2006 at 12:47:07PM -0500, Benjamin LaHaise wrote: On Sat, Jan 21, 2006 at 01:48:48AM +0100, Adrian Bunk wrote: Do we really have to wait the three years between stable Debian releases for removing an obsolete driver that has always been marked as EXPERIMENTAL? Please be serious. I am completely serious. The traditional cycle of obsolete code that works and is not causing a maintenence burden is 2 major releases -- one release during which the obsolete feature spews warnings on use, and another development cycle until it is actually removed. That's at least 3 years, which is still pretty short compared to distro cycles. There seems to be a lot of this disease of removing code for the sake of removal lately, and it's getting to the point of being really annoying. If the maintainer of the code in question isn't pushing for its removal, I see no need to rush the process too much, especially when the affected users aren't even likely to see the feature being marked obsolete since they don't troll the source code looking for things that break setups. The only supported combinations are distributions with the kernels they ship. I think you're being unreasonable here. Removing unused code from the kernel, I'm all for that. Really. But this is userspace visible functionality, and more care needs to be taken than just adding a few lines to an obscure file in the kernel. I agree with Ben that the kernel needs to printk a stern warning *AT USE OF THE FEATURE* for at least a year before such a feature can be removed. In addition I think that in case such a feature isn't actually harmful of further development (for example, it could be because it's fundamentally broken locking wise, or holding back major improvements) then a longer period of warnings should be no problem. Together with that should probably be something to ask distros to stop enabling the feature asap, or at least communicate it as deprecated in their respective release notes. - To unsubscribe from this list: send the 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 0.11 instability
You might try adjusting the interrupt coalescing parameters with ethtool -C eth0 ... But I can't give you hard guidelines as to what would make it better. I have a debug patch, but it needs work still. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem
Begin forwarded message:
Date: Sun, 22 Jan 2006 12:02:22 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem
http://bugzilla.kernel.org/show_bug.cgi?id=5936
Summary: Openswan tunnels + netfilter problem
Kernel Version: 2.6.16-rc1
Status: NEW
Severity: high
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL PROTECTED]
Most recent kernel where this bug did not occur:
Distribution: Fedora Core 4
Hardware Environment: Athlon 64, SATA HDD but occurs also with only ATA Drives
Software Environment:
Problem Description:using a tunnel (ping through it), trying to using another
the kernel Ooops
Jan 22 20:23:17 router kernel: Unable to handle kernel NULL pointer
dereference at 009c RIP:
Jan 22 20:23:17 router kernel: 80345195{xfrm4_output_finish+293}
Jan 22 20:23:17 router kernel: PGD 35377067 PUD 0
Jan 22 20:23:17 router kernel: Oops: [6]
Jan 22 20:23:17 router kernel: CPU 0
Jan 22 20:23:17 router kernel: Modules linked in: af_key deflate
zlib_deflate twofish serpent blowfish sha256 crypto_null ae$
Jan 22 20:23:17 router kernel: Pid: 9481, comm: ping Not tainted 2.6.16-rc1
#2
Jan 22 20:23:17 router kernel: RIP: 0010:[80345195]
80345195{xfrm4_output_finish+293}
Jan 22 20:23:17 router kernel: RSP: 0018:810030c19a78 EFLAGS: 00010297
Jan 22 20:23:17 router kernel: RAX: RBX: 810032242c3c
RCX: 0001
Jan 22 20:23:17 router kernel: RDX: 0001 RSI: 0449
RDI: 81003cba4d80
Jan 22 20:23:17 router kernel: RBP: 81003cba4d80 R08: 1d4b
R09: 804ac460
Jan 22 20:23:17 router kernel: R10: 001a R11: 810032242878
R12:
Jan 22 20:23:17 router kernel: R13: 0040 R14: 0040
R15: 810038dff9c0
Jan 22 20:23:17 router kernel: FS: 2aeb6a96fd00()
GS:804ba000() knlGS:
Jan 22 20:23:17 router kernel: CS: 0010 DS: ES: CR0:
8005003b
Jan 22 20:23:17 router kernel: CR2: 009c CR3: 38565000
CR4: 06e0
Jan 22 20:23:17 router kernel: Process ping (pid: 9481, threadinfo
810030c18000, task 81003ba90180)
Jan 22 20:23:17 router kernel: Stack: 80345070 8000
0002804ac450 80307864
Jan 22 20:23:17 router kernel:81003cba4d80 810032242c3c
81003ed74a40 81003868f0c0
Jan 22 20:23:17 router kernel:0040 0040
Jan 22 20:23:17 router kernel: Call Trace:
80345070{xfrm4_output_finish+0}
Jan 22 20:23:17 router kernel:80307864{nf_hook_slow+100}
803454b4{xfrm4_output+84}
Jan 22 20:23:17 router kernel:
8031289f{ip_push_pending_frames+895}
8032cf95{raw_sendmsg+1685}
Jan 22 20:23:17 router kernel:
803484e9{xfrm_state_get_afinfo+73}
8034a16c{xfrm_state_find+2588}
Jan 22 20:23:17 router kernel:802e28fa{sock_sendmsg+266}
80127e3d{try_to_wake_up+301}
Jan 22 20:23:17 router kernel:
80140a10{autoremove_wake_function+0}
80357f99{_read_unlock_irq+9}
Jan 22 20:23:17 router kernel:80151f46{filemap_nopage+390}
802e1935{move_addr_to_kernel+37}
Jan 22 20:23:17 router kernel:802e2f9a{sys_sendmsg+586}
80357ea9{_spin_lock_irqsave+9}
Jan 22 20:23:17 router kernel:
80140bb9{remove_wait_queue+25}
80357ea9{_spin_lock_irqsave+9}
Jan 22 20:23:17 router kernel:80203a81{__up_read+33}
80359583{do_page_fault+1139}
Jan 22 20:23:17 router kernel:802e4f29{release_sock+25}
80357f59{_spin_unlock_irq+9}
Jan 22 20:23:17 router kernel:8010ab12{system_call+126}
Jan 22 20:23:17 router kernel:
Jan 22 20:23:17 router kernel: Code: 41 80 bc 24 9c 00 00 00 00 74 57 48 8d
4d 58 48 8b 75 38 0f
Jan 22 20:23:17 router kernel: RIP
80345195{xfrm4_output_finish+293} RSP 810030c19a78
Jan 22 20:23:17 router kernel: CR2: 009c
Jan 22 20:24:42 router rmmod: ERROR: Module xfrm4_tunnel is in use
Steps to reproduce: With openswan running use two tunnels togheter, the
problem occours on both gateway but separately
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who 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: sky2 0.11 instability
Stephen Hemminger schrieb: You might try adjusting the interrupt coalescing parameters with ethtool -C eth0 ... But I can't give you hard guidelines as to what would make it better. I have a debug patch, but it needs work still. ethtool -C bridgeint1 rx-frames 255 rx-frames-irq 255 rx-usecs 0 rx-usecs-irq 0 tx-usecs 0 tx-frames 255 always results in a hang after less than 2 minutes if the network activity is not too high (about 100-600 packets/s). So yes, I can trigger this sucker on demand and give you all the debugging you need. Do you have any idea what the out-of-tree sk98lin did differently? Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: any way to easily map struct socket * to userspace fd?
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Sat, 21 Jan 2006 13:15:49 +0300 On Fri, Jan 20, 2006 at 05:06:36PM -0600, Christopher Friesen ([EMAIL PROTECTED]) wrote: I've been asked if there is any way to map a struct socket * in kernelspace, to the userspace fd that corresponds to it. I came up with looping through current-files-fd[i] and matching it against socket-file--if they match then i is the fd. Is there a better way? struct file *file = fget(fd)/fget_light(fd); struct inode *inode = igrab(file-f_dentry-d_inode); struct socket *socket = SOCKET_I(inode); He wants to go the other direction, from socket to file descriptor. Typically people doing this are implementing desktop notifiers for socket activity and stuff like that in order to fill in a feature checkbox that Windows happens to have... In my opinion, such things have little sense because of the one to many mapping from sockets to filedescriptors. Which app gets to make a decision or get the notifier? There is no good clean answer to that question. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem
Andrew Morton wrote:
Begin forwarded message:
Date: Sun, 22 Jan 2006 12:02:22 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 5936] New: Openswan tunnels + netfilter problem
http://bugzilla.kernel.org/show_bug.cgi?id=5936
Summary: Openswan tunnels + netfilter problem
Kernel Version: 2.6.16-rc1
Status: NEW
Severity: high
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL PROTECTED]
Jan 22 20:23:17 router kernel: Unable to handle kernel NULL pointer
dereference at 009c RIP:
Jan 22 20:23:17 router kernel: 80345195{xfrm4_output_finish+293}
Jan 22 20:23:17 router kernel: PGD 35377067 PUD 0
Jan 22 20:23:17 router kernel: Oops: [6]
Jan 22 20:23:17 router kernel: CPU 0
Jan 22 20:23:17 router kernel: Modules linked in: af_key deflate
zlib_deflate twofish serpent blowfish sha256 crypto_null ae$
Please post your iptables rules and the full list of loaded modules.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] schedule SHAPER for removal
On Sun, Jan 22, 2006 at 07:32:56PM +0100, Arjan van de Ven wrote: The only supported combinations are distributions with the kernels they ship. I think you're being unreasonable here. Absolutely. The statement is also completely false. Fedora rebases to a new point release shortly after they become available (in reality usually just after the .1 -stable release). At least part of the reason is that with 3-4000 changes going in upstream per release, the amount of work backporting fixes is just totally impractical. I just looked over feature-removal-schedule.txt for things that are probably going to impact us due to our rebasing. The only thing there that could cause major heartburn for FC4 users is Dominik's proposal to remove PCMCIA control ioctl (scheduled for Last November). Migrating already working setups from pcmcia-cs to pcmcia-utils when an update kernel gets pushed out gives me the creeps, especially as we're still not at a state where 'everything works' in our FC5-development branch. (I'd feel more comfortable retrofitting this after its been through a stable distro release and got a lot of exposure). So if the old pcmcia code got ripped out in 2.6.17, chances are I'd carry a 'revert this bunch of changes' patch for future FC4 updates. Not that big a deal, but probably a days work to build test, plus ongoing maintainence to rediff the patch on future updates. Pretty much everything else there is either only of impact to out-of-tree modules, for which I couldn't really care less, or they're bits of functionality that we have moved off already, or have disabled. (Though I'm not entirely sure everything has moved off of V4L1 yet without going and checking) In addition I think that in case such a feature isn't actually harmful of further development (for example, it could be because it's fundamentally broken locking wise, or holding back major improvements) then a longer period of warnings should be no problem. Together with that should probably be something to ask distros to stop enabling the feature asap, or at least communicate it as deprecated in their respective release notes. Sounds very practical, and something I'd be totally open to doing for Fedora. 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
[NET]: Reduce size of struct sk_buff on 64 bit architectures
[NET]: Reduce size of struct sk_buff on 64 bit architectures
Move skb-nf_mark next to skb-tc_index to remove a 4 byte hole between
skb-nfmark and skb-nfct and another one between skb-users and skb-head
when CONFIG_NETFILTER, CONFIG_NET_SCHED and CONFIG_NET_CLS_ACT are enabled.
For all other combinations the size stays the same.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 15e9ad873bcf3f95c69ad014ffc08ccd5e826601
tree a1fd77ae7e1addaf51ebda6525bee9cdf6615288
parent 18a4144028f056b77d6576d4eb284246e9c7ea97
author Patrick McHardy [EMAIL PROTECTED] Sun, 22 Jan 2006 23:07:25 +0100
committer Patrick McHardy [EMAIL PROTECTED] Sun, 22 Jan 2006 23:07:25 +0100
include/linux/skbuff.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index ad7cc22..838ce0f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -270,7 +270,6 @@ struct sk_buff {
void(*destructor)(struct sk_buff *skb);
#ifdef CONFIG_NETFILTER
- __u32 nfmark;
struct nf_conntrack *nfct;
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
struct sk_buff *nfct_reasm;
@@ -278,6 +277,7 @@ struct sk_buff {
#ifdef CONFIG_BRIDGE_NETFILTER
struct nf_bridge_info *nf_bridge;
#endif
+ __u32 nfmark;
#endif /* CONFIG_NETFILTER */
#ifdef CONFIG_NET_SCHED
__u16 tc_index; /* traffic control index */
Re: sky2 0.11 instability
Carl-Daniel Hailfinger schrieb: Stephen Hemminger schrieb: You might try adjusting the interrupt coalescing parameters with ethtool -C eth0 ... But I can't give you hard guidelines as to what would make it better. I have a debug patch, but it needs work still. After experimenting further, the following command will always hang the card after 2-3 seconds: ethtool -C bridgeint1 rx-frames 63 rx-frames-irq 63 rx-usecs 0 rx-usecs-irq 0 tx-usecs 0 tx-frames 63 Crude activity log (1 second interval) follows: interrupts RX packets TX packets # normal activity 18225503 1828622 2084564 18225914 1828932 2084939 18226422 1829361 2085422 18226875 1829694 2085832 18227286 1830012 2086183 18227622 1830270 2086465 18227963 1830541 2086738 18228340 1830827 2087057 18228710 1831107 2087382 18229091 1831390 2087694 18229467 1831677 2088002 18229835 1831954 2088338 # ethtool starts now 18230143 1832249 2088647 18230146 1832434 2088799 18230146 1832462 2088799 18230146 1832462 2088799 18230146 1832462 2088799 18230146 1832462 2088799 18230146 1832462 2088799 18230146 1832462 2088799 18230146 1832462 2088799 18230146 1832462 2088799 18230146 1832462 2088799 18230146 1832462 2088799 # the netdev watchdog triggers now So yes, I can trigger this sucker on demand and give you all the debugging you need. Do you have any idea what the out-of-tree sk98lin v8.14.3.3 did differently? Regards, Carl-Daniel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is packet split? Same as copybreak?
Hi Jesse, Thanks for your reply. I still have two questions about packet splittng: Question one: when e1000 does packet splitting, it seems packet data buffer is splitted into three parts, but how does e1000 decide how many parts needed to be splitted? Question two: It seems e1000 does not split those parts into equal size, why not choose equal size for each splitted part? Regards, John From: Jesse Brandeburg [EMAIL PROTECTED] To: John Smith [EMAIL PROTECTED] CC: netdev@vger.kernel.org Subject: Re: What is packet split? Same as copybreak? Date: Sat, 21 Jan 2006 23:49:04 -0800 On 1/20/06, John Smith [EMAIL PROTECTED] wrote: Hi, I just have some questions about the packet splitting which is supported by some PCI-express platforms. It seems the packet data buffer part (header and payload) is splitted into several parts and stored into different buffers while PCI-X NIC use 2K data buffer for every packet. sounds like you're talking about e1000, so I'll answer. My question is: what is the purpose of this packet splitting? It seems each splitted part has different size, why not choose a uniform size for each part? the major purpose is to have the data aligned to a 4k boundary, and to have a seperate allocation for the network header. It really seems to help most for decreasing cpu utilization, AFAICT. It seems it serve the same purpose as copybreak. Can anyone please me give some more hints. I believe it does serve much the same purpose, but copybreak optimizes receive socket buffer utilization (thanks to davem for pointing that out) esp if a dma device allocates a large amount of space (say for jumbo frame reception) and dev_alloc_skb forces an increase in allocation size to the next power of 2. conceiveably it could give you some efficiency due to multiple TCP/IP header buffers in the same page. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
