* RE: [PATCH v2 net-next 1/2] be2net: Modify GPL Marking in all source files.
From: Bandi,Sarveshwar @ 2013-01-23 19:37 UTC (permalink / raw)
To: Bandi,Sarveshwar, David Miller; +Cc: netdev@vger.kernel.org, Vasundhara, Volam
In-Reply-To: <32aacb12-c1af-4cff-becb-eb046eef0d6e@CMEXHTCAS2.ad.emulex.com>
Dave,
Does this explanation make sense? Would you want me to resubmit the patches?
Thanks,
Sarvesh
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Bandi,Sarveshwar
Sent: Wednesday, January 23, 2013 12:58 PM
To: David Miller
Cc: netdev@vger.kernel.org; Vasundhara, Volam
Subject: RE: [PATCH v2 net-next 1/2] be2net: Modify GPL Marking in all source files.
Dave,
Can I assume that the first 3 points are acceptable (copyright being extended, adding EMULEX/SLI as trademarks, and adding website information)?
As for the last one about disclaimer, most driver had it all the time and benet did not. It mentions section 15 "Disclaimer of Warranty" of gpl license explicitly (http://www.gnu.org/licenses/gpl.html).
Is there an issue with this?
Thanks,
Sarvesh
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Wednesday, January 23, 2013 12:36 PM
To: Bandi,Sarveshwar
Cc: netdev@vger.kernel.org; Vasundhara, Volam
Subject: Re: [PATCH v2 net-next 1/2] be2net: Modify GPL Marking in all source files.
From: <sarveshwar.bandi@emulex.com>
Date: Wed, 23 Jan 2013 12:22:03 +0530
> From: Vasundhara Volam <vasundhara.volam@emulex.com>
>
> The following modifications have been made to copyright:
> - years of copyright extended to include 2013
> - specify EMULEX and SLI as trademarks of Emulex corporation
> - specify emulex website
> - Added a more detailed disclaimer " ALL EXPRESS OR IMPLIED
> CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED
> WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
> NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH
> DISCLAIMERS ARE HELD TO BE LEGALLY INVALID."
>
> Signed-off-by: Vasundhara Volam <vasundhara.volam@emulex.com>
> Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
You're just essentially reading the contents of the patch, that's not satisfactory.
In particular, the problem is that you aren't explaining why you're making all of these changes.
There needs to be justification for copyright changes like this, you are not providing them.
--
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: BUG in netxen_release_tx_buffers when TSO enabled on kernels >= 3.3 and <= 3.6
From: Rajesh Borundia @ 2013-01-23 19:47 UTC (permalink / raw)
To: Eric Dumazet, Ben Hutchings
Cc: christoph.paasch@uclouvain.be, Ian Campbell, Sony Chacko,
David Miller, netdev
In-Reply-To: <1358884782.12374.8.camel@edumazet-glaptop>
>-----Original Message-----
>From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
>Sent: Wednesday, January 23, 2013 1:30 AM
>To: Ben Hutchings
>Cc: christoph.paasch@uclouvain.be; Ian Campbell; Sony Chacko; Rajesh
>Borundia; David Miller; netdev
>Subject: Re: BUG in netxen_release_tx_buffers when TSO enabled on
>kernels >= 3.3 and <= 3.6
>
>On Tue, 2013-01-22 at 19:36 +0000, Ben Hutchings wrote:
>
>> There's another bug right here, which is that 0 is a valid DMA address
>> in some systems. The driver should be calling pci_dma_mapping_error()
>> to find out whether an address is valid or not. But it also wants to
>be
>> able to assign an invalid address to netxen_skb_frag::dma, and
>> unfortunately there is no way to do that in the current DMA API.
>>
>
>I guess we should only test ->frag_count then, and set it to 0 in TX
>completion path.
>
We will send a patch with the suggested fix.
^ permalink raw reply
* Re: [PATCH v5 04/45] percpu_rwlock: Implement the core design of Per-CPU Reader-Writer Locks
From: Tejun Heo @ 2013-01-23 19:57 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: tglx, peterz, oleg, paulmck, rusty, mingo, akpm, namhyung,
rostedt, wangyun, xiaoguangrong, rjw, sbw, fweisbec, linux,
nikunj, linux-pm, linux-arch, linux-arm-kernel, linuxppc-dev,
netdev, linux-doc, linux-kernel
In-Reply-To: <51003B20.2060506@linux.vnet.ibm.com>
Hello, Srivatsa.
On Thu, Jan 24, 2013 at 01:03:52AM +0530, Srivatsa S. Bhat wrote:
> Hmm.. I split it up into steps to help explain the reasoning behind
> the code sufficiently, rather than spring all of the intricacies at
> one go (which would make it very hard to write the changelog/comments
> also). The split made it easier for me to document it well in the
> changelog, because I could deal with reasonable chunks of code/complexity
> at a time. IMHO that helps people reading it for the first time to
> understand the logic easily.
I don't know. It's a judgement call I guess. I personally would much
prefer having ample documentation as comments in the source itself or
as a separate Documentation/ file as that's what most people are gonna
be looking at to figure out what's going on. Maybe just compact it a
bit and add more in-line documentation instead?
> > The only two options are either punishing writers or identifying and
> > updating all such possible deadlocks. percpu_rwsem does the former,
> > right? I don't know how feasible the latter would be.
>
> I don't think we can avoid looking into all the possible deadlocks,
> as long as we use rwlocks inside get/put_online_cpus_atomic() (assuming
> rwlocks are fair). Even with Oleg's idea of using synchronize_sched()
> at the writer, we still need to take care of locking rules, because the
> synchronize_sched() only helps avoid the memory barriers at the reader,
> and doesn't help get rid of the rwlocks themselves.
Well, percpu_rwlock don't have to use rwlock for the slow path. It
can implement its own writer starving locking scheme. It's not like
implementing slow path global rwlock logic is difficult.
> CPU 0 CPU 1
>
> read_lock(&rwlock)
>
> write_lock(&rwlock) //spins, because CPU 0
> //has acquired the lock for read
>
> read_lock(&rwlock)
> ^^^^^
> What happens here? Does CPU 0 start spinning (and hence deadlock) or will
> it continue realizing that it already holds the rwlock for read?
I don't think rwlock allows nesting write lock inside read lock.
read_lock(); write_lock() will always deadlock.
Thanks.
--
tejun
^ permalink raw reply
* pull request: wireless 2013-01-23
From: John W. Linville @ 2013-01-23 20:16 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 18148 bytes --]
Dave,
This is a batch of fixes intende for the 3.8 stream.
Regarding the iwlwifi bits, Johannes says this:
"Please pull to get a single fix from Emmanuel for a bug I introduced due
to misunderstanding the code."
Regarding the mac80211 bits, Johannes says this:
"I have a few small fixes for you:
* some mesh frames would cause encryption warnings -- fixes from Bob
* scanning would pretty much break an association if we transmitted
anything to the AP while scanning -- fix from Stanislaw
* mode injection was broken by channel contexts -- fix from Felix
* FT roaming was broken: hardware crypto would get disabled by it"
Along with that, a handful of other fixes confined to specific drivers.
Avinash Patil fixes a typo in a NULL check in mwifiex.
Larry Finger fixes a build warning in rtlwifi. Seems safe...
Stanislaw Gruszka fixes iwlegacy to prevent microcode errors when
switching from IBSS mode to STA mode.
Felix Fietkau provides a trio of ath9k fixes related to proper tuning.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 5d0feaff230c0abfe4a112e6f09f096ed99e0b2d:
r8169: remove the obsolete and incorrect AMD workaround (2013-01-23 13:51:47 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to e91d1694d362f065c51eb07b46b19e8b33c92777:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-01-23 14:34:00 -0500)
----------------------------------------------------------------
Avinash Patil (1):
mwifiex: fix typo in PCIe adapter NULL check
Bob Copeland (2):
mac80211: set NEED_TXPROCESSING for PERR frames
mac80211: add encrypt headroom to PERR frames
Emmanuel Grumbach (1):
iwlwifi: audit single frames from AGG queue in RS
Felix Fietkau (4):
mac80211: fix monitor mode injection
ath9k_hw: fix calibration issues on chainmask that don't include chain 0
ath9k_hw: fix chain swap setting when setting rx chainmask to 5
ath9k: allow setting arbitrary antenna masks on AR9003+
Johannes Berg (1):
mac80211: fix FT roaming
John W. Linville (3):
Merge branch 'for-john' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
Merge branch 'for-john' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Larry Finger (1):
rtlwifi: Fix build warning introduced by commit a290593
Stanislaw Gruszka (2):
mac80211: synchronize scan off/on-channel and PS states
iwlegacy: fix IBSS cleanup
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 2 ++
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 27 ++++++---------------
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 3 +++
drivers/net/wireless/iwlegacy/common.c | 35 +++++++++++----------------
drivers/net/wireless/iwlwifi/dvm/tx.c | 2 ++
drivers/net/wireless/mwifiex/pcie.c | 2 +-
drivers/net/wireless/rtlwifi/Kconfig | 4 +--
net/mac80211/cfg.c | 12 ++++++++-
net/mac80211/ieee80211_i.h | 6 ++---
net/mac80211/mesh_hwmp.c | 5 +++-
net/mac80211/offchannel.c | 19 ++++++---------
net/mac80211/scan.c | 15 ++++--------
net/mac80211/tx.c | 9 ++++---
14 files changed, 67 insertions(+), 75 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index 8b0d8dc..56317b0 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -976,6 +976,8 @@ static bool ar9003_hw_init_cal(struct ath_hw *ah,
AR_PHY_CL_TAB_1,
AR_PHY_CL_TAB_2 };
+ ar9003_hw_set_chain_masks(ah, ah->caps.rx_chainmask, ah->caps.tx_chainmask);
+
if (rtt) {
if (!ar9003_hw_rtt_restore(ah, chan))
run_rtt_cal = true;
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index ce19c09..3afc24b 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -586,32 +586,19 @@ static void ar9003_hw_init_bb(struct ath_hw *ah,
ath9k_hw_synth_delay(ah, chan, synthDelay);
}
-static void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
+void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
{
- switch (rx) {
- case 0x5:
+ if (ah->caps.tx_chainmask == 5 || ah->caps.rx_chainmask == 5)
REG_SET_BIT(ah, AR_PHY_ANALOG_SWAP,
AR_PHY_SWAP_ALT_CHAIN);
- case 0x3:
- case 0x1:
- case 0x2:
- case 0x7:
- REG_WRITE(ah, AR_PHY_RX_CHAINMASK, rx);
- REG_WRITE(ah, AR_PHY_CAL_CHAINMASK, rx);
- break;
- default:
- break;
- }
+
+ REG_WRITE(ah, AR_PHY_RX_CHAINMASK, rx);
+ REG_WRITE(ah, AR_PHY_CAL_CHAINMASK, rx);
if ((ah->caps.hw_caps & ATH9K_HW_CAP_APM) && (tx == 0x7))
- REG_WRITE(ah, AR_SELFGEN_MASK, 0x3);
- else
- REG_WRITE(ah, AR_SELFGEN_MASK, tx);
+ tx = 3;
- if (tx == 0x5) {
- REG_SET_BIT(ah, AR_PHY_ANALOG_SWAP,
- AR_PHY_SWAP_ALT_CHAIN);
- }
+ REG_WRITE(ah, AR_SELFGEN_MASK, tx);
}
/*
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 7f1a8e9..9d26fc5 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -1066,6 +1066,7 @@ void ar9003_paprd_setup_gain_table(struct ath_hw *ah, int chain);
int ar9003_paprd_init_table(struct ath_hw *ah);
bool ar9003_paprd_is_done(struct ath_hw *ah);
bool ar9003_is_paprd_enabled(struct ath_hw *ah);
+void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx);
/* Hardware family op attach helpers */
void ar5008_hw_attach_phy_ops(struct ath_hw *ah);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 3796e65..dd91f8f 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1826,6 +1826,9 @@ static u32 fill_chainmask(u32 cap, u32 new)
static bool validate_antenna_mask(struct ath_hw *ah, u32 val)
{
+ if (AR_SREV_9300_20_OR_LATER(ah))
+ return true;
+
switch (val & 0x7) {
case 0x1:
case 0x3:
diff --git a/drivers/net/wireless/iwlegacy/common.c b/drivers/net/wireless/iwlegacy/common.c
index 7e16d10..90b8970 100644
--- a/drivers/net/wireless/iwlegacy/common.c
+++ b/drivers/net/wireless/iwlegacy/common.c
@@ -3958,17 +3958,21 @@ il_connection_init_rx_config(struct il_priv *il)
memset(&il->staging, 0, sizeof(il->staging));
- if (!il->vif) {
+ switch (il->iw_mode) {
+ case NL80211_IFTYPE_UNSPECIFIED:
il->staging.dev_type = RXON_DEV_TYPE_ESS;
- } else if (il->vif->type == NL80211_IFTYPE_STATION) {
+ break;
+ case NL80211_IFTYPE_STATION:
il->staging.dev_type = RXON_DEV_TYPE_ESS;
il->staging.filter_flags = RXON_FILTER_ACCEPT_GRP_MSK;
- } else if (il->vif->type == NL80211_IFTYPE_ADHOC) {
+ break;
+ case NL80211_IFTYPE_ADHOC:
il->staging.dev_type = RXON_DEV_TYPE_IBSS;
il->staging.flags = RXON_FLG_SHORT_PREAMBLE_MSK;
il->staging.filter_flags =
RXON_FILTER_BCON_AWARE_MSK | RXON_FILTER_ACCEPT_GRP_MSK;
- } else {
+ break;
+ default:
IL_ERR("Unsupported interface type %d\n", il->vif->type);
return;
}
@@ -4550,8 +4554,7 @@ out:
EXPORT_SYMBOL(il_mac_add_interface);
static void
-il_teardown_interface(struct il_priv *il, struct ieee80211_vif *vif,
- bool mode_change)
+il_teardown_interface(struct il_priv *il, struct ieee80211_vif *vif)
{
lockdep_assert_held(&il->mutex);
@@ -4560,9 +4563,7 @@ il_teardown_interface(struct il_priv *il, struct ieee80211_vif *vif,
il_force_scan_end(il);
}
- if (!mode_change)
- il_set_mode(il);
-
+ il_set_mode(il);
}
void
@@ -4575,8 +4576,8 @@ il_mac_remove_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
WARN_ON(il->vif != vif);
il->vif = NULL;
-
- il_teardown_interface(il, vif, false);
+ il->iw_mode = NL80211_IFTYPE_UNSPECIFIED;
+ il_teardown_interface(il, vif);
memset(il->bssid, 0, ETH_ALEN);
D_MAC80211("leave\n");
@@ -4685,18 +4686,10 @@ il_mac_change_interface(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
}
/* success */
- il_teardown_interface(il, vif, true);
vif->type = newtype;
vif->p2p = false;
- err = il_set_mode(il);
- WARN_ON(err);
- /*
- * We've switched internally, but submitting to the
- * device may have failed for some reason. Mask this
- * error, because otherwise mac80211 will not switch
- * (and set the interface type back) and we'll be
- * out of sync with it.
- */
+ il->iw_mode = newtype;
+ il_teardown_interface(il, vif);
err = 0;
out:
diff --git a/drivers/net/wireless/iwlwifi/dvm/tx.c b/drivers/net/wireless/iwlwifi/dvm/tx.c
index a790599..31534f7 100644
--- a/drivers/net/wireless/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
@@ -1079,6 +1079,8 @@ static void iwlagn_set_tx_status(struct iwl_priv *priv,
{
u16 status = le16_to_cpu(tx_resp->status.status);
+ info->flags &= ~IEEE80211_TX_CTL_AMPDU;
+
info->status.rates[0].count = tx_resp->failure_frame + 1;
info->flags |= iwl_tx_status_to_mac80211(status);
iwlagn_hwrate_to_tx_control(priv, le32_to_cpu(tx_resp->rate_n_flags),
diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c
index 13fbc4e..b879e13 100644
--- a/drivers/net/wireless/mwifiex/pcie.c
+++ b/drivers/net/wireless/mwifiex/pcie.c
@@ -161,7 +161,7 @@ static int mwifiex_pcie_suspend(struct pci_dev *pdev, pm_message_t state)
if (pdev) {
card = (struct pcie_service_card *) pci_get_drvdata(pdev);
- if (!card || card->adapter) {
+ if (!card || !card->adapter) {
pr_err("Card or adapter structure is not valid\n");
return 0;
}
diff --git a/drivers/net/wireless/rtlwifi/Kconfig b/drivers/net/wireless/rtlwifi/Kconfig
index 21b1bbb..b80bc46 100644
--- a/drivers/net/wireless/rtlwifi/Kconfig
+++ b/drivers/net/wireless/rtlwifi/Kconfig
@@ -57,12 +57,12 @@ config RTL8192CU
config RTLWIFI
tristate
- depends on RTL8192CE || RTL8192CU || RTL8192SE || RTL8192DE
+ depends on RTL8192CE || RTL8192CU || RTL8192SE || RTL8192DE || RTL8723AE
default m
config RTLWIFI_DEBUG
bool "Additional debugging output"
- depends on RTL8192CE || RTL8192CU || RTL8192SE || RTL8192DE
+ depends on RTL8192CE || RTL8192CU || RTL8192SE || RTL8192DE || RTL8723AE
default y
config RTL8192C_COMMON
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 47e0aca..516fbc9 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -164,7 +164,17 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
sta = sta_info_get(sdata, mac_addr);
else
sta = sta_info_get_bss(sdata, mac_addr);
- if (!sta) {
+ /*
+ * The ASSOC test makes sure the driver is ready to
+ * receive the key. When wpa_supplicant has roamed
+ * using FT, it attempts to set the key before
+ * association has completed, this rejects that attempt
+ * so it will set the key again after assocation.
+ *
+ * TODO: accept the key if we have a station entry and
+ * add it to the device after the station.
+ */
+ if (!sta || !test_sta_flag(sta, WLAN_STA_ASSOC)) {
ieee80211_key_free(sdata->local, key);
err = -ENOENT;
goto out_unlock;
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 8563b9a..2ed065c 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1358,10 +1358,8 @@ int ieee80211_request_sched_scan_stop(struct ieee80211_sub_if_data *sdata);
void ieee80211_sched_scan_stopped_work(struct work_struct *work);
/* off-channel helpers */
-void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local,
- bool offchannel_ps_enable);
-void ieee80211_offchannel_return(struct ieee80211_local *local,
- bool offchannel_ps_disable);
+void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local);
+void ieee80211_offchannel_return(struct ieee80211_local *local);
void ieee80211_roc_setup(struct ieee80211_local *local);
void ieee80211_start_next_roc(struct ieee80211_local *local);
void ieee80211_roc_purge(struct ieee80211_sub_if_data *sdata);
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index 47aeee2..2659e42 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -215,6 +215,7 @@ static void prepare_frame_for_deferred_tx(struct ieee80211_sub_if_data *sdata,
skb->priority = 7;
info->control.vif = &sdata->vif;
+ info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
ieee80211_set_qos_hdr(sdata, skb);
}
@@ -246,11 +247,13 @@ int mesh_path_error_tx(u8 ttl, u8 *target, __le32 target_sn,
return -EAGAIN;
skb = dev_alloc_skb(local->tx_headroom +
+ IEEE80211_ENCRYPT_HEADROOM +
+ IEEE80211_ENCRYPT_TAILROOM +
hdr_len +
2 + 15 /* PERR IE */);
if (!skb)
return -1;
- skb_reserve(skb, local->tx_headroom);
+ skb_reserve(skb, local->tx_headroom + IEEE80211_ENCRYPT_HEADROOM);
mgmt = (struct ieee80211_mgmt *) skb_put(skb, hdr_len);
memset(mgmt, 0, hdr_len);
mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index a5379ae..a3ad4c3 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -102,8 +102,7 @@ static void ieee80211_offchannel_ps_disable(struct ieee80211_sub_if_data *sdata)
ieee80211_sta_reset_conn_monitor(sdata);
}
-void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local,
- bool offchannel_ps_enable)
+void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata;
@@ -134,8 +133,7 @@ void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local,
if (sdata->vif.type != NL80211_IFTYPE_MONITOR) {
netif_tx_stop_all_queues(sdata->dev);
- if (offchannel_ps_enable &&
- (sdata->vif.type == NL80211_IFTYPE_STATION) &&
+ if (sdata->vif.type == NL80211_IFTYPE_STATION &&
sdata->u.mgd.associated)
ieee80211_offchannel_ps_enable(sdata);
}
@@ -143,8 +141,7 @@ void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local,
mutex_unlock(&local->iflist_mtx);
}
-void ieee80211_offchannel_return(struct ieee80211_local *local,
- bool offchannel_ps_disable)
+void ieee80211_offchannel_return(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata;
@@ -163,11 +160,9 @@ void ieee80211_offchannel_return(struct ieee80211_local *local,
continue;
/* Tell AP we're back */
- if (offchannel_ps_disable &&
- sdata->vif.type == NL80211_IFTYPE_STATION) {
- if (sdata->u.mgd.associated)
- ieee80211_offchannel_ps_disable(sdata);
- }
+ if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+ sdata->u.mgd.associated)
+ ieee80211_offchannel_ps_disable(sdata);
if (sdata->vif.type != NL80211_IFTYPE_MONITOR) {
/*
@@ -385,7 +380,7 @@ void ieee80211_sw_roc_work(struct work_struct *work)
local->tmp_channel = NULL;
ieee80211_hw_config(local, 0);
- ieee80211_offchannel_return(local, true);
+ ieee80211_offchannel_return(local);
}
ieee80211_recalc_idle(local);
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index d59fc68..bf82e69 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -292,7 +292,7 @@ static void __ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted,
if (!was_hw_scan) {
ieee80211_configure_filter(local);
drv_sw_scan_complete(local);
- ieee80211_offchannel_return(local, true);
+ ieee80211_offchannel_return(local);
}
ieee80211_recalc_idle(local);
@@ -341,7 +341,7 @@ static int ieee80211_start_sw_scan(struct ieee80211_local *local)
local->next_scan_state = SCAN_DECISION;
local->scan_channel_idx = 0;
- ieee80211_offchannel_stop_vifs(local, true);
+ ieee80211_offchannel_stop_vifs(local);
ieee80211_configure_filter(local);
@@ -678,12 +678,8 @@ static void ieee80211_scan_state_suspend(struct ieee80211_local *local,
local->scan_channel = NULL;
ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
- /*
- * Re-enable vifs and beaconing. Leave PS
- * in off-channel state..will put that back
- * on-channel at the end of scanning.
- */
- ieee80211_offchannel_return(local, false);
+ /* disable PS */
+ ieee80211_offchannel_return(local);
*next_delay = HZ / 5;
/* afterwards, resume scan & go to next channel */
@@ -693,8 +689,7 @@ static void ieee80211_scan_state_suspend(struct ieee80211_local *local,
static void ieee80211_scan_state_resume(struct ieee80211_local *local,
unsigned long *next_delay)
{
- /* PS already is in off-channel mode */
- ieee80211_offchannel_stop_vifs(local, false);
+ ieee80211_offchannel_stop_vifs(local);
if (local->ops->flush) {
drv_flush(local, false);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index e9eadc4..467c1d1 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1673,10 +1673,13 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
chanctx_conf =
rcu_dereference(tmp_sdata->vif.chanctx_conf);
}
- if (!chanctx_conf)
- goto fail_rcu;
- chan = chanctx_conf->def.chan;
+ if (chanctx_conf)
+ chan = chanctx_conf->def.chan;
+ else if (!local->use_chanctx)
+ chan = local->_oper_channel;
+ else
+ goto fail_rcu;
/*
* Frame injection is not allowed if beaconing is not allowed
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: [PATCH v3 1/1 net-next] net: fec: enable pause frame to improve rx prefomance for 1G network
From: Ben Hutchings @ 2013-01-23 20:39 UTC (permalink / raw)
To: Frank Li
Cc: lznuaa, shawn.guo, B38611, davem, linux-arm-kernel, netdev,
s.hauer
In-Reply-To: <1358391358-27977-1-git-send-email-Frank.Li@freescale.com>
On Thu, 2013-01-17 at 10:55 +0800, Frank Li wrote:
> The limition of imx6 internal bus cause fec can't achieve 1G perfomance.
> There will be many packages lost because FIFO over run.
>
> This patch enable pause frame flow control.
[...]
> --- a/drivers/net/ethernet/freescale/fec.c
> +++ b/drivers/net/ethernet/freescale/fec.c
[...]
> +static int fec_enet_set_pauseparam(struct net_device *ndev,
> + struct ethtool_pauseparam *pause)
> +{
> + struct fec_enet_private *fep = netdev_priv(ndev);
> +
> + if (pause->tx_pause != pause->rx_pause) {
> + netdev_info(ndev,
> + "hardware only support enable/disable both tx and rx");
> + return -EINVAL;
> + }
> +
> + fep->pause_flag = 0;
> +
> + /* tx pause must be same as rx pause */
> + fep->pause_flag |= pause->rx_pause ? FEC_PAUSE_FLAG_ENABLE : 0;
> + fep->pause_flag |= pause->autoneg ? FEC_PAUSE_FLAG_AUTONEG : 0;
> +
> + if (pause->rx_pause || pause->autoneg) {
> + fep->phy_dev->supported |= ADVERTISED_Pause;
> + fep->phy_dev->advertising |= ADVERTISED_Pause;
> + } else {
> + fep->phy_dev->supported &= ~ADVERTISED_Pause;
> + fep->phy_dev->advertising &= ~ADVERTISED_Pause;
> + }
[...]
Why is this changing the supported flags, i.e. device capabilities? You
need to leave those flags alone and reject an attempt to enable pause
frames on a device that doesn't support them.
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
* [PATCH] vhost-net: fall back to vmalloc if high-order allocation fails
From: Romain Francoise @ 2013-01-23 20:46 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, netdev, linux-kernel
Creating a vhost-net device allocates an object large enough (34320 bytes
on x86-64) to trigger an order-4 allocation, which may fail if memory if
fragmented:
libvirtd: page allocation failure: order:4, mode:0x2000d0
...
SLAB: Unable to allocate memory on node 0 (gfp=0xd0)
cache: size-65536, object size: 65536, order: 4
node 0: slabs: 8/8, objs: 8/8, free: 0
In that situation, rather than forcing the caller to use regular
virtio-net, try to allocate the descriptor with vmalloc().
Signed-off-by: Romain Francoise <romain@orebokech.com>
---
drivers/vhost/net.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index ebd08b2..1ded79b 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -18,6 +18,7 @@
#include <linux/rcupdate.h>
#include <linux/file.h>
#include <linux/slab.h>
+#include <linux/vmalloc.h>
#include <linux/net.h>
#include <linux/if_packet.h>
@@ -603,12 +604,23 @@ static void handle_rx_net(struct vhost_work *work)
handle_rx(net);
}
+static void vhost_net_kvfree(void *addr)
+{
+ if (is_vmalloc_addr(addr))
+ vfree(addr);
+ else
+ kfree(addr);
+}
+
static int vhost_net_open(struct inode *inode, struct file *f)
{
- struct vhost_net *n = kmalloc(sizeof *n, GFP_KERNEL);
+ struct vhost_net *n;
struct vhost_dev *dev;
int r;
+ n = kmalloc(sizeof *n, GFP_KERNEL | __GFP_NOWARN);
+ if (!n)
+ n = vmalloc(sizeof *n);
if (!n)
return -ENOMEM;
@@ -617,7 +629,7 @@ static int vhost_net_open(struct inode *inode, struct file *f)
n->vqs[VHOST_NET_VQ_RX].handle_kick = handle_rx_kick;
r = vhost_dev_init(dev, n->vqs, VHOST_NET_VQ_MAX);
if (r < 0) {
- kfree(n);
+ vhost_net_kvfree(n);
return r;
}
@@ -719,7 +731,7 @@ static int vhost_net_release(struct inode *inode, struct file *f)
/* We do an extra flush before freeing memory,
* since jobs can re-queue themselves. */
vhost_net_flush(n);
- kfree(n);
+ vhost_net_kvfree(n);
return 0;
}
--
1.8.1.1
^ permalink raw reply related
* Re: Doubts about listen backlog and tcp_max_syn_backlog
From: Vijay Subramanian @ 2013-01-23 20:48 UTC (permalink / raw)
To: Leandro Lucarella; +Cc: Rick Jones, Eric Dumazet, netdev, linux-kernel
In-Reply-To: <20130123104736.GK4608@sociomantic.com>
On 23 January 2013 02:47, Leandro Lucarella
<leandro.lucarella@sociomantic.com> wrote:
> On Tue, Jan 22, 2013 at 02:01:09PM -0800, Rick Jones wrote:
>> >>If that is being overflowed, I believe you should be seeing something like:
>> >>
>> >> 14 SYNs to LISTEN sockets dropped
>> >>
>> >>in the output of netstat -s on the system on which the server
>> >>application is running.
>> >
>> >What is that value reporting exactly?
>>
>> Netstat is reporting the ListenDrops and/or ListenOverflows which
>> map to LINUX_MIB_LISTENDROPS and LINUX_MIB_LISTENOVERFLOWS. Those
>> get incremented in tcp_v4_syn_recv_sock() (and its v6 version etc)
>>
>> if (sk_acceptq_is_full(sk))
>> goto exit_overflow;
>>
>> Will increment both overflows and drops, and drops will increment on
>> its own in some additional cases.
Note that tcp_v4_conn_request() can also drop SYNs directly (start of
TWHS) if acceptq is full and more than one young requests are queued
up
vim +1504 tcp_ipv4.c
if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1)
goto drop;
These drops do not seem to be tracked by any MIB variable and so will
not show up in netstat
(Also, newer nstat is preferred to netstat ).
Maybe we need to track these drops too?
Vijay
^ permalink raw reply
* Re: [PATCH] vhost-net: fall back to vmalloc if high-order allocation fails
From: Michael S. Tsirkin @ 2013-01-23 21:04 UTC (permalink / raw)
To: Romain Francoise; +Cc: kvm, netdev, linux-kernel
In-Reply-To: <87k3r31vbc.fsf@silenus.orebokech.com>
On Wed, Jan 23, 2013 at 09:46:47PM +0100, Romain Francoise wrote:
> Creating a vhost-net device allocates an object large enough (34320 bytes
> on x86-64) to trigger an order-4 allocation, which may fail if memory if
> fragmented:
>
> libvirtd: page allocation failure: order:4, mode:0x2000d0
> ...
> SLAB: Unable to allocate memory on node 0 (gfp=0xd0)
> cache: size-65536, object size: 65536, order: 4
> node 0: slabs: 8/8, objs: 8/8, free: 0
>
> In that situation, rather than forcing the caller to use regular
> virtio-net, try to allocate the descriptor with vmalloc().
>
> Signed-off-by: Romain Francoise <romain@orebokech.com>
Thanks for the patch.
Hmm, I haven't seen this.
Maybe we should try and reduce our memory usage,
I will look into this.
> ---
> drivers/vhost/net.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index ebd08b2..1ded79b 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -18,6 +18,7 @@
> #include <linux/rcupdate.h>
> #include <linux/file.h>
> #include <linux/slab.h>
> +#include <linux/vmalloc.h>
>
> #include <linux/net.h>
> #include <linux/if_packet.h>
> @@ -603,12 +604,23 @@ static void handle_rx_net(struct vhost_work *work)
> handle_rx(net);
> }
>
> +static void vhost_net_kvfree(void *addr)
> +{
> + if (is_vmalloc_addr(addr))
> + vfree(addr);
> + else
> + kfree(addr);
> +}
> +
> static int vhost_net_open(struct inode *inode, struct file *f)
> {
> - struct vhost_net *n = kmalloc(sizeof *n, GFP_KERNEL);
> + struct vhost_net *n;
> struct vhost_dev *dev;
> int r;
>
> + n = kmalloc(sizeof *n, GFP_KERNEL | __GFP_NOWARN);
> + if (!n)
> + n = vmalloc(sizeof *n);
> if (!n)
> return -ENOMEM;
>
> @@ -617,7 +629,7 @@ static int vhost_net_open(struct inode *inode, struct file *f)
> n->vqs[VHOST_NET_VQ_RX].handle_kick = handle_rx_kick;
> r = vhost_dev_init(dev, n->vqs, VHOST_NET_VQ_MAX);
> if (r < 0) {
> - kfree(n);
> + vhost_net_kvfree(n);
> return r;
> }
>
> @@ -719,7 +731,7 @@ static int vhost_net_release(struct inode *inode, struct file *f)
> /* We do an extra flush before freeing memory,
> * since jobs can re-queue themselves. */
> vhost_net_flush(n);
> - kfree(n);
> + vhost_net_kvfree(n);
> return 0;
> }
>
> --
> 1.8.1.1
^ permalink raw reply
* Re: [RFC PATCH v2 10/10] ixgbe: Add support for set_channels ethtool operation
From: Ben Hutchings @ 2013-01-23 21:20 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P
Cc: Duyck, Alexander H, netdev@vger.kernel.org, therbert@google.com,
ycai@google.com, eric.dumazet@gmail.com, davem@davemloft.net
In-Reply-To: <1358353807.29335.1.camel@ppwaskie-mobl2>
On Wed, 2013-01-16 at 16:30 +0000, Waskiewicz Jr, Peter P wrote:
> On Wed, 2013-01-16 at 16:19 +0000, Ben Hutchings wrote:
> > On Thu, 2013-01-10 at 10:58 -0800, Alexander Duyck wrote:
> > > This change adds support for the ethtool set_channels operation.
> > >
> > > Since the ixgbe driver has to support DCB as well as the other modes the
> > > assumption I made here is that the number of channels in DCB modes refers
> > > to the number of queues per traffic class, not the number of queues total.
> > >
> > > Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> >
> > In DCB mode are there separate IRQs for the different classes?
>
> Yes. The Rx packet buffer is split into multiple packet buffers, one
> for each online class. After that, it's just queues assigned to the
> packet buffers, and interrupts assigned however you want them to be.
Right, I think we've been through this before. And I can see how it
would be more useful for users to specify number of RX queues per
priority level. But that's not what was specified...
I'm afraid the 'channels' ethtool operations have turned into a mess...
I can't see how to get to a reasonable generic definition of what they
should do.
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: pull request (net-next): ipsec-next 2013-01-23
From: Herbert Xu @ 2013-01-23 21:23 UTC (permalink / raw)
To: David Miller; +Cc: steffen.klassert, netdev
In-Reply-To: <20130123.140058.1653306473705960117.davem@davemloft.net>
On Wed, Jan 23, 2013 at 02:00:58PM -0500, David Miller wrote:
> From: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Wed, 23 Jan 2013 09:18:56 +0100
>
> > 1) Add a statistic counter for invalid output states and
> > remove a superfluous state valid check, from Li RongQing.
> >
> > 2) Probe for asynchronous block ciphers instead of synchronous block
> > ciphers to make the asynchronous variants available even if no
> > synchronous block ciphers are found, from Jussi Kivilinna.
> >
> > 3) Make rfc3686 asynchronous block cipher and make use of
> > the new asynchronous variant, from Jussi Kivilinna.
> >
> > 4) Replace some rwlocks by rcu, from Cong Wang.
> >
> > 5) Remove some unused defines.
> >
> > Please pull or let me know if there are problems.
>
> Pulled, thanks Steffen.
>
> I hope Herbert is ok with the small crypto bits going in this way,
> since they really are IPSEC specific.
No problem at all :)
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Hung tasks related to do_filp_open in net-next (3.8.0-rc3+)
From: Ben Greear @ 2013-01-23 21:38 UTC (permalink / raw)
To: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev
I cranked up my 3000 NFS mounts test case on today's net-next (3.8.0-rc3+)
and about 8 of these splats. There were around 780 mounts active
when these occurred.
Seems like the system continues OK, so not sure how important
this is...
INFO: task btserver:8756 blocked for more than 180 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
btserver D 0000000000000004 0 8756 5781 0x00000080
ffff880404ab1bf8 0000000000000046 0000000004ab1ba8 0000000000000432
ffff880404ab0010 ffff880402263f20 ffff880404ab1fd8 00000000000132c0
00000000000132c0 00000000000132c0 ffff880404ab1fd8 00000000000132c0
Call Trace:
[<ffffffff815491ea>] schedule+0x5f/0x61
[<ffffffff815494fa>] schedule_preempt_disabled+0x13/0x1f
[<ffffffff81547ea8>] __mutex_lock_common+0x264/0x42d
[<ffffffff8115fadb>] ? do_last+0x1db/0xa4e
[<ffffffff8115fadb>] ? do_last+0x1db/0xa4e
[<ffffffff815480d0>] mutex_lock_nested+0x16/0x18
[<ffffffff8115fadb>] do_last+0x1db/0xa4e
[<ffffffff8115f3a5>] ? path_init+0xcd/0x2b6
[<ffffffff8116090b>] path_openat+0xcb/0x363
[<ffffffff810d0055>] ? __lock_acquire+0x1df/0x53d
[<ffffffff81160ca8>] do_filp_open+0x38/0x84
[<ffffffff8154a2db>] ? _raw_spin_unlock+0x45/0x52
[<ffffffff8116c203>] ? __alloc_fd+0x106/0x11a
[<ffffffff815490f9>] ? __schedule+0x561/0x5a3
8021q: adding VLAN 0 to HW filter on device eth4#621
[<ffffffff81153bfc>] do_sys_open+0x6d/0xff
8021q: adding VLAN 0 to HW filter on device eth3#612
[<ffffffff81153cbb>] sys_open+0x1c/0x1e
[<ffffffff8154f629>] system_call_fastpath+0x16/0x1b
2 locks held by btserver/8756:
#0: (sb_writers#10){......}, at: [<ffffffff81170013>] mnt_want_write+0x1f/0x48
#1: (&type->i_mutex_dir_key#4){......}, at: [<ffffffff8115fadb>] do_last+0x1db/0xa4e
--
Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Eric Dumazet @ 2013-01-23 21:43 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, linux-nfs@vger.kernel.org
In-Reply-To: <510028A7.1080902@candelatech.com>
On Wed, 2013-01-23 at 10:15 -0800, Ben Greear wrote:
> On 01/23/2013 05:35 AM, Eric Dumazet wrote:
> > On Tue, 2013-01-22 at 23:14 -0800, Ben Greear wrote:
> >
> >> How are the non-ref-counted dst objects used safely? Any chance
> >> that tearing down the IP protocol on a device (or deleting a device)
> >> could delete a dst that is referenced by an skb (and thus crashes as
> >> I see)?
> >
> > There is probably a bug. Normally it should be RCU protected.
>
> I'm building net-next, and will do some testing on it later today
> if all goes well.
>
> In the meantime, a few questions about RCU.
>
> If the non-ref-counted dst is protected by RCU, does that mean
> that from the time we acquire the pointer (ie, set it in the skb),
> to the time we clear the pointer from the skb, we must be under
> RCU read lock?
>
> If so, that means that ip_rcv_finish must be called under RCU
> read lock, etc?
Obviously yes. Check skb_dst_force() for the rare cases we want to
escape the RCU section.
^ permalink raw reply
* Re: Linux 3.6.x kernel crash in tcp_slow_start / bictcp_cong_avoid with wfica
From: Hannes Frederic Sowa @ 2013-01-23 21:44 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: netdev
In-Reply-To: <20130123161238.GE8912@reaktio.net>
On Wed, Jan 23, 2013 at 06:12:38PM +0200, Pasi Kärkkäinen wrote:
> My laptop running Fedora 17 randomly crashes when using wfica (Citrix Receiver / ICA Client)
> proprietary closed source client for accessing remote desktop server.
> wfica is running as a normal user, so it shouldn't be able to cause a kernel crash.
>
> Crashes seem to happen most often when I use either wlan- or 3G mobile data Internet connection.
> These kernel crashes happen ramdomly, often 1-2 times a week.
> What usually happens is that I notice the Internet connection has died,
> and when I check the kernel dmesg I'm seeing the traceback.
> At this point I'm still able to use the gnome desktop for maybe 1-5 minutes,
> but applications start to fail one by one, and finally everything just halts
> and I need to power cycle the laptop.
Would it be possible to capture a strace -e network, so we could see which
setsockopt combinations are being applied to the socket. Is capturing ss -ioem
in such moments still possible?
Thanks,
Hannes
^ permalink raw reply
* [PATCH v3] IP_GRE: Fix kernel panic in IP_GRE with GRE csum.
From: Pravin B Shelar @ 2013-01-23 21:45 UTC (permalink / raw)
To: netdev; +Cc: jesse, Pravin B Shelar
Due to IP_GRE GSO support, GRE can recieve non linear skb which
results in panic in case of GRE_CSUM.
Following patch fixes it by using correct csum API.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
v3: Coding style Fix.
---
net/ipv4/ip_gre.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 303012a..e81b1ca 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -963,8 +963,12 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb, struct net_device *dev
ptr--;
}
if (tunnel->parms.o_flags&GRE_CSUM) {
+ int offset = skb_transport_offset(skb);
+
*ptr = 0;
- *(__sum16 *)ptr = ip_compute_csum((void *)(iph+1), skb->len - sizeof(struct iphdr));
+ *(__sum16 *)ptr = csum_fold(skb_checksum(skb, offset,
+ skb->len - offset,
+ 0));
}
}
--
1.7.10
^ permalink raw reply related
* [PATCH] netem: fix delay calculation in rate extension
From: Johannes Naab @ 2013-01-23 21:36 UTC (permalink / raw)
To: netdev, hagen
From: Johannes Naab <jn@stusta.de>
The delay calculation with the rate extension introduces in v3.3 does
not properly work, if other packets are still queued for transmission.
For the delay calculation to work, both delay types (latency and delay
introduces by rate limitation) have to be handled differently. The
latency delay for a packet can overlap with the delay of other packets.
The delay introduced by the rate however is separate, and can only
start, once all other rate-introduced delays finished.
Latency delay is from same distribution for each packet, rate delay
depends on the packet size.
.: latency delay
-: rate delay
x: additional delay we have to wait since another packet is currently
transmitted
.....---- Packet 1
.....xx------ Packet 2
.....------ Packet 3
^^^^^
latency stacks
^^
rate delay doesn't stack
^^
latency stacks
-----> time
When a packet is enqueued, we first consider the latency delay. If other
packets are already queued, we can reduce the latency delay until the
last packet in the queue is send, however the latency delay cannot be
<0, since this would mean that the rate is overcommitted. The new
reference point is the time at which the last packet will be send. To
find the time, when the packet should be send, the rate introduces delay
has to be added on top of that.
Signed-off-by: Johannes Naab <jn@stusta.de>
Acked-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
Consider the following setup:
node0 <---> node1
For both nodes, the ARP entries are fixed, so only our IP packets are
considered.
qdisc for node0 outgoing:
tc qdisc add dev eth1 root netem latency 1100ms rate 100Mbps
> $ ping -n -i 1.0 -c 5 10.0.1.1
> PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
> 64 bytes from 10.0.1.1: icmp_req=1 ttl=64 time=1100 ms
> 64 bytes from 10.0.1.1: icmp_req=2 ttl=64 time=1282 ms
> 64 bytes from 10.0.1.1: icmp_req=3 ttl=64 time=1660 ms
> 64 bytes from 10.0.1.1: icmp_req=4 ttl=64 time=2417 ms
>
> --- 10.0.1.1 ping statistics ---
> 5 packets transmitted, 4 received, 20% packet loss, time 4012ms
> rtt min/avg/max/mdev = 1100.461/1615.107/2417.472/505.386 ms, pipe 2
The delay for each packet rises. (For me) the expected behavior would
be, that the delay does not increase with each additional packet.
This is the case if the interval between the pings is increased >1.1s
> $ ping -n -i 1.2 -c 5 10.0.1.1
> PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
> 64 bytes from 10.0.1.1: icmp_req=1 ttl=64 time=1100 ms
> 64 bytes from 10.0.1.1: icmp_req=2 ttl=64 time=1100 ms
> 64 bytes from 10.0.1.1: icmp_req=3 ttl=64 time=1100 ms
> 64 bytes from 10.0.1.1: icmp_req=4 ttl=64 time=1100 ms
> 64 bytes from 10.0.1.1: icmp_req=5 ttl=64 time=1100 ms
>
> --- 10.0.1.1 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4803ms
> rtt min/avg/max/mdev = 1100.407/1100.551/1100.927/0.691 ms
or if the rate is not set
tc qdisc add dev eth1 root netem latency 1100ms
> $ ping -n -i 1.0 -c 5 10.0.1.1
> PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
> 64 bytes from 10.0.1.1: icmp_req=1 ttl=64 time=1100 ms
> 64 bytes from 10.0.1.1: icmp_req=2 ttl=64 time=1100 ms
> 64 bytes from 10.0.1.1: icmp_req=3 ttl=64 time=1100 ms
> 64 bytes from 10.0.1.1: icmp_req=4 ttl=64 time=1100 ms
> 64 bytes from 10.0.1.1: icmp_req=5 ttl=64 time=1100 ms
>
> --- 10.0.1.1 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4011ms
> rtt min/avg/max/mdev = 1100.416/1100.474/1100.553/0.939 ms, pipe 2
The following patch seems to fix the problem. However, since I have no
familiarity with the code, please review it carefully (both from a
logical as a technical point of view).
The following problems might come to mind:
- What happens when the latency or rate is changed?
- How does it play with reordered packets?
- skb_peek_tail(list) is accessed twice, is the lock held, the list
private, or is it a bug waiting to happen?
I developed this patch while doing a student project at
http://www.nav.ei.tum.de/.
net/sched/sch_netem.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 298c0dd..3d2acc7 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -438,18 +438,18 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch)
if (q->rate) {
struct sk_buff_head *list = &sch->q;
- delay += packet_len_2_sched_time(skb->len, q);
-
if (!skb_queue_empty(list)) {
/*
- * Last packet in queue is reference point (now).
- * First packet in queue is already in flight,
- * calculate this time bonus and substract
+ * Last packet in queue is reference point (now),
+ * calculate this time bonus and subtract
* from delay.
*/
- delay -= now - netem_skb_cb(skb_peek(list))->time_to_send;
+ delay -= netem_skb_cb(skb_peek_tail(list))->time_to_send - now;
+ delay = max_t(psched_tdiff_t, 0, delay);
now = netem_skb_cb(skb_peek_tail(list))->time_to_send;
}
+
+ delay += packet_len_2_sched_time(skb->len, q);
}
cb->time_to_send = now + delay;
^ permalink raw reply related
* [PATCH] iproute2: tc netem rate: allow negative packet/cell overhead
From: Johannes Naab @ 2013-01-23 21:38 UTC (permalink / raw)
To: netdev
From: Johannes Naab <jn@stusta.de>
by fixing the parsing of command-line tokens
Signed-off-by: Johannes Naab <jn@stusta.de>
---
The packet or cell overhead used with the rate extension can be negative. The
man page tc-netem(8) documents this. However, iproute2 currently does not
detect negative numbers as valid token.
> $ tc qdisc add dev eth0 root netem rate 1024bps -14
> What is "-14"?
> Usage: ... netem [ limit PACKETS ]
I developed this patch while doing a student project at
http://www.nav.ei.tum.de/.
tc/q_netem.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tc/q_netem.c b/tc/q_netem.c
index f8489e9..2583072 100644
--- a/tc/q_netem.c
+++ b/tc/q_netem.c
@@ -147,6 +147,8 @@ static int get_distribution(const char *type, __s16 *data, int maxdata)
}
#define NEXT_IS_NUMBER() (NEXT_ARG_OK() && isdigit(argv[1][0]))
+#define NEXT_IS_SIGNED_NUMBER() \
+ (NEXT_ARG_OK() && (isdigit(argv[1][0]) || argv[1][0] == '-'))
/* Adjust for the fact that psched_ticks aren't always usecs
(based on kernel PSCHED_CLOCK configuration */
@@ -393,7 +395,7 @@ static int netem_parse_opt(struct qdisc_util *qu, int argc, char **argv,
explain1("rate");
return -1;
}
- if (NEXT_IS_NUMBER()) {
+ if (NEXT_IS_SIGNED_NUMBER()) {
NEXT_ARG();
if (get_s32(&rate.packet_overhead, *argv, 0)) {
explain1("rate");
@@ -407,7 +409,7 @@ static int netem_parse_opt(struct qdisc_util *qu, int argc, char **argv,
return -1;
}
}
- if (NEXT_IS_NUMBER()) {
+ if (NEXT_IS_SIGNED_NUMBER()) {
NEXT_ARG();
if (get_s32(&rate.cell_overhead, *argv, 0)) {
explain1("rate");
^ permalink raw reply related
* Re: Linux 3.6.x kernel crash in tcp_slow_start / bictcp_cong_avoid with wfica
From: Pasi Kärkkäinen @ 2013-01-23 21:51 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130123214445.GA16641@order.stressinduktion.org>
On Wed, Jan 23, 2013 at 10:44:45PM +0100, Hannes Frederic Sowa wrote:
> On Wed, Jan 23, 2013 at 06:12:38PM +0200, Pasi Kärkkäinen wrote:
> > My laptop running Fedora 17 randomly crashes when using wfica (Citrix Receiver / ICA Client)
> > proprietary closed source client for accessing remote desktop server.
> > wfica is running as a normal user, so it shouldn't be able to cause a kernel crash.
> >
> > Crashes seem to happen most often when I use either wlan- or 3G mobile data Internet connection.
> > These kernel crashes happen ramdomly, often 1-2 times a week.
> > What usually happens is that I notice the Internet connection has died,
> > and when I check the kernel dmesg I'm seeing the traceback.
> > At this point I'm still able to use the gnome desktop for maybe 1-5 minutes,
> > but applications start to fail one by one, and finally everything just halts
> > and I need to power cycle the laptop.
>
> Would it be possible to capture a strace -e network, so we could see which
> setsockopt combinations are being applied to the socket. Is capturing ss -ioem
> in such moments still possible?
>
I don't think I'm able to strace or anything at that point..
It took me at least 10 tries (=crashes) before I was able to "dmesg > log.txt" successfully ..
(usually writing/redirecting to a file fails because the disk/fs is already unavailable..)
I can always try though!
Any other ideas?
-- Pasi
^ permalink raw reply
* Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
From: Ben Greear @ 2013-01-23 21:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1358952122.12374.791.camel@edumazet-glaptop>
On 01/23/2013 06:42 AM, Eric Dumazet wrote:
> On Tue, 2013-01-22 at 23:14 -0800, Ben Greear wrote:
>
>> I suspect the bug goes back at least as far as 3.3. And since
>> I need the NFS patches for this test case, bisecting will be pure hell.
>
> Make sure the bug is still present in net-next.
>
My test case isn't running well on net-next. Seems most
of the file-io processes are hung trying to open a file:
[root@lf1011-12060006 lanforge]# cat /proc/10612/stack
[<ffffffff8115fadb>] do_last+0x1db/0xa4e
[<ffffffff8116090b>] path_openat+0xcb/0x363
[<ffffffff81160ca8>] do_filp_open+0x38/0x84
[<ffffffff81153bfc>] do_sys_open+0x6d/0xff
[<ffffffff81153cbb>] sys_open+0x1c/0x1e
[<ffffffff8154f629>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
I'm going back to 3.7.3 and will try to learn some more
about what it's doing there.
Thanks,
Ben
--
Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 v3] IP_GRE: Fix kernel panic in IP_GRE with GRE csum.
From: Eric Dumazet @ 2013-01-23 22:00 UTC (permalink / raw)
To: Pravin B Shelar; +Cc: netdev, jesse
In-Reply-To: <1358977542-1627-1-git-send-email-pshelar@nicira.com>
On Wed, 2013-01-23 at 13:45 -0800, Pravin B Shelar wrote:
> Due to IP_GRE GSO support, GRE can recieve non linear skb which
> results in panic in case of GRE_CSUM.
> Following patch fixes it by using correct csum API.
>
> Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
> ---
> v3: Coding style Fix.
More precisely, this comes from SG (Scatter Gather) support, not GSO.
Bug introduced in commit 6b78f16e4bdde3936b
(gre: add GSO support)
Acked-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: Linux 3.6.x kernel crash in tcp_slow_start / bictcp_cong_avoid with wfica
From: Hannes Frederic Sowa @ 2013-01-23 22:00 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: netdev
In-Reply-To: <20130123215151.GF8912@reaktio.net>
On Wed, Jan 23, 2013 at 11:51:51PM +0200, Pasi Kärkkäinen wrote:
> On Wed, Jan 23, 2013 at 10:44:45PM +0100, Hannes Frederic Sowa wrote:
> > On Wed, Jan 23, 2013 at 06:12:38PM +0200, Pasi Kärkkäinen wrote:
> > > My laptop running Fedora 17 randomly crashes when using wfica (Citrix Receiver / ICA Client)
> > > proprietary closed source client for accessing remote desktop server.
> > > wfica is running as a normal user, so it shouldn't be able to cause a kernel crash.
> > >
> > > Crashes seem to happen most often when I use either wlan- or 3G mobile data Internet connection.
> > > These kernel crashes happen ramdomly, often 1-2 times a week.
> > > What usually happens is that I notice the Internet connection has died,
> > > and when I check the kernel dmesg I'm seeing the traceback.
> > > At this point I'm still able to use the gnome desktop for maybe 1-5 minutes,
> > > but applications start to fail one by one, and finally everything just halts
> > > and I need to power cycle the laptop.
> >
> > Would it be possible to capture a strace -e network, so we could see which
> > setsockopt combinations are being applied to the socket. Is capturing ss -ioem
> > in such moments still possible?
> >
>
> I don't think I'm able to strace or anything at that point..
> It took me at least 10 tries (=crashes) before I was able to "dmesg > log.txt" successfully ..
> (usually writing/redirecting to a file fails because the disk/fs is already unavailable..)
The strace can be done without the system going downhill. Instead of
-e network, "-e socket,connect,setsockopt,getsockopt,shutdown,close"
can be used to reduce the output.
^ permalink raw reply
* Re: Linux 3.6.x kernel crash in tcp_slow_start / bictcp_cong_avoid with wfica
From: Eric Dumazet @ 2013-01-23 22:25 UTC (permalink / raw)
To: Pasi Kärkkäinen; +Cc: netdev
In-Reply-To: <20130123215151.GF8912@reaktio.net>
On Wed, 2013-01-23 at 23:51 +0200, Pasi Kärkkäinen wrote:
> On Wed, Jan 23, 2013 at 10:44:45PM +0100, Hannes Frederic Sowa wrote:
> > On Wed, Jan 23, 2013 at 06:12:38PM +0200, Pasi Kärkkäinen wrote:
> > > My laptop running Fedora 17 randomly crashes when using wfica (Citrix Receiver / ICA Client)
> > > proprietary closed source client for accessing remote desktop server.
> > > wfica is running as a normal user, so it shouldn't be able to cause a kernel crash.
> > >
> > > Crashes seem to happen most often when I use either wlan- or 3G mobile data Internet connection.
> > > These kernel crashes happen ramdomly, often 1-2 times a week.
> > > What usually happens is that I notice the Internet connection has died,
> > > and when I check the kernel dmesg I'm seeing the traceback.
> > > At this point I'm still able to use the gnome desktop for maybe 1-5 minutes,
> > > but applications start to fail one by one, and finally everything just halts
> > > and I need to power cycle the laptop.
> >
> > Would it be possible to capture a strace -e network, so we could see which
> > setsockopt combinations are being applied to the socket. Is capturing ss -ioem
> > in such moments still possible?
> >
>
> I don't think I'm able to strace or anything at that point..
> It took me at least 10 tries (=crashes) before I was able to "dmesg > log.txt" successfully ..
> (usually writing/redirecting to a file fails because the disk/fs is already unavailable..)
>
> I can always try though!
>
> Any other ideas?
Something sets tp->snd_cwnd to 0, and thats a bug.
^ permalink raw reply
* Re: [RFC PATCH v2 10/10] ixgbe: Add support for set_channels ethtool operation
From: Alexander Duyck @ 2013-01-23 22:31 UTC (permalink / raw)
To: Ben Hutchings
Cc: Waskiewicz Jr, Peter P, netdev@vger.kernel.org,
therbert@google.com, ycai@google.com, eric.dumazet@gmail.com,
davem@davemloft.net
In-Reply-To: <1358976045.2658.18.camel@bwh-desktop.uk.solarflarecom.com>
On 01/23/2013 01:20 PM, Ben Hutchings wrote:
> On Wed, 2013-01-16 at 16:30 +0000, Waskiewicz Jr, Peter P wrote:
>> On Wed, 2013-01-16 at 16:19 +0000, Ben Hutchings wrote:
>>> On Thu, 2013-01-10 at 10:58 -0800, Alexander Duyck wrote:
>>>> This change adds support for the ethtool set_channels operation.
>>>>
>>>> Since the ixgbe driver has to support DCB as well as the other modes the
>>>> assumption I made here is that the number of channels in DCB modes refers
>>>> to the number of queues per traffic class, not the number of queues total.
>>>>
>>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>>> In DCB mode are there separate IRQs for the different classes?
>> Yes. The Rx packet buffer is split into multiple packet buffers, one
>> for each online class. After that, it's just queues assigned to the
>> packet buffers, and interrupts assigned however you want them to be.
> Right, I think we've been through this before. And I can see how it
> would be more useful for users to specify number of RX queues per
> priority level. But that's not what was specified...
>
> I'm afraid the 'channels' ethtool operations have turned into a mess...
> I can't see how to get to a reasonable generic definition of what they
> should do.
>
> Ben.
Actually it looks like most of the drivers (I looked at bnx, bnx2x, tg3,
and qlcnic) are using the set_queues call in a similar way. What they
end up doing is using the value and plugging it into their TSS/RSS
fields in their private structures. From what I can tell in
bnx2x_setup_tc they may do exactly the same thing we are currently doing
for DCB since they use the BNX2X_NUM_ETH_QUEUES value that they set in
their set_channels call to set the number of queues they use per traffic
class. I would say the usage is actually pretty consistent between
bnx2x and ixgbe based on this, even if it isn't exactly correct.
For now I would say all of the drivers are using the set_channels
operation to specify the number of Tx/Rx queues, or queue pairs per
traffic class. So for non-DCB NICs this means it is setting exactly
that number of queues, and for DCB capable nics it means num_tcs times
the specified number of queues.
Thanks,
Alex
^ permalink raw reply
* [net-next 00/14][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2013-01-23 22:44 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
This series contains updates to ixgbe and ixgbevf. Majority of the
changes are against ixgbe PTP and SR-IOV.
The following are changes since commit 93b9c1ddd3fb4a5b67d512e534b30070f9ecec28:
Merge branch 'testing' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Alexander Duyck (1):
ixgbe: Inline Rx PTP descriptor handling
Donald Dutile (1):
ixgbe: Limit number of reported VFs to device specific value
Greg Rose (4):
ixgbe: Make mailbox ops initialization unconditional
ixgbe: Modularize SR-IOV enablement code
ixgbe: Implement PCI SR-IOV sysfs callback operation
ixgbevf: Fix link speed message to support 100Mbps
Jacob Keller (8):
ixgbe: ethtool ixgbe_diag_test cleanup
ixgbe: add missing supported filters to get_ts_info
ixgbe: Update ptp_overflow check comment and jiffies
ixgbe: Use watchdog check in favor of BPF for detecting latched
timestamp
ixgbe: Add ptp work item to poll for the Tx timestamp
ixgbe: add warning when scheduling reset
ixgbe: Fix overwriting of rx_mtrl in ixgbe_ptp_hwtstamp_ioctl
ixgbe: only compile ixgbe_debugfs.o when enabled
drivers/net/ethernet/intel/ixgbe/Makefile | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 34 +++-
drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c | 5 -
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 46 +++--
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 62 +++++-
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 221 ++++++++++------------
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 192 ++++++++++++++-----
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.h | 6 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 19 +-
9 files changed, 375 insertions(+), 213 deletions(-)
--
1.7.11.7
^ permalink raw reply
* [net-next 01/14] ixgbe: ethtool ixgbe_diag_test cleanup
From: Jeff Kirsher @ 2013-01-23 22:44 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1358981090-5794-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
This patch cleans up the ethtool diagnostics test by ensuring that the tests
work properly regardless of what state the adapter was in. The SRIOV VF check is
done at the beginning, forgoing the link test. The if_running -> dev_close is
moved before the link test, as well as a call to enable the Tx laser. This
ensures that the link test will return valid results even when adapter was
previously down. Also, a call to disable the Tx laser is added if the device
was down before the start. This ensures consistent behavior of the Tx laser
before and after the diagnostic checks. The end result is consistent behavior
regardless of device state.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 38 ++++++++++++++++--------
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 3268584..21bc72e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -1837,19 +1837,11 @@ static void ixgbe_diag_test(struct net_device *netdev,
struct ethtool_test *eth_test, u64 *data)
{
struct ixgbe_adapter *adapter = netdev_priv(netdev);
+ struct ixgbe_hw *hw = &adapter->hw;
bool if_running = netif_running(netdev);
set_bit(__IXGBE_TESTING, &adapter->state);
if (eth_test->flags == ETH_TEST_FL_OFFLINE) {
- /* Offline tests */
-
- e_info(hw, "offline testing starting\n");
-
- /* Link test performed before hardware reset so autoneg doesn't
- * interfere with test result */
- if (ixgbe_link_test(adapter, &data[4]))
- eth_test->flags |= ETH_TEST_FL_FAILED;
-
if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED) {
int i;
for (i = 0; i < adapter->num_vfs; i++) {
@@ -1870,12 +1862,24 @@ static void ixgbe_diag_test(struct net_device *netdev,
}
}
+ /* Offline tests */
+ e_info(hw, "offline testing starting\n");
+
if (if_running)
/* indicate we're in test mode */
dev_close(netdev);
- else
- ixgbe_reset(adapter);
+ /* bringing adapter down disables SFP+ optics */
+ if (hw->mac.ops.enable_tx_laser)
+ hw->mac.ops.enable_tx_laser(hw);
+
+ /* Link test performed before hardware reset so autoneg doesn't
+ * interfere with test result
+ */
+ if (ixgbe_link_test(adapter, &data[4]))
+ eth_test->flags |= ETH_TEST_FL_FAILED;
+
+ ixgbe_reset(adapter);
e_info(hw, "register testing starting\n");
if (ixgbe_reg_test(adapter, &data[0]))
eth_test->flags |= ETH_TEST_FL_FAILED;
@@ -1908,16 +1912,22 @@ static void ixgbe_diag_test(struct net_device *netdev,
skip_loopback:
ixgbe_reset(adapter);
+ /* clear testing bit and return adapter to previous state */
clear_bit(__IXGBE_TESTING, &adapter->state);
if (if_running)
dev_open(netdev);
} else {
e_info(hw, "online testing starting\n");
+
+ /* if adapter is down, SFP+ optics will be disabled */
+ if (!if_running && hw->mac.ops.enable_tx_laser)
+ hw->mac.ops.enable_tx_laser(hw);
+
/* Online tests */
if (ixgbe_link_test(adapter, &data[4]))
eth_test->flags |= ETH_TEST_FL_FAILED;
- /* Online tests aren't run; pass by default */
+ /* Offline tests aren't run; pass by default */
data[0] = 0;
data[1] = 0;
data[2] = 0;
@@ -1925,6 +1935,10 @@ skip_loopback:
clear_bit(__IXGBE_TESTING, &adapter->state);
}
+
+ /* if adapter was down, ensure SFP+ optics are disabled again */
+ if (!if_running && hw->mac.ops.disable_tx_laser)
+ hw->mac.ops.disable_tx_laser(hw);
skip_ol_tests:
msleep_interruptible(4 * 1000);
}
--
1.7.11.7
^ permalink raw reply related
* [net-next 03/14] ixgbe: Update ptp_overflow check comment and jiffies
From: Jeff Kirsher @ 2013-01-23 22:44 UTC (permalink / raw)
To: davem; +Cc: Jacob Keller, netdev, gospo, sassmann, Jeff Kirsher
In-Reply-To: <1358981090-5794-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
This patch fixes the comment on ptp_overflow_check to match up with what is
currently used as the parameters. Also change the jiffies check to use
time_is_after_jiffies macro.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
index 1a751c9..2e54e0c 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c
@@ -407,21 +407,21 @@ void ixgbe_ptp_check_pps_event(struct ixgbe_adapter *adapter, u32 eicr)
/**
- * ixgbe_ptp_overflow_check - delayed work to detect SYSTIME overflow
- * @work: structure containing information about this work task
+ * ixgbe_ptp_overflow_check - watchdog task to detect SYSTIME overflow
+ * @adapter: private adapter struct
*
- * this work function is scheduled to continue reading the timecounter
+ * this watchdog task periodically reads the timecounter
* in order to prevent missing when the system time registers wrap
- * around. This needs to be run approximately twice a minute when no
- * PTP activity is occurring.
+ * around. This needs to be run approximately twice a minute.
*/
void ixgbe_ptp_overflow_check(struct ixgbe_adapter *adapter)
{
- unsigned long elapsed_jiffies = adapter->last_overflow_check - jiffies;
+ bool timeout = time_is_before_jiffies(adapter->last_overflow_check +
+ IXGBE_OVERFLOW_PERIOD);
struct timespec ts;
if ((adapter->flags2 & IXGBE_FLAG2_PTP_ENABLED) &&
- (elapsed_jiffies >= IXGBE_OVERFLOW_PERIOD)) {
+ (timeout)) {
ixgbe_ptp_gettime(&adapter->ptp_caps, &ts);
adapter->last_overflow_check = jiffies;
}
--
1.7.11.7
^ 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