* [PATCH net v2 5/8] forcedeth: Add messages to indicate using MSI or MSI-X
From: David Decotigny @ 2011-11-04 1:41 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Ian Campbell, Eric Dumazet, Jeff Kirsher,
Jiri Pirko, Joe Perches, Szymon Janc, Mike Ditto, David Decotigny
In-Reply-To: <cover.1320369398.git.david.decotigny@google.com>
From: Mike Ditto <mditto@google.com>
This adds a few debug messages to indicate whether PCIe interrupts are
signaled with MSI or MSI-X.
Signed-off-by: David Decotigny <david.decotigny@google.com>
---
drivers/net/ethernet/nvidia/forcedeth.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index 4a45a46..0af12a8 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -3761,6 +3761,7 @@ static int nv_request_irq(struct net_device *dev, int intr_test)
writel(0, base + NvRegMSIXMap0);
writel(0, base + NvRegMSIXMap1);
}
+ netdev_info(dev, "MSI-X enabled\n");
}
}
if (ret != 0 && np->msi_flags & NV_MSI_CAPABLE) {
@@ -3782,6 +3783,7 @@ static int nv_request_irq(struct net_device *dev, int intr_test)
writel(0, base + NvRegMSIMap1);
/* enable msi vector 0 */
writel(NVREG_MSI_VECTOR_0_ENABLED, base + NvRegMSIIrqMask);
+ netdev_info(dev, "MSI enabled\n");
}
}
if (ret != 0) {
--
1.7.3.1
^ permalink raw reply related
* [PATCH net v2 4/8] forcedeth: Acknowledge only interrupts that are being processed
From: David Decotigny @ 2011-11-04 1:41 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Ian Campbell, Eric Dumazet, Jeff Kirsher,
Jiri Pirko, Joe Perches, Szymon Janc, Mike Ditto, David Decotigny
In-Reply-To: <cover.1320369398.git.david.decotigny@google.com>
From: Mike Ditto <mditto@google.com>
This is to avoid a race, accidentally acknowledging an interrupt that
we didn't notice and won't immediately process. This is based solely
on code inspection; it is not known if there was an actual bug here.
Signed-off-by: David Decotigny <david.decotigny@google.com>
---
drivers/net/ethernet/nvidia/forcedeth.c | 13 ++++++++-----
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index 375b03b..4a45a46 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -3419,7 +3419,8 @@ static irqreturn_t nv_nic_irq_tx(int foo, void *data)
for (i = 0;; i++) {
events = readl(base + NvRegMSIXIrqStatus) & NVREG_IRQ_TX_ALL;
- writel(NVREG_IRQ_TX_ALL, base + NvRegMSIXIrqStatus);
+ writel(events, base + NvRegMSIXIrqStatus);
+ netdev_dbg(dev, "tx irq events: %08x\n", events);
if (!(events & np->irqmask))
break;
@@ -3530,7 +3531,8 @@ static irqreturn_t nv_nic_irq_rx(int foo, void *data)
for (i = 0;; i++) {
events = readl(base + NvRegMSIXIrqStatus) & NVREG_IRQ_RX_ALL;
- writel(NVREG_IRQ_RX_ALL, base + NvRegMSIXIrqStatus);
+ writel(events, base + NvRegMSIXIrqStatus);
+ netdev_dbg(dev, "rx irq events: %08x\n", events);
if (!(events & np->irqmask))
break;
@@ -3574,7 +3576,8 @@ static irqreturn_t nv_nic_irq_other(int foo, void *data)
for (i = 0;; i++) {
events = readl(base + NvRegMSIXIrqStatus) & NVREG_IRQ_OTHER;
- writel(NVREG_IRQ_OTHER, base + NvRegMSIXIrqStatus);
+ writel(events, base + NvRegMSIXIrqStatus);
+ netdev_dbg(dev, "irq events: %08x\n", events);
if (!(events & np->irqmask))
break;
@@ -3638,10 +3641,10 @@ static irqreturn_t nv_nic_irq_test(int foo, void *data)
if (!(np->msi_flags & NV_MSI_X_ENABLED)) {
events = readl(base + NvRegIrqStatus) & NVREG_IRQSTAT_MASK;
- writel(NVREG_IRQ_TIMER, base + NvRegIrqStatus);
+ writel(events & NVREG_IRQ_TIMER, base + NvRegIrqStatus);
} else {
events = readl(base + NvRegMSIXIrqStatus) & NVREG_IRQSTAT_MASK;
- writel(NVREG_IRQ_TIMER, base + NvRegMSIXIrqStatus);
+ writel(events & NVREG_IRQ_TIMER, base + NvRegMSIXIrqStatus);
}
pci_push(base);
if (!(events & NVREG_IRQ_TIMER))
--
1.7.3.1
^ permalink raw reply related
* [PATCH net v2 3/8] forcedeth: allow to silence tx_timeout debug messages
From: David Decotigny @ 2011-11-04 1:41 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Ian Campbell, Eric Dumazet, Jeff Kirsher,
Jiri Pirko, Joe Perches, Szymon Janc, Sameer Nanda,
David Decotigny
In-Reply-To: <cover.1320369398.git.david.decotigny@google.com>
From: Sameer Nanda <snanda@google.com>
This adds a new module parameter "debug_tx_timeout" to silence most
debug messages in case of TX timeout. These messages don't provide a
signal/noise ratio high enough for production systems and, with ~30kB
logged each time, they tend to add to a cascade effect if the system
is already under stress (memory pressure, disk, etc.).
By default, the parameter is clear, meaning the debug messages are not
displayed.
Signed-off-by: David Decotigny <david.decotigny@google.com>
---
drivers/net/ethernet/nvidia/forcedeth.c | 98 ++++++++++++++++++-------------
1 files changed, 57 insertions(+), 41 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index c82a3c7..375b03b 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -894,6 +894,11 @@ enum {
static int dma_64bit = NV_DMA_64BIT_ENABLED;
/*
+ * Debug output control for tx_timeout
+ */
+static bool debug_tx_timeout = false;
+
+/*
* Crossover Detection
* Realtek 8201 phy + some OEM boards do not work properly.
*/
@@ -2481,56 +2486,64 @@ static void nv_tx_timeout(struct net_device *dev)
u32 status;
union ring_type put_tx;
int saved_tx_limit;
- int i;
if (np->msi_flags & NV_MSI_X_ENABLED)
status = readl(base + NvRegMSIXIrqStatus) & NVREG_IRQSTAT_MASK;
else
status = readl(base + NvRegIrqStatus) & NVREG_IRQSTAT_MASK;
- netdev_info(dev, "Got tx_timeout. irq: %08x\n", status);
+ netdev_warn(dev, "Got tx_timeout. irq status: %08x\n", status);
- netdev_info(dev, "Ring at %lx\n", (unsigned long)np->ring_addr);
- netdev_info(dev, "Dumping tx registers\n");
- for (i = 0; i <= np->register_size; i += 32) {
- netdev_info(dev,
- "%3x: %08x %08x %08x %08x %08x %08x %08x %08x\n",
- i,
- readl(base + i + 0), readl(base + i + 4),
- readl(base + i + 8), readl(base + i + 12),
- readl(base + i + 16), readl(base + i + 20),
- readl(base + i + 24), readl(base + i + 28));
- }
- netdev_info(dev, "Dumping tx ring\n");
- for (i = 0; i < np->tx_ring_size; i += 4) {
- if (!nv_optimized(np)) {
- netdev_info(dev,
- "%03x: %08x %08x // %08x %08x // %08x %08x // %08x %08x\n",
- i,
- le32_to_cpu(np->tx_ring.orig[i].buf),
- le32_to_cpu(np->tx_ring.orig[i].flaglen),
- le32_to_cpu(np->tx_ring.orig[i+1].buf),
- le32_to_cpu(np->tx_ring.orig[i+1].flaglen),
- le32_to_cpu(np->tx_ring.orig[i+2].buf),
- le32_to_cpu(np->tx_ring.orig[i+2].flaglen),
- le32_to_cpu(np->tx_ring.orig[i+3].buf),
- le32_to_cpu(np->tx_ring.orig[i+3].flaglen));
- } else {
+ if (unlikely(debug_tx_timeout)) {
+ int i;
+
+ netdev_info(dev, "Ring at %lx\n", (unsigned long)np->ring_addr);
+ netdev_info(dev, "Dumping tx registers\n");
+ for (i = 0; i <= np->register_size; i += 32) {
netdev_info(dev,
- "%03x: %08x %08x %08x // %08x %08x %08x // %08x %08x %08x // %08x %08x %08x\n",
+ "%3x: %08x %08x %08x %08x "
+ "%08x %08x %08x %08x\n",
i,
- le32_to_cpu(np->tx_ring.ex[i].bufhigh),
- le32_to_cpu(np->tx_ring.ex[i].buflow),
- le32_to_cpu(np->tx_ring.ex[i].flaglen),
- le32_to_cpu(np->tx_ring.ex[i+1].bufhigh),
- le32_to_cpu(np->tx_ring.ex[i+1].buflow),
- le32_to_cpu(np->tx_ring.ex[i+1].flaglen),
- le32_to_cpu(np->tx_ring.ex[i+2].bufhigh),
- le32_to_cpu(np->tx_ring.ex[i+2].buflow),
- le32_to_cpu(np->tx_ring.ex[i+2].flaglen),
- le32_to_cpu(np->tx_ring.ex[i+3].bufhigh),
- le32_to_cpu(np->tx_ring.ex[i+3].buflow),
- le32_to_cpu(np->tx_ring.ex[i+3].flaglen));
+ readl(base + i + 0), readl(base + i + 4),
+ readl(base + i + 8), readl(base + i + 12),
+ readl(base + i + 16), readl(base + i + 20),
+ readl(base + i + 24), readl(base + i + 28));
+ }
+ netdev_info(dev, "Dumping tx ring\n");
+ for (i = 0; i < np->tx_ring_size; i += 4) {
+ if (!nv_optimized(np)) {
+ netdev_info(dev,
+ "%03x: %08x %08x // %08x %08x "
+ "// %08x %08x // %08x %08x\n",
+ i,
+ le32_to_cpu(np->tx_ring.orig[i].buf),
+ le32_to_cpu(np->tx_ring.orig[i].flaglen),
+ le32_to_cpu(np->tx_ring.orig[i+1].buf),
+ le32_to_cpu(np->tx_ring.orig[i+1].flaglen),
+ le32_to_cpu(np->tx_ring.orig[i+2].buf),
+ le32_to_cpu(np->tx_ring.orig[i+2].flaglen),
+ le32_to_cpu(np->tx_ring.orig[i+3].buf),
+ le32_to_cpu(np->tx_ring.orig[i+3].flaglen));
+ } else {
+ netdev_info(dev,
+ "%03x: %08x %08x %08x "
+ "// %08x %08x %08x "
+ "// %08x %08x %08x "
+ "// %08x %08x %08x\n",
+ i,
+ le32_to_cpu(np->tx_ring.ex[i].bufhigh),
+ le32_to_cpu(np->tx_ring.ex[i].buflow),
+ le32_to_cpu(np->tx_ring.ex[i].flaglen),
+ le32_to_cpu(np->tx_ring.ex[i+1].bufhigh),
+ le32_to_cpu(np->tx_ring.ex[i+1].buflow),
+ le32_to_cpu(np->tx_ring.ex[i+1].flaglen),
+ le32_to_cpu(np->tx_ring.ex[i+2].bufhigh),
+ le32_to_cpu(np->tx_ring.ex[i+2].buflow),
+ le32_to_cpu(np->tx_ring.ex[i+2].flaglen),
+ le32_to_cpu(np->tx_ring.ex[i+3].bufhigh),
+ le32_to_cpu(np->tx_ring.ex[i+3].buflow),
+ le32_to_cpu(np->tx_ring.ex[i+3].flaglen));
+ }
}
}
@@ -6016,6 +6029,9 @@ module_param(phy_cross, int, 0);
MODULE_PARM_DESC(phy_cross, "Phy crossover detection for Realtek 8201 phy is enabled by setting to 1 and disabled by setting to 0.");
module_param(phy_power_down, int, 0);
MODULE_PARM_DESC(phy_power_down, "Power down phy and disable link when interface is down (1), or leave phy powered up (0).");
+module_param(debug_tx_timeout, bool, 0);
+MODULE_PARM_DESC(debug_tx_timeout,
+ "Dump tx related registers and ring when tx_timeout happens");
MODULE_AUTHOR("Manfred Spraul <manfred@colorfullife.com>");
MODULE_DESCRIPTION("Reverse Engineered nForce ethernet driver");
--
1.7.3.1
^ permalink raw reply related
* [PATCH net v2 2/8] forcedeth: new ethtool stat "tx_timeout" to account for tx_timeouts
From: David Decotigny @ 2011-11-04 1:41 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Ian Campbell, Eric Dumazet, Jeff Kirsher,
Jiri Pirko, Joe Perches, Szymon Janc, Sameer Nanda,
David Decotigny
In-Reply-To: <cover.1320369398.git.david.decotigny@google.com>
From: Sameer Nanda <snanda@google.com>
This change publishes a new ethtool stats: tx_timeout that counts the
number of times the tx_timeout callback was triggered.
Signed-off-by: David Decotigny <david.decotigny@google.com>
---
drivers/net/ethernet/nvidia/forcedeth.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index 64b1c7c..c82a3c7 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -633,6 +633,7 @@ static const struct nv_ethtool_str nv_estats_str[] = {
{ "rx_packets" },
{ "rx_errors_total" },
{ "tx_errors_total" },
+ { "tx_timeout" },
/* version 2 stats */
{ "tx_deferral" },
@@ -673,6 +674,7 @@ struct nv_ethtool_stats {
u64 rx_packets;
u64 rx_errors_total;
u64 tx_errors_total;
+ u64 tx_timeout;
/* version 2 stats */
u64 tx_deferral;
@@ -2534,6 +2536,8 @@ static void nv_tx_timeout(struct net_device *dev)
spin_lock_irq(&np->lock);
+ np->estats.tx_timeout++;
+
/* 1) stop tx engine */
nv_stop_tx(dev);
--
1.7.3.1
^ permalink raw reply related
* [PATCH net v2 1/8] forcedeth: Improve stats counters
From: David Decotigny @ 2011-11-04 1:41 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Ian Campbell, Eric Dumazet, Jeff Kirsher,
Jiri Pirko, Joe Perches, Szymon Janc, Mandeep Baines,
David Decotigny
In-Reply-To: <cover.1320369398.git.david.decotigny@google.com>
From: Mandeep Baines <msb@google.com>
Rx byte count was off; instead use the hardware's count. Tx packet
count was counting pre-TSO packets; instead count on-the-wire packets.
Report hardware dropped frame count as rx_fifo_errors.
- The count of transmitted packets reported by the forcedeth driver
reports pre-TSO (TCP Segmentation Offload) packet counts and not the
count of the number of packets sent on the wire. This change fixes
the forcedeth driver to report the correct count. Fixed the code by
copying the count stored in the NIC H/W to the value reported by the
driver.
- Count rx_drop_frame errors as rx_fifo_errors:
We see a lot of rx_drop_frame errors if we disable the rx bottom-halves
for too long. Normally, rx_fifo_errors would be counted in this case.
The rx_drop_frame error count is private to forcedeth and is not
reported by ifconfig or sysfs. The rx_fifo_errors count is currently
unused in the forcedeth driver. It is reported by ifconfig as overruns.
This change reports rx_drop_frame errors as rx_fifo_errors.
Signed-off-by: David Decotigny <david.decotigny@google.com>
---
drivers/net/ethernet/nvidia/forcedeth.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index 1e37eb9..64b1c7c 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -1682,6 +1682,7 @@ static void nv_get_hw_stats(struct net_device *dev)
np->estats.tx_pause += readl(base + NvRegTxPause);
np->estats.rx_pause += readl(base + NvRegRxPause);
np->estats.rx_drop_frame += readl(base + NvRegRxDropFrame);
+ np->estats.rx_errors_total += np->estats.rx_drop_frame;
}
if (np->driver_data & DEV_HAS_STATISTICS_V3) {
@@ -1706,11 +1707,14 @@ static struct net_device_stats *nv_get_stats(struct net_device *dev)
nv_get_hw_stats(dev);
/* copy to net_device stats */
+ dev->stats.tx_packets = np->estats.tx_packets;
+ dev->stats.rx_bytes = np->estats.rx_bytes;
dev->stats.tx_bytes = np->estats.tx_bytes;
dev->stats.tx_fifo_errors = np->estats.tx_fifo_errors;
dev->stats.tx_carrier_errors = np->estats.tx_carrier_errors;
dev->stats.rx_crc_errors = np->estats.rx_crc_errors;
dev->stats.rx_over_errors = np->estats.rx_over_errors;
+ dev->stats.rx_fifo_errors = np->estats.rx_drop_frame;
dev->stats.rx_errors = np->estats.rx_errors_total;
dev->stats.tx_errors = np->estats.tx_errors_total;
}
--
1.7.3.1
^ permalink raw reply related
* [PATCH net v2 0/8] forcedeth: minor fixes for stats, rmmod, sparse
From: David Decotigny @ 2011-11-04 1:41 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: David S. Miller, Ian Campbell, Eric Dumazet, Jeff Kirsher,
Jiri Pirko, Joe Perches, Szymon Janc, David Decotigny
Here is the v2 of a forcedeth patch series I sent a few months
ago (... May).
Changes since v1:
- rebased on top of netdev tip
- do not repeat name of device in netdev_dbg
- do not completely mute TX timeout messages when debug_tx_timeout is
not set
- make debug_tx_timeout writable in /sys/module
I am re-submitting "expose module parameters in /sys/module" as it can
be useful in production and I was assured it doesn't add much memory
overhead by the sysfs maintainers.
Tested:
16-way x86_64 SMP, dual forcedeth
############################################
# Patch Set Summary:
David Decotigny (2):
forcedeth: expose module parameters in /sys/module
forcedeth: fix a few sparse warnings (variable shadowing)
Mandeep Baines (1):
forcedeth: Improve stats counters
Mike Ditto (2):
forcedeth: Acknowledge only interrupts that are being processed
forcedeth: Add messages to indicate using MSI or MSI-X
Salman Qazi (1):
forcedeth: Fix a race during rmmod of forcedeth
Sameer Nanda (2):
forcedeth: new ethtool stat "tx_timeout" to account for tx_timeouts
forcedeth: allow to silence tx_timeout debug messages
drivers/net/ethernet/nvidia/forcedeth.c | 182 +++++++++++++++++++------------
1 files changed, 110 insertions(+), 72 deletions(-)
--
1.7.3.1
^ permalink raw reply
* Offres emplois pour vous
From: duloiscarole @ 2011-11-04 0:48 UTC (permalink / raw)
To: netdev
Bonjour,
des nouveaux offres emplois pour vous http://www.universfreeads.com/emplois.php
..
^ permalink raw reply
* Re: [RFC PATCH 17/17] phy_device: Rename phy_start_aneg() to phy_start_link()
From: Andy Fleming @ 2011-11-03 22:51 UTC (permalink / raw)
To: Kyle Moffett
Cc: linux-doc, Stephen Hemminger, David Decotigny, devel,
Matt Carlson, Kuninori Morimoto, Alexey Dobriyan,
Lennert Buytenhek, Mike Frysinger, Michał Mirosław,
Michael Chan, Giuseppe Cavallaro, Nobuhiro Iwamatsu, John Crispin,
Richard Cochran, Ilya Yanok, netdev, Yoshihiro Shimoda,
Greg Kroah-Hartman, linux-kernel, Ralf Baechle,
Christian Dietrich
In-Reply-To: <1319144425-15547-18-git-send-email-Kyle.D.Moffett@boeing.com>
2011/10/20 Kyle Moffett <Kyle.D.Moffett@boeing.com>:
> The name of the "phy_start_aneg()" function is very confusing, because
> it also handles forced-mode (AUTONEG_DISABLE) links.
>
> Rename the function to phy_start_link() and fix up all users.
>
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
Sounds good to me.
Acked-by: Andy Fleming <afleming@freescale.com>
^ permalink raw reply
* Re: [RFC PATCH 06/17] phy_driver: Add and use phy_driver_[un]register_multiple()
From: Andy Fleming @ 2011-11-03 22:46 UTC (permalink / raw)
To: Kyle Moffett
Cc: linux-kernel, netdev, David S. Miller, Greg Dietsche,
Giuseppe Cavallaro, David Daney, Arnaud Patard, Grant Likely,
Baruch Siach, Stephen Hemminger, Lucas De Marchi,
Marc Kleine-Budde, Andrew Morton, Mike Frysinger
In-Reply-To: <1319144425-15547-7-git-send-email-Kyle.D.Moffett@boeing.com>
On Thu, Oct 20, 2011 at 4:00 PM, Kyle Moffett <Kyle.D.Moffett@boeing.com> wrote:
> Several of the PHY drivers are registering dozens of "phy_driver"
> structures at load-time, with different IDs and variations on methods.
> As a result, the error handling is exceptionally ugly.
>
> The "marvell" driver already uses an array of "struct phy_driver" and
> iterates over that to add the drivers, but even then its error handling
> contains a bug (it will not unregister array item 0 on failure).
>
> To resolve these problems, new functions phy_driver_register_multiple()
> and phy_driver_unregister_multiple() are added which take an array and a
> number of drivers and iterate over them internally.
>
> All of the PHY driver files which register more than one "phy_driver"
> are modified to use the new helpers. This is a sizable net removal of
> about 260 lines of code.
>
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
Let's try that again, sending to the list.
This is excellent!
Very much
Acked-by: Andy Fleming <afleming@freescale.com>
^ permalink raw reply
* Re: bridge: allow forwarding LLDP frames
From: Nick Carter @ 2011-11-03 22:17 UTC (permalink / raw)
To: Ed Swierk; +Cc: shemminger, davem, netdev
In-Reply-To: <20111017181207.06081E3280@meep>
On 17 October 2011 19:12, Ed Swierk <eswierk@bigswitch.com> wrote:
> LLDP frames have reserved destination MAC address 01-80-C2-00-00-0E,
> which by default are not forwarded by 802.1d-compliant bridges.
>
> In certain situations, like when creating a transparent link-layer
> relay between a pair of interfaces, it may be useful to configure a
> bridge interface to forward LLDP and other control frames in the
> 01-80-C2-00-00-xx range rather than filtering them.
>
> Stephen Hemminger's recent patch allows the user to set a sysfs
> attribute /sys/class/net/brX/bridge/group_fwd_mask to enable
> forwarding of normally filtered addresses, with certain exceptions.
> This patch eliminates the restriction on LLDP frames, allowing the
> user to override the default behavior of filtering them.
The reason the group fwd mask was introduced was to make the bridge
forward link local group addresses. This is non standards based
behaviour. The point of the group fwd mask is so that users can have
non standard bridging behaviour.
I don't understand why the recent commit includes blocking the user
from choosing to forward certain groups because it breaks standards ?
The default mask of 0 is standards based behaviour. If the user sets
it to anything other than 0 then they want non standards based
behaviour.
In my view the behaviour now is very confusing for the user. 802.1X
is allowed to be forwarded but LLDP forwarding is rejected ?
The group fwd mask should be allowed to be set to any value. This
would give flexible and predictable behaviour to the user.
I think we should assume users know the behaviour they require and
BR_GROUPFWD_RESTRICTED should be removed from the codebase.
Nick
>
> Signed-off-by: Ed Swierk <eswierk@bigswitch.com>
>
> ---
>
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index a248fe6..b016dd8 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -31,8 +31,8 @@
>
> /* Control of forwarding link local multicast */
> #define BR_GROUPFWD_DEFAULT 0
> -/* Don't allow forwarding control protocols like STP and LLDP */
> -#define BR_GROUPFWD_RESTRICTED 0x4007u
> +/* Don't allow forwarding control protocols like STP */
> +#define BR_GROUPFWD_RESTRICTED 0x0007u
>
> /* Path to usermode spanning tree program */
> #define BR_STP_PROG "/sbin/bridge-stp"
> --
> 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: [PATCH] MAINTAINERS: Add can-gw include to maintained files
From: David Miller @ 2011-11-03 22:12 UTC (permalink / raw)
To: socketcan; +Cc: netdev, linux-can
In-Reply-To: <4EB1AE31.3080305@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Wed, 02 Nov 2011 21:55:13 +0100
> Commit c1aabdf379bc2feeb0df7057ed5bad96f492133e (can-gw: add netlink based
> CAN routing) added a new include file that's neither referenced by any of
> the CAN maintainers.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied.
^ permalink raw reply
* Re: [PATCH] af_packet: de-inline some helper functions
From: David Miller @ 2011-11-03 22:12 UTC (permalink / raw)
To: olof; +Cc: netdev, loke.chetan
In-Reply-To: <20111102210049.GA3697@quad.lixom.net>
From: Olof Johansson <olof@lixom.net>
Date: Wed, 2 Nov 2011 14:00:49 -0700
> This popped some compiler errors due to mismatched prototypes. Just
> remove most manual inlines, the compiler should be able to figure out
> what makes sense to inline and not.
>
> net/packet/af_packet.c:252: warning: 'prb_curr_blk_in_use' declared inline after being called
> net/packet/af_packet.c:252: warning: previous declaration of 'prb_curr_blk_in_use' was here
> net/packet/af_packet.c:258: warning: 'prb_queue_frozen' declared inline after being called
> net/packet/af_packet.c:258: warning: previous declaration of 'prb_queue_frozen' was here
> net/packet/af_packet.c:248: warning: 'packet_previous_frame' declared inline after being called
> net/packet/af_packet.c:248: warning: previous declaration of 'packet_previous_frame' was here
> net/packet/af_packet.c:251: warning: 'packet_increment_head' declared inline after being called
> net/packet/af_packet.c:251: warning: previous declaration of 'packet_increment_head' was here
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> Cc: Chetan Loke <loke.chetan@gmail.com>
Looks good, applied, thanks Olof.
^ permalink raw reply
* Re: [PATCH] net: Add back alignment for size for __alloc_skb
From: David Miller @ 2011-11-03 22:09 UTC (permalink / raw)
To: tony; +Cc: eric.dumazet, netdev, linux-kernel, linux-omap
In-Reply-To: <20111102234028.GP31337@atomide.com>
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 2 Nov 2011 16:40:28 -0700
> Subject: [PATCH] net: Add back alignment for size for __alloc_skb
Applied, thanks a lot!
^ permalink raw reply
* Re: Linux 3.1-rc9
From: David Miller @ 2011-11-03 22:07 UTC (permalink / raw)
To: sim
Cc: eric.dumazet, tglx, a.p.zijlstra, torvalds, linux-kernel, davej,
schwidefsky, mingo, netdev, bazsi, hidden
In-Reply-To: <20111103005255.GL5971@hostway.ca>
From: Simon Kirby <sim@hostway.ca>
Date: Wed, 2 Nov 2011 17:52:55 -0700
>> [PATCH] net: add missing bh_unlock_sock() calls
...
> Tested-by: Simon Kirby <sim@hostway.ca>
>
> I tried many times, with route unreach/blackhole, and could not reproduce
> the issue with this patch applied.
Applied and queued up for -stable, thanks everyone!
^ permalink raw reply
* Re: PROBLEM: pppol2tp over pppoe NULL pointer dereference
From: David Miller @ 2011-11-03 22:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: spiked.yar, netdev
In-Reply-To: <1320310064.2344.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 03 Nov 2011 09:47:44 +0100
> Le jeudi 03 novembre 2011 à 02:35 +0400, Misha Labjuk a écrit :
>> Thanks!! Panic disappeared.
>>
>
> Here is the official patch submission again (not mangled this time),
> thanks !
>
> [PATCH] l2tp: fix race in l2tp_recv_dequeue()
Applied and queued up for -stable, thanks!
^ permalink raw reply
* [PATCH] fsl_pq_mdio: Clean up tbi address configuration
From: Andy Fleming @ 2011-11-03 21:54 UTC (permalink / raw)
To: davem; +Cc: netdev
The code for setting the address of the internal TBI PHY was
convoluted enough without a maze of ifdefs. Clean it up a bit
so we allow the logic to fail down to -ENODEV at the end of
the if/else ladder, rather than using ifdefs to repeat the same
failure code over and over.
Also, remove the support for the auto-configuration. I'm not aware of
anyone using it, and it ends up using the bus mutex before it's been
initialized.
Signed-off-by: Andy Fleming <afleming@freescale.com>
---
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 53 ++++----------------------
1 files changed, 8 insertions(+), 45 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
index 52f4e8a..4d9f84b 100644
--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -183,28 +183,10 @@ void fsl_pq_mdio_bus_name(char *name, struct device_node *np)
}
EXPORT_SYMBOL_GPL(fsl_pq_mdio_bus_name);
-/* Scan the bus in reverse, looking for an empty spot */
-static int fsl_pq_mdio_find_free(struct mii_bus *new_bus)
-{
- int i;
-
- for (i = PHY_MAX_ADDR; i > 0; i--) {
- u32 phy_id;
-
- if (get_phy_id(new_bus, i, &phy_id))
- return -1;
-
- if (phy_id == 0xffffffff)
- break;
- }
-
- return i;
-}
-
-#if defined(CONFIG_GIANFAR) || defined(CONFIG_GIANFAR_MODULE)
static u32 __iomem *get_gfar_tbipa(struct fsl_pq_mdio __iomem *regs, struct device_node *np)
{
+#if defined(CONFIG_GIANFAR) || defined(CONFIG_GIANFAR_MODULE)
struct gfar __iomem *enet_regs;
/*
@@ -220,15 +202,15 @@ static u32 __iomem *get_gfar_tbipa(struct fsl_pq_mdio __iomem *regs, struct devi
} else if (of_device_is_compatible(np, "fsl,etsec2-mdio") ||
of_device_is_compatible(np, "fsl,etsec2-tbi")) {
return of_iomap(np, 1);
- } else
- return NULL;
-}
+ }
#endif
+ return NULL;
+}
-#if defined(CONFIG_UCC_GETH) || defined(CONFIG_UCC_GETH_MODULE)
static int get_ucc_id_for_range(u64 start, u64 end, u32 *ucc_id)
{
+#if defined(CONFIG_UCC_GETH) || defined(CONFIG_UCC_GETH_MODULE)
struct device_node *np = NULL;
int err = 0;
@@ -261,9 +243,10 @@ static int get_ucc_id_for_range(u64 start, u64 end, u32 *ucc_id)
return err;
else
return -EINVAL;
-}
+#else
+ return -ENODEV;
#endif
-
+}
static int fsl_pq_mdio_probe(struct platform_device *ofdev)
{
@@ -339,19 +322,13 @@ static int fsl_pq_mdio_probe(struct platform_device *ofdev)
of_device_is_compatible(np, "fsl,etsec2-mdio") ||
of_device_is_compatible(np, "fsl,etsec2-tbi") ||
of_device_is_compatible(np, "gianfar")) {
-#if defined(CONFIG_GIANFAR) || defined(CONFIG_GIANFAR_MODULE)
tbipa = get_gfar_tbipa(regs, np);
if (!tbipa) {
err = -EINVAL;
goto err_free_irqs;
}
-#else
- err = -ENODEV;
- goto err_free_irqs;
-#endif
} else if (of_device_is_compatible(np, "fsl,ucc-mdio") ||
of_device_is_compatible(np, "ucc_geth_phy")) {
-#if defined(CONFIG_UCC_GETH) || defined(CONFIG_UCC_GETH_MODULE)
u32 id;
static u32 mii_mng_master;
@@ -364,10 +341,6 @@ static int fsl_pq_mdio_probe(struct platform_device *ofdev)
mii_mng_master = id;
ucc_set_qe_mux_mii_mng(id - 1);
}
-#else
- err = -ENODEV;
- goto err_free_irqs;
-#endif
} else {
err = -ENODEV;
goto err_free_irqs;
@@ -386,16 +359,6 @@ static int fsl_pq_mdio_probe(struct platform_device *ofdev)
}
if (tbiaddr == -1) {
- out_be32(tbipa, 0);
-
- tbiaddr = fsl_pq_mdio_find_free(new_bus);
- }
-
- /*
- * We define TBIPA at 0 to be illegal, opting to fail for boards that
- * have PHYs at 1-31, rather than change tbipa and rescan.
- */
- if (tbiaddr == 0) {
err = -EBUSY;
goto err_free_irqs;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] tg3: fix error handling in tg3_open
From: Akinobu Mita @ 2011-11-03 21:23 UTC (permalink / raw)
To: Matt Carlson; +Cc: netdev@vger.kernel.org, David S. Miller, Michael Chan
In-Reply-To: <20111103191953.GA11186@mcarlson.broadcom.com>
2011/11/4 Matt Carlson <mcarlson@broadcom.com>:
> On Thu, Nov 03, 2011 at 03:36:43AM -0700, Akinobu Mita wrote:
>> If one of the request_irq calls fails in tg3_open, all interrupts
>> allocated with request_irq should be freed before returning error.
>>
>> But it accidentally attempts to free the same invalid IRQ repeatedly.
>
> Hi Akinobu. I have a similar patch under internal review at this very
> minute. The patch I have does a minor additional cleanup. (It moves
> the 'goto err_out2' inside the 'if (err)' block.) Is it O.K.
> with you to add your SOB to my patch instead?
Sounds good. Could you send the patch after finishing your review?
^ permalink raw reply
* Re: [PATCH] tg3: fix error handling in tg3_open
From: Matt Carlson @ 2011-11-03 19:19 UTC (permalink / raw)
To: Akinobu Mita
Cc: netdev@vger.kernel.org, David S. Miller, Matthew Carlson,
Michael Chan
In-Reply-To: <1320316603-8355-1-git-send-email-akinobu.mita@gmail.com>
On Thu, Nov 03, 2011 at 03:36:43AM -0700, Akinobu Mita wrote:
> If one of the request_irq calls fails in tg3_open, all interrupts
> allocated with request_irq should be freed before returning error.
>
> But it accidentally attempts to free the same invalid IRQ repeatedly.
Hi Akinobu. I have a similar patch under internal review at this very
minute. The patch I have does a minor additional cleanup. (It moves
the 'goto err_out2' inside the 'if (err)' block.) Is it O.K.
with you to add your SOB to my patch instead?
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Matt Carlson <mcarlson@broadcom.com>
> Cc: Michael Chan <mchan@broadcom.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> ---
> drivers/net/ethernet/broadcom/tg3.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
> index 161cbbb..13c4054 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -9674,8 +9674,10 @@ static int tg3_open(struct net_device *dev)
> struct tg3_napi *tnapi = &tp->napi[i];
> err = tg3_request_irq(tp, i);
> if (err) {
> - for (i--; i >= 0; i--)
> + for (i--; i >= 0; i--) {
> + tnapi = &tp->napi[i];
> free_irq(tnapi->irq_vec, tnapi);
> + }
> break;
> }
> }
> --
> 1.7.4.4
>
>
^ permalink raw reply
* Re: [PATCH ethtool 00/21] ethtool refactoring and misc changes
From: Ben Hutchings @ 2011-11-03 19:17 UTC (permalink / raw)
To: netdev; +Cc: linux-net-drivers
In-Reply-To: <1320186901.2758.30.camel@bwh-desktop>
I've pushed these changes, minus number 20, plus some additions
to .gitignore.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] ipv4: fix ipsec forward performance regression
From: Kim Phillips @ 2011-11-03 18:58 UTC (permalink / raw)
To: David Miller; +Cc: stable, eric.dumazet, zheng.z.yan, netdev
In-Reply-To: <20111101.203430.110242050755204948.davem@davemloft.net>
On Tue, 1 Nov 2011 20:34:30 -0400
David Miller <davem@davemloft.net> wrote:
> From: Kim Phillips <kim.phillips@freescale.com>
> Date: Tue, 1 Nov 2011 18:50:22 -0500
>
> > -stable maintainers, please consider the following two upstream
> > commits for inclusion in upcoming v3.0.x [1] stable releases:
>
> I submit networking stable fixes as needed, so please make such
> requests to me.
>
> I haven't submitted this change yet because I want it to sit a bit
> longer in Linus's tree to make sure there aren't any unwanted
> side-effects.
I see b732339 (ipv4: fix ipsec forward performance regression) has
been added to the 3.0- and 3.1-stable trees.
b732339 increases IPSec fwding performance from 0.2kpps to ~3.5kpps.
However, adding upstream commit aa1c366 (net: Handle different key
sizes between address families in flow cache) brings performance
back up to 2.6.38 levels, i.e., ~44kpps.
So can aa1c366 also be queued to the v2.6.39 and v3.0 stable
trees?
Thanks,
Kim
^ permalink raw reply
* Re: [PATCH] r8169: Fix WOL in power down case
From: Francois Romieu @ 2011-11-03 18:12 UTC (permalink / raw)
To: Stefan Becker; +Cc: netdev
In-Reply-To: <CAOJ2eMcFbt9zkA9-uq20OUs1r3Ee6jo=jbEJ7RP87OCxu5XJjA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
(Stefan, please keep the Cc:)
Stefan Becker <chemobejk@gmail.com> :
> On Thu, Nov 3, 2011 at 1:08 AM, Francois Romieu <romieu@fr.zoreil.com>wrote:
> > Stefan Becker <chemobejk@gmail.com> :
[...]
> > Plain power down, not suspend/resume ?
>
> Yes, the system executes "shutdown -h now" (S5?) after arming the watchdog
> that executes the etherwake command at the appointed time.
Thanks for the clarification.
[...]
> I've installed the previously working kernel from F15. Luckily it works
> with the Fedora 16 user space. With that kernel WoL works again.
>
> I can't check right now, but it should be
>
> kernel-2.6.40.6.-0.fc15.i686.rpm<http://koji.fedoraproject.org/koji/buildinfo?buildID=266719>
Ok.
Can you build the attached driver with your 3.1.x Fedora kernel ?
The diff is attached as well if the lack of gpg signature makes you nervous.
If the patch works, the regression almost surely dates back to
d4ed95d796e5126bba51466dc07e287cebc8bd19.
--
Ueimor
[-- Attachment #2: makefile_and_r8169.tgz --]
[-- Type: application/x-gzip, Size: 32425 bytes --]
[-- Attachment #3: r8169-more-rxconfig-bits.patch --]
[-- Type: text/plain, Size: 489 bytes --]
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 6d657ca..1fa2e80 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -3321,6 +3321,10 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
void __iomem *ioaddr = tp->mmio_addr;
switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_19:
+ case RTL_GIGA_MAC_VER_20:
+ case RTL_GIGA_MAC_VER_21:
+ case RTL_GIGA_MAC_VER_22:
case RTL_GIGA_MAC_VER_29:
case RTL_GIGA_MAC_VER_30:
case RTL_GIGA_MAC_VER_32:
^ permalink raw reply related
* Re: [PATCH] r8169: Fix WOL in power down case
From: Stefan Becker @ 2011-11-03 17:27 UTC (permalink / raw)
To: netdev
In-Reply-To: <20111102230827.GA8974@electric-eye.fr.zoreil.com>
Francois Romieu <romieu <at> fr.zoreil.com> writes:
>
> Plain power down, not suspend/resume ?
Plain power down, i.e. the system uses "shutdown -h now".
> However I am almost sure the regression would come from a different commit
> and I'd rather identify it. Can you narrow the kernel version a bit ?
> Your vendor's kernel identifier before regression would be a good start.
Here are my test results for vanilla Linux kernel sources, "defconfig +
CONFIG_EXT4_FS=y" and Fedora 16 user space:
Commit WoL
v3.1 BROKEN
92fc43b4159 BROKEN
4f6b00e5f13 WORKS (== 92fc43b4159^)
v3.0 WORKS
So WoL for my HW is broken by the same commit 92fc43b4159.
Regards,
Stefan
^ permalink raw reply
* RE: [PATCH] staging: hv: move hv_netvsc into drivers/net directory
From: Haiyang Zhang @ 2011-11-03 16:30 UTC (permalink / raw)
To: NetDev, linux-kernel@vger.kernel.org,
devel@linuxdriverproject.org, "virtualization@lists.os
Cc: gregkh@suse.de, Stephen Hemminger, davem@davemloft.net,
Haiyang Zhang, KY Srinivasan, Mike Sterling
In-Reply-To: <1318624485-23865-1-git-send-email-haiyangz@microsoft.com>
> -----Original Message-----
> From: Haiyang Zhang [mailto:haiyangz@microsoft.com]
> Sent: Friday, October 14, 2011 4:35 PM
> To: Haiyang Zhang; KY Srinivasan; gregkh@suse.de; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org
> Cc: Mike Sterling; NetDev
> Subject: [PATCH] staging: hv: move hv_netvsc into drivers/net
> directory
>
> hv_netvsc has been reviewed on netdev mailing list on 6/09/2011.
> All recommended changes have been made. We are requesting to move
> it from staging area into drivers/net directory.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Signed-off-by: KY Srinivasan <kys@microsoft.com>
> Signed-off-by: Mike Sterling <Mike.Sterling@microsoft.com>
> Cc: NetDev <netdev@vger.kernel.org>
>
> ---
> drivers/net/Kconfig | 2 +
> drivers/net/Makefile | 2 +
> drivers/net/hyperv/Kconfig | 5 +
> drivers/net/hyperv/Makefile | 3 +
> drivers/net/hyperv/hyperv_net.h | 1058
> +++++++++++++++++++++++++++++++++++++
> drivers/net/hyperv/netvsc.c | 944
> +++++++++++++++++++++++++++++++++
> drivers/net/hyperv/netvsc_drv.c | 456 ++++++++++++++++
> drivers/net/hyperv/rndis_filter.c | 855
> ++++++++++++++++++++++++++++++
> 8 files changed, 3325 insertions(+), 0 deletions(-)
> create mode 100644 drivers/net/hyperv/Kconfig
> create mode 100644 drivers/net/hyperv/Makefile
> create mode 100644 drivers/net/hyperv/hyperv_net.h
> create mode 100644 drivers/net/hyperv/netvsc.c
> create mode 100644 drivers/net/hyperv/netvsc_drv.c
> create mode 100644 drivers/net/hyperv/rndis_filter.c
>
Hi Dave,
Do you have any comments on this patch which requesting hv_netvsc
out of staging area?
Thanks,
- Haiyang
^ permalink raw reply
* Re: Route cache problem.
From: Eric Dumazet @ 2011-11-03 15:16 UTC (permalink / raw)
To: Rogier Wolff; +Cc: linux-kernel, netdev
In-Reply-To: <20111103143734.GA17218@bitwizard.nl>
Le jeudi 03 novembre 2011 à 15:37 +0100, Rogier Wolff a écrit :
> Hi,
>
> My workstation has an incorrect route cache entry:
>
What kernel version ?
> assurancetourix:~> route -nC | head -2 ; route -nC | grep 234.34
> Kernel IP routing cache
> Source Destination Gateway Flags Metric Ref Use Iface
> 192.168.235.8 192.168.234.34 192.168.235.251 0 0 3 eth0
> 192.168.235.8 192.168.234.34 192.168.235.251 0 0 4 eth0
> 192.168.235.8 192.168.234.34 192.168.235.251 0 0 2 eth0
>
> (I don't know why there are three).
>
Different routing keys, like TOS.
for tos in `seq 2 2 34`; do ping -c 1 -Q $tos 10.37.168.112; done
# route -nC|grep 10.37.168.112
10.37.168.112 192.168.20.108 192.168.20.108 l 0 0 479 lo
192.168.20.108 10.37.168.112 192.168.20.254 0 0 3 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 3 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 3 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 3 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 3 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 5 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 5 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 5 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 1 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 1 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 0 0 eth3
192.168.20.108 10.37.168.112 192.168.20.254 0 1 2 eth3
> the correct routing cache entries would look something like this:
> (this one works):
> assurancetourix:~> route -nC | head -2 ; route -nC | grep 234.20
> Kernel IP routing cache
> Source Destination Gateway Flags Metric Ref Use Iface
> 192.168.235.8 192.168.234.20 192.168.235.4 0 0 1 eth0
> 192.168.234.20 192.168.235.8 192.168.235.8 l 0 0 0 lo
> 192.168.235.8 192.168.234.20 192.168.235.4 0 0 0 eth0
>
> The routing table is:
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 0.0.0.0 192.168.235.251 0.0.0.0 UG 0 0 0 eth0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
> 192.168.234.0 192.168.235.4 255.255.255.0 UG 0 0 0 eth0
> 192.168.235.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
> 192.168.235.2 192.168.235.4 255.255.255.255 UGH 0 0 0 eth0
>
> It's the third line that is supposed to steer packets for '234.34 to
> the proper router that knows how to reach the 234.0 network.
>
> As a temporary workaround I've added the route to 192.168.235.2 which
> is that same host, but not in the nameserver, so it's annoying.
> (the other host that I can't reach due to this problem doesn't have
> a second IP address (yet)).
>
> Oh... routing to 192.168.234.34 works on the router 192.168.235.4:
> PING 192.168.234.34 (192.168.234.34) 56(84) bytes of data.
> 64 bytes from 192.168.234.34: icmp_req=1 ttl=64 time=41.5 ms
>
> Anyway, what would you suggest for me to try to get that invalid
> route cache entry dropped?
>
> Drop the default route? Ok. Done:
> # route del default
> # ping 192.168.234.34
> 2 packets transmitted, 0 received, 100% packet loss, time 1007ms
>
> I'm used to the default route being at the bottom, but deleting it should
> be enough to prevent it from being found first, right? :-)
>
> Add a host route to this host explicitly naming the router?
>
> assurancetourix:~# route add 192.168.234.34 gw driepoot
> assurancetourix:~# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
> 192.168.234.0 192.168.235.4 255.255.255.0 UG 0 0 0 eth0
> 192.168.234.34 192.168.235.4 255.255.255.255 UGH 0 0 0 eth0
> 192.168.235.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0
> 192.168.235.2 192.168.235.4 255.255.255.255 UGH 0 0 0 eth0
> assurancetourix:~# ping 192.168.234.34 -c 2
> ....
> 2 packets transmitted, 0 received, 100% packet loss, time 1008ms
>
> Still the packets end up on the ethernet with the 192.168.235.251 router's
> Ethernet address.....
>
> assurancetourix:~# route -nC | head -2 ; route -nC | grep 234.34
> Kernel IP routing cache
> Source Destination Gateway Flags Metric Ref Use Iface
> 192.168.235.8 192.168.234.34 192.168.235.251 0 0 0 eth0
> 192.168.235.8 192.168.234.34 192.168.235.251 0 0 0 eth0
> 192.168.235.8 192.168.234.34 192.168.235.251 0 0 5 eth0
>
Better use "ip -s route list cache" to diagnose problems (more
information)
>
> # ifconfig eth0 down
> # route -n
> <empty table>
> # ifconfig eth0 up
> <old routing table is restored automatically??? apparently with the routing
> cache entries as well....>
>
>
> I initially thought that this was a problem with the routing
> cache entry being too persistent in the kernel. While documenting
> this while writing this email, I've found that I can flush the whole routing
> cache with "ip route flush cache" .
>
> However the routing cache entry springs back to life when I first
> ping the 234.34 host. Even when the problem machine doesn't have a
> default route, so it shouldn't know about the 235.251 default router.
>
> This is getting weirder and weirder.
>
> During all this I have
> # tcpdump -nei eth0 net 192.168.234.0/24
> running. If my machine were to get an ICMP redirect from somewhere
> I'd see it, right?
>
> It could be that the 192.168.235.251 router is proxy-arping (incorreclty)
> for the problem hosts. But then my workstation would have to be
> ARPing in the first place.
>
> # route add 192.168.234.200 eth0
> # ping 192.168.234.200
> gives:
> 15:31:33.857343 00:23:54:15:1f:a9 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.234.200 tell 192.168.235.8, length 28
> in the TCPDUMP, so my machine is not arping for 192.168.234.34.
>
> Any suggestions? Any at all?
>
> Roger.
>
^ permalink raw reply
* Bug#647513: TX watchdog fires for ipheth after phone upgraded to iOS 5
From: Thibault Roulet @ 2011-11-03 15:09 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Diego Giagio, 647513, netdev
In-Reply-To: <1320331171.3079.31.camel@deadeye>
On 11/03/2011 03:39 PM, Ben Hutchings wrote:
> On Thu, 2011-11-03 at 14:52 +0100, darx wrote:
>> Package: linux-2.6
>> Version: 3.0.0-3
>> Severity: important
>> Tags: upstream
>>
>> Hi,
>>
>> After IOS5 update on my iphone when I plug it on my Debian, it crashes.
>
> No it doesn't.
well, "crash" is a bit strong. It looks like a kernel hickups
>
>> As I'm using it as a modem it's quite problematic.
>>
>>
>> Nov 3 14:16:51 thib kernel: [ 371.824017] ------------[ cut here
>> ]------------
>> Nov 3 14:16:51 thib kernel: [ 371.824024] WARNING: at /build/buildd-
>> linux-2.6_3.0.0-3-amd64-9ClimQ/linux-2.6-3.0.0/debian/build/source_amd64_none/net/sched/sch_generic.c:255
>> dev_watchdog+0xe9/0x148()
>> Nov 3 14:16:51 thib kernel: [ 371.824027] Hardware name: OptiPlex 780
>> Nov 3 14:16:51 thib kernel: [ 371.824029] NETDEV WATCHDOG: eth1 (ipheth):
>> transmit queue 0 timed out
> [...]
>
> Diego, please can you investigate this.
>
Oh and I can add that I tested on this DELL Optiplex 780 machine and also a small HP mini 5101 laptop (same debian
version). Same error.
Thanks
Thib
^ 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