* rtlwifi, rtl8192se bug soft-lockup @ 2011-11-29 0:58 Philipp Dreimann 2011-11-29 2:16 ` Larry Finger 0 siblings, 1 reply; 8+ messages in thread From: Philipp Dreimann @ 2011-11-29 0:58 UTC (permalink / raw) To: linux-wireless; +Cc: larry.finger, sgruszka, mikem Hello! I since kernel v3.1, my system suffers from lock-ups because of the rtl8192se driver. v3.0 is still fine. [ 704.057088] Pid: 2112, comm: kworker/0:3 Not tainted 3.1.0-1-686-pae #1 ASUSTeK Computer INC. 1201T/1201T [ 704.057120] EIP: 0060:[<c105cf7c>] EFLAGS: 00000297 CPU: 0 [ 704.057140] EIP is at do_raw_spin_lock+0x10/0x15 [ 704.057152] EAX: f4bbd188 EBX: f4bbd160 ECX: f4bbc4a8 EDX: 00009998 [ 704.057164] ESI: f4bbc320 EDI: 00000000 EBP: 00000100 ESP: f580dfc0 [ 704.057175] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 704.057190] Process kworker/0:3 (pid: 2112, ti=f580c000 task=f4b69660 task.ti=f49d8000) [ 704.057200] Stack: [ 704.057210] f84c5608 f4bbd308 f4bbd30c c103bac7 00000006 c13caa18 c103c05d c103c0f1 [ 704.057265] 00000001 0000000a 00000000 f49d9ebc f49d8000 c103c05d 00000046 c100ccb4 [ 704.057322] Call Trace: [ 704.057352] [<f84c5608>] ? rtl_lps_leave+0xf/0xc4 [rtlwifi] [ 704.057369] [<c103bac7>] ? tasklet_action+0x62/0xa5 [ 704.057383] [<c103c05d>] ? local_bh_enable+0x2/0x2 [ 704.057397] [<c103c0f1>] ? __do_softirq+0x94/0x12f [ 704.057411] [<c103c05d>] ? local_bh_enable+0x2/0x2 [ 704.057420] <IRQ> [ 704.057438] [<c103c2e2>] ? irq_exit+0x32/0x80 [ 704.057454] [<c100ca6e>] ? do_IRQ+0x65/0x76 [ 704.057468] [<c12b2a30>] ? common_interrupt+0x30/0x38 [ 704.057487] [<c1156283>] ? delay_tsc+0x1d/0x54 [ 704.057501] [<c115623b>] ? __delay+0x6/0x7 [ 704.057520] [<f86a4a15>] ? rtl92s_phy_set_rf_power_state+0x458/0x531 [rtl8192se] [ 704.057543] [<f84c4fd1>] ? rtl_ps_set_rf_state+0xbd/0xc2 [rtlwifi] [ 704.057566] [<f84c5973>] ? rtl_swlps_rf_sleep+0x6f/0x154 [rtlwifi] [ 704.057587] [<f84c5a7b>] ? rtl_swlps_wq_callback+0x23/0x78 [rtlwifi] [ 704.057603] [<c1049633>] ? process_one_work+0x112/0x1fa [ 704.057624] [<f84c5a58>] ? rtl_swlps_rf_sleep+0x154/0x154 [rtlwifi] [ 704.057638] [<c104a33e>] ? worker_thread+0xa9/0x122 [ 704.057653] [<c104a295>] ? manage_workers.isra.23+0x13d/0x13d [ 704.057668] [<c104ca80>] ? kthread+0x63/0x68 [ 704.057683] [<c104ca1d>] ? kthread_worker_fn+0x101/0x101 [ 704.057696] [<c12b2a3e>] ? kernel_thread_helper+0x6/0x10 [ 704.057706] Code: c3 3e ff 08 79 05 e8 0c 9d 0f 00 c3 3e 81 28 00 00 10 00 74 05 e8 e1 9c 0f 00 c3 ba 00 01 00 00 3e 66 0f c1 10 38 f2 74 06 f3 90 <8a> 10 eb f6 c3 89 c2 0f b7 02 38 e0 8d 88 00 01 00 00 75 05 3e One of the reasons for this lockup is most likely the change from spin_lock_irq* to spin_lock, see 67fc6052a49b781efbcfc138f3b68fe79ddd0c2f and earlier. I will try the recently proposed patch for another problem from Stanislaw, [PATCH v2] rtlwifi: fix lps_lock deadlock, to check if it resolves my issue as well. But I think that Mike might be affected by the change again... BR, Philipp ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: rtlwifi, rtl8192se bug soft-lockup 2011-11-29 0:58 rtlwifi, rtl8192se bug soft-lockup Philipp Dreimann @ 2011-11-29 2:16 ` Larry Finger 2011-12-07 13:59 ` Philipp Dreimann 0 siblings, 1 reply; 8+ messages in thread From: Larry Finger @ 2011-11-29 2:16 UTC (permalink / raw) To: Philipp Dreimann; +Cc: linux-wireless, sgruszka, mikem On 11/28/2011 06:58 PM, Philipp Dreimann wrote: > Hello! > > I since kernel v3.1, my system suffers from lock-ups because of the > rtl8192se driver. v3.0 is still fine. > > > [ 704.057088] Pid: 2112, comm: kworker/0:3 Not tainted > 3.1.0-1-686-pae #1 ASUSTeK Computer INC. 1201T/1201T > [ 704.057120] EIP: 0060:[<c105cf7c>] EFLAGS: 00000297 CPU: 0 > [ 704.057140] EIP is at do_raw_spin_lock+0x10/0x15 > [ 704.057152] EAX: f4bbd188 EBX: f4bbd160 ECX: f4bbc4a8 EDX: 00009998 > [ 704.057164] ESI: f4bbc320 EDI: 00000000 EBP: 00000100 ESP: f580dfc0 > [ 704.057175] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > [ 704.057190] Process kworker/0:3 (pid: 2112, ti=f580c000 > task=f4b69660 task.ti=f49d8000) > [ 704.057200] Stack: > [ 704.057210] f84c5608 f4bbd308 f4bbd30c c103bac7 00000006 c13caa18 > c103c05d c103c0f1 > [ 704.057265] 00000001 0000000a 00000000 f49d9ebc f49d8000 c103c05d > 00000046 c100ccb4 > [ 704.057322] Call Trace: > [ 704.057352] [<f84c5608>] ? rtl_lps_leave+0xf/0xc4 [rtlwifi] > [ 704.057369] [<c103bac7>] ? tasklet_action+0x62/0xa5 > [ 704.057383] [<c103c05d>] ? local_bh_enable+0x2/0x2 > [ 704.057397] [<c103c0f1>] ? __do_softirq+0x94/0x12f > [ 704.057411] [<c103c05d>] ? local_bh_enable+0x2/0x2 > [ 704.057420]<IRQ> > [ 704.057438] [<c103c2e2>] ? irq_exit+0x32/0x80 > [ 704.057454] [<c100ca6e>] ? do_IRQ+0x65/0x76 > [ 704.057468] [<c12b2a30>] ? common_interrupt+0x30/0x38 > [ 704.057487] [<c1156283>] ? delay_tsc+0x1d/0x54 > [ 704.057501] [<c115623b>] ? __delay+0x6/0x7 > [ 704.057520] [<f86a4a15>] ? > rtl92s_phy_set_rf_power_state+0x458/0x531 [rtl8192se] > [ 704.057543] [<f84c4fd1>] ? rtl_ps_set_rf_state+0xbd/0xc2 [rtlwifi] > [ 704.057566] [<f84c5973>] ? rtl_swlps_rf_sleep+0x6f/0x154 [rtlwifi] > [ 704.057587] [<f84c5a7b>] ? rtl_swlps_wq_callback+0x23/0x78 [rtlwifi] > [ 704.057603] [<c1049633>] ? process_one_work+0x112/0x1fa > [ 704.057624] [<f84c5a58>] ? rtl_swlps_rf_sleep+0x154/0x154 [rtlwifi] > [ 704.057638] [<c104a33e>] ? worker_thread+0xa9/0x122 > [ 704.057653] [<c104a295>] ? manage_workers.isra.23+0x13d/0x13d > [ 704.057668] [<c104ca80>] ? kthread+0x63/0x68 > [ 704.057683] [<c104ca1d>] ? kthread_worker_fn+0x101/0x101 > [ 704.057696] [<c12b2a3e>] ? kernel_thread_helper+0x6/0x10 > [ 704.057706] Code: c3 3e ff 08 79 05 e8 0c 9d 0f 00 c3 3e 81 28 00 > 00 10 00 74 05 e8 e1 9c 0f 00 c3 ba 00 01 00 00 3e 66 0f c1 10 38 f2 > 74 06 f3 90<8a> 10 eb f6 c3 89 c2 0f b7 02 38 e0 8d 88 00 01 00 00 75 > 05 3e > > One of the reasons for this lockup is most likely the change from > spin_lock_irq* to spin_lock, see > 67fc6052a49b781efbcfc138f3b68fe79ddd0c2f and earlier. > > I will try the recently proposed patch for another problem from > Stanislaw, [PATCH v2] rtlwifi: fix lps_lock deadlock, to check if it > resolves my issue as well. But I think that Mike might be affected by > the change again... From a quick look, Stanislaw's patch should fix your system. If not, then please consider pulling a git tree and checking out commit 34ddb20, which is the one before 67fc6052. Larry ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: rtlwifi, rtl8192se bug soft-lockup 2011-11-29 2:16 ` Larry Finger @ 2011-12-07 13:59 ` Philipp Dreimann 2011-12-07 17:23 ` Larry Finger 0 siblings, 1 reply; 8+ messages in thread From: Philipp Dreimann @ 2011-12-07 13:59 UTC (permalink / raw) To: Larry Finger; +Cc: linux-wireless, sgruszka, mikem On 29 November 2011 00:16, Larry Finger <Larry.Finger@lwfinger.net> wrote: > On 11/28/2011 06:58 PM, Philipp Dreimann wrote: > From a quick look, Stanislaw's patch should fix your system. If not, then > please consider pulling a git tree and checking out commit 34ddb20, which is > the one before 67fc6052. It fixed the issue *but* I am currently back to kernel v3.0.3, as it is the most stable for me. I am not sure whether new issues were introduced by using a v3.2-rc or if there is more wrong in the rtl8192se driver itself. I had random sound and standby issues at which I will have a look some other day. Another idea about the problem: I omitted for some reason the following line in the first email about the problem: [ 732.056049] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:3:2112] While looking at the Call Trace and the code I have no idea why rtl92s_phy_set_rf_power_state needs that much time for the ERFSLEEP operation. I suspected an issue in the loop but did not find it so far. Another solution which I tested was the following: 0. rtl_lps_leave function informs the rtl92s_phy_set_rf_power_state being in the ERFSLEEP-case-loop, that it needs the lock. 1. rtl92s_phy_set_rf_power_state notices, "return false" ( leaves the loop and function as if the action failed ) and the lock is released. This seemed to work fine as well. - But I am not sure what this might break for others... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: rtlwifi, rtl8192se bug soft-lockup 2011-12-07 13:59 ` Philipp Dreimann @ 2011-12-07 17:23 ` Larry Finger 2011-12-07 20:47 ` Philipp Dreimann 0 siblings, 1 reply; 8+ messages in thread From: Larry Finger @ 2011-12-07 17:23 UTC (permalink / raw) To: Philipp Dreimann; +Cc: linux-wireless, sgruszka, mikem, John Linville On 12/07/2011 07:59 AM, Philipp Dreimann wrote: > On 29 November 2011 00:16, Larry Finger<Larry.Finger@lwfinger.net> wrote: >> On 11/28/2011 06:58 PM, Philipp Dreimann wrote: >> From a quick look, Stanislaw's patch should fix your system. If not, then >> please consider pulling a git tree and checking out commit 34ddb20, which is >> the one before 67fc6052. > > It fixed the issue *but* I am currently back to kernel v3.0.3, as it > is the most stable for me. I am not sure whether new issues were > introduced by using a v3.2-rc or if there is more wrong in the > rtl8192se driver itself. I had random sound and standby issues at > which I will have a look some other day. The bug that affected 3.2-rcX and fixed by Stanislaw's patch was not introduced until 3.1. A patch to fix it there was just queued by GregKH. > Another idea about the problem: > I omitted for some reason the following line in the first email about > the problem: > [ 732.056049] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:3:2112] That was a serious omission. > While looking at the Call Trace and the code I have no idea why > rtl92s_phy_set_rf_power_state needs that much time for the ERFSLEEP > operation. I suspected an issue in the loop but did not find it so > far. With a modern CPU, no loop can take 22s unless it involves a spin lock that never is released. > Another solution which I tested was the following: > 0. rtl_lps_leave function informs the rtl92s_phy_set_rf_power_state > being in the ERFSLEEP-case-loop, that it needs the lock. > 1. rtl92s_phy_set_rf_power_state notices, "return false" ( leaves the > loop and function as if the action failed ) and the lock is released. > > This seemed to work fine as well. - But I am not sure what this might > break for others... Is this the same patch that you posted on the linux-wireless ML? Although I have not heard back from Chaoming, I formatted that patch correctly and submitted it to John Linville yesterday with the notation that it should be applied to the stable kernels. Larry ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: rtlwifi, rtl8192se bug soft-lockup 2011-12-07 17:23 ` Larry Finger @ 2011-12-07 20:47 ` Philipp Dreimann 2011-12-07 21:09 ` Larry Finger 2011-12-08 9:52 ` Stanislaw Gruszka 0 siblings, 2 replies; 8+ messages in thread From: Philipp Dreimann @ 2011-12-07 20:47 UTC (permalink / raw) To: Larry Finger; +Cc: linux-wireless, sgruszka, mikem, John Linville On 7 December 2011 15:23, Larry Finger <Larry.Finger@lwfinger.net> wrote: > On 12/07/2011 07:59 AM, Philipp Dreimann wrote: >> >> On 29 November 2011 00:16, Larry Finger<Larry.Finger@lwfinger.net> wrote: >>> >>> On 11/28/2011 06:58 PM, Philipp Dreimann wrote: >>> From a quick look, Stanislaw's patch should fix your system. If not, >>> then >>> please consider pulling a git tree and checking out commit 34ddb20, which >>> is >>> the one before 67fc6052. >> >> >> It fixed the issue *but* I am currently back to kernel v3.0.3, as it >> is the most stable for me. I am not sure whether new issues were >> introduced by using a v3.2-rc or if there is more wrong in the >> rtl8192se driver itself. I had random sound and standby issues at >> which I will have a look some other day. > > > The bug that affected 3.2-rcX and fixed by Stanislaw's patch was not > introduced until 3.1. A patch to fix it there was just queued by GregKH. I had Stanislaw's patch included. >> Another idea about the problem: >> I omitted for some reason the following line in the first email about >> the problem: >> [ 732.056049] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:3:2112] > > > That was a serious omission. Yes. >> While looking at the Call Trace and the code I have no idea why >> rtl92s_phy_set_rf_power_state needs that much time for the ERFSLEEP >> operation. I suspected an issue in the loop but did not find it so >> far. > > > With a modern CPU, no loop can take 22s unless it involves a spin lock that > never is released. Yes, and it should not, as the loop has the lock! Putting things together: - Stanislaw's patch prevents the occurrence of the issue with using the irq safe spin lock. This is kind of an an revert of 312d5479dcfaca2b8aa451201b5388fdb8c8684a (I did not check everything!). - The loop-issue is still around but won't be noticed unless the delayed execution of rtl_lps_leave() has side-effects.. - As it took up to an hour to hit the issue, I suspect that there is something else going wrong which interferes with the loop... >> Another solution which I tested was the following: >> 0. rtl_lps_leave function informs the rtl92s_phy_set_rf_power_state >> being in the ERFSLEEP-case-loop, that it needs the lock. >> 1. rtl92s_phy_set_rf_power_state notices, "return false" ( leaves the >> loop and function as if the action failed ) and the lock is released. >> >> This seemed to work fine as well. - But I am not sure what this might >> break for others... > > Is this the same patch that you posted on the linux-wireless ML? No, this was not posted so far. I will try to debug the loop issue soonish. The outlined idea above only prevents the issue without knowing what is happening. > Although I > have not heard back from Chaoming, I formatted that patch correctly and > submitted it to John Linville yesterday with the notation that it should be > applied to the stable kernels. Thanks. The comment in v2 is fine now. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: rtlwifi, rtl8192se bug soft-lockup 2011-12-07 20:47 ` Philipp Dreimann @ 2011-12-07 21:09 ` Larry Finger 2011-12-08 9:52 ` Stanislaw Gruszka 1 sibling, 0 replies; 8+ messages in thread From: Larry Finger @ 2011-12-07 21:09 UTC (permalink / raw) To: Philipp Dreimann; +Cc: linux-wireless, sgruszka, mikem, John Linville On 12/07/2011 02:47 PM, Philipp Dreimann wrote: > On 7 December 2011 15:23, Larry Finger<Larry.Finger@lwfinger.net> wrote: >> On 12/07/2011 07:59 AM, Philipp Dreimann wrote: >>> >>> On 29 November 2011 00:16, Larry Finger<Larry.Finger@lwfinger.net> wrote: >>>> >>>> On 11/28/2011 06:58 PM, Philipp Dreimann wrote: >>>> From a quick look, Stanislaw's patch should fix your system. If not, >>>> then >>>> please consider pulling a git tree and checking out commit 34ddb20, which >>>> is >>>> the one before 67fc6052. >>> >>> >>> It fixed the issue *but* I am currently back to kernel v3.0.3, as it >>> is the most stable for me. I am not sure whether new issues were >>> introduced by using a v3.2-rc or if there is more wrong in the >>> rtl8192se driver itself. I had random sound and standby issues at >>> which I will have a look some other day. >> >> >> The bug that affected 3.2-rcX and fixed by Stanislaw's patch was not >> introduced until 3.1. A patch to fix it there was just queued by GregKH. > > I had Stanislaw's patch included. > >>> Another idea about the problem: >>> I omitted for some reason the following line in the first email about >>> the problem: >>> [ 732.056049] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:3:2112] >> >> >> That was a serious omission. > > Yes. > >>> While looking at the Call Trace and the code I have no idea why >>> rtl92s_phy_set_rf_power_state needs that much time for the ERFSLEEP >>> operation. I suspected an issue in the loop but did not find it so >>> far. >> >> >> With a modern CPU, no loop can take 22s unless it involves a spin lock that >> never is released. > > Yes, and it should not, as the loop has the lock! > > Putting things together: > > - Stanislaw's patch prevents the occurrence of the issue with using > the irq safe spin lock. > This is kind of an an revert of > 312d5479dcfaca2b8aa451201b5388fdb8c8684a (I did not check > everything!). > > - The loop-issue is still around but won't be noticed unless the > delayed execution of rtl_lps_leave() has side-effects.. > > - As it took up to an hour to hit the issue, I suspect that there is > something else going wrong which interferes with the loop... I ran for almost 36 hours and never hit the issue. I have no idea what the difference is between our two systems. In fact, I have never hit the "stalled" CPU issue, even with the bug that Stanislaw fixed. You will need to do the testing. Larry ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: rtlwifi, rtl8192se bug soft-lockup 2011-12-07 20:47 ` Philipp Dreimann 2011-12-07 21:09 ` Larry Finger @ 2011-12-08 9:52 ` Stanislaw Gruszka 2011-12-08 17:26 ` Larry Finger 1 sibling, 1 reply; 8+ messages in thread From: Stanislaw Gruszka @ 2011-12-08 9:52 UTC (permalink / raw) To: Philipp Dreimann; +Cc: Larry Finger, linux-wireless, mikem, John Linville [-- Attachment #1: Type: text/plain, Size: 528 bytes --] On Wed, Dec 07, 2011 at 06:47:58PM -0200, Philipp Dreimann wrote: > No, this was not posted so far. I will try to debug the loop issue > soonish. The outlined idea above only prevents the issue without > knowing what is happening. I looked at it a bit more and realized that we can replace spinlock by mutex. This should fix remaining problems here, and hopefully do not introduce any others. Could you test two attached patches, and if they do not crash intermediately :-) retest again with CONFIG_LOCKDEP ? Thanks Stanislaw [-- Attachment #2: 0001-rtlwifi-use-work-for-lps.patch --] [-- Type: text/plain, Size: 3639 bytes --] >From ed41f99b001b31066f44d36898ff3e30642567c0 Mon Sep 17 00:00:00 2001 From: Stanislaw Gruszka <sgruszka@redhat.com> Date: Thu, 8 Dec 2011 10:34:41 +0100 Subject: [PATCH 1/2] rtlwifi: use work for lps --- drivers/net/wireless/rtlwifi/pci.c | 26 ++++++++++++++------------ drivers/net/wireless/rtlwifi/wifi.h | 3 ++- 2 files changed, 16 insertions(+), 13 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c index b6683a2..c1ac2a9 100644 --- a/drivers/net/wireless/rtlwifi/pci.c +++ b/drivers/net/wireless/rtlwifi/pci.c @@ -610,7 +610,7 @@ tx_status_ok: if (((rtlpriv->link_info.num_rx_inperiod + rtlpriv->link_info.num_tx_inperiod) > 8) || (rtlpriv->link_info.num_rx_inperiod > 2)) { - tasklet_schedule(&rtlpriv->works.ips_leave_tasklet); + schedule_work(&rtlpriv->works.lps_leave_work); } } @@ -736,7 +736,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw) if (((rtlpriv->link_info.num_rx_inperiod + rtlpriv->link_info.num_tx_inperiod) > 8) || (rtlpriv->link_info.num_rx_inperiod > 2)) { - tasklet_schedule(&rtlpriv->works.ips_leave_tasklet); + schedule_work(&rtlpriv->works.lps_leave_work); } dev_kfree_skb_any(skb); @@ -900,11 +900,6 @@ static void _rtl_pci_irq_tasklet(struct ieee80211_hw *hw) _rtl_pci_tx_chk_waitq(hw); } -static void _rtl_pci_ips_leave_tasklet(struct ieee80211_hw *hw) -{ - rtl_lps_leave(hw); -} - static void _rtl_pci_prepare_bcn_tasklet(struct ieee80211_hw *hw) { struct rtl_priv *rtlpriv = rtl_priv(hw); @@ -942,6 +937,15 @@ static void _rtl_pci_prepare_bcn_tasklet(struct ieee80211_hw *hw) return; } +static void rtl_lps_leave_work_callback(struct work_struct *work) +{ + struct rtl_works *rtlworks = + container_of(work, struct rtl_works, lps_leave_work); + struct ieee80211_hw *hw = rtlworks->hw; + + rtl_lps_leave(hw); +} + static void _rtl_pci_init_trx_var(struct ieee80211_hw *hw) { struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw)); @@ -1003,9 +1007,7 @@ static void _rtl_pci_init_struct(struct ieee80211_hw *hw, tasklet_init(&rtlpriv->works.irq_prepare_bcn_tasklet, (void (*)(unsigned long))_rtl_pci_prepare_bcn_tasklet, (unsigned long)hw); - tasklet_init(&rtlpriv->works.ips_leave_tasklet, - (void (*)(unsigned long))_rtl_pci_ips_leave_tasklet, - (unsigned long)hw); + INIT_WORK(&rtlpriv->works.lps_leave_work, rtl_lps_leave_work_callback); } static int _rtl_pci_init_tx_ring(struct ieee80211_hw *hw, @@ -1475,7 +1477,7 @@ static void rtl_pci_deinit(struct ieee80211_hw *hw) synchronize_irq(rtlpci->pdev->irq); tasklet_kill(&rtlpriv->works.irq_tasklet); - tasklet_kill(&rtlpriv->works.ips_leave_tasklet); + cancel_work_sync(&rtlpriv->works.lps_leave_work); flush_workqueue(rtlpriv->works.rtl_wq); destroy_workqueue(rtlpriv->works.rtl_wq); @@ -1550,7 +1552,7 @@ static void rtl_pci_stop(struct ieee80211_hw *hw) set_hal_stop(rtlhal); rtlpriv->cfg->ops->disable_interrupt(hw); - tasklet_kill(&rtlpriv->works.ips_leave_tasklet); + cancel_work_sync(&rtlpriv->works.lps_leave_work); spin_lock_irqsave(&rtlpriv->locks.rf_ps_lock, flags); while (ppsc->rfchange_inprogress) { diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h index f3c132b..6e6353b 100644 --- a/drivers/net/wireless/rtlwifi/wifi.h +++ b/drivers/net/wireless/rtlwifi/wifi.h @@ -1576,7 +1576,8 @@ struct rtl_works { /* For SW LPS */ struct delayed_work ps_work; struct delayed_work ps_rfon_wq; - struct tasklet_struct ips_leave_tasklet; + + struct work_struct lps_leave_work; }; struct rtl_debug { -- 1.7.1 [-- Attachment #3: 0002-rtlwifi-merge-ips-lps-spinlocks-into-one-mutex.patch --] [-- Type: text/plain, Size: 4211 bytes --] >From 8d2a9ff16d466d6dff638393095029e670625301 Mon Sep 17 00:00:00 2001 From: Stanislaw Gruszka <sgruszka@redhat.com> Date: Thu, 8 Dec 2011 10:48:09 +0100 Subject: [PATCH 2/2] rtlwifi: merge ips,lps spinlocks into one mutex --- drivers/net/wireless/rtlwifi/base.c | 3 +-- drivers/net/wireless/rtlwifi/ps.c | 20 ++++++++++---------- drivers/net/wireless/rtlwifi/wifi.h | 3 +-- 3 files changed, 12 insertions(+), 14 deletions(-) diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c index a13ecfc..d81a602 100644 --- a/drivers/net/wireless/rtlwifi/base.c +++ b/drivers/net/wireless/rtlwifi/base.c @@ -448,12 +448,11 @@ int rtl_init_core(struct ieee80211_hw *hw) /* <4> locks */ mutex_init(&rtlpriv->locks.conf_mutex); - spin_lock_init(&rtlpriv->locks.ips_lock); + mutex_init(&rtlpriv->locks.ps_mutex); spin_lock_init(&rtlpriv->locks.irq_th_lock); spin_lock_init(&rtlpriv->locks.h2c_lock); spin_lock_init(&rtlpriv->locks.rf_ps_lock); spin_lock_init(&rtlpriv->locks.rf_lock); - spin_lock_init(&rtlpriv->locks.lps_lock); spin_lock_init(&rtlpriv->locks.waitq_lock); spin_lock_init(&rtlpriv->locks.cck_and_rw_pagea_lock); diff --git a/drivers/net/wireless/rtlwifi/ps.c b/drivers/net/wireless/rtlwifi/ps.c index db52628..a14a68b 100644 --- a/drivers/net/wireless/rtlwifi/ps.c +++ b/drivers/net/wireless/rtlwifi/ps.c @@ -241,7 +241,7 @@ void rtl_ips_nic_on(struct ieee80211_hw *hw) if (mac->opmode != NL80211_IFTYPE_STATION) return; - spin_lock(&rtlpriv->locks.ips_lock); + mutex_lock(&rtlpriv->locks.ps_mutex); if (ppsc->inactiveps) { rtstate = ppsc->rfpwr_state; @@ -257,7 +257,7 @@ void rtl_ips_nic_on(struct ieee80211_hw *hw) } } - spin_unlock(&rtlpriv->locks.ips_lock); + mutex_unlock(&rtlpriv->locks.ps_mutex); } /*for FW LPS*/ @@ -395,7 +395,7 @@ void rtl_lps_enter(struct ieee80211_hw *hw) if (mac->link_state != MAC80211_LINKED) return; - spin_lock(&rtlpriv->locks.lps_lock); + mutex_lock(&rtlpriv->locks.ps_mutex); /* Idle for a while if we connect to AP a while ago. */ if (mac->cnt_after_linked >= 2) { @@ -407,7 +407,7 @@ void rtl_lps_enter(struct ieee80211_hw *hw) } } - spin_unlock(&rtlpriv->locks.lps_lock); + mutex_unlock(&rtlpriv->locks.ps_mutex); } /*Leave the leisure power save mode.*/ @@ -417,7 +417,7 @@ void rtl_lps_leave(struct ieee80211_hw *hw) struct rtl_ps_ctl *ppsc = rtl_psc(rtl_priv(hw)); struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw)); - spin_lock(&rtlpriv->locks.lps_lock); + mutex_lock(&rtlpriv->locks.ps_mutex); if (ppsc->fwctrl_lps) { if (ppsc->dot11_psmode != EACTIVE) { @@ -438,7 +438,7 @@ void rtl_lps_leave(struct ieee80211_hw *hw) rtl_lps_set_psmode(hw, EACTIVE); } } - spin_unlock(&rtlpriv->locks.lps_lock); + mutex_unlock(&rtlpriv->locks.ps_mutex); } /* For sw LPS*/ @@ -539,9 +539,9 @@ void rtl_swlps_rf_awake(struct ieee80211_hw *hw) RT_CLEAR_PS_LEVEL(ppsc, RT_PS_LEVEL_ASPM); } - spin_lock(&rtlpriv->locks.lps_lock); + mutex_lock(&rtlpriv->locks.ps_mutex); rtl_ps_set_rf_state(hw, ERFON, RF_CHANGE_BY_PS); - spin_unlock(&rtlpriv->locks.lps_lock); + mutex_unlock(&rtlpriv->locks.ps_mutex); } void rtl_swlps_rfon_wq_callback(void *data) @@ -574,9 +574,9 @@ void rtl_swlps_rf_sleep(struct ieee80211_hw *hw) if (rtlpriv->link_info.busytraffic) return; - spin_lock(&rtlpriv->locks.lps_lock); + mutex_lock(&rtlpriv->locks.ps_mutex); rtl_ps_set_rf_state(hw, ERFSLEEP, RF_CHANGE_BY_PS); - spin_unlock(&rtlpriv->locks.lps_lock); + mutex_unlock(&rtlpriv->locks.ps_mutex); if (ppsc->reg_rfps_level & RT_RF_OFF_LEVL_ASPM && !RT_IN_PS_LEVEL(ppsc, RT_PS_LEVEL_ASPM)) { diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h index 6e6353b..085dccd 100644 --- a/drivers/net/wireless/rtlwifi/wifi.h +++ b/drivers/net/wireless/rtlwifi/wifi.h @@ -1544,14 +1544,13 @@ struct rtl_hal_cfg { struct rtl_locks { /* mutex */ struct mutex conf_mutex; + struct mutex ps_mutex; /*spin lock */ - spinlock_t ips_lock; spinlock_t irq_th_lock; spinlock_t h2c_lock; spinlock_t rf_ps_lock; spinlock_t rf_lock; - spinlock_t lps_lock; spinlock_t waitq_lock; /*Dual mac*/ -- 1.7.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: rtlwifi, rtl8192se bug soft-lockup 2011-12-08 9:52 ` Stanislaw Gruszka @ 2011-12-08 17:26 ` Larry Finger 0 siblings, 0 replies; 8+ messages in thread From: Larry Finger @ 2011-12-08 17:26 UTC (permalink / raw) To: Stanislaw Gruszka; +Cc: Philipp Dreimann, linux-wireless, mikem, John Linville On 12/08/2011 03:52 AM, Stanislaw Gruszka wrote: > On Wed, Dec 07, 2011 at 06:47:58PM -0200, Philipp Dreimann wrote: >> No, this was not posted so far. I will try to debug the loop issue >> soonish. The outlined idea above only prevents the issue without >> knowing what is happening. > > I looked at it a bit more and realized that we can replace spinlock > by mutex. This should fix remaining problems here, and hopefully do > not introduce any others. Could you test two attached patches, and > if they do not crash intermediately :-) retest again with > CONFIG_LOCKDEP ? After about 1 hour of testing, I see no problems and no lockdep warnings. BTW, patch #2 did not apply to wireless-testing as your previous patch changing the locking in ps.c has already been applied. Fortunately, it was not much of a problem to get it applied using wiggle. Larry ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-12-08 17:26 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-29 0:58 rtlwifi, rtl8192se bug soft-lockup Philipp Dreimann 2011-11-29 2:16 ` Larry Finger 2011-12-07 13:59 ` Philipp Dreimann 2011-12-07 17:23 ` Larry Finger 2011-12-07 20:47 ` Philipp Dreimann 2011-12-07 21:09 ` Larry Finger 2011-12-08 9:52 ` Stanislaw Gruszka 2011-12-08 17:26 ` Larry Finger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).