[PATCH 2.6.21 3/4] cxgb3 - Tighten xgmac workaround
From: Divy Le Ray <[EMAIL PROTECTED]>
Run the watchdog task when the link is up.
Flush the XGMAC Tx FIFO when the link drops.
Also remove a statistics update that should have gone
in the previous modification of xgmac.c.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c | 16 +---
drivers/net/cxgb3/regs.h |4
drivers/net/cxgb3/xgmac.c |1 -
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 145b67c..512daf7 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -185,16 +185,26 @@ void t3_os_link_changed(struct adapter *
int speed, int duplex, int pause)
{
struct net_device *dev = adapter->port[port_id];
+ struct port_info *pi = netdev_priv(dev);
+ struct cmac *mac = &pi->mac;
/* Skip changes from disabled ports. */
if (!netif_running(dev))
return;
if (link_stat != netif_carrier_ok(dev)) {
- if (link_stat)
+ if (link_stat) {
+ t3_set_reg_field(adapter,
+A_XGM_TXFIFO_CFG + mac->offset,
+F_ENDROPPKT, 0);
netif_carrier_on(dev);
- else
+ } else {
netif_carrier_off(dev);
+ t3_set_reg_field(adapter,
+A_XGM_TXFIFO_CFG + mac->offset,
+F_ENDROPPKT, F_ENDROPPKT);
+ }
+
link_report(dev);
}
}
@@ -2119,7 +2129,7 @@ static void check_t3b2_mac(struct adapte
continue;
status = 0;
- if (netif_running(dev))
+ if (netif_running(dev) && netif_carrier_ok(dev))
status = t3b2_mac_watchdog_task(&p->mac);
if (status == 1)
p->mac.stats.num_toggled++;
diff --git a/drivers/net/cxgb3/regs.h b/drivers/net/cxgb3/regs.h
index b38629a..f8be41c 100644
--- a/drivers/net/cxgb3/regs.h
+++ b/drivers/net/cxgb3/regs.h
@@ -1940,6 +1940,10 @@
#define V_TXFIFOTHRESH(x) ((x) << S_TXFIFOTHRESH)
+#define S_ENDROPPKT21
+#define V_ENDROPPKT(x) ((x) << S_ENDROPPKT)
+#define F_ENDROPPKTV_ENDROPPKT(1U)
+
#define A_XGM_SERDES_CTRL 0x890
#define A_XGM_SERDES_CTRL0 0x8e0
diff --git a/drivers/net/cxgb3/xgmac.c b/drivers/net/cxgb3/xgmac.c
index 2b42c13..94aaff0 100644
--- a/drivers/net/cxgb3/xgmac.c
+++ b/drivers/net/cxgb3/xgmac.c
@@ -471,7 +471,6 @@ const struct mac_stats *t3_mac_update_st
RMON_UPDATE(mac, rx_symbol_errs, RX_SYM_CODE_ERR_FRAMES);
RMON_UPDATE(mac, rx_too_long, RX_OVERSIZE_FRAMES);
- mac->stats.rx_too_long += RMON_READ(mac, A_XGM_RX_MAX_PKT_SIZE_ERR_CNT);
v = RMON_READ(mac, A_XGM_RX_MAX_PKT_SIZE_ERR_CNT);
if (mac->adapter->params.rev == T3_REV_B2)
-
To unsubscribe from this list: send 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.21 4/4] cxgb3 - Firwmare update
From: Divy Le Ray <[EMAIL PROTECTED]>
Introduce FW micro version.
Bump up FW version to 3.3.0
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_main.c |4 ++--
drivers/net/cxgb3/version.h|5 -
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 512daf7..26240fd 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -721,7 +721,7 @@ static void bind_qsets(struct adapter *a
}
}
-#define FW_FNAME "t3fw-%d.%d.bin"
+#define FW_FNAME "t3fw-%d.%d.%d.bin"
static int upgrade_fw(struct adapter *adap)
{
@@ -731,7 +731,7 @@ static int upgrade_fw(struct adapter *ad
struct device *dev = &adap->pdev->dev;
snprintf(buf, sizeof(buf), FW_FNAME, FW_VERSION_MAJOR,
-FW_VERSION_MINOR);
+FW_VERSION_MINOR, FW_VERSION_MICRO);
ret = request_firmware(&fw, buf, dev);
if (ret < 0) {
dev_err(dev, "could not upgrade firmware: unable to load %s\n",
diff --git a/drivers/net/cxgb3/version.h b/drivers/net/cxgb3/version.h
index 82278f8..042e27e 100644
--- a/drivers/net/cxgb3/version.h
+++ b/drivers/net/cxgb3/version.h
@@ -36,6 +36,9 @@
#define DRV_NAME "cxgb3"
/* Driver version */
#define DRV_VERSION "1.0-ko"
+
+/* Firmware version */
#define FW_VERSION_MAJOR 3
-#define FW_VERSION_MINOR 2
+#define FW_VERSION_MINOR 3
+#define FW_VERSION_MICRO 0
#endif /* __CHELSIO_VERSION_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
[PATCH 2.6.21 2/4] cxgb3 - detect NIC only adapters
From: Divy Le Ray <[EMAIL PROTECTED]>
Differentiate NIC only adapters from RNICs.
Initialize offload capabilities for RNICs only.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h |6 +++---
drivers/net/cxgb3/cxgb3_main.c |8
drivers/net/cxgb3/mc5.c|3 +++
drivers/net/cxgb3/sge.c|2 +-
drivers/net/cxgb3/t3_hw.c | 24 ++--
5 files changed, 29 insertions(+), 14 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index 38a0565..97128d8 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -112,8 +112,7 @@ enum {
};
enum {
- SUPPORTED_OFFLOAD = 1 << 24,
- SUPPORTED_IRQ = 1 << 25
+ SUPPORTED_IRQ = 1 << 24
};
enum { /* adapter interrupt-maintained statistics */
@@ -405,6 +404,7 @@ struct adapter_params {
unsigned int stats_update_period; /* MAC stats accumulation
period */
unsigned int linkpoll_period; /* link poll period in 0.1s */
unsigned int rev; /* chip revision */
+ unsigned int offload;
};
enum { /* chip revisions */
@@ -605,7 +605,7 @@ static inline int is_10G(const struct ad
static inline int is_offload(const struct adapter *adap)
{
- return adapter_info(adap)->caps & SUPPORTED_OFFLOAD;
+ return adap->params.offload;
}
static inline unsigned int core_ticks_per_usec(const struct adapter *adap)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index b82544e..145b67c 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -407,7 +407,7 @@ static void quiesce_rx(struct adapter *a
static int setup_sge_qsets(struct adapter *adap)
{
int i, j, err, irq_idx = 0, qset_idx = 0, dummy_dev_idx = 0;
- unsigned int ntxq = is_offload(adap) ? SGE_TXQ_PER_SET : 1;
+ unsigned int ntxq = SGE_TXQ_PER_SET;
if (adap->params.rev > 0 && !(adap->flags & USING_MSI))
irq_idx = -1;
@@ -922,7 +922,7 @@ static int cxgb_open(struct net_device *
return err;
set_bit(pi->port_id, &adapter->open_device_map);
- if (!ofld_disable) {
+ if (is_offload(adapter) && !ofld_disable) {
err = offload_open(dev);
if (err)
printk(KERN_WARNING
@@ -2270,9 +2270,9 @@ static void __devinit print_port_info(st
if (!test_bit(i, &adap->registered_device_map))
continue;
- printk(KERN_INFO "%s: %s %s RNIC (rev %d) %s%s\n",
+ printk(KERN_INFO "%s: %s %s %sNIC (rev %d) %s%s\n",
dev->name, ai->desc, pi->port_type->desc,
- adap->params.rev, buf,
+ is_offload(adap) ? "R" : "", adap->params.rev, buf,
(adap->flags & USING_MSIX) ? " MSI-X" :
(adap->flags & USING_MSI) ? " MSI" : "");
if (adap->name == dev->name && adap->params.vpd.mclk)
diff --git a/drivers/net/cxgb3/mc5.c b/drivers/net/cxgb3/mc5.c
index 644d62e..84c1ffa 100644
--- a/drivers/net/cxgb3/mc5.c
+++ b/drivers/net/cxgb3/mc5.c
@@ -328,6 +328,9 @@ int t3_mc5_init(struct mc5 *mc5, unsigne
unsigned int tcam_size = mc5->tcam_size;
struct adapter *adap = mc5->adapter;
+ if (!tcam_size)
+ return 0;
+
if (nroutes > MAX_ROUTES || nroutes + nservers + nfilters > tcam_size)
return -EINVAL;
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c
index c237834..027ab2c 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -2631,7 +2631,7 @@ int t3_sge_alloc_qset(struct adapter *ad
q->txq[TXQ_ETH].stop_thres = nports *
flits_to_desc(sgl_len(MAX_SKB_FRAGS + 1) + 3);
- if (ntxq == 1) {
+ if (!is_offload(adapter)) {
#ifdef USE_RX_PAGE
q->fl[0].buf_size = RX_PAGE_SIZE;
#else
diff --git a/drivers/net/cxgb3/t3_hw.c b/drivers/net/cxgb3/t3_hw.c
index 791ed6d..d83f075 100644
--- a/drivers/net/cxgb3/t3_hw.c
+++ b/drivers/net/cxgb3/t3_hw.c
@@ -438,23 +438,23 @@ static const struct adapter_info t3_adap
{2, 0, 0, 0,
F_GPIO2_OEN | F_GPIO4_OEN |
F_GPIO2_OUT_VAL | F_GPIO4_OUT_VAL, F_GPIO3 | F_GPIO5,
-SUPPORTED_OFFLOAD,
+0,
&mi1_mdio_ops, "Chelsio PE9000"},
{2, 0, 0, 0,
F_GPIO2_OEN | F_GPIO4_OEN |
F_GPIO2_OUT_VAL | F_GPIO4_OUT_VAL, F_GPIO3 | F_GPIO5,
-SUPPORTED_OFFLOAD,
+0,
&mi1_mdio_ops, "Chelsio T302"},
{1, 0, 0, 0,
F_GPIO1_OEN | F_GPIO6_OEN | F_GPIO7_OEN | F_GPIO10_OEN |
F_GPIO1_OUT_VAL | F_GPIO6_OUT_VAL | F_GPIO10_OUT_VAL, 0,
-SUPPORTED_1baseT_Full | SUPPORTED_AUI | SUPPORTED_OFFLOAD,
+SUPPORTED_1baseT_Full | SUPPORTED_AUI,
&mi1_mdio_ext_ops, "C
[PATCH 2.6.21 1/4] cxgb3 - Safeguard TCAM size usage
From: Divy Le Ray <[EMAIL PROTECTED]>
Ensure that the TCAM active region size is at least 16.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h|3 +++
drivers/net/cxgb3/cxgb3_main.c|7 +--
drivers/net/cxgb3/cxgb3_offload.c |4 +++-
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cxgb3/common.h b/drivers/net/cxgb3/common.h
index 85e5543..38a0565 100644
--- a/drivers/net/cxgb3/common.h
+++ b/drivers/net/cxgb3/common.h
@@ -358,6 +358,9 @@ enum {
MC5_MODE_72_BIT = 2
};
+/* MC5 min active region size */
+enum { MC5_MIN_TIDS = 16 };
+
struct vpd_params {
unsigned int cclk;
unsigned int mclk;
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index d553836..b82544e 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -485,12 +485,14 @@ static ssize_t show_##name(struct device
static ssize_t set_nfilters(struct net_device *dev, unsigned int val)
{
struct adapter *adap = dev->priv;
+ int min_tids = is_offload(adap) ? MC5_MIN_TIDS : 0;
if (adap->flags & FULL_INIT_DONE)
return -EBUSY;
if (val && adap->params.rev == 0)
return -EINVAL;
- if (val > t3_mc5_size(&adap->mc5) - adap->params.mc5.nservers)
+ if (val > t3_mc5_size(&adap->mc5) - adap->params.mc5.nservers -
+ min_tids)
return -EINVAL;
adap->params.mc5.nfilters = val;
return 0;
@@ -508,7 +510,8 @@ static ssize_t set_nservers(struct net_d
if (adap->flags & FULL_INIT_DONE)
return -EBUSY;
- if (val > t3_mc5_size(&adap->mc5) - adap->params.mc5.nfilters)
+ if (val > t3_mc5_size(&adap->mc5) - adap->params.mc5.nfilters -
+ MC5_MIN_TIDS)
return -EINVAL;
adap->params.mc5.nservers = val;
return 0;
diff --git a/drivers/net/cxgb3/cxgb3_offload.c
b/drivers/net/cxgb3/cxgb3_offload.c
index f6ed033..eed7a48 100644
--- a/drivers/net/cxgb3/cxgb3_offload.c
+++ b/drivers/net/cxgb3/cxgb3_offload.c
@@ -553,7 +553,9 @@ int cxgb3_alloc_atid(struct t3cdev *tdev
struct tid_info *t = &(T3C_DATA(tdev))->tid_maps;
spin_lock_bh(&t->atid_lock);
- if (t->afree) {
+ if (t->afree &&
+ t->atids_in_use + atomic_read(&t->tids_in_use) + MC5_MIN_TIDS <=
+ t->ntids) {
union active_open_entry *p = t->afree;
atid = (p - t->atid_tab) + t->atid_base;
-
To unsubscribe from this list: send 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.21 0/4] cxgb3 - bug fixes
Hi Jeff, I'm submitting a set of bug fixes for inclusion in 2.6.21. The patches are built against Linus'git tree. Here is a brief description: - Ensure that the on-board TCAM's active region size is always greater than 16 - the driver now recognizes NIC only adapters - tighten the MAC hang workaround - bump up firmware version Cheers, Divy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: Add TCP connection abort IOCTL
On 30/03/07, Rick Jones <[EMAIL PROTECTED]> wrote: If the switchover from active to standby is "commanded" then there is the opportunity to "tell" the applications on the server to close their connections - either explicitly with some sort of defined interface, or implicitly by killing the processes. Then the IP can be brought-up on the standby and processes started/enabled/whatever and the clients can establish their new connections. The ioctl here (at least if it is like the tcp_discon options in HP-UX/Solaris) wouldn't be any better than just killing the process in so far as what happens on the network - in fact, it could be worse since the RST will not be retransmitted if lost, but FINs would. So, the ioctl could still leave clients twisting in the ether waiting for their application-level heartbeats to kick-in anyway. Heck, depending on their heartbeat lengths, even the FIN stuff if lost could leave them depending on their heartbeats. If the switchover from active to standby is "uncommanded" it probably means the primary went belly-up which means you don't have the opportunity to make an ioctl call anyway, and you are back to the heartbeats. rick jones What I meant is - it could be used on ***client***. Because clients are left stranded with invalid connections when a primary fails (your "uncommanded" switchover scenario). If you wait for them to timeout, that will indeed happen, but it takes time and you are not back online as fast as you would like. If cluster's services running on a client already know about the failover (by means of "heartbeat" and observing change in cluster membership), then they can propagate that knowledge to all processes uneccessarily blocked in their socket calls towards the failed IP address. If these connections are forcibly disconnected, the respective sockets' calls would return with error code and their processes can reconnect in few seconds after the failure and continue to do what they are meant to do. predrag - To unsubscribe from this list: send 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: [3/4] 2.6.21-rc5: known regressions (v2)
On 3/31/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: Subject: ThinkPad doesn't resume from suspend to RAM References : http://lkml.org/lkml/2007/2/27/80 http://lkml.org/lkml/2007/2/28/348 Submitter : Jens Axboe <[EMAIL PROTECTED]> Jeff Chua <[EMAIL PROTECTED]> Status : unknown Fixed with CONFIG_NO_HZ unset and patch from Maxim (http://lkml.org/lkml/2007/3/29/108). Thanks, Jeff, - To unsubscribe from this list: send 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: more iproute2 issues (not critical)
Ooops, sorry, it seems my fault, no library exist on this system.
But i guess it must not coredump in this case? Is it possible to check if
library not exist and just print some nice message?
It is trivial i guess.
On Sat, 31 Mar 2007 05:26:00 +0300, Denys wrote
> While running tc monitor
>
> defaulthost ~ #/sbin/tc2 monitor
> qdisc prio 1: dev if92 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1
> 1 1 1 1 qdisc tbf 2: dev if92 parent 1:1 rate 121600bit burst 512Kb
> peakrate 1280Kbit minburst 16Kb lat 500.0ms filter dev if92 parent
> 1: protocol ip pref 5 u32 fh 800::800 order 2048 key ht 800 bkt 0
> flowid 3:1 match c2929918/ at 12 filter dev if92 parent 1:
> protocol ip pref 5 u32 fh 800::801 order 2049 key ht 800 bkt 0
> flowid 3:1 match c292991a/ at 12 filter dev if92 parent 1:
> protocol ip pref 5 u32 fh 800::802 order 2050 key ht 800 bkt 0
> flowid 3:1 match 02020266/ at 12 filter dev if92 parent 1:
> protocol ip pref 5 u32 fh 800::803 order 2051 key ht 800 bkt 0
> flowid 3:1 match 02020269/ at 12 filter dev if92 parent 1:
> protocol ip pref 5 u32 fh 800::804 order 2052 key ht 800 bkt 0
> flowid 3:1 match 0202026a/ at 12 filter dev if92 parent 1:
> protocol ip pref 10 u32 fh 801::800 order 2048 key ht 801 bkt 0
> flowid 2:1 match / at 16 deleted filter dev ifb0
> parent 1: protocol ip pref 117 fw deleted class htb 1:117 dev ifb0
> root leaf 117: prio 0 rate 32000bit ceil 32000bit burst 1604b cburst
> 1604b class htb 1:117 dev ifb0 root prio 0 rate 32000bit ceil
> 32000bit burst 1604b cburst 1604b qdisc sfq 117: dev ifb0 parent
> 1:117 limit 128p quantum 1514b perturb 5sec filter dev ifb0 parent
> 1: protocol ip pref 117 fw handle 0x75 classid 1:117 qdisc ingress
> : dev if92 parent :fff1 filter dev if92
> parent : protocol ip pref 5 u32 fh 800::800 order 2048 key ht
> 800 bkt 0 flowid 1:1 match 02020266/ at 16 filter dev if92
> parent : protocol ip pref 5 u32 fh 800::801 order 2049 key ht
> 800 bkt 0 flowid 1:1 match 02020269/ at 16 filter dev if92
> parent : protocol ip pref 5 u32 fh 800::802 order 2050 key ht
> 800 bkt 0 flowid 1:1 match 0202026a/ at 16 filter dev if92
> parent : protocol ip pref 5 u32 fh 800::803 order 2051 key ht
> 800 bkt 0 flowid 1:1 match c2929918/ at 16 filter dev if92
> parent : protocol ip pref 5 u32 fh 800::804 order 2052 key ht
> 800 bkt 0 flowid 1:1 match c292991a/ at 16 filter dev if92
> parent : protocol ip pref 10 u32 fh 801::800 order 2048 key ht
> 801 bkt 0 flowid 1:1 match / at 0action
> order 1: tablename: mangle hook: NF_IP_PRE_ROUTING Segmentation
> fault (core dumped)
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x08069f38 in get_target_name (name=0xbfa397f2 "MARK") at m_ipt.c:219
> 219 char path[strlen(lib_dir) + sizeof ("/libipt_.so") +
> strlen(name)];
>
> Do you need "bt full" ?
> Compiled from git tree, but not latest (a little bit more fresh than
> latest release).
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Virtual ISP S.A.L.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
more iproute2 issues (not critical)
While running tc monitor
defaulthost ~ #/sbin/tc2 monitor
qdisc prio 1: dev if92 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc tbf 2: dev if92 parent 1:1 rate 121600bit burst 512Kb peakrate 1280Kbit
minburst 16Kb lat 500.0ms
filter dev if92 parent 1: protocol ip pref 5 u32 fh 800::800 order 2048 key
ht 800 bkt 0 flowid 3:1
match c2929918/ at 12
filter dev if92 parent 1: protocol ip pref 5 u32 fh 800::801 order 2049 key
ht 800 bkt 0 flowid 3:1
match c292991a/ at 12
filter dev if92 parent 1: protocol ip pref 5 u32 fh 800::802 order 2050 key
ht 800 bkt 0 flowid 3:1
match 02020266/ at 12
filter dev if92 parent 1: protocol ip pref 5 u32 fh 800::803 order 2051 key
ht 800 bkt 0 flowid 3:1
match 02020269/ at 12
filter dev if92 parent 1: protocol ip pref 5 u32 fh 800::804 order 2052 key
ht 800 bkt 0 flowid 3:1
match 0202026a/ at 12
filter dev if92 parent 1: protocol ip pref 10 u32 fh 801::800 order 2048 key
ht 801 bkt 0 flowid 2:1
match / at 16
deleted filter dev ifb0 parent 1: protocol ip pref 117 fw
deleted class htb 1:117 dev ifb0 root leaf 117: prio 0 rate 32000bit ceil
32000bit burst 1604b cburst 1604b
class htb 1:117 dev ifb0 root prio 0 rate 32000bit ceil 32000bit burst 1604b
cburst 1604b
qdisc sfq 117: dev ifb0 parent 1:117 limit 128p quantum 1514b perturb 5sec
filter dev ifb0 parent 1: protocol ip pref 117 fw handle 0x75 classid 1:117
qdisc ingress : dev if92 parent :fff1
filter dev if92 parent : protocol ip pref 5 u32 fh 800::800 order 2048
key ht 800 bkt 0 flowid 1:1
match 02020266/ at 16
filter dev if92 parent : protocol ip pref 5 u32 fh 800::801 order 2049
key ht 800 bkt 0 flowid 1:1
match 02020269/ at 16
filter dev if92 parent : protocol ip pref 5 u32 fh 800::802 order 2050
key ht 800 bkt 0 flowid 1:1
match 0202026a/ at 16
filter dev if92 parent : protocol ip pref 5 u32 fh 800::803 order 2051
key ht 800 bkt 0 flowid 1:1
match c2929918/ at 16
filter dev if92 parent : protocol ip pref 5 u32 fh 800::804 order 2052
key ht 800 bkt 0 flowid 1:1
match c292991a/ at 16
filter dev if92 parent : protocol ip pref 10 u32 fh 801::800 order 2048
key ht 801 bkt 0 flowid 1:1
match / at 0
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
Segmentation fault (core dumped)
Program terminated with signal 11, Segmentation fault.
#0 0x08069f38 in get_target_name (name=0xbfa397f2 "MARK") at m_ipt.c:219
219 char path[strlen(lib_dir) + sizeof ("/libipt_.so") +
strlen(name)];
Do you need "bt full" ?
Compiled from git tree, but not latest (a little bit more fresh than latest
release).
-
To unsubscribe from this list: send 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] Ensure local assignment bit on tun device MAC addr
On Sat, 31 Mar 2007, Rusty Russell wrote: > This becomes especially important after the tun patch sitting in the -mm > tree is applied, but it works standalone. Please apply. (See netdev > posting Message-Id: <[EMAIL PROTECTED]>) > > == > The effect of this bug was made worse by Brian Braunstein's patch to keep > net_device.dev_addr and tun.dev_addr in sync. > > Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> Acked-by: James Morris <[EMAIL PROTECTED]> > > diff -r fd8c40f4f533 drivers/net/tun.c > --- a/drivers/net/tun.c Fri Mar 30 17:02:19 2007 +1000 > +++ b/drivers/net/tun.c Sat Mar 31 10:30:47 2007 +1000 > @@ -507,9 +507,7 @@ static int tun_set_iff(struct file *file > tun->flags = flags; > /* Be promiscuous by default to maintain previous behaviour. */ > tun->if_flags = IFF_PROMISC; > - /* Generate random Ethernet address. */ > - *(u16 *)tun->dev_addr = htons(0x00FF); > - get_random_bytes(tun->dev_addr + sizeof(u16), 4); > + random_ether_addr(tun->dev_addr); > memset(tun->chr_filter, 0, sizeof tun->chr_filter); > > tun_net_init(dev); > > > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Ensure local assignment bit on tun device MAC addr
This becomes especially important after the tun patch sitting in the -mm tree is applied, but it works standalone. Please apply. (See netdev posting Message-Id: <[EMAIL PROTECTED]>) == The effect of this bug was made worse by Brian Braunstein's patch to keep net_device.dev_addr and tun.dev_addr in sync. Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> diff -r fd8c40f4f533 drivers/net/tun.c --- a/drivers/net/tun.c Fri Mar 30 17:02:19 2007 +1000 +++ b/drivers/net/tun.c Sat Mar 31 10:30:47 2007 +1000 @@ -507,9 +507,7 @@ static int tun_set_iff(struct file *file tun->flags = flags; /* Be promiscuous by default to maintain previous behaviour. */ tun->if_flags = IFF_PROMISC; - /* Generate random Ethernet address. */ - *(u16 *)tun->dev_addr = htons(0x00FF); - get_random_bytes(tun->dev_addr + sizeof(u16), 4); + random_ether_addr(tun->dev_addr); memset(tun->chr_filter, 0, sizeof tun->chr_filter); tun_net_init(dev); - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tcp crash in net-2.6 tree
From: Thomas Graf <[EMAIL PROTECTED]> Date: Sat, 31 Mar 2007 00:10:54 +0200 > * David Miller <[EMAIL PROTECTED]> 2007-03-30 14:43 > > Let's not speculate, let's find out for sure if snd_una is > > surpassing high_seq while we're in this state. > > > > Andrew please give this debugging patch a spin, and also what > > is your workload? I'd like to play with it too. > > > > I've tried to code this patch so that if the bug triggers your > > machine shouldn't crash and burn completely, just spit out the > > log message. > > I'm running into the same bug as Andew, i was able to reproduce > using Dave's patch within minutes: > > TCP BUG: high_seq==NULL [c3c9cc54] q[c3c94edc] t[c3c9cc54] > > The after(snd_una, high_seq) check is not triggered. So tp->high_seq points to the tail packet end sequence. Ilpo does this clear things up? - To unsubscribe from this list: send 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: tcp crash in net-2.6 tree
From: Andrew Morton <[EMAIL PROTECTED]> Date: Fri, 30 Mar 2007 15:06:03 -0700 > > Andrew please give this debugging patch a spin, > > OK, will take a look at that this evening, hopefully. BTW, Thomas Graf can also reproduce this and he is about to post a log message from my patch. > distccd seems to be rather good at triggering networking problems - I think > that's the third one I've seen in the past few years. Agreed, I remember the other hairy problems distcc could trigger. - To unsubscribe from this list: send 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: tcp crash in net-2.6 tree
* David Miller <[EMAIL PROTECTED]> 2007-03-30 14:43 > Let's not speculate, let's find out for sure if snd_una is > surpassing high_seq while we're in this state. > > Andrew please give this debugging patch a spin, and also what > is your workload? I'd like to play with it too. > > I've tried to code this patch so that if the bug triggers your > machine shouldn't crash and burn completely, just spit out the > log message. I'm running into the same bug as Andew, i was able to reproduce using Dave's patch within minutes: TCP BUG: high_seq==NULL [c3c9cc54] q[c3c94edc] t[c3c9cc54] The after(snd_una, high_seq) check is not triggered. - To unsubscribe from this list: send 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: tcp crash in net-2.6 tree
On Fri, 30 Mar 2007 14:43:47 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote: > From: "Ilpo_J__rvinen" <[EMAIL PROTECTED]> > Date: Fri, 30 Mar 2007 17:33:28 +0300 (EEST) > > > If there is nothing at high_seq (application hasn't given any data to/past > > that point), the search fails to find any skb and returns NULL... But I > > have no idea how this can happen? As TCP does after(skb->seq, > > tp->high_seq) (even in the quoted code block) guaranteeing that something > > is there after the high_seq for TCP to step temporarily on... So at least > > one skb should have it's end_seq after tp->high_seq (actually there > > should be at least two valid skbs after tp->high_seq since the used > > sequence number space does not have holes), which should be enough to get > > an existing skb from write_queue_find?! > > > > I also checked all call paths to tcp_update_scoreboard_fack to make sure > > that snd_una hasn't gone past high_seq and found nothing suspicious (and > > that wouldn't return NULL anyway I think)... > > Let's not speculate, let's find out for sure if snd_una is > surpassing high_seq while we're in this state. > > Andrew please give this debugging patch a spin, OK, will take a look at that this evening, hopefully. > and also what > is your workload? I'd like to play with it too. I use an x86_64 box as a distcc server: shove .i fiels at it, get .o files sent back. I was using it thusly and noticed that it had died. Also, an x86_64 box I have here at google was hanging yesterday and that appears to have stopped since I removed a couple of x86_64 patches and git-net. I'm in the process of working out what fixed it... > I've tried to code this patch so that if the bug triggers your > machine shouldn't crash and burn completely, just spit out the > log message. ok.. I don't know how repeatable the distcc crash is. We'll see. distccd seems to be rather good at triggering networking problems - I think that's the third one I've seen in the past few years. - To unsubscribe from this list: send 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: tcp crash in net-2.6 tree
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Fri, 30 Mar 2007 17:33:28 +0300 (EEST)
> If there is nothing at high_seq (application hasn't given any data to/past
> that point), the search fails to find any skb and returns NULL... But I
> have no idea how this can happen? As TCP does after(skb->seq,
> tp->high_seq) (even in the quoted code block) guaranteeing that something
> is there after the high_seq for TCP to step temporarily on... So at least
> one skb should have it's end_seq after tp->high_seq (actually there
> should be at least two valid skbs after tp->high_seq since the used
> sequence number space does not have holes), which should be enough to get
> an existing skb from write_queue_find?!
>
> I also checked all call paths to tcp_update_scoreboard_fack to make sure
> that snd_una hasn't gone past high_seq and found nothing suspicious (and
> that wouldn't return NULL anyway I think)...
Let's not speculate, let's find out for sure if snd_una is
surpassing high_seq while we're in this state.
Andrew please give this debugging patch a spin, and also what
is your workload? I'd like to play with it too.
I've tried to code this patch so that if the bug triggers your
machine shouldn't crash and burn completely, just spit out the
log message.
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 97b9be2..605b5a8 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1936,14 +1936,32 @@ static void tcp_update_scoreboard_fack(struct sock *sk,
u32 entry_seq,
if ((!IsFack(tp) || !tcp_skb_timedout(sk, skb)) &&
after(TCP_SKB_CB(skb)->seq, tp->high_seq)) {
+ if (after(tp->snd_una, tp->high_seq)) {
+ printk(KERN_ALERT "TCP BUG: snd_una>high_seq "
+ "[%08x:%08x]\n",
+ tp->snd_una, tp->high_seq);
+ goto skip;
+ }
/* RFC: should we have find_below? */
skb = tcp_write_queue_find(sk, tp->high_seq);
+ if (!skb) {
+ struct sk_buff *head = tcp_write_queue_head(sk);
+ struct sk_buff *tail = tcp_write_queue_tail(sk);
+ printk(KERN_ALERT "TCP BUG: high_seq==NULL "
+ "[%08x] q[%08x] t[%08x]\n",
+ tp->high_seq,
+ TCP_SKB_CB(head)->seq,
+ TCP_SKB_CB(tail)->end_seq);
+ goto skip;
+
+ }
not_marked_skb = skb;
skb = tcp_write_queue_prev(sk, skb);
/* Timedout top is again uncertain? */
if (tcp_skb_timedout(sk, skb))
timedout_continue = 1;
}
+skip:
/* RFC: ...else if (!tcp_skb_timedout) do skb fragmentation? */
/* Phase II: Marker */
-
To unsubscribe from this list: send 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.21-rc5-mm3: fix e1000 compilation
From: "Kok, Auke" <[EMAIL PROTECTED]> Date: Fri, 30 Mar 2007 10:27:50 -0700 > turns out that NETIF_F_TSO6 is defined even if CONFIG_IPV6 is turned > off, which is what broke e1000. That in itself might be a > problem. Perhaps this should be fixed in netdevice.h (gratuitous bad > inline patch below) but I'm not sure if people would appreciate > this, as it's rather ugly, and it gets all horrible when people > disable TCP protocol support... No, I don't think we should do this. We have the vlan acceleration flags available when 802.1Q is disabled, same situation, and just as valid. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[3/4] 2.6.21-rc5: known regressions (v2)
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: ThinkPad X60: resume no longer works (PCI related?) References : http://lkml.org/lkml/2007/3/13/3 Submitter : Dave Jones <[EMAIL PROTECTED]> Jeremy Fitzhardinge <[EMAIL PROTECTED]> Caused-By : PCI merge commit 78149df6d565c36675463352d0bfeb02b7a7 Handled-By : Eric W. Biederman <[EMAIL PROTECTED]> Rafael J. Wysocki <[EMAIL PROTECTED]> Status : problem is being debugged Subject: Suspend to RAM doesn't work anymore (ACPI?) References : http://lkml.org/lkml/2007/3/19/128 http://bugzilla.kernel.org/show_bug.cgi?id=8247 Submitter : Tobias Doerffel <[EMAIL PROTECTED]> Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]> Len Brown <[EMAIL PROTECTED]> Status : problem is being debugged Subject: SATA breakage on resume References : http://lkml.org/lkml/2007/3/7/233 Submitter : Thomas Gleixner <[EMAIL PROTECTED]> Soeren Sonnenburg <[EMAIL PROTECTED]> Status : unknown Subject: resume from RAM corrupts vesafb console References : http://lkml.org/lkml/2007/3/26/76 Submitter : Marcus Better <[EMAIL PROTECTED]> Handled-By : Pavel Machek <[EMAIL PROTECTED]> Status : problem is being debugged Subject: ThinkPad doesn't resume from suspend to RAM References : http://lkml.org/lkml/2007/2/27/80 http://lkml.org/lkml/2007/2/28/348 Submitter : Jens Axboe <[EMAIL PROTECTED]> Jeff Chua <[EMAIL PROTECTED]> Status : unknown Subject: MacBook Core Duo: suspend to memory wakeup hang References : http://bugzilla.kernel.org/show_bug.cgi?id=8272 Submitter : Mike Harris <[EMAIL PROTECTED]> Status : unknown Subject: suspend to disk hangs (skge) References : http://lkml.org/lkml/2007/3/27/212 Submitter : Michal Piotrowski <[EMAIL PROTECTED]> Caused-By : Stephen Hemminger <[EMAIL PROTECTED]> commit a504e64ab42bcc27074ea37405d06833ed6e0820 Status : unknown Subject: suspend to disk hangs (microcode driver) References : http://lkml.org/lkml/2007/3/16/126 Submitter : Maxim Levitsky <[EMAIL PROTECTED]> Caused-By : Rafael J. Wysocki <[EMAIL PROTECTED]> commit e3c7db621bed4afb8e231cb005057f2feb5db557 commit ed746e3b18f4df18afa3763155972c5835f284c5 commit 259130526c267550bc365d3015917d90667732f1 Handled-By : Rafael J. Wysocki <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/3/25/71 Status : patch available - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2/4] 2.6.21-rc5: known regressions (v2)
This email lists some known regressions in Linus' tree compared to 2.6.20. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject: snd_hda_intel doesn't work with ASUS M2V mainboard References : http://bugzilla.kernel.org/show_bug.cgi?id=8273 Submitter : Hans-Georg Rist <[EMAIL PROTECTED]> Status : unknown Subject: snd_intel8x0: divide error: References : http://lkml.org/lkml/2007/3/5/252 Submitter : Michal Piotrowski <[EMAIL PROTECTED]> Status : unknown Subject: hal daemon crashes after pulling a USB serial device References : http://www.opensubscriber.com/message/linux-usb-devel@lists.sourceforge.net/6369800.html Submitter : Andi Kleen <[EMAIL PROTECTED]> Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Status : problem is being debugged Subject: USB: iPod doesn't work (CONFIG_USB_SUSPEND) References : http://lkml.org/lkml/2007/3/21/320 Submitter : Tino Keitel <[EMAIL PROTECTED]> Caused-By : Marcelo Tosatti <[EMAIL PROTECTED]> commit 1d619f128ba911cd3e6d6ad3475f146eb92f5c27 Handled-By : Oliver Neukum <[EMAIL PROTECTED]> Status : problem is being debuggged Subject: USB: Oops when changing DVB-T adapter References : http://lkml.org/lkml/2007/3/9/212 Submitter : CIJOML <[EMAIL PROTECTED]> Status : unknown Subject: forcedeth: sporadic under-load crashes References : http://lkml.org/lkml/2007/3/26/63 Submitter : Ingo Molnar <[EMAIL PROTECTED]> Handled-By : Ingo Molnar <[EMAIL PROTECTED]> Ayaz Abdulla <[EMAIL PROTECTED]> Status : problem is being debugged - To unsubscribe from this list: send 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 19/19] e1000: major part of the new API changes
Stephen Hemminger wrote:
+s32
+e1000_alloc_zeroed_dev_spec_struct(struct e1000_hw *hw, u32 size)
+{
+ hw->dev_spec = kmalloc(size, GFP_KERNEL);
+
+ if (!hw->dev_spec)
+ return -ENOMEM;
+
+ memset(hw->dev_spec, 0, size);
+
+ return E1000_SUCCESS;
+}
This is what is wrong with a lot of the new code. It is written as
verbose as possible.
What is wrong with open coded
hw->dev_spec = kzalloc(size, GFP_KERNEL).
nothing, I'll make sure that we change this. Please remember that this code was
written over a period of about 1 year, and a lot of cleanups that happened in
other parts of e1000 may very well have been overlooked. Also, it may be "ugly"
but it's definately not wrong at all.
+
+void
+e1000_free_dev_spec_struct(struct e1000_hw *hw)
+{
+ if (!hw->dev_spec)
+ return;
+
+ kfree(hw->dev_spec);
+}
+
Almost looks like you contracted this out to someone paid by the LOC.
will fix, thanks for the comments.
Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: Add TCP connection abort IOCTL
If the switchover from active to standby is "commanded" then there is the opportunity to "tell" the applications on the server to close their connections - either explicitly with some sort of defined interface, or implicitly by killing the processes. Then the IP can be brought-up on the standby and processes started/enabled/whatever and the clients can establish their new connections. The ioctl here (at least if it is like the tcp_discon options in HP-UX/Solaris) wouldn't be any better than just killing the process in so far as what happens on the network - in fact, it could be worse since the RST will not be retransmitted if lost, but FINs would. So, the ioctl could still leave clients twisting in the ether waiting for their application-level heartbeats to kick-in anyway. Heck, depending on their heartbeat lengths, even the FIN stuff if lost could leave them depending on their heartbeats. If the switchover from active to standby is "uncommanded" it probably means the primary went belly-up which means you don't have the opportunity to make an ioctl call anyway, and you are back to the heartbeats. 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: [NET_SCHED]: cls_basic: fix memory leak in basic_destroy
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Fri, 30 Mar 2007 19:02:53 +0200 > [NET_SCHED]: cls_basic: fix memory leak in basic_destroy > > tp->root is not freed on destruction. > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Applied, thanks a lot Patrick. - To unsubscribe from this list: send 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: [NET] Change "not found" return value for rule lookup
From: Steven Whitehouse <[EMAIL PROTECTED]> Date: Fri, 30 Mar 2007 10:13:55 +0100 > >From 657baf6bbaa8302660d6b218149dcb5546b9b08c Mon Sep 17 00:00:00 2001 > From: Steven Whitehouse <[EMAIL PROTECTED]> > Date: Fri, 30 Mar 2007 09:06:34 +0100 > Subject: [PATCH] [NET] Change "not found" return value for rule lookup > > This changes the "not found" error return for the lookup > function to -ESRCH so that it can be distinguished from > the case where a rule or route resulting in -ENETUNREACH > has been found during the search. > > It fixes a bug where if DECnet was compiled with routing > support, but no routes were added to the routing table, > it was failing to fall back to endnode routing. > > Signed-off-by: Steven Whitehouse <[EMAIL PROTECTED]> > Signed-off-by: Patrick Caulfield <[EMAIL PROTECTED]> Applied, thanks Steven. - To unsubscribe from this list: send 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 19/19] e1000: major part of the new API changes
+s32
+e1000_alloc_zeroed_dev_spec_struct(struct e1000_hw *hw, u32 size)
+{
+ hw->dev_spec = kmalloc(size, GFP_KERNEL);
+
+ if (!hw->dev_spec)
+ return -ENOMEM;
+
+ memset(hw->dev_spec, 0, size);
+
+ return E1000_SUCCESS;
+}
This is what is wrong with a lot of the new code. It is written as
verbose as possible.
What is wrong with open coded
hw->dev_spec = kzalloc(size, GFP_KERNEL).
+
+void
+e1000_free_dev_spec_struct(struct e1000_hw *hw)
+{
+ if (!hw->dev_spec)
+ return;
+
+ kfree(hw->dev_spec);
+}
+
Almost looks like you contracted this out to someone paid by the LOC.
-
To unsubscribe from this list: send 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] netpoll: trapping fix/cleanup
CONFIG_NETPOLL_TRAP causes the TX queue controls to be completely bypassed in
the netpoll's "trapped" mode which easily causes overflows in the drivers with
short TX queues (most notably, in 8139too with its 4-deep queue).
Make this option more sensible by only bypassing TX softirq wakeup and remove
CONFIG_NETPOLL_RX option completely since there is *no* code depending on it.
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |5 -
include/linux/netdevice.h |8 +++-
2 files changed, 3 insertions(+), 10 deletions(-)
Index: linux-2.6/include/linux/netdevice.h
===
--- linux-2.6.orig/include/linux/netdevice.h
+++ linux-2.6/include/linux/netdevice.h
@@ -647,8 +647,10 @@ static inline void netif_start_queue(str
static inline void netif_wake_queue(struct net_device *dev)
{
#ifdef CONFIG_NETPOLL_TRAP
- if (netpoll_trap())
+ if (netpoll_trap()) {
+ clear_bit(__LINK_STATE_XOFF, &dev->state);
return;
+ }
#endif
if (test_and_clear_bit(__LINK_STATE_XOFF, &dev->state))
__netif_schedule(dev);
@@ -656,10 +658,6 @@ static inline void netif_wake_queue(stru
static inline void netif_stop_queue(struct net_device *dev)
{
-#ifdef CONFIG_NETPOLL_TRAP
- if (netpoll_trap())
- return;
-#endif
set_bit(__LINK_STATE_XOFF, &dev->state);
}
Index: linux-2.6/drivers/net/Kconfig
===
--- linux-2.6.orig/drivers/net/Kconfig
+++ linux-2.6/drivers/net/Kconfig
@@ -2928,11 +2928,6 @@ endif #NETDEVICES
config NETPOLL
def_bool NETCONSOLE
-config NETPOLL_RX
- bool "Netpoll support for trapping incoming packets"
- default n
- depends on NETPOLL
-
config NETPOLL_TRAP
bool "Netpoll traffic trapping"
default n
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: Add TCP connection abort IOCTL
On 30/03/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote: Predrag Hodoba wrote: > On 30/03/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote: >> David Miller wrote: >> > >> > Something being in the CGL specification is to me exactly a great >> > reason NOT to add it. That specification is so full of garbage it's >> > unbelievable. >> > >> > Thanks, you've given me one more reason not to even remotely consider >> > adding this feature. >> > >> Agreed, CGL is a vendor driven group that has always wanted to replicate >> proprietary misfeatures onto Linux. There is a real requirement to >> provide high availability but there should be no requirement to >> implement >> the solution in the same crap way as legacy Unix. > > OK, let's put aside CGL and legacy Unices. > > Still, I don't see how the case I mentioned can easily be handled. > (The case being - effective clean up of all affected client TCP > connections, following failover of the server IP address from active > to passive node in a highly available cluster). Why clean them up? The client connections will timeout and they can reconnect. Actively killing them early does nothing helpful. Just like the CGL requirement for forced unmount, the forced operation introduces a whole bunch of race conditions and shared file descriptor problems. Well, it depends on how fast you have to react on failure. For data-center grade high-availability it is, as you said, enough to wait for clients to timeout. For telco (or similar, more demanding) grade of high-availability, timeout just takes too long. You typically have to discover failure using some kind of heartbeat mechanism and clean up immediately ... - To unsubscribe from this list: send 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] rfkill - Add support for input key to control wireless radio
On 3/30/07, Ivo van Doorn <[EMAIL PROTECTED]> wrote: > > > > > > My only concern is where rfkill code should live. Since it is no > > > longer dependent on input core (embedded systems might disable > > > rfkill-input and use bare rfkill and control state from userspace) > > > it does not need to live in drivers/input. > > > > How about: > > rfkill -> drivers/misc > > Not in net? Well in drivers/net are the network drivers but not the irda and bluetooth drivers, those are located in different folders in drivers/ so I think misc would be the most suitable location. We could also consider the ./net itself. rfkill is not a driver, it is a facility. > > - input_polldev > >- Handlers polling, where the driver should check what the previous state was and the driver > > should send the event to rfkill. > > This is the input device visible to userspace and kernel. It polls > state of the button and sends KEY_WLAN/KEY_BLUETOOTH events through > input layer. They get distributed through various input handlers such > as evdev and rfkill-input. Evdev provides route for events to > userspace where application can listen to events and then toggle RF > switches according to the current policy via > /sys/class/rfkill/rfkillXXX/state. Rfkill-input provides in-kernel > route for events into rfkill system. If rfkill-input is loaded > switches that are not claimed by userspace will be toggled > automatically. > > Does this make sense? Yes, but what if the user loads both modules or has them both compiled in? Shouldn't there be some protection against that, since both handlers should not be active at the same time. Why not? evdev is just a delivery transport for input events to userspace. Even if user wants the kernel to control state of RF switches (which I expect most users woudl want) there still could be applications interested in knowing that used turned off wireless. And if userspace really wishes to control switch all by itself it can "claim" it. I guess what you are missing is that input event generated by a device is pushed through every handler bound to the device so there is no way for a "wrong" handler to "steals" an event from "right" handler. They all work simultaneously. > > personally I would prefer enforcing drivers to call > > allocate() > > register() > > unregister() > > free() > > > > Especially with unregister() doing the same steps as free() (put_device) > > might be somwhat confusing. But might be just me. ;) > > > > I know but for refcounted objects you can't really tell when they will > actually be freed. It depends when their last user drops off. Then perhaps rfkill_register could call put_device() when it fails, and free() can be removed entirely. That way it would we prevent some driver to call free() anyway. That would make error handling in ->probe() methods a bit unwieldy I think - if you are using the standard "goto err_xxx; goto err_yyy;" technique then you have to conditionally call rfkill_free(). Hovewer if register simply fails and does not free anything and you call rfkill_register() last (which you need to do because driver has to be almost fully functional to be able to serve toggle_radio calls) you can always call rfkill_free() if something fails. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: Add TCP connection abort IOCTL
Predrag Hodoba wrote: On 30/03/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote: David Miller wrote: > > Something being in the CGL specification is to me exactly a great > reason NOT to add it. That specification is so full of garbage it's > unbelievable. > > Thanks, you've given me one more reason not to even remotely consider > adding this feature. > Agreed, CGL is a vendor driven group that has always wanted to replicate proprietary misfeatures onto Linux. There is a real requirement to provide high availability but there should be no requirement to implement the solution in the same crap way as legacy Unix. OK, let's put aside CGL and legacy Unices. Still, I don't see how the case I mentioned can easily be handled. (The case being - effective clean up of all affected client TCP connections, following failover of the server IP address from active to passive node in a highly available cluster). Why clean them up? The client connections will timeout and they can reconnect. Actively killing them early does nothing helpful. Just like the CGL requirement for forced unmount, the forced operation introduces a whole bunch of race conditions and shared file descriptor problems. - To unsubscribe from this list: send 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: [1/5] 2.6.21-rc5: known regressions
On Wed, Mar 28, 2007 at 11:54:32AM -0700, Kok, Auke wrote: > Adrian Bunk wrote: > >Subject: e1000 resume weirdness > >References : http://lkml.org/lkml/2007/3/26/91 > >Submitter : Ingo Molnar <[EMAIL PROTECTED]> > >Handled-By : Jesse Brandeburg <[EMAIL PROTECTED]> > > Auke Kok <[EMAIL PROTECTED]> > >Status : problem is being debugged > > The issue comes from a corner case and the underlying problem is that e1000 > isn't stopping tx properly. We have a fix for this pending in our tree that > I'll push upstream for 2.6.22 to Jeff, but I don't think this should be a > blocker and it's probably is not a regression at all, the gap has always > been present. > > on a side note, this is probably fixed easily by turning the adapters > detect_tx_hung flag off in e1000_down, so if someone spots this reoccurring > somewhat regularly, please contact me so we can debug it. I myself have a > system suspend/resuming in circles for an hour now with traffic flying > across without a single hit on it > > Adrian, you probably want to drop this issue from your list. Thanks for the update, dropped as non-regression. > Cheers, > > > Auke 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: [PATCH][IPv6]: Fix incorrect length check in rawv6_sendmsg()
On Fri, 2007-03-30 at 09:13 +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: > In article <[EMAIL PROTECTED]> (at Thu, 29 Mar 2007 14:26:44 -0700 (PDT)), > David Miller <[EMAIL PROTECTED]> says: > > > From: Sridhar Samudrala <[EMAIL PROTECTED]> > > Date: Thu, 29 Mar 2007 14:17:28 -0700 > > > > > The check for length in rawv6_sendmsg() is incorrect. > > > As len is an unsigned int, (len < 0) will never be TRUE. > > > I think checking for IPV6_MAXPLEN(65535) is better. > > > > > > Is it possible to send ipv6 jumbo packets using raw > > > sockets? If so, we can remove this check. > > > > I don't see why such a limitation against jumbo would exist, > > does anyone else? > > > > Thanks for catching this Sridhar. A good compiler should simply > > fail to compile "if (x < 0)" when 'x' is an unsigned type, don't > > you think :-) > > Dave, we use "int" for returning value, > so we should fix this anyway, IMHO; > we should not allow len > INT_MAX. > > Don't you think so? > > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Acked-by: Sridhar Samudrala <[EMAIL PROTECTED]> > > diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c > index 306d5d8..203e069 100644 > --- a/net/ipv6/raw.c > +++ b/net/ipv6/raw.c > @@ -687,9 +687,9 @@ static int rawv6_sendmsg(struct kiocb *iocb, struct sock > *sk, > int err; > > /* Rough check on arithmetic overflow, > -better check is made in ip6_build_xmit > +better check is made in ip6_append_data(). >*/ > - if (len < 0) > + if (len > INT_MAX) > return -EMSGSIZE; > > /* Mirror BSD error message compatibility */ > diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c > index 0ad4719..f590db5 100644 > --- a/net/ipv6/udp.c > +++ b/net/ipv6/udp.c > @@ -615,7 +615,7 @@ do_udp_sendmsg: > return udp_sendmsg(iocb, sk, msg, len); > > /* Rough check on arithmetic overflow, > -better check is made in ip6_build_xmit > +better check is made in ip6_append_data(). > */ > if (len > INT_MAX - sizeof(struct udphdr)) > return -EMSGSIZE; > > --yoshfuji > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send 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.21-rc5-mm3: fix e1000 compilation
Randy Dunlap wrote: On Fri, 30 Mar 2007 10:01:04 -0700 Andrew Morton wrote: On Fri, 30 Mar 2007 07:39:04 -0700 "Kok, Auke" <[EMAIL PROTECTED]> wrote: Alexey Dobriyan wrote: CC [M] drivers/net/e1000/e1000_main.o drivers/net/e1000/e1000_main.c: In function 'e1000_tso': drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to incomplete type ... can you send me your config? I'd like to see why nobody here didn't spot this on any of our tests. test.kernel.org got thoroughly broken by e1000, but Alexey's patch fixed things up. My daily/nightly builds were also broken by it... turns out that NETIF_F_TSO6 is defined even if CONFIG_IPV6 is turned off, which is what broke e1000. That in itself might be a problem. Perhaps this should be fixed in netdevice.h (gratuitous bad inline patch below) but I'm not sure if people would appreciate this, as it's rather ugly, and it gets all horrible when people disable TCP protocol support... In any case, I was not suspecting this at all. The patch to e1000 is fine with me. Auke --- diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h index 1a52854..f077137 100644 --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -331,10 +331,16 @@ struct net_device #define NETIF_F_UFO(SKB_GSO_UDP << NETIF_F_GSO_SHIFT) #define NETIF_F_GSO_ROBUST (SKB_GSO_DODGY << NETIF_F_GSO_SHIFT) #define NETIF_F_TSO_ECN(SKB_GSO_TCP_ECN << NETIF_F_GSO_SHIFT) +#ifdef CONFIG_IPV6 #define NETIF_F_TSO6 (SKB_GSO_TCPV6 << NETIF_F_GSO_SHIFT) +#endif /* List of features with software fallbacks. */ +#ifdef CONFIG_IPV6 #define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6) +#else +#define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN) +#endif #define NETIF_F_GEN_CSUM (NETIF_F_NO_CSUM | NETIF_F_HW_CSUM) #define NETIF_F_ALL_CSUM (NETIF_F_IP_CSUM | NETIF_F_GEN_CSUM) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] ethX misnumbered and one missing in mii-tool
On Fri, 2007-03-30 at 12:35 -0400, Lennart Sorensen wrote:
> On Fri, Mar 30, 2007 at 10:42:23AM +0300, Andrei Popa wrote:
> > ethtool reports the same
>
> Is udev running and having fun renumbering interfaces as they are being
> detected in order to keep "consistent" interface names?
yes, it's udevs fault:
zeus rules.d # cat 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules
file.
#
# You can modify it, as long as you keep each rule on a single line.
# PCI device 0x8086:0x1096 (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:17:b7:55",
NAME="eth1"
# PCI device 0x8086:0x1026 (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0e:0c:ba:a8:50",
NAME="eth2"
# PCI device 0x8086:0x1096 (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:17:b7:54",
NAME="eth0"
# PCI device 0x8086:0x1027 (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0e:0c:5f:84:84",
NAME="eth3"
# PCI device 0x1148:0x4320 (skge)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:46:46:7c:7f",
NAME="eth4"
# PCI device 0x8086:0x105e (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:21:0c:09",
NAME="eth5"
# PCI device 0x8086:0x105e (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:21:0c:08",
NAME="eth6"
# PCI device 0x8086:0x1096 (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:17:b7:69",
NAME="eth7"
# PCI device 0x8086:0x1096 (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:17:b7:68",
NAME="eth8"
thanks for pointing this out.
>
> --
> Len Sorensen
-
To unsubscribe from this list: send 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] rfkill - Add support for input key to control wireless radio
> > > There is also an input handler that catces KEY_WLAN and KEY_BLUETOOTH > > > events passing through input system and toggles state of all RF > > > switches of appropriate type registered with rfkill system (unless > > > a switch was claimed by userspace in which case it is left alone). > > > I think this provides basic functionality that most of the users need > > > and any advanced control will have to be done from userspace. > > > > Shouldn't a KEY_IRDA be added as well? > > It isn't currently defined in input.h yet, but perhaps it actually should? > > Or is IRDA treated differently for a specific reason? > > Do we actually have cards with IRDA switches? We are kind of tight in > input KEY_ namespace so I am hesitant to add defines before there > actual users. Ah ok. Well that shouldn't be a problem, IRDA could be added once there are users for it. I am not sure if there are any devices with IRDA switches, so it shouldn't be a big problem. > > > In a followup patch there is a skeleton code for creating polled > > > input devices. For cards that have button physically connected > > > their drivers will have to register a separate input device and > > > let either input handler or userspace application take care of > > > switching RF state appropriately. > > > > > > My only concern is where rfkill code should live. Since it is no > > > longer dependent on input core (embedded systems might disable > > > rfkill-input and use bare rfkill and control state from userspace) > > > it does not need to live in drivers/input. > > > > How about: > > rfkill -> drivers/misc > > Not in net? Well in drivers/net are the network drivers but not the irda and bluetooth drivers, those are located in different folders in drivers/ so I think misc would be the most suitable location. > > rfkill_input -> input/misc > > I can go both ways on this one as it crosses line between input and > rfkill. I think from user/Kconfig point of view it is better to keep > it together with rfkill: user woudl select rfkill option and right > then and there decide if he wants to give the kernel ability to > automatically control RF switche Makes sense. > > input_polldev -> lib/ (perhaps small namechange to rfkill_polldev?) > > No, I do not want to change name - I have bunch of drivers that can me > converted to use this skeleton - wistron, aaedkbd, hdaps, ams, > cobalt_btns. It is also pure input-related function so it is the only > module that definitely belongs to drivers/input/misc. Ok. :) > > It would scatter the components a bit, but since each of those modules > > has its own specific task this would make the most sense. > > And by setting the depends and select fields for the menu entries correctly > > it shouldn't be too big of a problem. > > > > > Please let me know what you think. > > > > Just to get it straight on how these 3 modules would cooperate (before I > > start mixing things up) ;) > > > > - rfkill > >- Drivers register to the rfkill module, rfkill > >- Provides the sysfs interface > >- Drivers that don't require polling should report the events to > > this module > > Not quite. Drivers that have buttons do not require polling still > should create an input device and register it with input layer. Except > that with interrupt-driven devices there is not much you can stub out > so you just have to do input_allocate_device/input_register_device. > > > > > - rfkill_input > >- Provides input device visible to userspace > > > > No, rfkill-input is not an input device but input handler (or input > interface). It routes input events from buttons into switches (see > below). > > > - input_polldev > >- Handlers polling, where the driver should check what the previous > > state was and the driver > > should send the event to rfkill. > > This is the input device visible to userspace and kernel. It polls > state of the button and sends KEY_WLAN/KEY_BLUETOOTH events through > input layer. They get distributed through various input handlers such > as evdev and rfkill-input. Evdev provides route for events to > userspace where application can listen to events and then toggle RF > switches according to the current policy via > /sys/class/rfkill/rfkillXXX/state. Rfkill-input provides in-kernel > route for events into rfkill system. If rfkill-input is loaded > switches that are not claimed by userspace will be toggled > automatically. > > Does this make sense? Yes, but what if the user loads both modules or has them both compiled in? Shouldn't there be some protection against that, since both handlers should not be active at the same time. > Note that we don't start polling the state of button until tare are > users of that input device. If rfkill-input is loaded then there is a > user right away. Otherwise we wait for userspace to open evdev node. Sounds good. > > personally I would prefer enforcing drivers to call > > allocate() > > register() > > unregister()
Re: 2.6.21-rc5-mm3: fix e1000 compilation
On Fri, 30 Mar 2007 10:01:04 -0700 Andrew Morton wrote: > On Fri, 30 Mar 2007 07:39:04 -0700 "Kok, Auke" <[EMAIL PROTECTED]> wrote: > > > Alexey Dobriyan wrote: > > > CC [M] drivers/net/e1000/e1000_main.o > > > drivers/net/e1000/e1000_main.c: In function 'e1000_tso': > > > drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to > > > incomplete type > > > ... > > > > > > > can you send me your config? I'd like to see why nobody here didn't spot > > this on > > any of our tests. > > > > test.kernel.org got thoroughly broken by e1000, but Alexey's patch fixed > things > up. My daily/nightly builds were also broken by it... --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET_SCHED]: cls_basic: fix memory leak in basic_destroy
[NET_SCHED]: cls_basic: fix memory leak in basic_destroy tp->root is not freed on destruction. Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> --- commit b3df7f810c71b213224c105283c01e57ba7ed46a tree 7f49d1edbc955609e369317a5a76100c87082377 parent 167c6a396949ee921bf70cbe58529f8e4dd4398d author Patrick McHardy <[EMAIL PROTECTED]> Fri, 30 Mar 2007 15:46:00 +0200 committer Patrick McHardy <[EMAIL PROTECTED]> Fri, 30 Mar 2007 15:46:00 +0200 net/sched/cls_basic.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/sched/cls_basic.c b/net/sched/cls_basic.c index e76803c..c885412 100644 --- a/net/sched/cls_basic.c +++ b/net/sched/cls_basic.c @@ -110,6 +110,7 @@ static void basic_destroy(struct tcf_proto *tp) list_del(&f->link); basic_delete_filter(tp, f); } + kfree(head); } static int basic_delete(struct tcf_proto *tp, unsigned long arg)
Re: 2.6.21-rc5-mm3: fix e1000 compilation
On Fri, 30 Mar 2007 07:39:04 -0700 "Kok, Auke" <[EMAIL PROTECTED]> wrote: > Alexey Dobriyan wrote: > > CC [M] drivers/net/e1000/e1000_main.o > > drivers/net/e1000/e1000_main.c: In function 'e1000_tso': > > drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to > > incomplete type > > ... > > > > can you send me your config? I'd like to see why nobody here didn't spot this > on > any of our tests. > test.kernel.org got thoroughly broken by e1000, but Alexey's patch fixed things up. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] ethX misnumbered and one missing in mii-tool
On 2007.03.30 10:42:23 +0300, Andrei Popa wrote: > On Thu, 2007-03-29 at 21:21 -0700, Jesse Brandeburg wrote: > with kernel 2.6.20.4(and build in e1000 driver): > zeus ~ # uname -a > Linux zeus 2.6.20.4-zeus3 #3 SMP Wed Mar 28 13:44:50 EEST 2007 x86_64 > Intel(R) Xeon(TM) CPU 3.00GHz GenuineIntel GNU/Linux > > the devices are recognized ok as eth0,eth1.eth2,eth3,eth4 but misnumered > and one missing int mii-tool/ethtool > > Intel(R) PRO/1000 Network Driver - version 7.3.15-k2-NAPI > Copyright (c) 1999-2006 Intel Corporation. > ACPI: PCI Interrupt :03:00.0[A] -> GSI 16 (level, low) -> IRQ 16 > PCI: Setting latency timer of device :03:00.0 to 64 > e1000: :03:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x4) > 00:15:17:21:0c:08 > e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > ACPI: PCI Interrupt :03:00.1[B] -> GSI 17 (level, low) -> IRQ 17 > PCI: Setting latency timer of device :03:00.1 to 64 > e1000: :03:00.1: e1000_probe: (PCI Express:2.5Gb/s:Width x4) > 00:15:17:21:0c:09 > e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection > ACPI: PCI Interrupt :05:00.0[A] -> GSI 18 (level, low) -> IRQ 18 > PCI: Setting latency timer of device :05:00.0 to 64 > e1000: :05:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x4) > 00:15:17:17:b7:68 > e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection > ACPI: PCI Interrupt :05:00.1[B] -> GSI 19 (level, low) -> IRQ 19 > PCI: Setting latency timer of device :05:00.1 to 64 > e1000: :05:00.1: e1000_probe: (PCI Express:2.5Gb/s:Width x4) > 00:15:17:17:b7:69 > e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection > ACPI: PCI Interrupt :06:02.0[A] -> GSI 27 (level, low) -> IRQ 27 > e1000: :06:02.0: e1000_probe: (PCI-X:100MHz:64-bit) > 00:0e:0c:ba:a8:50 > e1000: eth4: e1000_probe: Intel(R) PRO/1000 Network Connection > > zeus ~ # mii-tool > eth2: no link > eth5: negotiated 100baseTx-FD, link ok > eth6: no link > eth7: no link > zeus ~ # > > ethtool shows the same The "misnaming" might be due to udev renaming the devices. Here, on debian, there are automatically created static rules for network devices in /etc/udev/rules.d/z25_persistent-net.rules, which you might want to adjust to meet your expectations. HTH Björn - To unsubscribe from this list: send 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] the scheduled eepro100 removal
Brandeburg, Jesse wrote: Roberto Nibali wrote: Sounds sane to me. My overall opinion on eepro100 removal is that we're not there yet. Rare problem cases remain where e100 fails but eepro100 works, and it's older drivers so its low priority for everybody. Needs to happen, though... It seems that several Tyan Opteron base system that were using IPMI add on card. the IPMI card share intel 100Mhz nic onboard. you need to use eepro100 instead of e100 otherwise the e100 will shutdown OOB (out of Band) connection for IPMI when shut down the OS. I find it hard to believe that something as common as IPMI in conjunction with the IPMI technology wasn't tested in Intel's lab. From my experience with Intel Server boards, onboard IPMI (all offered versions) and e100/e1000 NICs, I've never ever experienced any problems operating the BMC over the NIC. Also, I don't quite understand you point about the "IPMI card sharing the 100Mbit/s NIC" onboard? What exactly is shared? It's a legit problem, but only with this *one* system. Of course the eepro100 driver is not taking a lot of maintenance either, removing it is not critical as long as there is a legitimate need to support old hardware. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] ethX misnumbered and one missing in mii-tool
On Fri, Mar 30, 2007 at 10:42:23AM +0300, Andrei Popa wrote: > ethtool reports the same Is udev running and having fun renumbering interfaces as they are being detected in order to keep "consistent" interface names? -- Len Sorensen - To unsubscribe from this list: send 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: tcp crash in net-2.6 tree
On Fri, 30 Mar 2007 17:33:28 +0300 (EEST) "Ilpo Järvinen" <[EMAIL PROTECTED]>
wrote:
> On Thu, 29 Mar 2007, Andrew Morton wrote:
>
> > Full -mm lineup. The x86_64 box was acting as a distcc server at the time.
> >
> > Nothing hit the logs, I'm afraid. But almost all the info is in
> > http://userweb.kernel.org/~akpm/s5000494.jpg
> >
> >
> >
> > It died in tcp_update_scoreboard_fack() here:
> >
> > if ((!IsFack(tp) || !tcp_skb_timedout(sk, skb)) &&
> > after(TCP_SKB_CB(skb)->seq, tp->high_seq)) {
> > /* RFC: should we have find_below? */
> > skb = tcp_write_queue_find(sk, tp->high_seq);
> > not_marked_skb = skb;
> > skb = tcp_write_queue_prev(sk, skb);
> > /* Timedout top is again uncertain? */
> > if (tcp_skb_timedout(sk, skb))
> > timedout_continue = 1;
> > }
> >
> >
> > (gdb) l *0x8048ded8
> > 0x8048ded8 is in tcp_update_scoreboard_fack
> > (include/net/tcp.h:1197).
> > 1192return skb->next;
> > 1193}
> > 1194
> > 1195static inline struct sk_buff *tcp_write_queue_prev(struct sock *sk,
> > struct sk_buff *skb)
> > 1196{
> > 1197return skb->prev;
> > 1198}
> > 1199
> > 1200#define tcp_for_write_queue(skb, sk)
> >\
> >
> > (gdb) x/10i 0x8048ded8
> > 0x8048ded8 :mov
> > 0x8(%rdx),%r12
> >
> > So if that "CR2: 0008" is the access address then it appears
> > that
> > `skb' is NULL. tcp_write_queue_find() didn't find nuthin.
>
> If there is nothing at high_seq (application hasn't given any data to/past
> that point), the search fails to find any skb and returns NULL... But I
> have no idea how this can happen? As TCP does after(skb->seq,
> tp->high_seq) (even in the quoted code block) guaranteeing that something
> is there after the high_seq for TCP to step temporarily on... So at least
> one skb should have it's end_seq after tp->high_seq (actually there
> should be at least two valid skbs after tp->high_seq since the used
> sequence number space does not have holes), which should be enough to get
> an existing skb from write_queue_find?!
>
> I also checked all call paths to tcp_update_scoreboard_fack to make sure
> that snd_una hasn't gone past high_seq and found nothing suspicious (and
> that wouldn't return NULL anyway I think)...
Well, could I suggest that you prepare a patch which adds lots of debugging
checks in that area? I can apply it and will rerun the same workload.
-
To unsubscribe from this list: send 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: L2 network namespace benchmarking (resend with Service Demand)
Daniel Lezcano <[EMAIL PROTECTED]> writes: > Hi, > > as suggested Rick, I added the Service Demand results to the matrix. Thanks. The latency number is interesting and it confirms what we were seeing looking at cpu usage. We don't have an inexpesive way to get a packet from the outside world to a network namespace. Now if we can figure out why the routing code or the bridging code seems to be performing extra packet copies, perhaps that can be fixed. Eric - To unsubscribe from this list: send 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] rfkill - Add support for input key to control wireless radio
On 3/30/07, Ivo van Doorn <[EMAIL PROTECTED]> wrote: Hi, > I am very sorry for taking so much time to respond but finally I went > through the patch and I still have the same objection as before - > it mixes two logically (and often physically) separated objects into > a single entity. I think that RF switch and button should be separate > entities, created and destroyed independently of each other. This way > everything handled uniformly by the kernel. ok. Sounds good as well. :) > I attempted to rework the rfkill core supprt and simplify it and > came up with the patch below. Network card drivers that are able > to control state of their RF transmitters allocate and register > rfkill structures. Every rfkill structure belongs to one of > RF classes (WLAN, Bluetooth or IRDA) and exports its name, type, > state and "user_claim" through sysfs. > > There is also an input handler that catces KEY_WLAN and KEY_BLUETOOTH > events passing through input system and toggles state of all RF > switches of appropriate type registered with rfkill system (unless > a switch was claimed by userspace in which case it is left alone). > I think this provides basic functionality that most of the users need > and any advanced control will have to be done from userspace. Shouldn't a KEY_IRDA be added as well? It isn't currently defined in input.h yet, but perhaps it actually should? Or is IRDA treated differently for a specific reason? Do we actually have cards with IRDA switches? We are kind of tight in input KEY_ namespace so I am hesitant to add defines before there actual users. > In a followup patch there is a skeleton code for creating polled > input devices. For cards that have button physically connected > their drivers will have to register a separate input device and > let either input handler or userspace application take care of > switching RF state appropriately. > > My only concern is where rfkill code should live. Since it is no > longer dependent on input core (embedded systems might disable > rfkill-input and use bare rfkill and control state from userspace) > it does not need to live in drivers/input. How about: rfkill -> drivers/misc Not in net? rfkill_input -> input/misc I can go both ways on this one as it crosses line between input and rfkill. I think from user/Kconfig point of view it is better to keep it together with rfkill: user woudl select rfkill option and right then and there decide if he wants to give the kernel ability to automatically control RF switche input_polldev -> lib/ (perhaps small namechange to rfkill_polldev?) No, I do not want to change name - I have bunch of drivers that can me converted to use this skeleton - wistron, aaedkbd, hdaps, ams, cobalt_btns. It is also pure input-related function so it is the only module that definitely belongs to drivers/input/misc. It would scatter the components a bit, but since each of those modules has its own specific task this would make the most sense. And by setting the depends and select fields for the menu entries correctly it shouldn't be too big of a problem. > Please let me know what you think. Just to get it straight on how these 3 modules would cooperate (before I start mixing things up) ;) - rfkill - Drivers register to the rfkill module, rfkill - Provides the sysfs interface - Drivers that don't require polling should report the events to this module Not quite. Drivers that have buttons do not require polling still should create an input device and register it with input layer. Except that with interrupt-driven devices there is not much you can stub out so you just have to do input_allocate_device/input_register_device. - rfkill_input - Provides input device visible to userspace No, rfkill-input is not an input device but input handler (or input interface). It routes input events from buttons into switches (see below). - input_polldev - Handlers polling, where the driver should check what the previous state was and the driver should send the event to rfkill. This is the input device visible to userspace and kernel. It polls state of the button and sends KEY_WLAN/KEY_BLUETOOTH events through input layer. They get distributed through various input handlers such as evdev and rfkill-input. Evdev provides route for events to userspace where application can listen to events and then toggle RF switches according to the current policy via /sys/class/rfkill/rfkillXXX/state. Rfkill-input provides in-kernel route for events into rfkill system. If rfkill-input is loaded switches that are not claimed by userspace will be toggled automatically. Does this make sense? Note that we don't start polling the state of button until tare are users of that input device. If rfkill-input is loaded then there is a user right away. Otherwise we wait for userspace to open evdev node. personally I would prefer enforcing drivers to call allocate() register() unregister() free()
Re: [PATCH] NET: Add TCP connection abort IOCTL
On 30/03/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote: David Miller wrote: > > Something being in the CGL specification is to me exactly a great > reason NOT to add it. That specification is so full of garbage it's > unbelievable. > > Thanks, you've given me one more reason not to even remotely consider > adding this feature. > Agreed, CGL is a vendor driven group that has always wanted to replicate proprietary misfeatures onto Linux. There is a real requirement to provide high availability but there should be no requirement to implement the solution in the same crap way as legacy Unix. OK, let's put aside CGL and legacy Unices. Still, I don't see how the case I mentioned can easily be handled. (The case being - effective clean up of all affected client TCP connections, following failover of the server IP address from active to passive node in a highly available cluster). - To unsubscribe from this list: send 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] rfkill - Add support for input key to control wireless radio
Hi,
> I am very sorry for taking so much time to respond but finally I went
> through the patch and I still have the same objection as before -
> it mixes two logically (and often physically) separated objects into
> a single entity. I think that RF switch and button should be separate
> entities, created and destroyed independently of each other. This way
> everything handled uniformly by the kernel.
ok. Sounds good as well. :)
> I attempted to rework the rfkill core supprt and simplify it and
> came up with the patch below. Network card drivers that are able
> to control state of their RF transmitters allocate and register
> rfkill structures. Every rfkill structure belongs to one of
> RF classes (WLAN, Bluetooth or IRDA) and exports its name, type,
> state and "user_claim" through sysfs.
>
> There is also an input handler that catces KEY_WLAN and KEY_BLUETOOTH
> events passing through input system and toggles state of all RF
> switches of appropriate type registered with rfkill system (unless
> a switch was claimed by userspace in which case it is left alone).
> I think this provides basic functionality that most of the users need
> and any advanced control will have to be done from userspace.
Shouldn't a KEY_IRDA be added as well?
It isn't currently defined in input.h yet, but perhaps it actually should?
Or is IRDA treated differently for a specific reason?
> In a followup patch there is a skeleton code for creating polled
> input devices. For cards that have button physically connected
> their drivers will have to register a separate input device and
> let either input handler or userspace application take care of
> switching RF state appropriately.
>
> My only concern is where rfkill code should live. Since it is no
> longer dependent on input core (embedded systems might disable
> rfkill-input and use bare rfkill and control state from userspace)
> it does not need to live in drivers/input.
How about:
rfkill -> drivers/misc
rfkill_input -> input/misc
input_polldev -> lib/ (perhaps small namechange to rfkill_polldev?)
It would scatter the components a bit, but since each of those modules
has its own specific task this would make the most sense.
And by setting the depends and select fields for the menu entries correctly
it shouldn't be too big of a problem.
> Please let me know what you think.
Just to get it straight on how these 3 modules would cooperate (before I start
mixing things up) ;)
- rfkill
- Drivers register to the rfkill module, rfkill
- Provides the sysfs interface
- Drivers that don't require polling should report the events to this
module
- rfkill_input
- Provides input device visible to userspace
- input_polldev
- Handlers polling, where the driver should check what the previous
state was and the driver
should send the event to rfkill.
Could input_polldev perhaps not be setup to poll, and keep track of the current
button status
and send the signal directly to rfkill?
What I am also not sure of is that input_polldev and rfkill_input both register
a input device.
Instead of starting and stopping the polling through the input device it would
perhaps make more
sense to either use the input device from rfkill_input and/or make use of a
sysfs attribute.
> +/**
> + * rfkill_unregister - Uegister a rfkill structure.
> + * @rfkill: rfkill structure to be unregistered
> + *
> + * This function should be called by the network driver during device
> + * teardown to destroy rfkill structure. Note that rfkill_free() should
> + * _not_ be called after rfkill_unregister().
> + */
> +void rfkill_unregister(struct rfkill *rfkill)
> +{
> + device_del(&rfkill->dev);
> + rfkill_remove_switch(rfkill);
> + put_device(&rfkill->dev);
> +}
> +EXPORT_SYMBOL(rfkill_unregister);
personally I would prefer enforcing drivers to call
allocate()
register()
unregister()
free()
Especially with unregister() doing the same steps as free() (put_device)
might be somwhat confusing. But might be just me. ;)
The remainder looks good, unfortunately I can't test it since the laptop with
an rfkill button I have
requires isn't in a state for testing at this moment, and I would need to
figure out how button status
reading happens in bcm43xx.
Ivo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.21-rc5-mm3: fix e1000 compilation
On Fri, Mar 30, 2007 at 07:39:04AM -0700, Kok, Auke wrote: > Alexey Dobriyan wrote: > > CC [M] drivers/net/e1000/e1000_main.o > >drivers/net/e1000/e1000_main.c: In function 'e1000_tso': > >drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to > >incomplete type > > ... > > > > can you send me your config? I'd like to see why nobody here didn't spot > this on any of our tests. Sure... # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc5-mm3 # Fri Mar 30 13:00:57 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y # CONFIG_SWAP_PREFETCH is not set CONFIG_SYSVIPC=y CONFIG_IPC_NS=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set CONFIG_UTS_NS=y # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # CONFIG_PAGE_GROUP_BY_MOBILITY is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_M
[PATCH] [TCP]: SACK reneging clears stale recv_sack_cache
Though not very efficient, the previous way of maintaining a
stale SACK cache past reneging protected better against misuse
because receiver couldn't cause set-clear ping-pong for
SACKED_ACKED for a large number of skbs.
Mostly copy-paste from sacktag clearer. Compile tested.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 97b9be2..ea196de 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1509,7 +1509,7 @@ void tcp_enter_loss(struct sock *sk, int
const struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
struct sk_buff *skb;
- int cnt = 0;
+ int cnt = 0, i;
/* Reduce ssthresh if it has not yet been made inside this window. */
if (icsk->icsk_ca_state <= TCP_CA_Disorder || tp->snd_una ==
tp->high_seq ||
@@ -1527,8 +1527,15 @@ void tcp_enter_loss(struct sock *sk, int
/* Push undo marker, if it was plain RTO and nothing
* was retransmitted. */
- if (!how)
+ if (!how) {
tp->undo_marker = tp->snd_una;
+ } else {
+ /* We're going to flush SACKed state, every SACK counts again */
+ for (i = 0; i < ARRAY_SIZE(tp->recv_sack_cache); i++) {
+ tp->recv_sack_cache[i].start_seq = 0;
+ tp->recv_sack_cache[i].end_seq = 0;
+ }
+ }
tcp_for_write_queue(skb, sk) {
if (skb == tcp_send_head(sk))
--
1.4.2
Re: 2.6.21-rc5-mm3: fix e1000 compilation
Alexey Dobriyan wrote: CC [M] drivers/net/e1000/e1000_main.o drivers/net/e1000/e1000_main.c: In function 'e1000_tso': drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to incomplete type ... can you send me your config? I'd like to see why nobody here didn't spot this on any of our tests. thanks, Auke --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -32,6 +32,8 @@ #include #include #include #include +#include +#include #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send 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: tcp crash in net-2.6 tree
On Thu, 29 Mar 2007, Andrew Morton wrote:
> Full -mm lineup. The x86_64 box was acting as a distcc server at the time.
>
> Nothing hit the logs, I'm afraid. But almost all the info is in
> http://userweb.kernel.org/~akpm/s5000494.jpg
>
>
>
> It died in tcp_update_scoreboard_fack() here:
>
> if ((!IsFack(tp) || !tcp_skb_timedout(sk, skb)) &&
> after(TCP_SKB_CB(skb)->seq, tp->high_seq)) {
> /* RFC: should we have find_below? */
> skb = tcp_write_queue_find(sk, tp->high_seq);
> not_marked_skb = skb;
> skb = tcp_write_queue_prev(sk, skb);
> /* Timedout top is again uncertain? */
> if (tcp_skb_timedout(sk, skb))
> timedout_continue = 1;
> }
>
>
> (gdb) l *0x8048ded8
> 0x8048ded8 is in tcp_update_scoreboard_fack (include/net/tcp.h:1197).
> 1192return skb->next;
> 1193}
> 1194
> 1195static inline struct sk_buff *tcp_write_queue_prev(struct sock *sk,
> struct sk_buff *skb)
> 1196{
> 1197return skb->prev;
> 1198}
> 1199
> 1200#define tcp_for_write_queue(skb, sk)
> \
>
> (gdb) x/10i 0x8048ded8
> 0x8048ded8 :mov0x8(%rdx),%r12
>
> So if that "CR2: 0008" is the access address then it appears that
> `skb' is NULL. tcp_write_queue_find() didn't find nuthin.
If there is nothing at high_seq (application hasn't given any data to/past
that point), the search fails to find any skb and returns NULL... But I
have no idea how this can happen? As TCP does after(skb->seq,
tp->high_seq) (even in the quoted code block) guaranteeing that something
is there after the high_seq for TCP to step temporarily on... So at least
one skb should have it's end_seq after tp->high_seq (actually there
should be at least two valid skbs after tp->high_seq since the used
sequence number space does not have holes), which should be enough to get
an existing skb from write_queue_find?!
I also checked all call paths to tcp_update_scoreboard_fack to make sure
that snd_una hasn't gone past high_seq and found nothing suspicious (and
that wouldn't return NULL anyway I think)...
--
i.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
L2 network namespace benchmarking (resend with Service Demand)
Hi, as suggested Rick, I added the Service Demand results to the matrix. Cheers. Hi, I did some benchmarking on the existing L2 network namespaces. These patches are included in the lxc patchset at: http://lxc.sourceforge.net/patches/2.6.20 The lxc7 patchset series contains Dmitry's patchset The lxc8 patchset series contains Eric's patchset Here are the following scenarii I made in order to do some simple benchmarking on the network namespace. I tested three kernels: * Vanilla kernel 2.6.20 * lxc7 with Dmitry's patchset based on 2.6.20 * L3 network namespace has been removed to do testing * lxc8 with Eric's patchset based on 2.6.20 I didn't do any tests on Linux-Vserver because it is L3 namespace and it is not comparable with the L2 namespace implementation. If anyone is interessted by Linux-Vserver performances, that can be found at http://lxc.sf.net. Roughly, we know there is no performance degradation. For each kernel, several configurations were tested: * vanilla, obviously, only one configuration was tested for reference values. * lxc7, network namespace - compiled out - compiled in - without container - inside a container with ip_forward, route and veth - inside a container with a bridge and veth * lxc8, network namespace - compiled out - compiled in - without container - inside a container with a real network device (eth1 was moved in the container instead of using an etun device) - inside a container with ip_forward, route and etun - inside a container with a bridge and etun Each benchmarking has been done with 2 machines running netperf and tbench. A dedicated machine with a RH4 kernel run the bench servers. For each bench, netperf and tbench, the tests are ran on: * Intel Xeon EM64T, Bi-processor 2,8GHz with hyperthreading activated, 4GB of RAM and Gigabyte NIC (tg3) * AMD Athlon MP 1800+, Bi-processor 1,5GHz, 1GB of RAM and Gigabyte NIC (dl2000) Each tests are run on these machines in order to have a CPU relative overhead. # bench on vanilla === --- | Netperf | CPU usage (%) | Throughput (Mbits/s) | SD (us/KB) | --- | on xeon | 5.99 |941.38|2.084| | on athlon | 28.17 |844.82|5.462| --- --- | Tbench| Throughput (MBytes/s) | --- --- | on xeon | 66.35 | --- | on athlon | 65.31 | --- # bench from Dmitry's patchset == 1 - with net_ns compiled out --- - | Netperf | CPU usage (%) / overhead | Throughput (Mbits/s) / changed | SD (us/KB) | --- --- - | on xeon | 5.93 / -1 % |941.32 / 0 % |2.066| --- - | on athlon | 28.89 / +2.5 % |842.78 / -0.2 % |5.615| - --- - | Tbench| Throughput (MBytes/s) / changed | --- - | on xeon | 67.00 / +0.9 % | - | on athlon | 65.45 / 0 % | - Observation : no noticeable overhead 2 - with net_ns compiled in --- 2.1 - without container --- --- - | Netperf | CPU usage (%) / overhead | Throughput (Mbits/s) / changed | SD (us/KB) | --- --- - | on xeon | 6.23 / +4 % |941.35 / 0 % |2.168| --- - | on athlon | 28.83 / +2.3 % |850.76 / +0.7 % |5.552| - --- - | Tbench| Throughput (MBytes/s) / changed | --- - | on xeon | 67.00 / 0 % | - | on athlon | 65.45 / 0 % | - O
New card for hostap_cs
From: Marcin Juszkiewicz <[EMAIL PROTECTED]> Add ADLINK 345 CF card into hostap_cs product info: "ADLINK 345 CF" manfid 0xd601, 0x0005 Signed-off-by: Marcin Juszkiewicz <[EMAIL PROTECTED]> Index: git/drivers/net/wireless/hostap/hostap_cs.c === --- git.orig/drivers/net/wireless/hostap/hostap_cs.c2007-02-16 17:10:26.993110019 +0100 +++ git/drivers/net/wireless/hostap/hostap_cs.c 2007-02-16 17:11:15.241749387 +0100 @@ -838,6 +838,8 @@ PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0005), PCMCIA_DEVICE_MANF_CARD(0xd601, 0x0010), PCMCIA_DEVICE_MANF_CARD(0x0126, 0x0002), + PCMCIA_DEVICE_MANF_CARD_PROD_ID1(0xd601, 0x0005, "ADLINK 345 CF", +0x2d858104), PCMCIA_DEVICE_MANF_CARD_PROD_ID1(0x0156, 0x0002, "INTERSIL", 0x74c5e40d), PCMCIA_DEVICE_MANF_CARD_PROD_ID1(0x0156, 0x0002, "Intersil", -- JID: hrw-jabber.org OpenEmbedded developer - To unsubscribe from this list: send 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: many sockets, slow sendto
On Thu, 29 Mar 2007 21:24:31 +0200
Zacco <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Thanks for the patch. I almost dare not confess that I don't know which
> version to apply to. I tried 3 different ones (2.6.19-r5-gentoo,
> 2.6.20.1 and 2.6.21-rc4), but in the best case at least two hunks
> failed. Nevertheless, I applied the patches manually. In each case, UDP
> stopped working. I guess, you checked the patch and worked. I don't
> think I made a mistake in the manual copy, and it seems unlikely that
> your patch interfered with other parallel changes in the kernel - but,
> I'm just guessing ...
> I think, I'd better send you the spec and code, as you suggested that
> first we have a common understanding of the issue. I must have failed in
> passing the point. I'm removing irrelevant stuff, and I send it to you
> as soon as I can (sorry for my long delays).
>
> thx a lot,
> Zacco
Hum, please find a (working) patch against linux-2.6.21-rc5
(first patch was against net-2.6.22 git tree and had one bug)
Hope this helps
--- linux-2.6.21-rc5/net/ipv4/udp.c
+++ linux-2.6.21-rc5-ed/net/ipv4/udp.c
@@ -114,14 +114,33 @@ DEFINE_RWLOCK(udp_hash_lock);
static int udp_port_rover;
-static inline int __udp_lib_lport_inuse(__u16 num, struct hlist_head
udptable[])
+/*
+ * Note about this hash function :
+ * Typical use is probably daddr = 0, only dport is going to vary hash
+ */
+static inline unsigned int hash_port_and_addr(__u16 port, __be32 addr)
+{
+ addr ^= addr >> 16;
+ addr ^= addr >> 8;
+ return port ^ addr;
+}
+
+static inline int __udp_lib_port_inuse(unsigned int hash, int port,
+ __be32 daddr, struct hlist_head udptable[])
{
struct sock *sk;
struct hlist_node *node;
+ struct inet_sock *inet;
- sk_for_each(sk, node, &udptable[num & (UDP_HTABLE_SIZE - 1)])
- if (sk->sk_hash == num)
+ sk_for_each(sk, node, &udptable[hash & (UDP_HTABLE_SIZE - 1)]) {
+ if (sk->sk_hash != hash)
+ continue;
+ inet = inet_sk(sk);
+ if (inet->num != port)
+ continue;
+ if (inet->rcv_saddr == daddr)
return 1;
+ }
return 0;
}
@@ -142,6 +161,7 @@ int __udp_lib_get_port(struct sock *sk,
struct hlist_node *node;
struct hlist_head *head;
struct sock *sk2;
+ unsigned int hash;
interror = 1;
write_lock_bh(&udp_hash_lock);
@@ -156,7 +176,9 @@ int __udp_lib_get_port(struct sock *sk,
for (i = 0; i < UDP_HTABLE_SIZE; i++, result++) {
int size;
- head = &udptable[result & (UDP_HTABLE_SIZE - 1)];
+ hash = hash_port_and_addr(result,
+ inet_sk(sk)->rcv_saddr);
+ head = &udptable[hash & (UDP_HTABLE_SIZE - 1)];
if (hlist_empty(head)) {
if (result > sysctl_local_port_range[1])
result = sysctl_local_port_range[0] +
@@ -180,7 +202,10 @@ int __udp_lib_get_port(struct sock *sk,
result = sysctl_local_port_range[0]
+ ((result -
sysctl_local_port_range[0]) &
(UDP_HTABLE_SIZE - 1));
- if (! __udp_lib_lport_inuse(result, udptable))
+ hash = hash_port_and_addr(result,
+ inet_sk(sk)->rcv_saddr);
+ if (! __udp_lib_port_inuse(hash, result,
+ inet_sk(sk)->rcv_saddr, udptable))
break;
}
if (i >= (1 << 16) / UDP_HTABLE_SIZE)
@@ -188,11 +213,13 @@ int __udp_lib_get_port(struct sock *sk,
gotit:
*port_rover = snum = result;
} else {
- head = &udptable[snum & (UDP_HTABLE_SIZE - 1)];
+ hash = hash_port_and_addr(snum, inet_sk(sk)->rcv_saddr);
+ head = &udptable[hash & (UDP_HTABLE_SIZE - 1)];
sk_for_each(sk2, node, head)
- if (sk2->sk_hash == snum &&
+ if (sk2->sk_hash == hash &&
sk2 != sk&&
+ inet_sk(sk2)->num == snum&&
(!sk2->sk_reuse|| !sk->sk_reuse) &&
(!sk2->sk_bound_dev_if || !sk->sk_bound_dev_if
|| sk2->sk_bound_dev_if == sk->sk_bound_dev_if) &&
@@ -200,9 +227,9 @@ gotit:
goto fail;
}
inet_sk(sk)->num = snum;
- sk->sk_hash = snum;
+ sk->sk_hash = hash;
if (sk_unhashed(sk)) {
-
Re: traffic shaping with NAT: IFB as IMQ replacement?
On Fri, 2007-30-03 at 01:08 +0200, Gerd v. Egidy wrote: > I'm also interested in shaping NAT. Would you mind telling us what you have > in > mind with your userspace code? Do you plan something like > > tun -> your userspace code -> tun > ^ > | (netlink) > v > conntrack > Conntrack is already a perfomance hog - so using user space in that manner is sinful. The idea is to use contrack netlink to setup tc rules with ifb. In any case, if you are interested talk to me privately; i have received a few emails since i posted but mostly for people who want to test. If you are in that category please just keep pinging me and i will feel guilty and get it done. 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
[PATCH-resend]drivers/net/eexpress.c replace with time_after && time_before in drivers/net/eexpress.c
Resending the patch with few corrections related to time_after and
time_before in drivers/net/eexpress.c as suggested by Marcin slusarz.
thanks.
Signed-off-by: Shani Moideen <[EMAIL PROTECTED]>
diff --git a/drivers/net/eexpress.c b/drivers/net/eexpress.c
index 3868b80..1321757 100644
--- a/drivers/net/eexpress.c
+++ b/drivers/net/eexpress.c
@@ -115,6 +115,7 @@
#include
#include
#include
+#include
#include
#include
@@ -556,7 +557,7 @@ static void unstick_cu(struct net_device *dev)
if (lp->started)
{
- if ((jiffies - dev->trans_start)>50)
+ if (time_after( jiffies, dev->trans_start + 50))
{
if (lp->tx_link==lp->last_tx_restart)
{
@@ -612,7 +613,7 @@ static void unstick_cu(struct net_device *dev)
}
else
{
- if ((jiffies-lp->init_time)>10)
+ if (time_after(jiffies, lp->init_time + 10))
{
unsigned short status = scb_status(dev);
printk(KERN_WARNING "%s: i82586 startup timed out,
status %04x, resetting...\n",
@@ -776,7 +777,7 @@ static unsigned short eexp_start_irq(struct net_device *dev,
static void eexp_cmd_clear(struct net_device *dev)
{
unsigned long int oldtime = jiffies;
- while (scb_rdcmd(dev) && ((jiffies-oldtime)<10));
+ while (scb_rdcmd(dev) && (time_before(jiffies, oldtime + 10)));
if (scb_rdcmd(dev)) {
printk("%s: command didn't clear\n", dev->name);
}
@@ -1650,7 +1651,7 @@ eexp_set_multicast(struct net_device *dev)
#endif
oj = jiffies;
while ((SCB_CUstat(scb_status(dev)) == 2) &&
- ((jiffies-oj) < 2000));
+ (time_before(jiffies, oj + 2000)));
if (SCB_CUstat(scb_status(dev)) == 2)
printk("%s: warning, CU didn't stop\n", dev->name);
lp->started &= ~(STARTED_CU);
--
Shani Moideen
-
To unsubscribe from this list: send 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] Change "not found" return value for rule lookup
>From 657baf6bbaa8302660d6b218149dcb5546b9b08c Mon Sep 17 00:00:00 2001 From: Steven Whitehouse <[EMAIL PROTECTED]> Date: Fri, 30 Mar 2007 09:06:34 +0100 Subject: [PATCH] [NET] Change "not found" return value for rule lookup This changes the "not found" error return for the lookup function to -ESRCH so that it can be distinguished from the case where a rule or route resulting in -ENETUNREACH has been found during the search. It fixes a bug where if DECnet was compiled with routing support, but no routes were added to the routing table, it was failing to fall back to endnode routing. Signed-off-by: Steven Whitehouse <[EMAIL PROTECTED]> Signed-off-by: Patrick Caulfield <[EMAIL PROTECTED]> diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c index 06f304a..cb2dae1 100644 --- a/net/core/fib_rules.c +++ b/net/core/fib_rules.c @@ -164,7 +164,7 @@ jumped: } } - err = -ENETUNREACH; + err = -ESRCH; out: rcu_read_unlock(); -- 1.4.4.2 - To unsubscribe from this list: send 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.21-rc5-mm3: fix e1000 compilation
CC [M] drivers/net/e1000/e1000_main.o drivers/net/e1000/e1000_main.c: In function 'e1000_tso': drivers/net/e1000/e1000_main.c:2968: error: dereferencing pointer to incomplete type ... --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -32,6 +32,8 @@ #include #include #include #include +#include +#include #include #include #include - To unsubscribe from this list: send 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: Issue with connector/netlink
On Thu, Mar 29, 2007 at 08:47:18PM +0200, Philipp Reisner ([EMAIL PROTECTED]) wrote: > RIP: 0010:[] [] > netlink_broadcast+0x123/0x2de > RSP: 0018:8100379bddc0 EFLAGS: 00010297 > RAX: 656b736968772d31 RBX: 810079d7f800 RCX: 0004 > RDX: 81007e113000 RSI: 810079d68280 RDI: 804c6a80 > RBP: 810079d68280 R08: 00d0 R09: 810079d68280 > R10: 0002 R11: 81007fd6fac0 R12: 0020 > R13: R14: 810079d7f818 R15: 0003 > FS: () GS:804d6000() knlGS: > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > CR2: 2b2acc1ecb40 CR3: 79ac1000 CR4: 26e0 > Process cqueue/0 (pid: 1948, threadinfo 8100379bc000, task > 810037fd8040) > Stack: 810079d7f400 00d0 81007e113000 7e069a24 > 0100 810079d7f400 81007e069a10 > 81007e069a24 881e9d00 81007cf07800 881d5c23 ... > Code; 8024f904<= >0: 44 0f a3 38 bt %r15d,(%rax) <= %rax contains 0x656b736968772d31 In my x86_64 it is obtained from %rbx, which seems to be correct, so I'm a bit stuck, something has rewritten internals of the socket structure, and it does not look like free poisoning. 0x8024ea14 : mov0x268(%rbx),%rax 0x8024ea1b : bt %r15d,(%rax) Can you describe your load? Is it too high to put a debug printk there? Can you enable as much debug options as possible? -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8284] New: IPsec anti-replay window management flaw
On Fri, 30 Mar 2007 01:06:17 -0700 [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8284 > >Summary: IPsec anti-replay window management flaw > Kernel Version: 2.6.20.4 > Status: NEW > Severity: normal > Owner: [EMAIL PROTECTED] > Submitter: [EMAIL PROTECTED] > > > The IPsec ESP/AH anti-replay window size is configurable, 64 being the value > recommended by RFC 2406. > Linux kernels use a 32 bit bitmap to check whether a sequence number has > already been received. > > When a packet is received, if its seq is lower than the greatest received seq, > and if the difference is greater than 32, the check doesn't work. > This constitutes a security flaw. > > The faulty code is in net/xfrm/xfrm-state.c, functions xfrm_replay_check() > and > xfrm_replay_advance(). - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
