| Message ID | 20111215191523.GA2561@tuxdriver.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
2011/12/15 John W. Linville <linville@tuxdriver.com>: > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e > > Dave, > > Here are a few more fixes intended for the 3.2 release. They are > all small and narrowly focused. John, I've made a mistake and didn't use [PATCH 3.2] header to make it clean my patch is fix. Could you take a look at [PATCH] bcma: support for suspend and resume please? It's not one-liner, but fixes lock ups, which I believe - we really want to avoid.
On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote: > 2011/12/15 John W. Linville <linville@tuxdriver.com>: > > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e > > > > Dave, > > > > Here are a few more fixes intended for the 3.2 release. They are > > all small and narrowly focused. > > John, I've made a mistake and didn't use [PATCH 3.2] header to make it > clean my patch is fix. Could you take a look at > [PATCH] bcma: support for suspend and resume > please? > > It's not one-liner, but fixes lock ups, which I believe - we really > want to avoid. It's late in the release cycle, and Dave specifically asked me to slow down. Are these suspend/resume lockups a regression? Or have they always been there? Do they happen to everyone? John
From: "John W. Linville" <linville@tuxdriver.com> Date: Thu, 15 Dec 2011 14:15:24 -0500 > Here are a few more fixes intended for the 3.2 release. They are > all small and narrowly focused. > > First is a one liner fix for a signedness problem in NFC that could > lead to an incorrect return code being propogated. Next are two > iwlwifi regression fixes that received some recent attention on the > linux-wireless mailing list. A third iwlwifi fix corrects a sequence > numbering error, which can cause a lot of bad behaviour in the wireless > network. The ath9k fix corrects a potential for an array underrun. > Finally, the mwifiex fix corrects a double list deletion. > > Please let me know if there are problems! Pulled, thanks John. -- 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
W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville <linville@tuxdriver.com> napisał: > On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote: >> 2011/12/15 John W. Linville <linville@tuxdriver.com>: >> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e >> > >> > Dave, >> > >> > Here are a few more fixes intended for the 3.2 release. They are >> > all small and narrowly focused. >> >> John, I've made a mistake and didn't use [PATCH 3.2] header to make it >> clean my patch is fix. Could you take a look at >> [PATCH] bcma: support for suspend and resume >> please? >> >> It's not one-liner, but fixes lock ups, which I believe - we really >> want to avoid. > > It's late in the release cycle, and Dave specifically asked me to slow down. > > Are these suspend/resume lockups a regression? Or have they always > been there? Do they happen to everyone? The bug is present since first days of bcma. That's why I even decided to add stable to CC. Personally I've tested that only on 1 machine (I don't have more suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2 users have to remove b43 & bcma before suspending [0], they complain about that since ever. Arend: I know you're also complaining for suspend in bcma. Can you comment on this? [0] http://ubuntuforums.org/showthread.php?t=1695746
W dniu 16 grudnia 2011 07:40 użytkownik Rafał Miłecki <zajec5@gmail.com> napisał: > W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville > <linville@tuxdriver.com> napisał: >> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote: >>> 2011/12/15 John W. Linville <linville@tuxdriver.com>: >>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e >>> > >>> > Dave, >>> > >>> > Here are a few more fixes intended for the 3.2 release. They are >>> > all small and narrowly focused. >>> >>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it >>> clean my patch is fix. Could you take a look at >>> [PATCH] bcma: support for suspend and resume >>> please? >>> >>> It's not one-liner, but fixes lock ups, which I believe - we really >>> want to avoid. >> >> It's late in the release cycle, and Dave specifically asked me to slow down. >> >> Are these suspend/resume lockups a regression? Or have they always >> been there? Do they happen to everyone? > > The bug is present since first days of bcma. That's why I even decided > to add stable to CC. > > Personally I've tested that only on 1 machine (I don't have more > suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2 > users have to remove b43 & bcma before suspending [0], they complain > about that since ever. > > Arend: I know you're also complaining for suspend in bcma. Can you > comment on this? > > [0] http://ubuntuforums.org/showthread.php?t=1695746 User nephyrin on #bcm-users has confirmed this patch fixes suspend&resume for him. Without this patch he got deadlock without seeing any kernel panic logs - quite an ugly case. I still think this patch may be worth taking as fix and backporting too.
On Mon, Dec 26, 2011 at 12:36:59AM +0100, Rafał Miłecki wrote: > W dniu 16 grudnia 2011 07:40 użytkownik Rafał Miłecki > <zajec5@gmail.com> napisał: > > W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville > > <linville@tuxdriver.com> napisał: > >> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote: > >>> 2011/12/15 John W. Linville <linville@tuxdriver.com>: > >>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e > >>> > > >>> > Dave, > >>> > > >>> > Here are a few more fixes intended for the 3.2 release. They are > >>> > all small and narrowly focused. > >>> > >>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it > >>> clean my patch is fix. Could you take a look at > >>> [PATCH] bcma: support for suspend and resume > >>> please? > >>> > >>> It's not one-liner, but fixes lock ups, which I believe - we really > >>> want to avoid. > >> > >> It's late in the release cycle, and Dave specifically asked me to slow down. > >> > >> Are these suspend/resume lockups a regression? Or have they always > >> been there? Do they happen to everyone? > > > > The bug is present since first days of bcma. That's why I even decided > > to add stable to CC. > > > > Personally I've tested that only on 1 machine (I don't have more > > suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2 > > users have to remove b43 & bcma before suspending [0], they complain > > about that since ever. > > > > Arend: I know you're also complaining for suspend in bcma. Can you > > comment on this? > > > > [0] http://ubuntuforums.org/showthread.php?t=1695746 > > User nephyrin on #bcm-users has confirmed this patch fixes > suspend&resume for him. Without this patch he got deadlock without > seeing any kernel panic logs - quite an ugly case. > > I still think this patch may be worth taking as fix and backporting too. What patch specifically? What is the git commit id of it in Linus's tree? Without that information, telling stable@ about it is pointless... greg k-h -- 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
W dniu 3 stycznia 2012 21:52 użytkownik Greg KH <greg@kroah.com> napisał: > On Mon, Dec 26, 2011 at 12:36:59AM +0100, Rafał Miłecki wrote: >> W dniu 16 grudnia 2011 07:40 użytkownik Rafał Miłecki >> <zajec5@gmail.com> napisał: >> > W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville >> > <linville@tuxdriver.com> napisał: >> >> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote: >> >>> 2011/12/15 John W. Linville <linville@tuxdriver.com>: >> >>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e >> >>> > >> >>> > Dave, >> >>> > >> >>> > Here are a few more fixes intended for the 3.2 release. They are >> >>> > all small and narrowly focused. >> >>> >> >>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it >> >>> clean my patch is fix. Could you take a look at >> >>> [PATCH] bcma: support for suspend and resume >> >>> please? >> >>> >> >>> It's not one-liner, but fixes lock ups, which I believe - we really >> >>> want to avoid. >> >> >> >> It's late in the release cycle, and Dave specifically asked me to slow down. >> >> >> >> Are these suspend/resume lockups a regression? Or have they always >> >> been there? Do they happen to everyone? >> > >> > The bug is present since first days of bcma. That's why I even decided >> > to add stable to CC. >> > >> > Personally I've tested that only on 1 machine (I don't have more >> > suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2 >> > users have to remove b43 & bcma before suspending [0], they complain >> > about that since ever. >> > >> > Arend: I know you're also complaining for suspend in bcma. Can you >> > comment on this? >> > >> > [0] http://ubuntuforums.org/showthread.php?t=1695746 >> >> User nephyrin on #bcm-users has confirmed this patch fixes >> suspend&resume for him. Without this patch he got deadlock without >> seeing any kernel panic logs - quite an ugly case. >> >> I still think this patch may be worth taking as fix and backporting too. > > What patch specifically? What is the git commit id of it in Linus's > tree? Without that information, telling stable@ about it is > pointless... Sorry Greg, it's about commit 775ab52142b02237a54184238e922251c59a2b5c Author: Rafał Miłecki <zajec5@gmail.com> Date: Fri Dec 9 22:16:07 2011 +0100 bcma: support for suspend and resume bcma used to lock up machine without enabling PCI or initializing CC. Cc: stable@vger.kernel.org Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> it's located in wireless-testing: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git John didn't pass this to Linus yet.
On Tue, Jan 03, 2012 at 11:06:59PM +0100, Rafał Miłecki wrote: > W dniu 3 stycznia 2012 21:52 użytkownik Greg KH <greg@kroah.com> napisał: > > On Mon, Dec 26, 2011 at 12:36:59AM +0100, Rafał Miłecki wrote: > >> W dniu 16 grudnia 2011 07:40 użytkownik Rafał Miłecki > >> <zajec5@gmail.com> napisał: > >> > W dniu 15 grudnia 2011 22:38 użytkownik John W. Linville > >> > <linville@tuxdriver.com> napisał: > >> >> On Thu, Dec 15, 2011 at 09:04:29PM +0100, Rafał Miłecki wrote: > >> >>> 2011/12/15 John W. Linville <linville@tuxdriver.com>: > >> >>> > commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e > >> >>> > > >> >>> > Dave, > >> >>> > > >> >>> > Here are a few more fixes intended for the 3.2 release. They are > >> >>> > all small and narrowly focused. > >> >>> > >> >>> John, I've made a mistake and didn't use [PATCH 3.2] header to make it > >> >>> clean my patch is fix. Could you take a look at > >> >>> [PATCH] bcma: support for suspend and resume > >> >>> please? > >> >>> > >> >>> It's not one-liner, but fixes lock ups, which I believe - we really > >> >>> want to avoid. > >> >> > >> >> It's late in the release cycle, and Dave specifically asked me to slow down. > >> >> > >> >> Are these suspend/resume lockups a regression? Or have they always > >> >> been there? Do they happen to everyone? > >> > > >> > The bug is present since first days of bcma. That's why I even decided > >> > to add stable to CC. > >> > > >> > Personally I've tested that only on 1 machine (I don't have more > >> > suspendable machines with mini PCIe slot). However all Macbook 8.1/8.2 > >> > users have to remove b43 & bcma before suspending [0], they complain > >> > about that since ever. > >> > > >> > Arend: I know you're also complaining for suspend in bcma. Can you > >> > comment on this? > >> > > >> > [0] http://ubuntuforums.org/showthread.php?t=1695746 > >> > >> User nephyrin on #bcm-users has confirmed this patch fixes > >> suspend&resume for him. Without this patch he got deadlock without > >> seeing any kernel panic logs - quite an ugly case. > >> > >> I still think this patch may be worth taking as fix and backporting too. > > > > What patch specifically? What is the git commit id of it in Linus's > > tree? Without that information, telling stable@ about it is > > pointless... > > Sorry Greg, it's about > > commit 775ab52142b02237a54184238e922251c59a2b5c > Author: Rafał Miłecki <zajec5@gmail.com> > Date: Fri Dec 9 22:16:07 2011 +0100 > > bcma: support for suspend and resume > > bcma used to lock up machine without enabling PCI or initializing CC. > > Cc: stable@vger.kernel.org > Signed-off-by: Rafał Miłecki <zajec5@gmail.com> > Signed-off-by: John W. Linville <linville@tuxdriver.com> > > it's located in wireless-testing: > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git > > John didn't pass this to Linus yet. Then there's nothing I can do about it. As it's properly tagged, I'll pick it up when it gets to Linus. thanks, greg k-h -- 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
diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c index 888abc2..528d5f3 100644 --- a/drivers/net/wireless/ath/ath9k/rc.c +++ b/drivers/net/wireless/ath/ath9k/rc.c @@ -1271,7 +1271,9 @@ static void ath_rc_init(struct ath_softc *sc, ath_rc_priv->max_valid_rate = k; ath_rc_sort_validrates(rate_table, ath_rc_priv); - ath_rc_priv->rate_max_phy = ath_rc_priv->valid_rate_index[k-4]; + ath_rc_priv->rate_max_phy = (k > 4) ? + ath_rc_priv->valid_rate_index[k-4] : + ath_rc_priv->valid_rate_index[k-1]; ath_rc_priv->rate_table = rate_table; ath_dbg(common, ATH_DBG_CONFIG, diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c index a7a6def..5c7c17c 100644 --- a/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c +++ b/drivers/net/wireless/iwlwifi/iwl-agn-rxon.c @@ -606,8 +606,8 @@ int iwlagn_mac_config(struct ieee80211_hw *hw, u32 changed) if (ctx->ht.enabled) { /* if HT40 is used, it should not change * after associated except channel switch */ - if (iwl_is_associated_ctx(ctx) && - !ctx->ht.is_40mhz) + if (!ctx->ht.is_40mhz || + !iwl_is_associated_ctx(ctx)) iwlagn_config_ht40(conf, ctx); } else ctx->ht.is_40mhz = false; diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c index 35a6b71..df1540c 100644 --- a/drivers/net/wireless/iwlwifi/iwl-agn-tx.c +++ b/drivers/net/wireless/iwlwifi/iwl-agn-tx.c @@ -91,7 +91,10 @@ static void iwlagn_tx_cmd_build_basic(struct iwl_priv *priv, tx_cmd->tid_tspec = qc[0] & 0xf; tx_flags &= ~TX_CMD_FLG_SEQ_CTL_MSK; } else { - tx_flags |= TX_CMD_FLG_SEQ_CTL_MSK; + if (info->flags & IEEE80211_TX_CTL_ASSIGN_SEQ) + tx_flags |= TX_CMD_FLG_SEQ_CTL_MSK; + else + tx_flags &= ~TX_CMD_FLG_SEQ_CTL_MSK; } iwlagn_tx_cmd_protection(priv, info, fc, &tx_flags); diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c index bacc06c..e0e9a3d 100644 --- a/drivers/net/wireless/iwlwifi/iwl-agn.c +++ b/drivers/net/wireless/iwlwifi/iwl-agn.c @@ -2850,6 +2850,9 @@ static int iwlagn_mac_tx_sync(struct ieee80211_hw *hw, int ret; u8 sta_id; + if (ctx->ctxid != IWL_RXON_CTX_PAN) + return 0; + IWL_DEBUG_MAC80211(priv, "enter\n"); mutex_lock(&priv->shrd->mutex); @@ -2898,6 +2901,9 @@ static void iwlagn_mac_finish_tx_sync(struct ieee80211_hw *hw, struct iwl_vif_priv *vif_priv = (void *)vif->drv_priv; struct iwl_rxon_context *ctx = vif_priv->ctx; + if (ctx->ctxid != IWL_RXON_CTX_PAN) + return; + IWL_DEBUG_MAC80211(priv, "enter\n"); mutex_lock(&priv->shrd->mutex); diff --git a/drivers/net/wireless/mwifiex/cmdevt.c b/drivers/net/wireless/mwifiex/cmdevt.c index ac27815..6e0a3ea 100644 --- a/drivers/net/wireless/mwifiex/cmdevt.c +++ b/drivers/net/wireless/mwifiex/cmdevt.c @@ -939,7 +939,6 @@ mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter) { struct cmd_ctrl_node *cmd_node = NULL, *tmp_node = NULL; unsigned long cmd_flags; - unsigned long cmd_pending_q_flags; unsigned long scan_pending_q_flags; uint16_t cancel_scan_cmd = false; @@ -949,12 +948,9 @@ mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter) cmd_node = adapter->curr_cmd; cmd_node->wait_q_enabled = false; cmd_node->cmd_flag |= CMD_F_CANCELED; - spin_lock_irqsave(&adapter->cmd_pending_q_lock, - cmd_pending_q_flags); - list_del(&cmd_node->list); - spin_unlock_irqrestore(&adapter->cmd_pending_q_lock, - cmd_pending_q_flags); mwifiex_insert_cmd_to_free_q(adapter, cmd_node); + mwifiex_complete_cmd(adapter, adapter->curr_cmd); + adapter->curr_cmd = NULL; spin_unlock_irqrestore(&adapter->mwifiex_cmd_lock, cmd_flags); } @@ -981,7 +977,6 @@ mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter) spin_unlock_irqrestore(&adapter->mwifiex_cmd_lock, cmd_flags); } adapter->cmd_wait_q.status = -1; - mwifiex_complete_cmd(adapter, adapter->curr_cmd); } /* diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c index 3925c65..ea66034 100644 --- a/net/nfc/nci/core.c +++ b/net/nfc/nci/core.c @@ -69,7 +69,7 @@ static int __nci_request(struct nci_dev *ndev, __u32 timeout) { int rc = 0; - unsigned long completion_rc; + long completion_rc; ndev->req_status = NCI_REQ_PEND;
commit 42a3b63bb2ca4996a3d1210a004eae2333f1119e Dave, Here are a few more fixes intended for the 3.2 release. They are all small and narrowly focused. First is a one liner fix for a signedness problem in NFC that could lead to an incorrect return code being propogated. Next are two iwlwifi regression fixes that received some recent attention on the linux-wireless mailing list. A third iwlwifi fix corrects a sequence numbering error, which can cause a lot of bad behaviour in the wireless network. The ath9k fix corrects a potential for an array underrun. Finally, the mwifiex fix corrects a double list deletion. Please let me know if there are problems! Thanks, John --- The following changes since commit 3f1e6d3fd37bd4f25e5b19f1c7ca21850426c33f: sch_gred: should not use GFP_KERNEL while holding a spinlock (2011-12-12 19:08:54 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem Dan Carpenter (1): nfc: signedness bug in __nci_request() Johannes Berg (1): iwlwifi: tx_sync only on PAN context John W. Linville (1): Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem Rajkumar Manoharan (1): ath9k: fix max phy rate at rate control init Wey-Yi Guy (2): iwlwifi: do not set the sequence control bit is not needed iwlwifi: allow to switch to HT40 if not associated Yogesh Ashok Powar (1): mwifiex: avoid double list_del in command cancel path drivers/net/wireless/ath/ath9k/rc.c | 4 +++- drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 4 ++-- drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 5 ++++- drivers/net/wireless/iwlwifi/iwl-agn.c | 6 ++++++ drivers/net/wireless/mwifiex/cmdevt.c | 9 ++------- net/nfc/nci/core.c | 2 +- 6 files changed, 18 insertions(+), 12 deletions(-)