linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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