From: Larry Finger <Larry.Finger@lwfinger.net>
To: Robie Basak <rb-oss-3@justgohome.co.uk>
Cc: linux-wireless@vger.kernel.org
Subject: Re: r8187se panic
Date: Fri, 12 Nov 2010 10:09:40 -0600 [thread overview]
Message-ID: <4CDD66C4.10603@lwfinger.net> (raw)
In-Reply-To: <slrnidqorp.dlr.rb-oss-3@mal.justgohome.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]
On 11/12/2010 09:55 AM, Robie Basak wrote:
> Larry,
>
> The patches have helped - thanks!
>
> Failure case A:
> 1) Boot with AC power connected and wireless on
> 2) Switch wireless off
> 3) Kernel panic
>
> With just the change_panic_to_warn patch, case A works fine now.
> However, the following sequence of events now causes some sort of
> infinite loop (with lots of stack traces in dmesg) instead of a hang
> like it did before:
>
> Failure case B:
> 1) Boot with AC power connected and wireless on
> 2) Suspend
> 3) Resume (and Network Manager kicks in to reconnect etc)
> 4) Remove AC power
> 5) (wait a few seconds)
> 6) Some sort of loop with lots being dumped to dmesg, no wireless
> connection resumes
>
> With the addition of the lock_pci_remove patch, case B goes away too.
> However, adding more to the failure case still causes problems:
>
> Failure case C:
> 1) Boot with AC power connected and wireless on
> 2) Suspend
> 3) Resume (and Network Manager kicks in to reconnect etc)
> 4) Remove AC power
> 5) (wait a few seconds)
> 6) Restore AC power
> 7) (wireless disconnects; some sort of loop in dmesg; it does manage
> to associate at times but this never lasts long)
> 8) (network Manager gives up) but the loop in dmesg continues
> 9) Reloading the module and toggling the wireless switch seems to fix
> it
>
> Note that I can work around cases B and C by having
> SUSPEND_MODULES=r8187se in /etc/pm/config.d. The original problem does
> seem to be resolved. Case C also seems pretty non-deterministic. I can't
> reproduce it reliably. I have also managed to cause a hang using various
> combinations of switching AC power, suspend and the wireless switch but
> I haven't managed to reproduce it.
>
> All of the stuff in dmesg I could see seems to be the same RE|WE bits
> not clear stack trace from your patch.
>
> Does this help? Is there anything else I can do?
OK, we are making progress.
First of all, that locking patch that I sent is garbage. Throw it away.
I have fixed the problem with the remove_proc_entry() warning. See the attached
patch.
Apply the new patch and the "change panic to warning" patch and redo your case
B. Send me the dmesg output and a description of what happened. That data you
can send directly. No need to spam the list with the lengthy dmesg output.
I think my guess of a locking problem was correct, but turning IRQs off was not
the solution. I hope the stack dumps from the first patch will clue me as to the
source of the problem.
Larry
[-- Attachment #2: rtl8187se_fix_proc_entry_warning --]
[-- Type: text/plain, Size: 724 bytes --]
When the driver is unloaded, it generates a warning at fs/proc/generic.c:816.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Index: linux-realtek/drivers/staging/rtl8187se/r8180_core.c
===================================================================
--- linux-realtek.orig/drivers/staging/rtl8187se/r8180_core.c
+++ linux-realtek/drivers/staging/rtl8187se/r8180_core.c
@@ -322,7 +322,7 @@ void rtl8180_proc_remove_one(struct net_
remove_proc_entry("stats-tx", priv->dir_dev);
remove_proc_entry("stats-rx", priv->dir_dev);
remove_proc_entry("registers", priv->dir_dev);
- remove_proc_entry(dev->name, rtl8180_proc);
+// remove_proc_entry(dev->name, rtl8180_proc);
priv->dir_dev = NULL;
}
}
next prev parent reply other threads:[~2010-11-12 16:09 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-12 0:41 r8187se panic Robie Basak
2010-11-12 2:00 ` Larry Finger
2010-11-12 11:06 ` Robie Basak
2010-11-12 13:06 ` Larry Finger
2010-11-12 15:55 ` Robie Basak
2010-11-12 16:09 ` Larry Finger [this message]
2010-11-12 17:00 ` Robie Basak
2010-11-12 17:28 ` Larry Finger
2010-11-12 17:40 ` Robie Basak
2010-11-13 18:18 ` James Womack
2010-11-13 18:44 ` Larry Finger
2010-11-13 19:27 ` James Womack
2010-11-13 20:02 ` Larry Finger
2010-11-14 12:22 ` James Womack
2010-11-14 16:18 ` Larry Finger
2010-11-14 18:49 ` James Womack
2010-11-14 20:23 ` Larry Finger
2010-11-15 21:05 ` James Womack
2010-11-15 23:44 ` Larry Finger
2010-11-16 9:55 ` James Womack
2010-11-16 14:24 ` Larry Finger
2010-11-16 14:46 ` James Womack
2010-11-16 15:00 ` Larry Finger
2010-11-16 15:08 ` Rafał Miłecki
2010-11-16 15:42 ` Larry Finger
2010-11-16 16:55 ` James Womack
2010-11-16 17:16 ` Larry Finger
2010-11-14 19:38 ` James Womack
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=4CDD66C4.10603@lwfinger.net \
--to=larry.finger@lwfinger.net \
--cc=linux-wireless@vger.kernel.org \
--cc=rb-oss-3@justgohome.co.uk \
/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).