* [rfc] IPVS: convert scheduler management to RCU
From: Simon Horman @ 2010-08-20 13:33 UTC (permalink / raw)
To: lvs-devel, netdev, netfilter-devel
Cc: Stephen Hemminger, Wensong Zhang, Julian Anastasov
Signed-off-by: Simon Horman <horms@verge.net.au>
---
I'm still getting my head around RCU, so review would be greatly appreciated.
It occurs to me that this code is not performance critical, so
perhaps simply replacing the rwlock with a spinlock would be better?
Index: nf-next-2.6/net/netfilter/ipvs/ip_vs_sched.c
===================================================================
--- nf-next-2.6.orig/net/netfilter/ipvs/ip_vs_sched.c 2010-08-20 22:21:01.000000000 +0900
+++ nf-next-2.6/net/netfilter/ipvs/ip_vs_sched.c 2010-08-20 22:21:51.000000000 +0900
@@ -35,7 +35,7 @@
static LIST_HEAD(ip_vs_schedulers);
/* lock for service table */
-static DEFINE_RWLOCK(__ip_vs_sched_lock);
+static DEFINE_SPINLOCK(ip_vs_sched_mutex);
/*
@@ -91,9 +91,9 @@ static struct ip_vs_scheduler *ip_vs_sch
IP_VS_DBG(2, "%s(): sched_name \"%s\"\n", __func__, sched_name);
- read_lock_bh(&__ip_vs_sched_lock);
+ rcu_read_lock_bh();
- list_for_each_entry(sched, &ip_vs_schedulers, n_list) {
+ list_for_each_entry_rcu(sched, &ip_vs_schedulers, n_list) {
/*
* Test and get the modules atomically
*/
@@ -105,14 +105,14 @@ static struct ip_vs_scheduler *ip_vs_sch
}
if (strcmp(sched_name, sched->name)==0) {
/* HIT */
- read_unlock_bh(&__ip_vs_sched_lock);
+ rcu_read_unlock_bh();
return sched;
}
if (sched->module)
module_put(sched->module);
}
- read_unlock_bh(&__ip_vs_sched_lock);
+ rcu_read_unlock_bh();
return NULL;
}
@@ -167,10 +167,10 @@ int register_ip_vs_scheduler(struct ip_v
/* increase the module use count */
ip_vs_use_count_inc();
- write_lock_bh(&__ip_vs_sched_lock);
+ spin_lock_bh(&ip_vs_sched_mutex);
if (!list_empty(&scheduler->n_list)) {
- write_unlock_bh(&__ip_vs_sched_lock);
+ spin_unlock_bh(&ip_vs_sched_mutex);
ip_vs_use_count_dec();
pr_err("%s(): [%s] scheduler already linked\n",
__func__, scheduler->name);
@@ -181,9 +181,9 @@ int register_ip_vs_scheduler(struct ip_v
* Make sure that the scheduler with this name doesn't exist
* in the scheduler list.
*/
- list_for_each_entry(sched, &ip_vs_schedulers, n_list) {
+ list_for_each_entry_rcu(sched, &ip_vs_schedulers, n_list) {
if (strcmp(scheduler->name, sched->name) == 0) {
- write_unlock_bh(&__ip_vs_sched_lock);
+ spin_unlock_bh(&ip_vs_sched_mutex);
ip_vs_use_count_dec();
pr_err("%s(): [%s] scheduler already existed "
"in the system\n", __func__, scheduler->name);
@@ -193,8 +193,8 @@ int register_ip_vs_scheduler(struct ip_v
/*
* Add it into the d-linked scheduler list
*/
- list_add(&scheduler->n_list, &ip_vs_schedulers);
- write_unlock_bh(&__ip_vs_sched_lock);
+ list_add_rcu(&scheduler->n_list, &ip_vs_schedulers);
+ spin_unlock_bh(&ip_vs_sched_mutex);
pr_info("[%s] scheduler registered.\n", scheduler->name);
@@ -212,9 +212,9 @@ int unregister_ip_vs_scheduler(struct ip
return -EINVAL;
}
- write_lock_bh(&__ip_vs_sched_lock);
+ spin_lock_bh(&ip_vs_sched_mutex);
if (list_empty(&scheduler->n_list)) {
- write_unlock_bh(&__ip_vs_sched_lock);
+ spin_unlock_bh(&ip_vs_sched_mutex);
pr_err("%s(): [%s] scheduler is not in the list. failed\n",
__func__, scheduler->name);
return -EINVAL;
@@ -223,8 +223,8 @@ int unregister_ip_vs_scheduler(struct ip
/*
* Remove it from the d-linked scheduler list
*/
- list_del(&scheduler->n_list);
- write_unlock_bh(&__ip_vs_sched_lock);
+ list_del_rcu(&scheduler->n_list);
+ spin_unlock_bh(&ip_vs_sched_mutex);
/* decrease the module use count */
ip_vs_use_count_dec();
^ permalink raw reply
* [PATCH net-next-2.6] amd8111e: use net_device_stats from struct net_device
From: Eric Dumazet @ 2010-08-20 13:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev
struct net_device has its own struct net_device_stats member, so use
this one instead of a private copy in the amd8111e_priv struct.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/amd8111e.c | 14 +++++++-------
drivers/net/amd8111e.h | 1 -
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/amd8111e.c b/drivers/net/amd8111e.c
index 1f5fc64..58a0ab4 100644
--- a/drivers/net/amd8111e.c
+++ b/drivers/net/amd8111e.c
@@ -903,18 +903,18 @@ static int amd8111e_read_mib(void __iomem *mmio, u8 MIB_COUNTER)
}
/*
-This function reads the mib registers and returns the hardware statistics. It updates previous internal driver statistics with new values.
-*/
-static struct net_device_stats *amd8111e_get_stats(struct net_device * dev)
+ * This function reads the mib registers and returns the hardware statistics.
+ * It updates previous internal driver statistics with new values.
+ */
+static struct net_device_stats *amd8111e_get_stats(struct net_device *dev)
{
struct amd8111e_priv *lp = netdev_priv(dev);
void __iomem *mmio = lp->mmio;
unsigned long flags;
- /* struct net_device_stats *prev_stats = &lp->prev_stats; */
- struct net_device_stats* new_stats = &lp->stats;
+ struct net_device_stats *new_stats = &dev->stats;
- if(!lp->opened)
- return &lp->stats;
+ if (!lp->opened)
+ return new_stats;
spin_lock_irqsave (&lp->lock, flags);
/* stats.rx_packets */
diff --git a/drivers/net/amd8111e.h b/drivers/net/amd8111e.h
index ac36eb6..b5926af 100644
--- a/drivers/net/amd8111e.h
+++ b/drivers/net/amd8111e.h
@@ -787,7 +787,6 @@ struct amd8111e_priv{
struct vlan_group *vlgrp;
#endif
char opened;
- struct net_device_stats stats;
unsigned int drv_rx_errors;
struct amd8111e_coalesce_conf coal_conf;
^ permalink raw reply related
* [PATCH net-next-2.6] atl1c: use net_device_stats from struct net_device
From: Eric Dumazet @ 2010-08-20 12:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jie Yang
struct net_device has its own struct net_device_stats member, so use
this one instead of a private copy in the atl1c_adapter struct.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/net/atl1c/atl1c.h | 1 -
drivers/net/atl1c/atl1c_main.c | 6 +++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/atl1c/atl1c.h b/drivers/net/atl1c/atl1c.h
index 52abbbd..ef4115b 100644
--- a/drivers/net/atl1c/atl1c.h
+++ b/drivers/net/atl1c/atl1c.h
@@ -559,7 +559,6 @@ struct atl1c_adapter {
struct napi_struct napi;
struct atl1c_hw hw;
struct atl1c_hw_stats hw_stats;
- struct net_device_stats net_stats;
struct mii_if_info mii; /* MII interface info */
u16 rx_buffer_len;
diff --git a/drivers/net/atl1c/atl1c_main.c b/drivers/net/atl1c/atl1c_main.c
index c7b8ef5..61f1634 100644
--- a/drivers/net/atl1c/atl1c_main.c
+++ b/drivers/net/atl1c/atl1c_main.c
@@ -1562,7 +1562,7 @@ static struct net_device_stats *atl1c_get_stats(struct net_device *netdev)
{
struct atl1c_adapter *adapter = netdev_priv(netdev);
struct atl1c_hw_stats *hw_stats = &adapter->hw_stats;
- struct net_device_stats *net_stats = &adapter->net_stats;
+ struct net_device_stats *net_stats = &netdev->stats;
atl1c_update_hw_stats(adapter);
net_stats->rx_packets = hw_stats->rx_ok;
@@ -1590,7 +1590,7 @@ static struct net_device_stats *atl1c_get_stats(struct net_device *netdev)
net_stats->tx_aborted_errors = hw_stats->tx_abort_col;
net_stats->tx_window_errors = hw_stats->tx_late_col;
- return &adapter->net_stats;
+ return net_stats;
}
static inline void atl1c_clear_phy_int(struct atl1c_adapter *adapter)
@@ -1700,7 +1700,7 @@ static irqreturn_t atl1c_intr(int irq, void *data)
/* link event */
if (status & (ISR_GPHY | ISR_MANUAL)) {
- adapter->net_stats.tx_carrier_errors++;
+ netdev->stats.tx_carrier_errors++;
atl1c_link_chg_event(adapter);
break;
}
^ permalink raw reply related
* Re: dccp test-tree [Patch 1/1] ccid-3: use per-route min-RTO and/or TCP default
From: Ivo Calado @ 2010-08-20 12:38 UTC (permalink / raw)
To: Gerrit Renker, Leandro, Ivo Calado, dccp, netdev
In-Reply-To: <20100816051936.GD3571@gerrit.erg.abdn.ac.uk>
Acked-by: Ivo Calado <ivocalado@embedded.ufcg.edu.br> for ccid4 subtree
On Mon, Aug 16, 2010 at 02:19, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> This patch relates to the similar one submitted last week for CCID-2.
>
> It replaces the hardcoded (Kconfig) value of the minimum RTO value with
> a reconfigurable, per-route value which falls back to the TCP minimum
> RTO value.
>
> Leando, Ivo, can you please have a look and indicate whether you are ok
> with this? If yes I would like to also update the CCID-4 tree to make it
> consistent with the test tree - for this reason the test tree has not yet
> been updated.
>
>>>>>>>>>>>>>>>>>>>>>>>> Patch <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> dccp ccid-3: use per-route RTO or TCP RTO as fallback
>
> This makes the TCP (per-route) RTO value also available to CCID-3, hence it
> is now possible to influence this value at runtime rather than, as before,
> via Kconfig.
>
> The same effect as the default Kconfig option of 100ms is now achieved by
>
>> ip route replace to unicast 192.168.0.0/24 rto_min 100j dev eth0
>
> (assuming HZ=1000).
>
> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
> ---
> net/dccp/ccids/Kconfig | 31 -------------------------------
> net/dccp/ccids/ccid3.c | 9 ++++-----
> 2 files changed, 4 insertions(+), 36 deletions(-)
>
> --- a/net/dccp/ccids/Kconfig
> +++ b/net/dccp/ccids/Kconfig
> @@ -47,37 +47,6 @@ config IP_DCCP_CCID3_DEBUG
>
> If in doubt, say N.
>
> -config IP_DCCP_CCID3_RTO
> - int "Use higher bound for nofeedback timer"
> - default 100
> - depends on IP_DCCP_CCID3 && EXPERIMENTAL
> - ---help---
> - Use higher lower bound for nofeedback timer expiration.
> -
> - The TFRC nofeedback timer normally expires after the maximum of 4
> - RTTs and twice the current send interval (RFC 3448, 4.3). On LANs
> - with a small RTT this can mean a high processing load and reduced
> - performance, since then the nofeedback timer is triggered very
> - frequently.
> -
> - This option enables to set a higher lower bound for the nofeedback
> - value. Values in units of milliseconds can be set here.
> -
> - A value of 0 disables this feature by enforcing the value specified
> - in RFC 3448. The following values have been suggested as bounds for
> - experimental use:
> - * 16-20ms to match the typical multimedia inter-frame interval
> - * 100ms as a reasonable compromise [default]
> - * 1000ms corresponds to the lower TCP RTO bound (RFC 2988, 2.4)
> -
> - The default of 100ms is a compromise between a large value for
> - efficient DCCP implementations, and a small value to avoid disrupting
> - the network in times of congestion.
> -
> - The purpose of the nofeedback timer is to slow DCCP down when there
> - is serious network congestion: experimenting with larger values should
> - therefore not be performed on WANs.
> -
> config IP_DCCP_TFRC_LIB
> def_bool y if IP_DCCP_CCID3
>
> --- a/net/dccp/ccids/ccid3.c
> +++ b/net/dccp/ccids/ccid3.c
> @@ -461,12 +461,11 @@ done_computing_x:
>
> /*
> * Update timeout interval for the nofeedback timer.
> - * We use a configuration option to increase the lower bound.
> - * This can help avoid triggering the nofeedback timer too
> - * often ('spinning') on LANs with small RTTs.
> + * We use the current (per-route) value of the TCP RTO as lower bound
> + * to slow down rate-halving on networks with small RTTs (loopback,
> + * running DCCP in a virtual machine, Gbit ethernet, etc).
> */
> - hc->tx_t_rto = max_t(u32, 4 * hc->tx_rtt, (CONFIG_IP_DCCP_CCID3_RTO *
> - (USEC_PER_SEC / 1000)));
> + hc->tx_t_rto = max(4 * hc->tx_rtt, USEC_PER_SEC/HZ * tcp_rto_min(sk));
> /*
> * Schedule no feedback timer to expire in
> * max(t_RTO, 2 * s/X) = max(t_RTO, 2 * t_ipi)
>
--
Ivo Augusto Andrade Rocha Calado
PhD candidate in Electrical Engineering
Embedded Systems and Pervasive Computing Lab - http://embedded.ufcg.edu.br
Electrical Engineering Department - http://dee.ufcg.edu.br/
Electrical Engineering and Informatics Center - http://www.ceei.ufcg.edu.br
Federal University of Campina Grande - http://www.ufcg.edu.br
PGP: 0xD7C3860A pgp.mit.edu
Putt's Law:
Technology is dominated by two types of people:
Those who understand what they do not manage.
Those who manage what they do not understand.
^ permalink raw reply
* (unknown),
From: Mr. Vincent Cheng @ 2010-08-20 12:12 UTC (permalink / raw)
Good Day,
I have a business proposal of USD $22,500,000.00 only for you to
transact with me from my bank to your country.
Reply to address:choi_chu008@yahoo.co.jp and I will let you know what
is required of you.
Best Regards,
Mr. Vincent Cheng
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-20 10:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <1282299972.2484.21.camel@edumazet-laptop>
На 20.8.2010 г. 13:26, Eric Dumazet написа:
> Le vendredi 20 août 2010 à 12:19 +0300, Plamen Petrov a écrit :
>> На 20.8.2010 г. 11:31, Plamen Petrov написа:
>> ...
...
>>
>> Where to next?
>
>
> First, thanks a lot for finding this so fast.
For nothing.
>
> Hmmm, please check that on your net/core/dev.c file, line 3146 you have
> the fix added in
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e5093aec2e6b60c3df2420057ffab9ed4a6d2792
>
> commit e5093aec2e6b60c3df2420057ffab9ed4a6d2792
> Author: Jarek Poplawski<jarkao2@gmail.com>
> Date: Wed Aug 11 02:02:10 2010 +0000
>
> net: Fix a memmove bug in dev_gro_receive()
>
>
>
> --skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
>
Yes, I confirm I have the above code in place.
>
> If yes, I think David& Herbert will probably have to dig again into gro
> code :(
>
So, I guess its David and Herbert's turn?...
Thanks!
Plamen
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Eric Dumazet @ 2010-08-20 10:26 UTC (permalink / raw)
To: Plamen Petrov; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4C6E488A.4010100@fs.uni-ruse.bg>
Le vendredi 20 août 2010 à 12:19 +0300, Plamen Petrov a écrit :
> На 20.8.2010 г. 11:31, Plamen Petrov написа:
> ...
> > The next thing I will be trying is disabling
> > GRO for the tg3 network card in my network
> > startup scripts via my shiny new ethtool... ;)
>
> So, for nearly half an hour now running 2.6.36-rc1-FS-00127-g763008c:
>
> >
> root@fs:~# w; uname -a
> > 12:09:48 up 26 min, 1 user, load average: 2.43, 1.93, 1.26
> > USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
> > root pts/0 192.168.10.159 12:09 0.00s 0.02s 0.00s w
> > Linux fs 2.6.36-rc1-FS-00127-g763008c #1 SMP Thu Aug 19 07:10:57 UTC 2010 i686 Intel(R) Pentium(R) D CPU 3.00GHz GenuineIntel GNU/Linux
>
> And that's with the usual load, which can be found here:
> http://pvp.now.im/s/drraw.cgi?Mode=view;Dashboard=1173713287.13177
>
> The only addition I made was running
> ethtool -K ethX gro off
> for each network card.
>
> Which means that I have a Broadcom Tygon 3 (tg3) which doesn't
> like "generic-receive-offload" at all!
>
> With "generic-receive-offload" off, I will stay on
> 2.6.36-rc1-FS-00127-g763008c for as long as I can, just to
> confirm that in fact the "default on" setting for gro in the
> tg3 driver is the culprit for my troubles...
>
> Where to next?
First, thanks a lot for finding this so fast.
Hmmm, please check that on your net/core/dev.c file, line 3146 you have
the fix added in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e5093aec2e6b60c3df2420057ffab9ed4a6d2792
commit e5093aec2e6b60c3df2420057ffab9ed4a6d2792
Author: Jarek Poplawski <jarkao2@gmail.com>
Date: Wed Aug 11 02:02:10 2010 +0000
net: Fix a memmove bug in dev_gro_receive()
--skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
If yes, I think David & Herbert will probably have to dig again into gro
code :(
^ permalink raw reply
* Re: [PATCH] irda: fix a race in irlan_eth_xmit()
From: Eric Dumazet @ 2010-08-20 9:51 UTC (permalink / raw)
To: David Miller; +Cc: samuel, netdev
In-Reply-To: <20100819.004202.84378290.davem@davemloft.net>
Le jeudi 19 août 2010 à 00:42 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 18 Aug 2010 12:24:43 +0200
>
> > After skb is queued, its illegal to dereference it.
> >
> > Cache skb->len into a temporary variable.
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied, thanks.
Thanks David
On top of this patch (that you added in net-2.6 if I understood well), I
cooked following one, for net-next-2.6 this time.
[PATCH net-next-2.6] irda: use net_device_stats from struct net_device
struct net_device has its own struct net_device_stats member, so use
this one instead of a private copy in the irlan_cb struct.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/irda/irlan_common.h | 1
net/irda/irlan/irlan_eth.c | 32 ++++++++----------------------
2 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/include/net/irda/irlan_common.h b/include/net/irda/irlan_common.h
index 73cacb3..0af8b8d 100644
--- a/include/net/irda/irlan_common.h
+++ b/include/net/irda/irlan_common.h
@@ -171,7 +171,6 @@ struct irlan_cb {
int magic;
struct list_head dev_list;
struct net_device *dev; /* Ethernet device structure*/
- struct net_device_stats stats;
__u32 saddr; /* Source device address */
__u32 daddr; /* Destination device address */
diff --git a/net/irda/irlan/irlan_eth.c b/net/irda/irlan/irlan_eth.c
index 5bb8353..8ee1ff6 100644
--- a/net/irda/irlan/irlan_eth.c
+++ b/net/irda/irlan/irlan_eth.c
@@ -45,13 +45,11 @@ static int irlan_eth_close(struct net_device *dev);
static netdev_tx_t irlan_eth_xmit(struct sk_buff *skb,
struct net_device *dev);
static void irlan_eth_set_multicast_list( struct net_device *dev);
-static struct net_device_stats *irlan_eth_get_stats(struct net_device *dev);
static const struct net_device_ops irlan_eth_netdev_ops = {
.ndo_open = irlan_eth_open,
.ndo_stop = irlan_eth_close,
.ndo_start_xmit = irlan_eth_xmit,
- .ndo_get_stats = irlan_eth_get_stats,
.ndo_set_multicast_list = irlan_eth_set_multicast_list,
.ndo_change_mtu = eth_change_mtu,
.ndo_validate_addr = eth_validate_addr,
@@ -208,10 +206,10 @@ static netdev_tx_t irlan_eth_xmit(struct sk_buff *skb,
* tried :-) DB
*/
/* irttp_data_request already free the packet */
- self->stats.tx_dropped++;
+ dev->stats.tx_dropped++;
} else {
- self->stats.tx_packets++;
- self->stats.tx_bytes += len;
+ dev->stats.tx_packets++;
+ dev->stats.tx_bytes += len;
}
return NETDEV_TX_OK;
@@ -226,15 +224,16 @@ static netdev_tx_t irlan_eth_xmit(struct sk_buff *skb,
int irlan_eth_receive(void *instance, void *sap, struct sk_buff *skb)
{
struct irlan_cb *self = instance;
+ struct net_device *dev = self->dev;
if (skb == NULL) {
- ++self->stats.rx_dropped;
+ dev->stats.rx_dropped++;
return 0;
}
if (skb->len < ETH_HLEN) {
IRDA_DEBUG(0, "%s() : IrLAN frame too short (%d)\n",
__func__, skb->len);
- ++self->stats.rx_dropped;
+ dev->stats.rx_dropped++;
dev_kfree_skb(skb);
return 0;
}
@@ -244,10 +243,10 @@ int irlan_eth_receive(void *instance, void *sap, struct sk_buff *skb)
* might have been previously set by the low level IrDA network
* device driver
*/
- skb->protocol = eth_type_trans(skb, self->dev); /* Remove eth header */
+ skb->protocol = eth_type_trans(skb, dev); /* Remove eth header */
- self->stats.rx_packets++;
- self->stats.rx_bytes += skb->len;
+ dev->stats.rx_packets++;
+ dev->stats.rx_bytes += skb->len;
netif_rx(skb); /* Eat it! */
@@ -348,16 +347,3 @@ static void irlan_eth_set_multicast_list(struct net_device *dev)
else
irlan_set_broadcast_filter(self, FALSE);
}
-
-/*
- * Function irlan_get_stats (dev)
- *
- * Get the current statistics for this device
- *
- */
-static struct net_device_stats *irlan_eth_get_stats(struct net_device *dev)
-{
- struct irlan_cb *self = netdev_priv(dev);
-
- return &self->stats;
-}
^ permalink raw reply related
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-20 9:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4C6E3D58.5080303@fs.uni-ruse.bg>
На 20.8.2010 г. 11:31, Plamen Petrov написа:
...
> The next thing I will be trying is disabling
> GRO for the tg3 network card in my network
> startup scripts via my shiny new ethtool... ;)
So, for nearly half an hour now running 2.6.36-rc1-FS-00127-g763008c:
>
root@fs:~# w; uname -a
> 12:09:48 up 26 min, 1 user, load average: 2.43, 1.93, 1.26
> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
> root pts/0 192.168.10.159 12:09 0.00s 0.02s 0.00s w
> Linux fs 2.6.36-rc1-FS-00127-g763008c #1 SMP Thu Aug 19 07:10:57 UTC 2010 i686 Intel(R) Pentium(R) D CPU 3.00GHz GenuineIntel GNU/Linux
And that's with the usual load, which can be found here:
http://pvp.now.im/s/drraw.cgi?Mode=view;Dashboard=1173713287.13177
The only addition I made was running
ethtool -K ethX gro off
for each network card.
Which means that I have a Broadcom Tygon 3 (tg3) which doesn't
like "generic-receive-offload" at all!
With "generic-receive-offload" off, I will stay on
2.6.36-rc1-FS-00127-g763008c for as long as I can, just to
confirm that in fact the "default on" setting for gro in the
tg3 driver is the culprit for my troubles...
Where to next?
^ permalink raw reply
* Re: [RFC Patch] netxen: remove firmware exports
From: Cong Wang @ 2010-08-20 9:04 UTC (permalink / raw)
To: Amit Salecha
Cc: linux-kernel@vger.kernel.org, David S. Miller, Dhananjay Phadke,
Narender Kumar, netdev@vger.kernel.org
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80F86E69208@MNEXMB2.qlogic.org>
[-- Attachment #1: Type: text/plain, Size: 249 bytes --]
On 08/19/10 17:12, Amit Salecha wrote:
> NX_UNIFIED_ROMIMAGE_NAME(phanfw.bin) is already submitted and we won't submit any other fw files.
Based on above, remove the rest firmware exports.
Thanks!
--
Signed-off-by: WANG Cong <amwang@redhat.com>
[-- Attachment #2: drivers-net-netxen-remove-firmwares.diff --]
[-- Type: text/x-patch, Size: 586 bytes --]
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index fd86e18..2fedc3b 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -41,9 +41,6 @@
MODULE_DESCRIPTION("QLogic/NetXen (1/10) GbE Converged Ethernet Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(NETXEN_NIC_LINUX_VERSIONID);
-MODULE_FIRMWARE(NX_P2_MN_ROMIMAGE_NAME);
-MODULE_FIRMWARE(NX_P3_CT_ROMIMAGE_NAME);
-MODULE_FIRMWARE(NX_P3_MN_ROMIMAGE_NAME);
MODULE_FIRMWARE(NX_UNIFIED_ROMIMAGE_NAME);
char netxen_nic_driver_name[] = "netxen_nic";
^ permalink raw reply related
* RE: [RFC Patch] netxen: remove firmware exports
From: Amit Salecha @ 2010-08-20 8:53 UTC (permalink / raw)
To: Cong Wang
Cc: linux-kernel@vger.kernel.org, David S. Miller, Dhananjay Phadke,
Narender Kumar, netdev@vger.kernel.org
In-Reply-To: <4C6E423E.5080804@redhat.com>
> Okay. David, do you want me to submit an updated patch?
You have to submit updated patch.
-Amit
> -----Original Message-----
> From: Cong Wang [mailto:amwang@redhat.com]
> Sent: Friday, August 20, 2010 2:22 PM
> To: Amit Salecha
> Cc: linux-kernel@vger.kernel.org; David S. Miller; Dhananjay Phadke;
> Narender Kumar; netdev@vger.kernel.org
> Subject: Re: [RFC Patch] netxen: remove firmware exports
>
> On 08/19/10 17:12, Amit Salecha wrote:
> >> netxen_nic driver can store firmwares on flash, and get them
> porperly and
> >> dynamically, so the firmwares may not appear in /lib/firmware/.
> However, netxen_nic
> >> still exports these firmwares via modinfo, this makes our script
> which parses
> >> modinfo output fail.
> >
> > NX_UNIFIED_ROMIMAGE_NAME(phanfw.bin) is already submitted and we
> won't submit any other fw files.
> >
> >> -MODULE_FIRMWARE(NX_P2_MN_ROMIMAGE_NAME);
> >> -MODULE_FIRMWARE(NX_P3_CT_ROMIMAGE_NAME);
> >> -MODULE_FIRMWARE(NX_P3_MN_ROMIMAGE_NAME);
> >
> > It's not compulsory to submit firmware files which are exported
> (MODULE_FIRMWARE).
> > I am leaving this upto David to decide about this patch.
> >
>
> Okay. David, do you want me to submit an updated patch?
>
> Thanks!
>
> --
> The opposite of love is not hate, it's indifference.
> - Elie Wiesel
^ permalink raw reply
* Re: [RFC Patch] netxen: remove firmware exports
From: Cong Wang @ 2010-08-20 8:52 UTC (permalink / raw)
To: Amit Salecha
Cc: linux-kernel@vger.kernel.org, David S. Miller, Dhananjay Phadke,
Narender Kumar, netdev@vger.kernel.org
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80F86E69208@MNEXMB2.qlogic.org>
On 08/19/10 17:12, Amit Salecha wrote:
>> netxen_nic driver can store firmwares on flash, and get them porperly and
>> dynamically, so the firmwares may not appear in /lib/firmware/. However, netxen_nic
>> still exports these firmwares via modinfo, this makes our script which parses
>> modinfo output fail.
>
> NX_UNIFIED_ROMIMAGE_NAME(phanfw.bin) is already submitted and we won't submit any other fw files.
>
>> -MODULE_FIRMWARE(NX_P2_MN_ROMIMAGE_NAME);
>> -MODULE_FIRMWARE(NX_P3_CT_ROMIMAGE_NAME);
>> -MODULE_FIRMWARE(NX_P3_MN_ROMIMAGE_NAME);
>
> It's not compulsory to submit firmware files which are exported (MODULE_FIRMWARE).
> I am leaving this upto David to decide about this patch.
>
Okay. David, do you want me to submit an updated patch?
Thanks!
--
The opposite of love is not hate, it's indifference.
- Elie Wiesel
^ permalink raw reply
* Re: [Patch 1/2] s2io: remove lro parameter
From: Cong Wang @ 2010-08-20 8:54 UTC (permalink / raw)
To: Jon Mason
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
Ramkrishna Vepa, sgruszka@redhat.com, davem@davemloft.net
In-Reply-To: <20100818153626.GC9202@exar.com>
On 08/18/10 23:36, Jon Mason wrote:
> On Wed, Aug 18, 2010 at 12:51:09AM -0700, Amerigo Wang wrote:
>>
>> As suggested by David, this parameter can die, we can use ethtool
>> to turn LRO on/off. Compile tests only.
>
> Needs some additional removal
>
> Line 41 and 42 " * lro: Specifies whether to enable Large Receive ..."
> As you have removed the modparm
>
> Line 8286 "if (sp->lro)"
> As it will always be on in this instance
>
>
> Also, all references to "sp->lro" can be converted to "(dev->features
> & NETIF_F_LRO)", removing an unnecessary variable.
>
Thanks for pointing these out.
I will fix them later.
--
The opposite of love is not hate, it's indifference.
- Elie Wiesel
^ permalink raw reply
* Re: [PATCH v3] net/sched: add ACT_CSUM action to update packets checksums
From: David Miller @ 2010-08-20 8:43 UTC (permalink / raw)
To: baronchon; +Cc: netdev, hadi
In-Reply-To: <20100818231035.GD24125@n7mm.org>
From: Grégoire Baron <baronchon@n7mm.org>
Date: Thu, 19 Aug 2010 01:10:35 +0200
> net/sched: add ACT_CSUM action to update packets checksums
>
> ACT_CSUM can be called just after ACT_PEDIT in order to re-compute some
> altered checksums in IPv4 and IPv6 packets. The following checksums are
> supported by this patch:
> - IPv4: IPv4 header, ICMP, IGMP, TCP, UDP & UDPLite
> - IPv6: ICMPv6, TCP, UDP & UDPLite
> It's possible to request in the same action to update different kind of
> checksums, if the packets flow mix TCP, UDP and UDPLite, ...
>
> An example of usage is done in the associated iproute2 patch.
>
> Version 3 changes:
> - remove useless goto instructions
> - improve IPv6 hop options decoding
>
> Version 2 changes:
> - coding style correction
> - remove useless arguments of some functions
> - use stack in tcf_csum_dump()
> - add tcf_csum_skb_nextlayer() to factor code
>
> Acked-by: jamal <hadi@cyberus.ca>
> Signed-off-by: Gregoire Baron <baronchon@n7mm.org>
Applied, thanks.
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Masayuki Ohtake @ 2010-08-20 8:37 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Wang, Qi, arjan, meego-dev, Wang, Yong Y, gregkh, netdev,
socketcan-core, Khor, Andrew Chih Howe, Morinaga
In-Reply-To: <4C6E35D5.2080500@grandegger.com>
Hi Wolfgang,
Thank you for your comment.
We don't use kfifo infrastructure but brush up with current framework.
Thanks, Ohtake(OKISEMI)
----- Original Message -----
From: "Wolfgang Grandegger" <wg@grandegger.com>
To: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>
Cc: "Wang, Qi" <qi.wang@intel.com>; <arjan@linux.intel.com>; <meego-dev@meego.com>; "Wang, Yong Y"
<yong.y.wang@intel.com>; <gregkh@suse.de>; <netdev@vger.kernel.org>; <socketcan-core@lists.berlios.de>; "Khor, Andrew
Chih Howe" <andrew.chih.howe.khor@intel.com>; "Morinaga" <morinaga526@dsn.okisemi.com>
Sent: Friday, August 20, 2010 4:59 PM
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
> Hi Ohtake,
>
> On 08/20/2010 08:01 AM, Masayuki Ohtake wrote:
> > Hi Wolfgang,
> >
> >>>>>> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
> >>>>> Just take a look at kfifo.h. This structure has been changed. I remembered
> >>>> there was a spin_lock from kfifo previously. Currently it's been removed, good.
> >>>>> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to
> >>>> use this structure and APIs?
> >>>>
> >>>> As I see it, the code related to that fifo is not used (== dead code)?
> >>> I'm not familiar with kfifo structure, and I didn't like it because there need a spin_lock to use it.
> >
> > We are about to study kfifo infra structure.
> > I have a question.
> >
> > It seems all CAN drivers accepted by upstream don't use kfifo infrastructure, right ?
>
> Right!
>
> > (I couldn't see message with "grep kfifo * in drivers/net/can")
> >
> > If yes, why should we use the kfifo ?
> > If no, please show me the kfifo reference driver
>
> Sorry, nobody (of the socketcan core developers) said that kfifo should
> be used. We believe, that an additional queuing of CAN messages is *not*
> needed at all. Just eliminate the related code and follow more closely
> the existing mainline drivers.
>
> Wolfgang.
> --
> 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: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-20 8:31 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <1282286070.2295.6.camel@edumazet-laptop>
На 20.8.2010 г. 10:38, Plamen Petrov написа:
> На 20.8.2010 г. 09:34, Eric Dumazet написа:
>> > Le vendredi 20 août 2010 à 09:26 +0300, Plamen Petrov a écrit :
>>> >> Posting this only in the hope that it will be helpfull to the
>>> >> "net guys"...
>> >
...
>> >
> But again, this is on 2.6.34.4. Could it be that
> "generic-receive-offload" is ON by default on my
> only gigabit capable tg3 card on 2.6.35.x and later?
>
Well, as it turns out - the commit enabling GRO for
tg3 cards was from the 2.6.35 merge window:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cb903bf4ee2d6e53210e2174d363e10698112042
> tg3: Enable GRO by default.author David S. Miller <davem@davemloft.net>
> Wed, 21 Apr 2010 01:49:45 +0000 (18:49 -0700)
> committer David S. Miller <davem@davemloft.net>
> Wed, 21 Apr 2010 01:49:45 +0000 (18:49 -0700)
>
> This was merely an oversight when I added the *_gro_receive()
> calls.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
The next thing I will be trying is disabling
GRO for the tg3 network card in my network
startup scripts via my shiny new ethtool... ;)
^ permalink raw reply
* Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_CAN driver to 2.6.35
From: Wolfgang Grandegger @ 2010-08-20 7:59 UTC (permalink / raw)
To: Masayuki Ohtake
Cc: Khor, Andrew Chih Howe, Wang, Qi, netdev-u79uwXL29TY76Z2rM5mHXA,
gregkh-l3A5Bk7waGM, Wang, Yong Y,
socketcan-core-0fE9KPoRgkgATYTw5x5z8w, Morinaga,
meego-dev-WXzIur8shnEAvxtiuMwx3w, arjan-VuQAYsv1563Yd54FQh9/CA
In-Reply-To: <000f01cb402d$34b675b0$66f8800a-a06+6cuVnkTSQfdrb5gaxUEOCMrvLtNR@public.gmane.org>
Hi Ohtake,
On 08/20/2010 08:01 AM, Masayuki Ohtake wrote:
> Hi Wolfgang,
>
>>>>>> 2. Why don't you use kernel existing kfifo infrastructure? ([2]).
>>>>> Just take a look at kfifo.h. This structure has been changed. I remembered
>>>> there was a spin_lock from kfifo previously. Currently it's been removed, good.
>>>>> OKI-sans, would you please take a look at ./include/linux/kfifo.h, and try to
>>>> use this structure and APIs?
>>>>
>>>> As I see it, the code related to that fifo is not used (== dead code)?
>>> I'm not familiar with kfifo structure, and I didn't like it because there need a spin_lock to use it.
>
> We are about to study kfifo infra structure.
> I have a question.
>
> It seems all CAN drivers accepted by upstream don't use kfifo infrastructure, right ?
Right!
> (I couldn't see message with "grep kfifo * in drivers/net/can")
>
> If yes, why should we use the kfifo ?
> If no, please show me the kfifo reference driver
Sorry, nobody (of the socketcan core developers) said that kfifo should
be used. We believe, that an additional queuing of CAN messages is *not*
needed at all. Just eliminate the related code and follow more closely
the existing mainline drivers.
Wolfgang.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v2] net: build_ehash_secret() and rt_bind_peer() cleanups
From: David Miller @ 2010-08-20 7:51 UTC (permalink / raw)
To: eric.dumazet; +Cc: xiaosuo, netdev, mathieu.desnoyers
In-Reply-To: <1282234245.25476.3.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 19 Aug 2010 18:10:45 +0200
> [PATCH net-next-2.6] net: build_ehash_secret() and rt_bind_peer() cleanups
>
> Now cmpxchg() is available on all arches, we can use it in
> build_ehash_secret() and rt_bind_peer() instead of using spinlocks.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: dccp test-tree [PATCH 0/3] ccid-2: Congestion Window Validation, TCP code sharing
From: David Miller @ 2010-08-20 7:40 UTC (permalink / raw)
To: gerrit; +Cc: dccp, netdev
In-Reply-To: <20100820053843.GD5414@gerrit.erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Fri, 20 Aug 2010 07:38:43 +0200
> If you are ok with this, I would submit a small bunch of 4..5 per week, which
> would allow to keep this going as a background process.
Sounds good to me.
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-20 7:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <1282286070.2295.6.camel@edumazet-laptop>
На 20.8.2010 г. 09:34, Eric Dumazet написа:
> Le vendredi 20 août 2010 à 09:26 +0300, Plamen Petrov a écrit :
>> Posting this only in the hope that it will be helpfull to the
>> "net guys"...
>
> Its a forwarding setup.
>
> Please post
>
> ifconfig -a
> iptables -nvL
> iptables -t nat -nvL
> iptables -t mangle -nvL
> ip route
> ethtool -k eth0 (& eth1 ...)
>
> Try to disable gro ?
> ethtool -K eth0 gro off
> ethtool -K eth1 gro off
>
>
Sorry about this, but when I dig a bit into this, I found that
I had a pretty old ethtool:
> root@fs:~# ethtool --help
> ethtool version 5
> Usage:
> ethtool DEVNAME Display standard information about device
> ...
So my ethtool did not know anything about gro, because by
looking at
http://git.kernel.org/?p=network/ethtool/ethtool.git;a=shortlog
I saw I had this one:
2006-09-01 Jeff Garzik Release version 5. origin v5
and gro reading/setting was added "a bit later"...
2009-03-06 Jeff Garzik Get/set GRO settings.
So, I went on and compiled myself a new ethtool:
> root@fs:~# ethtool -h
> ethtool version 2.6.35
> Usage:
> ethtool DEVNAME Display standard information about device
> ...
And run it on my 2.6.34.4 kernel, which produced these:
>
root@fs:~# ethtool -k eth0
> Offload parameters for eth0:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: off
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: off
> large-receive-offload: off
> ntuple-filters: off
> receive-hashing: off
root@fs:~# ethtool -k eth1
> Offload parameters for eth1:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: on
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: off
> large-receive-offload: off
> ntuple-filters: off
> receive-hashing: off
root@fs:~# ethtool -k eth2
> Offload parameters for eth2:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp-segmentation-offload: off
> udp-fragmentation-offload: off
> generic-segmentation-offload: on
> generic-receive-offload: off
> large-receive-offload: off
> ntuple-filters: off
> receive-hashing: off
root@fs:~#
>
But again, this is on 2.6.34.4. Could it be that
"generic-receive-offload" is ON by default on my
only gigabit capable tg3 card on 2.6.35.x and later?
I will try to determine this myself later, but the
machine is a gateway on the local area network, and
is needed from the user here...
Thanks!
^ permalink raw reply
* Re: [PATCH 2/2] xen: netfront: support the ethtool drvinfo hook.
From: Ian Campbell @ 2010-08-20 7:07 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev@vger.kernel.org, xen-devel@lists.xensource.com,
Jeremy Fitzhardinge, David S. Miller
In-Reply-To: <1282265462.3454.153.camel@localhost>
On Fri, 2010-08-20 at 01:51 +0100, Ben Hutchings wrote:
> On Thu, 2010-08-19 at 10:27 +0100, Ian Campbell wrote:
> > Causes "ethtool -i" to report something useful:
> > # ethtool -i eth0
> > driver: xen-netfront
> > version:
> > firmware-version:
> > bus-info: vif-0
> [...]
>
> This should already be covered by:
>
> commit 01414802054c382072b6cb9a1bdc6e243c74b2d5
Excellent, thanks!
> Author: Ben Hutchings <bhutchings@solarflare.com>
> Date: Tue Aug 17 02:31:15 2010 -0700
>
> ethtool: Provide a default implementation of ethtool_ops::get_drvinfo
>
> Ben.
>
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-20 6:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <1282286070.2295.6.camel@edumazet-laptop>
На 20.8.2010 г. 09:34, Eric Dumazet написа:
> Le vendredi 20 août 2010 à 09:26 +0300, Plamen Petrov a écrit :
>> Posting this only in the hope that it will be helpfull to the
>> "net guys"...
>
> Its a forwarding setup.
>
> Please post
>
> ifconfig -a
> iptables -nvL
> iptables -t nat -nvL
> iptables -t mangle -nvL
> ip route
> ethtool -k eth0 (& eth1 ...)
>
> Try to disable gro ?
> ethtool -K eth0 gro off
> ethtool -K eth1 gro off
>
>
Here goes the output of the above:
root@fs:~# ifconfig -a
> eth0 Link encap:Ethernet HWaddr 00:0E:2E:5C:27:EF
> inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
> inet6 addr: fe80::20e:2eff:fe5c:27ef/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:40986 errors:0 dropped:0 overruns:0 frame:0
> TX packets:32825 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:36081064 (34.4 MiB) TX bytes:6457150 (6.1 MiB)
> Interrupt:18 Base address:0xe00
>
> eth1 Link encap:Ethernet HWaddr 00:1A:A0:38:8A:1B
> inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0
> inet6 addr: fe80::21a:a0ff:fe38:8a1b/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:1220443 errors:0 dropped:0 overruns:0 frame:0
> TX packets:568452 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:1477959893 (1.3 GiB) TX bytes:144840881 (138.1 MiB)
> Interrupt:17
>
> eth2 Link encap:Ethernet HWaddr 00:0E:2E:5C:27:E6
> inet addr:192.168.199.1 Bcast:192.168.199.255 Mask:255.255.255.0
> inet6 addr: fe80::20e:2eff:fe5c:27e6/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:1119 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1149 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:210401 (205.4 KiB) TX bytes:505063 (493.2 KiB)
> Interrupt:16 Base address:0x4f00
>
> gre0 Link encap:UNSPEC HWaddr 00-00-00-00-FF-00-73-69-00-00-00-00-00-00-00-00
> NOARP MTU:1476 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> ifb0 Link encap:Ethernet HWaddr 96:9F:C4:43:78:01
> BROADCAST NOARP MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:32
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> ifb1 Link encap:Ethernet HWaddr EA:B9:BD:02:C1:77
> BROADCAST NOARP MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:32
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> ip6tnl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> NOARP MTU:1460 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:13546 errors:0 dropped:0 overruns:0 frame:0
> TX packets:13546 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:1051287 (1.0 MiB) TX bytes:1051287 (1.0 MiB)
>
> sit0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-73-69-00-00-00-00-00-00-00-00
> NOARP MTU:1480 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> sixxs_t Link encap:UNSPEC HWaddr C0-A8-01-02-00-00-73-69-00-00-00-00-00-00-00-00
> inet6 addr: 2001:15c0:65ff:64::2/64 Scope:Global
> inet6 addr: fe80::c0a8:102/128 Scope:Link
> UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1
> RX packets:145 errors:0 dropped:0 overruns:0 frame:0
> TX packets:145 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:15080 (14.7 KiB) TX bytes:15080 (14.7 KiB)
>
> teql0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> NOARP MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> inet addr:192.168.11.1 P-t-P:192.168.11.2 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
> tunl0 Link encap:IPIP Tunnel HWaddr
> NOARP MTU:1480 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
>
root@fs:~# iptables -nvL
> Chain INPUT (policy ACCEPT 1207K packets, 1455M bytes)
> pkts bytes target prot opt in out source destination
> 0 0 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
> 0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
> 0 0 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:135
> 0 0 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:137
> 0 0 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:138
> 0 0 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
> 0 0 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
> 0 0 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
> 0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:135
> 0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
> 0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
> 0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:139
> 0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:445
> 0 0 DROP udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:993
>
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source destination
> 0 0 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
> 0 0 ACCEPT all -- * tun0 0.0.0.0/0 0.0.0.0/0
> 0 0 ACCEPT all -- eth2 eth1 192.168.199.15 192.168.10.0/24
> 0 0 REJECT all -- eth2 * 0.0.0.0/0 192.168.1.1 reject-with icmp-net-unreachable
> 0 0 REJECT all -- eth1 * 0.0.0.0/0 192.168.1.1 reject-with icmp-net-unreachable
> 29650 5450K ACCEPT all -- eth1 eth0 192.168.10.0/24 !192.168.1.1
> 821 165K ACCEPT all -- eth2 eth0 192.168.199.0/24 !192.168.1.1
> 0 0 ACCEPT all -- eth2 eth1 192.168.199.0/24 192.168.10.5
> 624 438K ACCEPT tcp -- * eth2 0.0.0.0/0 192.168.199.0/24 tcp flags:!0x17/0x02
> 33228 34M ACCEPT tcp -- * eth1 0.0.0.0/0 192.168.10.0/24 tcp flags:!0x17/0x02
> 199 14395 ACCEPT !tcp -- * eth2 0.0.0.0/0 192.168.199.0/24
> 2891 597K ACCEPT !tcp -- * eth1 0.0.0.0/0 192.168.10.0/24
>
> Chain OUTPUT (policy ACCEPT 546K packets, 100M bytes)
> pkts bytes target prot opt in out source destination
root@fs:~# iptables -t nat -nvL
> Chain PREROUTING (policy DROP 701 packets, 94310 bytes)
> pkts bytes target prot opt in out source destination
> 0 0 LOG tcp -- eth1 * 192.168.10.0/24 !192.168.10.1 tcp dpt:25 LOG flags 0 level 4
> 0 0 DROP tcp -- eth1 * 192.168.10.0/24 !192.168.10.1 tcp dpt:25
> 0 0 LOG tcp -- eth2 * 192.168.199.0/24 !192.168.199.1 tcp dpt:25 LOG flags 0 level 4
> 0 0 DROP tcp -- eth2 * 192.168.199.0/24 !192.168.199.1 tcp dpt:25
> 0 0 LOG tcp -- tun0 * 192.168.11.0/24 !192.168.11.1 tcp dpt:25 LOG flags 0 level 4
> 0 0 DROP tcp -- tun0 * 192.168.11.0/24 !192.168.11.1 tcp dpt:25
> 0 0 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
> 0 0 ACCEPT all -- * * 0.0.0.0/0 192.168.11.0/24
> 0 0 ACCEPT all -- * * 192.168.11.0/24 0.0.0.0/0
> 0 0 DROP tcp -- * * 87.249.45.135 0.0.0.0/0 tcp dpts:20:22
> 0 0 ACCEPT all -- eth0 * 212.18.63.73 192.168.1.2
> 0 0 ACCEPT all -- eth2 * 192.168.199.15 192.168.10.0/24
> 0 0 DROP all -- eth2 * 192.168.199.0/24 192.168.10.0/24
> 0 0 DROP all -- eth1 * 192.168.10.0/24 192.168.199.0/24
> 5629 597K ACCEPT all -- eth1 * 192.168.10.0/24 0.0.0.0/0
> 262 26231 ACCEPT all -- eth2 * 192.168.199.0/24 0.0.0.0/0
> 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:21 state NEW,ESTABLISHED
> 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp spts:1024:65535 dpts:1024:65535 state RELATED,ESTABLISHED
> 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpts:20:21 flags:0x17/0x02
> 0 0 ACCEPT tcp -- * * 77.0.0.0/8 192.168.1.2 tcp dpt:22 flags:0x17/0x02
> 0 0 ACCEPT tcp -- * * 87.0.0.0/8 192.168.1.2 tcp dpt:22 flags:0x17/0x02
> 0 0 ACCEPT tcp -- * * 90.0.0.0/8 192.168.1.2 tcp dpt:22 flags:0x17/0x02
> 0 0 ACCEPT tcp -- * * 95.0.0.0/8 192.168.1.2 tcp dpt:22 flags:0x17/0x02
> 0 0 ACCEPT tcp -- * * 212.45.77.11 192.168.1.2 tcp dpt:22 flags:0x17/0x02
> 0 0 LOG tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:22 flags:0x17/0x02 LOG flags 0 level 4
> 0 0 DROP tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:22 flags:0x17/0x02
> 11 628 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:25 flags:0x17/0x02
> 2 96 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:80 flags:0x17/0x02
> 2 100 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:443 flags:0x17/0x02
> 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.1.2 tcp dpt:41414 flags:0x17/0x02
> 1197 58544 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02
> 0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 192.168.1.2 tcp dpts:1023:65500
> 6 2006 ACCEPT udp -- eth1 * 0.0.0.0 255.255.255.255 udp spts:67:68 dpts:67:68
> 1 328 ACCEPT udp -- eth2 * 0.0.0.0 255.255.255.255 udp spts:67:68 dpts:67:68
>
> Chain OUTPUT (policy ACCEPT 2685 packets, 196K bytes)
> pkts bytes target prot opt in out source destination
>
> Chain POSTROUTING (policy ACCEPT 2656 packets, 186K bytes)
> pkts bytes target prot opt in out source destination
> 1 124 ACCEPT all -- * eth0 192.168.1.2 212.18.63.73
> 0 0 ACCEPT tcp -- * eth0 192.168.1.2 0.0.0.0/0 tcp spts:1024:65535 dpts:1024:65535 state RELATED,ESTABLISHED
> 0 0 ACCEPT tcp -- * eth0 192.168.1.2 0.0.0.0/0 tcp spt:20 state RELATED,ESTABLISHED
> 0 0 SNAT all -- * eth0 192.168.10.16/29 0.0.0.0/0 to:192.168.1.2
> 4 192 SNAT all -- * eth0 192.168.10.24/29 0.0.0.0/0 to:192.168.1.2
> 0 0 SNAT all -- * eth0 192.168.10.32/29 0.0.0.0/0 to:192.168.1.2
> 0 0 SNAT all -- * eth0 192.168.10.40/29 0.0.0.0/0 to:192.168.1.2
> 0 0 SNAT all -- * eth0 192.168.10.48/29 0.0.0.0/0 to:192.168.1.2
> 0 0 SNAT all -- * eth0 192.168.10.56/29 0.0.0.0/0 to:192.168.1.2
> 0 0 SNAT all -- * eth0 192.168.10.64/28 0.0.0.0/0 to:192.168.1.2
> 4893 516K SNAT all -- * eth0 192.168.10.0/24 0.0.0.0/0 to:192.168.1.2
> 211 16721 SNAT all -- * eth0 192.168.199.0/24 0.0.0.0/0 to:192.168.1.2
> 24 8328 ACCEPT udp -- * eth1 192.168.10.1 255.255.255.255 udp spts:67:68 dpts:67:68
> 4 1388 ACCEPT udp -- * eth2 192.168.199.1 255.255.255.255 udp spts:67:68 dpts:67:68
> 0 0 DROP all -- * * 0.0.0.0 0.0.0.0/0
root@fs:~# iptables -t mangle -nvL
> Chain PREROUTING (policy ACCEPT 1287K packets, 1508M bytes)
> pkts bytes target prot opt in out source destination
>
> Chain INPUT (policy ACCEPT 1212K packets, 1461M bytes)
> pkts bytes target prot opt in out source destination
>
> Chain FORWARD (policy ACCEPT 73581 packets, 47M bytes)
> pkts bytes target prot opt in out source destination
>
> Chain OUTPUT (policy ACCEPT 548K packets, 100M bytes)
> pkts bytes target prot opt in out source destination
>
> Chain POSTROUTING (policy ACCEPT 622K packets, 147M bytes)
> pkts bytes target prot opt in out source destination
root@fs:~# ip route
> 192.168.11.2 dev tun0 proto kernel scope link src 192.168.11.1
> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
> 192.168.199.0/24 dev eth2 proto kernel scope link src 192.168.199.1
> 192.168.11.0/24 via 192.168.11.2 dev tun0
> 192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.1
> 127.0.0.0/8 dev lo scope link
> default via 192.168.1.1 dev eth0 metric 1
root@fs:~# ethtool -k eth0
> Offload parameters for eth0:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp segmentation offload: off
> udp fragmentation offload: off
> generic segmentation offload: on
root@fs:~# ethtool -k eth1
> Offload parameters for eth1:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp segmentation offload: on
> udp fragmentation offload: off
> generic segmentation offload: on
root@fs:~# ethtool -k eth2
> Offload parameters for eth2:
> rx-checksumming: on
> tx-checksumming: on
> scatter-gather: on
> tcp segmentation offload: off
> udp fragmentation offload: off
> generic segmentation offload: on
root@fs:~# uname -a
> Linux fs 2.6.34.4-FS #1 SMP Thu Aug 19 18:09:58 UTC 2010 i686 Intel(R) Pentium(R) D CPU 3.00GHz GenuineIntel GNU/Linux
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Eric Dumazet @ 2010-08-20 6:34 UTC (permalink / raw)
To: Plamen Petrov; +Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4C6E202E.5030406@fs.uni-ruse.bg>
Le vendredi 20 août 2010 à 09:26 +0300, Plamen Petrov a écrit :
> Posting this only in the hope that it will be helpfull to the
> "net guys"...
Its a forwarding setup.
Please post
ifconfig -a
iptables -nvL
iptables -t nat -nvL
iptables -t mangle -nvL
ip route
ethtool -k eth0 (& eth1 ...)
Try to disable gro ?
ethtool -K eth0 gro off
ethtool -K eth1 gro off
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-20 6:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <20100819232019.6f6074a8.akpm@linux-foundation.org>
Posting this only in the hope that it will be helpfull to the
"net guys"...
root@fs:~# uname -a; lspci -vvv; ethtool -i eth1
> Linux fs 2.6.34.4-FS #1 SMP Thu Aug 19 18:09:58 UTC 2010 i686 Intel(R) Pentium(R) D CPU 3.00GHz GenuineIntel GNU/Linux
> 00:00.0 Host bridge: Intel Corporation E7230/3000/3010 Memory Controller Hub
> Subsystem: Dell Unknown device 01df
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
> Latency: 0
> Capabilities: [e0] Vendor Specific Information
>
> 00:01.0 PCI bridge: Intel Corporation E7230/3000/3010 PCI Express Root Port (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 0000f000-00000fff
> Memory behind bridge: efe00000-efefffff
> Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
> Capabilities: [88] Subsystem: Intel Corporation Unknown device 0000
> Capabilities: [80] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
> Address: fee0300c Data: 4149
> Capabilities: [a0] Express Root Port (Slot+) IRQ 0
> Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
> Device: Latency L0s <64ns, L1 <1us
> Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
> Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
> Link: Supported Speed 2.5Gb/s, Width x8, ASPM L0s, Port 2
> Link: Latency L0s <256ns, L1 <4us
> Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
> Link: Speed 2.5Gb/s, Width x0
> Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise-
> Slot: Number 1, PowerLimit 25.000000
> Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
> Slot: AttnInd Off, PwrInd On, Power-
> Root: Correctable- Non-Fatal- Fatal- PME-
> Capabilities: [100] Virtual Channel
> Capabilities: [140] Unknown (5)
>
> 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
> I/O behind bridge: 00001000-00001fff
> Memory behind bridge: efd00000-efdfffff
> Prefetchable memory behind bridge: 0000000020000000-00000000201fffff
> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
> Capabilities: [40] Express Root Port (Slot+) IRQ 0
> Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
> Device: Latency L0s unlimited, L1 unlimited
> Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
> Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
> Link: Supported Speed 2.5Gb/s, Width x4, ASPM L0s, Port 1
> Link: Latency L0s <256ns, L1 <4us
> Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
> Link: Speed 2.5Gb/s, Width x0
> Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
> Slot: Number 4, PowerLimit 10.000000
> Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
> Slot: AttnInd Unknown, PwrInd Unknown, Power-
> Root: Correctable- Non-Fatal- Fatal- PME-
> Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
> Address: fee0300c Data: 4151
> Capabilities: [90] Subsystem: Gammagraphx, Inc. Unknown device 0000
> Capabilities: [a0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [100] Virtual Channel
> Capabilities: [180] Unknown (5)
>
> 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
> I/O behind bridge: 00002000-00002fff
> Memory behind bridge: 20200000-203fffff
> Prefetchable memory behind bridge: 0000000020400000-00000000205fffff
> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
> Capabilities: [40] Express Root Port (Slot+) IRQ 0
> Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
> Device: Latency L0s unlimited, L1 unlimited
> Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
> Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
> Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 5
> Link: Latency L0s <256ns, L1 <4us
> Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
> Link: Speed 2.5Gb/s, Width x0
> Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
> Slot: Number 1, PowerLimit 10.000000
> Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
> Slot: AttnInd Unknown, PwrInd Unknown, Power-
> Root: Correctable- Non-Fatal- Fatal- PME-
> Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
> Address: fee0300c Data: 4159
> Capabilities: [90] Subsystem: Gammagraphx, Inc. Unknown device 0000
> Capabilities: [a0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [100] Virtual Channel
> Capabilities: [180] Unknown (5)
>
> 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) (prog-if 00 [Normal decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0, Cache Line Size: 64 bytes
> Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
> I/O behind bridge: 00003000-00003fff
> Memory behind bridge: efc00000-efcfffff
> Prefetchable memory behind bridge: 0000000020600000-00000000207fffff
> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
> Capabilities: [40] Express Root Port (Slot+) IRQ 0
> Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
> Device: Latency L0s unlimited, L1 unlimited
> Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
> Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
> Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
> Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 6
> Link: Latency L0s <256ns, L1 <4us
> Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
> Link: Speed 2.5Gb/s, Width x1
> Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+
> Slot: Number 0, PowerLimit 10.000000
> Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
> Slot: AttnInd Unknown, PwrInd Unknown, Power-
> Root: Correctable- Non-Fatal- Fatal- PME-
> Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable+
> Address: fee0300c Data: 4161
> Capabilities: [90] Subsystem: Gammagraphx, Inc. Unknown device 0000
> Capabilities: [a0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [100] Virtual Channel
> Capabilities: [180] Unknown (5)
>
> 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI])
> Subsystem: Dell Unknown device 01df
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Interrupt: pin A routed to IRQ 21
> Region 4: I/O ports at ff80 [size=32]
>
> 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI])
> Subsystem: Dell Unknown device 01df
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Interrupt: pin B routed to IRQ 22
> Region 4: I/O ports at ff60 [size=32]
>
> 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI])
> Subsystem: Dell Unknown device 01df
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Interrupt: pin C routed to IRQ 18
> Region 4: I/O ports at ff40 [size=32]
>
> 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI])
> Subsystem: Dell Unknown device 01df
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Interrupt: pin A routed to IRQ 21
> Region 0: Memory at ff980800 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [58] Debug port
>
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) (prog-if 01 [Subtractive decode])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Bus: primary=00, secondary=05, subordinate=05, sec-latency=32
> I/O behind bridge: 0000d000-0000dfff
> Memory behind bridge: efa00000-efbfffff
> Prefetchable memory behind bridge: 00000000e0000000-00000000e7ffffff
> Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
> BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
> Capabilities: [50] Subsystem: Gammagraphx, Inc. Unknown device 0000
>
> 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Capabilities: [e0] Vendor Specific Information
>
> 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) (prog-if 8a [Master SecP PriP])
> Subsystem: Dell Unknown device 01df
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Interrupt: pin A routed to IRQ 16
> Region 0: I/O ports at 01f0 [size=8]
> Region 1: I/O ports at 03f4 [size=1]
> Region 2: I/O ports at 0170 [size=8]
> Region 3: I/O ports at 0374 [size=1]
> Region 4: I/O ports at ffa0 [size=16]
>
> 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01) (prog-if 8f [Master SecP SecO PriP PriO])
> Subsystem: Dell Unknown device 01df
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Interrupt: pin C routed to IRQ 20
> Region 0: I/O ports at fe00 [size=8]
> Region 1: I/O ports at fe10 [size=4]
> Region 2: I/O ports at fe20 [size=8]
> Region 3: I/O ports at fe30 [size=4]
> Region 4: I/O ports at fec0 [size=16]
> Region 5: Memory at effffc00 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [70] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
> Subsystem: Dell Unknown device 01df
> Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Interrupt: pin B routed to IRQ 17
> Region 4: I/O ports at ece0 [size=32]
>
> 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02)
> Subsystem: Dell Unknown device 01df
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 28
> Region 0: Memory at efcf0000 (64-bit, non-prefetchable) [size=64K]
> Expansion ROM at <ignored> [disabled]
> Capabilities: [48] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=1 PME-
> Capabilities: [50] Vital Product Data
> Capabilities: [58] Vendor Specific Information
> Capabilities: [e8] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
> Address: 00000000fee0300c Data: 4189
> Capabilities: [d0] Express Endpoint IRQ 0
> Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
> Device: Latency L0s <4us, L1 unlimited
> Device: AtnBtn- AtnInd- PwrInd-
> Device: Errors: Correctable- Non-Fatal+ Fatal+ Unsupported-
> Device: RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop-
> Device: MaxPayload 128 bytes, MaxReadReq 4096 bytes
> Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0
> Link: Latency L0s <4us, L1 <64us
> Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
> Link: Speed 2.5Gb/s, Width x1
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [13c] Virtual Channel
> Capabilities: [160] Device Serial Number 1b-8a-38-fe-ff-a0-1a-00
> Capabilities: [16c] Power Budgeting
>
> 05:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
> Subsystem: Realtek Semiconductor Co., Ltd. RT8139
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 64 (8000ns min, 16000ns max)
> Interrupt: pin A routed to IRQ 18
> Region 0: I/O ports at d400 [size=256]
> Region 1: Memory at efaefe00 (32-bit, non-prefetchable) [size=256]
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 05:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
> Subsystem: Realtek Semiconductor Co., Ltd. RT8139
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Latency: 64 (8000ns min, 16000ns max)
> Interrupt: pin A routed to IRQ 16
> Region 0: I/O ports at d800 [size=256]
> Region 1: Memory at efaeff00 (32-bit, non-prefetchable) [size=256]
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> 05:07.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) (prog-if 00 [VGA])
> Subsystem: Dell Unknown device 01df
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
> Interrupt: pin A routed to IRQ 5
> Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]
> Region 1: I/O ports at dc00 [size=256]
> Region 2: Memory at efaf0000 (32-bit, non-prefetchable) [size=64K]
> Expansion ROM at efb00000 [disabled] [size=128K]
> Capabilities: [50] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> driver: tg3
> version: 3.108
> firmware-version: 5754-v3.12
> bus-info: 0000:04:00.0
> root@fs:~#
^ permalink raw reply
* Re: [PATCH v7] PPTP: PPP over IPv4 (Point-to-Point Tunneling Protocol)
From: Eric Dumazet @ 2010-08-20 6:24 UTC (permalink / raw)
To: Dmitry Kozlov; +Cc: netdev
In-Reply-To: <E1Om1Q6-0005Fm-00.xeb-mail-ru@f239.mail.ru>
Le jeudi 19 août 2010 à 13:28 +0400, Dmitry Kozlov a écrit :
> Ang again...
> This patch contains:
> 1. pptp driver
> 2. gre demultiplexer driver for demultiplexing gre packets with different gre version
> so ip_gre and pptp may coexists
> 3. ip_gre modification
> 4. other stuff
>
> Changes from v6:
> 1. memory allocation moved to begin of module initialization
> 2. fixed coding style issues
> Thanks to Eric Dumazet.
>
> --
> MAINTAINERS | 14 +
> drivers/net/Kconfig | 11 +
> drivers/net/Makefile | 1 +
> drivers/net/pptp.c | 726 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/if_pppox.h | 59 +++--
> include/net/gre.h | 18 ++
> net/ipv4/Kconfig | 7 +
> net/ipv4/Makefile | 1 +
> net/ipv4/gre.c | 151 ++++++++++
> net/ipv4/ip_gre.c | 14 +-
> 10 files changed, 975 insertions(+), 27 deletions(-)
Seems fine to me, but you need to make a nice looking Changelog and add
your "Signed-off-by: ...." signature.
Thanks
^ 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