On 7 December 2011 15:23, Larry Finger <Larry.Finger@xxxxxxxxxxxx> wrote: > On 12/07/2011 07:59 AM, Philipp Dreimann wrote: >> >> On 29 November 2011 00:16, Larry Finger<Larry.Finger@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
