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.
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
--
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
