* [PATCH] Fix b44 RX FIFO overflow recovery.
From: James Courtier-Dutton @ 2010-06-30 20:11 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
Hi,
This patch improves the recovery after a RX FIFO overflow on the b44
Ethernet NIC.
Before it would do a complete chip reset, resulting is loss of link
for a few seconds.
This patch improves this to do recovery in about 20ms without loss of link.
Kind Regards
James
b44: Handle RX FIFO overflow better.
Signed off by: James@superbug.co.uk
[-- Attachment #2: b44-fix-rx-overflow.txt --]
[-- Type: text/plain, Size: 1363 bytes --]
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 69d9f3d..72537c1 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -852,12 +852,46 @@ static int b44_poll(struct napi_struct *napi, int budget)
/* spin_unlock(&bp->tx_lock); */
}
spin_unlock_irqrestore(&bp->lock, flags);
+ if (bp->istat & ISTAT_DSCE)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_DSCE\n");
+ }
+ if (bp->istat & ISTAT_DATAE)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_DATAE\n");
+ }
+ if (bp->istat & ISTAT_DPE)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_DPE\n");
+ }
+ if (bp->istat & ISTAT_RDU)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_RDU\n");
+ }
+ if (bp->istat & ISTAT_RFO)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_RFO\n");
+ spin_lock_irqsave(&bp->lock, flags);
+ b44_disable_ints(bp);
+ /* This resets the ISTAT_RFO flag */
+ ssb_device_enable(bp->sdev, 0);
+ b44_init_rings(bp);
+ b44_init_hw(bp, B44_FULL_RESET_SKIP_PHY);
+ netif_wake_queue(bp->dev);
+ spin_unlock_irqrestore(&bp->lock, flags);
+ work_done = 0;
+ }
+ if (bp->istat & ISTAT_TFU)
+ {
+ printk(KERN_INFO "b44_poll: ISTAT_TFU\n");
+ }
+
work_done = 0;
if (bp->istat & ISTAT_RX)
work_done += b44_rx(bp, budget);
- if (bp->istat & ISTAT_ERRORS) {
+ if ((bp->istat & ISTAT_ERRORS) && !(bp->istat & ISTAT_RFO)) {
spin_lock_irqsave(&bp->lock, flags);
b44_halt(bp);
b44_init_rings(bp);
^ permalink raw reply related
* Re: [PATCH 0/4] Introduce and use printk pointer extension %pV
From: David Miller @ 2010-06-30 20:07 UTC (permalink / raw)
To: joe; +Cc: akpm, linux-kernel, netdev, greg
In-Reply-To: <cover.1277636090.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sun, 27 Jun 2010 04:02:32 -0700
> Recursive printk can reduce the total image size of an x86 defconfig about 1%
> by reducing duplicated KERN_<level> strings and centralizing the functions
> used by macros in new separate functions.
>
> Joe Perches (4):
> vsprintf: Recursive vsnprintf: Add "%pV", struct va_format
> device.h drivers/base/core.c Convert dev_<level> logging macros to functions
> netdevice.h net/core/dev.c: Convert netdev_<level> logging macros to functions
> netdevice.h: Change netif_<level> macros to call netdev_<level> functions
I'm fine with this, thanks Joe.
Greg, could you ACK this and let me know if it's OK if it swings
through my net-next-2.6 tree?
Thanks.
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Mitchell Erblich @ 2010-06-30 20:06 UTC (permalink / raw)
To: Ivan Novick; +Cc: netdev, jmatthews, Tim Heath
In-Reply-To: <AANLkTinJC6uS1GTbKJWL9AlEs2e5GleQvJbTUZrsQHaE@mail.gmail.com>
On Jun 30, 2010, at 11:04 AM, Ivan Novick wrote:
> Hello all,
>
> Attached is a packet capture from my application that is running on
> RedHat Enterprise Linux 5.4
>
> I am seeing a Retransmission timeout but I was hoping this case would
> go into fast retransmit and not RTO.
>
> I am wondering why did the sender not send more data? If the sender
> was to send more data and extend the window then it would seem the
> duplicate acks or SACKS should trigger fast retransmit.
>
> The application does not constantly send data, but data should arrive
> to be sent before 200 milliseconds that it takes for the RTO.
>
> Is it possible that there was no data to send and the window is not
> advanced and the sender is waiting for an ACK. Then data arrives half
> way into the RTO 200 milliseconds while waiting for an outstanding ACK
> but the window is not advanced?
>
> You can see right after the RTO and retransmission additional data is
> sent, so there is additional data. In theory that additional data
> could be arriving right at the 200 milliseconds point, but we see this
> pattern in the dump regularly and I believe data is there before the
> end of the 200 milliseconds RTO.
>
> As a related point the advertised window from the receiver seems to be
> a constant value of 22060, so either the receiver is handling its data
> fast enough to never have to reduce its window... or this number is
> really not used to indicate space available currently in the receive
> window?
>
> Any feedback to help understand why we are not doing fast retransmit
> and or why the sender is not extending the window would be greatly
> appreciated.
>
> Cheers,
> Ivan Novick
> <sender_backoff.cap>
Ivan, et al,
Without looking at your dump, not getting DUPAcks then
- their isn't enough in-flight data/ segments to generate enough ACKs (Duplicate ACKs)
assuming you get ACKs with non-increasing SEQs
- or the/some ACKs are being dropped.
Normally to fix this is to set the MTU / MSS size to say 576 at the two
end points if this is re-runnable, OR make it a thin flow
With a real quick look at your dump,
my first question is why the .1 -> .2 always has a small window of 46
one way data transfer?
Now, taking a look at the dump with a -r ,
What makes you think that DupACKs are being sent?
To then cause a Fast Re-transmit?
Sometimes, adding tracing within the tcps, can identify if.
the tcp flow has periods of idleness,
the tcp flow is/has been application limited versus network limited,
whether the flow is in SS or CA?
CA normally has DELayed ACks, which reduces the number
of ACKs to 1/2 or more,
Whether Fast re-xmit is triggered by 2 or 3 DupAcks.
whether any burst avoidance has occured,
etc,
Mitchell Erblich
^ permalink raw reply
* Re: [PATCH 1/2 v3] mv643xx_eth: use sw csum for big packets
From: David Miller @ 2010-06-30 20:01 UTC (permalink / raw)
To: saeed; +Cc: netdev
In-Reply-To: <1277634403-1018-1-git-send-email-saeed@marvell.com>
From: Saeed Bishara <saeed@marvell.com>
Date: Sun, 27 Jun 2010 13:26:43 +0300
> Some controllers (KW, Dove) limits the TX IP/layer4 checksum offloading to a max size.
>
> Signed-off-by: Saeed Bishara <saeed@marvell.com>
> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: b44: Reset due to FIFO overflow.
From: James Courtier-Dutton @ 2010-06-30 19:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Mitchell Erblich, netdev
In-Reply-To: <1277788678.4235.1285.camel@edumazet-laptop>
On 29 June 2010 06:17, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> rx ring buffer is about 200 frames on b44. One single tcp flow should
> fit.
>
> Limit is 511. James, did you try to increase rx ring ?
>
> ethtool -G eth0 rx 511
>
Any value given to that command results in a non operating NIC.
rmmod b44
modprobe b44 fixes that.
I have narrowed down the problem now.
I can now reset the RX fifo after the RFO in less than 20 ms without
the Ethernet Link going down.
When I get a moment, I will post a patch so other people can test it.
Kind Regards
James
^ permalink raw reply
* Re: TCP not triggering a fast retransmit?
From: Brian Bloniarz @ 2010-06-30 19:26 UTC (permalink / raw)
To: Ivan Novick; +Cc: netdev, jmatthews, Tim Heath
In-Reply-To: <AANLkTinJC6uS1GTbKJWL9AlEs2e5GleQvJbTUZrsQHaE@mail.gmail.com>
On 06/30/2010 02:04 PM, Ivan Novick wrote:
> I am wondering why did the sender not send more data? If the sender
> was to send more data and extend the window then it would seem the
> duplicate acks or SACKS should trigger fast retransmit.
Hi Ivan,
Like you said, the receive window can't explain why the sender wouldn't
send. The congestion window is another possible reason why the sender
might not send, though it's sorta impossible to tell if that's really
it from a small tcpdump. Maybe investigating the details of congestion
control might yield something?
HTH,
-Brian
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-06-30
From: Johannes Berg @ 2010-06-30 19:15 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20100630.120551.170116973.davem@davemloft.net>
On Wed, 2010-06-30 at 12:05 -0700, David Miller wrote:
> > + /*
> > + * Receiving all multicast frames is always enabled by the
> > + * default flags setup in iwl_connection_init_rx_config()
> > + * since we currently do not support programming multicast
> > + * filters into the device.
> > + */
> > *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
> > FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
>
> Note that this is an amazingly serious limitation.
>
> This basically makes iwl chips unsuitable for use on networks where
> real multicast use is common.
Lots of wireless devices have this limitation unfortunately. I think we
-might- be able to have proper filters for iwl, but haven't found out
quite how yet unfortunately, if it's actually implemented properly on
the device and there's not just some fake API.
johannes
^ permalink raw reply
* Re: [PATCH] act_mirred: combine duplicate code
From: David Miller @ 2010-06-30 19:13 UTC (permalink / raw)
To: hadi; +Cc: xiaosuo, netdev
In-Reply-To: <1277894942.3509.25.camel@bigi>
From: jamal <hadi@cyberus.ca>
Date: Wed, 30 Jun 2010 06:49:02 -0400
> On Wed, 2010-06-30 at 06:24 -0400, jamal wrote:
>
>> m->tcf_qstats.drops.
>
> Sorry - this nagged me - we are already incrementing overlimits - we
> should increment drops. Scratch that too. I am going to say your patch
> as is:
> signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied.
Jamal, please capitalize "Signed-off-by" in the future, thanks.
^ permalink raw reply
* Re: [PATCH] act_nat: use stack variable
From: David Miller @ 2010-06-30 19:12 UTC (permalink / raw)
To: herbert; +Cc: hadi, xiaosuo, netdev
In-Reply-To: <20100630103005.GA24688@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 30 Jun 2010 18:30:05 +0800
> On Wed, Jun 30, 2010 at 06:25:21AM -0400, jamal wrote:
>> On Wed, 2010-06-30 at 17:07 +0800, Changli Gao wrote:
>> > act_nat: use stack variable
>> >
>> > structure tc_nat isn't too big for stack, so we can put it in stack.
>> >
>> > Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>>
>> Doesnt look unreasonable - will let Herbert make the call..
>
> Looks good to me too.
Applied.
^ permalink raw reply
* Re: [PATCH] net/neighbour.h: fix typo
From: David Miller @ 2010-06-30 19:07 UTC (permalink / raw)
To: segooon
Cc: trivial, tj, ebiederm, eric.dumazet, shemminger, netdev,
linux-kernel
In-Reply-To: <1277914095-25905-1-git-send-email-segooon@gmail.com>
From: Kulikov Vasiliy <segooon@gmail.com>
Date: Wed, 30 Jun 2010 20:08:15 +0400
> 'Shoul' must be 'should'.
>
> Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-06-30
From: David Miller @ 2010-06-30 19:05 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100630185319.GA2618-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 30 Jun 2010 14:53:20 -0400
> Here are a few more fixes intended for 2.6.35. Included are a couple of
> small regression fixes for iwlwifi, one that causes connection stalls with
> 802.11n on some devices and another which could disable multicast traffic.
> Also included is an ath9k fix which avoids a null pointer dereference
> resulting from a timer leak.
>
> Please let me know if there are problems!
...
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Pulled, thanks John.
> @@ -1329,6 +1328,12 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
>
> mutex_unlock(&priv->mutex);
>
> + /*
> + * Receiving all multicast frames is always enabled by the
> + * default flags setup in iwl_connection_init_rx_config()
> + * since we currently do not support programming multicast
> + * filters into the device.
> + */
> *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
> FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
Note that this is an amazingly serious limitation.
This basically makes iwl chips unsuitable for use on networks where
real multicast use is common.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* pull request: wireless-2.6 2010-06-30
From: John W. Linville @ 2010-06-30 18:53 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
David,
Here are a few more fixes intended for 2.6.35. Included are a couple of
small regression fixes for iwlwifi, one that causes connection stalls with
802.11n on some devices and another which could disable multicast traffic.
Also included is an ath9k fix which avoids a null pointer dereference
resulting from a timer leak.
Please let me know if there are problems!
John
---
The following changes since commit d3ead2413cb99d3e6265577b12537434e229d8c2:
Guillaume Gaudonville (1):
ixgbe: skip non IPv4 packets in ATR filter
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Johannes Berg (1):
iwlwifi: fix multicast
Vasanthakumar Thiagarajan (1):
ath9k: Fix bug in starting ani
Wey-Yi Guy (1):
iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 11 ++++++++++-
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 6 +-----
drivers/net/wireless/iwlwifi/iwl-core.c | 7 ++++++-
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index fbb7dec..5ea8773 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -445,6 +445,7 @@ void ath_deinit_leds(struct ath_softc *sc);
#define SC_OP_TSF_RESET BIT(11)
#define SC_OP_BT_PRIORITY_DETECTED BIT(12)
#define SC_OP_BT_SCAN BIT(13)
+#define SC_OP_ANI_RUN BIT(14)
/* Powersave flags */
#define PS_WAIT_FOR_BEACON BIT(0)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index abfa049..1e2a68e 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -336,6 +336,10 @@ set_timer:
static void ath_start_ani(struct ath_common *common)
{
unsigned long timestamp = jiffies_to_msecs(jiffies);
+ struct ath_softc *sc = (struct ath_softc *) common->priv;
+
+ if (!(sc->sc_flags & SC_OP_ANI_RUN))
+ return;
common->ani.longcal_timer = timestamp;
common->ani.shortcal_timer = timestamp;
@@ -872,11 +876,13 @@ static void ath9k_bss_assoc_info(struct ath_softc *sc,
/* Reset rssi stats */
sc->sc_ah->stats.avgbrssi = ATH_RSSI_DUMMY_MARKER;
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
} else {
ath_print(common, ATH_DBG_CONFIG, "Bss Info DISASSOC\n");
common->curaid = 0;
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
}
}
@@ -1478,8 +1484,10 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
if (vif->type == NL80211_IFTYPE_AP ||
vif->type == NL80211_IFTYPE_ADHOC ||
- vif->type == NL80211_IFTYPE_MONITOR)
+ vif->type == NL80211_IFTYPE_MONITOR) {
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
+ }
out:
mutex_unlock(&sc->mutex);
@@ -1500,6 +1508,7 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
mutex_lock(&sc->mutex);
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
/* Reclaim beacon resources */
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
index 44ef5d9..01658cf 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
@@ -212,11 +212,7 @@ static void iwlagn_chain_noise_reset(struct iwl_priv *priv)
static void iwlagn_rts_tx_cmd_flag(struct ieee80211_tx_info *info,
__le32 *tx_flags)
{
- if ((info->control.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS) ||
- (info->control.rates[0].flags & IEEE80211_TX_RC_USE_CTS_PROTECT))
- *tx_flags |= TX_CMD_FLG_RTS_CTS_MSK;
- else
- *tx_flags &= ~TX_CMD_FLG_RTS_CTS_MSK;
+ *tx_flags |= TX_CMD_FLG_RTS_CTS_MSK;
}
/* Calc max signal level (dBm) among 3 possible receivers */
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 426e955..5bbc529 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -1314,7 +1314,6 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
changed_flags, *total_flags);
CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
- CHK(FIF_ALLMULTI, RXON_FILTER_ACCEPT_GRP_MSK);
CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
@@ -1329,6 +1328,12 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
mutex_unlock(&priv->mutex);
+ /*
+ * Receiving all multicast frames is always enabled by the
+ * default flags setup in iwl_connection_init_rx_config()
+ * since we currently do not support programming multicast
+ * filters into the device.
+ */
*total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
}
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH v2 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163915.GC23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:15 +0400
> MPC8313ECE says:
>
> "If the controller receives a 1- or 2-byte frame (such as an illegal
> runt packet or a packet with RX_ER asserted) before GRS is asserted
> and does not receive any other frames, the controller may fail to set
> GRSC even when the receive logic is completely idle. Any subsequent
> receive frame that is larger than two bytes will reset the state so
> the graceful stop can complete. A MAC receiver (Rx) reset will also
> reset the state."
>
> This patch implements the proposed workaround:
>
> "If IEVENT[GRSC] is still not set after the timeout, read the eTSEC
> register at offset 0xD1C. If bits 7-14 are the same as bits 23-30,
> the eTSEC Rx is assumed to be idle and the Rx can be safely reset.
> If the register fields are not equal, wait for another timeout
> period and check again."
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/3] gianfar: Implement workaround for eTSEC76 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163913.GB23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:13 +0400
> MPC8313ECE says:
>
> "For TOE=1 huge or jumbo frames, the data required to generate the
> checksum may exceed the 2500-byte threshold beyond which the controller
> constrains itself to one memory fetch every 256 eTSEC system clocks.
>
> This throttling threshold is supposed to trigger only when the
> controller has sufficient data to keep transmit active for the duration
> of the memory fetches. The state machine handling this threshold,
> however, fails to take large TOE frames into account. As a result,
> TOE=1 frames larger than 2500 bytes often see excess delays before start
> of transmission."
>
> This patch implements the workaround as suggested by the errata
> document, i.e.:
>
> "Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to
> memory throttling.
> When using packets larger than 2700 bytes, it is recommended to turn TOE
> off."
>
> To be sure, we limit the TOE frames to 2500 bytes, and do software
> checksumming instead.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163912.GA23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:12 +0400
> MPC8313ECE says:
>
> "If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
> which are larger than MAXFRM, the controller truncates the frames to
> length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller
> also erroneously marks RxBD[TR]=1 if the received frame length is MAXFRM
> or MAXFRM-1, even though those frames are not truncated.
> No truncation or truncation error occurs if MACCFG2[Huge Frame]=1."
>
> There are two options to workaround the issue:
>
> "1. Set MACCFG2[Huge Frame]=1, so no truncation occurs for invalid large
> frames. Software can determine if a frame is larger than MAXFRM by
> reading RxBD[LG] or RxBD[Data Length].
>
> 2. Set MAXFRM to 1538 (0x602) instead of the default 1536 (0x600), so
> normal-length frames are not marked as truncated. Software can examine
> RxBD[Data Length] to determine if the frame was larger than MAXFRM-2."
>
> This patch implements the first workaround option by setting HUGEFRAME
> bit, and gfar_clean_rx_ring() already checks the RxBD[Data Length].
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: manfred.rudigier, Sandeep.Kumar, afleming, netdev, linuxppc-dev
In-Reply-To: <20100630163804.GA636@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:38:04 +0400
> On Tue, Jun 29, 2010 at 03:16:26PM -0700, David Miller wrote:
>>
>> I really don't see any value at all to this config option,
>> the errata fixup code should be there all the time.
>
> Well, at least for eTSEC76 erratum (patch 2/3) we have to touch
> fast path (i.e. start_xmit), so I just wanted to make zero
> overhead for controllers that don't need any fixups.
>
> Not that there's much of the overhead in a single additional
> 'if' condition, no. ;-)
The register accesses will dominate the costs with this chip.
The only case where a if() test is going to potentially create
some practical performance impact is if the TX is performed
purely using changes to a shared memory data structure and
absolutely no MMIO register reads or writes.
^ permalink raw reply
* TCP not triggering a fast retransmit?
From: Ivan Novick @ 2010-06-30 18:04 UTC (permalink / raw)
To: netdev; +Cc: jmatthews, Tim Heath
[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]
Hello all,
Attached is a packet capture from my application that is running on
RedHat Enterprise Linux 5.4
I am seeing a Retransmission timeout but I was hoping this case would
go into fast retransmit and not RTO.
I am wondering why did the sender not send more data? If the sender
was to send more data and extend the window then it would seem the
duplicate acks or SACKS should trigger fast retransmit.
The application does not constantly send data, but data should arrive
to be sent before 200 milliseconds that it takes for the RTO.
Is it possible that there was no data to send and the window is not
advanced and the sender is waiting for an ACK. Then data arrives half
way into the RTO 200 milliseconds while waiting for an outstanding ACK
but the window is not advanced?
You can see right after the RTO and retransmission additional data is
sent, so there is additional data. In theory that additional data
could be arriving right at the 200 milliseconds point, but we see this
pattern in the dump regularly and I believe data is there before the
end of the 200 milliseconds RTO.
As a related point the advertised window from the receiver seems to be
a constant value of 22060, so either the receiver is handling its data
fast enough to never have to reduce its window... or this number is
really not used to indicate space available currently in the receive
window?
Any feedback to help understand why we are not doing fast retransmit
and or why the sender is not extending the window would be greatly
appreciated.
Cheers,
Ivan Novick
[-- Attachment #2: sender_backoff.cap --]
[-- Type: application/octet-stream, Size: 3076 bytes --]
^ permalink raw reply
* Re: [PATCH net-next-2.6] netfilter: remove deprecated config option NF_CT_ACCT
From: David Miller @ 2010-06-30 17:48 UTC (permalink / raw)
To: kaber; +Cc: jpirko, netdev, ole
In-Reply-To: <4C2B49B9.5050302@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Wed, 30 Jun 2010 15:42:17 +0200
> I usually leave those for the architecture maintainers.
Right, that's how this is supposed to work. If we update defconfigs
every time we make some Kconfig change it's going to be nothing but
pain for arch folks.
^ permalink raw reply
* Re: [PATCH] xfrm: fix XFRMA_MARK extraction in xfrm_mark_get
From: David Miller @ 2010-06-30 17:41 UTC (permalink / raw)
To: andreas.steffen; +Cc: netdev, hadi
In-Reply-To: <4C2AF8EE.8030508@strongswan.org>
From: Andreas Steffen <andreas.steffen@strongswan.org>
Date: Wed, 30 Jun 2010 09:57:34 +0200
> Determine the size of the xfrm_mark struct, not of its pointer.
>
> Signed-off-by: Andreas Steffen <andreas.steffen@strongswan.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] net/core: use ntohs for skb->protocol
From: David Miller @ 2010-06-30 17:39 UTC (permalink / raw)
To: sebastian; +Cc: netdev
In-Reply-To: <20100630090229.GB25541@Chamillionaire.breakpoint.cc>
From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Date: Wed, 30 Jun 2010 11:02:29 +0200
> From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
> This is only noticed by people that are not doing everything correct in
> the first place.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] ipv6: Use interface max_desync_factor instead of static default
From: David Miller @ 2010-06-30 17:29 UTC (permalink / raw)
To: ben; +Cc: yoshfuji, kaber, 514646, piotr.lewandowski, netdev
In-Reply-To: <1277588575.26161.311.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sat, 26 Jun 2010 22:42:55 +0100
> max_desync_factor can be configured per-interface, but nothing is
> using the value.
>
> Reported-by: Piotr Lewandowski <piotr.lewandowski@gmail.com>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/2] ipv6: Clamp reported valid_lft to a minimum of 0
From: David Miller @ 2010-06-30 17:28 UTC (permalink / raw)
To: ben; +Cc: yoshfuji, kaber, 514644, piotr.lewandowski, netdev
In-Reply-To: <1277588267.26161.300.camel@localhost>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sat, 26 Jun 2010 22:37:47 +0100
> Since addresses are only revalidated every 2 minutes, the reported
> valid_lft can underflow shortly before the address is deleted.
> Clamp it to a minimum of 0, as for prefered_lft.
>
> Reported-by: Piotr Lewandowski <piotr.lewandowski@gmail.com>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] usb: pegasus: fixed coding style issues
From: David Miller @ 2010-06-30 17:26 UTC (permalink / raw)
To: nikai-bVCNqDZ4lKNeoWH0uzbU5w
Cc: petkan-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100626185854.4a3eff43-m0oTu1HmxXpuhsjpcywf5g@public.gmane.org>
From: Nicolas Kaiser <nikai-bVCNqDZ4lKNeoWH0uzbU5w@public.gmane.org>
Date: Sat, 26 Jun 2010 18:58:54 +0200
> Fixed brace, static initialization, comment, whitespace and spacing
> coding style issues.
>
> Signed-off-by: Nicolas Kaiser <nikai-bVCNqDZ4lKNeoWH0uzbU5w@public.gmane.org>
Applied to net-next-2.6, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] igbvf: avoid name clash between PF and VF
From: Casey Leedom @ 2010-06-30 16:59 UTC (permalink / raw)
To: Stefan Assmann
Cc: netdev, e1000-devel, Duyck, Alexander H, gregory.v.rose,
jeffrey.t.kirsher, Andy Gospodarek
In-Reply-To: <4C2B0614.9040004@redhat.com>
| From: Stefan Assmann <sassmann@redhat.com>
| Date: Wednesday, June 30, 2010 01:53 am
|
| This is not a udev bug since udev doesn't create persistent rules for
| VFs as their MAC address changes every reboot.
|
| To avoid this problem we could change the kernel name for the VFs and
| thus avoid confusion between VFs and PFs.
|
| I've already discussed this with Alexander Duyck and Greg Rose, so far
| they have no objection. However this problem appears for all drivers that
| support PFs and VFs and thus the changes should be applied consistently
| to all of these drivers.
I'm not sure that this problem affects "all drivers which support PFs and VFs."
I think that you might mean "all drivers which support PFs and VFs with non-
persistent MAC addresses for the VFs." For instance, the MAC addresses
associated with the new cxgb4vf VFs are persistent so, from what I understand of
the scenario you outlined, I don't think that they would trigger the problem you
describe. Please correct me if I've missed something. Thanks.
Casey
^ permalink raw reply
* RE: [Pv-drivers] [PATCH net-next-2.6 3/3] vmxnet3: Remove incorrect implementation of ethtool_ops::get_flags()
From: Bhavesh Davda @ 2010-06-30 16:46 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, VMware, Inc., netdev@vger.kernel.org
In-Reply-To: <1277913534.2082.28.camel@achroite.uk.solarflarecom.com>
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Wednesday, June 30, 2010 8:59 AM
>
> On Wed, 2010-06-30 at 08:44 -0700, Bhavesh Davda wrote:
> > Thanks for fixing this, Ben! Had to look at ethtool-2.6.34 src to
> > convince myself of the correctness. Looks good to me.
> >
> > Signed-off-by: Bhavesh Davda <bhavesh@vmware.com>
> >
> > ps: I do wonder, however, why not always use ethtool_op_get_flags for
> > all drivers, and mask whatever is returned by the driver specific
> > dev->ethtool_ops->get_flags with flags_dup_features instead of this
> > approach?
>
> I think you're right that ethtool_op_get_flags could be the implicit
> default (i.e. used if ethtool_ops::get_flags is NULL) and drivers
> should
> not have to set it. Following this change, no drivers in net-next-2.6
> will be using any other implementation. However, I don't think
> ethtool_ops::get_flags should be removed - in future there are likely
> to
> be additional ethtool flags that do not correspond to net device
> feature
> flags, and some drivers will need a different implementation.
>
> Ben.
>
Hi Ben,
I'm not suggesting nuking ethtool_ops::get_flags. What I was suggesting is *always* calling ethtool_ops_get_flags from dev_ethtool for case ETHTOOL_GFLAGS, but doing something like this simple patch:
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index a0f4964..f5da6ed 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -139,8 +139,9 @@ u32 ethtool_op_get_flags(struct net_device *dev)
* handling for flags which are not so easily handled
* by a simple masking operation
*/
-
- return dev->features & flags_dup_features;
+ return (dev->ethtool_ops->get_flags ?
+ dev->ethtool_ops->get_flags(dev) :
+ dev->features) & flags_dup_features;
}
EXPORT_SYMBOL(ethtool_op_get_flags);
@@ -1495,9 +1496,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
break;
case ETHTOOL_GFLAGS:
rc = ethtool_get_value(dev, useraddr, ethcmd,
- (dev->ethtool_ops->get_flags ?
- dev->ethtool_ops->get_flags :
- ethtool_op_get_flags));
+ ethtool_op_get_flags);
break;
case ETHTOOL_SFLAGS:
rc = ethtool_set_value(dev, useraddr,
Plus nuking all such code in the netdev drivers:
.get_flags = ethtool_op_get_flags,
This is still pretty fragile and could lead to infinite recursion if some drivers are missed. But you get the idea.
Thanks
- Bhavesh
^ permalink raw reply related
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