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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.