* Re: [PATCH 1/4] bonding: Fix work initing and cancelling
From: Makito SHIOKAWA @ 2008-01-16 5:17 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev, Makito SHIOKAWA
In-Reply-To: <20080115105601.GC1696@ff.dom.local>
> I wonder why don't you use cancel_delayed_work_sync() here (and in a
> few other places), like in bond_work_cancel_all() from patch 2/4?
In bond_close(), you can't use cancel_delayed_work_sync() because you can't
unlock RTNL in it. (So, on current implementation, it becomes work cancel is
not ensured on bond_close().)
In sysfs, I think you are right, thanks. So, I will modify the patch as below
(other patches won't be affected).
---
drivers/net/bonding/bond_main.c | 46 ++++++++++++++++++++------------------
drivers/net/bonding/bond_sysfs.c | 34 ++++++++--------------------
drivers/net/bonding/bonding.h | 3 +-
3 files changed, 37 insertions(+), 46 deletions(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2692,7 +2692,7 @@ out:
void bond_loadbalance_arp_mon(struct work_struct *work)
{
struct bonding *bond = container_of(work, struct bonding,
- arp_work.work);
+ lb_arp_work.work);
struct slave *slave, *oldcurrent;
int do_failover = 0;
int delta_in_ticks;
@@ -2803,7 +2803,7 @@ void bond_loadbalance_arp_mon(struct wor
re_arm:
if (bond->params.arp_interval)
- queue_delayed_work(bond->wq, &bond->arp_work, delta_in_ticks);
+ queue_delayed_work(bond->wq, &bond->lb_arp_work, delta_in_ticks);
out:
read_unlock(&bond->lock);
}
@@ -2826,7 +2826,7 @@ out:
void bond_activebackup_arp_mon(struct work_struct *work)
{
struct bonding *bond = container_of(work, struct bonding,
- arp_work.work);
+ ab_arp_work.work);
struct slave *slave;
int delta_in_ticks;
int i;
@@ -3060,7 +3060,7 @@ void bond_activebackup_arp_mon(struct wo
re_arm:
if (bond->params.arp_interval) {
- queue_delayed_work(bond->wq, &bond->arp_work, delta_in_ticks);
+ queue_delayed_work(bond->wq, &bond->ab_arp_work, delta_in_ticks);
}
out:
read_unlock(&bond->lock);
@@ -3679,30 +3679,23 @@ static int bond_open(struct net_device *
return -1;
}
- INIT_DELAYED_WORK(&bond->alb_work, bond_alb_monitor);
queue_delayed_work(bond->wq, &bond->alb_work, 0);
}
if (bond->params.miimon) { /* link check interval, in milliseconds. */
- INIT_DELAYED_WORK(&bond->mii_work, bond_mii_monitor);
queue_delayed_work(bond->wq, &bond->mii_work, 0);
}
if (bond->params.arp_interval) { /* arp interval, in milliseconds. */
if (bond->params.mode == BOND_MODE_ACTIVEBACKUP)
- INIT_DELAYED_WORK(&bond->arp_work,
- bond_activebackup_arp_mon);
+ queue_delayed_work(bond->wq, &bond->ab_arp_work, 0);
else
- INIT_DELAYED_WORK(&bond->arp_work,
- bond_loadbalance_arp_mon);
-
- queue_delayed_work(bond->wq, &bond->arp_work, 0);
+ queue_delayed_work(bond->wq, &bond->lb_arp_work, 0);
if (bond->params.arp_validate)
bond_register_arp(bond);
}
if (bond->params.mode == BOND_MODE_8023AD) {
- INIT_DELAYED_WORK(&bond->ad_work, bond_3ad_state_machine_handler);
queue_delayed_work(bond->wq, &bond->ad_work, 0);
/* register to receive LACPDUs */
bond_register_lacpdu(bond);
@@ -3736,7 +3729,10 @@ static int bond_close(struct net_device
}
if (bond->params.arp_interval) { /* arp interval, in milliseconds. */
- cancel_delayed_work(&bond->arp_work);
+ if (bond->params.mode == BOND_MODE_ACTIVEBACKUP)
+ cancel_delayed_work(&bond->ab_arp_work);
+ else
+ cancel_delayed_work(&bond->lb_arp_work);
}
switch (bond->params.mode) {
@@ -4416,6 +4412,12 @@ static int bond_init(struct net_device *
if (!bond->wq)
return -ENOMEM;
+ INIT_DELAYED_WORK(&bond->alb_work, bond_alb_monitor);
+ INIT_DELAYED_WORK(&bond->mii_work, bond_mii_monitor);
+ INIT_DELAYED_WORK(&bond->ab_arp_work, bond_activebackup_arp_mon);
+ INIT_DELAYED_WORK(&bond->lb_arp_work, bond_loadbalance_arp_mon);
+ INIT_DELAYED_WORK(&bond->ad_work, bond_3ad_state_machine_handler);
+
/* Initialize pointers */
bond->first_slave = NULL;
bond->curr_active_slave = NULL;
@@ -4498,18 +4500,20 @@ static void bond_work_cancel_all(struct
bond->kill_timers = 1;
write_unlock_bh(&bond->lock);
- if (bond->params.miimon && delayed_work_pending(&bond->mii_work))
+ if (bond->params.miimon)
cancel_delayed_work(&bond->mii_work);
- if (bond->params.arp_interval && delayed_work_pending(&bond->arp_work))
- cancel_delayed_work(&bond->arp_work);
+ if (bond->params.arp_interval) {
+ if (bond->params.mode == BOND_MODE_ACTIVEBACKUP)
+ cancel_delayed_work(&bond->ab_arp_work);
+ else
+ cancel_delayed_work(&bond->lb_arp_work);
+ }
- if (bond->params.mode == BOND_MODE_ALB &&
- delayed_work_pending(&bond->alb_work))
+ if (bond->params.mode == BOND_MODE_ALB)
cancel_delayed_work(&bond->alb_work);
- if (bond->params.mode == BOND_MODE_8023AD &&
- delayed_work_pending(&bond->ad_work))
+ if (bond->params.mode == BOND_MODE_8023AD)
cancel_delayed_work(&bond->ad_work);
}
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -643,10 +643,7 @@ static ssize_t bonding_store_arp_interva
"%s Disabling MII monitoring.\n",
bond->dev->name, bond->dev->name);
bond->params.miimon = 0;
- if (delayed_work_pending(&bond->mii_work)) {
- cancel_delayed_work(&bond->mii_work);
- flush_workqueue(bond->wq);
- }
+ cancel_delayed_work_sync(&bond->mii_work);
}
if (!bond->params.arp_targets[0]) {
printk(KERN_INFO DRV_NAME
@@ -660,16 +657,10 @@ static ssize_t bonding_store_arp_interva
* timer will get fired off when the open function
* is called.
*/
- if (!delayed_work_pending(&bond->arp_work)) {
- if (bond->params.mode == BOND_MODE_ACTIVEBACKUP)
- INIT_DELAYED_WORK(&bond->arp_work,
- bond_activebackup_arp_mon);
- else
- INIT_DELAYED_WORK(&bond->arp_work,
- bond_loadbalance_arp_mon);
-
- queue_delayed_work(bond->wq, &bond->arp_work, 0);
- }
+ if (bond->params.mode == BOND_MODE_ACTIVEBACKUP)
+ queue_delayed_work(bond->wq, &bond->ab_arp_work, 0);
+ else
+ queue_delayed_work(bond->wq, &bond->lb_arp_work, 0);
}
out:
@@ -1022,10 +1013,10 @@ static ssize_t bonding_store_miimon(stru
bond->params.arp_validate =
BOND_ARP_VALIDATE_NONE;
}
- if (delayed_work_pending(&bond->arp_work)) {
- cancel_delayed_work(&bond->arp_work);
- flush_workqueue(bond->wq);
- }
+ if (bond->params.mode == BOND_MODE_ACTIVEBACKUP)
+ cancel_delayed_work_sync(&bond->ab_arp_work);
+ else
+ cancel_delayed_work_sync(&bond->lb_arp_work);
}
if (bond->dev->flags & IFF_UP) {
@@ -1034,12 +1025,7 @@ static ssize_t bonding_store_miimon(stru
* timer will get fired off when the open function
* is called.
*/
- if (!delayed_work_pending(&bond->mii_work)) {
- INIT_DELAYED_WORK(&bond->mii_work,
- bond_mii_monitor);
- queue_delayed_work(bond->wq,
- &bond->mii_work, 0);
- }
+ queue_delayed_work(bond->wq, &bond->mii_work, 0);
}
}
out:
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -206,7 +206,8 @@ struct bonding {
struct packet_type arp_mon_pt;
struct workqueue_struct *wq;
struct delayed_work mii_work;
- struct delayed_work arp_work;
+ struct delayed_work ab_arp_work;
+ struct delayed_work lb_arp_work;
struct delayed_work alb_work;
struct delayed_work ad_work;
};
--
Makito SHIOKAWA
MIRACLE LINUX CORPORATION
^ permalink raw reply
* Re: [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 5:34 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-dev, netdev, benh
In-Reply-To: <20080115200019.GA2598@gate.ebshome.net>
On Tuesday 15 January 2008, Eugene Surovegin wrote:
> > OK. But how do we detect GigE support? Seems like GigE enabled devices
> > have CONFIG_IBM_EMAC4 defined. If nobody objects I'll fix up another
> > version tomorrow.
>
> Look couple of lines down where I set MTU changing hook. If you cannot
> change MTU you cannot get big frames.
Ahhh, I must have been blind. Thanks for pointing out.
I'll send new patches for ibm_emac and ibm_newemac in a short while.
Best regards,
Stefan
^ permalink raw reply
* Re: questions on NAPI processing latency and dropped network packets
From: Jarek Poplawski @ 2008-01-16 6:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: cfriesen, davem, netdev, linux-kernel
In-Reply-To: <E1JEvxs-0006cZ-00@gondolin.me.apana.org.au>
On Wed, Jan 16, 2008 at 11:17:08AM +1100, Herbert Xu wrote:
...
> Well people are always going to operate on this model for commercial
> reasons. FWIW I used to work for a company that stuck to a specific
> version of the Linux kernel, and I suppose I still do even now :)
>
> But the important thing is that if you're going to do that, then the
> cost that comes with it should be borne by the company and not the
> community.
Sure. But the most sad thing is there seems to be not so much savings
in this (unless a company isn't sure of its near future). Trying to
upgrade and test current products with current kernels, even if not
necessary, should be always useful and make developing of new products
faster and better fit (and of course, BTW, make the kernel better on
time).
Regards,
Jarek P.
^ permalink raw reply
* [IPV4] FIB_HASH: Reduce memory needs and speedup lookups
From: Eric Dumazet @ 2008-01-16 6:58 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
Hi David
CONFIG_FIB_HASH=y being default configuration, we can still work on it.
Thank you
[IPV4] FIB_HASH: Reduce memory needs and speedup lookups
Currently, sizeof(struct fib_alias) is 24 or 48 bytes on 32/64 bits arches.
Because of SLAB_HWCACHE_ALIGN requirement, these are rounded to 32 and 64
bytes respectively.
This patch moves rcu to the end of fib_alias, and conditionally defines it
only for CONFIG_IP_FIB_TRIE.
We also remove SLAB_HWCACHE_ALIGN requirement for fib_alias and fib_node
objects because it is not necessary.
(BTW SLUB currently denies it for objects smaller than cache_line_size() / 2,
but not SLAB)
Finally, sizeof(fib_alias) go back to 16 and 32 bytes.
Then, we can embed one fib_alias on each fib_node, to favor locality.
Most of the time access to the fib_alias will be free because one cache line
contains both the list head (fn_alias) and (one of) the list element.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
net/ipv4/fib_hash.c | 33 ++++++++++++++++++++-------------
net/ipv4/fib_lookup.h | 4 +++-
2 files changed, 23 insertions(+), 14 deletions(-)
[-- Attachment #2: fib_hash.patch --]
[-- Type: text/plain, Size: 3289 bytes --]
diff --git a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c
index fe6008d..d92282d 100644
--- a/net/ipv4/fib_hash.c
+++ b/net/ipv4/fib_hash.c
@@ -52,6 +52,7 @@ struct fib_node {
struct hlist_node fn_hash;
struct list_head fn_alias;
__be32 fn_key;
+ struct fib_alias fn_embedded_alias;
};
struct fn_zone {
@@ -193,10 +194,13 @@ static inline void fn_free_node(struct fib_node * f)
kmem_cache_free(fn_hash_kmem, f);
}
-static inline void fn_free_alias(struct fib_alias *fa)
+static inline void fn_free_alias(struct fib_alias *fa, struct fib_node *f)
{
fib_release_info(fa->fa_info);
- kmem_cache_free(fn_alias_kmem, fa);
+ if (fa == &f->fn_embedded_alias)
+ fa->fa_info = NULL;
+ else
+ kmem_cache_free(fn_alias_kmem, fa);
}
static struct fn_zone *
@@ -473,15 +477,12 @@ static int fn_hash_insert(struct fib_table *tb, struct fib_config *cfg)
goto out;
err = -ENOBUFS;
- new_fa = kmem_cache_alloc(fn_alias_kmem, GFP_KERNEL);
- if (new_fa == NULL)
- goto out;
new_f = NULL;
if (!f) {
- new_f = kmem_cache_alloc(fn_hash_kmem, GFP_KERNEL);
+ new_f = kmem_cache_zalloc(fn_hash_kmem, GFP_KERNEL);
if (new_f == NULL)
- goto out_free_new_fa;
+ goto out;
INIT_HLIST_NODE(&new_f->fn_hash);
INIT_LIST_HEAD(&new_f->fn_alias);
@@ -489,6 +490,12 @@ static int fn_hash_insert(struct fib_table *tb, struct fib_config *cfg)
f = new_f;
}
+ new_fa = &f->fn_embedded_alias;
+ if (new_fa->fa_info != NULL) {
+ new_fa = kmem_cache_alloc(fn_alias_kmem, GFP_KERNEL);
+ if (new_fa == NULL)
+ goto out_free_new_f;
+ }
new_fa->fa_info = fi;
new_fa->fa_tos = tos;
new_fa->fa_type = cfg->fc_type;
@@ -515,8 +522,8 @@ static int fn_hash_insert(struct fib_table *tb, struct fib_config *cfg)
&cfg->fc_nlinfo, 0);
return 0;
-out_free_new_fa:
- kmem_cache_free(fn_alias_kmem, new_fa);
+out_free_new_f:
+ kmem_cache_free(fn_hash_kmem, new_f);
out:
fib_release_info(fi);
return err;
@@ -592,7 +599,7 @@ static int fn_hash_delete(struct fib_table *tb, struct fib_config *cfg)
if (fa->fa_state & FA_S_ACCESSED)
rt_cache_flush(-1);
- fn_free_alias(fa);
+ fn_free_alias(fa, f);
if (kill_fn) {
fn_free_node(f);
fz->fz_nent--;
@@ -628,7 +635,7 @@ static int fn_flush_list(struct fn_zone *fz, int idx)
fib_hash_genid++;
write_unlock_bh(&fib_hash_lock);
- fn_free_alias(fa);
+ fn_free_alias(fa, f);
found++;
}
}
@@ -749,10 +756,10 @@ static int fn_hash_dump(struct fib_table *tb, struct sk_buff *skb, struct netlin
void __init fib_hash_init(void)
{
fn_hash_kmem = kmem_cache_create("ip_fib_hash", sizeof(struct fib_node),
- 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+ 0, SLAB_PANIC, NULL);
fn_alias_kmem = kmem_cache_create("ip_fib_alias", sizeof(struct fib_alias),
- 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+ 0, SLAB_PANIC, NULL);
}
diff --git a/net/ipv4/fib_lookup.h b/net/ipv4/fib_lookup.h
index 26ee66d..2c1623d 100644
--- a/net/ipv4/fib_lookup.h
+++ b/net/ipv4/fib_lookup.h
@@ -7,12 +7,14 @@
struct fib_alias {
struct list_head fa_list;
- struct rcu_head rcu;
struct fib_info *fa_info;
u8 fa_tos;
u8 fa_type;
u8 fa_scope;
u8 fa_state;
+#ifdef CONFIG_IP_FIB_TRIE
+ struct rcu_head rcu;
+#endif
};
#define FA_S_ACCESSED 0x01
^ permalink raw reply related
* [PATCH] net: EMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 7:10 UTC (permalink / raw)
To: linuxppc-dev, netdev; +Cc: ebs
Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.
This patch now changes the driver to call emac_start_xmit_sg() on all
GigE platforms and not only the TAH equipped ones (440GX). This enables
an MTU of 9000 instead 4080.
Tested on Kilauea (405EX) with GigE link -> jumbo frames enabled.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_emac/ibm_emac_core.c | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index 73664f2..8d1901e 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -1089,7 +1089,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return emac_xmit_finish(dev, len);
}
-#if defined(CONFIG_IBM_EMAC_TAH)
static inline int emac_xmit_split(struct ocp_enet_private *dev, int slot,
u32 pd, int len, int last, u16 base_ctrl)
{
@@ -1203,9 +1202,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
DBG2("%d: stopped TX queue" NL, dev->def->index);
return 1;
}
-#else
-# define emac_start_xmit_sg emac_start_xmit
-#endif /* !defined(CONFIG_IBM_EMAC_TAH) */
/* BHs disabled */
static void emac_parse_tx_error(struct ocp_enet_private *dev, u16 ctrl)
@@ -2163,11 +2159,8 @@ static int __init emac_probe(struct ocp_device *ocpdev)
/* Fill in the driver function table */
ndev->open = &emac_open;
- if (dev->tah_dev) {
- ndev->hard_start_xmit = &emac_start_xmit_sg;
+ if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- } else
- ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_full_tx_reset;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
@@ -2175,8 +2168,11 @@ static int __init emac_probe(struct ocp_device *ocpdev)
ndev->set_multicast_list = &emac_set_multicast_list;
ndev->do_ioctl = &emac_ioctl;
if (emac_phy_supports_gige(emacdata->phy_mode)) {
+ ndev->hard_start_xmit = &emac_start_xmit_sg;
ndev->change_mtu = &emac_change_mtu;
dev->commac.ops = &emac_commac_sg_ops;
+ } else {
+ ndev->hard_start_xmit = &emac_start_xmit;
}
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
--
1.5.4.rc3
^ permalink raw reply related
* [PATCH] net: NEWEMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Stefan Roese @ 2008-01-16 7:11 UTC (permalink / raw)
To: linuxppc-dev, netdev; +Cc: benh
Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
xmit. This routine doesn't check if the frame length exceeds the max.
MAL buffer size.
This patch now changes the driver to call emac_start_xmit_sg() on all
GigE platforms and not only the TAH equipped ones (440GX). This enables
an MTU of 9000 instead 4080.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/core.c | 14 ++++----------
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index cb06280..b24bd2d 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -1297,7 +1297,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
return emac_xmit_finish(dev, len);
}
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
static inline int emac_xmit_split(struct emac_instance *dev, int slot,
u32 pd, int len, int last, u16 base_ctrl)
{
@@ -1410,9 +1409,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
DBG2(dev, "stopped TX queue" NL);
return 1;
}
-#else
-# define emac_start_xmit_sg emac_start_xmit
-#endif /* !defined(CONFIG_IBM_NEW_EMAC_TAH) */
/* Tx lock BHs */
static void emac_parse_tx_error(struct emac_instance *dev, u16 ctrl)
@@ -2683,13 +2679,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
/* Fill in the driver function table */
ndev->open = &emac_open;
-#ifdef CONFIG_IBM_NEW_EMAC_TAH
- if (dev->tah_dev) {
- ndev->hard_start_xmit = &emac_start_xmit_sg;
+ if (dev->tah_dev)
ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
- } else
-#endif
- ndev->hard_start_xmit = &emac_start_xmit;
ndev->tx_timeout = &emac_tx_timeout;
ndev->watchdog_timeo = 5 * HZ;
ndev->stop = &emac_close;
@@ -2697,8 +2688,11 @@ static int __devinit emac_probe(struct of_device *ofdev,
ndev->set_multicast_list = &emac_set_multicast_list;
ndev->do_ioctl = &emac_ioctl;
if (emac_phy_supports_gige(dev->phy_mode)) {
+ ndev->hard_start_xmit = &emac_start_xmit_sg;
ndev->change_mtu = &emac_change_mtu;
dev->commac.ops = &emac_commac_sg_ops;
+ } else {
+ ndev->hard_start_xmit = &emac_start_xmit;
}
SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
--
1.5.4.rc3
^ permalink raw reply related
* Re: [PATCH] net: NEWEMAC: Fix problem with mtu > 4080 on non TAH equipped 4xx PPC's
From: Benjamin Herrenschmidt @ 2008-01-16 7:15 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200467475-1663-1-git-send-email-sr@denx.de>
On Wed, 2008-01-16 at 08:11 +0100, Stefan Roese wrote:
> Currently, all non TAH equipped 4xx PPC's call emac_start_xmit() upon
> xmit. This routine doesn't check if the frame length exceeds the max.
> MAL buffer size.
>
> This patch now changes the driver to call emac_start_xmit_sg() on all
> GigE platforms and not only the TAH equipped ones (440GX). This enables
> an MTU of 9000 instead 4080.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> ---
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Jeff, please pick up for .25.
Ben.
> drivers/net/ibm_newemac/core.c | 14 ++++----------
> 1 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
> index cb06280..b24bd2d 100644
> --- a/drivers/net/ibm_newemac/core.c
> +++ b/drivers/net/ibm_newemac/core.c
> @@ -1297,7 +1297,6 @@ static int emac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> return emac_xmit_finish(dev, len);
> }
>
> -#ifdef CONFIG_IBM_NEW_EMAC_TAH
> static inline int emac_xmit_split(struct emac_instance *dev, int slot,
> u32 pd, int len, int last, u16 base_ctrl)
> {
> @@ -1410,9 +1409,6 @@ static int emac_start_xmit_sg(struct sk_buff *skb, struct net_device *ndev)
> DBG2(dev, "stopped TX queue" NL);
> return 1;
> }
> -#else
> -# define emac_start_xmit_sg emac_start_xmit
> -#endif /* !defined(CONFIG_IBM_NEW_EMAC_TAH) */
>
> /* Tx lock BHs */
> static void emac_parse_tx_error(struct emac_instance *dev, u16 ctrl)
> @@ -2683,13 +2679,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
>
> /* Fill in the driver function table */
> ndev->open = &emac_open;
> -#ifdef CONFIG_IBM_NEW_EMAC_TAH
> - if (dev->tah_dev) {
> - ndev->hard_start_xmit = &emac_start_xmit_sg;
> + if (dev->tah_dev)
> ndev->features |= NETIF_F_IP_CSUM | NETIF_F_SG;
> - } else
> -#endif
> - ndev->hard_start_xmit = &emac_start_xmit;
> ndev->tx_timeout = &emac_tx_timeout;
> ndev->watchdog_timeo = 5 * HZ;
> ndev->stop = &emac_close;
> @@ -2697,8 +2688,11 @@ static int __devinit emac_probe(struct of_device *ofdev,
> ndev->set_multicast_list = &emac_set_multicast_list;
> ndev->do_ioctl = &emac_ioctl;
> if (emac_phy_supports_gige(dev->phy_mode)) {
> + ndev->hard_start_xmit = &emac_start_xmit_sg;
> ndev->change_mtu = &emac_change_mtu;
> dev->commac.ops = &emac_commac_sg_ops;
> + } else {
> + ndev->hard_start_xmit = &emac_start_xmit;
> }
> SET_ETHTOOL_OPS(ndev, &emac_ethtool_ops);
>
^ permalink raw reply
* Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
From: Zhang, Yanmin @ 2008-01-16 7:15 UTC (permalink / raw)
To: LKML; +Cc: Ilpo Järvinen, Netdev, Herbert Xu, Ingo Molnar
In-Reply-To: <1200443644.3151.33.camel@ymzhang>
On Wed, 2008-01-16 at 08:34 +0800, Zhang, Yanmin wrote:
> On Mon, 2008-01-14 at 21:53 +1100, Herbert Xu wrote:
> > On Mon, Jan 14, 2008 at 08:44:40AM +0000, Ilpo Jrvinen wrote:
> > >
> > > > > I tried to use bisect to locate the bad patch between 2.6.22 and 2.6.23-rc1,
> > > > > but the bisected kernel wasn't stable and went crazy.
> > >
> > > TCP work between that is very much non-existing.
> >
> > Make sure you haven't switched between SLAB/SLUB while testing this.
> I can make sure. In addition, I tried both SLAB and SLUB and make sure the
> regression is still there if CONFIG_SLAB=y.
I retried bisect between 2.6.22 and 2.6.23-rc1. This time, I enabled CONFIG_SLAB=y,
and deleted the warmup procedure in the testing scripts. In addition, bind the 2
processes on the same logical processor. The regression is about 20% which is larger
than the one when binding 2 processes to different core.
The new bisect reported cfs core patch causes it. The results of every step look
stable.
dd41f596cda0d7d6e4a8b139ffdfabcefdd46528 is first bad commit
commit dd41f596cda0d7d6e4a8b139ffdfabcefdd46528
Author: Ingo Molnar <mingo@elte.hu>
Date: Mon Jul 9 18:51:59 2007 +0200
sched: cfs core code
apply the CFS core code.
this change switches over the scheduler core to CFS's modular
design and makes use of kernel/sched_fair/rt/idletask.c to implement
Linux's scheduling policies.
thanks to Andrew Morton and Thomas Gleixner for lots of detailed review
feedback and for fixlets.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
-yanmin
^ permalink raw reply
* Re: Packetlost when "tc qdisc del dev eth0 root"
From: Jarek Poplawski @ 2008-01-16 8:02 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Badalian Vyacheslav, netdev
In-Reply-To: <478D8FC8.9000107@trash.net>
On Wed, Jan 16, 2008 at 06:02:00AM +0100, Patrick McHardy wrote:
...
> This would need support from the qdiscs to do it properly. Looks
> non-trivial for HTB/HFSC/CBQ, but the others shouldn't be that hard.
Yes. At first I've thought this would need quite a lot of work, but
it seems, there could be probably used something very simple too,
like e.g. a 'dummy' sched switcher, which after replacing as a root
the old qdisc and knowing the pointer to the new one could simply
call for dequeing the old one and the new one for everything else.
Then, after completely dequeuing it would call destroy for the old
qdisc and probably switch itself with the new one as a root. If this
new one were created temporarily e.g. on a dummyX dev, and the switch
qdisc added to dummyY (as a temporary holder) with ethX and dummyX as
parameters, it seems this could be done without any API changes.
(But, of course, something more sophisticated should be even better.)
Regards,
Jarek P.
^ permalink raw reply
* Re: Packetlost when "tc qdisc del dev eth0 root"
From: Patrick McHardy @ 2008-01-16 8:05 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Badalian Vyacheslav, netdev
In-Reply-To: <20080116080259.GB1638@ff.dom.local>
Jarek Poplawski wrote:
> On Wed, Jan 16, 2008 at 06:02:00AM +0100, Patrick McHardy wrote:
> ...
>> This would need support from the qdiscs to do it properly. Looks
>> non-trivial for HTB/HFSC/CBQ, but the others shouldn't be that hard.
>
> Yes. At first I've thought this would need quite a lot of work, but
> it seems, there could be probably used something very simple too,
> like e.g. a 'dummy' sched switcher, which after replacing as a root
> the old qdisc and knowing the pointer to the new one could simply
> call for dequeing the old one and the new one for everything else.
> Then, after completely dequeuing it would call destroy for the old
> qdisc and probably switch itself with the new one as a root. If this
> new one were created temporarily e.g. on a dummyX dev, and the switch
> qdisc added to dummyY (as a temporary holder) with ethX and dummyX as
> parameters, it seems this could be done without any API changes.
> (But, of course, something more sophisticated should be even better.)
Yes, thats one possibility (without the dummy device though please).
But I wonder what this would actually be useful for. I don't think
replacing the root qdisc by a different type is a common scenario,
for the same type you can simply use "tc qdisc change", "tc class
change" and "tc class replace".
Badalian, what are you actually doing?
^ permalink raw reply
* Re: Packetlost when "tc qdisc del dev eth0 root"
From: Badalian Vyacheslav @ 2008-01-16 8:35 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Jarek Poplawski, netdev
In-Reply-To: <478DBADB.1080200@trash.net>
>
>
> Yes, thats one possibility (without the dummy device though please).
> But I wonder what this would actually be useful for. I don't think
> replacing the root qdisc by a different type is a common scenario,
> for the same type you can simply use "tc qdisc change", "tc class
> change" and "tc class replace".
>
> Badalian, what are you actually doing?
>
Sorry. Resend to all.
I simple recreate all rules. I change idea from do many
add,change,delete because have many kernel panics on many kernels 2.6.x
First i have panics on "delete filter" operation... was fix it...
great.. then have panics on "delete htb" operation... long time wait to
fix it (maintainer of tc not have time to fix it i think).. but have 1-5
panics at day.... i think my clients hate me =) i rewrite script to
simple recreate all rules... in this method i have small packetlost 1
time in hour (then recreate root qdisc), but not have panics... now i
use new logic of scripts... =)
maybe need go back to accurate logic of scripts, but i to fear kernel
panics =)
P.S. Feature request:
tc class show [ dev STRING ] [ root | parent CLASSID ]
may add classid filter to show?
i need do like this
/sbin/tc -s class show dev eth0 | grep -A2 "htb $HTB "
to get stats of class... but i every run real look all table.. its not good
Thanks that are you interesting history of my problems =)
Slavon.
^ permalink raw reply
* Re: Packetlost when "tc qdisc del dev eth0 root"
From: Jarek Poplawski @ 2008-01-16 8:52 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Badalian Vyacheslav, netdev
In-Reply-To: <478DBADB.1080200@trash.net>
On Wed, Jan 16, 2008 at 09:05:47AM +0100, Patrick McHardy wrote:
...
> Yes, thats one possibility (without the dummy device though please).
> But I wonder what this would actually be useful for. I don't think
> replacing the root qdisc by a different type is a common scenario,
> for the same type you can simply use "tc qdisc change", "tc class
> change" and "tc class replace".
>
> Badalian, what are you actually doing?
I'm not sure Vyacheslav needs just this, but I've thought about the
possibility to recreate the 'shadow' copy of currently used qdisc
tree (with some updates of course) while it's running. So, the
possibility of using all the same handles and classids, and even
dev names if possible, and doing such a switch without any visible
break.
Jarek P.
^ permalink raw reply
* Re: Packetlost when "tc qdisc del dev eth0 root"
From: Badalian Vyacheslav @ 2008-01-16 8:54 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Patrick McHardy, netdev
In-Reply-To: <20080116085254.GB2307@ff.dom.local>
Jarek Poplawski пишет:
> On Wed, Jan 16, 2008 at 09:05:47AM +0100, Patrick McHardy wrote:
> ...
>
>> Yes, thats one possibility (without the dummy device though please).
>> But I wonder what this would actually be useful for. I don't think
>> replacing the root qdisc by a different type is a common scenario,
>> for the same type you can simply use "tc qdisc change", "tc class
>> change" and "tc class replace".
>>
>> Badalian, what are you actually doing?
>>
>
> I'm not sure Vyacheslav needs just this, but I've thought about the
> possibility to recreate the 'shadow' copy of currently used qdisc
> tree (with some updates of course) while it's running. So, the
> possibility of using all the same handles and classids, and even
> dev names if possible, and doing such a switch without any visible
> break.
>
> Jarek P.
>
>
I also think that system must forward all packets what it get if it not
dropped manual (by iptables or shaper).
Maybe someone need to test delete big TREE.. simple delete, not
recreate... linux unavailable some time (if its realy big table its time
may be 10-20 sec on 2xXeon).
I think need helper to do that operations more accurate. Now see
situation that linux is PPTP server... its get 2000k connection... try
delete qdisc on eth0 (incoming from wan to pptp clients)... i think many
sessions will drop.
Thanks!
^ permalink raw reply
* Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: Frans Pop @ 2008-01-16 8:56 UTC (permalink / raw)
To: David Miller; +Cc: jesse.brandeburg, slavon, netdev, linux-kernel
In-Reply-To: <20080115.210214.170759690.davem@davemloft.net>
On Wednesday 16 January 2008, David Miller wrote:
> Ok, here is the patch I'll propose to fix this. The goal is to make
> it as simple as possible without regressing the thing we were trying
> to fix.
Looks good to me. Tested with -rc8.
Cheers,
FJP
^ permalink raw reply
* Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: Badalian Vyacheslav @ 2008-01-16 9:02 UTC (permalink / raw)
To: David Miller; +Cc: elendil, netdev, linux-kernel
In-Reply-To: <20080114.215317.38045859.davem@davemloft.net>
applied to 2.6.24-rc7-git2
Have messages
Also have regression after apply patch.
System may do above 800mbs traffic before patch. After its "exit polling
mode?" (4 CPU, 1 cpu get 100% si (process ksoftirqd/0), 3 CPU is IDLE)
After patch system was go to "exit polling mode" at above 600mbs.
Thanks.
> From: Frans Pop <elendil@planet.nl>
> Date: Tue, 15 Jan 2008 06:25:10 +0100
>
>
>> kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
>>
>
> Does this make the problem go away?
>
> (Note this isn't the final correct patch we should apply. There
> is no reason why this revert back to the older ->poll() logic
> here should have any effect on the TX hang triggering...)
>
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
> index 13d57b0..cada32c 100644
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -3919,7 +3919,7 @@ e1000_clean(struct napi_struct *napi, int budget)
> {
> struct e1000_adapter *adapter = container_of(napi, struct e1000_adapter, napi);
> struct net_device *poll_dev = adapter->netdev;
> - int work_done = 0;
> + int tx_work = 0, work_done = 0;
>
> /* Must NOT use netdev_priv macro here. */
> adapter = poll_dev->priv;
> @@ -3929,8 +3929,8 @@ e1000_clean(struct napi_struct *napi, int budget)
> * simultaneously. A failure obtaining the lock means
> * tx_ring[0] is currently being cleaned anyway. */
> if (spin_trylock(&adapter->tx_queue_lock)) {
> - e1000_clean_tx_irq(adapter,
> - &adapter->tx_ring[0]);
> + tx_work = e1000_clean_tx_irq(adapter,
> + &adapter->tx_ring[0]);
> spin_unlock(&adapter->tx_queue_lock);
> }
>
> @@ -3938,7 +3938,7 @@ e1000_clean(struct napi_struct *napi, int budget)
> &work_done, budget);
>
> /* If budget not fully consumed, exit the polling mode */
> - if (work_done < budget) {
> + if (!tx_work && (work_done < budget)) {
> if (likely(adapter->itr_setting & 3))
> e1000_set_itr(adapter);
> netif_rx_complete(poll_dev, napi);
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: Packetlost when "tc qdisc del dev eth0 root"
From: Jarek Poplawski @ 2008-01-16 9:42 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: Patrick McHardy, netdev
In-Reply-To: <478DC1D7.90401@bigtelecom.ru>
On Wed, Jan 16, 2008 at 11:35:35AM +0300, Badalian Vyacheslav wrote:
...
> I simple recreate all rules. I change idea from do many add,change,delete
> because have many kernel panics on many kernels 2.6.x
> First i have panics on "delete filter" operation... was fix it... great..
> then have panics on "delete htb" operation... long time wait to fix it
> (maintainer of tc not have time to fix it i think).. but have 1-5 panics at
> day.... i think my clients hate me =) i rewrite script to simple recreate
> all rules... in this method i have small packetlost 1 time in hour (then
> recreate root qdisc), but not have panics... now i use new logic of
> scripts... =)
> maybe need go back to accurate logic of scripts, but i to fear kernel
> panics =)
BTW, I don't know about others, but it seems this bugzilla #9632 waits
for your testing, to find the reason of this bug... IMHO, if you can't
try this now, it's better to close this or/and at least add some
comment. And if there are any other bugs unfixed which are
reproducible and you can test (or have tested) some patches, please
resend them as new threads to the list. Alas, omitting the panics
can't help in removing these bugs.
Jarek P.
^ permalink raw reply
* [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Stefan Roese @ 2008-01-16 9:37 UTC (permalink / raw)
To: linuxppc-dev, netdev; +Cc: benh
With the removal the the "rgmii-interface" device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/rgmii.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index 9bc1132..5757788 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
static struct of_device_id rgmii_match[] =
{
{
- .type = "rgmii-interface",
.compatible = "ibm,rgmii",
},
{
--
1.5.4.rc3
^ permalink raw reply related
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: David Gibson @ 2008-01-16 9:39 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200476230-14026-1-git-send-email-sr@denx.de>
On Wed, Jan 16, 2008 at 10:37:10AM +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
In fact, this patch should go in before the one changing the dts
files.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: SO_RCVBUF doesn't change receiver advertised window
From: Bill Fink @ 2008-01-16 9:50 UTC (permalink / raw)
To: Ritesh Kumar; +Cc: netdev
In-Reply-To: <f47983b00801151236l3b06f6dci35898fee71f6a942@mail.gmail.com>
On Tue, 15 Jan 2008, Ritesh Kumar wrote:
> Hi,
> I am using linux 2.6.20 and am trying to limit the receiver window
> size for a TCP connection. However, it seems that auto tuning is not
> turning itself off even after I use the syscall
>
> rwin=65536
> setsockopt(sock, SOL_SOCKET, SO_RCVBUF, &rwin, sizeof(rwin));
>
> and verify using
>
> getsockopt(sock, SOL_SOCKET, SO_RCVBUF, &rwin, &rwin_size);
>
> that RCVBUF indeed is getting set (the value returned from getsockopt
> is double that, 131072).
Linux doubles what you requested, and then uses (by default) 1/4
of the socket space for overhead, so you effectively get 1.5 times
what you requested as an actual advertised receiver window, which
means since you specified 64 KB, you actually get 96 KB.
> The above calls are made before connect() on the client side and
> before bind(), accept() on the server side. Bulk data is being sent
> from the client to the server. The client and the server machines also
> have tcp_moderate_rcvbuf set to 0 (though I don't think that's really
> needed; setting a value to SO_RCVBUF should automatically turnoff auto
> tuning.).
>
> However the tcp trace shows the SYN, SYN/ACK and the first few packets as:
> 14:34:18.831703 IP 192.168.1.153.45038 > 192.168.2.204.9999: S
> 3947298186:3947298186(0) win 5840 <mss 1460,sackOK,timestamp 2842625
> 0,nop,wscale 5>
> 14:34:18.836000 IP 192.168.2.204.9999 > 192.168.1.153.45038: S
> 3955381015:3955381015(0) ack 3947298187 win 5792 <mss
> 1460,sackOK,timestamp 2843649 2842625,nop,wscale 2>
> 14:34:18.837654 IP 192.168.1.153.45038 > 192.168.2.204.9999: . ack 1
> win 183 <nop,nop,timestamp 2842634 2843649>
> 14:34:18.837849 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
> 1:1449(1448) ack 1 win 183 <nop,nop,timestamp 2842634 2843649>
> 14:34:18.837851 IP 192.168.1.153.45038 > 192.168.2.204.9999: P
> 1449:1461(12) ack 1 win 183 <nop,nop,timestamp 2842634 2843649>
> 14:34:18.839001 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
> 1449 win 2172 <nop,nop,timestamp 2843652 2842634>
> 14:34:18.839011 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
> 1461 win 2172 <nop,nop,timestamp 2843652 2842634>
> 14:34:18.840875 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
> 1461:2909(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
> 14:34:18.840997 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
> 2909:4357(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
> 14:34:18.841120 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
> 4357:5805(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
> 14:34:18.841244 IP 192.168.1.153.45038 > 192.168.2.204.9999: .
> 5805:7253(1448) ack 1 win 183 <nop,nop,timestamp 2842637 2843652>
> 14:34:18.841388 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
> 2909 win 2896 <nop,nop,timestamp 2843655 2842637>
> 14:34:18.841399 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
> 4357 win 3620 <nop,nop,timestamp 2843655 2842637>
> 14:34:18.841413 IP 192.168.2.204.9999 > 192.168.1.153.45038: . ack
> 5805 win 4344 <nop,nop,timestamp 2843655 2842637>
>
> As you can see, the syn and syn ack show rcv windows to be 5840 and
> 5792 and it automatically increases for the receiver to values 2172
> till 4344 and more in the later part of the trace till 24214.
Since the window scale was 2, the final advertised receiver window
you indicate of 24214 gives 2^2*24214 or right around 96 KB, which
is what is expected given the way Linux works.
-Bill
> The values for the tcp sysctl variables are given below:
> /proc/sys/net/ipv4/tcp_moderate_rcvbuf 0
> /proc/sys/net/ipv4/tcp_mem 32768 43690 65536
> /proc/sys/net/ipv4/tcp_rmem 4096 87380 1398080
> /proc/sys/net/ipv4/tcp_wmem 4096 16384 1398080
> /proc/sys/net/core/rmem_max 131071
> /proc/sys/net/core/wmem_max 131071
> /proc/sys/net/core/wmem_default 109568
> /proc/sys/net/core/rmem_default 109568
>
> I will really appreciate your help,
>
> Ritesh
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Benjamin Herrenschmidt @ 2008-01-16 9:53 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <1200476230-14026-1-git-send-email-sr@denx.de>
On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> With the removal the the "rgmii-interface" device_type property from the
> dts files, the newemac driver needs an update to only rely on compatible
> property.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
I need to test if it works on CAB, can't change the DT on those. I'll
let you know tomorrow.
> ---
> drivers/net/ibm_newemac/rgmii.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
> index 9bc1132..5757788 100644
> --- a/drivers/net/ibm_newemac/rgmii.c
> +++ b/drivers/net/ibm_newemac/rgmii.c
> @@ -302,7 +302,6 @@ static int __devexit rgmii_remove(struct of_device *ofdev)
> static struct of_device_id rgmii_match[] =
> {
> {
> - .type = "rgmii-interface",
> .compatible = "ibm,rgmii",
> },
> {
^ permalink raw reply
* [PATCH] ICMP: ICMP_MIB_OUTMSGS increment duplicated
From: Wang Chen @ 2008-01-16 9:59 UTC (permalink / raw)
To: David S. Miller, David L Stevens; +Cc: netdev
In tree net-2.6.25, commit "96793b482540f3a26e2188eaf75cb56b7829d3e3"
made a mistake.
In that patch, David L added a icmp_out_count() in ip_push_pending_frames(),
remove icmp_out_count() from icmp_reply(). But he forgot to remove
icmp_out_count() from icmp_send() too.
Since icmp_send and icmp_reply will call icmp_push_reply, which will call
ip_push_pending_frames, a duplicated increment happened in icmp_send.
This patch remove the icmp_out_count from icmp_send too.
Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com>
---
diff -Nurp linux-2.6.24.rc8.org/net/ipv4/icmp.c linux-2.6.24.rc8/net/ipv4/icmp.c
--- linux-2.6.24.rc8.org/net/ipv4/icmp.c 2008-01-16 17:45:02.000000000 +0800
+++ linux-2.6.24.rc8/net/ipv4/icmp.c 2008-01-16 17:52:13.000000000 +0800
@@ -540,7 +540,6 @@ void icmp_send(struct sk_buff *skb_in, i
icmp_param.data.icmph.checksum = 0;
icmp_param.skb = skb_in;
icmp_param.offset = skb_network_offset(skb_in);
- icmp_out_count(icmp_param.data.icmph.type);
inet_sk(icmp_socket->sk)->tos = tos;
ipc.addr = iph->saddr;
ipc.opt = &icmp_param.replyopts;
--
WCN
^ permalink raw reply
* Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: David Miller @ 2008-01-16 10:29 UTC (permalink / raw)
To: elendil; +Cc: jesse.brandeburg, slavon, netdev, linux-kernel
In-Reply-To: <200801160956.09053.elendil@planet.nl>
From: Frans Pop <elendil@planet.nl>
Date: Wed, 16 Jan 2008 09:56:08 +0100
> On Wednesday 16 January 2008, David Miller wrote:
> > Ok, here is the patch I'll propose to fix this. The goal is to make
> > it as simple as possible without regressing the thing we were trying
> > to fix.
>
> Looks good to me. Tested with -rc8.
Thanks for testing.
^ permalink raw reply
* [PATCH 1/2] [IPV4] fib_hash: fix duplicated route issue
From: Joonwoo Park @ 2008-01-16 11:13 UTC (permalink / raw)
To: David Miller
Cc: Joonwoo Park, linux-netdev, Stephen Hemminger, Alexander Zubkov
http://bugzilla.kernel.org/show_bug.cgi?id=9493
The fib allows making identical routes with 'ip route replace'.
This patch makes the fib return -EEXIST if replacement would cause duplication.
Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
---
net/ipv4/fib_hash.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/fib_hash.c b/net/ipv4/fib_hash.c
index 527a6e0..99071d7 100644
--- a/net/ipv4/fib_hash.c
+++ b/net/ipv4/fib_hash.c
@@ -444,6 +444,9 @@ static int fn_hash_insert(struct fib_table *tb, struct fib_config *cfg)
struct fib_info *fi_drop;
u8 state;
+ if (fi->fib_treeref > 1)
+ goto out;
+
write_lock_bh(&fib_hash_lock);
fi_drop = fa->fa_info;
fa->fa_info = fi;
--
1.5.3.rc5
^ permalink raw reply related
* [PATCH 2/2] [IPV4] fib_trie: fix duplicated route issue
From: Joonwoo Park @ 2008-01-16 11:13 UTC (permalink / raw)
To: David Miller
Cc: Joonwoo Park, linux-netdev, Stephen Hemminger, Alexander Zubkov
http://bugzilla.kernel.org/show_bug.cgi?id=9493
The fib allows making identical routes with 'ip route replace'.
This patch makes the fib return -EEXIST if replacement would cause duplication.
Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
---
net/ipv4/fib_trie.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 8d8c291..1010b46 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1214,6 +1214,9 @@ static int fn_trie_insert(struct fib_table *tb, struct fib_config *cfg)
struct fib_info *fi_drop;
u8 state;
+ if (fi->fib_treeref > 1)
+ goto out;
+
err = -ENOBUFS;
new_fa = kmem_cache_alloc(fn_alias_kmem, GFP_KERNEL);
if (new_fa == NULL)
--
1.5.3.rc5
^ permalink raw reply related
* RE: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
From: Kalra Ashish @ 2008-01-16 11:47 UTC (permalink / raw)
To: Kumar Gala, Andrew Morton
Cc: Phillips Kim, Aggrwal Poonam, sfr, rubini, linux-ppcdev, netdev,
linux-kernel, Barkowski Michael, Cutler Richard, Kalra Ashish,
Suresh PV
In-Reply-To: <5927F7A4-D42A-40F6-AE9C-EDA34738A752@kernel.crashing.org>
Hello All,
I am sure that the TDM bus driver model/framework will make us put a lot
more programming effort without
any assurance of the code being accepted by the Linux community,
especially as there are many
Telephony/VoIP stack implementations in Linux such as the Sangoma
WANPIPE Kernel suite which
have their own Zaptel TDM (channelized zero-copy) interface layer. There
are other High Speed serial (HSS)
API interfaces, again supporting channelized and/or prioritized API
interfaces. All these implementations
are proprietary and have their own tightly coupled upper layers and
hardware abstraction layers. It is
difficult to predict that these stacks will move towards a generic TDM
bus driver interface. Therefore, i think
we can have our own tightly coupled interface with our VoIP framework
and let us the keep the driver as it is,
i.e., as a misc driver.
Ashish
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Tuesday, January 15, 2008 9:01 AM
To: Andrew Morton
Cc: Phillips Kim; Aggrwal Poonam; sfr@canb.auug.org.au;
rubini@vision.unipv.it; linux-ppcdev@ozlabs.kernel.org;
netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Barkowski Michael;
Kalra Ashish; Cutler Richard
Subject: Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
On Jan 14, 2008, at 3:15 PM, Andrew Morton wrote:
> On Mon, 14 Jan 2008 12:00:51 -0600
> Kim Phillips <kim.phillips@freescale.com> wrote:
>
>> On Thu, 10 Jan 2008 21:41:20 -0700
>> "Aggrwal Poonam" <Poonam.Aggrwal@freescale.com> wrote:
>>
>>> Hello All
>>>
>>> I am waiting for more feedback on the patches.
>>>
>>> If there are no objections please consider them for 2.6.25.
>>>
>> if this isn't going to go through Alessandro Rubini/misc drivers, can
>> it go through the akpm/mm tree?
>>
>
> That would work. But it might be more appropriate to go Kumar-
> >paulus->Linus.
I'm ok w/taking the arch/powerpc bits, but I"m a bit concerned about
the driver itself. I'm wondering if we need a TDM framework in the
kernel.
I guess if Poonam could possibly describe how this driver is actually
used that would be helpful. I see we have 8315 with a discrete TDM
block and I'm guessing 82xx/85xx based CPM parts of some form of TDM
as well.
- k
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox