From: Robin Holt <holt@sgi.com>
To: ipw3945-devel@lists.sourceforge.net, linux-wireless@vger.kernel.org
Cc: Robin Holt <holt@sgi.com>
Subject: Re: System pauses with iwl3945 AP associate. RFKill unpauses.
Date: Thu, 2 Oct 2008 22:29:38 -0500 [thread overview]
Message-ID: <20081003032938.GX28581@sgi.com> (raw)
In-Reply-To: <20081003022554.GU28581@sgi.com>
On Thu, Oct 02, 2008 at 09:25:54PM -0500, Robin Holt wrote:
> OK. I think I have convinced myself this is an issue with
> sta_info_debugfs_add_work(). I am going to turn off
> CONFIG_MAC80211_DEBUGFS and see if that makes things better.
Appear to be on the right track here. With CONFIG_MAC80211_DEBUGFS=y, I
could only suspend/resume approx 4 times without iwl3945 hanging. I had
worked around that by modprobe -r iwl3945 and waiting a while before
suspending. Now with CONFIG_MAC80211_DEBUGFS=n, I have done 6 suspends
with the machine suspended for 5 minutes before resuming and it has not
hung. That has not occurred before. I will continue to test this for
the next few days.
Thanks,
Robin
>
> Thanks,
> Robin
>
> On Thu, Oct 02, 2008 at 08:47:50PM -0500, Robin Holt wrote:
> > On Thu, Oct 02, 2008 at 06:34:22PM -0500, Robin Holt wrote:
> > > I do have KDB installed as well and one other thing I noticed is we are
> > > adding work to a workqueue at the time of the hang. Not sure if this
> > > is accurate and I forgot that I only have a VGA console so there is
> > > no record of the KDB output.
> >
> > OK. In KDB. Here goes...
> >
> > events/0 process is on cpu0 with the following stack.
> >
> > _spin_unlock_irqrestore+0x10
> > [mac80211]sta_info_debugfs_add_work+0x82
> > run_workqueue+0xd4
> > worker_thread+0x88
> > kthread+0x42
> >
> >
> > I few times later, I got:
> > _cond_resched+0x10
> > [mac80211]sta_info_destroy+0x10
> > [mac80211]sta_info_debugfs_add_work+0xee
> > run_workqueue+0xd4
> > worker_thread+0x88
> > kthread+0x42
> >
> > I am transposing these from screen to this email so I reserve the right
> > to be slightly off, but these appear to be the call traces.
> >
> > It looks to me like this add_work loop is truly an infinite loop and
> > preventing interrupts from being processed on cpu0.
> >
> > Thanks,
> > Robin
parent reply other threads:[~2008-10-03 3:29 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20081003022554.GU28581@sgi.com>]
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=20081003032938.GX28581@sgi.com \
--to=holt@sgi.com \
--cc=ipw3945-devel@lists.sourceforge.net \
--cc=linux-wireless@vger.kernel.org \
/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).