* Re: [RFC] [PATCH 0/3] ioat: DMA engine support
From: Andi Kleen @ 2005-11-24 15:37 UTC (permalink / raw)
To: Avi Kivity
Cc: Andi Kleen, Benjamin LaHaise, Jeff Garzik, Andrew Grover, netdev,
linux-kernel, john.ronciak, christopher.leech
In-Reply-To: <4385DDBE.3040208@argo.co.il>
> >Just pointing out that it's not clear it will always be a big help.
> >
> >
> >
> Agree it should default to in-cache.
This would mean no DMA engine by default.
Clearly there needs to be some heuristic to decide by default. We'll see how
effective it will be in the end.
-Andi
^ permalink raw reply
* [PATCH] ibm_emac: fix graceful stop timeout handling
From: Eugene Surovegin @ 2005-11-24 22:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
This patch fixes graceful stop timeout handling in PPC4xx EMAC driver.
Currently, when we stop TX/RX channels we just do some number of loops
without relying on actual spent time. This has finally bitten me on
one of our systems (heavy network traffic during start up, RX channel
is stopped several times to configure multicast list).
Graceful channel stop can take up to 1 frame time, so I've added
device specific timeout counter which depends on current link speed
and calls to udelay() to really wait required amount of time before
giving up.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
---
drivers/net/ibm_emac/ibm_emac_core.c | 38 ++++++++++++++++++++++++++--------
drivers/net/ibm_emac/ibm_emac_core.h | 2 ++
2 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index eb7d694..1da8a66 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -65,7 +65,7 @@
*/
#define DRV_NAME "emac"
-#define DRV_VERSION "3.53"
+#define DRV_VERSION "3.54"
#define DRV_DESC "PPC 4xx OCP EMAC driver"
MODULE_DESCRIPTION(DRV_DESC);
@@ -158,6 +158,14 @@ static inline void emac_report_timeout_e
#define PHY_POLL_LINK_ON HZ
#define PHY_POLL_LINK_OFF (HZ / 5)
+/* Graceful stop timeouts in us.
+ * We should allow up to 1 frame time (full-duplex, ignoring collisions)
+ */
+#define STOP_TIMEOUT_10 1230
+#define STOP_TIMEOUT_100 124
+#define STOP_TIMEOUT_1000 13
+#define STOP_TIMEOUT_1000_JUMBO 73
+
/* Please, keep in sync with struct ibm_emac_stats/ibm_emac_error_stats */
static const char emac_stats_keys[EMAC_ETHTOOL_STATS_COUNT][ETH_GSTRING_LEN] = {
"rx_packets", "rx_bytes", "tx_packets", "tx_bytes", "rx_packets_csum",
@@ -222,10 +230,12 @@ static void emac_tx_disable(struct ocp_e
r = in_be32(&p->mr0);
if (r & EMAC_MR0_TXE) {
- int n = 300;
+ int n = dev->stop_timeout;
out_be32(&p->mr0, r & ~EMAC_MR0_TXE);
- while (!(in_be32(&p->mr0) & EMAC_MR0_TXI) && n)
+ while (!(in_be32(&p->mr0) & EMAC_MR0_TXI) && n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev, "TX disable timeout");
}
@@ -248,9 +258,11 @@ static void emac_rx_enable(struct ocp_en
if (!(r & EMAC_MR0_RXE)) {
if (unlikely(!(r & EMAC_MR0_RXI))) {
/* Wait if previous async disable is still in progress */
- int n = 100;
- while (!(r = in_be32(&p->mr0) & EMAC_MR0_RXI) && n)
+ int n = dev->stop_timeout;
+ while (!(r = in_be32(&p->mr0) & EMAC_MR0_RXI) && n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev,
"RX disable timeout");
@@ -273,10 +285,12 @@ static void emac_rx_disable(struct ocp_e
r = in_be32(&p->mr0);
if (r & EMAC_MR0_RXE) {
- int n = 300;
+ int n = dev->stop_timeout;
out_be32(&p->mr0, r & ~EMAC_MR0_RXE);
- while (!(in_be32(&p->mr0) & EMAC_MR0_RXI) && n)
+ while (!(in_be32(&p->mr0) & EMAC_MR0_RXI) && n) {
+ udelay(1);
--n;
+ }
if (unlikely(!n))
emac_report_timeout_error(dev, "RX disable timeout");
}
@@ -395,6 +409,7 @@ static int emac_configure(struct ocp_ene
r = EMAC_MR1_BASE(emac_opb_mhz()) | EMAC_MR1_VLE | EMAC_MR1_IST;
if (dev->phy.duplex == DUPLEX_FULL)
r |= EMAC_MR1_FDE;
+ dev->stop_timeout = STOP_TIMEOUT_10;
switch (dev->phy.speed) {
case SPEED_1000:
if (emac_phy_gpcs(dev->phy.mode)) {
@@ -409,12 +424,16 @@ static int emac_configure(struct ocp_ene
r |= EMAC_MR1_MF_1000;
r |= EMAC_MR1_RFS_16K;
gige = 1;
-
- if (dev->ndev->mtu > ETH_DATA_LEN)
+
+ if (dev->ndev->mtu > ETH_DATA_LEN) {
r |= EMAC_MR1_JPSM;
+ dev->stop_timeout = STOP_TIMEOUT_1000_JUMBO;
+ } else
+ dev->stop_timeout = STOP_TIMEOUT_1000;
break;
case SPEED_100:
r |= EMAC_MR1_MF_100;
+ dev->stop_timeout = STOP_TIMEOUT_100;
/* Fall through */
default:
r |= EMAC_MR1_RFS_4K;
@@ -2048,6 +2067,7 @@ static int __init emac_probe(struct ocp_
dev->phy.duplex = DUPLEX_FULL;
dev->phy.autoneg = AUTONEG_DISABLE;
dev->phy.pause = dev->phy.asym_pause = 0;
+ dev->stop_timeout = STOP_TIMEOUT_100;
init_timer(&dev->link_timer);
dev->link_timer.function = emac_link_timer;
dev->link_timer.data = (unsigned long)dev;
diff --git a/drivers/net/ibm_emac/ibm_emac_core.h b/drivers/net/ibm_emac/ibm_emac_core.h
index e9b44d0..911abba 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.h
+++ b/drivers/net/ibm_emac/ibm_emac_core.h
@@ -189,6 +189,8 @@ struct ocp_enet_private {
struct timer_list link_timer;
int reset_failed;
+ int stop_timeout; /* in us */
+
struct ibm_emac_error_stats estats;
struct net_device_stats nstats;
^ permalink raw reply related
* ipw2200 in 2.6.15-rc2-git4 warns about improper NETDEV_TX_BUSY retcode
From: Alessandro Suardi @ 2005-11-24 23:38 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: netdev
Dell Latitude D610, FC4 base distro, kernel is:
[asuardi@sandman ~]$ cat /proc/version
Linux version 2.6.15-rc2-git4 (asuardi@sandman) (gcc version 4.0.1
20050727 (Red Hat 4.0.1-5)) #2 Fri Nov 25 00:15:46 CET 2005
Onboard wireless card as detected by kernel is:
ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
and I placed the 2.4 firmware from sourceforge.net in /lib/firmware.
ifup eth1 yields this message:
eth1: NETDEV_TX_BUSY returned; driver should report queue full via
ieee_device->is_queue_full.
I'm connected to my wireless DSL router while typing this mail
so it obviously isn't fatal...
Thanks,
--alessandro
"So much can happen by accident
No rhyme, no reason - no one's innocent"
(Steve Wynn - "Under The Weather")
^ permalink raw reply
* Re: ipw2200 in 2.6.15-rc2-git4 warns about improper NETDEV_TX_BUSY retcode
From: Zhu Yi @ 2005-11-25 3:23 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <5a4c581d0511241538s496adee9s249cd038501545c9@mail.gmail.com>
On Fri, 2005-11-25 at 00:38 +0100, Alessandro Suardi wrote:
> Dell Latitude D610, FC4 base distro, kernel is:
>
> [asuardi@sandman ~]$ cat /proc/version
> Linux version 2.6.15-rc2-git4 (asuardi@sandman) (gcc version 4.0.1
> 20050727 (Red Hat 4.0.1-5)) #2 Fri Nov 25 00:15:46 CET 2005
>
> Onboard wireless card as detected by kernel is:
> ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
>
> and I placed the 2.4 firmware from sourceforge.net in /lib/firmware.
>
> ifup eth1 yields this message:
>
> eth1: NETDEV_TX_BUSY returned; driver should report queue full via
> ieee_device->is_queue_full.
Please use the patch here. It will be push to upstream very soon.
http://bughost.org/bugzilla/show_bug.cgi?id=808
Thanks,
-yi
^ permalink raw reply
* Re: ipw2200 in 2.6.15-rc2-git4 warns about improper NETDEV_TX_BUSY retcode
From: Alessandro Suardi @ 2005-11-25 10:59 UTC (permalink / raw)
To: Zhu Yi; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <1132889013.24413.5.camel@debian.sh.intel.com>
On 11/25/05, Zhu Yi <yi.zhu@intel.com> wrote:
> On Fri, 2005-11-25 at 00:38 +0100, Alessandro Suardi wrote:
> > Dell Latitude D610, FC4 base distro, kernel is:
> >
> > [asuardi@sandman ~]$ cat /proc/version
> > Linux version 2.6.15-rc2-git4 (asuardi@sandman) (gcc version 4.0.1
> > 20050727 (Red Hat 4.0.1-5)) #2 Fri Nov 25 00:15:46 CET 2005
> >
> > Onboard wireless card as detected by kernel is:
> > ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
> >
> > and I placed the 2.4 firmware from sourceforge.net in /lib/firmware.
> >
> > ifup eth1 yields this message:
> >
> > eth1: NETDEV_TX_BUSY returned; driver should report queue full via
> > ieee_device->is_queue_full.
>
> Please use the patch here. It will be push to upstream very soon.
> http://bughost.org/bugzilla/show_bug.cgi?id=808
The offsets of the patch are off by several hundred lines,
however the patch itself works fine. Thanks !
--alessandro
"So much can happen by accident
No rhyme, no reason - no one's innocent"
(Steve Wynn - "Under The Weather")
^ permalink raw reply
* [PATCH] netfilter : zap get_cpu()/put_cpu() calls from ip_tables
From: Eric Dumazet @ 2005-11-25 11:23 UTC (permalink / raw)
To: David S. Miller, Harald Welte, kaber
Cc: Andrew Morton, netdev, netfilter-devel
In-Reply-To: <4331CFA7.50104@cosmosbay.com>
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
The 'ip_tables: NUMA-aware allocation' patch
(http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.16.git;a=commit;h=6d1273850cac8db77c462caaa145b813d93adc55)
introduced a problem with get_cpu()/put_cpu()
The problem is that get_cpu() disables preemption and the thread is not
allowed to sleep.
As the intent was only to give a hint, relax the enforcement and switch to a
hint : If the current thread is preempted and migrated to another cpu, this is
not a problem. Most of the time, thread wont be migrated anyway.
This patch removes get_cpu()/put_cpu() pairs and uses raw_smp_processor_id()
were appropriate.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: zap_getput_cpu.patch --]
[-- Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH (resent with the attachment !)] netfilter : zap get_cpu()/put_cpu() calls from ip_tables
From: Eric Dumazet @ 2005-11-25 11:28 UTC (permalink / raw)
To: David S. Miller, Harald Welte, kaber, Andrew Morton
Cc: netdev, netfilter-devel
In-Reply-To: <4386F440.5020505@cosmosbay.com>
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
The 'ip_tables: NUMA-aware allocation' patch
(http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.16.git;a=commit;h=6d1273850cac8db77c462caaa145b813d93adc55)
introduced a problem with get_cpu()/put_cpu()
The problem is that get_cpu() disables preemption and the thread is not
allowed to sleep.
As the intent was only to give a hint, relax the enforcement and switch to a
hint : If the current thread is preempted and migrated to another cpu, this is
not a problem. Most of the time, thread wont be migrated anyway.
This patch removes get_cpu()/put_cpu() pairs and uses raw_smp_processor_id()
were appropriate.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: zap_getput_cpu.patch --]
[-- Type: text/plain, Size: 9865 bytes --]
--- net-2.6.16-orig/net/ipv4/netfilter/ip_tables.c 2005-11-25 10:24:02.000000000 +0100
+++ net-2.6.16/net/ipv4/netfilter/ip_tables.c 2005-11-25 11:44:40.000000000 +0100
@@ -988,11 +988,14 @@
{
unsigned int cpu;
unsigned int i;
- unsigned int curcpu = get_cpu();
+ unsigned int curcpu;
/* Instead of clearing (by a previous call to memset())
* the counters and using adds, we set the counters
- * with data used by current CPU */
+ * with data used by 'current' CPU
+ * We dont care about preemption here.
+ */
+ curcpu = raw_smp_processor_id();
i = 0;
IPT_ENTRY_ITERATE(t->entries[curcpu],
@@ -1011,7 +1014,6 @@
counters,
&i);
}
- put_cpu();
}
static int
@@ -1029,7 +1031,7 @@
(other than comefrom, which userspace doesn't care
about). */
countersize = sizeof(struct ipt_counters) * table->private->number;
- counters = vmalloc(countersize);
+ counters = vmalloc_node(countersize, numa_node_id());
if (counters == NULL)
return -ENOMEM;
@@ -1039,8 +1041,11 @@
get_counters(table->private, counters);
write_unlock_bh(&table->lock);
- /* choose the copy that is on our node/cpu, ... */
- loc_cpu_entry = table->private->entries[get_cpu()];
+ /* choose the copy that is on our node/cpu, ...
+ * This choice is lazy (because current thread is
+ * allowed to migrate to another cpu)
+ */
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
/* ... then copy entire thing ... */
if (copy_to_user(userptr, loc_cpu_entry, total_size) != 0) {
ret = -EFAULT;
@@ -1091,7 +1096,6 @@
}
free_counters:
- put_cpu();
vfree(counters);
return ret;
}
@@ -1189,7 +1193,7 @@
return -ENOMEM;
/* choose the copy that is our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
if (copy_from_user(loc_cpu_entry, user + sizeof(tmp),
tmp.size) != 0) {
ret = -EFAULT;
@@ -1242,9 +1246,8 @@
/* Get the old counters. */
get_counters(oldinfo, counters);
/* Decrease module usage counts and free resource */
- loc_cpu_old_entry = oldinfo->entries[smp_processor_id()];
+ loc_cpu_old_entry = oldinfo->entries[raw_smp_processor_id()];
IPT_ENTRY_ITERATE(loc_cpu_old_entry, oldinfo->size, cleanup_entry,NULL);
- put_cpu();
free_table_info(oldinfo);
if (copy_to_user(tmp.counters, counters,
sizeof(struct ipt_counters) * tmp.num_counters) != 0)
@@ -1261,7 +1264,6 @@
free_newinfo_counters:
vfree(counters);
free_newinfo:
- put_cpu();
free_table_info(newinfo);
return ret;
}
@@ -1303,7 +1305,7 @@
if (len != sizeof(tmp) + tmp.num_counters*sizeof(struct ipt_counters))
return -EINVAL;
- paddc = vmalloc(len);
+ paddc = vmalloc_node(len, numa_node_id());
if (!paddc)
return -ENOMEM;
@@ -1326,7 +1328,7 @@
i = 0;
/* Choose the copy that is on our node */
- loc_cpu_entry = t->private->entries[smp_processor_id()];
+ loc_cpu_entry = t->private->entries[raw_smp_processor_id()];
IPT_ENTRY_ITERATE(loc_cpu_entry,
t->private->size,
add_counter_to_entry,
@@ -1525,8 +1527,10 @@
if (!newinfo)
return -ENOMEM;
- /* choose the copy on our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ /* choose the copy on our node/cpu
+ * but dont care of preemption
+ */
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
memcpy(loc_cpu_entry, repl->entries, repl->size);
ret = translate_table(table->name, table->valid_hooks,
@@ -1534,7 +1538,6 @@
repl->num_entries,
repl->hook_entry,
repl->underflow);
- put_cpu();
if (ret != 0) {
free_table_info(newinfo);
return ret;
@@ -1584,10 +1587,9 @@
up(&ipt_mutex);
/* Decrease module usage counts and free resources */
- loc_cpu_entry = table->private->entries[get_cpu()];
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
IPT_ENTRY_ITERATE(loc_cpu_entry, table->private->size,
cleanup_entry, NULL);
- put_cpu();
free_table_info(table->private);
}
--- net-2.6.16-orig/net/ipv6/netfilter/ip6_tables.c 2005-11-25 10:24:02.000000000 +0100
+++ net-2.6.16/net/ipv6/netfilter/ip6_tables.c 2005-11-25 11:23:03.000000000 +0100
@@ -1074,11 +1074,14 @@
{
unsigned int cpu;
unsigned int i;
- unsigned int curcpu = get_cpu();
+ unsigned int curcpu;
/* Instead of clearing (by a previous call to memset())
* the counters and using adds, we set the counters
- * with data used by current CPU */
+ * with data used by 'current' CPU
+ * We dont care about preemption here.
+ */
+ curcpu = raw_smp_processor_id();
i = 0;
IP6T_ENTRY_ITERATE(t->entries[curcpu],
@@ -1097,7 +1100,6 @@
counters,
&i);
}
- put_cpu();
}
static int
@@ -1126,7 +1128,7 @@
write_unlock_bh(&table->lock);
/* choose the copy that is on ourc node/cpu */
- loc_cpu_entry = table->private->entries[get_cpu()];
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
if (copy_to_user(userptr, loc_cpu_entry, total_size) != 0) {
ret = -EFAULT;
goto free_counters;
@@ -1176,7 +1178,6 @@
}
free_counters:
- put_cpu();
vfree(counters);
return ret;
}
@@ -1271,7 +1272,7 @@
return -ENOMEM;
/* choose the copy that is on our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
if (copy_from_user(loc_cpu_entry, user + sizeof(tmp),
tmp.size) != 0) {
ret = -EFAULT;
@@ -1324,9 +1325,8 @@
/* Get the old counters. */
get_counters(oldinfo, counters);
/* Decrease module usage counts and free resource */
- loc_cpu_old_entry = oldinfo->entries[smp_processor_id()];
+ loc_cpu_old_entry = oldinfo->entries[raw_smp_processor_id()];
IP6T_ENTRY_ITERATE(loc_cpu_old_entry, oldinfo->size, cleanup_entry,NULL);
- put_cpu();
free_table_info(oldinfo);
if (copy_to_user(tmp.counters, counters,
sizeof(struct ip6t_counters) * tmp.num_counters) != 0)
@@ -1343,7 +1343,6 @@
free_newinfo_counters:
vfree(counters);
free_newinfo:
- put_cpu();
free_table_info(newinfo);
return ret;
}
@@ -1609,7 +1608,7 @@
return -ENOMEM;
/* choose the copy on our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
memcpy(loc_cpu_entry, repl->entries, repl->size);
ret = translate_table(table->name, table->valid_hooks,
@@ -1617,7 +1616,6 @@
repl->num_entries,
repl->hook_entry,
repl->underflow);
- put_cpu();
if (ret != 0) {
free_table_info(newinfo);
return ret;
@@ -1667,10 +1665,9 @@
up(&ip6t_mutex);
/* Decrease module usage counts and free resources */
- loc_cpu_entry = table->private->entries[get_cpu()];
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
IP6T_ENTRY_ITERATE(loc_cpu_entry, table->private->size,
cleanup_entry, NULL);
- put_cpu();
free_table_info(table->private);
}
--- net-2.6.16-orig/net/ipv4/netfilter/arp_tables.c 2005-11-25 10:24:02.000000000 +0100
+++ net-2.6.16/net/ipv4/netfilter/arp_tables.c 2005-11-25 11:15:50.000000000 +0100
@@ -814,11 +814,14 @@
{
unsigned int cpu;
unsigned int i;
- unsigned int curcpu = get_cpu();
+ unsigned int curcpu;
/* Instead of clearing (by a previous call to memset())
* the counters and using adds, we set the counters
- * with data used by current CPU */
+ * with data used by 'current' CPU
+ * We dont care about preemption here.
+ */
+ curcpu = raw_smp_processor_id();
i = 0;
ARPT_ENTRY_ITERATE(t->entries[curcpu],
@@ -837,7 +840,6 @@
counters,
&i);
}
- put_cpu();
}
static int copy_entries_to_user(unsigned int total_size,
@@ -865,7 +867,7 @@
get_counters(table->private, counters);
write_unlock_bh(&table->lock);
- loc_cpu_entry = table->private->entries[get_cpu()];
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
/* ... then copy entire thing ... */
if (copy_to_user(userptr, loc_cpu_entry, total_size) != 0) {
ret = -EFAULT;
@@ -898,7 +900,6 @@
}
free_counters:
- put_cpu();
vfree(counters);
return ret;
}
@@ -996,7 +997,7 @@
return -ENOMEM;
/* choose the copy that is on our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
if (copy_from_user(loc_cpu_entry, user + sizeof(tmp),
tmp.size) != 0) {
ret = -EFAULT;
@@ -1049,9 +1050,9 @@
/* Get the old counters. */
get_counters(oldinfo, counters);
/* Decrease module usage counts and free resource */
- loc_cpu_old_entry = oldinfo->entries[smp_processor_id()];
+ loc_cpu_old_entry = oldinfo->entries[raw_smp_processor_id()];
ARPT_ENTRY_ITERATE(loc_cpu_old_entry, oldinfo->size, cleanup_entry,NULL);
- put_cpu();
+
free_table_info(oldinfo);
if (copy_to_user(tmp.counters, counters,
sizeof(struct arpt_counters) * tmp.num_counters) != 0)
@@ -1068,7 +1069,6 @@
free_newinfo_counters:
vfree(counters);
free_newinfo:
- put_cpu();
free_table_info(newinfo);
return ret;
}
@@ -1295,7 +1295,7 @@
}
/* choose the copy on our node/cpu */
- loc_cpu_entry = newinfo->entries[get_cpu()];
+ loc_cpu_entry = newinfo->entries[raw_smp_processor_id()];
memcpy(loc_cpu_entry, repl->entries, repl->size);
ret = translate_table(table->name, table->valid_hooks,
@@ -1303,7 +1303,6 @@
repl->num_entries,
repl->hook_entry,
repl->underflow);
- put_cpu();
duprintf("arpt_register_table: translate table gives %d\n", ret);
if (ret != 0) {
free_table_info(newinfo);
@@ -1354,10 +1353,9 @@
up(&arpt_mutex);
/* Decrease module usage counts and free resources */
- loc_cpu_entry = table->private->entries[get_cpu()];
+ loc_cpu_entry = table->private->entries[raw_smp_processor_id()];
ARPT_ENTRY_ITERATE(loc_cpu_entry, table->private->size,
cleanup_entry, NULL);
- put_cpu();
free_table_info(table->private);
}
^ permalink raw reply
* Re: ipw2200 in 2.6.15-rc2-git4 warns about improper NETDEV_TX_BUSY retcode
From: Kasper Sandberg @ 2005-11-25 13:17 UTC (permalink / raw)
To: Alessandro Suardi; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <5a4c581d0511241538s496adee9s249cd038501545c9@mail.gmail.com>
mine does something different, it keep saying something about firmware
error, and that it restarts, however it holds the connection fine.
On Fri, 2005-11-25 at 00:38 +0100, Alessandro Suardi wrote:
> Dell Latitude D610, FC4 base distro, kernel is:
>
> [asuardi@sandman ~]$ cat /proc/version
> Linux version 2.6.15-rc2-git4 (asuardi@sandman) (gcc version 4.0.1
> 20050727 (Red Hat 4.0.1-5)) #2 Fri Nov 25 00:15:46 CET 2005
>
> Onboard wireless card as detected by kernel is:
> ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
>
> and I placed the 2.4 firmware from sourceforge.net in /lib/firmware.
>
> ifup eth1 yields this message:
>
> eth1: NETDEV_TX_BUSY returned; driver should report queue full via
> ieee_device->is_queue_full.
>
>
> I'm connected to my wireless DSL router while typing this mail
> so it obviously isn't fatal...
>
>
> Thanks,
>
> --alessandro
>
> "So much can happen by accident
> No rhyme, no reason - no one's innocent"
>
> (Steve Wynn - "Under The Weather")
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: ipw2200 in 2.6.15-rc2-git4 warns about improper NETDEV_TX_BUSY retcode
From: Alejandro Bonilla Beeche @ 2005-11-25 16:33 UTC (permalink / raw)
To: Alessandro Suardi
Cc: Linux Kernel Mailing List, netdev, James Ketrenos, yi.zhu
In-Reply-To: <5a4c581d0511241538s496adee9s249cd038501545c9@mail.gmail.com>
Alessandro Suardi wrote:
>Dell Latitude D610, FC4 base distro, kernel is:
>
>[asuardi@sandman ~]$ cat /proc/version
>Linux version 2.6.15-rc2-git4 (asuardi@sandman) (gcc version 4.0.1
>20050727 (Red Hat 4.0.1-5)) #2 Fri Nov 25 00:15:46 CET 2005
>
>Onboard wireless card as detected by kernel is:
>ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8
>
> and I placed the 2.4 firmware from sourceforge.net in /lib/firmware.
>
>ifup eth1 yields this message:
>
>eth1: NETDEV_TX_BUSY returned; driver should report queue full via
>ieee_device->is_queue_full.
>
>
There is bug 808 at bughost.org for the IPW2200 project.
I have asked the patch to be merged but I dunno why it hasn't been
pushed up.
.Alejandro
>
>I'm connected to my wireless DSL router while typing this mail
> so it obviously isn't fatal...
>
>
>Thanks,
>
>--alessandro
>
>
^ permalink raw reply
* Re: [PATCH (resent with the attachment !)] netfilter : zap get_cpu()/put_cpu() calls from ip_tables
From: Patrick McHardy @ 2005-11-25 18:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Harald Welte, Andrew Morton, netfilter-devel, David S. Miller,
netdev
In-Reply-To: <4386F56F.7020205@cosmosbay.com>
Eric Dumazet wrote:
> The 'ip_tables: NUMA-aware allocation' patch
> (http://www.kernel.org/git/?p=linux/kernel/git/davem/net-2.6.16.git;a=commit;h=6d1273850cac8db77c462caaa145b813d93adc55)
>
> introduced a problem with get_cpu()/put_cpu()
>
> The problem is that get_cpu() disables preemption and the thread is not
> allowed to sleep.
>
> As the intent was only to give a hint, relax the enforcement and switch
> to a hint : If the current thread is preempted and migrated to another
> cpu, this is not a problem. Most of the time, thread wont be migrated
> anyway.
>
> This patch removes get_cpu()/put_cpu() pairs and uses
> raw_smp_processor_id() were appropriate.
Looks good, thanks. I'm going to test it and pass it on to Dave if it
works.
^ permalink raw reply
* Re: Mouse issues in -mm
From: Dmitry Torokhov @ 2005-11-25 22:31 UTC (permalink / raw)
To: Frank Sorenson
Cc: Andrew Morton, Marc Koschewski, linux-kernel, Harald Welte,
netdev
In-Reply-To: <43855A50.80808@tuxrocks.com>
On Thursday 24 November 2005 01:14, Frank Sorenson wrote:
> Note: I believe this issue may also be related to the mouse protocol
> extension. I typically run with 'psmouse.proto=exps' on the kernel
> command line, and the psmouse resync patch seems to break tapping in
> that mode.
So the resync patch - is it only tapping that is broken or you also
loosing the touchpad completely?
> However, booting without proto=exps seems to continue to
> work, even with the resync patch (though the touchpad is unusably
> sensitive--hence the use of exps in the first place).
Without the parameter your touchpad is using native ALPS protocol and
resync is disabled for it. You may have better liuck with toucpad
sensitivity using synaptics X driver.
--
Dmitry
^ permalink raw reply
* VIA "Velocity" test report - VLAN reception not working
From: linux @ 2005-11-26 0:40 UTC (permalink / raw)
To: alan; +Cc: linux, netdev
Okay this is a little late for your May '04 test request, but
I just got one of these (Zyxel GN670-T brand) to upgrade a server.
(PII+440BX motherboard, getting a bit dated, but working very reliably)
0000:00:09.0 0200: 1106:3119 (rev 11)
Subsystem: 187e:3302
Flags: bus master, 66MHz, medium devsel, latency 48, IRQ 9
I/O ports at d000 [size=256]
Memory at e1800000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
ethtool output:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: Not reported
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: puag
Wake-on: g
Current message level: 0x00000002 (2)
Link detected: no
Kernel 2.6.15-rc2, monolithic. Only local patch is PPSkit-lite, which
really shouldn't have any effect. No idea about that "Link detected: no"
line; I'm ssh- ed in over it right now.
Anyway, I can send and receive untagged packets just fine, but I can't
seem to receive tagged packets. A Tulip-based 100baseT card plugged
into another port on the same switch gets everything. (I also swapped
ports to confirm.)
I saw a bunch of VLAN filtering stuff in the driver that I didn't
really follow, so perhaps the problem's there.
(I confess I didn't choose super-carefully. It was advertised as having
Linux support and VLAN support and was reasonably cheap. I didn't
actually know the chipset until it arrived. And yes, I *am* asking the
vendor for support, but I expect that'll take a while.)
Here are some simultaneous TCPdumps of the two cards both
plugged into tagged ports (vlan 2 only) on the same switch.
First, the Velocity card:
18:47:43.612697 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 00ad
18:47:45.615858 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 00ad
18:47:47.615340 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 015e
18:47:49.615663 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0000 0000 0000
18:47:51.619371 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 015d
18:47:53.621815 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 015e
18:47:55.623634 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8001 0000
0x0020: 1400 0200 0f00 0000 0101 080a 015e
Then, the Tulip card:
18:47:44.253702 vlan 2, p 0, IP 192.35.100.29.45877 > 192.35.100.1.53: 26928+ A? home25.netscape.com.horizon.com. (49)
0x0000: 0002 0800 4500 004d 0daa 4000 ff11 2590
0x0010: c023 641d c023 6401 b335 0035 0039 9b66
0x0020: 6930 0100 0001 0000 0000 0000 0668 6f6d
0x0030: 6532 3508 6e65 7473 6361 7065 0363 6f6d
0x0040: 0768 6f72 697a 6f6e 0363 6f6d 0000 0100
0x0050: 01
18:47:44.264620 vlan 2, p 0, IP 192.35.100.29.45878 > 192.35.100.1.53: 21460+ A? loghost.horizon.com. (37)
0x0000: 0002 0800 4500 0041 0dab 4000 ff11 259b
0x0010: c023 641d c023 6401 b336 0035 002d 97a2
0x0020: 53d4 0100 0001 0000 0000 0000 076c 6f67
0x0030: 686f 7374 0768 6f72 697a 6f6e 0363 6f6d
0x0040: 0000 0100 01
18:47:44.418660 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:44.462252 vlan 2, p 0, IP 192.35.100.23.36769 > 192.35.100.1.53: 4757+ A? inc.horizon.com. (33)
0x0000: 0002 0800 4500 003d 0f62 4000 ff11 23ee
0x0010: c023 6417 c023 6401 8fa1 0035 0029 dd6f
0x0020: 1295 0100 0001 0000 0000 0000 0369 6e63
0x0030: 0768 6f72 697a 6f6e 0363 6f6d 0000 0100
0x0040: 01
18:47:44.764354 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40257, length 64
0x0000: 0002 0800 4500 0054 9d40 4000 4001 551d
0x0010: c023 6403 c023 6401 0800 0b0d df4e 9d41
0x0020: a0a2 8743 0000 0000 7ea9 0b00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:44.839288 vlan 2, p 0, IP 192.35.100.36.40967 > 192.35.100.1.53: 40979+ A? mirror.csit.fsu.edu. (37)
0x0000: 0002 0800 4500 0041 227d 4000 ff11 10c2
0x0010: c023 6424 c023 6401 a007 0035 002d 73e5
0x0020: a013 0100 0001 0000 0000 0000 066d 6972
0x0030: 726f 7204 6373 6974 0366 7375 0365 6475
0x0040: 0000 0100 01
18:47:45.049258 vlan 2, p 0, arp who-has 192.35.100.139 tell 192.35.100.234
0x0000: 0002 0806 0001 0800 0604 0001 0080 c8b9
0x0010: c1d5 c023 64ea 0000 0000 0000 c023 648b
18:47:45.264333 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40258, length 64
0x0000: 0002 0800 4500 0054 9d41 4000 4001 551c
0x0010: c023 6403 c023 6401 0800 39ad df4e 9d42
0x0020: a1a2 8743 0000 0000 5608 0400 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:45.418585 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:45.628260 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8019 0000
0x0020: 1400 0200 0f00 0000 0101 080a 00ad
18:47:45.780328 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40259, length 64
0x0000: 0002 0800 4500 0054 9d42 4000 4001 551b
0x0010: c023 6403 c023 6401 0800 9bcc df4e 9d43
0x0020: a1a2 8743 0000 0000 ece7 0b00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:46.049345 vlan 2, p 0, arp who-has 192.35.100.139 tell 192.35.100.234
0x0000: 0002 0806 0001 0800 0604 0001 0080 c8b9
0x0010: c1d5 c023 64ea 0000 0000 0000 c023 648b
18:47:46.215070 vlan 2, p 0, IP 192.35.100.39.723 > 192.35.100.1.111: UDP, length 56
0x0000: 0002 0800 4500 0054 7d0a 4000 ff11 b61e
0x0010: c023 6427 c023 6401 02d3 006f 0040 c42e
0x0020: 4385 9ea7 0000 0000 0000 0002 0001 86a0
0x0030: 0000 0002 0000 0003 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0001 86a4 0000 0002
0x0050: 0000 0011 0000 0000
18:47:46.280315 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40260, length 64
0x0000: 0002 0800 4500 0054 9d43 4000 4001 551a
0x0010: c023 6403 c023 6401 0800 ca6c df4e 9d44
0x0020: a2a2 8743 0000 0000 c446 0400 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:46.418594 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:46.796311 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40261, length 64
0x0000: 0002 0800 4500 0054 9d44 4000 4001 5519
0x0010: c023 6403 c023 6401 0800 2c8c df4e 9d45
0x0020: a2a2 8743 0000 0000 5a26 0c00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:47.049424 vlan 2, p 0, arp who-has 192.35.100.139 tell 192.35.100.234
0x0000: 0002 0806 0001 0800 0604 0001 0080 c8b9
0x0010: c1d5 c023 64ea 0000 0000 0000 c023 648b
18:47:47.296299 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40262, length 64
0x0000: 0002 0800 4500 0054 9d45 4000 4001 5518
0x0010: c023 6403 c023 6401 0800 5b2c df4e 9d46
0x0020: a3a2 8743 0000 0000 3285 0400 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:47.412369 vlan 2, p 0, IP 192.35.100.23.727 > 192.35.100.1.111: UDP, length 56
0x0000: 0002 0800 4500 0054 0f63 4000 ff11 23d6
0x0010: c023 6417 c023 6401 02d7 006f 0040 e607
0x0020: 4382 7cdd 0000 0000 0000 0002 0001 86a0
0x0030: 0000 0002 0000 0003 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0001 86a4 0000 0002
0x0050: 0000 0011 0000 0000
18:47:47.418592 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:47.452763 vlan 2, p 0, IP 192.35.100.23.36770 > 198.69.104.3.53: 10818+ A? xave0. (23)
0x0000: 0002 0800 4500 0033 0911 4000 ff11 2025
0x0010: c023 6417 c645 6803 8fa2 0035 001f 23f3
0x0020: 2a42 0100 0001 0000 0000 0000 0578 6176
0x0030: 6530 0000 0100 01
18:47:47.627380 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8019 0000
0x0020: 1400 0200 0f00 0000 0101 080a 015e
18:47:47.812301 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40263, length 64
0x0000: 0002 0800 4500 0054 9d46 4000 4001 5517
0x0010: c023 6403 c023 6401 0800 bd4b df4e 9d47
0x0020: a3a2 8743 0000 0000 c864 0c00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:48.306211 vlan 2, p 0, arp who-has 192.35.100.1 tell 192.35.100.43
0x0000: 0002 0806 0001 0800 0604 0001 00e0 18cf
0x0010: e42f c023 642b 0000 0000 0000 c023 6401
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:48.306279 vlan 2, p 0, arp reply 192.35.100.1 is-at 00:80:c8:b9:c1:d5
0x0000: 0002 0806 0001 0800 0604 0002 0080 c8b9
0x0010: c1d5 c023 6401 00e0 18cf e42f c023 642b
18:47:48.312271 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40264, length 64
0x0000: 0002 0800 4500 0054 9d47 4000 4001 5516
0x0010: c023 6403 c023 6401 0800 eaeb df4e 9d48
0x0020: a4a2 8743 0000 0000 a1c3 0400 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:48.828276 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40265, length 64
0x0000: 0002 0800 4500 0054 9d48 4000 4001 5515
0x0010: c023 6403 c023 6401 0800 4e0b df4e 9d49
0x0020: a4a2 8743 0000 0000 36a3 0c00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:49.263637 vlan 2, p 0, IP 192.35.100.29.45879 > 192.35.100.1.53: 21460+ A? loghost.horizon.com. (37)
0x0000: 0002 0800 4500 0041 0dac 4000 ff11 259a
0x0010: c023 641d c023 6401 b337 0035 002d 97a1
0x0020: 53d4 0100 0001 0000 0000 0000 076c 6f67
0x0030: 686f 7374 0768 6f72 697a 6f6e 0363 6f6d
0x0040: 0000 0100 01
18:47:49.328257 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40266, length 64
0x0000: 0002 0800 4500 0054 9d49 4000 4001 5514
0x0010: c023 6403 c023 6401 0800 7dab df4e 9d4a
0x0020: a5a2 8743 0000 0000 0d02 0500 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:49.628255 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8019 0000
0x0020: 1400 0200 0f00 0000 0000 0000 0000
18:47:49.829323 vlan 2, p 0, IP 192.35.100.36.40968 > 192.35.100.1.53: 32418+ A? sunfreeware.mirrors.tds.net.horizon.com. (57)
0x0000: 0002 0800 4500 0055 227e 4000 ff11 10ad
0x0010: c023 6424 c023 6401 a008 0035 0041 757e
0x0020: 7ea2 0100 0001 0000 0000 0000 0b73 756e
0x0030: 6672 6565 7761 7265 076d 6972 726f 7273
0x0040: 0374 6473 036e 6574 0768 6f72 697a 6f6e
0x0050: 0363 6f6d 0000 0100 01
18:47:49.844258 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40267, length 64
0x0000: 0002 0800 4500 0054 9d4a 4000 4001 5513
0x0010: c023 6403 c023 6401 0800 deca df4e 9d4b
0x0020: a5a2 8743 0000 0000 a4e1 0c00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:49.994730 vlan 2, p 0, IP 192.35.100.28.41057 > 192.35.100.1.53: 41451+ A? bimini. (24)
0x0000: 0002 0800 4500 0034 758e 4000 ff11 bdc5
0x0010: c023 641c c023 6401 a061 0035 0020 3186
0x0020: a1eb 0100 0001 0000 0000 0000 0662 696d
0x0030: 696e 6900 0001 0001
18:47:50.344249 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40268, length 64
0x0000: 0002 0800 4500 0054 9d4b 4000 4001 5512
0x0010: c023 6403 c023 6401 0800 086b df4e 9d4c
0x0020: a6a2 8743 0000 0000 8140 0500 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:50.463048 vlan 2, p 0, IP 192.35.100.23.36771 > 198.69.104.19.53: 4757+ A? inc.horizon.com. (33)
0x0000: 0002 0800 4500 003d f58a 4000 ff11 3391
0x0010: c023 6417 c645 6813 8fa3 0035 0029 d339
0x0020: 1295 0100 0001 0000 0000 0000 0369 6e63
0x0030: 0768 6f72 697a 6f6e 0363 6f6d 0000 0100
0x0040: 01
18:47:50.860237 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40269, length 64
0x0000: 0002 0800 4500 0054 9d4c 4000 4001 5511
0x0010: c023 6403 c023 6401 0800 6f8a df4e 9d4d
0x0020: a6a2 8743 0000 0000 1220 0d00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:51.138682 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:51.211846 vlan 2, p 0, IP 192.35.100.23.734 > 192.35.100.1.2049: S 3636096760:3636096760(0) win 8760 <mss 1460>
0x0000: 0002 0800 4500 002c 0f64 4000 ff06 2408
0x0010: c023 6417 c023 6401 02de 0801 d8ba 6ef8
0x0020: 0000 0000 6002 2238 dafc 0000 0204 05b4
0x0030: 5555
18:47:51.360222 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40270, length 64
0x0000: 0002 0800 4500 0054 9d4d 4000 4001 5510
0x0010: c023 6403 c023 6401 0800 9e2a df4e 9d4e
0x0020: a7a2 8743 0000 0000 ea7e 0500 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:51.631385 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8019 0000
0x0020: 1400 0200 0f00 0000 0000 0000 0000
18:47:51.876222 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40271, length 64
0x0000: 0002 0800 4500 0054 9d4e 4000 4001 550f
0x0010: c023 6403 c023 6401 0800 014a df4e 9d4f
0x0020: a7a2 8743 0000 0000 7f5e 0d00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:52.138545 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:52.376207 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40272, length 64
0x0000: 0002 0800 4500 0054 9d4f 4000 4001 550e
0x0010: c023 6403 c023 6401 0800 2eea df4e 9d50
0x0020: a8a2 8743 0000 0000 58bd 0500 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:52.449501 vlan 2, p 0, IP 192.35.100.86.933 > 192.35.100.1.2049: S 3199884626:3199884626(0) win 8760 <mss 1460>
0x0000: 0002 0800 4500 002c d816 4000 ff06 5b16
0x0010: c023 6456 c023 6401 03a5 0801 beba 5d52
0x0020: 0000 0000 6002 2238 059d 0000 0204 05b4
0x0030: 5555
18:47:52.829061 vlan 2, p 0, IP 192.35.100.32.265061 > 192.35.100.1.2049: 104 getattr fh Unknown/010000020009000440ED2B00DF7741008B4F2400DA774100724F240000000000
0x0000: 0002 0800 4500 0084 e550 0000 ff11 8daf
0x0010: c023 6420 c023 6401 03fb 0801 0070 0000
0x0020: 0004 0b65 0000 0000 0000 0002 0001 86a3
0x0030: 0000 0002 0000 0001 0000 0001 0000 0020
0x0040: 4387 a2a8 0000 0006 6261 6c72 6f67 0000
0x0050: 0000 0000 0000 0000 0000 0001 0000 0000
0x0060: 0000 0000 0000 0000 0100 0002 0009 0004
0x0070: 40ed 2b00 df77 4100 8b4f 2400 da77 4100
0x0080: 724f 2400 0000 0000
18:47:52.849002 vlan 2, p 0, IP 192.35.100.32.265062 > 192.35.100.1.2049: 132 getattr fh Unknown/010000020009000440ED2B0004261D0055782400AD251D00A676240000000000
0x0000: 0002 0800 4500 00a0 e551 0000 ff11 8d92
0x0010: c023 6420 c023 6401 03fc 0801 008c 0000
0x0020: 0004 0b66 0000 0000 0000 0002 0001 86a3
0x0030: 0000 0002 0000 0001 0000 0001 0000 003c
0x0040: 4387 a2a8 0000 0006 6261 6c72 6f67 5b6d
0x0050: 0000 009e 0000 000b 0000 0008 0000 000b
0x0060: 0000 000a 0000 000c 0000 000e 0000 000f
0x0070: 0000 003c 0000 0014 0000 0018 0000 0000
0x0080: 0000 0000 0100 0002 0009 0004 40ed 2b00
0x0090: 0426 1d00 5578 2400 ad25 1d00 a676 2400
0x00a0: 0000 0000
18:47:52.892204 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40273, length 64
0x0000: 0002 0800 4500 0054 9d50 4000 4001 550d
0x0010: c023 6403 c023 6401 0800 9209 df4e 9d51
0x0020: a8a2 8743 0000 0000 ed9c 0d00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:53.076199 vlan 2, p 0, IP 192.35.100.3.123 > 192.35.100.1.123: NTPv4, Client, length 48
0x0000: 0002 0800 4510 004c 5084 4000 4011 a1c1
0x0010: c023 6403 c023 6401 007b 007b 0038 710f
0x0020: 6302 04ec 0000 000f 0000 050f c023 6401
0x0030: c732 1eb8 166c c1ca 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 c732 2129 137d fa00
18:47:53.138525 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
18:47:53.392190 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40274, length 64
0x0000: 0002 0800 4500 0054 9d51 4000 4001 550c
0x0010: c023 6403 c023 6401 0800 c0a9 df4e 9d52
0x0020: a9a2 8743 0000 0000 c5fb 0500 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:53.452379 vlan 2, p 0, IP 192.35.100.23.36772 > 192.35.100.1.53: 10818+ A? xave0. (23)
0x0000: 0002 0800 4500 0033 0f65 4000 ff11 23f5
0x0010: c023 6417 c023 6401 8fa4 0035 001f 2e15
0x0020: 2a42 0100 0001 0000 0000 0000 0578 6176
0x0030: 6530 0000 0100 01
18:47:53.542795 vlan 2, p 0, IP 192.35.100.30.53148 > 192.35.100.1.661: UDP, length 92
0x0000: 0002 0800 4500 0078 2e79 4000 ff11 0495
0x0010: c023 641e c023 6401 cf9c 0295 0064 f084
0x0020: 4381 bb7b 0000 0000 0000 0002 0001 86a4
0x0030: 0000 0002 0000 0003 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0000 000b 686f 7269
0x0050: 7a6f 6e2e 636f 6d00 0000 000d 7061 7373
0x0060: 7764 2e62 796e 616d 6500 0000 0000 000a
0x0070: 7275 6e64 6c32 6265 616d 0000
18:47:53.571691 vlan 2, p 0, IP 192.35.100.30.53149 > 192.35.100.1.111: UDP, length 64
0x0000: 0002 0800 4500 005c 2e7a 4000 ff11 04b0
0x0010: c023 641e c023 6401 cf9d 006f 0048 5c16
0x0020: 4381 549a 0000 0000 0000 0002 0001 86a0
0x0030: 0000 0003 0000 0003 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0001 86a4 0000 0002
0x0050: 0000 0003 7564 7000 0000 0000 0000 0000
18:47:53.574510 vlan 2, p 0, IP 192.35.100.30.53150 > 192.35.100.1.661: UDP, length 88
0x0000: 0002 0800 4500 0074 2e7b 4000 ff11 0497
0x0010: c023 641e c023 6401 cf9e 0295 0060 f79d
0x0020: 4381 0cb2 0000 0000 0000 0002 0001 86a4
0x0030: 0000 0002 0000 0003 0000 0000 0000 0000
0x0040: 0000 0000 0000 0000 0000 000b 686f 7269
0x0050: 7a6f 6e2e 636f 6d00 0000 000d 7061 7373
0x0060: 7764 2e62 796e 616d 6500 0000 0000 0008
0x0070: 7365 6e64 6d61 696c
18:47:53.634245 802.1d unknown version
0x0000: 4242 0300 0002 024c 8000 000f b53f 7ea4
0x0010: 0000 0000 8000 000f b53f 7ea4 8019 0000
0x0020: 1400 0200 0f00 0000 0101 080a 00ad
18:47:53.908188 vlan 2, p 0, IP 192.35.100.3 > 192.35.100.1: ICMP echo request, id 57166, seq 40275, length 64
0x0000: 0002 0800 4500 0054 9d52 4000 4001 550b
0x0010: c023 6403 c023 6401 0800 21c9 df4e 9d53
0x0020: a9a2 8743 0000 0000 5cdb 0d00 0000 0000
0x0030: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0040: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f
0x0050: 3031 3233 3435 3637
18:47:54.138621 vlan 2, p 0, arp who-has 192.35.100.95 (ff:ff:ff:ff:ff:ff) tell 192.35.100.92
0x0000: 0002 0806 0001 0800 0604 0001 0003 bad9
0x0010: a038 c023 645c ffff ffff ffff c023 645f
0x0020: 0000 0000 0000 0000 0000 0000 0000 0000
0x0030: 0000
Thanks a lot for any suggestions!
^ permalink raw reply
* In Confindence/Shara
From: Kwasha Shara @ 2005-11-26 6:23 UTC (permalink / raw)
To: netdev
Hello dear,
I am Miss Shara Kwasha. It is my desire to contact you on honesty and sincerity to assist me in transferring the sum of $2,350,000 inherited from my father late Mr. Kwasha. I am motivated in contacting you and hope to gradually build trust, relationship and confidence in you as i get to know you better.
So please i want to know if you will be of assistance but first i want to get to know you better. I am willing to offer you $235,000 usd for your effort input after the successful transfer of this money to your account overseas.
Indicate your interest towards assisting me by sending your phone # and address so that i can communicate with you at any time. I will be waiting for your response.
Thanks
Shara
^ permalink raw reply
* [PATCH 2.4] sis900: come alive after temporary memory shortage
From: Vasily Averin @ 2005-11-26 9:23 UTC (permalink / raw)
To: Marcelo Tosatti, linux-kernel
Cc: Konstantin Khorenko, netdev, Daniele Venzano
[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]
Hello Marcelo,
I would like to inform you that unfortunately the committed patch is wrong
http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commit;h=ecf3337f76eaa94c5a771308d184dc248b74b725
+ int rx_work_limit =
+ (sis_priv->dirty_rx - sis_priv->cur_rx) % NUM_RX_DESC;
when dirty_rx = cur_rx it computes limit=0, but should be NUM_RX_DESC
Could you please drop the wrong patch and use a new one based on the version
approved by Daniele Venzano and Jeff Garzik
http://www.kernel.org/git/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff_plain;h=7380a78a973a8109c13cb0e47617c456b6f6e1f5;hp=b2795f596932286ef12dc08857960d654f577405
Thank you,
Vasily Averin
SWSoft Linux kernel Team
sis900: come alive after temporary memory shortage
1) Forgotten counter incrementation in sis900_rx() in case
it doesn't get memory for skb, that leads to whole interface failure.
Problem is accompanied with messages:
eth0: Memory squeeze,deferring packet.
eth0: NULL pointer encountered in Rx ring, skipping
2) If counter cur_rx overflows and there'll be temporary memory problems
buffer can't be recreated later, when memory IS available.
3) Limit the work in handler to prevent the endless packets processing
if new packets are generated faster then handled.
Signed-off-by: Konstantin Khorenko <khorenko@sw.ru>
Signed-off-by: Vasily Averin <vvs@sw.ru>
---
[-- Attachment #2: diff-drv-sis900-20051126 --]
[-- Type: text/plain, Size: 1973 bytes --]
--- a/drivers/net/sis900.c 2005-11-26 10:54:33.000000000 +0300
+++ b/drivers/net/sis900.c 2005-11-26 11:30:17.000000000 +0300
@@ -1613,15 +1613,20 @@ static int sis900_rx(struct net_device *
long ioaddr = net_dev->base_addr;
unsigned int entry = sis_priv->cur_rx % NUM_RX_DESC;
u32 rx_status = sis_priv->rx_ring[entry].cmdsts;
+ int rx_work_limit;
if (sis900_debug > 3)
printk(KERN_INFO "sis900_rx, cur_rx:%4.4d, dirty_rx:%4.4d "
"status:0x%8.8x\n",
sis_priv->cur_rx, sis_priv->dirty_rx, rx_status);
+ rx_work_limit = sis_priv->dirty_rx + NUM_RX_DESC - sis_priv->cur_rx;
while (rx_status & OWN) {
unsigned int rx_size;
+ if (--rx_work_limit < 0)
+ break;
+
rx_size = (rx_status & DSIZE) - CRC_SIZE;
if (rx_status & (ABORT|OVERRUN|TOOLONG|RUNT|RXISERR|CRCERR|FAERR)) {
@@ -1648,9 +1653,11 @@ static int sis900_rx(struct net_device *
some unknow bugs, it is possible that
we are working on NULL sk_buff :-( */
if (sis_priv->rx_skbuff[entry] == NULL) {
- printk(KERN_INFO "%s: NULL pointer "
- "encountered in Rx ring, skipping\n",
- net_dev->name);
+ printk(KERN_WARNING "%s: NULL pointer "
+ "encountered in Rx ring\n"
+ "cur_rx:%4.4d, dirty_rx:%4.4d\n",
+ net_dev->name, sis_priv->cur_rx,
+ sis_priv->dirty_rx);
break;
}
@@ -1688,6 +1695,7 @@ static int sis900_rx(struct net_device *
sis_priv->rx_ring[entry].cmdsts = 0;
sis_priv->rx_ring[entry].bufptr = 0;
sis_priv->stats.rx_dropped++;
+ sis_priv->cur_rx++;
break;
}
skb->dev = net_dev;
@@ -1705,7 +1713,7 @@ static int sis900_rx(struct net_device *
/* refill the Rx buffer, what if the rate of refilling is slower than
consuming ?? */
- for (;sis_priv->cur_rx - sis_priv->dirty_rx > 0; sis_priv->dirty_rx++) {
+ for (; sis_priv->cur_rx != sis_priv->dirty_rx; sis_priv->dirty_rx++) {
struct sk_buff *skb;
entry = sis_priv->dirty_rx % NUM_RX_DESC;
^ permalink raw reply
* Re: [PATCH 2.4] sis900: come alive after temporary memory shortage
From: Marcelo Tosatti @ 2005-11-27 8:35 UTC (permalink / raw)
To: Vasily Averin; +Cc: linux-kernel, Konstantin Khorenko, netdev, Daniele Venzano
In-Reply-To: <438829AF.8060101@sw.ru>
On Sat, Nov 26, 2005 at 12:23:59PM +0300, Vasily Averin wrote:
> Hello Marcelo,
>
> I would like to inform you that unfortunately the committed patch is wrong
> http://www.kernel.org/git/?p=linux/kernel/git/marcelo/linux-2.4.git;a=commit;h=ecf3337f76eaa94c5a771308d184dc248b74b725
>
> + int rx_work_limit =
> + (sis_priv->dirty_rx - sis_priv->cur_rx) % NUM_RX_DESC;
>
> when dirty_rx = cur_rx it computes limit=0, but should be NUM_RX_DESC
>
> Could you please drop the wrong patch and use a new one based on the version
> approved by Daniele Venzano and Jeff Garzik
> http://www.kernel.org/git/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commitdiff_plain;h=7380a78a973a8109c13cb0e47617c456b6f6e1f5;hp=b2795f596932286ef12dc08857960d654f577405
Will do - thanks Vasily.
^ permalink raw reply
* memory allocation for DMA operations from network interface
From: Mateusz Berezecki @ 2005-11-27 18:06 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev
Hello List,
My question is about DMA transfers from network device. I suspect
these transfers require allocating physically contiguous memory
blocks. What is the proper way to allocate such contiguous memory for
DMA purposes inside the kernel? Also what is the proper and
architecture independent way to convert virtual address to physical
one?
kind regards
Mateusz Berezecki
^ permalink raw reply
* Re: memory allocation for DMA operations from network interface
From: Arjan van de Ven @ 2005-11-27 18:19 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <aec8d6fc0511271006v265a3537r6a90e7d53f706d26@mail.gmail.com>
On Sun, 2005-11-27 at 19:06 +0100, Mateusz Berezecki wrote:
> Hello List,
>
> My question is about DMA transfers from network device. I suspect
> these transfers require allocating physically contiguous memory
> blocks. What is the proper way to allocate such contiguous memory for
> DMA purposes inside the kernel? Also what is the proper and
> architecture independent way to convert virtual address to physical
> one?
see Documentation/DMA-mapping.txt
^ permalink raw reply
* net_device + pci_dev question
From: Mateusz Berezecki @ 2005-11-27 19:58 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
Hello List!
Having only net_device pointer is it possible to retrieve associated pci_dev
pointer basing on this information only?
kind regards,
Mateusz Berezecki
^ permalink raw reply
* Re: net_device + pci_dev question
From: Arjan van de Ven @ 2005-11-27 21:25 UTC (permalink / raw)
To: Mateusz Berezecki; +Cc: linux-kernel, netdev
In-Reply-To: <2510370984.20051127205827@gmail.com>
On Sun, 2005-11-27 at 20:58 +0100, Mateusz Berezecki wrote:
> Hello List!
>
> Having only net_device pointer is it possible to retrieve associated pci_dev
> pointer basing on this information only?
what do you need it for?
(and.. what if the nic isn't a pci one?)
^ permalink raw reply
* Re: [PATCH 05/13]: [IPV4/6]: Netfilter IPsec output hooks
From: Patrick McHardy @ 2005-11-28 1:07 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051122121358.GA9057@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
Herbert Xu wrote:
> On Tue, Nov 22, 2005 at 09:31:39PM +1100, herbert wrote:
>
>>Unfortunately it looks like gcc 3.3.5 at least is too dumb to optimise
>>it away. I think we'll need a better strategy.
>
>
> OK, the idea is still the same: Move the loop from dst_output into
> xfrm4_output/xfrm6_output since they're the only ones who need to it.
>
> In order to avoid the tail call issue, I've added the inline function
> nf_hook which is nf_hook_slow plus the empty list check.
Thanks, this looks great. I've changed it to only call the hooks
before tunnel mode transforms and added a missing dst_output call
for the final packet.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 8459 bytes --]
[XFRM4/6]: Netfilter IPsec output hooks
Call netfilter hooks before IPsec transforms. Packets visit the FORWARD/LOCAL_OUT
and POST_ROUTING hook before the first encapsulation and the LOCAL_OUT and
POST_ROUTING hook before each following tunnel mode transform.
Based in large parts on patch by Herbert Xu <herbert@gondor.apana.org.au>,
that hides everything within xfrm{4,6}_output.c. Original description:
-
Move the loop from dst_output into xfrm4_output/xfrm6_output since they're
the only ones who need to it.
In order to avoid the tail call issue, I've added the inline function
nf_hook which is nf_hook_slow plus the empty list check.
-
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit 7abb84c6c3916fc365051a090c752db682b022ab
tree 31b5c4089aaf23cd2c44516f95fddf2158d0fd70
parent b47e6dc58fa6342f2403a32dd1060bc8b1cef56b
author Patrick McHardy <kaber@trash.net> Mon, 28 Nov 2005 01:56:11 +0100
committer Patrick McHardy <kaber@trash.net> Mon, 28 Nov 2005 01:56:11 +0100
include/linux/netfilter.h | 61 +++++++++++++++++++++++++++------------------
include/net/dst.h | 11 +-------
net/ipv4/xfrm4_output.c | 39 +++++++++++++++++++++++++++--
net/ipv6/xfrm6_output.c | 39 +++++++++++++++++++++++++++--
4 files changed, 112 insertions(+), 38 deletions(-)
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
index be365e7..79bb977 100644
--- a/include/linux/netfilter.h
+++ b/include/linux/netfilter.h
@@ -168,6 +168,37 @@ void nf_log_packet(int pf,
const struct net_device *out,
struct nf_loginfo *li,
const char *fmt, ...);
+
+int nf_hook_slow(int pf, unsigned int hook, struct sk_buff **pskb,
+ struct net_device *indev, struct net_device *outdev,
+ int (*okfn)(struct sk_buff *), int thresh);
+
+/**
+ * nf_hook_thresh - call a netfilter hook
+ *
+ * Returns 1 if the hook has allowed the packet to pass. The function
+ * okfn must be invoked by the caller in this case. Any other return
+ * value indicates the packet has been consumed by the hook.
+ */
+static inline int nf_hook_thresh(int pf, unsigned int hook,
+ struct sk_buff **pskb,
+ struct net_device *indev,
+ struct net_device *outdev,
+ int (*okfn)(struct sk_buff *), int thresh)
+{
+#ifndef CONFIG_NETFILTER_DEBUG
+ if (list_empty(&nf_hooks[pf][hook]))
+ return 1;
+#endif
+ return nf_hook_slow(pf, hook, pskb, indev, outdev, okfn, thresh);
+}
+
+static inline int nf_hook(int pf, unsigned int hook, struct sk_buff **pskb,
+ struct net_device *indev, struct net_device *outdev,
+ int (*okfn)(struct sk_buff *))
+{
+ return nf_hook_thresh(pf, hook, pskb, indev, outdev, okfn, INT_MIN);
+}
/* Activate hook; either okfn or kfree_skb called, unless a hook
returns NF_STOLEN (in which case, it's up to the hook to deal with
@@ -188,35 +219,17 @@ void nf_log_packet(int pf,
/* This is gross, but inline doesn't cut it for avoiding the function
call in fast path: gcc doesn't inline (needs value tracking?). --RR */
-#ifdef CONFIG_NETFILTER_DEBUG
-#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \
-({int __ret; \
-if ((__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, INT_MIN)) == 1) \
- __ret = (okfn)(skb); \
-__ret;})
-#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh) \
-({int __ret; \
-if ((__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, thresh)) == 1) \
- __ret = (okfn)(skb); \
-__ret;})
-#else
-#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \
-({int __ret; \
-if (list_empty(&nf_hooks[pf][hook]) || \
- (__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, INT_MIN)) == 1) \
- __ret = (okfn)(skb); \
-__ret;})
+
+/* HX: It's slightly less gross now. */
+
#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh) \
({int __ret; \
-if (list_empty(&nf_hooks[pf][hook]) || \
- (__ret=nf_hook_slow(pf, hook, &(skb), indev, outdev, okfn, thresh)) == 1) \
+if ((__ret=nf_hook_thresh(pf, hook, &(skb), indev, outdev, okfn, thresh)) == 1)\
__ret = (okfn)(skb); \
__ret;})
-#endif
-int nf_hook_slow(int pf, unsigned int hook, struct sk_buff **pskb,
- struct net_device *indev, struct net_device *outdev,
- int (*okfn)(struct sk_buff *), int thresh);
+#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \
+ NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, INT_MIN)
/* Call setsockopt() */
int nf_setsockopt(struct sock *sk, int pf, int optval, char __user *opt,
diff --git a/include/net/dst.h b/include/net/dst.h
index 6c196a5..e641dd2 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -224,16 +224,7 @@ static inline void dst_set_expires(struc
/* Output packet to network from transport. */
static inline int dst_output(struct sk_buff *skb)
{
- int err;
-
- for (;;) {
- err = skb->dst->output(skb);
-
- if (likely(err == 0))
- return err;
- if (unlikely(err != NET_XMIT_BYPASS))
- return err;
- }
+ return skb->dst->output(skb);
}
/* Input packet from network to transport. */
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
index 66620a9..67b9483 100644
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -8,8 +8,10 @@
* 2 of the License, or (at your option) any later version.
*/
+#include <linux/compiler.h>
#include <linux/skbuff.h>
#include <linux/spinlock.h>
+#include <linux/netfilter_ipv4.h>
#include <net/inet_ecn.h>
#include <net/ip.h>
#include <net/xfrm.h>
@@ -95,7 +97,7 @@ out:
return ret;
}
-int xfrm4_output(struct sk_buff *skb)
+static int xfrm4_output_one(struct sk_buff *skb)
{
struct dst_entry *dst = skb->dst;
struct xfrm_state *x = dst->xfrm;
@@ -133,7 +135,7 @@ int xfrm4_output(struct sk_buff *skb)
err = -EHOSTUNREACH;
goto error_nolock;
}
- err = NET_XMIT_BYPASS;
+ err = 0;
out_exit:
return err;
@@ -143,3 +145,36 @@ error_nolock:
kfree_skb(skb);
goto out_exit;
}
+
+static int xfrm4_output_finish(struct sk_buff *skb)
+{
+ int err;
+
+ while (likely((err = xfrm4_output_one(skb)) == 0)) {
+ if (!skb->dst->xfrm || skb->dst->xfrm->props.mode) {
+ nf_reset(skb);
+ err = nf_hook(PF_INET, NF_IP_LOCAL_OUT, &skb, NULL,
+ skb->dst->dev, dst_output);
+ if (unlikely(err != 1))
+ break;
+
+ if (!skb->dst->xfrm) {
+ err = dst_output(skb);
+ break;
+ }
+
+ err = nf_hook(PF_INET, NF_IP_POST_ROUTING, &skb, NULL,
+ skb->dst->dev, xfrm4_output_finish);
+ if (unlikely(err != 1))
+ break;
+ }
+ }
+
+ return err;
+}
+
+int xfrm4_output(struct sk_buff *skb)
+{
+ return NF_HOOK(PF_INET, NF_IP_POST_ROUTING, skb, NULL, skb->dst->dev,
+ xfrm4_output_finish);
+}
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index 6b98677..69ee2bf 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -9,9 +9,11 @@
* 2 of the License, or (at your option) any later version.
*/
+#include <linux/compiler.h>
#include <linux/skbuff.h>
#include <linux/spinlock.h>
#include <linux/icmpv6.h>
+#include <linux/netfilter_ipv6.h>
#include <net/dsfield.h>
#include <net/inet_ecn.h>
#include <net/ipv6.h>
@@ -92,7 +94,7 @@ static int xfrm6_tunnel_check_size(struc
return ret;
}
-int xfrm6_output(struct sk_buff *skb)
+static int xfrm6_output_one(struct sk_buff *skb)
{
struct dst_entry *dst = skb->dst;
struct xfrm_state *x = dst->xfrm;
@@ -132,7 +134,7 @@ int xfrm6_output(struct sk_buff *skb)
err = -EHOSTUNREACH;
goto error_nolock;
}
- err = NET_XMIT_BYPASS;
+ err = 0;
out_exit:
return err;
@@ -142,3 +144,36 @@ error_nolock:
kfree_skb(skb);
goto out_exit;
}
+
+static int xfrm6_output_finish(struct sk_buff *skb)
+{
+ int err;
+
+ while (likely((err = xfrm6_output_one(skb)) == 0)) {
+ if (!skb->dst->xfrm || skb->dst->xfrm->props.mode) {
+ nf_reset(skb);
+ err = nf_hook(PF_INET6, NF_IP6_LOCAL_OUT, &skb, NULL,
+ skb->dst->dev, dst_output);
+ if (unlikely(err != 1))
+ break;
+
+ if (!skb->dst->xfrm) {
+ err = dst_output(skb);
+ break;
+ }
+
+ err = nf_hook(PF_INET6, NF_IP6_POST_ROUTING, &skb, NULL,
+ skb->dst->dev, xfrm6_output_finish);
+ if (unlikely(err != 1))
+ break;
+ }
+ }
+
+ return err;
+}
+
+int xfrm6_output(struct sk_buff *skb)
+{
+ return NF_HOOK(PF_INET6, NF_IP6_POST_ROUTING, skb, NULL, skb->dst->dev,
+ xfrm6_output_finish);
+}
^ permalink raw reply related
* Re: [PATCH 05/13]: [IPV4/6]: Netfilter IPsec output hooks
From: Herbert Xu @ 2005-11-28 4:56 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <438A5837.5040706@trash.net>
On Mon, Nov 28, 2005 at 02:07:03AM +0100, Patrick McHardy wrote:
>
> Thanks, this looks great. I've changed it to only call the hooks
Glad you liked it :)
> before tunnel mode transforms and added a missing dst_output call
> for the final packet.
This shouldn't be necessary if you apply it on top of my previous
patch which made xfrm[46]_output process the first SA and all subsequent
transport mode SAs. I've included that patch here again.
I think it still makes sense to do that because this corresponds
with the usual representation of an IPsec connection and it
simplifies the handling of netfilter hooks.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/net/ip.h b/include/net/ip.h
diff --git a/net/ipv4/xfrm4_output.c b/net/ipv4/xfrm4_output.c
--- a/net/ipv4/xfrm4_output.c
+++ b/net/ipv4/xfrm4_output.c
@@ -113,26 +113,31 @@ int xfrm4_output(struct sk_buff *skb)
goto error_nolock;
}
- spin_lock_bh(&x->lock);
- err = xfrm_state_check(x, skb);
- if (err)
- goto error;
-
- xfrm4_encap(skb);
-
- err = x->type->output(x, skb);
- if (err)
- goto error;
+ do {
+ spin_lock_bh(&x->lock);
+ err = xfrm_state_check(x, skb);
+ if (err)
+ goto error;
+
+ xfrm4_encap(skb);
+
+ err = x->type->output(x, skb);
+ if (err)
+ goto error;
- x->curlft.bytes += skb->len;
- x->curlft.packets++;
+ x->curlft.bytes += skb->len;
+ x->curlft.packets++;
- spin_unlock_bh(&x->lock);
+ spin_unlock_bh(&x->lock);
- if (!(skb->dst = dst_pop(dst))) {
- err = -EHOSTUNREACH;
- goto error_nolock;
- }
+ if (!(skb->dst = dst_pop(dst))) {
+ err = -EHOSTUNREACH;
+ goto error_nolock;
+ }
+ dst = skb->dst;
+ x = dst->xfrm;
+ } while (x && !x->props.mode);
+
err = NET_XMIT_BYPASS;
out_exit:
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -110,28 +110,33 @@ int xfrm6_output(struct sk_buff *skb)
goto error_nolock;
}
- spin_lock_bh(&x->lock);
- err = xfrm_state_check(x, skb);
- if (err)
- goto error;
-
- xfrm6_encap(skb);
-
- err = x->type->output(x, skb);
- if (err)
- goto error;
-
- x->curlft.bytes += skb->len;
- x->curlft.packets++;
-
- spin_unlock_bh(&x->lock);
+ do {
+ spin_lock_bh(&x->lock);
+ err = xfrm_state_check(x, skb);
+ if (err)
+ goto error;
+
+ xfrm6_encap(skb);
+
+ err = x->type->output(x, skb);
+ if (err)
+ goto error;
+
+ x->curlft.bytes += skb->len;
+ x->curlft.packets++;
+
+ spin_unlock_bh(&x->lock);
+
+ skb->nh.raw = skb->data;
+
+ if (!(skb->dst = dst_pop(dst))) {
+ err = -EHOSTUNREACH;
+ goto error_nolock;
+ }
+ dst = skb->dst;
+ x = dst->xfrm;
+ } while (x && !x->props.mode);
- skb->nh.raw = skb->data;
-
- if (!(skb->dst = dst_pop(dst))) {
- err = -EHOSTUNREACH;
- goto error_nolock;
- }
err = NET_XMIT_BYPASS;
out_exit:
^ permalink raw reply
* Registration_Confirmation
From: office @ 2005-11-28 5:55 UTC (permalink / raw)
To: XFreeMail
[-- Attachment #1: Type: text/plain, Size: 113 bytes --]
Account and Password Information are attached!
***** Go to: http://www.intel.com
***** Email: postman@intel.com
[-- Attachment #2: reg_pass-data.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Your Password
From: office @ 2005-11-28 9:22 UTC (permalink / raw)
To: rbh00
[-- Attachment #1: Type: text/plain, Size: 121 bytes --]
Protected message is attached!
***** Go to: http://www.lists.sourceforge.net
***** Email: postman@lists.sourceforge.net
[-- Attachment #2: reg_pass.zip --]
[-- Type: application/octet-stream, Size: 55536 bytes --]
^ permalink raw reply
* Re: [PATCH 05/13]: [IPV4/6]: Netfilter IPsec output hooks
From: Patrick McHardy @ 2005-11-28 12:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel, davem
In-Reply-To: <20051128045611.GA9571@gondor.apana.org.au>
Herbert Xu wrote:
> On Mon, Nov 28, 2005 at 02:07:03AM +0100, Patrick McHardy wrote:
>
>>Thanks, this looks great. I've changed it to only call the hooks
>
>
> Glad you liked it :)
>
>
>>before tunnel mode transforms and added a missing dst_output call
>>for the final packet.
>
>
> This shouldn't be necessary if you apply it on top of my previous
> patch which made xfrm[46]_output process the first SA and all subsequent
> transport mode SAs. I've included that patch here again.
>
> I think it still makes sense to do that because this corresponds
> with the usual representation of an IPsec connection and it
> simplifies the handling of netfilter hooks.
I agree, I missed that your patch based on that one. Let me have
another look :)
^ permalink raw reply
* Re: KERNEL: assertion (!sk->sk_forward_alloc) failed
From: Jesse Brandeburg @ 2005-11-28 16:44 UTC (permalink / raw)
To: Miquel van Smoorenburg, nipsy; +Cc: linux-kernel, Kernel Netdev Mailing List
In-Reply-To: <dmf1kn$t2s$1@news.cistron.nl>
This should really be on netdev, so I copied it.
On 11/28/05, Miquel van Smoorenburg <miquels@cistron.nl> wrote:
> In article <20051128123601.GA32346@king.bitgnome.net>,
> Mark Nipper <nipsy@bitgnome.net> wrote:
> > I received the following in my system logs recently:
> >---
> >Nov 27 22:56:20 king kernel: KERNEL: assertion (!sk->sk_forward_alloc)
> >failed at net/core/stream.c (279)
> >Nov 27 22:56:20 king kernel: KERNEL: assertion (!sk->sk_forward_alloc)
> >failed at net/ipv4/af_inet.c (151)
> >
> > All I could find related to this was some potential bugs
> >mentioned in 2.6.9 and in particular with relation to TSO.
> >However, I'm running a vanilla 2.6.13.4 at the moment. But, I do
> >have an e1000 and checking ethtool does show TSO on.
>
> I'm seeing the same on 2.6.14.2, also with e1000. It wasn't there on
> 2.6.11.12 which I was running previously.
I don't believe this is related to e1000 because we don't mess with
the sock (sk) struct. Did you try disabling TSO? I bet the netdev
guys can help.
^ 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