From: Larry Finger <Larry.Finger@lwfinger.net>
To: Philipp Dreimann <philipp@dreimann.net>
Cc: linux-wireless@vger.kernel.org, sgruszka@redhat.com,
mikem@ring3k.org, John Linville <linville@tuxdriver.com>
Subject: Re: rtlwifi, rtl8192se bug soft-lockup
Date: Wed, 07 Dec 2011 11:23:48 -0600 [thread overview]
Message-ID: <4EDFA124.7010804@lwfinger.net> (raw)
In-Reply-To: <CADYPuQ61D997MA2JCw1WD_xOosaKvaWK-_RHeBkLtabydDj2iw@mail.gmail.com>
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
next prev parent reply other threads:[~2011-12-07 17:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EDFA124.7010804@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mikem@ring3k.org \
--cc=philipp@dreimann.net \
--cc=sgruszka@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).